系列导读：上一篇我们拆解了大模型的6个根本问题。这一篇，我们把视角从“用AI”切换到“造AI”——如何设计一个真正能在研发流程中稳定输出的智能体。不讲理论框架，只讲我们在项目中验证过的 SOP设计、技能拆分、规则制定和记忆管理 的实操方法。如果你想深入了解前沿的AI Agent技术实践，欢迎关注云栈社区的“人工智能”板块。
前言：为什么你的智能体“不好用”？
很多人搭建智能体的方式是：写一段长长的提示词，塞进去一堆规则和技能，然后期望它能“全自动”完成工作。
结果往往是：
- 前几次表现还行，用着用着就开始“跑偏”
- 换个任务就不行了，鲁棒性极差
- 输出质量忽高忽低，无法稳定复用
根本原因只有一个：没有标准化的 SOP（标准作业程序）。
一、SOP篇：标准化是一切的基础
核心观点
无法 SOP 的操作，不建议交给 AI。
这句话听起来很绝对，但它是我们踩过无数坑后得出的结论。
AI 智能体不是“万能助手”，它是 标准化流程的执行器。你给它的流程越标准，它执行得越稳定；流程越模糊，它越容易“自由发挥”。
研发流程的 SOP 设计
在我们的实践中，研发流程采用 瀑布式管理，编码流程采用 TDD（测试驱动开发）：
graph TB
subgraph 业务流程 [业务流程 - 瀑布式]
A1[需求分析] --> A2[概要设计]
A2 --> A3[详细设计]
A3 --> A4[编码实现]
A4 --> A5[测试验证]
A5 --> A6[部署上线]
end
subgraph 编码流程 [编码流程 - TDD]
B1[写测试用例] --> B2[运行测试-确认失败]
B2 --> B3[编写最小实现]
B3 --> B4[运行测试-确认通过]
B4 --> B5[重构优化]
B5 --> B1
end
A4 --> B1
为什么业务流程用瀑布式？
- AI 需要明确的阶段边界，每个阶段的输入输出必须清晰
- 瀑布式的线性结构更容易被 AI 理解和执行
- 敏捷的迭代循环容易让 AI 在上下文中“迷失”
为什么编码流程用 TDD？
- 先写测试 = 先明确预期，AI 知道“要达到什么效果”
- 红-绿-重构的循环是标准化的，AI 可以稳定执行
- 测试本身就是最好的“验收标准”
SOP 的三个关键要素
| 要素 |
说明 |
示例 |
| 输入定义 |
每步开始前，明确需要什么输入 |
“编码阶段需要：详细设计文档 + 接口定义 + 数据模型” |
| 输出定义 |
每步结束后，明确产出什么 |
“编码阶段产出：源代码 + 单元测试 + 代码注释” |
| 验收标准 |
怎么判断这步做完了、做对了 |
“所有测试用例通过 + 代码覆盖率 > 80%” |
每步确认，拆分成更可控的单元
graph LR
A[大任务] --> B[拆分为子任务]
B --> C[子任务1: 确认输入]
C --> D[子任务1: 执行]
D --> E[子任务1: 自检验收]
E --> F{通过?}
F -->|是| G[子任务2...]
F -->|否| D
实操建议：
- 每个子任务完成后，要求 AI 进行自检
- 自检内容包括：是否满足输出定义、是否符合验收标准
- 不通过则重试，通过则进入下一步
- 每步都需要 AI 反复确认，提高可用性
二、技能篇：小而美的标准化组件
核心观点
技能不是“说明书”，而是“标准组件”。
很多人把技能写成一大段操作说明，试图覆盖所有场景。结果技能越大，AI 越难精准执行。
我们的做法是：将技能高度抽象成标准化的组件模块，每个组件只做一件事，通过组合来实现复杂功能。
技能设计原则
graph TB
subgraph 原则1 [原则一：单一职责]
P1[一个技能只做一件事]
P1A[❌ “完整开发流程技能”]
P1B[✅ “数据库设计技能” + “API设计技能” + “测试生成技能”]
end
subgraph 原则2 [原则二：小样本学习]
P2[包含Good Case和Bad Case]
P2A[Good Case: 正确示例]
P2B[Bad Case: 错误示例]
P2C[边界Case: 特殊情况处理]
end
subgraph 原则3 [原则三：可组合]
P3[技能之间可以串联组合]
P3A[技能A的输出 = 技能B的输入]
P3B[通过文件/文档传递上下文]
end
subgraph 原则4 [原则四：可纳入流程]
P4[技能可以嵌入SOP流程]
P4A[在SOP的特定步骤触发特定技能]
P4B[技能执行结果反馈给SOP流程]
end
技能拆分示例
以“代码质量保障”为例，我们不是写一个“代码质量技能”，而是拆成 4 个独立技能：
| 技能名称 |
职责 |
输入 |
输出 |
code-style |
代码风格检查 |
源代码 |
风格问题列表 |
unit-test-gen |
单元测试生成 |
源代码 + 测试框架 |
测试代码 |
security-check |
安全漏洞扫描 |
源代码 |
安全问题列表 |
perf-review |
性能审查 |
源代码 |
性能优化建议 |
组合使用：
SOP步骤 “编码完成” → 依次触发：
code-style → unit-test-gen → security-check → perf-review
→ 汇总所有检查结果 → 生成质量报告
Good Case / Bad Case 示例
在技能中加入示例，是提升 AI 执行精度的最有效手段：
## 技能：RESTful API设计
### Good Case ✅
GET /api/users # 获取用户列表
GET /api/users/123 # 获取单个用户
POST /api/users # 创建用户
PUT /api/users/123 # 更新用户
DELETE /api/users/123 # 删除用户
### Bad Case ❌
GET /api/getUsers # 动词不应出现在URL中
POST /api/users/create # 冗余路径
GET /api/user-list # 连字符风格不统一
PUT /api/updateUser/123 # 动词不应出现在URL中
技能加载策略
不是所有技能都需要一直加载。我们采用 按需加载 策略：
graph LR
A[任务开始] --> B{判断任务类型}
B -->|需求分析| C[加载: 需求拆分技能]
B -->|编码| D[加载: 代码规范 + TDD技能]
B -->|测试| E[加载: 测试生成 + 测试执行技能]
B -->|部署| F[加载: 部署检查 + 配置管理技能]
C --> G[执行任务]
D --> G
E --> G
F --> G
G --> H[任务完成， 卸载技能]
三、规则篇：项目规则5S + 个人规则5S
核心观点
规则是智能体的“护栏”，不是“束缚”。
好的规则体系能同时提高 开发者效率 和 输出稳定性。
项目规则5S
| S |
含义 |
示例 |
| Standard（标准） |
采用公司/团队规范 |
“API响应格式遵循公司RESTful规范v2.0” |
| Structure（结构） |
项目目录和文件结构 |
“Controller放在web层，Service放在biz层” |
| Style（风格） |
代码风格统一 |
“使用Google Java Style，缩进2空格” |
| Security（安全） |
安全相关强制要求 |
“所有外部输入必须校验，SQL必须用参数化查询” |
| Scope（范围） |
明确能做和不能做的事 |
“禁止直接修改数据库，必须通过迁移脚本” |
个人规则5S
| S |
含义 |
示例 |
| Shortcut（快捷方式） |
个人常用缩写和别名 |
“当我说‘跑一下’，意思是执行mvn test” |
| Sequence（顺序） |
个人工作习惯顺序 |
“我习惯先写Service层，再写Controller层” |
| Specific（特定偏好） |
个人技术偏好 |
“日志框架用SLF4J + Logback，不用Log4j” |
| Summary（总结习惯） |
输出格式偏好 |
“每次完成任务后，输出一份简要的变更摘要” |
| Sanity（理性检查） |
需要AI特别注意的事项 |
“修改代码前先问我确认，不要直接改” |
规则文件的最佳实践
项目根目录/
├── .ai/
│ ├── rules.md # 项目规则（精简，< 100行）
│ └── forbidden.md # 禁止事项清单
├── .ai-skills/ # 技能目录（规范放在这里）
│ ├── code-style.md
│ ├── tdd.md
│ ├── api-design.md
│ └── db-design.md
└── ...
关键原则：
- 项目规则尽量少：只放强制性的、不可违反的规则
- 规范放在技能里：详细的操作规范通过技能按需加载
- 禁止事项单独管理：明确列出 AI 不能做的事项
四、记忆篇：让智能体“记住”经验
核心观点
AI的记忆不是靠“聊出来的”，而是靠“管出来的”。
大模型的对话记忆是不可靠的。真正的“记忆”应该通过 文件系统 来管理。
记忆管理三层架构
graph TB
subgraph L1 [第一层：即时记忆]
M1[当前对话上下文]
M1A[当前任务相关]
M1B[临时性、易丢失]
end
subgraph L2 [第二层：工作记忆]
M2[项目文件中的文档]
M2A[设计文档、接口文档、架构决策]
M2B[持久化、可检索]
end
subgraph L3 [第三层：经验记忆]
M3[经验库/知识库]
M3A[历史问题的解决方案]
M3B[最佳实践、踩坑记录]
end
L1 -->|任务完成后归档| L2
L2 -->|提炼总结后入库| L3
L3 -->|新任务时检索参考| L1
实操：问题追踪与经验沉淀
Step 1：发现问题
在项目规则中增加一条：
当AI处理过程中出现以下情况时，记录到 issues-log.md：
- 生成的内容不符合预期但AI自行修正了
- 需要多轮对话才能解决的问题
- AI遗漏了某些要求
Step 2：记录问题
## issues-log.md
### 2025-03-15
- **问题**: AI生成的SQL未使用索引，导致慢查询
- **原因**: 技能中未包含“查询必须考虑索引”的规则
- **解决**: 在db-design技能中添加索引设计规范
- **归类**: 技能完善
Step 3：定期回顾
每周回顾 issues-log.md，识别高频问题，更新技能和规则。
技能自动识别：是否需要纳入标准
我们设计了一个“规则审查”机制：
graph LR
A[任务执行过程中] --> B{发现重复性问题?}
B -->|是| C[记录到issues-log]
B -->|否| D[继续执行]
C --> E{出现3次以上?}
E -->|是| F[评估是否纳入技能/规则]
E -->|否| G[保持观察]
F --> H[更新技能或规则文件]
H --> I[通知开发者确认]
五、智能体架构全景图
把以上所有内容整合起来，一个高质量研发智能体的完整架构如下：
graph TB
subgraph 控制层 [总控层]
CTRL[总控提示词协调所有子智能体]
end
subgraph 流程层 [SOP流程层]
S1[需求分析Agent] --> S2[设计Agent]
S2 --> S3[编码Agent]
S3 --> S4[测试Agent]
S4 --> S5[部署Agent]
end
subgraph 技能层 [技能层]
SK1[代码规范]
SK2[TDD流程]
SK3[API设计]
SK4[数据库设计]
SK5[安全检查]
SK6[文档生成]
end
subgraph 规则层 [规则层]
R1[项目规则5S]
R2[个人规则5S]
R3[禁止事项]
end
subgraph 记忆层 [记忆层]
M1[设计文档]
M2[接口文档]
M3[问题日志]
M4[经验库]
end
CTRL --> 流程层
流程层 -->|按需调用| 技能层
流程层 -->|始终遵守| 规则层
流程层 -->|读写| 记忆层
写在最后
打造一个高质量智能体，核心不在于提示词写得多“聪明”，而在于流程设计得多“标准”。
总结成一句话：
SOP是骨架，技能是肌肉，规则是神经，记忆是大脑。
四者缺一不可，但优先级是：SOP > 技能 > 规则 > 记忆。
先把流程标准化，再拆分技能组件，然后制定规则护栏，最后建立记忆体系。这个顺序不能乱。
下一篇预告：《AI智能体实战笔记（三）：你的专业上限决定AI的高度》——智能体造好了，但用得好不好，取决于使用者的专业能力。下一篇我们聊聊开发者如何通过“提示词反向提问”和“7步学习法”来提升自己驾驭智能体的能力。
发表于 前天 04:21
|
查看: 10|
回复: 0
