方法论体系

AI Coding 驱动的
项目交付体系

面向项目中的所有参与者：产品经理、研发、QA、设计师、技术主R。
从项目分级、协作模式、交付流程到质量保障的完整方法论。

项目分级 协作模式 交付流程 质量保障
SCROLL
Part 一

项目分级 — "不是所有项目都一样"

不同项目的复杂度和风险差异巨大，AI 的参与深度应该因项目而异。我们按「系统复杂度」×「业务风险」两个维度对项目进行分级。

1.1 分级矩阵（2×2）

L1 - 绿区
低系统复杂度 × 低业务风险
新独立页面、运营配置后台、内部工具、活动页面
L2 - 黄区
低系统复杂度 × 高业务风险
涉及资金但逻辑简单的功能、C 端新独立功能
L3 - 黄区
高系统复杂度 × 低业务风险
已有系统迭代、跨服务联动、涉及核心链路改动
L4 - 红区
高系统复杂度 × 高业务风险
支付/交易核心链路、高并发场景、多团队核心系统

1.2 各级别判断标准

通过 requirement-router 技能进行 6 维度评分来确定项目等级：

评分维度说明
功能独立性是否可独立部署、不影响其他系统
业务风险是否涉及资金、用户核心体验
用户影响影响用户的范围和严重程度
状态复杂度状态流转是否复杂、是否有跨服务状态同步
接口复杂度涉及的接口数量和交互模式
团队规模参与的团队和人员数量

1.3 各等级的 AI 参与策略

等级AI 参与策略协作模式
L1 绿区AI 深度参与，可端到端生成代码，人做 review 和验收模式 B（AI 端到端）
L2 黄区AI 辅助生成草稿，人 review 和补全，逐步扩大 AI 范围模式 A（Spec 驱动）
L3 黄区AI 辅助生成草稿，人 review 和补全，涉及复杂系统需特别审慎模式 A（Spec 驱动）
L4 红区AI 仅辅助技术方案和测试用例，核心代码人工编写模式 A（Spec 驱动，极度审慎）

1.4 分级是动态演进的

分级不是固定的。当低等级项目跑通高度 AI 参与模式并积累足够数据后，高等级项目可以逐步提升 AI 参与深度：

L1 跑通模式 B → L2 从模式 A 阶段二起步 L2 跑通模式 A 阶段二 → L2 可直接模式 B，L3 从模式 A 阶段二起步 L3 跑通模式 A 阶段二 → L3 可直接模式 B L4 → 始终保持模式 A，根据数据逐步提升阶段
Part 二

协作模式 — "不同级别怎么协作"

根据项目等级，选择不同的协作模式。两种模式各有侧重，核心区别在于 AI 的参与深度和研发的角色定位。

2.1 模式 A：Spec 驱动（适用于 L2/L3/L4）

产品和研发围绕 Spec 文档协作，随着 AI 知识库的积累，分两个阶段逐步演进。

阶段一：探索期 — PRD → Spec-PRD → Spec（三步走）

初期知识库尚不完善，产品聚焦业务逻辑结构化，研发补充技术设计，分步降低门槛。

Step 1：PRD → Spec-PRD（产品主导）

原始 PRD → AI 辅助结构化 → Spec-PRD 草稿 → 质量自检 → Spec-PRD 定稿

Spec-PRD：业务逻辑结构化（功能定义、状态流转、验收标准、异常分支），不含技术实现细节，标注"需技术方案补充"。

模块内容负责人
业务上下文背景、目标、核心用户场景、业务规则产品主导
功能定义状态流转、核心流程、异常分支、边界条件产品主导
验收标准每个功能点的 Given-When-Then 验收条件产品 + QA
接口语义业务层面的输入/输出描述、字段含义（不含技术细节）产品主导
设计资产交互稿/视觉稿的链接或截图设计师提供
技术方案占位标注"需技术方案补充"的区域待研发补充

Step 2：Spec-PRD → 实施 Spec（研发主导）

Spec-PRD → 研发补充技术设计 → 实施 Spec 草稿 → 联合评审 → 实施 Spec 定稿

实施 Spec：在 Spec-PRD 上补充完整接口契约、技术方案、数据库设计、约束与依赖。形成可直接指导 AI 编码的完整文档。

阶段二：成熟期 — PRD → Spec（一步到位）

AI 知识库已沉淀技术架构、领域知识、历史设计方案，产品可直接从 PRD 生成包含技术设计的完整 Spec。

原始 PRD → AI 生成完整 Spec → 质量评审 → 研发确认技术方案 → Spec 定稿

研发角色转变：从"技术设计的编写者"变为"技术方案的评审者"。

两阶段对比

维度阶段一（探索期）阶段二（成熟期）
Spec 流程PRD → Spec-PRD → 实施 Spec（两步）PRD → 完整 Spec（一步）
技术设计研发手动补充AI 基于知识库生成，研发确认
产品门槛低 — 只需结构化业务逻辑中 — 需理解 AI 生成的技术方案
知识库依赖低 — 可从零开始高 — 需充分积累

阶段推进标准

从阶段一到阶段二的推进是数据驱动的，需要满足以下门槛：

维度标准
知识库建设编码规范层 + 技术架构层建设完成；领域知识层覆盖主要业务模块
流程验证累计完成 ≥ 5 个项目的 Spec-PRD → 实施 Spec 全流程
质量指标实施 Spec 质量评审稳定达到 B 级以上
效率指标交付周期相比传统 PRD 模式缩短 ≥ 20%
质量底线提测缺陷密度不高于历史均值

2.2 模式 B：AI 端到端闭环（适用于 L1 绿区）

产品输出 Spec → AI 端到端生成（代码 + 测试 + 部署方案）→ 研发快速 Review → 自动化测试 → 灰度 → QA 线上验证

直接从 AI 端到端开始，限定在低风险低复杂度项目，失败成本可控。产品输出 Spec，AI 生成代码 + 测试 + 部署方案，研发快速 review 后上线。

研发 Review 重点：是否遵循项目规范、是否有安全问题、是否影响其他模块。

2.3 两种模式总览

维度模式 A（Spec 驱动）模式 B（AI 端到端）
适用等级L2/L3/L4L1
核心特点人与 AI 协作，分步推进AI 主导，人做验收
研发角色技术设计者/评审者 + 代码审查者快速审查者
QA 角色测试策略设计 + 探索性测试线上验证 + 探索性测试
产品角色Spec 编写 + 交付驱动Spec 编写 + UAT 验收
Part 三

交付流程 — "具体怎么一步步做"

一个完整项目的流程分为 8 个阶段（Stage 0 — Stage 7），每个阶段有明确的参与者、产出物和质量门禁。

阶段 0 阶段 1 阶段 2 阶段 3 阶段 4 阶段 4.5 阶段 5 阶段 6 阶段 7 需求路由 → 需求定义 → Spec评审 → 技术设计 → 开发实现 → 一致性审查 → 测试验证 → 上线发布 → 复盘改进

各阶段速览

阶段核心活动主导者核心产出质量门禁
0. 需求路由评估流程产品/技术主R路由决策（L1-L4）+ 推荐流程评分完成
1. 需求定义写 Spec产品结构化 Spec + 设计资产B级以上
2. Spec 评审评审+补充产品+研发评审通过的 Spec + 全局契约各角色签字确认
3. 技术设计生成方案研发技术方案 + AI-CONTEXT.md研发团队确认
4. 开发实现AI+人编码研发可运行代码 + 测试Code Review 通过
4.5 一致性审查比对实现与Spec研发+产品一致性报告 + 修正一致率 100%
5. 测试验证QA测试QA测试报告 + UAT确认达到交付标准
6. 上线发布灰度上线研发上线成功灰度指标正常
7. 复盘改进数据复盘全角色改进报告 + 技能迭代改进动作已落地

各阶段详情

0

需求路由

产品/技术主R — 评估需求复杂度和系统影响
谁做什么
角色具体工作产出
产品经理使用 requirement-router 技能评估需求；提供需求描述和背景路由决策报告
技术主R/研发提供涉及的代码仓库和系统信息；确认代码影响分析是否准确代码影响确认
requirement-router 做什么
  • 6 维度评分（功能独立性/业务风险/用户影响/状态复杂度/接口复杂度/团队规模）
  • 代码影响分析（涉及模块、历史 Bug 密度、AI-CONTEXT.md 陷阱交叉检查）
  • 输出：项目等级（L1-L4）+ 推荐流程 + 是否需要拆解 + 推荐的技能链
路由结果决定后续流程
路由结果后续流程
L1 绿区直接进入阶段 1，走模式 B（AI 端到端）简化流程
L2 黄区进入阶段 1，走模式 A（Spec 驱动）标准流程
L3/L4先用 project-decomposer 拆解，再各模块进入阶段 1
涉及大量存量代码阶段 1 之前先用 legacy-code-analyzer 理解现有系统
存量代码处理（如路由结果指出涉及存量代码）

使用 legacy-code-analyzer 技能：

  1. 输入涉及的代码模块 + AI-CONTEXT.md
  2. AI 生成理解报告（结构、业务规则、风险区域、影响范围）
  3. 研发确认报告的准确性（关键！AI 的理解可能有错）
  4. 确认后的报告作为阶段 1 写 Spec 的上下文输入
质量门禁
  • 路由评分已完成，项目等级已确定
  • 如涉及存量代码，理解报告已由研发确认
  • 后续流程和技能链已明确

时间参考：简单需求 15 分钟，涉及存量代码 1-2 小时

详细的需求路由评估维度见 requirement-router 技能 · 存量代码治理策略见 legacy-code-strategy.md · 完整流程图见 flowchart.html
1

需求定义

产品主导 — 产出 B 级以上的结构化 Spec + 设计资产
谁做什么
角色具体工作产出
产品经理用 spec-writer 技能将 PRD 转为结构化 Spec；用 spec-reviewer 技能自检质量；标注"需研发补充"和"需确认"的部分Spec 草稿（含标注）
设计师完成交互和视觉设计；按设计交付指南提供结构化设计资产；提供组件映射表和交互说明；参与 Spec 评审，提供设计资产设计资产包
产品负责人（大项目）用 project-decomposer 拆解模块；定义全局契约草案；确定各模块的产品经理Level 0 Spec + 全局契约草案

时间参考：简单项目 1-2 天，中等项目 3-5 天，复杂项目 1-2 周

质量门禁
  • Spec 通过 spec-reviewer 自检，达到 B 级以上
  • 设计资产包含组件映射表和结构化交互说明
  • 所有"需确认"项已标注
注意事项：不要闷头写完才给人看——写完业务上下文和核心场景后就可以先口头和研发对一下。不要猜技术约束——标注"需研发补充"。接口契约只定义业务语义（字段含义、约束），不定义技术实现。
2

Spec 评审

产品+研发共同主导 — 全角色对齐理解，补全技术部分
谁做什么
角色具体工作产出
产品经理主持评审会，逐模块讲解；记录研发和QA的反馈；会后更新 Spec更新后的 Spec
研发评审功能定义的可行性；补充"约束与依赖"模块；评审接口契约，补充技术约束；指出遗漏的异常场景和系统影响约束与依赖内容 + 接口技术约束
QA评审验收标准是否可测试；补充遗漏的测试场景；评估测试复杂度和风险补充的验收标准 + 测试风险评估
设计师确认设计资产与 Spec 功能定义一致；补充设计细节说明；使用 design-spec-converter 转换设计规范设计规范确认 + 结构化设计标注
技术主R（大项目）评审模块拆解合理性；组织跨模块接口对齐；确认全局契约全局契约定稿
评审会议程（建议 60-90 分钟）
0-5min 产品简介 Spec 结构（第一次协作时需要） 5-20min 业务上下文 + 功能定义过一遍（研发提问和补充） 20-40min 验收标准逐条过（QA重点参与） 40-55min 接口契约讨论（研发主导） 55-65min 约束与依赖（研发填写） 65-75min 汇总开放问题和待确认项 75-80min 确认下一步计划和排期
大项目额外增加跨模块 Review
各模块 Spec 评审通过后 → 跨模块 Review 会 - 使用 cross-module-reviewer 技能 - 检查接口对齐、术语一致、数据模型一致 - 参与者：各模块产品经理 + 技术主R - 产出：跨模块一致性审查报告
质量门禁
  • 研发已补充"约束与依赖"
  • QA 已确认验收标准可测试
  • 设计师已确认设计资产与功能定义一致
  • 所有"需确认"项已解决或转为"开放问题"
  • 大项目：跨模块 Review 零 Blocking
注意：这一步不是走过场——研发的补充可能会改变你的功能设计。评审中发现的重大问题，宁可推迟开发也要改清楚。评审后的 Spec 才是"基线版本"，后续变更走变更管理。
3

技术设计

研发主导 — 基于评审通过的 Spec，确定技术实现方案
谁做什么
角色具体工作产出
研发用 tech-plan-generator 生成技术方案草稿；Review 和修改 AI 生成的草稿；确认/创建 AI-CONTEXT.md；确定实现步骤和排期技术方案 + AI-CONTEXT.md + 排期
产品经理答疑业务问题；确认排期是否满足业务要求排期确认
QA用 testcase-generator 生成测试用例草稿；审查和补充 AI 生成的测试用例；评估自动化测试可行性测试用例集

AI-CONTEXT.md 的创建/更新（研发核心任务）

如果仓库没有 AI-CONTEXT.md，研发在这个阶段创建。参照 ai-context-guide.md。

这直接决定后续 AI 生成代码的质量——写得越完善，后面 Review 的工作量越小。

质量门禁
  • 技术方案中的待决策项全部已决策
  • AI-CONTEXT.md 已创建或更新
  • 测试用例覆盖所有验收标准（追溯矩阵完整）
  • 排期已确认
4

开发实现

研发主导 — 产出可运行的、符合 Spec 和 AI-CONTEXT.md 的代码
谁做什么
角色具体工作产出
研发AI 生成代码（按技术方案和 Spec）；Review AI 产出（用 ai-code-reviewer 技能）；补全 AI 做不好的部分；编写/补充自动化测试；确保 CI 通过可运行代码 + 自动化测试
产品经理响应研发的业务问题；跟踪进度，识别风险；如有 Spec 变更需求，走变更流程进度跟踪 + 变更管理
QA准备测试环境；完善探索性测试计划；等待提测测试环境 + 探索测试计划
设计师首轮视觉走查（核心页面完成后）；对照设计稿检查 UI 还原度；记录视觉偏差问题并反馈给研发首轮视觉走查报告
代码合入标准（Code Review 通过条件）
□ ai-code-reviewer 检查零 Blocking □ AI-CONTEXT.md 合规检查通过 □ 单元测试覆盖核心路径 □ CI 全部通过（lint + test + build） □ 人工 Review 无重大问题
赛马机制（L3/L4 高风险模块可选）
Spec 同时给两个方案（不同模型 / 不同思路） → 各自生成代码 → 用 ai-code-reviewer 分别 Review → 综合比较择优 → 必要时取各方案优点整合
循环达标（每个模块）
AI 生成代码 → Code Review → 不达标 → 明确修改点 → AI 修改 → 再 Review 最多 3-5 轮。超过则研发人工接管该部分。
质量门禁
  • 所有 Code Review Blocking 已修复
  • CI 全部绿色
  • 核心路径自动化测试通过
  • 研发自测核心场景通过
4.5

实现-Spec 一致性审查

研发+产品 — 确保实际代码与 Spec 完全一致
为什么需要这一步：开发过程中，实现很容易"偏离"Spec——研发做了 Spec 没写的功能、Spec 要求的某个边界没实现、接口字段名不一致。这些偏差如果不在提测前捕获，就会变成 Bug 或长期技术债。
谁做什么
角色具体工作产出
研发使用 implementation-spec-diff 技能比对代码与 Spec；标注差异项一致性报告
产品经理审查差异项；决定每个差异的处理方式确认决策
implementation-spec-diff 做什么
  • 逐条比对 Spec 验收标准（AC）与代码实现
  • 比对接口契约（字段名、类型、错误码）
  • 比对状态机（转换路径是否一致）
  • 发现"多做的"（代码有但 Spec 没定义）和"少做的"（Spec 有但没实现）
产品确认差异项

对每个差异，产品选择：

  • 改代码：Spec 是对的，实现偏了 → 研发修复
  • 更新 Spec：实现合理，Spec 需要更新 → 产品更新 Spec
  • 两边都调整：双方都有问题
质量门禁
  • 所有 AC 的实现状态已确认
  • 一致率达到 100%（所有差异项已处理）
  • 如有 Spec 更新，已记录变更

时间参考：L1 项目 15-30 分钟，L2 项目 1-2 小时，L3/L4 项目 2-4 小时

触发时机
  • 提测前（必须）
  • UAT 前（L2+ 建议）
  • 上线前（L3/L4 必须）
详细技能说明见 implementation-spec-diff 技能
5

测试验证

QA 主导 — 验证交付质量达到标准
谁做什么
角色具体工作产出
QA执行测试用例（自动化 + 手工）；执行探索性测试（重点关注 AI 代码特有风险）；提交 Bug 并标记根因分类；回归验证测试报告 + Bug 列表（含根因标记）
研发修复 Bug；分析 Bug 根因（Spec问题/AI-CONTEXT.md缺失/AI能力限制/人的错误）；补充遗漏的自动化测试修复代码 + 根因分析
产品经理UAT 验收；对照验收标准逐条确认；确认用户体验达预期UAT 签字
设计师终轮视觉走查 — 全页面/全场景检查；对照设计稿逐页确认 UI 还原度、间距、颜色、字体；视觉验收签字视觉验收报告 + 视觉验收签字
Bug 根因标记（重要，为后续改进提供数据）
标记含义后续动作
S-specSpec 没写清楚导致改进 Spec 写法
C-contextAI-CONTEXT.md 缺少约定导致研发更新 AI-CONTEXT.md
A-aiAI 能力限制导致记录到 AI 能力边界
H-human人的失误（与 AI 流程无关）常规修复
探索性测试重点方向（AI 代码特有）

参照 探索性测试指南，重点关注：

  • 跨模块状态一致性
  • 边界值行为
  • 异常恢复路径
  • 用户体验连贯性
质量门禁
  • 所有 P0/P1 Bug 已修复并回归通过
  • 自动化测试通过率 100%
  • 产品 UAT 签字通过
  • 设计师视觉验收签字通过
  • 探索性测试无重大发现
6

上线发布

研发主导 — 安全上线，灰度验证
谁做什么
角色具体工作产出
研发制定上线方案（灰度策略）；执行上线；监控关键指标；异常时回滚上线完成
QA线上回归测试；验证灰度环境功能正常线上验证报告
产品经理线上验收核心功能；监控业务指标；收集用户反馈业务指标确认
灰度策略
项目等级灰度方式
L1 绿区全量发布或简单灰度（10% → 100%）
L2 黄区分步灰度（1% → 10% → 50% → 100%）
L3/L4严格灰度（1% → 5% → 10% → 50% → 100%），每步观察 ≥ 24h
质量门禁
  • 灰度期间核心指标无异常
  • 无 P0/P1 线上问题
  • 产品确认业务指标正常
7

复盘改进

全角色 — 从本次项目中提取改进点，让下次更好
谁做什么
角色具体工作产出
产品经理汇总本次 Spec 的问题；用 spec-iteration-tracker 归因分析；更新 Spec 写法指南Spec 改进记录
研发汇总 Code Review 中的高频问题；更新 AI-CONTEXT.md；评估 AI 草稿可用率AI-CONTEXT.md 更新 + 数据
QA汇总 Bug 根因分布；更新测试策略；更新质量度量看板质量报告 + 度量更新
设计师汇总视觉走查中的高频还原问题；总结设计资产交付的改进点；反馈 AI 生成代码对设计还原的常见偏差体验质量回顾报告
全角色用 skill-evaluator 评估本次使用的技能；讨论流程中的卡点；确定下次改进的优先级改进计划
复盘会议程（建议 60 分钟）
0-10min 数据回顾：交付周期、缺陷密度、AI可用率 10-25min Bug 根因分析：S类/C类/A类/H类的分布 25-40min 各角色反馈：哪里顺畅、哪里卡顿 40-55min 确定 TOP 3 改进项和负责人 55-60min 确认下次项目使用什么改进后的流程和技能
质量门禁
  • 改进动作有明确的负责人和截止时间
  • AI-CONTEXT.md 已更新
  • 质量度量看板已更新

不同项目规模的协同差异

小项目（1PM + 1-2研发 + 1QA）

特点：沟通成本低，不需要正式评审会

  • 阶段 2 评审可以简化为 30 分钟的 1:1 对齐
  • 不需要全局契约
  • 不需要跨模块 Review
  • 复盘可以简化为 15 分钟快速回顾

中项目（1-2PM + 3-8研发 + 1-2QA）

特点：需要正式评审，但团队单一

  • 标准流程走一遍
  • 可能需要 1 层拆解（Level 0 → Level 1）
  • 评审会按标准议程执行
  • 需要指定一个技术主R

大项目（多PM + 多团队 + 多QA）

特点：多团队并行，一致性是最大风险

  • 必须 2 层拆解（Level 0 → Level 1 → Level 2）
  • 必须定义全局契约
  • 必须有跨模块 Review
  • 必须有技术主R承担全局一致性
  • 各模块并行走标准流程，但增加同步节点

同步节点

  1. 全局契约评审（项目启动后第 1 周）
  2. 各模块 Spec 完成后的跨模块 Review
  3. 各模块开发完成后的契约测试
  4. 集成测试前的联调对齐
  5. 全量上线前的综合评估

Spec 变更管理

项目执行过程中，Spec 不可避免会有变更。关键是管理变更，而不是阻止变更。

变更流程

发现需要变更 → 评估影响范围 ↓ 影响小（仅当前模块内）： → 产品更新 Spec → 通知研发和QA → 研发评估实现影响 → 确认变更 影响大（跨模块 / 涉及接口变更）： → 产品提变更请求 → 技术主R评估影响 → 受影响模块确认 → 更新全局契约（如需）→ 各模块同步更新 Spec → 确认变更

变更记录格式

日期变更内容影响范围发起人确认人
[日期][改了什么][影响哪些模块/接口][谁提的][谁确认的]

协同工具一览

各阶段使用的技能

阶段产品使用研发使用QA 使用设计使用
0 需求路由requirement-routerrequirement-router（确认代码影响）--
0 存量代码-legacy-code-analyzer--
1 需求定义spec-writer, project-decomposer---
2 Spec评审spec-reviewer--design-spec-converter
2 跨模块Reviewcross-module-reviewercross-module-reviewer--
3 技术设计-tech-plan-generatortestcase-generator-
4 开发实现-ai-code-reviewer--
4.5 一致性审查implementation-spec-diff（确认）implementation-spec-diff（执行）--
7 复盘改进spec-iteration-trackerspec-iteration-trackerspec-iteration-tracker-
持续skill-evaluatorskill-evaluatorskill-evaluator-

各阶段使用的工具包文档

阶段参考文档
0 需求路由完整流程图, 存量代码策略
1 需求定义Spec模板, 快速上手指南, 设计交付指南
2 Spec评审Spec评审清单, 大项目策略
3 技术设计AI-CONTEXT指南, 测试用例审查指南
4 开发实现代码审查清单, 反馈闭环指南
5 测试验证探索性测试指南, 质量度量看板
7 复盘改进技能创建指南, 最佳实践
Part 四

质量保障 — "怎么确保做得好"

AI 参与的项目，线上质量标准只能更高，不能更低。从方法论、Spec 质量评级、多层防护到风险应对，构建完整的质量保障体系。

4.1 三大方法论

当项目超出"一个 Spec 就能搞定"的范围时（L3/L4），需要更高级的策略来保障质量。

层层拆解（Hierarchical Decomposition）

复杂项目通过多层 Spec 循环逐步分解：

层级目标产出参与者
Level 0 项目级拆成哪些模块和阶段模块清单 + 依赖关系 + 全局契约产品负责人 + 各模块PM + 技术主R
Level 1 模块级每个模块的完整 Spec业务定义 + 验收标准 + 接口契约模块PM + 对应研发
Level 2 任务级可执行的实施方案技术方案 + 代码结构 + 测试用例研发 + QA
铁律：每个拆解单元必须可独立交付、可独立验证、有明确的输入输出边界。

拆解层数取决于项目规模：简单项目（≤5人2周）0层直接写 Spec；中等项目 1 层；复杂项目 2 层；超大型项目 2-3 层 + 阶段制。

赛马机制（Horse Racing）

对关键模块或高不确定性的实现，用多个方案并行探索，择优整合：

  • 不同 AI 模型各生成一版 → 综合 Review 择优
  • 同一模型多次生成不同方案 → 取各方案的精华
  • 适用于：核心算法、UI 方案、技术选型等"没有标准答案"的场景
  • 成本控制：只对高风险模块赛马，不是所有模块

循环达标（Loop Until Quality Bar）

先定义清晰的交付标准，然后循环（生成 → 评估 → 改进 → 再评估），直到达标：

  • 每次循环必须有明确的"这次改什么"——不允许盲目重跑
  • 设置最大循环次数（通常 3-5 次）——超过则升级人工介入
  • 每次循环后比对差距是否缩小——不缩小说明方向错了

4.2 Spec 质量评级

Spec 质量是整个交付链条的源头。使用 spec-reviewer 技能对 Spec 进行质量评级：

等级标准可否进入开发
A 级所有模块完整、验收标准清晰、接口契约完备、无歧义直接进入开发
B 级核心模块完整、验收标准基本清晰、有少量待确认项可进入开发，待确认项并行解决
C 级部分模块缺失或不清晰、验收标准不够具体需补充后重新评审
D 级结构不完整、缺少关键定义、无法指导开发需重写
质量门禁要求：Spec 必须达到 B 级以上方可进入开发阶段。

详细评审维度参见 spec-review-checklist.md（5 维度 30+ 检查项）和 spec-quality-rubric.md（好/坏写法对比示例）。

4.3 多层防护体系

1

AI 知识库（事前规范）

AI 基于知识库（编码规范 + 技术架构 + 领域知识）生成代码，从源头保证质量

2

自动化检查（事中拦截）

CI/CD 流水线中的 lint、单元测试、集成测试自动执行。不通过就不能合并，无论是 AI 写的还是人写的

3

人工 Review（事中把关）

研发做 Code Review，重点关注系统兼容性、安全、性能。所有 AI 生成的代码必须经过人工 review 才能合入

4

测试验证（事后兜底）

自动化测试 + QA 探索性测试 + 产品 UAT

5

灰度发布 + 监控（上线保障）

所有变更灰度发布，关键指标异常自动回滚

4.4 视觉走查流程（设计师专属质量保障）

设计师在交付流程中承担视觉质量守护的角色，通过两轮走查确保 UI 还原度：

走查轮次时机重点
首轮走查（阶段 4）核心页面开发完成后整体布局、核心交互、组件使用是否正确
终轮走查（阶段 5）提测完成、上线前全页面逐像素检查、间距/颜色/字体/动效细节
终轮走查通过后，设计师出具视觉验收签字，签字后方可进入上线发布阶段。

详细的视觉走查流程和检查清单见 visual-review-guide.md

4.5 AI 特有的风险和应对

风险应对机制
AI 不了解系统历史逻辑，改 A 影响 BAI 知识库记录模块关联逻辑 + AI 生成影响范围分析供 review
AI 重复造轮子，不用已有组件库AI 知识库明确组件库和禁止事项 + Code Review 专项检查
AI 生成的代码不符合编码规范AI 知识库编码规范层定义规范 + CI lint 自动拦截
AI 生成的代码有安全漏洞安全扫描工具集成到 CI + 人工 review 安全检查项
AI 对复杂业务逻辑理解偏差Spec 中用 Given-When-Then 明确验收标准 + 完善的测试覆盖

底线原则

AI 参与的项目，线上质量标准只能更高，不能更低。

一张图总结

产品经理 研发 QA 设计师 技术主R ──────── ──── ── ────── ────── 阶段0 requirement-router 确认代码影响 协助评估 评估需求复杂度 legacy-code-analyzer 确定L1/L2/L3/L4 (存量代码时) ▼ 阶段1 写 Spec (等待) (等待) 提供设计资产 (大项目)拆解 ┃ spec-writer 组件映射表 project-decomposer ┃ spec-reviewer 交互说明 全局契约 ▼ 阶段2 主持评审 ←────────→ 补充约束依赖 ←──→ 审查验收标准 确认设计一致性 跨模块 Review 记录反馈 评审接口契约 补充测试场景 design-spec- 接口对齐仲裁 更新 Spec 指出系统影响 测试风险评估 converter ▼ 阶段3 答疑 + 排期确认 技术方案设计 生成测试用例 AI-CONTEXT.md 审查+补充用例 tech-plan-generator testcase-generator ▼ 阶段4 进度跟踪 AI生成代码 首轮视觉走查 业务答疑 Code Review 准备测试环境 UI还原度检查 变更管理 ai-code-reviewer 探索测试计划 ▼ 阶段4.5 确认差异处理方式 implementation-spec-diff 更新Spec(如需) 比对实现与Spec ▼ 阶段5 UAT 验收 修 Bug 执行测试 终轮视觉走查 验收标准逐条确认 根因分析 探索性测试 视觉验收签字 Bug 根因标记 ▼ 阶段6 线上业务验收 执行上线 线上回归测试 业务指标监控 灰度 + 监控 ▼ 阶段7 Spec 改进 AI-CONTEXT.md更新 质量度量更新 体验质量回顾 spec-iteration- 反馈闭环 Bug分布分析 设计还原问题总结 tracker skill-evaluator skill-evaluator