过去一年，渡劫博客这个站点从基础设施到 20 多篇文章的产出，背后大概只有一个半人类。说得更准确点：人类负责拍板和擦屁股，AI Agent 负责搬砖。这篇文章复盘我与 AI Agent 协作的完整工作流——Spec 驱动、批量生成、人工审批节点，以及那些没人告诉你、但每个用 AI 写代码的人都会踩的坑。
先说结论：AI 放大的是判断力，不是产出量
很多人对 AI 编程的期待是"我说需求，它给我成品"。实际跑下来，这个期待既对又不对。对的部分是：一个描述清楚的任务，AI 的完成度确实高得惊人；不对的部分是：什么叫"描述清楚"，这件事本身就是工程能力。我的工作流核心就一句话：把模糊需求压缩成无歧义的 Spec，再让 AI 执行，人在关键节点验收。少了任何一环，产出质量都会断崖式下跌。
Spec 驱动：动代码之前先动文档
每个功能动工前，先有一份 Spec。不是八股文的 PRD，是一页纸，包含四件事：
- 目标：这个功能做成什么事算成，必须可验证；
- 非目标：明确不做什么，防范围蔓延；
- 验收标准：3-5 条可执行检查项，比如"curl /api/health 返回 200 且耗时低于 100ms"；
- 边界：涉及哪些文件、哪些目录不能碰。
Spec 的价值在 AI 场景下被放大了。人类程序员会自己猜需求，AI 不会——你写得含糊，它就自由发挥，而自由发挥的方差大得惊人。我们的评论系统 Spec 里有这么一条："状态流转只允许 pending 到 approved、pending 到 hidden、hidden 到 pending 三条边，其余组合一律返回 400。"有了这句，AI 生成的状态机代码一次通过；没有这句，它大概率给你画一张全连通图。
经验：Spec 写到"换一个同类项目的工程师来看，不会来问你第二遍"的程度，就可以发给 AI 了。
批量生成：模板化任务的最优解
Spec 驱动的下一个形态是模板化。当一类任务的结构完全同构时，人工逐个描述是浪费——写好一个模板加变量，批量生成。这次博客的 6 篇文章就是典型：同一个 Prompt 骨架，六个不同的主题变量，六篇一千五百字以上的正文。
但批量生成有两个前提，缺一不可：
- 模板必须经过单点验证：先用一个样本跑通全流程、人工验收合格，确认模板没问题，再复制。跳过这步直接批量，等于把错误乘以 N；
- 输出必须可批量校验：比如文章有明确的下限字数、必须的章节结构、manifest 的 JSON 合法性——这些都能写成脚本一次性检查，而不是肉眼看六遍。
# 批量校验示例：字数下限 + JSON 合法性
for f in /tmp/articles-batch-b/*.body.html; do
hanzi=$(grep -oP '[\x{4e00}-\x{9fa5}]' "$f" | wc -l)
[ "$hanzi" -lt 1200 ] && echo "FAIL $f: $hanzi"
done
python3 -c "import json;json.load(open('/tmp/articles-batch-b/manifest-b.json'))" && echo "manifest OK"批量生成的边界也要说清楚：结构同构的任务才配批量。写六篇文章是批量，设计六个不同架构不是——后者每一个都值得单独一轮 Spec 与评审。
人工审批节点：哪些必须人看
这是整个工作流里最反效率、也最不能砍的环节。我给自己定的规矩是按风险分级：
| 风险级 | 场景 | 审批方式 |
|---|---|---|
| 高 | 密钥处理、数据迁移、破坏性操作、安全逻辑 | 逐行看，命令级确认 |
| 中 | API 契约变更、状态机流转、缓存策略 | 看 diff 概要 + 关键文件全文 |
| 低 | 文案微调、样式调整、重复性模板产出 | 抽查 + 自动化校验兜底 |
高风险级没有商量空间。AI 提议一条 wrangler d1 execute --file=reset.sql 的时候，它不知道你那表里有 800 条真实评论，你必须知道。审批节点的本质是把"领域后果"的最终判断权留给人——AI 能看到代码，看不到业务。
数据：这套流程到底省了多少
拿这次 6 篇文章的批量生产做基准，对比人工纯手写：
| 环节 | 纯人工 | AI 工作流 |
|---|---|---|
| 6 篇 × 1500 字正文 | 约 18-24 小时（含查资料） | 约 2.5 小时（含人工审批） |
| 模板与 Spec 打磨 | — | 1 小时（一次性） |
| 批量校验脚本 | — | 0.5 小时（一次性） |
| 人工返工 | — | 约 0.5 小时 |
效率提升大概一个数量级，但我要主动拆穿一个幻觉：省下的时间没有变成假期，而是变成了更多功能、更多文章、更细的监控。独立开发者的时间瓶颈从"写不完"变成了"审不及"——所以下一步我准备把中风险级的审批也部分自动化，比如用另一轮 AI 做 diff 预审，人只看它标记的可疑点。
坑与对策
- 上下文腐烂：单个任务塞太多文件，AI 后半段开始"发明"不存在的 API。对策：一个任务的上下文控制在一屏内，超过就拆。我们的硬规矩是单个提交不超过 200 行改动；
- 幻觉 API 与过期知识：AI 会信心满满地写出三年前就变更的接口签名。对策：Spec 里附真实文件片段和官方文档链接，让它有据可查；
- 审批疲劳：连续看 20 个 diff 之后，第 21 个基本是闭眼签的。对策：批量任务拆批，每批不超过 5 个单元，批间休息；
- 静默偏差：AI 完成度 90%，但改了你没注意的默认值。对策：验收标准里写"未在 Spec 中列出的改动一律回退"，把"别乱改"变成显式契约；
- 模板污染：模板里一个笔误被复制到全部 6 个产物。对策：单点验证先行，校验脚本兜底，两条都别省。
结论
这套工作流跑通之后，我对"AI 编程"的理解收敛成三句话：Spec 决定上限，审批决定下限，批量只放大已经验证过的东西。它不浪漫，甚至有点工业化，但一个人维护全栈站点、持续产出内容的场景里，这套无聊的流程就是最可靠的东西。下一篇聊聊静态站性能优化的每一毫秒，那是另一个"抠细节抠到无聊"的故事。