目录
一、从 AI Coding 到 AI Builder
二、为什么只做 AI Coding 不够
三、Harness 的本质：不是铁笼，而是环境
四、Plan：用 Contract 把需求变成护栏
五、Do：让 AI 开发零等待
六、Check：让推荐效果 7x24 可度量
七、Act：把 Bad Case 变成下一轮能力
八、七阶段之后，还有三个深层痛点
九、知识治理：文档给人看，Coding 给 AI 戴枷锁
十、推查查：Highway 与 ATV 的混合 Agent 架构
1.Highway：确定性来自代码
2.ATV：长尾问题需要受控探索
十一、NOW：从单点提效到工程复利
十二、尾声：碳硅梦蝶
本文是得物技术专家在 AICon 上海演讲整理的技术实录。AICon上海2026_全球人工智能开发与应用大会暨大模型应用生态展_InfoQ技术大会
「得物推荐 AI Harness 工程化实践系列」的开篇内容，本系列共三篇连载。将系统拆解得物推荐复杂业务场景下，AI代码从生成、防护校验到安全上线的完整技术体系，逐一详解自研AI Harness整体架构框架、全流程安全防护机制、混合智能体核心算法实现，以及工业级工程落地的实战细节。
本篇（上篇）：将整体介绍团队自研的AI Harness体系，包括建设思路、全生命周期防护机制、混合智能体架构及落地效果。
一
从 AI Coding 到 AI Builder
AI 写代码已经不新鲜，真正困难的是：怎么让 AI 在复杂业务系统里按目标、按边界、按质量标准持续生产。得物推荐的答案不是再造一个更会写代码的工具，而是围绕 PDCA 全链路搭建一套 AI Harness，让需求可约束、执行不断点、效果可度量、经验可复用。
过去一年，AI Coding 的体验快速成熟。它能写代码、补测试、改 bug，甚至能在局部任务里表现得非常高效。但在真实工程系统里，“能跑” 并不等于 “按目标生产”。
推荐系统尤其如此：链路长、模块多，改一处可能牵动多路召回；效果变化很难解释，经验也很难沉淀成标准。AI 如果只停留在 Do 阶段，就会变成一个更快的代码生成器，而不是一个能推动业务迭代的工程伙伴。
核心变化：AI 化的不只是开发环节，而是整个周期闭环。
二
为什么只做 AI Coding 不够
传统工程迭代可以抽象成 PDCA：Plan 对齐目标和边界，Do 完成开发实现，Check 验证效果和风险，Act 沉淀复盘与下一轮优化。AI Coding 主要解决的是 Do，但复杂系统里的失败，往往并不只发生在 Do。
因此，我们推荐做AI的目标不是让 AI “更会写代码”，而是让 AI 进入完整迭代飞轮：目标更清晰、执行不断点、效果可量化、经验可复用。
AI Coding to AI Builder：能跑不等于按目标生产
三
Harness 的本质：不是铁笼，而是环境
讲 Harness 之前，可以先想一部电影：《楚门的世界》。楚门被关在一个巨大的虚假世界里，但真正有效的约束并不是摄像头、海岛或演员，而是环境本身：它让楚门觉得，这就是世界本来的样子。
好的 AI Harness 也是这样。它不是在 AI 外面挂一串硬规则，而是把目标、边界、依赖、验证和回流能力做进协作环境，让 AI 在“自然行动”的同时不容易越界。
好的 Harness 不是铁笼，是环境。它让 AI 觉得自己在自由行动，但每一步都天然处在可验证、可回滚、可复用的工程上下文里。
楚门的世界：最有效的harness是环境，让他觉得，世界本该如此
七阶段护栏：把 PDCA 拆成可度量协作面
七阶段护栏：全面覆盖 PDCA
四
Plan：用 Contract 把需求变成护栏
很多需求失败，不是因为代码没写好，而是从一开始就理解错了。自然语言 PRD 对人已经有歧义，对 AI 更是如此。所以 Plan 阶段的核心，是把需求改造成 AI 能理解、能执行、能验证的结构化契约。
在得物推荐实践里，T-PRD 会把需求拆成 EP，每个 EP 再绑定影响范围、指标方向、稳定性红线和验收断言。以“负反馈调权”为例，产品说“用户点不感兴趣，希望少推类似商品”，工程上要拆成信号接入、多粒度降权策略、实验与指标护栏等可执行单元。
feature:negative_feedback_rerankgoal:用户点“不感兴趣”后，减少相似商品曝光scope: -Signal:not_interested/dislike -Rnking:item/spu/shop/brandguardrails: -禁止核心点击率显著劣化 -必须保留多样性与新颖性观察 -所有影响模块需具备回滚路径
五
Do：让 AI 开发零等待
AI 自主开发最怕“等人”。它写完代码跑不起来，拿不到日志，依赖服务不稳定，就会不断回头问人，最终变成一个很贵的自动补全。
六
Check：让推荐效果 7x24 可度量
推荐系统的 Check 很难，因为很多时候团队自己也无法简单判断“这次推荐到底好不好”。传统方式依赖 AUC、GAUC、线上实验和人工评审，成本高，反馈慢。
Axis 推荐 AI 评测平台引入 AI 评审员，模拟不同用户画像，从新颖性、质量、相关性等维度对推荐结果打分。它不是替代线上实验，而是在上线前多一层体验风险雷达。AI 全量评分，专家抽样复核，再把复核知识沉淀回评测体系。
关键点：AI 评测不是为了证明模型一定对，而是为了让体验风险更早暴露、让评审口径可以持续沉淀。
Check：Axis 推荐 AI 评测平台，把体验评审变成 7x24 自动评审
七
Act：把 Bad Case 变成下一轮能力
当线上出现异常，系统会进入 Bad Case 捕获、诊断、沙箱复盘和 Story 沉淀流程。一次问题排查不应该只留下一个结论，而应该留下下一次能直接复用的路径。
八
七阶段之后，还有三个深层痛点
流程护栏能解决很多问题，但 Agent 本身仍然有局限：知识会丢、行为会漂、路径不透明。这些不是某个阶段的问题，而是 Agent 工程化承载的问题。
九
知识治理：文档给人看，Coding 给 AI 戴枷锁
有个程序员笑话：程序员最不喜欢两件事，第一是别人不写文档，第二是我写文档。AI 也一样。你不告诉它规则，它就乱跑；你用纯自然语言告诉它，它又很难稳定理解边界。
得物推荐把知识分成三层：L1 是整体架构，定义不可逾越的行动边界；L2 是模块设计文档，解释关键取舍和依赖关系；L3 是代码注释，最贴近 AI，读代码时随用随取。
在实验中，补充 L3 注释后，简单问题准确率从 52% 提升到 91%，复杂问题准确率达到 100%；简单题整体 token 消耗下降 48%，复杂题下降 26%。单次上下文可能变长，但任务完成轮次显著减少，整体成本反而下降。
L3 注释评测：让模型从猜测走向可验证
十
推查查：Highway 与 ATV 的混合 Agent 架构
在推荐链路排查场景里，一个现实观察是：80% 的问题是高频、可归类、可复现的，20% 的问题是长尾、复杂、需要探索的。两类问题不应该用同一种 Agent 路径解决。
Highway：确定性来自代码
一个经典玩笑是：女朋友让你买两根香蕉，如果看到卖苹果的，就买四根。人会脑补，到底买香蕉还是苹果；代码不会，它只会按条件执行。
Highway 的原则也一样：好的 Highway 不是更会猜，而是不脑补。把稳定路径写进代码，让每一次都在同一个地方执行、同一个地方观测、同一个地方定位错误。LLM 只负责最后的结果润色。
ATV：长尾问题需要受控探索
剩下 20% 的长尾问题无法靠写死程序覆盖。ATV 提供工具、MCP 和约束，让 Agent 按 ReAct 方式自主拆解、调用工具、读取结果、生成结论。探索成功后，Memory 会把轨迹剪枝，把 UID 等一次性特征升维成业务变量，再经过 Dry Run 准入，沉淀为新的 Highway 能力。
Memory：把一次成功变成下次默认能力
十一
NOW：从单点提效到工程复利
当 Plan、Do、Check、Act 都被 AI Harness 纳入治理，收益就不只是“某个人写代码快了”，而是整个迭代系统开始转起来。
这套体系的价值，不是让 AI 替代工程师，而是让工程系统本身更适合人和 AI 一起工作。
十二
尾声：碳硅梦蝶
两千多年前，庄子醒来，不知道是自己梦见了蝴蝶，还是蝴蝶梦见了自己。今天的 AI 协作也有类似的错觉：我们一边给大模型写 Prompt、喂 Context、鼓励它进入创造状态；另一边，我们自己在流程、工单、SOP 和评测指标里越来越像一个接口。
于是，一个有趣的反转出现了：我们把 AI 当人用，接受它的涌现、幻觉和不确定性；同时，我们也把人当 AI 用，把沟通前提、输入输出、执行边界和健康度工程化。
Harness 就是梦境边缘。它不判断谁在做梦，只保证 AI 梦醒时有规则兜底，人类疲惫时有流程支撑。最终的命题不是“AI 会不会写代码”，而是“我们能不能把 AI 纳入一套可控、可度量、可复用的工程协作系统”。这才是从狂野代码走向按目标生产的真正跃迁。
