📝 0. 使用方式（建议先读）

0.1 先选范式，再开工

0.2 对比实验建议（把“优缺点”落到数字上）

• 需求澄清轮次：从“说得清”到“能开发”，来回沟通了多少轮

• 返工次数：因为理解偏差或边界遗漏导致的重做次数

• 质量闸门表现：测试、lint、类型检查、静态扫描是否一次过（first-pass）以及最终是否过（final）

• 变更可追溯性：出了问题能不能回到 PRD/Issue/Spec 找到当时的依据

• 协作成本：多人并行时的冲突、等待、同步成本有多高

0.3 术语澄清（避免误用）

• PRD（本手册语境）：面向 AI 可解析的提示化需求文档，不等同于传统大而全的产品需求文档

• SDD：规范驱动开发的流程思想，落地常见形态是“Spec-anchored”（规范随代码同步更新），不建议默认追求“规范自动生成一切代码”

• CCPM（本手册语境）：GitHub Issues-based 中心化项目管理法，避免与传统项目管理中的“关键链 CCPM（Critical Chain Project Management）”混淆

0.4 贯穿示例需求（用于下文模板示例）

• 需求标题：为一个 Web API 服务新增 API Key 鉴权 + 审计日志

• 目标（Goals）
• 为除健康检查外的所有 API 增加 API Key 鉴权
• 记录鉴权结果的审计日志（允许/拒绝、原因），支持排障与合规追溯

• 非目标（Non-Goals）
• 不做 OAuth/JWT、RBAC、多租户、权限细分
• 不做可视化后台、密钥轮换 UI

• 接口范围（示例）
• GET /health：不鉴权
• POST /orders：鉴权
• GET /orders/{id}：鉴权

• 规则与约束（Constraints）
• 客户端通过 Header X-API-Key 传入密钥
• 密钥从配置/环境变量读取，不写死在代码中
• 审计日志禁止打印完整密钥，只允许记录哈希前缀/后缀或指纹（例如前 4 位 + 后 4 位）
• 未携带/不合法密钥返回 401 Unauthorized，响应体包含可读错误码（例如 AUTH_MISSING_KEY / AUTH_INVALID_KEY）

• 验收标准（Acceptance Criteria）
• AC1：GET /health 在无 X-API-Key 时仍返回 200
• AC2：受保护接口在无 X-API-Key 时返回 401 且错误码为 AUTH_MISSING_KEY
• AC3：受保护接口在错误 X-API-Key 时返回 401 且错误码为 AUTH_INVALID_KEY
• AC4：受保护接口在正确 X-API-Key 时行为与原来一致
• AC5：每次鉴权必须产生日志，且日志中不出现完整密钥

📝 1. 通用工程规范（建议所有范式都遵守）

1.1 人机协作的“统一协议”

• 不把密钥、客户数据、未授权的私有代码片段发给外部模型

• 把 AI 输出当作“候选实现”，落地前至少过三关：先读懂 → 能跑通 → 再审查

• 只要涉及接口、数据模型或安全策略的变更，都要留下可追溯记录（PRD/Spec/Issue/Story 任一即可）

1.2 质量闸门（建议当作默认配置）

• 测试：关键路径必须能跑测试；确实不适合单测的部分，至少给出可执行的验收脚本/手工用例

• 静态检查：lint / typecheck / formatter（以项目现有工具为准）

• 安全：至少做一次依赖与代码安全扫描（以项目现有工具为准）

• 审查：至少 1 人 code review；高风险改动尽量结对审查

• JavaScript/TypeScript：npm test / npm run lint / npm run typecheck

• Python：pytest / ruff check . / mypy .

• Go：go test ./... / golangci-lint run

1.3 迭代节奏（适用于和 AI 的对话）

• 先小后大：先把最小闭环跑通，再逐步补边界、补校验、补性能

• 一轮只解决一个主问题：别把多个变量揉成一团，最后谁也验证不了

• 设定收敛条件：验收标准满足 + 质量闸门通过，就先到这里，不再无止境“精雕细琢”

1.4 产物最小集（保证可复用、可交接）

• 需求侧：至少给出可执行的验收标准（PRD/Issue/Story 任一即可）

• 设计侧：只记录“代码里看不出来但很关键”的决策（接口契约、数据约束、迁移/回滚、风险假设）

• 验证侧：写清楚“怎么验”（命令/脚本/测试入口/手工步骤），别只留一句“已测试”

📝 2. Vibe Coding（极简派：对话驱动、快速迭代）

2.1 适用场景

• 个人快速原型、一次性脚本、小修小补、探索性调研

• 不建议：多人协作核心业务、长期维护模块

2.2 实操流程（最小闭环）

1. 明确目标：用三句话写清楚“做什么 / 不做什么 / 硬约束是什么”

2. 先跑起来：先让 AI 给一个“能运行的最小版本”

3. 立刻验证：本地把关键路径跑通，别靠脑补

4. 小步迭代：每轮只追一个点（Bug/边界/性能/安全/可读性）

5. 收口加固：补测试、补错误处理、补日志（按项目要求来）

6. 提交前复检：跑质量闸门，再过一遍自查清单

2.3 Prompt 模板（直接可用）

2.4 自查清单（Vibe Coding 最常踩坑）

• 需求边界：有没有隐含前提没写出来（权限、并发、幂等、失败重试）

• 回归风险：有没有动到公共接口/数据结构，影响别的调用方

• 可维护性：有没有把一次性方案塞进长期维护的核心路径

📝 3. PRD（Prompt Requirements Document：提示需求文档）

3.1 适用场景

• 需要多人协作、需要明确验收标准的需求

• 与 SDD/6A/CCPM 搭配更顺手（PRD 可作为上游输入）

3.2 PRD 产物规范（模板）

3.2.1 PRD 示例（基于 0.4 贯穿示例需求）

3.3 实操流程

1. 写 PRD v0.1：先把目标、非目标、验收标准写到“够用”

2. 让 AI 做一次“需求体检”：找歧义、找缺失、找冲突、找不可测试的点

3. PRD v1.0 冻结：把它当成本次开发的输入基线（直到需求真的变更）

4. 由 PRD 拆任务：每个任务都要可验收、可独立合并

5. 开发与验证：实现过程中一旦偏离 PRD，就把原因和变更写回“变更记录”

📝 4. SDD（Spec-Driven Development：规范驱动开发）

4.1 适用场景

• 中大型项目、需求清晰、长期维护、合规审计要求较高

• 大型重构/核心模块重写

4.2 规范（Spec）结构模板

4.2.1 Spec 示例（基于 0.4 贯穿示例需求）

4.3 实操流程

1. 需求规格化：把 PRD 的验收标准翻译成可检验的 R1/R2（尽量别留模糊词）

2. 设计规格化：把接口、数据模型、失败策略、迁移/回滚说清楚

3. 任务原子化：任务要能独立实现、独立验证、独立合并

4. 按任务推进：一次只做一个任务，尽量减少上下文串味

5. 审查 + 验证：每个任务都过质量闸门

6. 同步 Spec：实现与 Spec 不一致时，先把 Spec 改对再改代码；必要时在 Spec 里写清楚“为什么要这样改”

📝 5. 6A（Align → Architect → Atomize → Approve → Automate → Assess）

5.1 适用场景

• 金融/医疗/安全敏感系统

• 高风险变更：权限、支付、审计、数据一致性、跨服务接口

5.2 6A 分阶段交付物（标准化）

A1. Align（需求对齐）

• 交付物：PRD v1.0（冻结）

• 通过条件：验收标准可执行、非目标明确、风险与回滚存在

A2. Architect（架构设计）

• 交付物：设计说明（接口、数据模型、错误策略、兼容/迁移）

• 通过条件：关键路径可说明、约束可验证、风险可控

A3. Atomize（任务原子化）

• 交付物：任务列表（每个任务含输入/输出/验证方式）

• 通过条件：任务之间依赖清晰；单任务可独立合并

A4. Approve（人工审批）

• 交付物：审批记录（批准的 PRD/设计/任务）

• 通过条件：核心风险点已有人类明确决策

A5. Automate（自动执行）

• 交付物：按任务实现的代码与测试

• 通过条件：所有质量闸门通过

A6. Assess（质量评估）

• 交付物：评估报告（缺陷、覆盖率、性能、安全扫描结果）

• 通过条件：达到团队门槛；未达标则回到对应阶段修正

📝 6. Peter Steinberger 工作流（务实派：精简规则 + 可检索文档）

6.1 适用场景

• 中小团队常规项目

• 需要保持效率，但希望上下文可复用、可检索

6.2 AGENTS.md（精简规则）模板

6.3 Frontmatter 索引文档模板

6.4 实操流程

1. 维护一份精简 AGENTS：把“必须遵守的硬规则”固定下来

2. 文档只写“可复用决策”：接口、数据模型、关键约束、踩坑与反例

3. 大任务拆分并做原子化提交：一次 PR 只解决一个主题

4. 预留“机械性重构”批次：让 AI 承担批量迁移、重命名、格式化

📝 7. PRP 五层上下文（PRD + 精选代码库 + AI 操作手册）

7.1 适用场景

• 追求高一次通过率、减少反复对话迭代

• 作为团队通用底座，配合其他范式使用

7.2 PRP 五层上下文（交付物清单）

1. 系统层：AI 角色、权限边界、输出格式约束

2. 业务层：业务背景、术语表、业务规则、合规约束

3. 技术层：技术栈、架构边界、性能指标、目录约定

4. 功能层：本次需求的 PRD/用户故事/验收标准

5. 验证层：质量闸门、测试策略、必须通过的检查项

7.3 PRP Prompt 模板（把 5 层一次性喂给 AI）

7.4 实操流程

1. 先把底座做出来：把项目里“不常变”的约束沉淀成 PRP 包

2. 需求来了只换功能层：其他层尽量别动，避免上下文漂移

3. 放 3-5 段“黄金代码”：用于风格对齐和模式复用，能省掉不少来回沟通

4. 按验证层推进：优先写测试，至少先写验收脚本，减少盲改

📝 8. BMAD（敏捷 AI 驱动开发：多角色分工 + 故事文件系统）

8.1 适用场景

• 大型项目、遗留系统迁移、复杂系统重构

• 需要把“需求→设计→实现→测试→交付”流程体系化

8.2 故事文件（Story File）模板

8.2.1 Story 示例（基于 0.4 贯穿示例需求）

8.3 角色分工（可用同一个模型分阶段执行）

• 分析师（Analyst）：澄清需求、补齐约束与边界

• 产品经理（PM）：聚焦目标/非目标/验收与里程碑

• 架构师（Architect）：定接口、定数据、定演进路径

• 敏捷主管（Scrum Master）：拆任务、排依赖、定优先级

• 开发者（Dev）：按任务实现、跑验证、提交 PR

• 测试（QA）：补测试、定义用例、做回归与风险扫描

8.4 实操流程（推荐节奏）

1. 规划阶段：Analyst → PM → Architect 先把 Story v1.0 写扎实

2. 执行阶段：Scrum Master 拆任务（每个任务都要能独立验证、独立合并）

3. 并行实现：Dev 按任务推进；QA 给出对应的验证清单

4. 评审与合并：合并时把 Story 更新到 v1.1/v1.2，把关键决策和变更记下来

5. 收敛发布：统一做一次 Assess（缺陷、性能、安全、回滚可行性）

📝 9. CCPM（GitHub Issues 中心化项目管理：多 AI 协作的状态中枢）

9.1 适用场景

• 已经使用 GitHub（或类似平台）做协作与代码评审

• 需要多 Agent/多人并行，担心上下文丢失、任务冲突、进度不透明

9.2 最小治理约定（让“中心化状态”真正可用）

• Issue 必填字段：目标/非目标、验收标准、验证方式、风险与回滚

• 标签约定：area/*（模块归属）、type/*（feat/bug/chore）、priority/*、status/*（todo/doing/blocked/done）

• 所有权约定：每个 Issue 都要有负责人（Assignee）；并行任务要明确文件/模块边界，尽量别多人挤同一个热点目录

• 并行硬约束：同一 area/* + status/doing 同时只保留 1 个 Issue；真要并行，就拆成不同 area/* 或不同仓库/模块边界

9.3 Issue 模板（单个 Issue 即一个可追踪任务）

9.3.1 Issue 示例（基于 0.4 贯穿示例需求）

9.4 实操流程

1. 用 PRD 拆成 Issue：每个 Issue 都要能独立交付、独立验收

2. Issue 作为状态中心：决策、进度、阻塞、风险都写回去

3. 并行执行要守边界：尽量避免多人/多 Agent 同时改同一文件或同一模块

4. PR 关联 Issue：在 PR 描述里引用 Issue，形成从需求到代码的闭环

5. 关闭条件：验收标准满足 + 质量闸门通过 + 回滚方案可执行

📝 10. 混合落地策略（推荐：用组合拳而非单一教条）

• PRP 做底座：上下文稳定下来，迭代次数自然会少

• PRD 做上游：需求表达更清晰，对齐成本更低

• Peter 工作流做日常默认：少量硬规则 + 原子化提交，足够覆盖大多数需求

• SDD/6A 用在高风险模块：把可追溯和质量控制抬上去

• BMAD+CCPM 面向企业级：角色化分工 + 状态中枢，专治“并行与复杂度”

📝 11. 一页式对比复盘表（跑完 8 个范式后填写）

📎 参考文章

• [1] AI编程方法论体系化研究：理论溯源、实战解析与团队协作优化_https://blog.rahc.top/article/thought-learning/ai-programming-methodologies