AI Coding 之后，如何让 Agent 进入企业研发全链路？得物推荐的 Harness 实践

从 AI Coding 走向 AI 全链路

AI Coding 已经能较好完成 0→1 项目和简单编码任务，但在运行十几年、代码量庞大的企业级老项目或跨系统超大型项目中，AI 能否准确理解需求、控制影响范围并对结果负责，仍是待解问题。

得物推荐系统本身包含召回、粗排、精排、推荐引擎及大量上下游服务，兼具商品交易推荐（类似淘宝京东）和内容社区推荐（类似短视频平台）两大场景。团队的目标不是让 AI 仅写代码，而是将 AI Coding 扩展为覆盖需求、开发、验收和问题反思的全链路方法。

AI 驱动的研发迭代飞轮

从软件工程视角，研发迭代可抽象为 PDCA 循环：

Plan（需求对焦）：产出 PRD、研发排期、成功标准判断
Do（开发实现）：编码 + 上下游联调 + 单测/集成测试/功能验收
Check（效果校验）：测试验证、灰度发布、指标观测
Act（分析反思）：业务指标观察、Bad Case 分析、结论带入下轮迭代

目前多数团队的 AI 实践集中在 Do 阶段（写代码），Plan/Check/Act 中 AI 参与度有限。得物希望将所有环节串联，让 AI 进入完整 PDCA 循环。

全链路 AI 化的四个前提

Plan 阶段需求必须明确：目标和边界不能反复摇摆
Do 阶段减少中断：AI 应持续运行较长时间，而非频繁因环境/依赖问题求助
Check 阶段结果可量化：通过测试结果和后验数据判断产出可靠性
Act 阶段经验可复用：踩过的坑不能反复出现

ROI 目标：提高 AI 渗透率和产出采纳率，缩短迭代周期（双周→周→天，最终自动进入下一轮）。

好的 Harness，是环境而不是铁笼

借用《楚门的世界》类比——真正限制楚门的不是围墙，而是水（环境本身）。好的 AI Harness 不应在 Prompt 中堆叠"不要""禁止""必须"，而应搭建让 AI 自然按预期运行的环境。约束应融入环境、工具和验证流程，而非显性限制。

基于此思路，团队按 PDCA 抽象出七阶段护栏，从护栏能力、护栏载体、约束逻辑三方面设计全链路体系。人仍承担不可替代作用，尤其在技术方案评审（AI 自主执行前最后的人工双层 Review 点）和 Check/Act 阶段。

Plan：TPRD + Contract 把需求变成可执行边界

自然语言需求存在歧义。团队在 PRD 之后增加 TPRD（技术 PRD），并在其中引入 Contract，提前明确：需求影响哪些模块、优化目标、方向调整、不可突破的技术约束。

TPRD 将需求拆解为多个 EP（功能点），每个 EP 明确修改位置、实现目标、约束条件、实验方式和验收标准。Contract 为每个 EP 划定边界。这些内容共同构成后续阶段的"北极星"。

核心洞察："如果方向走偏了，怎么努力都没有用。" 比如产品说"用户点击不感兴趣后少推荐类似商品"——技术上需拆解：不感兴趣的是商品/品牌/类目？"少推荐"是完全不出现/三天减少/降频/降权？这些未澄清会导致 AI 方案与产品意图偏差。

Do：三类基础设施减少 AI 等待

沙箱隔离：通过本地可运行环境/代理/预发，让 AI 一边改代码一边执行获取日志，不必等工程师到其他系统取反馈
UTD（单测驱动）：不依赖 TDD 让 AI 先写测试，而是通过数据形成验证闭环——AI 修改前 2500 用例 → 新增 100 → 执行后 400 不通过 → AI 据数据反思修改是否可靠
外部依赖 Mock：将下游服务/推荐引擎/随机条件静态化，确保输入稳定才能准确评估代码影响范围

关键理念：Harness 是给 AI 用的，也是为人建的。 AI 可以本地编码运行验证，工程师同样不必反复等联调环境。

Check：AI 模拟用户做推荐质量评测前置

推荐系统是黑盒，传统人工评测极度消耗人力（8 小时/天最多 200 条，继续增加则判断质量下降）。

团队用 AI 模拟真实用户画像（性别/年龄/购买力/人生阶段 + 季节/节日/历史行为），按 L1-L5 对推荐结果分级评分。功能上线前即可完成质量前置审核，评测从一次性人工工作转为 7×24 小时常态运行。

AI 评测准确率尚未完全对齐人工，但人工本身也有偏差。更重要的是 AI 判断过程和结果可完整保留，供专家抽样二次审核，沉淀为可复用评测资产（如"秋季推大闸蟹、冬季向价格敏感用户推反季服装"等经验）。

Act：问题排查沉淀为 Story

建设线上问题排查工具"推查查"——监控发现异常或舆情 Bad Case 后，人工和 AI 同时排查。排查完成后复盘原因、路径、有效信息，最终沉淀为 Story。

Story ≠ Skill。Skill 是等待 AI 下次重新理解的经验说明；Story 是将已验证的排查路径转化为确定、可编码、可重复执行的方案。

用 CDD 和三层知识体系解决知识丢失

AI 进入完整链路后暴露三个问题：知识丢失（上下文有限）、随机漂移（相同 Prompt 不同结果，甚至假调用工具自行 Mock）、路径不透明（Agent 黑盒，难定位卡点）。

团队从工程自身出发，采用 CDD（Comment-Driven Development）——先让 AI 补注释而非补文档，因为注释距代码最近，可在 AI Coding 时同时被读取，也随代码变化及时更新。

在此之上构建三层知识体系：

L1（不可逾越的行为边界）：团队级硬约束，如必须配套单测、注释率 >30%，整个任务过程中始终生效
L2（模块级设计知识）：解释模块为何这样设计、关键依赖关系，架构师梳理，更新频率低（半年级），AI 处理跨模块问题时提供架构背景
L3（代码关联注释知识）：距离代码最近的即时知识，随代码变化更新，帮助 AI 理解常量含义/局部逻辑/设计意图

执行逻辑：L1 始终生效 → AI 先读 L3 → 局部不足时启用 L2。效果验证：无注释时 AI 回答准确率约 52%，补齐注释后达 90%+，追问次数和总体 Token 消耗均下降。

Highway + ATV 混合 Agent 架构

设计思路来自二八定律：

Highway（80% 高频问题）：将已知问题的排查过程编码成确定的执行逻辑（代码），意图路由匹配后直接执行，不由 AI 重新推导。核心洞察——"人会猜测，AI 会猜测，代码不会"，把已知问题全部代码化即最大化确定性
ATV（20% 长尾问题）：允许 Agent 自主探索（使用 OpenClaw/龙虾、Hermes 等），像工程师面对未知问题一样调用多系统多工具
进化层：ATV 解决的问题每晚触发反思，AI 将已解决问题重新转化为代码（非 Skill），人工按 Checklist 检查后进入 Highway。随积累增加，Highway 确定性能力持续扩大

Story vs Skill 的核心区别：Skill 需要 AI 再次理解（存在随机性）；Story 是经问题验证并固化为代码的执行经验。

阶段性实战结果

AI 需求链路渗透率约 30%（并非所有需求都适合 AI 参与，如一行配置修改无需复杂流程）
问题排查处理时长下降约 80%，部分场景更高（已知问题代码化后一轮执行跑完，接近甚至快于人工）

结语：让人和 AI 在同一个"梦境"中工作

借用 OpenClaw 的"梦境"概念——AI Harness 中执行任务的是 AI 还是人并非最重要。AI 会遗忘犯错，人也会；人需沉淀经验，AI 也需建立经验体系。

真正重要的是在"梦境"边缘搭好 Harness，让执行者自然理解环境、遵循边界、持续验证反思积累经验。当需求边界清晰、开发可验证、效果可量化、经验可复用时，AI 才能从写代码的工具真正成为企业研发迭代飞轮的一部分。

Zero 的看法

这篇文章的核心价值在于一个判断：Agent 进入企业研发的瓶颈不在模型能力，而在工程基础设施的搭建。 得物团队的实践本质上是在回答"当 AI 作为协作者时，研发体系需要怎样重构"。

几个值得关注的点：

TPRD/Contract 是被低估的一环。 多数 AI Coding 讨论聚焦在代码生成质量，但得物指出需求歧义才是企业级场景最大的损耗来源。"如果方向走偏了，怎么努力都没用"——这句话对前端工程同样成立，需求阶段的结构化投入 ROI 远超编码阶段的工具优化。
Story vs Skill 的区分有洞察力。 Skill 依赖 AI 每次重新理解（引入随机性），Story 直接固化为可执行代码。这个区分对 Agent 架构设计有实操意义——确定性问题的解法不应经过 LLM 推理路径。但这也有风险：代码化的 Story 库本身会成为维护负担，且当系统演进时过期 Story 可能产生误导。
三层知识体系（L1/L2/L3）对前端团队可直接借鉴。 React 项目中 L3 对应组件级注释、L2 对应架构决策记录（ADR）、L1 对应 ESLint 规则和团队规范。注释驱动的知识建设比维护独立文档更可持续，52%→90% 的准确率提升数据有说服力。
Highway/ATV 混合架构是务实的工程选择，但"80% 走代码"的前提是你已经积累了足够多已验证的问题路径。 对新团队或新系统，前期 ATV 占比会远高于 20%，"进化层"的自动代码化也依赖人工审核——这个人工成本文中没有量化。
一个值得警惕的信号： AI 假装调用工具、自行 Mock 结果（随机漂移案例）。这是 Agent 可靠性的根本性风险，得物用代码化（Highway）来规避，但 ATV 路径中这个问题仍然存在。在企业级应用中，缺乏调用链路的可观测性会严重制约 Agent 的可信度。

总体来看，这篇文章是少有的从"工程基础设施建设"角度谈 Agent 落地的实践分享，比泛泛讨论"AI 能做什么"有价值得多。其方法论可迁移性较高，但数据（30% 渗透率、80% 效率提升）仍需更长时间的验证。