去年七月我写了AI 编程工具用了半年，我的结论是：别让它写完整功能。之后又写了选型、写了 Claude Code 和 Codex CLI 的对比、写了 Trae、写了「AI 是异步实习生」。五篇下来，每篇都在回答一个问题：这个工具能干什么。
没有一篇回答另一个问题：我到底是怎么用它干活的。
这次补上。这篇是这个系列的树干，下面每一节都能点进一篇具体的文章。如果你想只看一篇，看这篇；如果你想看我是怎么得出这些结论的，顺着链接往下走。
01 我为什么用 AI
不是为了写得更快。
我写代码的速度从来不是瓶颈。瓶颈是那些我不想动手的活：13 个页面逐个接同一个函数、把 7 篇文章的分类批量换掉、给一个 85 行 bash 脚本起头。这些活不难，做起来烦，一烦就拖，一拖就是两个月。
AI 真正的价值在这里：它把「不想动手」变成「顺手就做」。这个价值比省下的几小时大得多。
我把 AI 编程工具当成了替代品，这是最大的错误里我写过那个实验——把开源项目的维护全丢给 AI，自己去干「重要的事」，结果两天都在收拾烂摊子。那次之后我改了用法：它不是替代我的，是替我去干那些会把我拖住的活。
02 分工
一句话概括：AI 负责「已知问题的未知解法」，我负责「未知问题的已知边界」。
具体拆开：
| 交给 AI | 我自己来 |
|---|---|
| 机械重复的接入改造 | 决定改哪些文件、不改哪些 |
| 第一版骨架（脚本、配置、样板） | 判断骨架方向对不对 |
| 批量替换、批量重命名 | 定义替换规则 |
| 写测试、写注释、写文档 | 决定什么值得测 |
| 解释报错、给出候选修法 | 判断哪个修法不会埋雷 |
这个表不是一开始就有的。是我说过别让 AI 写完整功能，这次我把整个迭代交给了它那次迭代之后，我回头看六小时花在哪，才列出来的。
03 拆需求
我的做法很土：一句话丢给 AI，让它还我一份清单。
那次博客迭代，我给的是「未来日期的文章不该上线」，它还了 9 条。其中两条我没想到：RSS 要过滤，搜索索引也要过滤。我只想到了列表页和详情页。
清单拿到手，我自己过一遍。删掉两条不需要的，补上一条它不可能知道的约束——构建必须在北京时间零点之后跑，因为所有发布时间都写在东八区。
这里有个前提容易被忽略：AI 拆需求不是替你思考，是帮你把漏掉的角度补上。前提是你自己得先想一遍，不然你连它漏了什么都看不出来。
04 喂上下文
这是整个流程里最烦、也最值钱的一步。
我每次会话开头会贴三样东西：项目结构说明、utils.ts 里现有工具函数的写法、内容集合的 schema。外加一份约定清单——函数要短、注释用中文、日期一律带时区。
前两样它看一眼就学会了。真正要喂的是约定。
我在这上面栽过跟头。第二个会话开始五分钟，它就把第一个会话定的「日期统一带时区」忘了，生成的代码又用裸日期。我贴回约定，它说明白，第三个会话又忘一次。
不是它笨，是它每次都是新的。这件事逼出我一个习惯：
任何约定，写进文件，不写进对话。写进对话的约定不算约定。
现在这些约定躺在项目说明文件里。AI 下次读得到，我下次也忘不掉。
MCP 协议，AI 终于有了一个能用的「USB 接口」里讲的其实是同一件事的工业化版本——上下文不该靠我手动贴，该有标准接口去接。
05 让它改代码
同样的需求，两种说法，两种结果。
第一次我说「接入所有列表页」，它改了 8 个页面，漏了 archive 和两个动态路由页。我没怪它，因为是我自己说得模糊。
第二次我换成：「13 个页面，逐个列出文件名，改一个勾一个。」全改完了。
给 AI 的指令里要有名词，不要只有形容词。 「所有列表页」是形容词，「archive.astro、tags/[tag].astro、series/[id].astro」是名词。这个差别值一次返工。
工具选择上，Claude Code 和 Codex CLI：两个终端 AI 编程工具，我最终留下了哪个里写过我的分配：长期维护的项目用 Claude Code，它有项目记忆；一次性脚本用 Codex CLI，用完即走。Trae 用了一个月，字节做的 AI IDE 到底行不行那篇补充了第三种场景——中文需求、快速搭原型，Trae 的 Builder 模式确实顺手。
具体怎么选，看AI 编程工具选型，别问哪个最好，问哪个最适合你的场景。核心就一句：按场景分配，不要按工具站队。
06 Review 是工序，不是可选项
那次迭代能跑之后，我又花了一晚上查隐患，查出两个。
第一个还是时区。filterPublished 里 Date.now() 是 UTC，如果 frontmatter 写的是 2026-08-28 这种裸日期，JS 按 UTC 零点解析，换到北京时间是早上八点。定时构建凌晨跑的时候，这篇文章还没到期，得晚一天才上线。
第二个在脚本里。它用字符串比较日期：[[ "$PUBDATE" > "$TODAY" ]]。格式永远统一时才安全，哪天少个前导零，判断就错了。我给 AI 加了一条硬规则：脚本里所有日期必须 date +"%Y-%m-%d" 输出，不许手写。
还查出一个 workflow 的细节：日志没变化时不产生 commit，Cloudflare Pages 就不会重建，文章照样上不了线。加了个 --allow-empty。
Review 时我看三类东西：时区、边界条件、它没改到的地方。 语法和风格它自己会，不用我操心。
07 测试与验证
个人项目我没有完整测试套件，靠三道关：
- 本地全量构建。不是
astro build单独跑，是npm run build，因为 CI 里的检查（比如断链检查）在这一步之后 - 手动点一遍受影响的页面
- 部署完再看一遍线上
第 1 条救过我好几次。本地惯用 npx astro build 会跳过 check-links，问题只在 CI 里暴露——那次两百多个断链报错就是这么来的，根因是中文路径没做 decode。
GitHub Actions 跑了半年，这些坑我替你踩过了里有更多这类「本地过了，CI 挂了」的记录。
08 部署
我的链路是 GitHub Actions 构建 + Cloudflare Pages 分发，没有后端。AI 在这段的价值是写 yaml 和排查失败原因——它读报错日志比我有耐心。
但有两个坑它反复踩：
- 定时任务要考虑「没有变化就没有 commit」
- 任何跟日期有关的东西，先确认时区再写代码
Docker Compose 管了 12 个服务，我是怎么没把自己累死的讲的是另一条线：服务多了之后，靠 AI 记配置不如靠文件记配置。同样的道理。
09 出问题怎么办
三步：
- 把完整报错贴给它，不要自己精简
- 让它先解释原因，再给修法——直接要修法，它经常给一个能跑但不对的
- 修完问一句：「这个改动会不会影响别的地方？」
第 2 步是我踩出来的。有一次脚本时区错了，我直接问怎么改，它给了个强制加 8 小时的方案，能跑，但埋了个雷。后来我追问「如果构建发生在北京时间 23 会怎样」，它自己算了一遍，承认错了，改成统一用 TZ=Asia/Shanghai。
让它先解释，是低成本的验证。
10 我坚决不交给 AI 的事
- 架构决策。 它能给方案，不能替我选。选了要负责任的
- 数据库迁移。 个人项目没有回滚的成本预算
- 涉及钱的改动。 服务器付费配置、域名 DNS
- 删数据。 任何
rm -rf级别的命令我自己敲 - 没想清楚的需求。 我自己都说不清，它更说不清
- 最后一道 review。 这一步交出去，前面全白做
最后一条最重要。去年我说「别让 AI 写完整功能」，这句话今天依然成立。更准确的说法是：别让它一个人写完整功能。
全程参与、每段有人把关，性质完全不同。
这套流程花了多久
那次完整迭代：六小时，分三个晚上。AI 生成代码占一个半小时，剩下四个半小时是我在拆需求、喂上下文、review、排查时区。
对照手动估算七小时多。省了两三成，不多。
但账不能只算时间。分类合并 7 篇文章这种活，AI 十分钟干完，我 review 一眼就过；13 页接入这种活，换我自己会拖到周末，AI 做完当晚就上线了。
它改变的不是速度，是我的启动阈值。
这个系列的其他文章
按阅读顺序：
- AI 编程工具用了半年，我的结论是：别让它写完整功能——起点，为什么要这么小心
- AI 编程工具选型，别问哪个最好，问哪个最适合你的场景——怎么选工具
- Claude Code 和 Codex CLI：两个终端 AI 编程工具，我最终留下了哪个——工具怎么分配
- Trae 用了一个月，字节做的 AI IDE 到底行不行——一个具体工具的实测
- 我把 AI 编程工具当成了替代品，这是最大的错误——认知转折点
- 我说过别让 AI 写完整功能，这次我把整个迭代交给了它——完整项目实录
一年前我写的是工具评测，现在写的是工作流。评测会过期，工具会换代，这套流程不会——它本来就是从一次次翻车里长出来的。