🛠️  AI编程工作流——当模型遇上工程纪律

📌 本文是「小白学AI」系列第八篇，建议从第一章开始循序渐进地看。

让 AI 帮我改一个项目，改到第三天发现——代码回不去了 😱

原本好好的登录模块被折腾废了，最后只好从头再来。

相信我，你不是一个人。AI 编程"改着改着就乱了"，这是常态，不是你运气差。

今天我们就来聊聊：怎么用"规划"和"规范"两个手段，把 AI 编程变成一件靠谱的事。

🤔 读前先想

在开始之前，先问自己两个问题：

• 上一篇我们聊了 AI 生态的变化——Skills 让经验能复用、MCP 让工具能互通、CLI 让 AI 能真动手。但具体到编程这个场景，为什么让 AI 改一段代码，它经常改着改着就乱了？
• 人类程序员有代码审查、有测试、有版本控制——AI 编程是不是也需要类似的"工程纪律"？

带着这两个问题往下看 👇

📌 本章以编程为例，但方法适用于任何复杂任务

即使你不写代码，"Plan 模式"也能帮你：

• 写一份复杂的项目方案（先列提纲 → 确认 → 再展开）
• 组织一场活动（先规划流程 → 再执行）
• 做一份详尽的调研报告（先定框架 → 再填内容）

核心逻辑是通用的：**复杂任务需要"先规划再动手"**。

📖 为什么 AI 复杂任务总是"改着改着就乱了" 🤯

❓ 提问

• 为什么让 AI 改一段代码，它经常改着改着就偏离目标了？
• 同样的需求，为什么 AI 有时做得很好，有时却"放飞自我"？

📝 术语

• Plan 模式（Plan Mode）：先制定详细计划，经确认后再执行的工作模式
• 执行模式（Act Mode）：边想边干、直接动手改代码的模式

💬 一句话解释

AI 编程需要"先规划再动手"，因为模型本身不会自动"三思而后行"——它只会根据当前看到的内容，预测下一个最可能出现的词。

🧐 你可以先这样理解

想象你请了一个装修工人（AI）来改造你的房子：

执行模式（Act Mode） 就像工人拿到钥匙就进场，边看边改：

• 看到厨房不顺眼，拆了重装
• 拆完发现水管位置不对，又改水管
• 改完水管发现影响客厅布局，又把客厅拆了
• 三天后你发现房子一团糟，原始格局也找不回来了

Plan 模式 就像工人先花一天时间：

• 仔细测量每个房间
• 画出设计图纸 📐
• 列出材料清单和施工顺序
• 给你看过方案、确认无误后再动手

AI 模型本质是按概率"接话"的。任务越短，它越不容易跑偏；任务越长，它越容易"走一步看一步"，逐渐被新信息带偏，忘记最初的目标。

这就是为什么长任务容易"改着改着就乱了"——上下文被新信息淹没了。

📚 示例

场景一：用 Plan 模式写项目方案（非技术场景）

❌ 执行模式： 你直接打开 PPT 开始写，写到第 3 页发现逻辑不通，返回修改第 1 页； 改着改着发现需要补充数据，又回去找资料； 最后整个方案结构混乱，花了半天时间。

✅ Plan 模式：

1. 研究阶段：先搜集所有相关资料，理解项目背景
2. 规划阶段：列出方案框架——背景 → 目标 → 策略 → 执行 → 预算
3. 确认阶段：把框架给领导看，确认方向无误
4. 执行阶段：按框架一步步填充内容，每完成一部分就核对

场景二：让 AI 给现有项目添加用户登录功能（编程场景）

执行模式下的 AI：

1. 先看到需要登录页面，就创建一个 login.html
2. 然后发现需要后端接口，就创建一个 login.php
3. 写着写着发现需要数据库，就去改数据库配置
4. 改数据库时发现权限系统不完善，又去改权限系统
5. 最后登录功能还没做好，其他部分却被改得乱七八糟

Plan 模式下的 AI：

1. 研究阶段：通读整个代码库，理解现有架构
2. 规划阶段：生成实施计划——需要改哪些文件、按什么顺序、每步做什么
3. 确认阶段：把计划给你看，你确认无误
4. 执行阶段：严格按照计划一步步实施

✅ 你只需要记住 🗒️

1. AI 模型是按概率"接话"的，任务越长越容易跑偏
2. Plan 模式的核心是**"先规划再动手"**，不是让 AI 变聪明，而是强制它"三思而后行"
3. 这属于主线二（驾驭工程派）——通过设计"作业环境"让模型可靠工作

💭 我们知道了：AI 编程容易"改着改着就乱了"，是因为模型本质是按概率接话，长任务容易偏离目标。那具体怎么解决？接下来看 Plan 模式。

📖 Plan 模式——让 AI "先想后做" 🧠

❓ 提问

• Plan 模式具体是怎么工作的？
• 主流 AI 编程工具都支持吗？

📝 术语

• Plan 模式（Plan Mode）：创建只读研究阶段，在做任何代码更改之前先分析和规划
• 只读研究阶段：AI 只能查看代码，不能修改，用于充分理解代码库

💬 一句话解释

Plan 模式给 AI 配了一个"项目经理"角色，强制它先进入"只读研究"状态理解代码库，生成实施计划，经你批准后再动手。

🧐 你可以先这样理解

回到装修工人的比喻：

• 执行模式 = 工人拿到钥匙就进场拆墙
• Plan 模式 = 工人先花一天"量房"——只看不动手

Plan 模式的设计有三条"克制"：

1. 不改代码，直到你点"开始实施"

• AI 在这个阶段只能"看"和"想"，不能"动手" 🔒
• 你掌握最终决策权

2. 只读探索，充分理解上下文

• AI 会通读相关文件，理解项目结构
• 这就像给模型扩展上下文——让它看到更多相关信息

3. 生成可审计的计划文档

• 不是黑盒操作，而是产出清晰的计划清单
• 你可以审查、修改、确认每一步

为什么这能解决问题？

• 回扣本质一（概率模型）：把"规划"和"执行"分离，降低执行阶段的随机性
• 回扣本质二（上下文）：规划阶段在扩展上下文（充分理解代码库），执行阶段在约束上下文（按计划走，不被新信息带偏）

📚 示例

主流 AI 编程工具的 Plan 模式对比：

使用 CodeBuddy Plan Mode 的典型流程：

你：我想给这个项目添加用户权限系统CodeBuddy：我来启动 Plan 模式分析这个项目...[只读研究阶段：通读代码库，理解现有架构]CodeBuddy：我分析了项目结构，这是我的实施计划：1. 创建用户表迁移文件2. 添加认证中间件3. 修改路由配置4. 创建登录/注册页面5. 添加权限检查逻辑你：第3步我有点担心，会不会影响现有 API？CodeBuddy：好问题。让我重新检查一下 API 路由...[调整计划]你：确认执行CodeBuddy：[开始按步骤实施]

📚 非技术场景：组织部门团建

Plan 模式同样适用：

1. 研究：了解预算、人数、时间、大家偏好
2. 规划：生成方案——上午拓展 → 午餐 → 下午自由活动 → 晚餐
3. 确认：把方案发群里，收集反馈并调整
4. 执行：按确认后的方案预订场地、安排交通

为什么这能避免"改着改着就乱了"？

• 如果不先规划，可能订了餐厅才发现有人不吃辣 🌶️
• 如果不先确认，可能按自己想法安排，结果大家不满意

✅ 你只需要记住 🗒️

1. Plan 模式的核心是规划与执行分离——不是让 AI 变聪明，而是给它配一个"项目经理"
2. 规划阶段扩展上下文（理解全貌），执行阶段约束上下文（按计划走）
3. 适合复杂、多步骤、影响范围广的任务——不管是编程还是写方案

💭 上我们知道了：Plan 模式通过"先规划再动手"解决了单次任务的失控问题。但项目级的质量和可维护性如何保证？这就需要"先写需求再动手"了。

📖 从"写代码"到"写规格"——SDD 规范驱动 📋

❓ 提问

• Plan 模式解决了单次任务的规划问题，但项目级的代码质量如何保证？
• 如果 AI 生成了代码，半年后出了问题，谁来负责？

📝 术语

• 先写需求再动手：复杂任务开始前，先写清楚需求文档，再让 AI 执行
• 需求文档优先：把需求说明当作最重要的产出，AI 生成的内容要符合需求

💬 一句话解释

💡 先写需求再动手的核心是"需求文档优先"——人写清楚需求，AI 按需求生成内容，每步都能追溯到需求条款，让不确定性被关在笼子里。

🧐 你可以先这样理解

想象你是一家餐厅的老板：

传统开发 = 你直接教厨师（AI）做菜

• 你说："做一份红烧肉"
• 厨师凭经验做，可能每次味道都不一样
• 半年后你问："为什么今天这么咸？"——没人记得当时的配方 😕

先写需求再动手 = 你先写菜谱，厨师按菜谱做

• 你写："红烧肉做法——五花肉 500g、生抽 2 勺、老抽 1 勺、冰糖 30g..."
• 厨师按菜谱做，出品稳定
• 半年后味道变了，你查菜谱就知道哪里出了问题 ✅

三大核心原则：

1. 一份需求，一个标准

• 需求文档是项目唯一合法的定义
• AI 生成的内容必须与需求严格对齐

2. 按规矩来

• AI 在需求设定的边界内创作，而非自由发挥
• 这就是回扣本质一——用明确需求约束概率生成

3. 有据可查

• 每步 AI 生成的内容都能追溯到需求中的具体条款
• 需求文档是最结构化的上下文组织形式（回扣本质二）

为什么这很重要？

AI 生成代码很快，但"生成"不等于"正确"，更不等于"可维护"。

当项目越来越大，你需要知道：

• 这段代码为什么这样写？
• 需求变了，该改哪些地方？
• 新成员如何快速理解项目？

💡 需求文档回答了这些问题。人写需求，AI 生成内容，输出只是需求的副产品。

📚 示例

对比直接生成和规格驱动：

方式一：直接让 AI 写功能

你：给我写一个用户登录功能AI：[生成代码]半年后：这段代码谁写的？为什么这样设计？不知道。

方式二：先写需求再动手

1. 人写需求文档：   - 功能：用户登录   - 输入：用户名、密码   - 验证规则：用户名长度 3-20 字符...   - 错误处理：用户名不存在 → 提示"用户名或密码错误"...2. AI 根据需求生成内容3. 验证：输出是否符合需求？4. 半年后：查需求文档就知道当初的设计逻辑

代表项目：

✅ 你只需要记住 🗒️

1. 先写需求再动手的核心是"需求文档优先"——人写需求，AI 生成内容
2. 需求是唯一标准，每步输出都能追溯到需求条款
3. 这是驾驭工程派的终极形态——用明确需求把概率模型的不确定性关进笼子里

📝 本章总结

💡 一句话核心结论

AI 编程工作流的本质，是用"规划"和"规范"两个手段，把概率模型的不确定性关进笼子里。

📊 核心脉络回顾

🎯 回到两个本质

🌉 下一篇预告 👀

我们聚焦"AI 编程"这个具体场景，讲了 Plan 模式和 SDD 如何用"规划"和"规范"解决工程纪律问题。

但掌握了这些技能之后，一个更深层次的问题浮现出来：

如何让 AI 不只是帮你"做事"，更能帮你"成长"？ 🤔

同样的 AI 工具，为什么有人越用越聪明，有人越用越依赖？

下一篇，我们将进入"成长篇"——聊聊怎么把 AI 当作你的老师和镜子，借助它实现持续的个人成长。

内容来源：ZZZ-Simple-AI 开源项目 欢迎前往 GitHub 学习完整版：https://github.com/mfkyddh/ZZZ-Simple-AI

觉得有收获？转发给也在学AI的朋友吧 👇