不是让 AI 写代码: 我是在指挥 AI 干活: 一套打磨出来的 AI 编程工作流

写在前面

用 AI 编程的人越来越多，但我发现一个很普遍的困惑："同样的工具我也在用，为啥别人能出活，我一让 AI 写就崩？"

我自己摸索下来，答案不在工具。市面上的 AI 编程工具卷到今天，能力差距没大家想的那么大。真正拉开距离的是工作流——你把 AI 当成一个"许愿池"，还是当成一个"需要被管理的、很强但很莽的初级工程师"。

这篇就把我这套工作流拆开讲。它不玄，核心就一句话：

如果你也在用 AI 编程但总觉得"时好时坏、不敢交给它做正经活儿"，这篇也许能帮你把它变成一个稳定的生产力。

一、认知转变：从"帮我写"到"我指挥"

大部分人用 AI 编程的姿势是这样的：

然后 AI 洋洋洒洒吐 200 行，你一跑，报错、跟项目风格对不上、漏了一半需求。于是你得出结论:"AI 也就那样。"

问题不在 AI，在这个指令本身就是废的。你把一个需要澄清、拆解、约束的复杂任务，压缩成了一句没有上下文的许愿。

我后来彻底换了个心智模型：把 AI 当成一个刚入职的、聪明但对我项目一无所知的工程师。

对这样一个人，你不会甩一句"做个导航"就走。你会：

• 先告诉他项目长什么样、有哪些规矩（上下文）；
• 把需求讲清楚，让他先说方案，你拍板再动手（规划）；
• 大活儿拆成小块，一块块验收（拆解）；
• 每写完一块，让他自己跑通、自测（验证）；
• 他踩过的坑，记下来，下次别再踩（沉淀）。

这五件事——上下文、规划、拆解、验证、沉淀——就是我整套工作流的骨架。工具会变，这套骨架不变。

二、工作流全景

先上一张总图，后面每一环单独展开：

┌──────────────────────────────────────────────┐│① 上下文：让 AI "懂"我的项目（规则文件 + 记忆）│└──────────────────────────────────────────────┘│┌─────────────────▼──────────────────┐ 我 │② 规划：AI 先出方案 → 我审 → 定稿│ ← 决策在人└─────────────────┬──────────────────┘│┌─────────────────▼──────────────────┐│③ 拆解：大任务 → 可独立验收的小任务 │└─────────────────┬──────────────────┘│┌─────────────────▼──────────────────┐ AI │④ 实现 + 验证：写完必须能编译、能测 │ ← 执行在机└─────────────────┬──────────────────┘│┌─────────────────▼──────────────────┐ 我 │⑤ 沉淀：把坑和规矩写回规则文件 │ ← 让下次更快└──────────────────────────────────────┘

注意左边标的"我 / AI"：决策类的两头（规划、沉淀）握在人手里，执行类的中间交给 AI。 这条分界线是整套流程的灵魂。

三、① 上下文：先让 AI"懂"这个项目

AI 生成的代码"跟项目格格不入"，九成是因为它根本不知道你的项目有什么规矩。它只能靠训练里学到的"通用最佳实践"来猜，猜出来的东西自然像个外来户。

解法是把项目的"隐性知识"变成显性文档，让 AI 每次干活前先读。现在主流的 AI 编程工具都支持一个项目级的规则文件（放在仓库根目录，随代码一起版本管理）。我在一个 Tauri + React 的桌面项目里，就维护了这么一份，里面写清楚三类东西：

1. 项目是什么、怎么跑

## ProjectTauri 2 + React 18 桌面应用，包管理器 pnpm（已锁版本）。## Common Commands- pnpm run tauri:dev # 起真实 Tauri 窗口- pnpm run build # tsc 类型检查 + Vite 打包- pnpm run test:unit # Vitest 单测- npx tsc --noEmit # 只做类型检查

2. 架构边界（最关键）

## Architecture三层，边界要清晰：1. React 前端（src/）：路由、页面、Zustand 状态、TanStack Query 服务端状态2. Tauri/Rust（src-tauri/）：原生能力、命令、事件桥接3. C++ 引擎（cpp/）：Wine/Qemu## 数据流- 临时 UI 状态 → 组件本地- 共享应用状态 → Zustand- 远程数据 + 缓存 → TanStack Query

3. 硬性约束（哪些线不能碰）

## 约定- 禁止用 as any / @ts-ignore / @ts-expect-error 来消除报错- 不允许提交 hardcode 的中文（会被 i18n 扫描卡住）- fetch/错误用现成的 Axios 工具 + 统一的 401 处理，不要裸 fetch- 组件 PascalCase、hooks useXxx、store useXxxStore、布尔量以 is/has/can 开头

这份文档的威力在于：它一次写好，之后每个任务都自动生效。 我不用在每条指令里重复"记得用 TanStack Query 别裸 fetch"——AI 读了规则就知道。项目里那套手柄焦点导航引擎之所以能写成"TypeScript 严格模式、无 as any、中英双语 i18n"的规范代码，靠的就是这份文档在背后当护栏。

四、② 规划：让 AI 先"说"，别急着让它"写"

这是我从踩坑里换来的最值钱的一条经验：

为什么？因为 AI 一旦开始写代码，就会沿着第一个念头一路跑到黑。如果它对需求的理解偏了、或者选了个笨方案，你要到 200 行之后才发现，那时候返工成本极高。

而"先出方案"把纠偏点提前到了最便宜的位置——还只是几段文字的时候。

我的做法是，复杂任务开头先给这样一条指令：

先别写代码。读一下相关文件，给我一个实现方案：- 你打算改哪几个文件、各自改什么- 关键的数据结构 / 接口长什么样- 有没有多个可选路线，各自的取舍- 有哪些你不确定、需要我拍板的点

拿大屏那套焦点引擎举例，AI 第一版方案是"用一套纯几何最近邻算法搞定所有方向移动"。听起来简洁，但我一看就知道不行——顶部导航、Hero 墙、游戏网格这些是结构化的布局，纯几何算出来的落点会很别扭。

于是我们在方案阶段（还没写一行代码）就讨论出了那个"分层 → 分组 → 几何兜底 → 覆写表"的三级结构。等真正动手时，方向已经对了，AI 只是在填肉。

这里的分工特别清楚：AI 能列出所有技术选项和它们的优劣，但"哪个方案更符合这个产品的调性、哪个特例会污染核心逻辑"——这种品味判断，是我的活儿。 我否掉纯几何方案，不是因为它跑不通，而是因为我知道它"不好用"。这种判断，目前 AI 替代不了。

很多工具现在专门有个"规划模式 / plan mode"，就是把这个"先谋后动"固化成了一道流程。哪怕你的工具没有，手动加一句"先给方案别写码"也一样有效。

五、③ 拆解：大任务切成能单独验收的小块

方案定了，别一股脑丢给 AI"照着做"。方案越大，AI 一次实现出错的概率越高，而且一旦哪里错了，你很难定位是哪一环崩的。

我会把方案拆成一串可独立验收的小任务。判断标准很简单：每一块做完，我都能立刻验证它对不对（能编译、能跑、能测、或者肉眼能看出效果）。

还是拿大屏举例，那个大任务被拆成了大致这样一条链：

1. 手柄接入层：Gamepad API 轮询 + 边缘触发/长按连发 → 验收：console 打出正确的方向事件2. 焦点注册/上下文：元素能注册、能查询当前焦点→ 验收：单测覆盖注册与查询3. 分层移动逻辑：上/下在层间跳转 → 验收：真机按上下，焦点在条带间跳4. 网格移动逻辑：Feed 区行列移动→ 验收：真机在网格里走位不斜跳5. 几何兜底 + 作用域焦点陷阱→ 验收：弹窗打开焦点困在弹窗内6. 输入源切换 + 焦点跟随滚动→ 验收：手柄/鼠标无缝切、焦点自动滚进安全区

拆成这样有几个好处：

• 每一步都有明确的"完成"信号，不会出现"写了一大坨、不知道对不对"的悬空状态；
• 出错能精确定位——第 4 步走位斜跳，我就知道是网格那段的列号计算有问题，不用翻整个引擎；
• 随时能停。真实开发不是一口气干完的，拆成小块后我今天做前三步、明天做后三步，衔接毫无压力。

当子任务之间互相独立时，还能更进一步：让 AI 并行去做。现在不少工具支持派多个"子袋里"同时干活——比如"同时读这五个模块，各自总结它们的手柄相关逻辑"。互不依赖的活儿并行铺开，能省掉大量串行等待。判断哪些任务能并行、哪些有先后依赖，也是人来把关的。

六、④ 验证：AI 写完不算完，能跑通才算完

这是最容易被跳过、但最不该跳过的一环。

AI 写出来的代码"看起来对"和"真的对"之间，隔着一整条验证链。我的铁律是：

在我的项目里，这条链具体是：

npx tsc --noEmit# 类型层面先卡一道pnpm run build# tsc + Vite，构建能过pnpm run test:unit# 涉及逻辑的跑单测

我会在指令里明确要求："改完后跑 tsc 和相关单测，有报错先自己修，修好再告诉我结果。"

这么做的收益超乎想象：

1. AI 的很多低级错误会被自己发现、自己修掉——类型不匹配、漏 import、拼错方法名，编译器一报错，它下一轮就修了，根本不用我介入；
2. 它逼着 AI 面对现实。没有验证环节的 AI，很容易"自信地写出错的代码"；一旦要求它跑通，它就得对结果负责；
3. 我拿到的是"已经能跑"的东西，而不是一份"可能能跑"的草稿。

对没有测试的模块，我会顺手让 AI 补上——用项目已有的测试框架（这个项目是 Vitest + Playwright），别自创一套。新功能配新测试，这一步做进工作流后，回归 bug 明显少了。

七、⑤ 沉淀：把踩过的坑写回规则，让工作流"越用越顺"

前四步能让你这一次把活干好。第五步，是让你下一次更快。

每次协作里,总会冒出一些"AI 一开始不知道、我纠正了它才对"的点。比如：

• "这个项目的全屏路由要注册在 router 顶层，不能塞进 PrivateRoute 里"；
• "改 Rust 命令签名，记得同步改 src/apis/tauri/ 里的 TS wrapper"；
• "这个 bug 是合成键盘事件的 isTrusted 问题，以后遇到输入源乱切先查这个"。

这些如果只是当场纠正完就算了，下次 AI 还会再犯一遍。所以我会把它们写回规则文件（或者工具提供的"记忆"机制里）。规则文件因此不是一次写死的，而是跟着项目一起长——用得越久，AI 越懂我的项目，越少犯我已经纠正过的错。

这就形成了一个正反馈：

用 AI 干活→发现新的坑/规矩→写回规则▲│└──────────下次更省心◀──────────┘

半年下来，我这份规则文件从最初的几行长成了一份完整的"项目说明书"。副作用是，它顺便成了新人（人类同事）最好的 onboarding 文档——毕竟能把 AI 讲明白的东西，人看着也清楚。

八、几条反直觉的经验

有些东西是我用出来、跟直觉相反的，单独拎出来：

1. 手感/魔法参数，AI 只能给"常见值"，最终得人来调。 大屏里那个 380ms 长按连发延迟、0.35 摇杆死区、128px 焦点安全区——AI 给的都是"教科书默认值"，真正合适的数字是我在真机上反复试出来的。AI 搭骨架，手感靠人打磨。 别指望它替你做只能靠体感验证的调优。

2. 描述"现象"，比读源码更高效。 遇到 bug，我常常根本看不懂事件流。我的做法不是硬啃代码，而是精确描述症状给 AI："我明明切到鼠标了，一按手柄的确定键又被弹回手柄模式。" 它顺着现象就定位到了根因。我的价值在于把症状描述准，而不是替它读代码。

3. 同一个方案卡壳两次，就别再打补丁了。 AI 有个毛病：一个思路走不通时，它会不停打小补丁,越补越乱。我的规矩是——同一个方向失败两次，就叫停，让它退回去分析根因、换一条路，而不是继续缝。这条同样适用于你自己：别陪着 AI 在一条死路上耗。

4. 给它"后门"，但要可控。 通用规则覆盖不了 100% 的情况。大屏里我加了一张"方向覆写表"，允许为特定跳转注册自定义目标，move 时优先查表。关键是这个后门是显式的、局部的、用完即弃的，不会污染核心算法。跟 AI 协作也一样：允许特例，但要把特例圈在明确的边界里。

九、什么该交给 AI，什么必须自己扛

聊了一圈方法，最后收敛成一张我自己心里的分工表：

这张表的规律很清楚：AI 擅长"执行"，人负责"判断"。 AI 极大地压平了"语言/语法/API 记忆"这道墙，但墙推平之后，真正稀缺的能力反而回到了产品判断力、架构品味、和'知道什么是好的'这件事上。

十、写在最后

回到开头那个问题——"同样的工具，为啥有人出活有人崩"。

我的答案是:别把 AI 当许愿池，把它当一个需要被你管理的、很强的执行者。 你管理得越好——上下文喂得越足、需求拆得越清、验证卡得越死、坑沉淀得越勤——它就越像一个靠谱的资深队友；你管理得越懒，它就越像个闯祸的实习生。

工具年年在变，但"上下文 → 规划 → 拆解 → 验证 → 沉淀"这套骨架，我觉得会一直有效。因为它本质上不是"怎么用某个 AI 工具",而是**"怎么把一件复杂的事，交给一个执行力极强但需要方向的伙伴去完成"**——这套东西，管理人也一样成立。

如果你也在观望，我的建议还是那句：别等学完工具再动手。挑个你真想做的东西，把这套流程套上去边做边磨——你会发现,难的从来不是让 AI 写代码，而是想清楚要它写什么。