#研发效能

共 3 篇内容,涉及 1 个模块

案例3
案例企业应用

Agent 编码返工率治理实战:spec + 验收测试 + diff 自检三件套,把 AI 代码一次通过率从 38% 拉到 71%

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 天,以及两个必须诚实说明的负面结果。

2026-10-13
#AI实战#AI编码
案例企业应用

AI 代码评审闸门落地实战:三道闸门 + 分级拦截,6 周把评审等待从 19 小时压到 2.4 小时,线上缺陷率降 34%

代码评审是研发流程里最容易堵的一环: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 评审失败的头号原因不是能力不够,是它不敢说「这里我没把握」。

2026-10-12
#AI实战#代码评审
案例企业应用

31 万行 TypeScript 单仓接入 AI 编码实战:Cursor + DeepSeek V4.1 Flash + MCP 六周落地,PR 周期从 4.2 天降到 1.6 天

把 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 的天敌,没有类型信息才是。

2026-10-10
#AI实战#遗留代码