我们大多数开发者每天都在使用人工智能编写代码。我认为更不寻常的是，整个团队以标准化的方式使用人工智能，而不陷入两个极端：要么变得过于官僚化，导致无人遵循；要么各自为政，导致无人知晓自己是否走在正确的道路上。
本文探讨的是中间路线。它不是配置教程（官方文档比任何博客文章都做得更好、更新更及时），也不是成功案例或成果展示，因为我认为目前还没有人拥有这样的成果。这是我在研究了 Anthropic 和 Cognition 发布的相关材料后，从一名从事 Web 开发和分布式系统工作的从业者的视角对问题的解读。
问题很少出在提示词上
最重要的视角转变是，不再将人工智能代理仅仅视为“模型”，而是将其视为模型及其周围的支持设施。这种支持设施在文献中有一个名称，称为“ harness ”（驾驭层/支撑框架）。它包括工具、检查机制、你提供的上下文、你施加的限制，以及在模型出错时纠正它的反馈循环。
当一次人工智能会话效果不佳时，许多人会立即归咎于模型或提示词。然而，在我看来，问题往往出在支撑框架上：缺乏关于代码如何运作的上下文，没有测试来验证是否有内容被破坏，模型无法自行验证其工作成果。这与服务在生产环境中表现不佳时的逻辑相同，原因不在于请求代码本身，而在于缺少超时设置、重试机制以及能提前揭示问题的监控指标。
请记住“ harness ”这个词，它是围绕人工智能的基础设施，而我们接下来要讨论的大部分内容都是构建它的方法。让我们从它允许做出的最实际的决定开始。
自主性应遵循可验证性，而非任务难度
人们的本能是在简单任务中给予人工智能更多自主权，而在困难任务中给予较少自主权。然而，我认为轴心应该不同，应侧重于在可验证的工作中给予更多自主权，在不可验证的工作中给予较少自主权。
一个具有良好测试覆盖率的服务为代理提供了一个客观的反馈循环：它编辑代码，运行测试，查看是否出错，然后进行修正。你可以大量委托任务并审查结果。相反，一个没有测试的服务无法提供这种循环，此时人工智能可能会在无人察觉的情况下朝着错误的方向加速，因为没有任何机制表明行为发生了改变。在这种情况下，人工智能最有价值的用途不是生成新功能，而是生成捕捉当前行为的测试，从而将一个模糊不清的服务转化为可验证的对象。在信任该工具之前，先用该工具偿还技术债务。
然而，可验证性并非凭空而来：它是你构建的支撑框架的一部分。最简单的方法是在代码仓库根目录下创建一个文件，即著名的 CLAUDE.md（如果你正在使用 Anthropic 的产品），向代理描述项目、如何构建、如何运行测试、相关规范以及禁止触碰的内容。大致如下：
# 服务名称
用一句话描述其功能。主要技术栈。
## 命令
- 构建、模块测试、本地启动
## 规范（不可协商）
- 标准错误处理、边界验证等。
## 未经人工批准不得触碰
- 数据库迁移、公共接口契约、支付流程
这看起来非常简单，但事实并非如此。该文件是未来所有人工智能会话的输入素材，也是新员工入职的基本文档。然而，它需要始终保持最新状态
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
