ai产业链

代码越便宜，验证越值钱：Anthropic 的 Loop engineering 启示

信源：Ryan Peterman｜Claude Code 工程师 Thariq Shihipar 访谈｜2026-09-07

AI 编程正在改变软件生产的组织方式：越来越多的实现工作可以交给模型，工程师开始设计持续组织这些工作的系统。Anthropic 这场访谈最值得关注的变化，就藏在 Loop engineering 里。它指向一个更大的机会：把一次性的开发能力，变成可以持续发现问题、执行修改并检验结果的生产能力。

Thariq 对 Loop engineering 的解释很直接：搭建一个会向 Claude 发出任务的系统。他举过一个具体例子：给功能加入事件记录，让 Claude 每天读取这些事件与改动，再提出改进建议，并强调数据源、技能与验证必须配套。这里的关键是反馈能否改变下一步行动。如果没有记录失败原因、更新上下文或检查实际结果，定时启动和失败重跑很容易只是增加尝试次数。

理解这种变化，可以从一个看似矛盾的事实入手。Anthropic 在 7 月披露，针对 Opus 5、Fable 5 等模型，Claude Code 删掉了超过 80% 的系统提示词，公司编码评估未测出损失；与此同时，验证和代码评审的一部分指导被移入按需调用的技能。减少的是常驻指令，工程能力则通过更合适的接口和加载方式提供。

由此可以看清 Harness 的价值变化。Harness 是模型周围负责工具、权限、状态和验证的运行系统。模型能力增强后，逐条教它怎样写代码的必要性下降；工作时间拉长、影响范围扩大后，环境隔离、结果检查和失败恢复的要求却会提高。让模型少受无效指令干扰，与让系统承担更多责任，可以同时发生。

这也解释了为什么代码生成速度不能直接代表生产率。交付还要经过需求澄清、集成、验收和上线。实现环节加速，其他环节就更容易积压。倘若工程师每天收到更多修改，却仍要逐一重建上下文、猜测设计意图，节省的编码时间便会转化为审阅负担。扩大自主执行范围，需要让系统同时产出可检查的证据。

但“多放一个 AI 裁判”也有边界。Claude Code 当前的 /goal 会在每轮结束后调用另一个模型判断目标是否完成；官方文档明确，这个评估器不能独立读文件或运行命令，只能判断主 Agent 在对话中呈现的内容。因此，测试输出是否真实、是否覆盖验收条件，会直接影响判断质量。

这意味着，验证能力必须包含通向实际运行结果的证据通道。假如执行者和评估者共享同一个错误前提，反复讨论可能让结论越来越自洽，却没有增加正确性。更有价值的反馈来自可复现的失败、真实执行的测试，以及上线后的行为变化。而这些检查还要建立在明确的业务目标上：错误需求也能通过测试，团队仍须判断问题是否值得解决、验收标准是否遗漏了重要约束。循环的质量取决于它每一轮获得了什么新证据。

沿着这个机制往前看，软件团队值得积累的资产也会变化。一套记录业务边界、历史故障和验收标准的测试环境，可以用来判断不同模型生成的实现。未来替换实现可能越来越便宜，而重新弄清“哪些行为必须保持正确”仍然昂贵。由此推演，掌握客户业务语义、运行数据和验证环境的工具，更有机会成为长期使用的基础设施；仅有通用生成能力，较难形成同样的客户黏性。

对 AI 需求而言，这条路径也有扩张意义。可靠闭环降低了每项任务需要占用的人工注意力，一些过去没人手持续处理的小问题，才可能进入自动化范围。单次任务更省算力，与总任务量增长并不冲突。不过，新增尝试必须转化为被接受的结果，才能形成持续付费的理由。

推广这套经验，还要算清组织层面的投入。Thariq 坦言，在 Anthropic，探索自动化即使失败，也能帮助改进产品；普通公司的员工则需要按期交付。访谈约 03:45⁠ 这使两类组织能承受的试错成本不同。对于重复频率低、结果难验收的任务，搭建闭环的投入可能很难收回；流程高频、反馈清晰的工作，更容易率先体现经济价值。

访谈也没有给出公司端到端自主完成工程工作的统一比例。代码由模型生成，仍可能承载着此前大量人工设计与决策。访谈约 09:18⁠ 往后最值得观察的是：单位合格交付所需的人工干预是否持续下降，同时返工与线上故障没有恶化。这个指标走通，Loop engineering 才能把模型能力稳定地转化为企业产能。