29天26个仓库：AI流水线中真正出问题的并非代码

一位开发者使用 Claude Code 在 29 天内构建了 26 个仓库、1,549 次提交和 335 个页面。该流水线采用静态优先架构，所有内容部署到 Cloudflare Workers 的边缘节点。每个会话都遵循相同循环：描述目标、让模型规划并构建、审查差异、让模型自行验证现场站点、然后提交。验证步骤至关重要——下文中的每个失败案例都是被检查捕获的，而非靠运气。

真正出问题的地方并非语法错误、构建失败或无法运行的代码。每个实际问题都是结构性的——在单独的差异中不可见，只有从系统整体角度才能发现。

第一个问题是流水线自相残杀。当要求构建一个单词工具中心时，流水线愉快地在 /word-tools/ 下创建了一个，而现有工具位于 /tools/ 下。两个页面针对相同的查询，导致了经典的SEO关键词冲突。教训是：模型针对你要求的页面进行优化，而不是针对你已有的网站。

第二个问题是URL约定不一致。有些工具被构建为平面文件（page.html），有些则构建为目录（page/index.html）。在Cloudflare的静态资产服务上，这两者的尾部斜杠行为相反，导致网站积累了规范标记不匹配、两次重定向链以及一批Search Console重定向错误。修复消耗了冲刺中最大的两天提交量（各114次），并催生了一套书面URL约定和一个预部署爬虫检查器。教训是：必须在第二个仓库之前而不是第二十个仓库之后写下模型必须遵循的约定。

第三个问题是源码与生产环境悄然脱节。游戏仓库被镜像到中心网站进行部署。数周内，SEO改进被应用于生产镜像，但从未回传到源码仓库。陷阱在于：明显“同步”操作——将源码复制到镜像——会悄然破坏实时元数据。只有在复制前进行差异检查成为强制要求后才被发现。教训是：同一文件的任何两个副本都会产生差异，除非强制进行比较，否则AI不会注意到。

第四个问题是验证工具自身也会说谎。第一次链接图谱审计报告了大量孤立页面，但这是误报：爬虫比较了绝对URL与未解析的相对href。后来的一次规范审计报告了123个规范标记不匹配，这也是误报，因为检查器假设文件路径等于服务路径，而CDN提供的是简洁URL。两次都是通过先探测现场站点然后才相信静态分析才发现的。教训是：验证验证者。AI编写的检查继承了编写它的AI的所有盲点。

经济方面：冲刺产生了44个工作会话和826 MB的会话记录。当审计token账单时，发现约93%的token消耗是缓存的上下文被一遍遍地重新读取，这些上下文来自本应分割的长会话。解决方法是不花任何成本：在任务之间清除上下文，将持久知识保存在小型记忆文件中，下一会话可以在几百个token内加载，并将“一次会话=一个任务”设为默认。

最后，该网站从257个有搜索数据的页面获得了7,320次展示和207次点击。对于一个大约五周大的域名来说，这是一个正常、健康的轨迹。最大的流量来源是2048游戏页面，该页面拥有可见的AI求解器——那里有着最真实的工程。搜索需求追随深度而非页面数量。

幸存下来的规则包括：发布前进行可重复的基准测试；任何覆盖文件的操作都必须先进行差异比较；在信任静态分析之前通过HTTP验证生产站点；在扩展之前将约定写入模型每次会话加载的记忆文件；一次会话只做一件事；安排审计以检查整个系统而非单个差异。