从复杂架构到极简提示词：AI工程化的认知转变

1. 从复杂架构到极简提示词的认知转变

作为一名长期从事AI工程化落地的实践者，我最近经历了一次深刻的认知转变。我们团队原本设计了一套看似完美的三层架构系统，包含Command层、Agent层和Skill层，还定义了严格的九步工作流。这个架构在纸面上看起来非常漂亮，但当我们真正尝试使用时，却发现它带来了巨大的认知负担。

最让我震惊的转折点出现在一个简单的开发任务上。当我直接在聊天框中输入"帮我在user表加一个last_login_at字段"这样的自然语言指令时，AI在5分钟内就完美完成了任务。而按照我们设计的架构，同样的任务需要走完需求创建、意图识别、路由分发等复杂流程，预计耗时15分钟。这个对比让我们不得不重新思考：AI工程化的本质到底是什么？

2. 两个产品的关键启示

在反思过程中，Google的NotebookLM和Anthropic的Claude Code给了我们重要启发。NotebookLM的界面简单到令人惭愧——只有来源、对话和输出三个区域，但它完美解决了信息消化的问题。这让我们意识到：LLM本身已经足够强大，关键在于如何组织输入。

Claude Code团队的经历尤其引起共鸣。他们最初也尝试创建复杂的工具图，但最终发现"你给模型的工具越少，每次调用的效率就越高"。这与我们设计大量精细Skill的做法完全相反。更震撼的是Claude Code创作者的实际工作方式：同时运行10-15个Claude实例，每周产出50-100个PR，这种效率让我们开始质疑复杂架构的价值。

3. 新思维模式的核心原则

基于这些反思，我们形成了全新的思维模式：

文档即记忆：AGENTS.md文件既是新人的入职手册，也是AI的核心记忆。我们不再维护两套知识体系，而是用同一份文档服务人类和AI。例如，原本需要开发pre-commit Skill来强制lint检查，现在只需在文档中写明"提交前必须运行make lint"，AI就能自主遵守。

先跑起来再优化：我们放弃了追求完美设计，转而从最简单的提示词开始。就像Claude Code团队强调的："大多数会话都从计划模式开始，与Claude讨论直到满意其计划，然后切换到自动接受编辑模式。"这种简单直接的方式反而更高效。

自然演进：我们不再预设复杂架构，而是观察团队如何使用工具，将高频模式固化为能力。正如Claude Code团队所说："构建一个足够开放的产品，观察人们如何'滥用'它，然后为此而构建。"

4. 极简落地方案：一个文件搞定AI工程化

我们现在的方案简单得令人难以置信：在项目根目录创建一个AGENTS.md文件。这个文件包含项目背景、工作规范和常见坑点等基本信息。随着使用，它会自然生长出更多内容：

markdown复制# AGENTS.md
## 项目背景
微服务架构，Go语言，核心服务有用户服务、订单服务。

## 工作规范
- 代码注释用中文，变量命名用英文
- 不确定的地方问我，不要自己瞎猜

## 常见坑点
- Apollo配置格式：key必须是xxx.yyy.zzz三段式
- 数据库连接：测试环境IP是10.0.0.1，不是localhost

这种方案带来了惊人的效果。原本需要复杂Skill实现的规范检查，现在通过简单的文档说明就能达到相同目的。我们总结了几条实用的提示词设计技巧：

1. 用XML标签隔离指令类型：

markdown复制<coding_style>
<dos>
- 错误处理必须包装：fmt.Errorf("failed to x: %w", err)
- 日志必须带traceId
</dos>
</coding_style>

2. 写决策逻辑而非散乱规则：

markdown复制## 遇到不确定的业务逻辑时
1. 先搜索context/business/下的相关文档
2. 如果文档没写，搜索相关代码实现
3. 如果代码也不明确，再问我

3. 记录AI容易犯的错：

markdown复制## AI注意事项
- 【重要】修改config后要重启服务才能生效
- 【重要】用户表的status字段：0=未激活，1=正常，2=封禁（不是布尔值！）

5. 解决AI的"失忆"问题

LLM的无状态特性是个挑战，我们通过文件系统实现了"记忆"的持久化。在会话结束前，让AI把当前状态保存到process.txt：

markdown复制# process.txt
## 当前状态
正在开发用户认证功能，API已完成，下一步是写单元测试。
## 已完成
- [x] 设计JWT Token结构
- [x] 实现登录接口
## 待完成
- [ ] 编写单元测试

新会话开始时，AI读取这个文件就能恢复上下文。对于复杂任务，我们使用features.json来跟踪功能清单：

json复制{
"features": [
{
"id": "F001",
"name": "用户登录",
"status": "done",
"related_files": ["src/login.ts"]
}
]
}

Claude Code团队发现的一个重要技巧是：让AI验证自己的工作。例如：

• 后端API：运行测试套件
• 前端UI：浏览器预览
• 配置变更：重启服务验证

这种反馈循环能将最终结果的质量提高2-3倍。

6. 团队协作的单仓库模式

我们采用单仓库模式来共享AI配置和知识：

code复制AgenticMetaEngineering/
├── AGENTS.md              # 团队共享的提示词
├── context/               # 团队知识库
│   ├── team/              # 团队通用知识
│   └── project/           # 项目特定知识
└── .codebuddy/            # 团队共享的工具

这种模式实现了：

• 知识共享：所有人共用一套AGENTS.md
• 经验沉淀：踩坑记录通过PR共享
• 工作隔离：各自在独立分支上开发

与传统RAG方案不同，我们直接赋予AI grep、find等能力，让它像工程师一样主动探索代码库。知识组织原则很简单：

• 按领域分文件夹：tech/、business/、experience/
• 文件名要清晰：让ls出来的列表就有语义
• 内容用Markdown：最自然的文本格式

7. 复合工程：让经验产生复利

我们建立了三层迭代循环：

1. 日常开发循环：遇到问题→解决→记录
2. 周期整理循环：每周Review记录→整理归类
3. 能力固化循环：每月识别高频模式→封装

通过PR共享经验的示例：

markdown复制## PR标题
add: 商品发放钱包选择经验
## 变更内容
- 新增context/experience/商品发放-钱包问题.md
## 背景
开发xxx需求时发现虚拟商品和实物商品的钱包配置不同，
多次踩坑后整理成文档。

Claude Code团队甚至让AI作为PR的一部分向CLAUDE.md添加内容，实现了经验沉淀的自动化。

8. 推广策略与避坑指南

推广这种新方法时，我们总结了以下策略：

分级推进：

1. 试点阶段：1-2个种子用户验证流程
2. 扩展阶段：感兴趣的同事加入
3. 全员阶段：成为标准工作方式

避免的陷阱：

• 过度流程化：简化Review标准，快速合并
• 只有少数人参与：鼓励"小"贡献
• context膨胀：定期清理过时文档
• 知识过时：遇到问题时顺手更新

9. 架构与Agent的重新思考

经过这段旅程，我们对Workflow和Agent有了更清晰的认识：

判断是否需要Agent的三个问题：

1. 任务步骤是否可预先定义？→ 是则用Workflow
2. 是否需要根据中间结果调整？→ 是则用Agent
3. 能否用单次LLM调用解决？→ 是则先优化Prompt

10. 持续探索的开放问题

虽然我们已经取得进展，但仍有未解决的问题：

• 如何量化AI工程化的ROI？
• context的最佳组织方式是什么？
• 团队规模增大后如何避免context混乱？

这些问题的答案可能因团队而异，但通过持续实践和分享，我们相信会找到更好的解决方案。