他重建网站2次才醒悟：AI不是打印机，是设计师同事

第一次重建花了3天，第二次只花了几小时——但后者效果反而更好。这个反直觉的结果，来自一位后端工程师对AI协作方式的彻底推翻。

故事的主角叫Robb Knight，一位常年和基础设施打交道、前端技能"仍在发育中"的开发者。他的个人网站最初用Astro搭建，白字黑底，毫无个性，"功能齐全但完全记不住"。

第一次重建时，他拿到了Cursor（一款AI编程工具）， workflow 很直接：描述需求，获取方案，让AI一次性生成整个站点。结果确实比原版强：红色下划线做成毛笔笔触效果，排版更有设计感。但也乱成一团——颜色变体太多，彼此打架。最离谱的是，AI发现他提过喜欢日本美学，直接在界面里塞了汉字。

Robb不会日语。他把汉字删了。

但汉字只是症状，病根在于工作方式。他给了AI一个模糊指令（"我喜欢日本美学"），收获的是字面化解读，以及一次性生成带来的系统性混乱。没有设计系统，一切全靠即兴发挥。

从"生成器"到"协作者"：一次关系重构

Robb本可以修修补补继续用Cursor版本。但他选择推倒重来——这次换成Claude Code，并给自己设了条铁律：碰任何组件之前，先定义设计系统。

这听起来像事后诸葛亮，但当时对他并不显然。"我不是设计师，"他写道，"我能看出东西好不好，但很难搭建让设计一致的底层系统。"

他需要的不是组件生成器，而是一个会在他决策混乱时顶回来的角色。

于是他从设计令牌（design tokens）起步：背景色、文字层级、边框数值、单一强调色（Akane红，#C91F37）。规则定死之后，AI开始拦截他自己注意不到的问题：颜色变体过多、视觉语言不一致、单独看还行的图案在上下文里冲突。

「颜色太多。挑几个能搭的，坚持用。」

这种反馈，是设计师会给你的那种。Robb从AI那里得到了。

协作式开发的3个实操细节

Robb总结了第二次重建的关键差异，全是执行层面的颗粒度：

第一，用对话替代一次性生成。不再扔个需求等成品，而是像和同事讨论一样逐步推进。AI会追问意图，他被迫把模糊想法翻译成具体约束。

第二，让AI扮演特定角色。他明确告诉Claude："你现在是我的设计系统审核员。"角色设定改变了反馈的性质——从"你要什么我给什么"变成"这个决定有问题"。

第三，接受"慢即是快"。前期定义系统花了额外时间，但后续实现快得多。因为规则已清，AI的生成不再需要在"创意"和"一致性"之间反复横跳。

最终站点上线时，Robb的改动量比第一次少了60%，但满意度反升。没有汉字，没有打架的颜色，只有一套他真正理解的视觉语言。

一个被忽略的隐喻

Robb的经历戳破了一个流行幻觉：AI编程工具的价值不在于"生成更快"，而在于它能否填补你团队里缺位的那个角色。

对独立开发者来说，这个角色通常是设计师。对设计师来说，可能是前端工程师。对小团队来说，可能是那个会追问"这个需求真的必要吗"的产品经理。

Cursor和Claude Code的技术差异不是重点——两者都能写代码。区别在于Robb第二次使用时，把AI从"执行工具"重新定位为"思维搭档"。

这个转变的代价是前期投入：你得先知道自己要什么，才能把AI锚定在正确的方向上。第一次重建的失败，本质是"用AI逃避思考"的惩罚。

Robb在复盘里写了一句很产品经理的话：「第一次我以为问题是旧网站，第二次我才意识到问题是我的工作方式。」

这句话的适用范围远超建站。任何把AI当黑箱使用的场景——写文案、做分析、生成方案——都可能重蹈他的覆辙：拿到一个"更好但不对劲"的结果，然后在修补中耗尽耐心。

他的第二次重建只花了"几个小时"，但这个数字 misleading。真正的时间消耗发生在那之前：阅读AI辅助开发的最佳实践，观察别人怎么和模型协作，理解"协作"和"委托"的边界在哪里。

这些准备无法被AI替代，因为它们定义了AI能发挥什么作用。

Robb的网站现在 live 着，Akane红作为唯一强调色贯穿始终。没有汉字，没有多余的颜色变体，没有AI的过度发挥。访客能看到的是一个干净、有个人印记的页面——而这些印记来自他自己的决策，不是模型的猜测。

他在文章结尾留了道没回答的问题：如果当初第一次就用协作模式，能省多少时间？

但另一个问题或许更值得问：有多少人的"第一次重建"还在进行中，却以为问题出在工具上？