AI 编程工作流

AI 能很快写出一段代码，但真实产品需要连续几十次正确修改。

效率差距不在提示词多漂亮，而在于项目是否给 AI 足够清晰的边界和反馈。

先建立项目上下文

至少让 AI 能读到：

• 产品解决什么问题，当前不做什么
• 技术栈、目录职责和运行命令
• 数据和权限边界
• 代码风格与禁止事项
• 完成任务后必须运行的检查

这些稳定信息应该放进仓库里的规则文件，而不是每次聊天重新解释。

每次重新解释有两个代价：你会漏掉一部分，而且不同次解释得不一样，AI 的行为就会飘。

规则文件里最值钱的一节是"当前不做什么"。AI 很乐意帮你加功能，它不会提醒你这不在计划里。

一个任务只交付一个可验证结果

好的任务包含四部分：现状、目标、边界、验收。

现状：支付结果页只依赖前端回跳参数。
目标：改成根据当前用户和订单号查询服务端状态。
边界：不修改下单接口和页面样式。
验收：未登录、他人订单、待支付和已支付四种状态都有测试方式。

"做一个完整支付系统"同时包含产品、架构、安全和界面决策，失败后很难定位。

"边界"那一行是四行里最容易省掉、也最不该省的。 不写它，你会在差异里看到七个文件被改动，其中三个是你要的，两个是顺手重构，两个是它自己的偏好。

保持短反馈循环

推荐节奏：

检查现状 → 写小计划 → 改一块 → 运行检查 → 手动验收 → 看差异

不要让 AI 连续改几十个文件后才第一次运行。范围越大，它越容易基于错误假设继续向前——而且每一步都建立在上一步的错误上，最后整段都要推翻。

一个具体的界线：单次改动超过五个文件，就该拆。

每次改完先看差异再提交

这条和项目地基里说的是同一件事，但在这里更频繁地发生。

看差异时问三句：

1. 这个改动我认识吗
2. 它属于我刚才那个任务吗
3. 它有没有删掉我之前特意加的东西

第三句最重要。AI 有时会把它认为多余的代码删掉——那可能正是你上周为了处理某个边界情况加的。

让 AI 说明证据

完成后要求它回答四件事：改了哪些文件、为什么这样改、运行了什么检查、还剩什么风险。

"应该没问题"不算验证。算验证的是：命令的实际输出、具体的响应状态、可复现的操作步骤。

上下文变长时要重开

一次对话进行得越久，AI 越容易：

• 记着早已作废的中间方案
• 反复回到一个已经被否决的思路
• 混淆几个相似文件的内容

出现这些迹象时，别继续纠正，重开一个对话。带上规则文件、当前状态和一个明确任务，通常比在长对话里拉回来快得多。

判断线：同一个问题纠正两次还没对，重开。

哪些决策不要交出去

AI 可以提供选项，不能替你承担后果。

常见错误

每次聊天重新解释项目背景。 会漏、会飘，行为不一致。

规则文件里没写"当前不做什么"。 AI 会热情地帮你扩范围。

任务里没写边界。 差异里会出现一堆你没要的改动。

一次改几十个文件才第一次运行。 错误层层叠加，最后整段推翻。

接受"应该没问题"当验证。 要命令输出和复现步骤。

在长对话里反复纠正同一个问题。 重开更快。

把权限和金额校验的判断交给 AI。 后果由你承担。

验收标准

• 仓库里有规则文件，包含技术栈、命令、边界和"当前不做什么"
• 每个任务都写了现状、目标、边界、验收四部分
• 单次改动控制在五个文件以内
• 每次提交前都看过完整差异
• 要求 AI 给出运行过的命令和输出，不接受"应该没问题"
• 同一问题纠正两次不对就重开对话
• 权限、金额、数据收集的决定都由你自己做

本章动作

把当前最大的任务拆成三个半天内能验收的小任务。

每个任务只保留一个结果，并明确写出"不修改什么"。

下一步

1. 测试与排错——让验收有客观依据
2. 项目地基——版本和回滚是这套流程的前提
3. 账号、权限与数据模型——不能交给 AI 的那部分决策