1. 从完美架构到提示词本质:AI工程化的认知转变
在AI辅助开发领域,我们团队经历了一次深刻的认知转变。最初,我们设计了一个看似完美的三层架构系统:Command层作为入口,Agent层负责决策,Skill层执行具体任务。这个架构包含了严格的九步工作流,从需求录入到需求关闭,每一步都有专门的Agent和Skill负责,甚至设计了标准的JSON协议用于Agent间通信。
然而,当我们尝试用这个架构解决实际问题时,发现了一个根本性矛盾:为了修改配置文件中的一行代码,需要花费15分钟走完整个流程。而直接在聊天框中输入简单的提示词,AI在5分钟内就完成了同样的任务。这个对比让我们开始质疑:复杂的架构是否真的提升了效率?
关键发现:当AI需要花费更多精力理解流程而非理解业务时,架构本身就成为了障碍。
2. 两个产品的启示:简单性的力量
2.1 NotebookLM的极简设计
Google的NotebookLM给我们上了重要一课。它的界面简单到令人惊讶:左栏是来源材料,中栏是对话,右栏是输出。没有复杂的"智能路由"或"多Agent协作",却能高效帮助用户消化大量信息。
NotebookLM的成功公式可以简化为:
code复制输出 = f(来源, 输出格式)
其中f代表LLM的理解和生成能力。这个产品告诉我们:当输入组织得当,LLM本身的能力已经足够强大,不需要额外的架构复杂性。
2.2 Claude Code的反直觉实践
Anthropic的Claude Code团队分享的经验更具冲击力。他们最初也尝试创建复杂的工具图,但发现"做的越多,系统变得越不可靠"。最终他们选择了相反路径:
- 最小化工具数量:使用少量表达能力强的工具,而非大量精确的小工具
- 信任模型能力:让模型自行决定如何使用这些工具
- 并行工作流:同时运行10-15个Claude实例处理独立任务
Claude Code创作者的一句话特别发人深省:"最好的工具是你不知道它存在的工具。"我们的架构恰恰相反——用户时刻能感受到流程的存在,这本身就是设计失败的信号。
3. 新思维:文本作为通用接口
基于这些观察,我们形成了全新的工程化思维:
| 维度 | 旧思维 | 新思维 |
|---|---|---|
| 规范执行 | 开发工具强制执行 | 写成提示词让AI理解 |
| 状态管理 | 设计元数据系统 | 保存到文件下次读取 |
| 经验沉淀 | 开发"经验管理Agent" | 写文档放到context目录 |
| 意图路由 | 开发"路由Agent" | 在提示词里写决策逻辑 |
核心观点:不需要为AI开发复杂工具,只需将知识结构化地写成文本。例如,原本需要开发pre-commit Skill来强制执行lint检查,现在只需在AGENTS.md中写明:
code复制# 代码提交规范
- 提交前必须运行`make lint`
- lint不通过不要提交,先修复问题
AI会自动理解并执行这些规范,无需额外代码实现。
4. 落地三原则
4.1 文档即记忆(Dual Use)
AGENTS.md同时服务于人类和AI,既是新人的入职手册,也是AI的核心记忆。写文档时要想象在给一个聪明但对项目一无所知的新同事讲解——这个同事可能是人类,也可能是AI。
4.2 先跑起来
从最简单的提示词开始,让AI辅助工作能用起来。Claude Code的"计划模式"工作流是绝佳范例:
- 与Claude讨论直到满意其计划
- 切换到自动接受编辑模式
- Claude通常可以一次完成
关键在于:不是设计复杂的"计划Agent",而是用对话自然形成计划。
4.3 自然演进
观察团队如何使用(甚至"滥用")工具,将高频模式固化为能力。Claude Code团队的建议:"构建一个足够开放的产品,观察人们如何'滥用'它,然后为此而构建。"
5. 最简实践:一个文件搞定AI工程化
5.1 基础配置
在项目根目录创建AGENTS.md,包含:
markdown复制# AGENTS.md
## 项目背景
这是xxx项目,使用Go+MySQL,核心服务包括用户服务和订单服务。
## 工作规范
- 先读代码再改,不要猜测未检查的代码
- 代码注释用中文,变量命名用英文
- 不确定的地方问我,不要自己瞎猜
## 常见坑点
(遇到问题再补充)
5.2 提示词演进路径
-
起步阶段:基础背景
markdown复制## 项目背景 微服务架构,Go语言,核心服务有用户服务、订单服务。 -
积累阶段:补充踩坑经验
markdown复制## 常见坑点 - Apollo配置格式:key必须是xxx.yyy.zzz三段式 - 数据库连接:测试环境IP是10.0.0.1,不是localhost -
成熟阶段:形成知识索引
markdown复制## 关键知识 详细技术背景见context/目录: - 服务架构:context/tech/services/ - 业务逻辑:context/business/
5.3 实用提示词技巧
-
XML标签隔离指令类型
markdown复制<coding_style> <dos> - 错误处理必须包装:fmt.Errorf("failed to x: %w", err) </dos> <donts> - 禁止使用panic </donts> </coding_style> -
写决策逻辑而非散乱规则
markdown复制## 遇到不确定的业务逻辑时 1. 先搜索context/business/下的相关文档 2. 如果文档没写,搜索相关代码实现 3. 如果代码也不明确,再问我 -
记录AI易犯错误
markdown复制## AI注意事项 - 【重要】修改config后要重启服务才能生效 - 【重要】用户表的status字段:0=未激活,1=正常,2=封禁
6. 解决AI"失忆"问题
6.1 内存持久化方案
LLM本质上是无状态的,需要将"记忆"保存到文件:
code复制会话内存(易失) <-> 文件系统(持久)
实现方式:
- 会话结束前,让AI保存当前状态到process.txt
- 新会话开始时,让AI读取process.txt恢复上下文
6.2 长期任务管理
对于复杂任务,创建features.json跟踪进度:
json复制{
"requirement_id": "example-requirement",
"features": [
{
"id": "F001",
"name": "用户登录",
"status": "done",
"related_files": ["src/login.ts"]
}
]
}
6.3 高级技巧:独立上下文审查
完成代码后,开启全新会话让另一个AI实例审查。两个互不知道对方上下文的窗口,往往能发现明显的逻辑漏洞,就像找另一个同事做Code Review。
7. 团队共享:单仓库模式
7.1 目录结构
code复制AgenticMetaEngineering/
├── AGENTS.md # AI的"入职手册"
├── context/ # 团队知识库
│ ├── team/ # 团队通用知识
│ └── project/ # 项目特定知识
└── .codebuddy/
└── commands/ # 自定义命令
7.2 分支策略
code复制master(模板,保持干净)
├── AGENTS.md
├── context/
└── .codebuddy/
feature/your-work(工作分支)
├── 继承master内容
├── requirements/
└── ../workspace/
7.3 知识路由表
| 信息类型 | 存放位置 | 示例 |
|---|---|---|
| 新人必读 | AGENTS.md | "本项目使用DDD架构" |
| 踩坑经验 | context/experience/ | "Apollo配置注意事项" |
| 业务规则 | context/business/ | "VIP用户提现规则" |
| 当前进度 | process.txt | "API完成,下一步写测试" |
8. 复合工程:经验即资产
8.1 核心理念
让每一单元的工程工作使后续工作变得更容易。每次遇到问题解决后,花2分钟记录到AGENTS.md或context/目录。
8.2 三层迭代循环
- 日常开发循环(每天):遇到问题→解决→记录
- 周期整理循环(每周):Review记录→整理归类→提交PR
- 能力固化循环(每月):识别高频模式→讨论封装→创建Command/Skill
9. 关键认知转变
- 从"精密设计"到"最简起点"
- 从"代码实现"到"文本描述"
- 从"个人使用"到"团队共享"
AI工程化的本质是把AI当成团队新成员培养:
- 入职手册:AGENTS.md
- 项目知识:context/
- 经验记忆:process.txt
最终形成团队的共享能力。记住:先让它跑起来,在实践中迭代。最好的工具往往是最简单的工具。