我是怎么用 AI 编程助手 30 天搭出三个站的

过去 30 天，博客体系、渡劫code、个人官网站点全部推到了公网可访问状态。三个站背后是一万二千行 TypeScript、18 篇文章、3 条 GitHub Actions 工作流、4 张 D1 表。工作量是真的，但坦诚说：其中相当比例的第一稿出自 AI 编程助手。这篇复盘不神化也不甩锅——只讲哪些该它做，哪些必须我扛，以及一套救过我们多次的代码审查纪律。

先说清楚：30 天搭的不是从零开始

博客有 Hexo 时代的老底（第一篇文章写在 2024 年 12 月），渡劫code 也有一个多月的迭代。这 30 天做的是「从能跑到能发布」：评论系统、三端同步、SEO 治理、文章工程化、移动端适配全部落地。把 AI 的功劳记账成「30 天从零造三个站」是不诚实的——真实叙事是「30 天把三个半成品推到可公网访问，AI 是这期间的主力工人之一」。诚信这条铁律，复盘文里先立着。

该 AI 做的：机械劳动的全面外包

判断标准很清晰：有明确对错、模式重复、错了立刻可见的活，全给 AI。博客前几篇手写 HTML 迁移到 gen_posts.py 模板（见 SEO 全流程），这种枯燥到反人类的活是人类犯错率最高的地方——复制漏一个 canonical、漏一段评论区——恰恰是 AI 的主场。它不知疲倦，也不会在第 20 次复制时走神。

不该 AI 做的：决策、安全与发布

• 架构决策：D1 还是自建 Postgres、自建评论还是 Giscus、每端独立的回滚路径——这些问题的关键信息在约束里而不在代码里。AI 看不到「国内读者打不开 GitHub Pages」这种真实约束，它的建议永远偏向「技术上更优雅」而不是「处境上更合适」
• 安全代码：JWT 验签、限流窗口、CORS 白名单、访客指纹脱敏——这些逻辑「看起来对」和「对」之间的差距最大。AI 能写骨架，但白名单该放谁、异常该返回什么、密钥丢了怎么办，必须人来定（边缘安全四件套就是这么来的）
• 发布动作：push、部署、开 Pages 服务、DNS 变更——每一发都该是人按下的。有意思的是，渡劫code 本身就把「人工审批」做成了产品功能（五状态机与审批闸门），自己用 AI 时没理由降级标准

代码审查：一套救过我们多次的纪律

AI 生成代码的审查成本和手写不同——它没有「当时怎么想的」可以问，只能全靠读。我们的流程固定五步：

1. 先看 diff 规模：一次改动超过五百行，退回重来。AI 擅长小步快跑，逼它一次吞一头象，产出必然虚胖——大 diff 是人类审查失守的头号原因
2. 安全相关逐行：涉及鉴权、限流、SQL、CORS 的 diff 逐行读，不抽样。这类代码的正确性幻觉代价最高
3. 类型即测试：TypeScript strict 加 Bindings 全类型（见 Hono 工程化），让编译期先拦一批——类型系统是 24 小时不睡觉的初审员
4. 跑起来再信：任何「已实现」的声明，以 wrangler dev 里的真实响应为准、以 curl 的状态码为准——不以聊天记录为准
5. 悬疑命名法：变量名看起来太顺、注释过于完整、边界情况一个没提——这三种「过度整洁」反而是重点审查信号，它在用流畅度掩盖没想清楚的部分

最典型的一次教训：限流逻辑的 KV 计数 TTL 差一点覆盖不满整个滑动窗口，测试全绿、逻辑「显然正确」，是审查时对着分钟桶公式手推一遍才发现的。AI 写的正确性幻觉，只有人对数学。从此定下规矩：凡是涉及窗口、并发、时间、金额的代码，人手推一遍边界，不省这一步。

人机分工的最终形态

30 天下来，我的角色从「写代码的人」变成了「定约束、审产出、按发布钮的人」。三个站能上线，不是因为 AI 强，而是因为约束定得细——Env 接口注释写清每个绑定存什么，错误信封全项目只有一种，发布链路每条 ref 都显式。AI 在细约束里产出质量极高，在模糊地带产出的是看起来能跑的债。欠下的债不会消失，只会在凌晨的告警里连本带利。

如果重来一次，我会更早做两件事：更早写全类型定义，让 AI 从第一天就在笼子里跳舞；更早把「跑起来验证」设为唯一验收标准。工具不会替代判断，但会放大判断——包括放大你的懒。渡劫还长，AI 是剑，握剑的还得是人。