Customized Spec：我的 AI 开发流程规范（PO/架构师监管 + 多Agent并行）

这不是“多加一层流程”，而是把已经在做的事情变成可复用、可审计、可并行扩展的工程规范。

为什么要做这份 Spec

过去 AI 研发里最常见的问题不是“模型不够强”，而是：

1. 需求口径经常漂移，执行层只能边做边猜。
2. 多个 Agent 并行时，边界不清，返工和冲突频繁。
3. 结果难复盘，出了问题只能靠个人记忆追责。

所以我把流程标准化为 Customized Spec：用 PO/架构师做监管闭环，用多 Agent 做执行并行，把速度和质量同时拉起来。

角色分工（监管者 vs 执行者）

监管者（PO/架构师）

1. 定义任务边界、验收标准和优先级。
2. 拆解里程碑，控制节奏与风险。
3. 审阅关键设计与关键提交，做 go/no-go 决策。
4. 维护规范资产：模板、检查清单、回滚策略。

执行者（多 Agent + 人类开发者）

1. 按分工并行实现，严格遵守输入输出契约。
2. 在每个里程碑提交可验证产物（代码/文档/测试）。
3. 主动暴露阻塞与风险，不隐性跳过规范步骤。
4. 通过 PR/日志沉淀可追踪证据链。

核心原则：监管者负责“方向和质量门”，执行者负责“速度和产出密度”。

端到端七阶段流程

1. Stage 1 - 任务立项：明确业务目标、范围、约束、验收指标。
2. Stage 2 - Spec 编制：输出任务 spec，定义角色、接口、风险与回滚方案。
3. Stage 3 - 架构评审：监管者确认方案可行性与并行切分策略。
4. Stage 4 - 多 Agent 执行：按子任务并行推进，保持接口一致性。
5. Stage 5 - 集成验证：合并产物，执行测试与数据回归校验。
6. Stage 6 - 里程碑发布：按阶段打里程碑 commit，并同步里程碑 blog。
7. Stage 7 - 复盘沉淀：记录偏差、复用资产、更新规范版本。

MUST / SHOULD / MUST NOT 清单

MUST

1. 必须先有 spec，再进入编码阶段。
2. 必须定义监管者与执行者责任边界。
3. 必须按里程碑提交，且每个里程碑可独立验证。
4. 必须保留证据链（commit、PR、日志、测试结果）。

SHOULD

1. 应优先做高风险项前置验证（PoC/烟囱测试）。
2. 应使用统一模板减少沟通成本。
3. 应在每日/每阶段结束时同步状态快照。
4. 应在复盘中输出可复用“反模式清单”。

MUST NOT

1. 禁止无 spec 直接大规模编码。
2. 禁止跨角色越权决策（执行者直接改需求口径）。
3. 禁止里程碑前一次性堆积提交。
4. 禁止发布后不做复盘闭环。

YAML 模板片段

customized_spec:
  meta:
    name: "任务名称"
    owner: "监管者(PO/架构师)"
    version: "v1.0"
  goal:
    business_objective: "业务目标"
    acceptance_criteria:
      - "验收条件1"
      - "验收条件2"
  roles:
    supervisor:
      responsibilities:
        - "范围与优先级裁决"
        - "关键设计审批"
    executors:
      responsibilities:
        - "并行实现"
        - "测试与证据提交"
  milestones:
    - id: "M1"
      output: "spec + 架构评审记录"
    - id: "M2"
      output: "核心功能可运行"
    - id: "M3"
      output: "集成验收 + 发布说明"
  guardrails:
    must:
      - "先spec后编码"
      - "里程碑可验证"
    must_not:
      - "无审查直接发布"

立即生效的执行约定（里程碑 Commit + 里程碑 Blog）

从今天开始，所有 AI 开发任务执行以下硬约定：

1. 每个里程碑至少一个可追踪 commit，commit message 统一包含里程碑编号（如 M2:）。
2. 每完成一个关键里程碑，产出一篇里程碑 blog（记录目标、产出、风险、下一步）。
3. 里程碑 blog 不是“总结文档”，而是监管与协同接口，必须具备可审计性。
4. 未满足“里程碑 commit + 里程碑 blog”双条件，不视为阶段完成。

这份 Customized Spec 不是一次性文档，而是持续演进的团队操作系统。