共 4 篇内容，涉及 1 个模块
8 人全栈团队，两种 IDE 混用（VS Code 前端 / JetBrains 后端），还有三个新人装了什么都不会配。本文记录两周把 DeepSeek V4.1 接进全团队工作流的完整过程：不搞一刀切——VS Code 走 Continue 插件、JetBrains 走 Continue（配置直接拷贝复用）、新人用 Trae 内置模型起步；Key 统一走公司级账号充值而不是个人垫付；用一份 config.json 模板 + 半小时上手培训把配置时间从人均半天压到 20 分钟。结果：日均活跃使用 6/8 人，月 API 成本 ¥213（人均 ¥27），AI 生成代码采纳率 61%， PR 周期中位从 2.1 天降到 1.4 天。全文含工具选型决策表、成本明细、五条踩坑记录和一份可直接复制的团队接入清单。
AI 写代码的产能和它的返工量成正比，这是研发团队用AI 编码半年后才真正撞到的墙。我们团队 12 个前端工程师、4 个 AI 编码 Agent Cursor / Cline / Copilot 并行，日均产出 PR 从 11 个涨到 27 个，看起来赢了——但首轮评审通过率只有 38%，意味着三分之二的工作量在被返工吃掉。真正的原因不是模型能力不够，而是任务交给 Agent 的方式错了：需求描述里没有验收标准，Agent 只能猜；Agent 不知道验收标准，就没法自检；不自检就直接提交，返工必然发生。本文记录我们用四个月把一次通过率从 38% 提到 71% 的完整过程。核心是三件套：① 提交前把模糊需求转成可验收的 spec（含验收命令与判定标准）；② 在 Agent 里挂可执行的验收测试，让它提交前自己跑一遍；③ 加一道 diff 自检环节专门抓「超出任务范围的改动」。四个阶段的实施顺序和每阶段的踩坑、三条被证明无效的尝试（包括「写更详细的 Prompt」）、以及12 个可复制的 Prompt 模板。附分阶段效果数据表：一次通过率 38%→71%、返工工时占比 44%→19%、交付周期 2.8 天→1.1 天，以及两个必须诚实说明的负面结果。
代码评审是研发流程里最容易堵的一环：PR 提上去平均要等 19 小时才有人看， reviewer 的时间被「这个变量命名不统一」「这里缺个空行」这类机械问题吃掉大半，真正的设计问题反而因为疲劳被放过。本文记录 N 公司基础架构组 2026 年 8 到 10 月用六周建成 AI 评审闸门的全过程：不追求「AI 替代人评审」，而是把评审拆成三道闸门——第一道 AI 机械扫描（风格、缺测试、明显 bug、安全模式），秒级返回、不过直接打回；第二道 AI 深度审查（逻辑正确性、边界、并发），只在第一道通过后跑，输出结构化意见并标注置信度；第三道人工，且 AI 明确标注「本次我覆盖了什么、没覆盖什么」，让人把注意力放在 AI 说不清的地方。关键设计是「分级拦截」：按改动风险自动决定闸门严格度，改个文案不该走全流程。结果：评审首响从中位 19 小时降到 2.4 小时，reviewer 人均每周花在评审上的时间从 6.5 小时降到 2.8 小时，合并后 7 天内发现的缺陷率下降 34%，AI 误报导致的无效返工控制在 8% 以内。全文含完整的工具分工表、三道闸门的判定规则与 Prompt 模板、分阶段投入产出数据、12 条踩坑清单，以及一条最重要的教训：AI 评审失败的头号原因不是能力不够，是它不敢说「这里我没把握」。
把 AI 编码助手引进一个 31 万行、8 年历史、几乎没有类型覆盖的 TypeScript 单仓，第一周就有工程师反馈「它写的东西我全都要重写」。本文记录 M 公司平台团队 2026 年 8 到 10 月用六周完成 AI 编码落地的完整过程：不换模型、不换工具，只做四件事——把 implicit any 清理出来让模型有类型可读（第 1-2 周）、写 14 条 .cursor/rules 把团队约束固化进去（第 3 周）、自建 OpenAI 兼容代理解决 429 中断与 Key 管控（第 4 周）、用 MCP 把内部的服务元数据和埋点查询接进 Agent（第 5-6 周）。结果：PR 从提交到合并的中位从 4.2 天降到 1.6 天，单测覆盖率从 41% 升到 67%，AI 生成代码的「几乎不用改」比例从 12% 升到 58%，月模型支出 ¥3,180（人均 ¥106）。全文含完整的工具分工表、分阶段投入与产出数据、四份可直接复制的配置、12 条踩坑清单，以及一条最重要的结论：历史包袱不是 AI 的天敌，没有类型信息才是。