对齐认知，讨论 AI Coding 在项目交付中的协作模式
共同设计试点方案
AI 编程能力在过去一年发生了质变，不再只是"代码补全"，而是能理解完整上下文并生成可运行的业务代码。
关键认知：AI 不是要替代任何人，而是在重新定义每个角色的"价值区间"——就像 Excel 没有消灭会计，而是让会计从手工记账升级到了财务分析。我们需要一起探索：在我们的实际场景中，AI 能帮我们做什么，怎么做最稳妥？
在讨论具体方案之前，先对齐三个基本出发点。
AI 承担的是重复性、模式化的工作，让每个角色聚焦到更高价值的事情上。
| 角色 | AI 承担的部分 | 人聚焦的部分 |
|---|---|---|
| 研发 | 模板代码、CRUD、格式化工作 | 架构决策、系统可靠性、复杂逻辑、性能优化 |
| QA | 基础测试用例生成、回归执行 | 测试策略设计、探索性测试、质量体系建设 |
| 产品 | 文档格式化、一致性检查 | 需求洞察、验收标准定义、交付质量把关 |
我们会定义清晰的度量指标。任何阶段，如果数据表现不好，我们就调整方案，不强推。推进到下一阶段的前提是：效率有改善 + 质量不劣化。
不同项目的复杂度和风险差异巨大，AI 的参与深度应该因项目而异。高风险项目始终保持高度审慎，低风险项目可以大胆探索。
项目按「系统复杂度」x「业务风险」分为 L1（绿区）到 L4（红区）四个等级。不同等级采用不同的 AI 参与深度：L1 可端到端，L2/L3 逐步渐进，L4 极度审慎。
根据项目等级，选择不同的协作模式：模式 A（Spec 驱动）适用于 L2/L3/L4 项目，产品和研发围绕 Spec 文档协作，随知识库积累分两个阶段演进（探索期两步走 → 成熟期一步生成）；模式 B（AI 端到端闭环）适用于 L1 绿区项目，AI 直接端到端生成，研发快速 review 后上线。
AI 知识库不是一个单一文件，而是一套多层文档体系。它是 AI 理解项目上下文的基础，也是从阶段一演进到阶段二的关键积累。
原来的 AI-CONTEXT.md 只是知识库的一部分。完整的 AI 知识库由五个层次组成，覆盖从编码规范到产品架构的完整上下文。知识库越完善，AI 生成的 Spec 和代码质量越高，人工 review 的工作量越小。
| 层次 | 核心内容 | 生成/维护方式 | 负责人 | 建设优先级 |
|---|---|---|---|---|
| 编码规范 | 命名约定、目录结构、禁止做法、lint 规则、测试覆盖率要求 | 研发手动编写，定期更新 | 研发 TL | P0 — 必须先建 |
| 领域知识 | 业务概念、领域模型、实体关系、业务规则、术语表 | 基于历史 PRD 和 Spec-PRD 用 AI 提取，人工审核 | 产品 + 研发 | P1 — 随 Spec 积累 |
| 技术架构 | 系统架构、服务拆分、模块关系、技术栈、中间件 | 基于代码仓库和现有设计文档用 AI 生成，研发审核 | 研发架构师 | P1 — 尽早建立 |
| 技术设计 | 历史技术方案、接口设计、DB 设计、性能方案 | 每次项目的实施 Spec 自动归档 | 研发 | P2 — 自然积累 |
| 产品架构 | 功能架构图、用户旅程、模块关系、路线图 | 产品梳理文档，定期更新 | 产品 | P2 — 逐步完善 |
知识库不是一次性工程。编码规范层是启动门槛（P0），其余四层在日常协作中自然积累。关键是建立沉淀机制——每次项目交付后，产出的文档自动归入对应层次，而不是丢在各自的文件夹里遗忘。
阶段推进不是时间驱动的，而是数据驱动的。
两种 Spec 文档对应两个阶段，逐步从业务结构化走向技术可执行。
产品主导输出。在 PRD 基础上进行结构化改造，让文档逻辑完整、定义清晰、AI 可读性高。不深入技术实现细节。
背景、目标、核心用户场景、业务规则
产品主导状态流转、核心流程、异常分支、边界条件
产品主导每个功能点的 Given-When-Then 验收条件
产品 + QA业务层面的输入/输出描述、字段含义
不含具体字段类型、错误码等技术细节
交互稿/视觉稿的链接或截图
设计师提供标注"需技术方案补充"的区域，等待研发在实施 Spec 中填充
待研发补充研发主导，在 Spec-PRD 基础上补充技术设计。是 AI 编码的直接输入，包含完整的技术方案和接口定义。
继承自 Spec-PRD，不变
继承继承自 Spec-PRD，可能微调
继承完整的字段定义、类型、约束、错误码、请求/响应示例
研发补充影响的技术模块、大致实现方案、数据库设计
研发补充现有系统依赖、技术规范、性能/安全要求
研发补充继承自 Spec-PRD，不变
继承两份文档的关系：Spec-PRD 是实施 Spec 的「上游输入」。阶段一中它们是两份独立文档；阶段二中它们合并为一份完整 Spec，由 AI 基于知识库一步生成。
多层防护体系，确保 AI 参与不会降低交付质量和线上可靠性。
AI 基于知识库（编码规范 + 技术架构 + 领域知识）生成代码，从源头保证质量
CI/CD 流水线中的 lint、单元测试、集成测试自动执行，不通过不能合并
研发做 Code Review，重点关注系统兼容性、安全、性能。所有 AI 生成的代码必须经过人工 review
自动化测试 + QA 探索性测试 + 产品 UAT，多层验证
所有变更灰度发布，关键指标异常自动回滚
底线原则：AI 参与的项目，线上质量标准只能更高，不能更低。所有 AI 生成的代码通过与人工代码完全相同的 CI/CD 流程。试点期间加强监控，设置更敏感的告警阈值。一旦出现 AI 引入的线上问题，立即复盘并调整流程。
从近期项目中选一个 L1 级别、有明确交付时间、参与者愿意尝试的项目。
选定试点项目
编写 Spec-PRD 模板
建立 AI 知识库（编码规范层）
按新流程执行
过程中记录数据
收集各角色反馈
数据汇总分析
各角色反馈收集
总结经验改进点
根据数据决定
扩大 / 调整 / 暂停
| 指标 | 度量方法 | 对比基准 |
|---|---|---|
| 交付周期 | Spec 完成到上线的日历天数 | 同等复杂度历史项目 |
| 提测缺陷密度 | QA 发现的缺陷数 / 功能点数 | 历史均值 |
| AI 草稿可用率 | 被直接采纳的内容占比 | 首次度量，建立基线 |
| Code Review 修改率 | 需修改的代码行数占比 | 首次度量，建立基线 |
| 参与者满意度 | 各角色的主观评价 | 问卷调查 |
请大家围绕以下问题展开讨论。
分级矩阵是否合理？还有哪些维度应该纳入？
近期有哪些项目适合作为试点？
试点项目用模式 A 阶段一还是直接模式 B？
Spec 结构是否满足研发和 QA 的需要？
方案是否可行？初始版本编写工作量怎么评估？
各项指标的门槛是否合理？
防护机制是否足够？还有哪些风险需要覆盖？
还有哪些问题或担忧需要在方案中解决？