作为团队里负责“得物小摊”这条业务线的技术负责人，我过去大半年一直在推动一件事：把整个交付链条从传统的“人写代码、人测试、人发布”，逐步改造成一条 AI Native 的流水线。这个过程中踩了不少坑，也沉淀了一套至今还在稳定运行的做法，核心就是用 Harness 这套思路来约束和编排 AI 的工作方式。今天这篇实录，就是把我们在“得物小摊”项目里从 0 到 1 落地 AI 交付的完整过程写出来，包括为什么非要转、Harness 解决的核心问题、实际搭建步骤，以及几段比较有代表性的排查经历。
如果你所在的团队正处于“AI 写代码很爽但不敢让它独立交付”的阶段，或者你听过 AI Native 概念但不知道怎么落到工程实践里，这篇内容应该能帮上忙。
1. 为什么要把“得物小摊”的交付迁到 AI Native 轨道上
1.1 小摊业务的真实处境：需求零散、节奏极快、人力长期紧张
“得物小摊”本质上是一个轻量级的交易场景，面向的是碎片化、高频次的供需匹配。这类业务有个共同特点：需求变化特别快，而且很多需求都是临时冒出来的。比如一个新活动入口、一个临时运营位、一个针对特定商品类目的展示规则调整，往往今天提需求，明天就想看到效果。
放在传统交付模型里，这种节奏意味着开发、测试、上线都要被压缩，而且留给架构设计的时间几乎为零。小团队本来人就不多，后端、前端、数据一把抓，每个人同时挂在三四个任务上是常态。这种状态下，代码质量靠的是个人自律，而不是流程保障。久而久之，技术债务越积越厚，发布一次要祈祷半小时，出问题的概率自然居高不下。
所以我一直在想：有没有一种方式，能让最常见的那类交付需求，不需要人全程盯在代码细节上，而是由 AI 把大头的代码产出、测试用例编写、甚至部分发布检查都接过去，人只保留需求判断和质量验收这两个关键动作。这其实就是后来我们理解的 AI Native 交付的雏形。
1.2 普通 AI 编程助手的失控感：能干活，但不敢放手
最早我们试用过各种 AI 编程助手，结论很一致：单点生成能力很强，但整体不可控。你让它写一个工具函数，它能写得像模像样；你让它改一个涉及状态流转的页面逻辑，它可能改完 A 又把 B 弄坏了，而且不会主动告诉你。
问题出在哪？传统 AI 编程助手的设计思路是“人下指令、AI 给结果”，它既不理解这个任务的上下文，也没有能力对自己产出的代码负责。你说“帮我加个筛选功能”，它能给你生成一段代码，但这段代码和现有模块的耦合方式、异常处理逻辑、边界情况，都得靠人替它兜底。这等于 AI 负责产出垃圾概率，人负责清理垃圾，效果还不如人直接写。
真正的 AI Native 交付，不是让 AI 做一个高级补全工具，而是把 AI 当成交付链条里的“执行主体”，通过一整套工程机制让它的产出可靠、可验证、可回溯。这个机制，就是我们后来引入的 Harness。
1.3 AI Native 交付的准确定位：AI 干细活，人抓方向盘
说句实在话，“AI Native”这个词现在被用烂了，很多人觉得只要用了大模型就算 AI Native，实际上差得很远。在我们的定义里，AI Native 交付至少要满足三个条件：
- AI 直接参与从需求理解、拆解到代码实现、测试验证、发布准备的全链路，而不是只负责中间某一小段
- AI 的工作过程可以被分段控制，任何一步出问题都能被及时发现并回退
- 人的角色从“写每一行代码”让渡为“定义目标、设定边界、验收结果”
听起来很简单，做起来完全是另一码事。我们试过的第一版方案里，AI 确实参与了多个环节，但缺少 Harness 这套控制机制，结果就是 AI 一旦在某个环节理解偏了，后面全跟着偏，而且偏得悄无声息。后来我们才意识到，AI Native 的核心短板不在 AI 的生成能力，而在“可控性”。
2. Harness 到底解决了什么问题：初衷、设计与核心机制
2.1 剥开“Harness”这个概念：它不是模型，而是一套作业规程
先解释一下名字。Harness 原本是马具、挽具的意思，引申到工程领域就是“让动力源按照人的意图去干活的那套约束装置”。放在 AI 交付场景里，它就是一套介于“大模型”和“交付结果”之间的工程框架，负责调度 AI 干活、检查 AI 的产出、控制 AI 的工作边界，以及记录每一步的操作痕迹。
那时候市面上还没有那么多现成的 Agent 框架，我们也没有直接买商业平台，而是参考了早期开源社区里 Agent Harness 的设计思想，自己搭了一套。核心思路很简单：不要把大模型直接暴露给任务，而是把它包在一个半封闭的工作环境里，外面套上任务拆解、规范校验、结果审计这几层“栅栏”，让它只能在允许的轨道里发挥生成能力。
2.2 和“裸调模型”相比，Harness 多了哪几层保险
为了讲清楚这个差异，我经常拿做饭来打比方。裸调大模型，相当于你把一个厨师叫进厨房，跟他说“做一桌年夜饭”，然后人就不管了，等两小时回来才发现菜是做了，但麻婆豆腐是甜的，可乐鸡翅用的是鸭肉。Harness 则像是给这个厨师配了一套完整的后厨管理系统：先根据菜单做任务拆解，每道菜有标准的原料清单；每做完一道菜先有试菜员尝一口，验收不通过就返工；所有操作步骤记录在案，出了问题能追溯是哪一步跑偏。
落回到工程上，我们这套 Harness 包含了四个关键层：
- 任务拆解层：把一条需求拆成若干子任务，每个子任务都带明确的输入输出定义
- 执行调度层：按依赖顺序把子任务分发给 AI 执行，注入对应的上下文和约束条件
- 质量校验层：自动跑测试、静态检查、规范校验，并把结果反馈给 AI 做修正
- 审计回溯层：记录每次执行的任务快照、提示词、产出物、校验报告，方便全程追踪
装上这套东西之后，AI 还是那个 AI，但它的干活方式从“猜我想干什么”变成了“按我定义的标准化流程执行”。这才是可控性的来源。
2.3 可控 AI 交付的三个核心能力：分段可见、错误回退、结果可验
在“得物小摊”的实践里，我最看重 Harness 带来的三个能力，这也是 AI 交付能不能从实验走向生产的决定性因素。
第一个是分段可见。以往 AI 生成代码，输入提示词、输出结果，中间发生了什么完全是个黑盒。引入 Harness 后，一条需求在流水线里跑到哪一步、当前由哪个 Agent 在处理、它选择了什么方案，每一步都有迹可循。这个能力在排查问题时特别关键，我们后面讲踩坑经历时会具体展开。
第二个是错误回退。传统模式下 AI 产出了坏代码，最稳妥的处置方式是人工重写。而在 Harness 设计里，每个阶段的产出都有对应的校验关卡，校验不通过就自动带着错误信息打回上一级，让 AI 自己修正。只有重复修正仍然不通过的，才升级给人处理。这样做大大降低了人的介入频率。
第三个是结果可验。这是容易被忽略的一点。AI 交付出来的东西，必须有一组定义好的验收标准，不管是通过单测还是通过契约测试，都要做到“自动判定是否达标”，而不是靠人眼读一遍代码觉得还行就放行。只有做到这一点，AI 才能真正独立跑在交付链路上。
3. 得物小摊 AI 交付流水线的实际搭建过程
3.1 场景筛选：不是所有需求都适合交给 AI 执行
在动手搭建 Harness 流水线之前，我做的第一件事是划定场景边界。AI 再强，也不可能对所有需求都保持同样的交付质量。我们把“得物小摊”的需求分成了三类：
- 高确定性任务：比如标准 CRUD 接口开发、固定模板页面搭建、配置类脚本调整，这类任务逻辑清晰、有章可循，交给 AI 执行成功率很高
- 中等确定性任务：比如涉及状态流转、权限判断的改动，需要 AI 结合现有代码结构做推断，属于可以尝试但必须加强校验的类型
- 低确定性任务：比如全新业务模式探索、交互方案设计，这类需求连人都还没想清楚，直接交给 AI 等于盲人骑瞎马，坚决不做
我们的原则是：先从不那么性感但重复度最高的高确定性任务开始跑通流水线，积累数据，建立团队信心，再逐步往中等确定性任务渗透。现在回头看，这个“渐进式引入”的策略非常关键，它避免了团队一上来就面对 AI 翻车现场的挫败感。
3.2 Harness 工作流的落地配置样例
下面是我们跑得最顺的一条 AI 交付流水线的简化配置，对应“标准页面需求”这一类任务。整条流水线的输入是产品经理写好的需求卡片，输出是已经通过全部校验、合入代码仓库的发布分支。
整个流水线分成五个阶段执行，每个阶段都由 Harness 调度层控制。我把核心配置大致描述一下，不贴完整代码，重点是让读者理解每一层在做什么：
delivery_pipeline: name: stall_standard_page_delivery trigger: type: requirement_card_created source: product_backlog stages: - stage: requirement_parse agent: requirement_agent input: raw_requirement_card output: structured_task_spec validation: - spec field completeness check - acceptance criteria existence check - stage: code_generation agent: coding_agent input: structured_task_spec output: code_diff constraints: - max_file_change: 15 - forbidden_module: ["payment", "refund"] validation: - static_lint - unit_test - type_check - stage: code_review_simulation agent: review_agent input: code_diff + structured_task_spec output: review_report validation: - defect_pattern check - security_todo check - stage: smoke_deploy agent: deploy_agent input: code_diff + review_report output: smoke_env_url validation: - health_check - access_log_check - stage: human_acceptance agent: human_reviewer input: smoke_env_url + review_report + test_report output: accept_or_reject fallback: on_reject: return_to_code_generation_with_feedback看起来有点抽象，我拆开讲一下每个阶段的设计用意。
需求解析阶段，我们让一个专门的 requirement_agent 把产品经理写的自然语言需求，转成结构化的任务规格书。这里面包含字段清单、状态流转表、验收标准列表。这一层的作用相当于把“模糊的人话”翻译成“AI 能照着施工的工程图纸”。如果这一层输出不完整，后面所有阶段的代码必然跑偏，所以校验里强制要求验收标准不能为空。
代码生成阶段，coding_agent 根据任务规格书生成代码改动。这里有两个比较关键的约束：一是单次改动文件数上限 15 个，防止 AI 一次改动面过大，出了错难以定位；二是把支付、退款这类高风险的模块直接列入禁用清单，不允许 AI 在缺乏人审的情况下触碰。别小看这两个约束，它们为后续的排查省了无数力气。
代码评审模拟阶段，我们用另一个专门的 review_agent 对 coding_agent 的输出做交叉检查。这个设计参考了人类社会里的“四眼原则”：写代码的和审代码的必须是两个角色，避免 AI 自我印证。review_agent 会重点找缺陷模式、安全风险标记、以及和任务规格书不一致的地方。它的产出是一份评审报告，同时喂给下一步部署和最终的人工验收。
部署验证阶段，deploy_agent 会把代码部署到 smoke 环境，做健康检查和访问日志检查。这一步是为了拦截一类典型问题：代码在单测层面没问题，但一跑真实环境就起不来，比如依赖没装对、配置项引用错误。
人工验收阶段是整条流水线里唯一一个人工节点。人不需要看每一行代码，只需要看到一个综合报告：需求卡片、代码改动摘要、自动评审结论、测试报告、预览环境地址。看完之后决定接受还是打回。被打回的会附上具体反馈，重新回到代码生成阶段修正。
3.3 人在环上的几个关键节点设计
这条流水线里的人工介入点很少，但不是“无人值守”，而是把人的时间用在刀刃上。我们刻意保留了三个关键的人工节点：
第一个是需求解析确认。requirement_agent 给出结构化的任务规格书后，产品经理和开发负责人需要确认这份“图纸”没有理解偏。这个环节看起来麻烦，实际上一次确认可以避免后面所有阶段的返工，性价比极高。
第二个是高风险变更放行。只要改动涉及禁用清单里的模块，或者触发了删除代码、修改数据库表结构等危险操作，Harness 会强制把任务挂起，等技术人员人工判断后再放行。
第三个是最终验收。这一步是不可省略的信心闸门。即便前面所有自动校验都过了，我们还是要求至少有一个真人看过预览效果。这里看的不是代码，而是业务结果：这个页面交互是不是符合预期，边界状态有没有处理，数据展示是否正确。
刚开始跑这套流程的时候，团队会觉得多了一层“确认需求规格”的额外负担，不太适应。但跑了两三周之后，大家普遍认可：与其让 AI 闷头写半天再推倒重来，不如最开始花 10 分钟把图纸画清楚。现在这个确认动作已经变成整个团队的默认习惯。
4. 落地半年踩过的坑和完整排查链路
4.1 首坑：AI 生成的代码跑通了测试，业务逻辑却全错
第一个印象深刻的坑，出现在流水线上线后的第二周。当时我们让 AI 开发“小摊商品详情页增加近期销量展示”的需求。AI 一顿输出，单测也写了，类型检查也过了，部署到预览环境后页面上确实出现了销量数字。我打开页面看了一眼，数字是出来了，但那个数字根本不是“近 7 天销量”，而是全部历史销量的总和。问它为什么这么做，它说“任务规格书里没有明确定义‘近期’是一个什么口径，所以我取了默认的累计值”。
这个坑暴露了一个底层问题：任务拆解层如果只检查“字段齐全”而不检查“口径明确”，AI 就会拿自己的默认假设来填补需求里的一切含糊地带。人看到“近期销量”会联想到时间窗口，AI 不会，它只会从你的描述里提取信息，提取不到就自由发挥。
排查的完整链路是这样的：先返回到需求解析阶段看结构化任务规格书，发现“近期”确实没有映射成具体的天数参数，属于上游缺陷；然后我们改了 requirement_agent 的校验规则，要求所有涉及时间、金额、排名的字段必须带出明确的定义；最后把这条反馈加入 review_agent 的检查清单，让它专门盯着这类“语义模糊但数值确定”的字段。
这个案例让我意识到，AI 交付质量的上限，其实取决于需求结构化的下限。AI 不是一个擅长追问“你确定这个口径吗”的协作对象，它在大多数情况下只会把你的文字当成权威输入。所以，想让它可控，前面的拆解环节就必须把所有含糊点全部消解掉。
4.2 二坑：任务链越跑越偏，上下文开始“污染”
另一个印象深刻的问题是上下文污染。我们跑的是一个多阶段流水线，上一阶段的输出会传递给下一阶段作为输入。一开始设计时，每个阶段只传“必要信息”，但后来为了图省事，改成把全量结果都塞给下一步的 Agent。结果几周后开始出现一种诡异的现象：代码生成阶段的行为越来越不稳定，有时候会莫名其妙地参考上一单需求里的代码风格，甚至把上一单新增的工具函数也混进当前这单。
我当时的排查思路是：先怀疑缓存，因为大模型服务通常有上下文缓存，怀疑是不是同一实例复用了之前的 session；后面对比了失败案例和成功案例的完整执行记录，发现一个共同点，所有失败案例的 prompt 里都带着一大段无关的历史代码和旧需求描述。问题不是模型层的缓存，而是 Harness 编排层在上文传递上偷懒了。
根因明确后，我们把所有的阶段间通信改成了“最小上下文原则”，明确每个阶段 Agent 只能收到当前阶段的任务说明和限定范围内的参考文件，其他历史数据一律隔离。整改后这类问题基本绝迹。现在我们的 Harness 管理台里有一个强约束：任何阶段的 prompt 组装都必须显式声明允许引用的上下文范围，不在清单内的内容会被物理隔离，不是“提醒 Agent 忽略”，而是根本不传给模型。
4.3 三坑：把 AI 当全能选手用，权责边界越来越模糊
第三个坑比较隐性，是组织层面的。流水线跑顺之后，团队里开始滋生一种心态：AI 什么都能干，我们只需要当监工。结果就是，产品经理提需求越来越随意，需求卡片写得越来越敷衍；开发人员对 AI 产出的评审也越来越粗，很多本来应该在需求解析阶段发现的问题，一路漏到最终验收才暴露。
后来我们做了一次专项复盘，发现很多返工其实是“上游输入质量差”导致的。人把需求草草丢给 AI，然后期待 AI 自己从烂需求里提炼出准确的产品意图，这既不现实也不合理。
解决思路不是重新让开发手写所有需求，而是给需求输入加一道“准入门槛”：
- 需求卡片必须有明确的效果描述和验收标准，否则 requirement_agent 直接拒绝解析
- 产品经理提交需求前需要对照一张简化版的“自检清单”：是什么、给谁用、怎么验收、改动范围多大
- 最终验收时如果发现 AI 产出和真实业务目标不符，复盘的第一顺位永远是“需求本身是否清晰”，而不是“AI 是不是不够聪明”
把 AI 的权责边界划定清楚之后，团队协作效率反而上来了。因为流程会倒逼每个人对自己的输出负责，而不是把责任推给 AI。
4.4 从坑中沉淀的通用排查方法论：让每一步都可观测
把这些坑串起来看，我们最终沉淀出来一套适用于 AI 交付问题的排查方法，核心就一句话：让每一步都可观测，让每个错误都能关联到具体阶段。
现在排查 AI 交付问题，我们不看最终失败结果本身，而是按这个链路去查：
第一步，先看失败发生在哪个阶段，是需求解析、代码生成、自动校验，还是部署验证。不同的失败位置对应的根因类型完全不同，这一步能快速缩小范围。
第二步，回放该阶段 Agent 收到的输入内容。重点看输入里有没有引入不该出现的上下文，有没有模糊不清的任务描述，有没有缺失必要的规格信息。
第三步，查看 Agent 在不同候选方案上的选择轨迹。这一步依赖 Harness 的审计回溯层，它可以记录 Agent 在思考过程中尝试过哪些方向，最终为什么选择了当前这条路径。
第四步，再把校验结果和任务规格书做对比，确认是校验标准本身太宽松，还是产出确实偏离了规格。
这套方法论现在沉淀成了一份团队内部的《AI 交付问题排查手册》，每个新加入的成员都会先过一遍。它不能解决所有问题，但能保证大多数问题都有章可循，不会出现出了事只能干瞪眼或者从头到尾重跑一遍的窘境。
5. 资源和计划的边界：现在能用 Harness 做到什么程度
5.1 得物小摊当前的落地效果
流水线稳定运行大半年后，团队自己做了个内部统计。对比改造前，在标准页面类需求上，交付周期从平均 3 到 5 天压缩到 1 天以内；单次需求的人工介入时长从原来的 6 到 8 小时降低到 1 到 1.5 小时；需求的返工率从 30% 左右降到了 10% 以下，而且返工的主要原因从“代码写错”变成了“需求口径变更”。
虽然是“标准页面”这类相对简单的需求，但这个数据给了我们继续往前推进的信心。因为团队省下来的时间没有用来摸鱼，而是投到了更复杂的中等确定性任务上，包括涉及权限判断、状态流转、支付模块联调的需求。那些任务的交付体验没法和标准页面比，需要人工介入的频率明显更高，但比起完全人写，效率上还是有相当优势。
5.2 为什么我们不追求“全无人”的交付
经常有人问我，做这个的目标是不是有一天把研发团队缩减到零？我说不是。AI Native 交付的核心价值，不是让人消失，而是把人的精力从低价值的重复劳动中释放出来。
以我们现在的实践来看，AI 在交付链条里承担的是高频、确定性强、需要大量上下文检索的体力活。人做的事情则越来越聚焦在“定义问题”和“判断结果”这两件事上。这个分工逼着团队里每个人都往上游走。比如我们现在要求工程师能写清楚“验收标准”，这其实要求他们对业务目标有更深的理解，光会写代码是不够的。
这也是为什么要强调可控，而不是强调自动化。可控意味着每个环节都有退路，都有检查，都有记录。自动化可能追求的是“过程无人参与”，但可控追求的是“过程出了问题一定能被发现并且能回溯”。
5.3 下一步的扩展方向
这条流水线还远没到终态。我们正在探索三个方向：
第一，把 Harness 从“单需求交付”扩展到“多需求协同编排”。小摊业务经常有批量的小需求同时涌入，现在每条需求各自占一条流水线，整体资源调度不够高效。下一步希望能做一个需求集成的调度器，由 Harness 统一决定哪些需求可以并行、哪些必须串行、哪些可以合并到同一次发布窗口。
第二，让 Agent 具备结果宣讲能力。现在最终验收环节，review_agent 产出的报告还是偏技术视角，产品经理阅读起来有一定的理解成本。我们正在训练一个新的说明 agent，把代码改动、测试报告、风险点转译成业务语言，让验收人能在几分钟内完成判断，而不是追着工程师问细节。
第三，建立基于历史执行数据的质量预测模型。现在 Harness 积累了大量的执行记录，我们打算用这些数据训练一个小模型，在新需求进入流水线之前就预测它在每个阶段可能出现的风险点，提前打上预防针。这个方向还在验证阶段，但值得期待。
从“得物小摊”这个项目里走出来，我个人最大的感受是：AI Native 交付这条路能不能走通，关键不一定在模型选得多强，而是在工程机制愿不愿意为可控性付出设计成本。Harness 给我们带来的最大价值，不是某个惊艳的效果，而是一种“允许 AI 犯错、但错误不会失控”的底气。如果你也在尝试类似的转型，建议不要一上来就想搞一个大而全的 Agent 系统，先找一个场景范围小、迭代节奏快的业务，把可控性这套骨架搭起来，然后让 AI 在骨架上不断长肉，这才是最稳的走法。
