写在前面：你的 AI 编程工作流，决定产出效率

如今，越来越多开发者开始尝试借助 AI 编程，但一个普遍困惑也随之浮现：“明明用的是同一个工具，为什么别人能高效产出，我让 AI 写个功能就频繁崩坏？”

经过大量实践发现，答案并不在工具本身。当前市面上的 AI 编程工具经过激烈竞争，能力差距并没有想象中那么大。真正的分野在于你的 AI 编程工作流——你是把 AI 当作一个“许愿池”，还是当作一个“需要被管理、能力强但有点莽撞的初级工程师”。

本文将这套高效的 AI 编程工作流拆解开来细讲。它并不玄妙，核心可以浓缩为一句话：

如果你也在用 AI 编程，却总觉得结果“时好时坏、不敢把它交给正经活儿”，那么这篇文章或许能帮你把它变成一个稳定的生产力来源，大幅提升你的 AI 编程效率。

一、认知转变：从“帮我写”到“我指挥”——AI 编程的核心心法

大部分人使用 AI 编程的方式是这样的：

丢下一个指令：“帮我写个导航组件”，然后 AI 洋洋洒洒吐出 200 行代码。结果一运行，报错、跟项目风格对不上、还漏掉一半需求。于是得出结论：“AI 也不过如此。”问题并非出在 AI 身上，而是这条指令本身就有缺陷——将一个需要澄清、拆解、约束的复杂任务，压缩成了一句没有上下文的许愿。

后来彻底换了一个心智模型：把 AI 当作一个刚入职的、聪明但对你项目一无所知的工程师。面对这样一个新人，你不会甩下一句“做个导航”就走，而是会：

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

这五件事——上下文、规划、拆解、验证、沉淀——构成了整套 AI 编程工作流的骨架。工具会迭代，但骨架不变。

二、工作流全景：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“照着做”。方案越大，AI 一次实现出错的概率就越高，而且一旦某个环节出错，很难定位是哪里出了问题。把方案拆解成一串可独立验收的小任务，判断标准很简单：每一块做完后，都能立刻验证它对不对（能编译、能运行、能测试、或者肉眼可见效果）。

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

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

拆成这样有几个显著的好处：

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

当子任务之间互相独立时，还能更进一步：让 AI 并行处理。如今不少工具支持派发多个“小任务”同时干活——比如“同时读这五个模块，各自总结它们的手柄相关逻辑”。互不依赖的任务并行铺开，能节省大量串行等待时间。判断哪些任务可以并行、哪些有先后依赖，依然是人类来把关。

六、④ 验证：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 协作

前四步能确保这一次把活儿干好。第五步，是让下一次更快。每次协作中总会冒出一些“AI 一开始不知道、纠正了才对的”点。比如：

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

如果仅仅是当场纠正完就算了，下次 AI 还会再犯一遍。所以需要把它们写回规则文件（或者工具提供的“记忆”机制里）。规则文件并非一次性写死，而是跟着项目一起成长——用得越久，AI 越懂项目，越少犯那些已经纠正过的错误。这就形成了一个正反馈循环：

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

半年下来，规则文件从最初的几行长成了一份完整的“项目说明书”。它同时成了新人（人类同事）最好的 onboarding 文档——毕竟能把 AI 讲明白的东西，人看着也清晰。

八、几条反直觉的经验：AI 编程中那些意想不到的真相

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

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

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

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

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

九、什么该交给 AI，什么必须自己扛——AI 辅助开发的分工智慧

聊了一圈方法，最后收敛成一张分工表：

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

十、写在最后：掌握 AI 编程工作流，才能持续高效产出

回到最初那个问题——“同样的工具，为什么有人出活有人崩”。答案在于：别把 AI 当许愿池，把它当一个需要被管理的、能力很强的执行者。管理得越好——上下文喂得越足、需求拆得越清、验证卡得越死、坑沉淀得越勤——它就越像一个靠谱的资深队友；管理得越懒，它就越像个闯祸的实习生。

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

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