领先的 AI 智能体
让 AI 智能体构建项目前，我会准备的 5 件事
跟 AI 智能体协作，很多决定在敲下第一条提示词之前就做完了：它们需要什么上下文、该遵循哪些模式、做出来的东西怎么融入项目。目标并不是搭一套完美的编排系统，然后把整个项目甩给 AI。就我个人而言，我始终希望深度参与——搞清楚正在构建什么、引导架构方向、对最终结果负责。智能体帮我干活，但方向由我来把控。
这篇文章里，我会讲讲自己作为亲力亲为的开发者，是怎么带领 AI 智能体的——从建立基础模式和规则，到设置检查机制，让自己始终跟项目保持紧密连接。
定义技术栈及其规则
在让 AI 智能体写代码之前，我会先定好：项目用哪些技术和依赖包、怎么用、代码按什么风格写。这些决定会整理成一套项目规则，交给 AI 智能体。
规则放在仓库根目录的指令文件里，智能体每次开始会话时都会加载。内容包括：
- 技术栈及其版本
- 如何构建和运行测试
- 编码规范
- 架构边界
- 我希望智能体避开哪些做法
这个文件我写得很短。它不记录所有细节，而是一个入口：指向更详细的规则文件，以及针对特定任务的技能，这样任务需要更多信息时，智能体知道去哪儿找。
下面用一个简化例子说明这个思路。
这不是从真实项目里拿来的，只是为了展示结构：
# 项目规则
## 技术栈
- 主要语言和框架，固定版本号
- 只使用已批准的包；新增依赖前先询问
## 构建与测试
- 每次提交前运行完整测试套件
- 构建和测试通过才算完成任务
## 约定
- 每个模块一个文件夹，放在 src/module/ 下
- 功能模块通过定义好的接口通信，不要直接访问彼此内部实现
## 禁止
- 全局状态和隐藏依赖
- 在 UI 或控制器层写业务逻辑
## 更多
- 详细规则：docs/rules/
- 技能：create-module、commit-changes
这样做的目的是，在代理开始做实现决策之前，把我的工程期望明确下来。
构建一个小型参考实现
把任务交给 AI 代理之前，我会先在项目里建一个小的参考实现，包含我希望使用的文件夹结构、编码和命名模式。这些示例展示了我期望某一类功能怎么构建：代码放哪里、职责怎么划分、用哪些已有的抽象、各部分怎么连接。它给代理提供了一个具体的模式，基于它实际要工作的项目。
“遵循项目架构”可以有多种理解。一个能跑起来的示例让这些期望变得可见。它也帮我在让代理把决策应用到别处之前，先检查自己的决策是否合理。这为后续任务提供了统一的起点。代理可以根据每个功能调整实现，同时保留我已经确立的架构决策。
把重复工作变成可复用的技能
参考实现稳定下来后，我开始注意到自己的提示词里有规律：我总是在重复解释同样的事情。文件放哪里、继承哪个基类、遵循什么命名约定、怎么检查结果。同一套指令写到第三遍的时候，我就会把它变成一个技能。
“第一次做某件事，直接做就行。第二次做类似的事，你会对重复感到不爽，但还是照做。
再次做类似的事情时，你就该重构了。—— Martin Fowler 引用 Don Roberts（《重构：改善既有代码的设计》）
技能（skill）是一组简短的指令，当任务匹配时由 agent 加载，比如「创建一个新模块」。它不教 agent 怎么写代码，而是告诉 agent 这个项目期望这类工作该怎么做。我写的技能通常会回答四个问题：
- 什么时候适用？—— 说明它覆盖的任务类型。
- 模式在哪里？—— 指向参考实现的位置。
- 什么不能变？—— 这些是光读代码看不出来的约定。
- 怎么算完成？—— 结果必须通过的检查项。
下面是一个可能的写法。再次强调，这只是示例，不是某个真实项目里的文件：
# create-module
## 使用时机
向项目中添加一个新的自包含模块。
## 模式
参考 src/modules/example-module/ 作为范本。
## 不可变更
- 在中央注册表中注册该模块
- 仅通过其公开接口对外暴露
## 完成条件
- 模块的测试通过
- 不直接依赖其他模块
我是故意写得这么精简的。技能并不复制参考代码，只是指向它。如果我把它抄一遍，两份副本迟早会漂移，到时候 agent 读到哪份就按哪份办。只保留一份权威源，我每次改进参考实现，未来的所有任务都能受益。
每一层各有分工。规则定义什么可以做；参考实现展示「做得好」长什么样；技能把这两者跟某一类具体任务接上。
最后一个问题——怎么算完成——不该只是技能里的一句话。这才是真正跟 agent 「握手」的地方。
定义验证 —— 与 AI 握手
黑盒测试关注系统做了什么，白盒测试关注它是怎么做到的。配合 agent 干活时，两者我都需要。
我现在读的代码比以前少多了。很多任务里，我把结果当成黑盒：定义输入、定义预期输出，再写一组测试来证明行为正确。只要这些测试通过，我就不必逐行审查。
但测试通过只能说明代码能跑，不代表它符合项目。这正是白盒检查仍然重要的原因。我不会通读全部代码，只检查决定架构的部分：代码放在哪里、用了哪些抽象、怎么跟系统其他部分衔接。规则和参考实现给这种审查提供了明确标准。所以在动手实现之前，agent 会先带我过一遍它的方案。配合测试，它会告诉我：打算改动架构的哪些部分、怎么改，哪些地方需要我介入审查，哪些边界情况可能压垮设计。方案谈妥，agent 才开始动手。如果还有不清楚的地方，就先别写代码，回头一起把设计理清。
把任务拆小，方便审查
“AI 十秒写完代码，代码审查要两周。”——开发者，2026
Agent 一口气能产出大量代码。问题不在于写，而在于审查。如果一处改动大到无法理解，我就没法真正对它负责。所以在写任何代码之前，我会让 agent 先给一份计划，把工作拆成小步骤。计划由我自己调整。每一步只负责一件事，完成后项目仍能正常运行，并且能独立验证。然后一步一步来：我审查结果、提交，之后才继续下一步。每次提交都是一个检查点，下一步出问题时可以安全回退。
结语：做主导者，而不是跟随者
与 AI agent 协作，不是退到一边、把方向盘交给自动化系统，而是作为架构师和技术负责人站出来。清晰的规则、可供参照的范例、应对重复工作的技能、双方认可的验证方式，以及小而可审查的步骤，并不会让 agent 变得完美。但它们能把 agent 的产出，从“需要我费劲解读的东西”变成“我能评估、信任并为之负责的东西”。Agent 让我更快，但不会让我责任更少。关键很简单：定好标准、划清边界、验证结构，执行交给 agent。
- 三人法则（计算机编程）- 维基百科
- 错误的抽象 - Sandi Metz
- 黑盒测试 - 维基百科
- 白盒测试 - 维基百科
- 构建高效的 AI 智能体
- Claude 如何记住你的项目 - Claude Code 文档
- AGENTS.md
- 用 Agent Skills 让智能体应对真实世界
《构建高效的 AI 智能体》最初发表于 Medium 平台的 Dev Genius，读者仍在通过标注和高亮这篇文章来延续讨论。