先让 AI 写计划，再让它写代码

有阵子我发现自己和 AI 的对话模式是这样的：描述需求 → 它直接给一版代码 → 我跑一遍 → 挂了 → 让它修 → 又挂了 → 我开始逐行读它写的代码找 bug。

第三轮的时候我意识到不对劲：我在用最贵的方式（读代码、跑测试、回滚）去发现本该最便宜发现的问题——方案本身就不对。于是我把流程加了一步：先计划，后动手。

固定流程

把需求和背景一次性给足：相关代码、现状、约束；
让它先输出一份改动计划，不动代码：改哪些文件、按什么顺序、明确不做什么、有什么风险、怎么验证；
我审这份计划——这一步最关键，也是全程唯一需要我全神贯注的地方；
确认后再让它逐步执行，每步跑测试。

审计划时我在看什么

有没有动不该动的：顺手重构、升级依赖、改公共函数签名，一律砍掉；
边界条件想到了吗：空值、分页、并发、时区；
验证手段够不够：只跑 lint 不跑测试的计划，直接打回；
回滚方式：万一坏了，怎么回到改动前。

一个例子

需求很典型：「导出功能支持按日期区间筛选」。

直接动手版：它改了 DAO、Service、Controller 三层，顺手把分页逻辑「优化」了一下，回归出两个新 bug，前后耗了一个多小时。

先计划版：它先给的是这样一份东西——

## 改动计划（草案）
1. 目标：导出支持按日期区间筛选（含头含尾）
2. 文件：app/api/export.py 加 start/end 查询参数；
        app/services/export.py 查询加 WHERE 条件
3. 不做：不改返回格式，不动分页逻辑
4. 风险：日期边界（统一用服务器本地时间？）
5. 验证：新增 2 个单测 + 手工 curl 一遍

我划掉了它想顺手重命名参数的那一条，其余照单执行，十分钟收工。

审计划的本质，是把「纠错」从昂贵的阶段（运行中的代码）挪到便宜的阶段（几行文字）。

什么时候不必这么重

改一两行、影响面一目了然的小事，直接让它动手就好。我的判断标准是三条：改动是否跨文件、是否触碰核心路径、错了是否容易发现。三条里中了两条，就值得先要一份计划。

· 完 ·