企业官网建设流程全解析

用了 Claude Code 一段时间，经手了几十个项目，有自己折腾的，也有跟团队一起干的。踩过的坑不能算少，下面这 7 个是最容易出现、每次都能精准命中我的那种——如果你也在用，也许可以少走几段弯路。

1. 还没搞懂项目就开始动手

这是我早期犯得最多的错误。一上来直接甩需求，Claude 也确实能干活，但出来的东西常常像“没看过项目历史的人写的”——因为它确实没看过。正所谓没有调查就没有发言权。

后来我养成了一个习惯：新建项目后，先让 Claude 去读一遍项目结构和现有约定，不急着改东西。就一个简单指令：

“先了解一下当前项目的架构和设计规范，别修改任何文件。”

花几分钟让 Claude 先“看一遍”，比后面花几小时改错划得来得多。

2.CLAUDE.md变成了一本“设计百科全书”

很多人知道这个文件有用，但不知道它应该放什么。我在一些项目里见过 500 多行的CLAUDE.md——从颜色规范到字体大小到文案语气全塞进去了。

问题是这个文件是每次会话都会加载的“常驻内存”，塞太多东西进去不仅浪费上下文，还会让真正重要的指令被淹没。

我的建议是：保持它在 200 行以内，把具体的设计细节放在单独的文件（比如DESIGN.md）里，然后在CLAUDE.md里引用它。这样 Claude 需要的时候再去读，不需要的时候不占空间。

如下

#系统设计规则与系统设计相关的请查看design.md

3. 用形容词描述 UI，不给参考图

“让它看起来更高级一点。”——这句话我说过，效果你也猜得到。

Claude 不是设计师，也不在你脑子里。只说“更清爽”“更简洁”，它的理解可能跟你完全不一样。

最靠谱的做法还是给参考图：截图、组件、已有页面——哪怕画个草图都比纯文字强。附上图片，再说明“参考这个布局的间距和颜色，应用到当前页面上”，出来的东西会更接近你想要的。

4. 想让 Claude 一次搞定整个功能

Scope 越大，Claude 给出的方案就越“通用”。你说“帮我搭一个类似Uber风格的app”——这背后可能是好几个页面、几十种状态、无数个决策点。最后你花了很多时间和金钱，最后claude也只能给你搭建一个空架子。

如果是前期探索方向，一次搞一大块没问题。但如果已经进入具体开发阶段，分步走效果会好很多：一个屏幕 → 单个组件 → 不同状态 → 响应式适配 → 细节打磨。每一步都能做更具体的调整，质量也更可控。

5. 大改动直接开干，不用 Plan Mode

即使你前面做对了——给了上下文、分了步骤——Claude 还是可能误解你的意思。最糟糕的情况是它已经开始改文件了，你才发现方向偏了。

Plan Mode 是专门为这种风险设计的功能：它会先输出一个方案，解释它打算怎么做、改哪些文件，但不会真的修改源码。看完方案觉得不对，可以纠正方向——这时候成本几乎为零。我一般会在不确定的地方先用 Plan Mode，确认方向之后再让它执行。

6. 所有事情都在同一个对话里做

调研、搭建、调试、反馈——如果都在同一个会话里做，上下文很快就满了。对话变得很“杂”，Claude 也很难在后续任务中保持专注。

更好的做法是按任务类型拆开：调研用一个会话，具体开发用另一个，调试用另一个，反馈用另一个。如果项目比较复杂，可以试试用 Subagents 来拆分不同任务，每个子代理有独立的上下文和工具权限，这样主会话不会被“拖累”。

7. 因为不懂，就把决策权全交给 Claude

“看不懂改了什么，先点了允许再说”——这种习惯很危险。Claude Code 本身有权限控制，每次修改文件或执行命令前都会请求确认，但最终“放行”的人是你。

你不一定要成为工程师，但至少要知道：改了哪些文件、为什么改、怎么撤销。看不懂的时候，先让 Claude 解释一遍再做决定。理解自己项目里在发生什么，自己才是真正掌控工作流的人，AI始终只是实现的工具。

用 AI 工具并不意味着要把判断力外包给 AI。保持对流程的清晰认知，比学会用什么模型更重要。希望这些经验能帮你少踩几个我已经踩过的坑。