包含完整战略意图与真实判断，面向产品团队内部对齐认知、指导行动
这不是"要不要做"的问题，而是做慢了就是竞争劣势的问题。
头部 AI 工具已能在给定充分上下文的情况下，生成可直接运行的业务代码，理解数万行级别的代码库上下文。
Google、Microsoft、字节、阿里已在内部大规模推进 AI Coding，部分团队报告交付效率提升 30-50%。
6-12 个月内建立成熟的流程和工具体系，否则将在交付效率上形成结构性落后。
内部现状的真实判断：当前研发对 AI 的使用停留在"个人工具"层面，没有进入流程层面。研发侧的抵触底层是对"被替代"的焦虑，但表现为对"代码质量"和"线上可靠性"的担忧。如果不主动推进流程变革，AI 的使用会停留在"更快地写同样的代码"，而无法实现"用更少的人做更多的事"。
产品侧战略意图：终态目标是方案三（AI 端到端）覆盖大部分 L1-L2 级项目。人效目标是同等交付规模下研发资源投入降低 40-60%。产品侧的 Spec 编写能力是新的核心竞争力——能写出高质量结构化 Spec 的产品经理，在 AI 时代价值倍增。
三条核心原则，是整个方案的认知地基。
Excel 没有消灭会计，但消灭了"只会手算的会计"。AI 不会消灭研发，但会使"只会写 CRUD 的研发"失去不可替代性。
| 角色 | 当前价值中心 | 未来价值中心 |
|---|---|---|
| 产品经理 | 写 PRD，跟进度 | 精准定义问题，编写结构化 Spec，驱动交付链 |
| 研发 | 写代码，联调 | 架构决策，系统可靠性守护，AI 产出质量把关 |
| QA | 写用例，执行测试 | 测试策略设计，质量体系建设，探索性测试 |
每个阶段的推进必须有上一阶段的硬数据支撑。指标不劣化 + 效率有改善，才能推进。任何阶段数据恶化可以回退。
不同风险等级的项目适用不同的 AI 参与深度。这既是科学的，也给了研发"选择权"的感觉——他们会觉得自己在参与决策而非被推着走。
项目按「系统复杂度」x「业务风险」分为 L1（绿区）到 L4（红区）四个等级，不同等级采用不同的 AI 参与深度和协作流程。L1 低风险项目可直接 AI 端到端，L4 高风险项目 AI 仅辅助方案和用例。分级不是固定的，而是随数据积累动态演进——"信任逐级传递"。
我们定义了两种协作模式：模式 A（Spec 驱动渐进）适用于 L2/L3/L4 项目，产品和研发围绕 Spec 文档协作，随知识库积累分阶段演进；模式 B（AI 端到端闭环）适用于 L1 低风险项目，AI 直接端到端生成，研发快速 review 后上线。
Spec 是所有角色和 AI 的"共同语言"——不是传统 PRD 的升级版，而是一份同时服务于人和 AI 的结构化契约。
每个代码仓库一份，由研发团队维护和拥有——强化"研发是系统守护者"的定位。
# AI-CONTEXT.md ## 技术栈 - 前端框架：XXX - 组件库：公司内部 YYY 组件库，文档地址：... - 后端框架：ZZZ ## 编码规范 - 命名约定：... - 目录结构约定：... - 禁止事项：不要自己实现 XX，必须使用 YY 组件库 ## 常见陷阱 - 修改 A 模块时必须同步检查 B 模块的 XX 逻辑 - C 表的 D 字段有历史兼容逻辑，不能直接修改 ## 测试要求 - 单元测试覆盖率要求：... - 必须通过的 CI 检查项：...
讨论会策略、节奏控制与风险预案。
讨论会核心策略：不要以"产品提需求"的姿态推进，而是以"一起探索行业方向"的姿态。让研发参与规则制定——他们参与制定的规则，他们更愿意遵守。承诺"数据不达标就调整方案，不强推"。
当方案三在 L1-L3 级项目全面铺开后，每个角色的终态形态。
一个优秀的产品经理 + AI 可以完成过去需要产品 + 3-5 个研发的工作量。Spec 编写能力成为核心竞争力。
团队规模收缩，但留下的人都是架构师级别，薪资和价值更高。聚焦系统治理和技术决策。
从"测试执行"彻底转型为"质量工程"，人数减少但能力要求提升，聚焦体系建设。
L1-L2 项目的交付周期从周级别缩短到天级别，L3 项目大幅缩短。