【导读】
AI Coding 改变了研发方式，然而单点代码生成仅占研发工时 10 - 32%，整体提效有限。本文从团队项目的真实交付复盘出发，提出 Harness 全链路研发智能体，将大模型融入可控研发流程，把需求分析、接口设计等环节串成带反馈控制的闭环，让 AI 从 "会写代码" 升级为 "能完成可验证交付"。同时，文章系统阐述了其需求可执行性检查、状态机与质量门禁设计等内容，并以行业研究做交叉印证。
【01 问题定义：AI Coding 为什么 "用起来不错，但没省多少时间"？】
【1.1 我们自己的复盘：coding 快了，但需求没更快交付】
2026 年 4 月起，团队在项目里全面接入 AI Coding。复盘发现，写代码环节明显提速，但需求落地的整体时间并未按相同比例缩短。统计已接入需求的实际数据显示，coding 环节可提效 30%，但需求完成时间几乎不变。与不同项目同学沟通，反馈一致，提速集中在 "写"，而写前的需求澄清、写后的验证和环境等环节，AI 基本未涉及。
【1.2 这个体感成立吗？业界研究也指向同一处】
团队复盘可能存在偏差，对照业界研究发现结论一致且能解释原因。Antenna 研究显示开发者每天实际编码中位数仅 52 分钟，远低于多数人自认的 "2 小时以上"；Stripe 报告指出工程师约 42% 的时间花在技术债和维护上，真正写新代码只占约 32%。若 AI 只加速 10 - 32% 的编码时间，即便提效 55%，整体也只省 5 - 16%，这解释了复盘结论。几组独立证据共同表明，问题不在模型，而在模型外面的工程系统，模型解题能力已过剩，裸用模型可能减速，决定成败的是模型外的 "控制系统"。
【1.3 研发的日常，远不止写代码】
对照服务端研发的典型节奏，AI Coding 能帮忙的地方很多，但大多未被串进研发流程，未得到有效利用。
【1.4 本文要回答的问题与成功标准】
目标是让 AI 从 "只会写代码" 升级为 "能跟着研发链路从头到尾走完"，实现全链路提效。为此，设定了三条可检验的标准：端到端，即从需求卡片到提测材料无需人工衔接断点；可验证，每次交付都经过 "QA" 从单模块到系统测试并保留 CR 证据；可复制，无项目背景的同学也能按流程独立交付，不依赖个别熟手。
【02 问题分解：时间损耗到底在哪几个环节】
团队调研发现，多数同学已用 AI 辅助编程，coding 环节的模型辅助效果显著。问题转变为，既然写代码变快，研发的工作量和时间还损耗在哪些环节？通过试用发现，研发提效瓶颈分散在需求、验证、环境、排查等场景，根因是能力未形成闭环。
【2.1 需求不清楚，AI 写的代码就是错的】
大模型生成代码的质量高度依赖输入，若需求卡片信息不清，AI 只能猜测，猜错会导致代码返工。复盘发现，问题集中在 iCafe 未写清优化前后状态、边界条件等，导致代码提交且 CR 通过，但功能不对，这是需求输入未达可执行标准的问题。
【2.2 代码写完不验证，问题全堆到后面】
传统 AI Coding 常以代码生成完成作为终点，但生成完成不等于功能正确，单测通过也不意味着接口行为符合预期。一次开发经历表明，单测虽能覆盖代码内部逻辑，但无法覆盖接口在真实调用场景下的可用性。因此，后续链路需加入真实接口验证、冒烟测试和历史回归，业界数据也证明问题发现越晚成本越高。
【2.3 能力是单点的，没有形成闭环】
需求、验证等环节并非无工具可用，但这些能力过去多为单点存在，未形成可执行、可回流的研发链路。失败后不知如何回流，简单和复杂需求走同一流程，无项目背景的同学难以衔接。所以，缺的不是单点能力，而是闭环，需将各环节按顺序和复杂度编排成能持续回流的闭环。
【2.4 环境问题吃掉大量时间】
对无项目背景的同学来说，服务启动、测试环境部署等环节比写代码更耗时。实际带新同学接入项目时，coding 环节在 AI 辅助下提效，但环境部署耗时是 coding 的几倍。GitHub 调查也显示开发者等待构建和测试的时间与编码时间相当，说明只优化代码生成，不解决环境部署，端到端交付时间难以下降。
【2.5 非 coding 高频事务：线上排查、配置变更、答疑】
研发工作中，线上排查、配置查询等非 coding 高频事务占用大量时间，且这些工作重复、有固定流程，适合用 AI 提效。但这些能力过去无统一入口，未接入 AI Coding 主流程，全链路提效应将其纳入范围。
【2.6 AI 自己写、自己验，测试结论不可信】
开发和测试由同一模型完成会出现 "自己写、自己验" 的问题，如模型跳步、伪造输出等，研发侧结论会污染测试判定，导致测试结果不可信。要让验证结果可信，测试应独立于研发，二者在输入上共享知识，在判定上保持对抗，这是高质量交付的关键。
【03 解法：Harness 全链路闭环工程】
上述问题的根因是能力未形成闭环，解法是将需求、生成、验证等能力编排成可执行、可回流的链路。Harness 把大模型放进可控研发流程，使其成为带反馈控制的工程系统，由调度中心和阶段能力构成，调度中心按复杂度判定链路，调用子能力完成交付。
【3.1 需求可执行性检查：不清楚就不往下走】
在判定任务类型前，需检查业务目标、输入输出等是否明确，任何一项不清楚就追问。这是链路关键一步，输入质量决定输出上限。需求不仅要写给人看，也要写给大模型看，有效的描述方式能让模型按结构化上下文推进任务。
【3.2 验证设计：不止单测，还要验证真实接口和历史影响】
单测通过只能证明部分代码逻辑成立，不能证明接口行为符合真实预期。因此，将验证扩展为本次需求验证和历史功能回归两层。本次需求验证要验证新增或修改能力在真实场景下的可用性，历史功能回归要验证改动是否影响既有能力。
【3.3 闭环编排：按复杂度选链路，失败后能回流】
要解决开始时怎么选链路和失败后怎么回流的问题。按复杂度选链路，简单需求无需走重链路，复杂需求走轻链路会有风险。失败后能回流，将流程做成有状态的闭环执行系统，失败时保存上下文、选择回流阶段、修复并重跑验证，同时有工程化约束，如记录失败证据、最多 3 轮止损等。
【3.4 环境部署：把服务跑起来也纳入链路】
对无项目背景的同学，环境部署比代码本身更耗时，因此环境部署应成为全链路的一部分。将 QA 对测试环境等的经验前置到流程中，让无背景同学无需摸索环境搭建，代码生成和基础验证后可直接进入测试环境部署，并记录相关信息。
【3.5 非 Coding 高频事务：接入 Dodo 群聊远端触发】
调研发现，日志排查等非 coding 高频事务适合 AI 接管，但过去触达不便。接入群聊助手后，整个研发链路可通过群聊远端触发，不依赖研发本地环境。
【3.6 QA SubAgent：引导 + 检查，构建不断对抗的研发测试智能体】
针对 "自己写、自己验" 的问题，将测试拆成独立的 QA 子 Agent。核心变化是 QA 将质量经验前置，在代码生成前后进行约束和验证。采用隔离式架构、对抗式校验和闭环式沉淀，解决上下文膨胀、测试判定失真等问题，构建可迭代的知识底座。
【04 效果验证与评估】
【4.1 已落地情况】
对提供的 skill 进行真实数据打点，并建成可视化报表展示。
【4.2 效果对比】
按具体损耗对照，查看 Harness 带来的整体改善。
【05 演进方向（Roadmap）】
Roadmap 的取舍逻辑基于代码生成本身已非瓶颈，提效空间集中在验证、环境、排查和经验沉淀等环节，后续投入将聚焦链路纵深。
【06 结论】
AI Coding 的关键是将清晰需求、可执行流程、可验证质量门禁和可沉淀经验串成全链路，让 AI 从 "体感能用" 变为 "实际可用"，使无项目背景的同学也能快速完成可验证的工程交付。核心论断有三条：瓶颈在系统不在模型，模型解题能力已过剩，实际产出取决于模型外的 scaffolding；验证是交付的一部分，质量门禁等必须内嵌于流程；经验必须流程化，QA 环境经验等沉淀为可执行能力，提效才可复制。那么，在未来的研发中，Harness 全链路研发智能体能否持续发挥作用，进一步推动 AI Coding 的发展呢？
扫一扫
347
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
