本文不是工具推荐，不是概念科普。这是一个十人技术团队在推进 AI 编程过程中，基于行业深度调研、大厂踩坑复盘和自身实践总结出的完整落地方案。核心命题只有一个：如何让 AI 省下来的时间，真正变成团队多交付的需求。
一、为什么要写这份文档
我们团队 10 个人，已经在用 AI 编程工具了。补全在用，Agent 模式也在用，体感效率确实有提升。
但有一个问题越来越清晰：个人觉得快了，团队出活没快。
需求还是那个交付节奏，迭代还是那个迭代周期。AI 省下来的时间去了哪？被会议吃了，被等 CR 吃了，被联调等待吃了。没人刻意把这些省下来的碎片时间攒成一整块，去多接一个需求、多做一轮测试。
这不是我们一家的问题。快手 10000 人的团队，花了一整年才搞明白这件事。
所以这份文档要解决的问题是：怎么设计一套机制，让 AI 在个人手里省下来的时间，能传导成团队层面的交付能力提升。
二、行业调研：大厂都踩过什么坑
在动手之前，我们花了大量时间研究行业头部团队的实践。不是为了抄他们的方案——万人团队的做法搬到十人团队是灾难——而是为了搞清楚哪些坑是必踩的，哪些弯路可以绕过去。
2.1 快手：10000 人团队的核心教训
快手是目前公开披露最完整的「从个人到组织」转型案例。他们花了三年，走了三个阶段：
阶段一（2023-2024）：先搞流程标准化 还没推 AI，先花了整整一年把研发流程拉齐——工具渗透率做到 95%+，流程自动化做到 94%+。这一步完成后，人均需求吞吐量提升了 41.57%。
阶段二（2024.6-2025.6）：推了 AI，效果不传导 全面推广 AI 编码、测试、CR 等工具。AI 代码生成率从 1% 做到了 30%+，开发人员主观感觉编码效率提升 20-40%。
但组织层面的需求交付效率——纹丝不动。
这是他们最痛的一课。原因被他们精准总结为两条：
碎片化时间陷阱：AI 省下来的是 5-10 分钟的编码碎片，这些时间被会议、等 CR、等联调填满了，没有转化成完整的交付能力。
木桶效应：编码只占交付周期的 20-30%。编码再快，需求评审、联调、测试、发布这些短板不变，整体交付周期不会缩短。
这意味着：如果我们只推工具不改流程，大概率重走快手第二阶段的弯路。
阶段三（2025.7 起）：范式升级——L1/L2/L3 三级跳 快手最终找到了突破口：不是让每个人用好 AI，而是用 AI 重新定义人和流程的关系。
| 级别 | 定义 | 人的角色 | 交付周期影响 |
|---|---|---|---|
| L1 AI 辅助 | IDE 内代码补全 | 人写，AI 补 | 编码提速 10-20%，交付周期几乎不变 |
| L2 AI 协同 | 需求→设计→编码→测试全链路 AI 参与 | 人审核，AI 执行 | 开发周期 -30% |
| L3 AI 自主 | 工程师变 PM，自然语言下需求 | 人定义，AI 交付 | 开发周期 -40% |
关键转折点数据：当 L2+L3 级需求占比达到 20.34% 时，需求交付周期下降 58%，人均交付需求数提升 38%。
快手的结论原话：「AI 是透视镜和放大器——在流程清晰的组织能释放巨大效能，在流程混乱的组织会暴露所有问题。」
2.2 腾讯广告审核团队：单团队深度落地的标杆
腾讯广告审核团队是最接近我们体量的参考对象。他们的做法可以概括为五个字：规范、结构、方案、指令、总结。
核心范式是一句话：告诉 AI「按什么规范、在哪里、做什么、怎么做」，让 AI 告诉我们「做了啥」。
| 步骤 | 要解决的问题 | 具体做法 |
|---|---|---|
| ① 什么规范（Rules） | AI 不知道你的规矩 | 制定安全/工程/代码规范，以 Rules 文件注入 AI 上下文 |
| ② 在哪里（Structure） | AI 不知道代码放哪 | 描述代码目录层级结构，让 AI 精准定位 |
| ③ 做什么（Spec） | AI 不知道业务逻辑 | 技术方案模板化，面向 AI 可执行的结构化描述 |
| ④ 怎么做（Prompt） | AI 不知道执行顺序 | Prompt 标准化，按依赖链编排任务 |
| ⑤ 做了啥（Summary） | 人不知道 AI 干了什么 | AI 强制自我总结，方便 CR 和后续维护 |
落地效果：人员覆盖 100%，需求覆盖 70%+，Agent 代码行采纳率 50%+，研发时长节约 30%+。
他们还发现了一个关键细节：任务顺序必须遵循依赖链。 先生成 Service 再生成 Repository 时，AI 可能遗漏接口。正确顺序是 Model → Repository → Service → Controller。
2.3 快手智能 CR：信任是怎么建起来的
快手的智能 Code Review 进化史特别值得研究，因为它完整展示了「AI 怎么从不被信任到被信任」的过程：
| 阶段 | 做法 | 采纳率 | 问题 |
|---|---|---|---|
| 1.0 纯 LLM | 直接让大模型审代码 | 7.9% | 废话太多，误报严重，开发者抵触 |
| 2.0 知识引擎 | 上下文引擎 + 1100 条确定性规则 + 三层过滤 + BadCase 反例库 | 54% | 深度分析不够，规则驱动缺乏创造性 |
| 3.0 Agentic | 双路并行：简单走确定性链路，复杂走智能体深度分析 | 持续提升 | 成本和延迟更高 |
从 7.9% 到 54%，核心不是换了更强的模型，而是做了三件事：
- 注入知识：把团队规范、历史故障、最佳实践固化为 1100+ 条规则
- 多层过滤：废话过滤→准确性校验→价值密度评估，只透出有价值的评论
- 反馈闭环：BadCase 入库，向量检索拦截同类误判，越用越准
结论：AI 质量保障不是接个 API 就行，它是一套需要持续运营的知识工程。
2.4 GitHub Copilot 500 人部署：培训比工具重要
GitHub 一个 500 人企业级部署案例给出了一组非常有说服力的数据：
- 中级开发者（2-5 年经验）效率提升最大，达 38%
- 初级开发者 25%，资深开发者 18%
- 有结构化培训的团队，采纳率 74%；没培训的，19%
- 推进节奏：50 人试点（1 个月）→ 200 人扩展（2 个月）→ 500 人全覆盖（3 个月）
- ROI：$39/人/月成本，保守估算 4:1 回报
最重要的发现：工具一样，培训与不培训，采纳率差 4 倍。
2.5 行业共性数据：信任危机
我们必须正视一组矛盾数据：
| 指标 | 数据 | 来源 |
|---|---|---|
| AI 编程工具使用率 | 84% | Stack Overflow 2025 |
| 对 AI 输出的信任度 | 29%（较 2024 年下降 11 个百分点） | Stack Overflow 2026 |
| 「高度信任」占比 | 仅 3% | Stack Overflow 2026 |
| AI 代码安全测试通过率 | 55%（45% 不通过） | Veracode 2025 |
| 开发者验证 AI 代码的时间占比 | 工作时间的 24% | byteiota 2026 |
| 使用 AI 的开发者实际速度 | 比不用 AI 慢 19% | METR 2025 |
最后一条数据最刺眼：METR 的研究发现，使用 AI 的开发者自认为快了 20%，但实际测量下来慢了 19%。原因是验证和修复 AI 代码消耗了大量时间。
这不是说 AI 没用——而是说如果不建立正确的使用方式，AI 反而会拖慢速度。 这是我们设计方案时必须正视的现实。
2.6 其他关键参考
| 企业/产品 | 核心做法 | 关键数据 |
|---|---|---|
| 腾讯 CodeBuddy | 三形态（插件/IDE/CLI）+ Skills | 1.2 万工程师使用，50% 新增代码 AI 辅助 |
| 字节 TRAE | Context Engineering + Spec + Rules + Skills + MCP + Agent | CRUD 场景效率 +340% |
| AWS Kiro | Spec-Driven：Requirements→Design→Tasks→Code | CDK 项目从 10h→1.5h（效率 6-7 倍） |
| Augment Code | Context Engine，40 万文件级代码库理解 | 多文件 AI 编码准确率从 19.36%→87.2%（有架构上下文时） |
三、关键洞察提炼
把调研结果蒸馏一下，有五条对我们十人团队最重要的洞察：
洞察一：个人提效到组织提效之间有一道鸿沟
这不是自然传导的。AI 省下的编码时间是碎片化的，如果没有机制把这些碎片重新组织成交付能力，它们就会消散在会议、等待和上下文切换中。
对我们的启示：不能只推工具，必须同步调整需求拆分方式和交付节奏，让省下来的时间有事可做。
洞察二：编码不是瓶颈，瓶颈在编码之外
编码只占交付周期的 20-30%。我们十个人的需求交付周期里，需求对齐、方案评审、联调、测试、发布流程占了大头。如果只加速编码，交付周期不会显著缩短。
对我们的启示：AI 的投入重心不应该只在代码生成上。需求结构化拆解、技术方案自动生成、测试用例生成、AI CR——每个环节哪怕提速 10%，累加起来才是真正的交付周期压缩。
洞察三：信任必须用工程手段建立
84% 使用但 29% 信任。快手 CR 从 7.9% 到 54% 不是靠换模型，是靠知识注入、过滤机制和反馈闭环。
对我们的启示：不能让大家「凭感觉」判断 AI 代码能不能用。需要建立 Rules 体系约束生成质量，建立 AI CR 作为安全网，建立 AI Summary 作为追溯链路。
洞察四：培训决定了采纳率的生死线
有培训 74%，没培训 19%。这是 4 倍的差距，而且是同一个工具。
对我们的启示：十人团队的优势是面对面传帮带成本低。但必须投入专门时间做实操培训，不能只发个链接让大家自己摸索。
洞察五：先标准化再智能化
快手第一阶段花了一整年做流程标准化（没推 AI），人均吞吐量就提升了 41.57%。而第二阶段推了 AI，交付效率反而不变。
对我们的启示：我们的流程标准化程度如何？如果技术方案格式不统一、代码规范没有共识、CR 标准因人而异，推 AI 只会放大这些混乱。十人团队做标准化的成本远低于大厂，这是我们的优势。
四、十人团队的特殊性分析
大厂方案不能直接搬。十人团队有自己的优势和约束，方案必须适配：
4.1 我们的优势
| 优势 | 为什么重要 |
|---|---|
| 沟通成本低 | 不需要层层审批，一个站会就能对齐全组 |
| 流程改造阻力小 | 没有大组织的惯性，说改就改 |
| 面对面培训成本低 | Pair Programming 搞两周全组就会 |
| 反馈闭环快 | 试点→复盘→调整一周就能走完，不需要三个月 |
| 规范统一容易 | 十个人达成编码规范共识比千人团队简单得多 |
4.2 我们的约束
| 约束 | 影响 |
|---|---|
| 没有专职平台团队 | 不可能自建度量平台、MCP 工具集、知识库系统 |
| 人力不可替换 | 每个人走了都是伤筋动骨，不存在「先试点再推广」的余裕 |
| 预算有限 | 不能人手一个 $20/月的 Cursor Pro |
| 业务压力不会暂停 | 不可能停下来花一个月搞标准化 |
| 知识集中度高 | 核心业务知识可能集中在 1-2 个人脑子里，没有文档化 |
4.3 核心策略：轻量化、渐进式、全员参与
大厂的路径是「先标准化→再推工具→最后改范式」，三步分三年。我们不可能这么干。
十人团队的正确姿势是：三件事并行推，但每件事都做最小可行版本。
- 标准化：不写 100 页规范，写 3 个 Rules 文件 + 1 个技术方案模板
- 工具推广：不做工具选型报告，全组统一一个工具，Pair Programming 搞两周
- 流程调整：不重新设计研发流程，只调整需求拆分粒度和 CR 环节
五、落地方案设计
5.1 总体框架
Phase 0: 地基（第 1-2 周） Phase 1: 跑通（第 3-6 周） Phase 2: 扩面（第 7-12 周）
─────────────────────── ─────────────────────── ───────────────────────
团队规范共识 编码环节 AI 深度接入 全链路 AI 渗透
↓ ↓ ↓
知识显性化 方案模板化 + Prompt 标准化 需求→方案→代码→测试→CR
↓ ↓ ↓
工具统一 + 实操培训 试点 2-3 个需求验证效果 度量数据驱动持续优化
─────────────────────── ─────────────────────── ───────────────────────
目标：共识 + 能力就绪 目标：编码环节 ROI 验证 目标：交付周期可度量缩短
5.2 Phase 0：地基（第 1-2 周）
这个阶段不写一行 AI 代码。 只做三件事：统一规范、显性化知识、工具培训。
5.2.1 团队规范共识（3 个文件搞定）
不写大部头文档。用 AI 编程工具的 Rules 机制，把最核心的规范固化为三个文件：
文件一：安全红线（全员必读，不可违反）
覆盖内容：敏感信息处理、SQL 注入防护、权限校验、依赖版本约束。这个文件的特点是「禁止清单」——告诉 AI 什么绝对不能做。
文件二：架构约定（指导代码放哪、怎么分层）
覆盖内容：分层规范（Controller/Service/Repository/Model）、命名约定、模块划分。这个文件的特点是「组织契约」——告诉 AI 代码的物理结构。
文件三：编码风格（统一团队代码风格）
覆盖内容：语言级编码规范（Java/Go/Python 各一份）、日志规范、异常处理规范。这个文件的特点是「风格统一」——让 AI 生成的代码看起来像一个人写的。
操作方式：开一次 2 小时的全组会，逐条过，有争议当场表决。通过后 commit 到代码仓库。
5.2.2 知识显性化
十人团队最大的知识风险是「都在脑子里」。AI 不能读脑子，所以必须把关键知识拿出来：
| 要显性化的知识 | 做法 | 负责人 | 预计耗时 |
|---|---|---|---|
| 核心模块依赖关系 | 画一张模块依赖图（不需要很精致，白板拍照就行） | 架构最熟的人 | 2h |
| 代码仓库目录结构说明 | 一个 markdown，说明各目录的职责 | 各模块负责人 | 每人 30min |
| 业务术语表 | 把核心业务概念列出来，附一句话解释 | 业务最熟的人 | 2h |
| 常用内部 SDK 的用法 | 闭源组件的调用示例，给 AI 当参考 | 用过的人 | 每个 SDK 1h |
这些东西做一次，后续所有人用 AI 编程都受益。而且它们不只服务 AI——新人 onboarding 也需要。
5.2.3 工具统一 + 实操培训
工具选型原则：全组统一一个，别搞百花齐放。原因很简单——十个人分别用三个工具，Rules 写三套，经验没法复用，培训做三遍。
培训方式：不搞讲座。用 Pair Programming 的方式，两人一组，拿一个真实需求走一遍完整流程。两周轮完全组，每个人至少完成一次「AI 辅助完成完整需求」的体验。
培训内容不是教怎么打开工具，而是教：
- 怎么写好 Rules 让 AI 遵守规范
- 怎么写结构化的技术方案让 AI 能执行
- 怎么写 Prompt 让 AI 按依赖顺序实现
- 怎么审查 AI 生成的代码（重点审什么，可以跳过什么）
- 什么时候该用 AI，什么时候不该用
5.3 Phase 1：跑通（第 3-6 周）
这个阶段的目标是验证 ROI：在编码环节证明 AI 确实能省时间，量化出来。
5.3.1 技术方案模板化
这是整个方案里投入产出比最高的一步。
传统技术方案是写给人看的，比如：「用户提交审核后，系统校验权限，更新状态，记录日志。」 AI 看到这句话，不知道改哪个类、调哪个方法、异常怎么处理。
面向 AI 的技术方案是结构化的执行指令：
目标类: ReviewServiceImpl
目标方法: submitReview(ReviewSubmitRequest)
步骤:
1. TaskRepository.findById(taskId) → 校验存在且状态="PENDING"
2. AuthService.checkPermission(currentUser, taskId)
3. TaskRepository.updateStatus(taskId, result)
4. AuditLogService.log(userId, taskId, result, reason)
5. IF result.isFinal() THEN NotificationService.notify(taskId)
异常: TaskNotFoundException / AccessDeniedException / IllegalStateException
依赖: TaskRepository, AuthService, AuditLogService, NotificationService
做法：设计一套轻量模板，覆盖四层——代码结构（structure）、控制器层（controller）、业务逻辑层（service）、持久层（repository）。每层模板不超过一页。开发者填空就行。
关键细节：任务编排顺序必须遵循依赖链。腾讯团队踩过的坑——先生成 Service 再生成 Repository，AI 可能遗漏接口定义。正确顺序：Model → Repository → Service → Controller。
5.3.2 Prompt 标准化
不是让每个人自己想怎么跟 AI 说话。准备一个 Prompt 模板，核心结构：
任务描述 → 技术规范引用 → 代码结构引用 → 分步任务（按依赖顺序）→ 约束声明 → 验收标准
其中「约束声明」非常关键，必须包含：
- 只实现以下任务，不修改范围外的代码（防止 AI 画蛇添足）
- 按任务编号顺序执行（防止依赖错误）
- 每个任务完成后对照验收标准自检（防止遗漏）
5.3.3 AI 总结机制
AI 生成代码后，强制产出一份变更总结：改了哪些文件、做了什么决策、有哪些待确认点、与技术方案的偏差。
这不是形式主义——它直接服务于两个场景：
- CR 时：审查者不用逐行看代码，先看总结就能判断方向对不对
- 后续维护时：三个月后回来改这段代码，总结是比注释更好的上下文
5.3.4 试点验证
选 2-3 个中等复杂度需求，全流程走一遍：需求拆解 → 技术方案（用模板）→ Prompt（用模板）→ AI 生成 → AI 总结 → CR → 上线。
同时记录这些数据：
- 技术方案编写时长（vs 传统方式）
- 编码实现时长（vs 传统方式）
- AI 生成代码的修改量
- CR 时长
- 整体需求交付时长
不需要精确到分钟。粗略估算就行，目的是看趋势。
5.4 Phase 2：扩面（第 7-12 周）
Phase 1 跑通了，这个阶段向编码之外的环节延伸——解决木桶效应。
5.4.1 需求结构化拆解
目前的痛点：需求经常是一大坨，技术方案要花很多时间理解和拆分。
AI 介入方式：输入需求描述（或 PRD 链接），AI 输出结构化拆解——子任务列表、影响模块、接口变更、风险点。
十人团队不需要自建需求分析系统。直接在 AI 编程工具里用一个标准 Prompt 就行：
请分析以下需求并输出：
1. 子任务列表（按模块分组，标注依赖关系）
2. 涉及的模块和接口变更
3. 数据库表变更（如有）
4. 技术风险点
5. 需要澄清的问题
需求描述：[粘贴]
这步的价值不在于 AI 拆得多准——而在于它逼着你在动手之前想清楚范围，减少开发中途发现遗漏的返工。
5.4.2 测试用例生成
腾讯、快手的经验都表明：AI 生成测试用例是 ROI 很高的场景。原因是测试用例模式化程度高，而且手工写测试是开发者最不愿意干的活。
做法：在 AI 生成代码后，用技术方案中的验收标准作为输入，让 AI 生成单元测试。重点覆盖：
- 正常路径
- 边界条件（空值、越界、枚举值）
- 异常路径（下游超时、数据不存在）
5.4.3 AI 辅助 Code Review
不是用 AI 取代人工 CR。是让 AI 先过一遍，把确定性的问题（安全合规、命名规范、分层违规）提前拦截，人工 CR 聚焦架构决策和业务逻辑。
快手的经验：「AI 先审，人再看」模式可以让审查总时间缩短 70%，缺陷逃逸率降低 35%。
十人团队的实现方式不需要自建 CR Bot，用 AI 编程工具的 Review 功能就够。关键是要把 Rules 文件设置好——Rules 就是 AI CR 的检查标准。
5.4.4 MCP 工具接入
根据团队实际情况，优先接入最有价值的 MCP 工具：
| 优先级 | MCP 工具 | 解决什么问题 |
|---|---|---|
| P0 | 代码库搜索 | AI 理解现有代码实现 |
| P0 | 文档/Wiki 检索 | AI 获取业务知识和接口文档 |
| P1 | 数据库 Schema | AI 了解表结构生成正确的 SQL 和实体类 |
| P1 | Git 操作 | AI 辅助提交、分支管理、MR 创建 |
| P2 | CI/CD | AI 触发构建和测试 |
注意：MCP 工具不一定要自己开发。很多开源 MCP Server 可以直接用，或者简单适配一下。十人团队不值得投入人力从零建 MCP 基础设施。
5.5 持续运营：让飞轮转起来
方案落地不是一次性的。需要一个持续优化的机制：
周级：每周站会花 5 分钟收集 AI 使用中的 BadCase 和 GoodCase。BadCase 检查是否需要补充 Rules，GoodCase 沉淀为团队经验。
双周级：回顾 AI 辅助需求的交付数据，对比传统方式，看趋势。
月级：更新 Rules 和模板，根据实际使用反馈迭代。把效果好的模式固化，淘汰不好用的。
六、实施过程中的关键问题讨论
以下是基于行业调研和我们自身情况，提前预判的关键问题和应对思路。
6.1 「AI 生成的代码我不放心」——信任问题
根源：84% 使用但 29% 信任，这是行业普遍现象，不是我们团队的特殊问题。
应对：
- 不要强制信任，建立验证机制。AI Summary + AI CR + 人工终审的三层保险
- 初期明确「AI 负责生成，人负责审核」的分工。先建立「AI 是实习生」的心智模型
- 用数据说话：记录 AI 代码上线后的缺陷率，和纯人工代码对比。快手的数据是 AI 辅助的代码质量不低于人工
不应该做的：不要搞「AI 代码必须采纳率达到 X%」的强制指标，这会导致开发者为了凑数字而降低审查标准。
6.2 「资深工程师觉得 AI 太 low」——认知差异
根源：GitHub 500 人部署数据显示，资深开发者效率提升最低（18%），因为 AI 的建议对他们来说确实太基础了。
应对：
- 资深工程师的 AI 使用场景不同：不是让 AI 帮他写代码，而是让 AI 帮他写技术方案、生成测试用例、做 CR 初筛。这些是高级别的、他们本来不愿意做但必须做的工作
- 让资深工程师参与 Rules 制定和模板设计——他们的经验应该编码进 Rules，而不是每次口头传授
- 提升视角：资深工程师的未来不是写更多代码，是驾驭 AI 交付更多系统
6.3 「技术方案模板化太死板了」
根源：好的工程师喜欢灵活性，模板化看起来像官僚主义。
应对：
- 先搞清楚模板化的目的不是限制人，是降低 AI 的使用门槛。没有模板，每个人要从零写 Prompt，试错成本高
- 模板是最小可行模板，不是面面俱到的表格。只约定结构，不约定内容细节
- 明确：模板是过渡态。随着团队 AI 使用越来越熟练，模板会越来越薄，最终可能只剩几条核心约定
6.4 「哪些需求适合用 AI，哪些不适合？」
基于行业经验和我们的判断：
| 适合 AI 的 | 不适合 AI 的（当前阶段） |
|---|---|
| CRUD 接口开发 | 线上紧急止损 |
| 配置变更、字段增删 | 分库分表等数据层操作 |
| 单元测试编写 | 安全凭据相关变更 |
| 代码重构（明确范围） | 深度性能优化 |
| 文档和注释生成 | 涉及闭源 SDK 且无使用模板 |
| 标准化的接口迁移 | 跨 5 个以上模块的复杂需求 |
核心原则：不适合的场景不硬上。保留人工通道，别让「全面 AI 化」变成目标本身。
6.5 「Token 不够用怎么办？」
根源：大模型有 token 配额限制和工具调用次数限制，复杂需求可能中途断裂。
应对：
- 合理拆分粒度：腾讯团队的经验是以「单个独立可编译模块」作为单次 AI Code 的范围
- 先 Spec 后 Code：把技术方案写清楚了再让 AI 执行，避免 AI「边想边写」浪费 token
- 复杂逻辑用强模型，简单 CRUD 用快模型——不同场景不同模型策略
6.6 「怎么防止团队成员技能退化？」
根源：2026 年行业研究显示 48.8% 的开发者在与 AI 协作时存在认知偏差，包括过度依赖（automation bias）和认知卸载。41% 的初级工程师在无 AI 帮助时已经难以完成基础开发。
应对：
- AI 生成的代码必须附带人工审查，审查者需要理解代码逻辑，不是点个「approve」
- 初级成员的培养路径要包含「不用 AI 独立完成」的练习
- 定期做「裸写」练习：每月选一个小需求，全程不用 AI，保持基本功
七、度量体系：怎么知道做对了
7.1 十人团队的度量原则
大厂搞度量平台、搞数据大盘。我们不需要。十人团队的度量原则是：
- 指标少而精：不超过 5 个核心指标
- 收集成本低：不需要额外工具，从现有流程中自然收集
- 看趋势不看绝对值：我们要的是「变好了」还是「变差了」，不是精确到小数点
7.2 核心指标
| 指标 | 怎么收集 | 看什么 |
|---|---|---|
| 需求交付周期 | 项目管理工具里直接看（需求创建到上线的天数） | 这是最终指标。如果这个没缩短，其他指标再好看也没用 |
| AI 辅助需求占比 | 每个需求标记是否使用了 AI 辅助 | 覆盖面。目标 Phase 1 结束时 30%+，Phase 2 结束时 70%+ |
| AI 代码修改率 | AI 生成后人工修改的比例（粗略估算） | 质量指标。如果修改率持续 >50%，说明 AI 输入质量（Spec/Prompt/Rules）需要优化 |
| 上线缺陷率 | AI 辅助需求 vs 纯人工需求的线上 Bug 数 | 安全底线。如果 AI 辅助需求的缺陷率显著高于人工，必须停下来排查 |
| 团队满意度 | 每月一次匿名问卷（1-5 分） | 主观感受。如果分数下降，说明有阻力需要处理 |
7.3 反直觉数据的预警
行业数据告诉我们要小心这些情况：
- AI 让代码产出增加 41%，但代码 churn 翻倍：可能意味着 AI 在制造更多需要返工的代码
- 生产力提升 18% 但缺陷密度 1.7 倍：速度提升被质量问题对冲了
- 开发者自认为快了 20% 但实际慢了 19%：主观感受和客观数据可能完全相反
所以我们必须看客观数据（交付周期、缺陷率），不能只看主观感受。
八、风险全景与应对
| 风险 | 概率 | 影响 | 我们的应对 |
|---|---|---|---|
| AI 幻觉——生成范围外的代码 | 高 | 中 | Prompt 约束声明 + AI Summary 对照技术方案 |
| 团队抵触——觉得是额外负担 | 中 | 高 | Phase 0 全员参与规范制定（参与感）；用试点数据说话（不靠命令） |
| 安全风险——敏感信息泄露 | 低 | 极高 | Rules 安全红线 alwaysApply；AI CR 自动检测；人工终审 |
| Token 耗尽——生成中断 | 中 | 中 | 拆分粒度控制；多模型策略 |
| 过度依赖——技能退化 | 中 | 高 | AI 代码必须 CR；初级成员定期「裸写」练习 |
| 规范没人维护——逐渐过时 | 中 | 中 | 每月 Rules 维护日，指定 owner |
| 闭源组件——AI 认知盲区 | 高 | 中 | 内部 SDK 使用模板纳入知识库 |
九、时间线总览
第 1 周 ▓▓ 全组会：规范共识 + 工具选定
第 2 周 ▓▓ 知识显性化 + Pair Programming 培训开始
第 3 周 ░░ 技术方案模板 + Prompt 模板定稿
第 4 周 ░░ 试点需求 #1 全流程走通
第 5 周 ░░ 试点需求 #2 + 数据收集
第 6 周 ▓▓ Phase 1 复盘，方案迭代
第 7 周 ░░ 全组推广：所有新需求默认走 AI 流程
第 8 周 ░░ 需求结构化拆解 + 测试生成接入
第 9 周 ░░ AI CR 流程接入
第10 周 ░░ MCP 工具接入（代码搜索 + 文档检索）
第11 周 ░░ 数据回顾 + Rules 迭代
第12 周 ▓▓ Phase 2 复盘，产出效果报告
▓▓ = 里程碑节点 ░░ = 执行周
Phase 2 结束时的预期目标（参考行业数据设定）：
| 指标 | 目标值 | 行业参考 |
|---|---|---|
| AI 辅助需求占比 | 70%+ | 腾讯审核团队 70%+ |
| 需求交付周期缩短 | 20%+ | 快手标杆团队 58%（万人），我们保守估计 |
| Agent 代码修改率 | <40% | 腾讯审核团队采纳率 50%+（即修改率 <50%） |
| 团队满意度 | 4.0/5.0 | GitHub 调研 88% 感觉更高效 |
十、给自己的备忘
写这份文档的过程中，我反复提醒自己几件事，也作为团队共识记下来：
1. 我们要的不是「用上 AI」，是「多交付需求」。 工具使用率 100% 但交付周期不变，等于零。
2. AI 不是目标，是手段。 如果某个环节人工更快更稳，就该人工。别为了「全面 AI 化」而 AI 化。
3. 信任靠工程建立，不靠信仰。 Rules 约束 + AI CR + AI Summary + 人工终审，四层保险。
4. 先标准化再智能化，但十人团队可以并行。 三个 Rules 文件 + 一套模板，两周搞定，不需要等半年。
5. 碎片化时间必须被重新组织。 省下来的编码时间如果不被有意识地用于多接需求、多做测试、多还技术债，它就会消散。
6. 模板是脚手架，不是牢笼。 建起来是为了让楼立住，楼立住了脚手架就该拆。
快手花了三年、一万人走完的路，我们不需要重走。但他们踩过的坑——特别是「个人提效不等于组织提效」这一条——我们必须从第一天就记在脑子里。
