用 Claude 结对搭博客：从聊设计到上线的复盘

昨天这个站上线了。《开博记》里讲了为什么要写博客，这篇把另一半讲清楚：站是怎么搭的。说”用 AI 建了个博客”很容易让人以为是一句话生成一个站，实际过程不是那样，值得复盘一下。

先聊设计，不急着写代码

整个过程里花时间最多的其实是聊。风格选什么、首页信息怎么摆、要不要中英文切换，这些都是来回讨论出来的，不是我丢一句”帮我建个博客”就开工。

有个决策我印象很深。我想要评论区，方案选了 giscus——它把评论存在 GitHub Discussions 里，博客本身不用碰数据库。但 giscus 要求仓库公开，而我的博客源码仓库想保持私有，两个要求撞上了。讨论出来的解法很简单：另建一个空的公开仓库，只开 Discussions，专门放评论；源码仓库照旧私有。这种矛盾如果直接让 AI 闷头写，大概率是它替我做一个我没意识到的取舍，事后才发现。聊出来的好处就在这，取舍是我自己拍的板。

聊完的东西落成了两份文档：一份设计规格，记下所有拍板的决策；一份实施计划，把开发拆成八个小任务——脚手架、布局和主题切换、首页卡片、文章页、RSS、双语界面、评论、首批内容，再加上建仓库和部署。后面所有开发都对着这两份文档走，没有临场发挥。

任务拆小，一个一个验收

八个任务是串行交付的，每个做完我看一遍 diff 再进下一个。任务拆得小，是为了让”看一遍”这件事真的可行——diff 大到看不完的时候，审查就变成了走形式。

我在这个过程里没写一行代码，做的是三件事：定方向、审代码、挑毛病。挑出来的毛病都很具体：窄屏下页头会横向溢出；首页为了视觉效果没放 h1，可访问性上不合格，补了一个视觉隐藏的；切到英文界面时主题按钮偶尔还显示中文，查下来是两段初始化脚本的执行顺序问题。这些没有一个是”AI 不行”的证据，人结对写代码一样会漏，区别只在于有没有人负责把它们找出来。

让”发现错误”自动化

比逐个挑毛病更重要的，是搭一层自动化的兜底。仓库里有个 verify 脚本，每次构建完自动检查产物：标了 draft 的草稿绝不能出现在线上，所有路由都得真实生成。这个脚本本身也返工过一轮——最早的版本用字符串匹配找 draft 标记，大小写不同或者标记写在注释里就会漏判，后来改成了老老实实解析 frontmatter 字段。

部署脚本把整个链条串起来：verify 不过就不上传；上传完再把线上每个路由 curl 一遍，确认都返回 200 才算完。和 AI 结对，我最实际的体会是：不用怕它写错，要怕的是错了没人发现。人工审查覆盖不了每一次改动，就把最不能出错的几件事写成断言，让机器盯着机器。

复盘

回头看，这次结对里人的价值不在敲代码——那部分 AI 干得又快又好——而在三个地方：把需求聊透、在矛盾处拍板、给产出验收。约束给得越清楚，拿回来的东西越靠谱；约束给得含糊，返工就多。这个经验不只适用于搭博客，往后和 AI 协作做别的事，大概也是同一个道理。

这个站现在就跑在这套流程上，连你正在读的这篇文章，发布前也要过一遍同样的 verify。