Claude写了我70%代码：一个SaaS创业者的3条血泪教训

去年有个数据在开发者圈子悄悄传开：用AI写代码的人里，超过六成会在三个月后回滚重构。不是AI写得慢，是写得太快——快到架构烂掉才发现。

Sitewatch的作者最近摊牌了。这个监控SaaS的代码库，60%-70%出自Claude Code之手，现在有付费用户在跑。他把自己踩的坑写成了清单，第一条就值得所有想"让AI干活"的人贴在显示器旁边。

先规划再提示，否则三周后重写

作者早期的 workflow 很典型：打开 Claude Code，丢需求进去。"做个检查调度系统。""加重试逻辑。""搭告警管道。"AI 每次都交出能跑的代码。

三周后他傻眼了。每个功能单独看都正常，拼在一起却互相打架。错误处理有三种风格，数据模型各说各话，状态流向像 spaghetti。他被迫停下来重写架构，时间成本比一开始就规划还高。

现在的流程变了：先写 spec，再拆成块喂给 AI。数据模型、模块边界、API 表面、错误约定，全部想清楚了才动手。同一个工具，产出完全不同。

AI 是加速器，不是方向盘。没地图的时候，油门越大越危险。

80% 是陷阱，20% 才是护城河

作者描述过一个复杂需求：多区域检查支持，每个区域独立重试验证。Claude Code 几分钟给出能用的实现，大概 80% 完成度。

剩下的 20% 呢？边缘 case、失效模式、与现有代码的集成、两个区域数据冲突时的诡异行为——这些需要他的经验来填。

这个 80/20 分割本身不是问题。危险的是误以为 80% 等于"做完了"。作者的原话是：「If you assume the first output is done, you'll ship bugs.」

Sitewatch 的核心价值在于检测逻辑：CDN 怎么改写 MIME 类型、为什么 200 OK 可能意味着网站全崩、重定向链在什么 cookie 状态下会循环、同一页面从不同边缘节点返回不同内容。Claude Code 能写这些逻辑的"管道"，但判断规则来自作者的领域知识。

AI 解决 how，你负责 what 和 why。这个分工没搞清楚的人，正在把半成品当成品卖。

代码库是训练数据，前三个文件定调性

一旦作者建立了统一的模式——API handler 怎么组织、错误怎么格式化、composable（可复用组合逻辑）怎么写、状态怎么处理——Claude Code 就能稳定复刻这些约定。

前提是它得先看到。如果前几个文件风格混乱，AI 会忠实地继承这种混乱。作者的解法：前几个模块亲手写，故意做出清晰模式。让 AI 从代码库学习，再让它规模化复制。

这是 Claude Code 代码库"感觉像一个人写的"而不是"缝起来的"秘密。

有个细节他没展开，但值得玩味：当他说「Claude Code picks up conventions from your codebase」，用的是 picks up，不是 learns。暗示的不是深度学习式的理解，是模式匹配式的跟随。你的代码库就是 prompt 的一部分，而且权重很高。

这也解释了为什么有人用 AI 写代码越写越快，有人越写越乱——差距在最初的"种子文件"质量。

作者最后提到一个没人讨论的话题：Claude Code 写功能被说烂了，但没人讲怎么用它维护代码、重构、或者处理技术债。这部分他留到了下一篇。