用 Claude Code 29 天搭 26 个仓库：真正翻车的不是代码

一名独立开发者在 2026 年 6 月 5 日至 7 月 3 日的 29 天里，借助 Anthropic 的 Claude Code 从零搭建了 26 个 Git 仓库，累计 1549 次提交、上线 335 个页面。这篇复盘文章的核心结论是：AI 编码流水线真正翻车的地方，不是代码写错，而是系统层面的结构性失误。

项目规模与基本数据

仓库数：26 个
周期：29 天
提交数：1549 次
上线页面：335 个
日均提交约 53 次，峰值出现在 6 月 20 日，单日 122 次
全周期仅 6 月 18 日为「零提交日」，其余日均在持续推进

所有数字均来自 git 日志、会话记录与 Google Search Console。

技术栈与工作循环

整套流水线刻意保持简单：一名开发者、终端里运行 Claude Code、git 管理版本、静态优先架构。游戏与工具类项目是独立的纯 HTML/CSS/JS 仓库，站点中枢使用 Astro 框架，全部部署到 Cloudflare Workers 的边缘静态资源上，无后端、无数据库。

每个会话遵循同一循环：描述目标 → 让模型规划与实现 → 人工 review diff → 让模型在生产站点上自验 → 提交。其中「自验」环节被作者视为流水线能跑通的关键，所有失败案例都是被检查环节捕获的，而非靠运气。

模型真正擅长的部分

经典 AI 算法的快速落地。2048 求解器实现了 expectimax 搜索加角落-蛇形启发与自适应深度，在 250 局无头自对弈中，69.6% 的对局能合成 2048 块，单步耗时约 0.5 毫秒；井字棋对手使用 alpha-beta 剪枝的 minimax；Color Lines 的寻路则是标准 BFS。这些教科书算法被正确实现并快速上线。

一致性高的批量产出。335 个页面共享同一品牌系统、URL 规范与 schema 模式。一旦规范写入项目的 memory 文件，模型就能在数十个页面之间保持一致，不会出现风格漂移。memory 文件是整个流水线中杠杆最高的资产。

不厌其烦的审计任务。全站链接图爬取、跨数百条 URL 的重定向链验证、逐页对照真实 HTTP 响应做 canonical 检查，这类枯燥工作模型不会疲倦，而这恰恰是站点级 bug 最容易藏身的地方。

真正翻车的四类问题

没有一次失败是语法错误、构建失败或代码无法运行。所有问题都是结构性的——在单次 diff 里看不出来，只有把系统当整体审视时才会暴露。

1. 流水线与自己打架。作者要求做一个 word-tools 中心页，模型老老实实搭了出来，路径放在 /word-tools/，而既有工具都位于 /tools/。同一域名下出现两个定位相同查询的页面，是典型的 SEO 自相蚕食。Search Console 显示两个 URL 都在争同一组关键词，最终靠 301 合并与 sitemap 排除解决。教训是：模型只会优化「你让做的那个页面」，不会替你照顾「站点已有的整体结构」。

2. 26 个仓库、两套 URL 规范、数周的清理。部分工具以扁平文件（如 page.html）构建，另一些以目录结构（如 page/index.html）构建。Cloudflare 的资源托管对两者产生相反的尾斜杠行为，于是站点累积了大量 canonical 不一致、二跳重定向链和 Search Console 报错。修复耗掉了冲刺中两个最大的提交日（各 114 次），并产出一份书面 URL 规范与每次发布前必须跑的爬虫检查器。教训是：要求模型遵守的规范，必须在第二个仓库之前就写好，而不是第二十个之后。

3. 源码与生产环境静默漂移。游戏仓库被镜像到中枢站点用于部署。几周内，SEO 改进只被应用到生产镜像、从未回写到源仓库。危险之处在于：「同步」操作（把源覆盖到镜像）会无声地毁掉线上元数据。最终靠强制「复制前先 diff」才捕获这个问题，手动回写到两边逐字节一致。教训是：同一个文件的任何两份副本终将分道扬镳，除非有检查强制比对，否则 AI 自己不会发现。

4. 验证工具本身也在撒谎。第一次链接图审计报告了一波孤立页面——误报，因为爬虫把绝对 URL 与未解析的相对 href 直接比较。后来的 canonical 审计又报 123 处不一致——同样是误报，检查器默认文件路径等于服务路径，而 CDN 实际提供的是干净 URL。两次都是 AI 写的审计工具自身有 bug，若据此去「修复」一个本无问题的站点，反而会把它改坏。教训是：必须验证验证者本身——AI 写的检查天然继承写它那个 AI 的盲区。

经济账：约 93% 的 token 成本花在重读而非生成

冲刺期间共进行 44 个工作会话，沉淀 826 MB 会话记录。审计 token 账单时发现：约 93% 的 token 消耗并非来自生成，而是被反复重读的缓存上下文。会话越长，累积上下文越大，每一轮都要重新读一遍；当一个会话横跨多个不相关任务时，这一比例还会进一步恶化。

这一发现指向一个朴素的工程结论：把长会话拆短，能显著压低单位工作的 token 开销，也是当前 AI 编码工作流中最容易被忽视的成本优化点。