2026了你还只会写点prompt？从AI提示词到可控自动化的演进之路

1、前言

简单总结一下个人使用AI的路线演进:

• 定义prompt优化AI提示和补全效果
• 定义规则rules约束AI生成的可控性
• 定义工作流，让AI分步执行任务
• 通过Agent实现AI自动化可控式迭代

前面3个步骤比较常见，这里避免啰嗦，直接最后一步；另外本文不涉及具体实现细节，只分享整体架构以及对应的演化思路。

2、最初的设想

graph TB A[线上系统运行] --> B[线上错误监控] A --> C[用户反馈] D[接口文档] E[需求文档] %% MCP 模块 B --> M[MCP Server] C --> M D --> M E --> M M --> F[AI Agent] F -->|自动分析与决策| G[生成 / 修改代码] G -->|自动提交| H[部署上线] H -->|形成闭环| A style M fill:#e3f2fd style F fill:#e1f5ff style G fill:#e1ffe1 style H fill:#fff4e1 style A fill:#ffe8e1

最初的想法很简单，就是把日常开发需要的东西全部丢给AI，自己做撒手掌柜，这里解决向AI传输数据的核心方式是通过MCP协议构建的MCP Server服务。

MCP全称(Model Context Protocol)，可以自己搜一下，主要是用来解决这些Prompt的问题：

• 不可校验
• 不可diff
• 不可回滚
• 不可组合
• 不可规模化

为了解决这些个问题，大家不得不打成了共识。

3、遇到的问题

3.1、AI项目迭代的失控

如果大家有自己亲手尝试从零开始生成一个项目进行迭代，就会遇到一些很明显的场景：

1. 初始生成，惊为天人
2. 后续修改，逐渐崩溃
3. 细节调整，开始混乱
4. 对话过长，胡言乱语
5. 问题修复，陷入循环

实际运行效果如下😅：

graph TB D1[Day 1: AI快速搭建系统] D2[Day 2: AI修改功能] P1[遗忘早期设计决策] P2[修Bug引入新Bug] P3[代码膨胀 5k -> 12k 40%冗余] P4[同一需求多次生成结果不一致] M3[Day 3: 不敢再让AI改代码] %% 主线 D1 --> D2 D2 --> P1 D2 --> P2 D2 --> P3 D2 --> P4 P1 --> M3 P2 --> M3 P3 --> M3 P4 --> M3

遇到问题就解决问题：

graph TB %% 起点 A[反思为什么失败] --> B[根本原因] %% 顿悟阶段 B --> C1[AI没有长期记忆] B --> C2[代码是唯一载体] B --> C3[每次都要重读代码] %% 永久记忆阶段 C1 --> D[思考&顿悟] C2 --> D[思考&顿悟] C3 --> D[思考&顿悟] %% 解决方案阶段 D --> E1[AI需要长期记忆] E1 --> E2[提取项目核心元数据 - AST] %% 产物阶段 E2 --> F1[AST是项目的基因] E2 --> F2[代码是基因编译的一次性产物] E2 --> F3[AI是基因编译实体的工具] %% APS-DSL诞生 F1 --> G[APS-DSL诞生] F2 --> G[APS-DSL诞生] F3 --> G[APS-DSL诞生]

然后我们的整体流程就变成了这样：

graph TB A[线上系统运行] --> B[线上错误监控] A --> C[用户反馈] D[接口文档] E[需求文档] %% MCP 模块 B --> M[MCP Server] C --> M D --> M E --> M M --> N[项目基因AST& AI_GUIDE.MD] N --> F[AI Agent] F -->|自动分析与决策| G[生成 / 修改代码] G -->|自动提交| H[部署上线] H -->|形成闭环| A style M fill:#e3f2fd style F fill:#e1f5ff style G fill:#e1ffe1 style H fill:#fff4e1 style A fill:#ffe8e1

这个流程里增加了核心模块AST，解决AI需要外部记忆系统的问题。后续项目的迭代，就成了以AST作为核心基因，进行基因表达式的演进流程

上面这个是最为关键的一步，应该算是独创的流程，没见过类似的。

这里AST可以理解为项目知识图谱Knowledge Graph，核心元数据等等，个人还是喜欢称为AST，和抽象语法树没关系。

AST的模版最初参考DSL选择了yaml，因为这个东西很像是容器里的DockerFile,目标是设想有了这个后，代码可以像容器一样随意删除。

后来便于AI校验和识别，以及便于阅读，改为json文件。

我这里定义了主要13个基础模版,细节就不展示了，仅供参考：

**_meta.ast.json** - 📌 **入口文件**：项目元信息、技术栈、团队、架构，**包含所有AST文件清单**
**_ast_index.json** - AST索引文件：全局统计和关系图谱（最后生成）
**api.ast.json** - API接口定义 API 接口（基础信息：id, name, method, path, params, response）
**api.enhanced.ast.json** - API增强定义（含semantics、implementationHints等AI分析）
**config.ast.json** - 配置信息、环境变量、构建配置
**contexts.ast.json** - 应用上下文（认证、缓存、数据库连接等）
**domain.ast.json** - 数据模型、实体、字段、关系
**infrastructure.ast.json** - 中间件、工具函数、公共服务
**permission.ast.json** - 权限定义、角色、资源访问控制
**response-format.ast.json** - API响应格式标准、错误码定义
**ui-components.ast.json** - UI组件抽象定义（框架无关）
**ui.ast.json** - UI页面、路由、布局结构
**workflow.ast.json** - 业务流程、工作流定义

3.2、信息源造成的混乱

实际场景：

Sentry说：User.save()报错
Swagger说：POST /user需要email字段
用户反馈说：注册后没收到邮件
老代码说：User模型有username字段

→ AI整合4个信息源，生成了"看似正确"的代码
→ 实际运行：逻辑冲突，更多Bug

解决思路：

graph TB A[多信息源] --> B[Sentry错误] A --> C[用户反馈] A --> D[Swagger文档] A --> E[现有代码] B & C & D & E -->|AI提取| F[AST元数据] F -->|AI自动化审核| G{完备性检查} G -->|62%| H[生成缺失报告] H --> I[详细清单:
- 32个参数缺说明
- 18个缺验证规则] I -->|补充| F G -->|>95%| J[唯一可信源] J -->|自动生成| K[代码] J -->|自动生成| L[文档] J -->|自动生成| M[测试] style F fill:#fff4e1 style G fill:#ffe1f5 style J fill:#e1ffe1 style K fill:#e1f5ff style L fill:#e1f5ff style M fill:#e1f5ff

这个流程增加了核心模块：AST完备性检查，用来确认数据是否冲突，是否完整，等等。

3.3、无法保证生成结果的一致性

失败案例：

需求：实现User注册接口

AI第1次生成：
- POST /api/user/register
- 使用bcrypt加密密码
- 返回JWT token

AI第2次生成（同一需求）：
- POST /api/v1/users
- 使用md5加密密码
- 返回session cookie

AI第3次生成：
- POST /register
- 明文存储密码（！）
- 返回user_id

→ 同一需求，3种完全不同的实现！

根本原因：

• AI的生成过程包含随机性
• 缺乏标准化约束
• 没有确定性生成机制
• 没有明确指示的，AI就会漂移摇摆不定

解决思路：

graph LR A[AST定义] -->|标准化| B[134个预定义动作] B --> C[禁止AI自创] A -->|模板引擎| D[自定义模板] D -->|决定性生成| E[代码输出] E -->|10次生成| F[哈希验证] F -->|完全一致| G[diff = 0] H[失败方案] -->|AI自由发挥| I[每次不同] style A fill:#fff4e1 style B fill:#e1ffe1 style G fill:#e1ffe1 style I fill:#ffe1e1

到这里大家可能会发现一个问题，怎么搞模版了，这是不是变成了类似'低代码平台'JSON Schema类似的东西，恭喜你猜对了一半，给你点个👍。

其实到这一步确实遇到了偏离最初设想的问题：

我们想要：有限的基因AST + 无限制的语言/框架/库/工具 === 去实现有限的结果输出。

但是： 1+无限=无限， 1x无限=无限

在这种要求下，我们只能通过迭代流程等要素，无限趋近于100%的实现有限和一致的输出，但是就像圆周率永远算不尽，永远没有绝对光滑的圆，我们也只能实现有一定波动的输出。

这种波动并非没有意义，比如我们用来重构项目时，更换一下框架语言，升级一下依赖和运行环境版本等，实现一个95%完成率的重构项目，也是很有价值的，具体不再过多讨论。

3.4、现有项目的知识流失

真实案例：

核心开发人员离职 
  ↓
业务逻辑散落在代码中，难以理解
  ↓
文档缺失或已过时
  ↓
新人上手需要2-3周，频繁踩坑
  ↓
维护成本越来越高，不敢重构

根本原因：

• 业务逻辑隐藏在代码实现细节中
• 文档与代码分离，容易不同步
• 缺乏结构化的知识沉淀机制
• 项目知识随人员流失而消失

解决思路（反向提取）

graph TB A[现有源码项目] -->|AI分析提取| B[AST元数据] B --> C[13类结构化知识] C --> C1[API定义] C --> C2[数据模型] C --> C3[业务流程] C --> C4[权限规则] C --> C5[UI组件] C --> C6[配置项] C1 -->|自动生成| E[API文档] C2 -->|自动生成| F[ER图] C3 -->|自动生成| G[流程图] B -->|自动生成| H[架构图] C4 -->|自动生成| I[权限矩阵] E & F & G & H & I & C -->|综合生成| D[项目接手指南] D --> D1[架构图] D --> D2[API列表] D --> D3[ER图] D --> D4[业务流程图] D --> D5[权限模块] D --> D6[源码核心摘要] D --> D7[开发流程/注意事项] B -->|可追溯| J[源码位置记录] J --> K[文件路径+行号] style A fill:#e1f5ff style B fill:#fff4e1 style D fill:#e1ffe1 style E fill:#e1ffe1 style F fill:#e1ffe1 style G fill:#e1ffe1 style H fill:#e1ffe1 style I fill:#e1ffe1 style K fill:#ffe8e1

这个流程其实只是增加了一些文档： PROCESS_PROJECT_ONBOARDING_DOC_GENERATION.md，用于生成项目使用指南。 AI_GUIDE_V2.md ，迭代后的AI指引入口文档，用于让AI参考指定的文件分步执行流程。

总结

其实还有很多细节。

比如：如何进行AI流程开发的调试工作，如何生成AI修改报告等，网上也能搜到，这里就不再赘述了。

以上就是个人总结的一些思路，希望对大家有所帮助。

写文章太痛苦了，有用的话点个赞，掘金的mermaid图貌似版本有点低？后面该画图的我都省了。