如何停止手工编写代码，开始为神经网络设计马具

最近我发现自己有一种奇怪的感觉。你坐在编辑器里，启动一个像 Claude Code 或 Cursor 这样的智能体，给它一个任务，十分钟后你就在整理一堆凭空捏造的函数和破碎的类型。试图写一个五页的系统提示词通常会让事情变得更糟：模型在第三步就忘了指令开头的内容。

事实证明，在 OpenAI、Anthropic 和 Cursor 周围的工程社区中，这个问题已经被正式定义为一门独立的学科。它被称为 Harness Engineering，可以翻译为为智能体设计马具或缰绳。

仓库 deusyu/harness-engineering 汇集了关于这个主题的广泛知识库：概念分析、数十篇来自 Martin Fowler、LangChain 和 Bun 创建者的英文文章翻译，以及在自己的项目中实施这种方法的就绪模板。

这个想法从何而来

如果在传统开发中是人写代码、机器执行，那么随着自主智能体的到来，这条链条发生了变化。人制定约束和游戏规则，神经网络写代码，环境运行检查并向智能体返回反馈。

关键在于，工程师不再是每一行代码的作者。工程师的主要产品变成了一套约束系统：配置文件 AGENTS.md、自定义 linter、结构化测试，以及 CI 中的严格关卡。

仓库引用了一个团队的真实实验数据：在 5 个月的时间里，一个 3-7 人的团队合并了约 15,000 个 pull request，总计近一百万行代码，平均每人每天关闭 3.5 个 PR。大部分生成工作是在夜间六小时的会话中完成的。

仓库作者将这种方法分解为几个应用层面的概念。

任何不在 git 仓库里的东西对智能体来说都不存在。你的 Zoom 会议、Slack 中的架构讨论，或者 Google Docs 中的草稿都不会进入模型的上下文。

如果你决定更改 API 签名或商定了文件夹结构，这应该作为版本化文件存在于仓库中。任何规范和任务计划都立即提交到一个分支。

在设置智能体开发时，一个常见的错误是创建一个包含所有项目指令的巨型系统文件。模型会被冗长的提示词淹没。

相反，使用一个约 100 行的 AGENTS.md 文件。它充当目录或地形图，根据任务指向智能体应该查看哪些子目录以获取详细信息。每个子目录都包含自己的本地 AGENTS.md。这个原则被称为渐进式上下文披露。

文档中的文本规则很快就会过时，智能体往往忽略或误解它们。而 linter 和单元测试不会过时。

不写冗长的架构风格描述，而是编写自定义 linter。最有趣的部分是：这些 linter 中的错误消息立即包含清晰的修复说明。智能体运行检查，捕获 linter 错误，阅读提示文本，然后自行重写有问题的代码部分。

面向智能体的代码可读性和熵管理

选择库时，优先考虑稳定、有完善文档且行为可预测的技术。如果一个库太复杂或使用了黑暗的元编程魔法，智能体就会不断踩坑。有时从头实现一个简单的内部模块，比让神经网络猜测一个不透明外部包的行为更容易。

此外，智能体喜欢复制现有代码库中的坏模式。为了防止仓库腐化，特殊的重构智能体在后台运行，它们的任务简化为寻找偏离标准的地方并创建修正性的 PR。

项目 deusyu/harness-engineering 的引人之处在于，它本身就是用所描述的原则构建的。

在仓库内部，运行着一个严格的 scripts/check-consistency.sh 脚本，通过 pre-commit hooks 和 GitHub Actions 触发。该脚本检查十三个级别的完整性：

添加新材料的过程通过专门的 Claude skill 自动化，智能体执行文章的初始解析和格式化，而人类只作为最终审查者。

这个项目适合谁

如果你正在独自编写个人项目，或者想在团队中与 Cursor、Claude Code、Aider 或本地模型建立高效工作，这个仓库值得收藏。

这里没有魔法按钮或现成的二进制文件。这是一本手册和工程经验的集合，解释了为什么你的提示词会随着距离增加而失效，以及如何配置仓库以使神经网络带来收益而不是把代码库变成垃圾场。

最简单的学习起点是 concepts/ 目录中的文件，然后查看项目根目录中 AGENTS.md 的实现，为你自己的工作仓库尝试类似结构。