从“提示工程”到“AI工程”：构建全自动化Coding的工作流

## 引言：当代码生成不再“神奇”

相信很多开发者都有过这样的体验：面对一个复杂需求，你怀着兴奋与期待，将一段精心构思的提示词扔给GPT-4或Claude。起初，AI生成的代码片段令人惊艳，但当你试图扩展功能、修复边界case或整合模块时，事情开始变得棘手。代码前后矛盾、上下文遗忘、架构混乱……最初的兴奋迅速被**焦虑和挫败感**取代。我们不禁反思：大模型代码生成能力如此强大，为何落地一个完整项目依然如此艰难？

分享的这套“全自动化Coding流程”，正是对这个痛点的直接回应。它宣告了一个转变：从依赖灵光一现的“提示工程”（Prompt Engineering），迈向有流程、可迭代、可积累的“AI工程”（AI Engineering）。这不再是和AI“聊天”，而是与AI“协同开发”。

## 痛点剖析：为什么你的AI编码会失败？

在深入流程之前，我们必须正视问题。AI编码的失败，往往源于以下几个工程化缺失：

1.  **需求模糊与“幻觉”放大**：给AI一个模糊指令（如“开发一个网站”），它会基于其训练数据“幻想”出无数种可能，结果必然南辕北辙。
2.  **上下文爆炸与性能衰减**：试图在一个对话中解决所有问题，导致上下文窗口被塞满。模型在处理超长上下文时，对中间部分的理解和记忆能力会急剧下降，输出质量不稳定。
3.  **缺乏验证与迭代闭环**：生成代码后，没有标准化的验证环节来判断其是否正确，错误会像滚雪球一样积累。
4.  **知识无法沉淀**：每次开发都是“从零开始”，成功的经验和失败的教训没有留存，无法形成“复利”。

视频中提到的“成本”和“性能”，正是对这些痛点的量化思考。这套流程，就是为了系统性地解决它们。

## 工作流三部曲：从想法到成品的AI工程化路径

### 第一阶段：需求澄清与结构化拆解

**核心动作：从“对话”到“访谈”**

流程的起点不是写代码，甚至不是写需求文档，而是**需求挖掘**。视频中强调：“首先是你第一要把用户的需求清楚。” 这里的“清楚”，不是你自己清楚，而是让AI和你一起，通过多轮、有目的的“采访”（interview），将模糊的想法聚焦为清晰的“初始需求文档”。

> **情绪描写**：这个阶段需要极大的耐心。看着AI像一个新手产品经理一样不断追问“这个功能的用户场景是什么？”“异常情况如何处理？”，你可能会感到一丝**烦躁**，但请坚持。当模糊的概念逐渐变得棱角分明时，那种**拨云见日般的释然**，是后续所有步骤成功的基石。

**关键产出：PRD与PRD.json**

初始需求之后，不是直接编码，而是让AI将其整理成规整的产品需求文档（PRD）。更重要的是下一步：**将PRD拆解为结构化的`prd.json`**。这一步借鉴了A16Z提出的“AI软件工程”思想。

```json
// 模拟 prd.json 中的一个任务单元
{
  "task_id": "TASK_001",
  "description": "实现用户登录API端点，接收邮箱和密码，返回JWT令牌",
  "acceptance_criteria": [
    "端点路径为 /api/auth/login",
    "请求方法为POST，Content-Type为application/json",
    "验证邮箱格式与密码非空",
    "密码需与数据库哈希值比对",
    "成功时返回 {\"token\": \"<jwt_string>\"}",
    "失败时返回相应的HTTP状态码和错误信息"
  ],
  "verification": {
    "method": "单元测试",
    "script": "将提供 test_auth_login.py，需通过所有测试用例"
  },
  "dependencies": []
}
```

这个JSON文件是机器可读的“工作说明书”。它将一个“功能”（feature）拆解为多个具备明确“验收标准”和“验证方法”的“用户故事”（user story）或任务。至此，AI要解决的问题被原子化了。

### 第二阶段：Ralph循环——迭代式精准执行

这是整个流程的**灵魂**，也是对抗“上下文爆炸”和“性能衰减”的利器。

**什么是Ralph循环？**
简单说，就是 **“单任务执行-验证-记录-下一任务”** 的循环。视频中尖锐地指出：“不要让它一次性的把所有的task，全部扔给这个模型”。

**循环步骤拆解：**
1.  **读取单任务**：从`prd.json`中读取**下一个**待处理的任务（如`TASK_001`）。
2.  **执行与生成**：将当前任务描述、相关上下文（如架构文档）和**历史迭代记录**（`process.txt`）一起提供给AI，生成代码或解决方案。
3.  **验证**：运行针对该任务的验证（如单元测试）。这一步可以由AI自己调用解释器执行，也可以由开发者审核。
4.  **记录**：无论成功与否，都将本次执行的**输入、输出、结果、学到的经验或教训**，完整追加记录到 `process.txt` 中。
5.  **迭代**：基于记录的结果，决定是进入下一个任务，还是修复当前任务后重试。

> **情绪描写**：运行Ralph循环的感觉，就像在指挥一支纪律严明的军队。看着AI一个堡垒一个堡垒地攻克，每一步都有迹可循，失败也能快速定位和回溯。那种对进程的**绝对掌控感**，彻底取代了以往面对一团乱码时的**无力感**。当循环顺畅运行，任务一个接一个变绿（成功）时，带来的是一种平稳而持续的**成就感**。

### 第三阶段：迭代记录与资产沉淀——复利工程的核心

这是区分“一次性实验”和“可持续工程”的关键。`process.txt` 文件不仅是日志，更是项目的“长期记忆”和“经验库”。

**`process.txt` 的价值：**
- **错误学习**：AI在任务TASK_003中学会了某种库的特定用法，当未来类似任务出现时，它能直接参考，避免重复犯错。
- **上下文管理**：替代臃肿的聊天历史，为后续任务提供高价值、精炼的上下文。
- **流程追溯**：项目复盘或新人接手时，这是最佳的学习材料。

**架构资产沉淀：`AGENTS.md` / `ARCHITECTURE.md`**

视频更进一步，提出了将成功经验固化为可复用的架构资产。例如，在本次项目中，我们摸索出使用`FastAPI`+`SQLAlchemy`+`JWT`是一种高效的后端架构。那么，就可以将这个模式总结成 `ARCHITECTURE_backend_fastapi.md`。

当下次开发类似功能时，工作流可以直接读取这份架构文档作为初始上下文。AI不再是凭空创造，而是在你团队的最佳实践基础上进行开发。这就是“复利工程”——每一次成功的开发，都为下一次积累了“利息”，知识资产像滚雪球一样增长。

## 技术对比与思想升华

这套工作流并非凭空创造，它深刻融合了多项工程思想：

- **敏捷开发与用户故事**：将大需求拆解为小、可验证的任务。
- **持续集成/持续部署（CI/CD）中的自动化测试**：每个任务都有验证环节，确保质量关口前移。
- **DevOps中的“一切即代码”**：不仅应用代码，连需求（`prd.json`）、流程知识（`process.txt`）、架构（`ARCHITECTURE.md`）都代码化、版本化。
- **智能体（Agent）研究中的规划与反思**：Ralph循环本质是一个具有规划和反思能力的智能体的行动模式。

它与单纯使用GitHub Copilot或ChatGPT写代码的最大区别在于**系统性和主动性**。它是一个预设好的、自动化的“思考-行动-反思”框架，强制将混沌的开发过程纳入有序的轨道。

## 总结与展望：拥抱AI工程化时代

回顾整个流程，它就像一个为AI编程量身定制的“脚手架”（Scaffolding）和“流水线”。

**核心收获：**
1.  **清晰化优于模糊化**：任何自动化都必须始于绝对清晰的定义。
2.  **拆解是应对复杂性的唯一法宝**：无论是给人还是给AI的任务。
3.  **循环迭代优于单次爆发**：用可控的小循环代替不可控的大爆炸，是保证稳定性的关键。
4.  **沉淀创造复利**：工程的核心价值在于将知识转化为可复用的资产。

> **情绪描写**：初看这套流程，你或许会觉得步骤繁琐，不如直接问AI来得“爽快”。但当你真正因一个模糊需求而浪费数小时调试，或因上下文丢失而重头再来时，**你会怀念流程带来的秩序**。掌握它，意味着你将AI从一个时灵时不灵的“魔术师”，转变为你团队中一位可靠、可管理、且不断成长的“初级工程师”。这种转变带来的，是作为技术驾驭者的**深度自信和从容**。

未来，随着AI智能体能力的进一步增强，这类工程化工作流将不再是极客的玩具，而会成为软件开发的标准配置。我们现在探索的，不仅仅是如何使用AI，更是在定义下一代软件工程协同范式的基础构件。旅程已经开始，而你，正站在最前沿。

评论