• 作者: 作者
  • 时间:
  • 分类: 文章

在大模型接入日常开发的今天，不知道大家有没有遇到过这种尴尬：AI 生成代码的速度虽快，但风格千奇百怪，甚至有时候完全无视项目已有的规范，最后花在重构和审核上的时间比手写还多。

最近看到一个很有意思的话题：“Harness Engineering（AI 程序员工程化）”。简单来说，就是怎么给那个狂奔的 AI 套上缰绳，让它老老实实按照我们既定的路线干活。今天就来聊聊这个事情，看看是不是有必要每个人都从头造轮子，以及有没有现成的“现成饭”可以吃。

为什么我们需要“缰绳”？

现在的 AI 编程助手（比如各种 Copilot 类工具）大多很“傻白甜”，你给它个简短的 prompt，它就噼里啪啦给你一堆代码。但在实际企业级项目 or 复杂开源项目中，我们需要的不只是代码，而是符合规范的代码。

这就是 Harness Engineering 要解决的问题。它的核心目的就是把项目规范、开发流程固化下来，防止 AI 瞎写。

CC 比 Codex 更懂工程化？

AI Coding Concept

AI 编程助手示意图

在具体的技术选型上，社区里有个很有意思的对比：CC（可能是指某种基于约束的架构）的设计理念其实比 Codex 更适合做 Harness。

为什么这么说？因为它引入了一整套工程化的概念，听起来就很有后端开发的味儿：

  • Rules（规则）： 硬性规定，比如“必须使用 TypeScript”，“禁止使用 var”。
  • Skills（技能）： 定义 AI 能做什么，比如“只会写 React 组件，不会写 SQL 语句”。
  • Hooks（钩子）： 在代码生成的关键节点介入，比如生成前检查上下文，生成后跑个 Lint。
  • MCP (Model Context Protocol)： 统一上下文协议，确保 AI 能准确读取到项目的文档和结构。
  • Subagents： 子代理系统，像微服务一样拆解任务，处理复杂逻辑。

这一套组合拳下来，AI 就不再是一个随性的“艺术家”，而是一个听话的“流水线工人”。

真的要自己造轮子吗？

回到原帖的灵魂拷问：大家真的有必要在项目中从零搭建这些吗？

我的答案是：尽量别。

软件开发这么多年，我们早就学到了一个教训：能用成熟框架就别手写。如果每个人都要自己实现一套 Rules 引擎和 Hooks 机制，那项目的复杂度会指数级上升。

目前社区里已经有一些针对 AI 工程化的成熟框架推荐，我们可以重点关注这两个：

1. Superpowers

如果你希望快速给项目加上“AI 护盾”，Superpowers 是一个很值得探索的方向。它通常专注于提供一套预定义的能力包，让你能像配置插件一样约束 AI 的行为。对于不想在底层架构上花费太多时间的团队来说，这是一个比较轻量的选择。

2. Spec-kit

这就属于重兵器了。Spec-kit 更偏向于规范性管理，它能让你定义非常详细的代码规范（Spec），并强制 AI 执行。如果你的项目对代码质量、安全性有极高的要求（比如金融或者基础设施相关），这种能深度定制的框架会非常适合。

实操建议：如何起步？

如果你想在新项目中尝试这种“工程化 Harness”，我建议按这个路径走：

  1. 先定规则： 不要上来就搞框架。先把项目的 .eslintrc、.prettierrc、Contributing Guidlines 整理清楚。这是给 AI 喂的“基础饲料”。
  2. 引入 MCP： 尝试使用支持 Model Context Protocol 的工具，确保 AI 能看到项目的全貌，而不是在盲写。
  3. 小步试用 Subagents： 不要试图让一个 AI 干所有事。试着把任务拆分，比如专门的“文档生成 Agent”和“测试用例 Agent”，通过简单的 Orchestrator 调度。
  4. 评估框架： 在团队规模扩大后，再考虑引入 Superpowers 或 Spec-kit 来管理这些散乱的配置。

最后

AI 赋能开发是大趋势，但“失控”的风险也是真实存在的。与其等到代码库变成“屎山”再去重构，不如在一开始就搭建好 Harness。既然有现成的框架和理念可以借鉴，我们何不站在巨人的肩膀上，让 AI 成为真正的“超级工程师”，而不是“随机代码生成器”呢？

不知道大家在项目中有没有用过类似的工程化手段？或者有其他好用的框架推荐？欢迎在评论区交流！

标签: none

评论已关闭