今天群里有人问，现在把时间花在 Harness 搭建上，是不是一个好的选择。
群里大部分人的反应都比较一致：不是特别好的选择。我自己的感受也差不多。不是因为 Harness 不重要，而是因为多数人现在纠结的 Harness，很可能不是他们当下最该解决的问题。
这件事让我想到鸭哥之前说过的一个词：外包。
这个词听起来很朴素，甚至有点不够“技术”。但我现在越来越觉得，它可能是 AI Coding 进入下一阶段之后，很多人最缺的一种能力。
AI 越强，人越容易重新变成手工业者
过去几个月，AI Coding 的能力确实在快速变强。模型能处理更长的上下文，工具能跑更复杂的任务，Agent 能在一个 repo 里来回改文件、跑测试、修错误。以前你只敢让它写一个函数，现在你会开始让它做一个功能，甚至做一个完整模块。
能力变强以后，一个很自然的冲动就出现了：既然它能做，那我就让它从零做。
页面自己写，框架自己搭，评测自己做，Harness 自己建。以前人写代码成本高，大家还会认真想想这个东西到底该不该自研。现在 AI 把第一版代码的成本打得很低，反而让很多人失去了 build or buy 的判断。
这是一个很隐蔽的陷阱。
AI 让执行变便宜了，但没有让维护变便宜。它能帮你把第一版写出来，但后面的理解、迁移、升级、验证、排错，还是会回到你身上。尤其是 Harness 这种东西，一旦你自建，它就不是一个功能，而是一条长期责任链。
所以最危险的不是 AI 不够强，而是 AI 足够强，让你误以为什么都可以自己搭。
Harness 当然重要，但它不是所有人的第一优先级
我并不是反对 Harness。
Agent 要从 Demo 变成真正可用的系统，肯定需要一整套中间层：状态怎么保存，工具怎么调用，权限怎么控制，失败怎么恢复，过程怎么记录，效果怎么评估。这些问题每一个都不性感，但每一个都决定 Agent 能不能长期稳定运行。
成熟团队确实需要 Harness。平台团队要做 Agent 发布门禁，需要评测集、回归门槛、灰度机制。业务 Agent 上线给多人使用，需要可回放、可审计、可回滚。公司要比较不同模型、不同 prompt、不同工具配置，也需要稳定的评测框架。
但这里有个前提：你得先有稳定的任务分布。
如果你现在每次让 AI 做的事情都不一样，没有固定任务集，没有失败样本库，没有明确 KPI，没有持续回归需求，那你搭出来的 Harness 服务谁？它评测什么？它优化什么？它证明什么？
很多人现在的问题不是缺 Harness，而是缺一个清楚的任务定义和验收标准。你还不知道什么叫做“做对了”，却开始搭一套系统来评估“做得好不好”。这个顺序反了。
这就像店还没开，先花半年造收银系统。收银系统当然重要，但它不是第一天最该解决的问题。
所谓外包，不是把责任甩出去
我理解的外包，不是把事情丢给别人，也不是降低要求。
它更像现代软件工程里的依赖管理。通用的东西，尽量交给成熟模块。真正和你业务强相关、和你判断强相关、和你责任强相关的东西，自己留下。
模型能力，外包给模型厂商。Agent runtime，优先看成熟框架或公司内部平台。评测基准，先看现成的 eval 工具和开源 harness。部署、监控、权限、审计，能接已有基础设施就不要重做。
那人留下什么？
留下问题定义，留下上下文，留下方案选择，留下结果验收。
这几件事才是 AI Coding 时代人的核心价值。你知道这个问题为什么重要，知道输入怎么描述才不偏，知道输出长什么样才算对，知道哪些风险不能接受，知道这个方案放到你的业务和组织里会不会出问题。
AI 擅长执行，但它不天然知道你的业务边界。成熟工具擅长提供通用能力，但它不替你承担最终判断。
所以外包不是放弃控制权。相反，它是为了把控制权从“我能不能写出这段代码”，转移到“我能不能判断这套方案是否正确”。
AI Coding 有两个层级
我现在越来越觉得，AI Coding 至少有两个层级。
第一个层级是执行层 AI Coding。你让 AI 一行一行写，把功能做出来。这个阶段很重要，它让很多过去不会写代码的人，第一次可以把想法变成可运行的东西。
第二个层级是架构层 AI Coding。你让 AI 帮你判断：这个问题有没有成熟解法，同类开源项目怎么做，官方文档推荐什么架构，别人踩过什么坑，哪些模块该接，哪些模块该买，哪些地方必须自己保留控制权。
这两个层级的差别很大。
执行层 AI Coding 让你更快地产生代码。架构层 AI Coding 让你更少地产生错误代码。前者提升速度，后者提升方向。
如果只停留在第一层，人会越来越像一个指挥 AI 干活的包工头：这里加个功能，那里补个模块，缺什么搭什么。项目看起来推进很快，但底层越来越重。
进入第二层以后，问题会变成：这个模块是不是我的核心竞争力？有没有成熟方案？我真正需要掌控的是接口、数据、流程，还是底层实现？
这个判断一旦做对，后面少写的代码，比多写的代码更值钱。
更好的路径：先集成，再沉淀，最后才平台化
如果今天有人问我该不该投入 Harness，我会建议他先按这个顺序走。
第一步，先用现成工具跑通真实问题。不要先搭系统，先让 AI 真正在你的场景里完成几次任务。
第二步，把验收标准写清楚。不是“看起来不错”，而是哪些输入要覆盖，哪些输出不能错，失败了怎么发现。
第三步，保留运行轨迹和失败样本。不要急着抽象，先积累足够多的真实失败。真正有价值的 Harness，往往不是从设计文档里长出来的，而是从重复失败里长出来的。
第四步，当失败模式开始重复，再做轻量机制。比如固定测试集、简单回归脚本、日志结构化、人工 review 表单。
第五步，只有当这些轻量机制变成瓶颈，再考虑平台化。
这个顺序听起来慢，其实更快。因为你没有在一开始就背上一个大系统，也没有为了一个还没被验证的问题，提前支付复杂度。
AI Coding 的高级用法，不是让 AI 写更多代码，而是让 AI 帮你识别哪些代码根本不该写。
回到群里的那个问题
所以，如果问“现在把时间花在 Harness 搭建上是不是好选择”，我的回答会是：看你处在哪个阶段。
如果你是平台团队，有稳定场景，有上线责任，有评测闭环，那当然值得做。Harness 是基础设施，不做迟早要还债。
但如果你只是个人 AI Coding 使用者，或者团队还在探索阶段，那现在最值得投入的不是从零搭 Harness，而是训练自己做三件事：定义问题，寻找成熟模块，设计验收闭环。
这三件事比写代码更难，也更值钱。
AI 时代的工程能力，不会只体现在“我能造出什么”。它还会体现在“我知道什么不该自己造”。过去不会写代码是一种短板，未来不懂外包才是一种短板。
真正拉开差距的人，不是最会让 AI 干活的人，而是最会给 AI 和外部系统分工的人。