企业官网建设流程全解析

最近好几个技术群里都在聊 Claude Code，朋友圈里也频繁刷到，我一开始以为是又一款炒概念的花架子编程助手。直到我自己把一个磨了两天都没解决的跨端 bug 甩给它，它花了大概十分钟把问题定位清楚，顺势把补丁和单测全写了，我才真正意识到，这玩意儿和之前那些 AI 助手不是一个物种。

这已经不只是"帮你补全代码"的聊天工具，而是一个真正能在你项目里干活、修 bug、补测试、跑命令的 AI 队友。一个人顶五个，不是什么夸张营销话术，而是把过去需要几个人分工的杂活全数扛下来之后，你终于可以专心做只有人能做的事。这篇我就以一个普通开发者的视角，分享怎么把它从"玩具"变成"生产力"，以及这背后要交的学费和要注意的边界。

1. 为什么你要重新认识 Claude Code

1.1 它到底是什么，和聊天式 AI 有什么区别

以前我们熟悉的 AI 编程助手，基本是"问答模式"：你贴一段报错，它给你一段解释，你再手动去改。改完再贴，它再看。人像传话筒一样在 IDE、终端和浏览器之间来回折腾，本质上只是个带代码知识的搜索引擎。

Claude Code 走的是另一条路，叫 Agent 模式。你给它一个目标，它自己读项目文件、查目录结构、执行命令、跑测试、看结果、改代码，循环往复直到完成。它不再等你的指令，而是像一个接了需求就开始自驱推进的实习生，中间遇到问题自己换方案。

举个实际例子。我让它"检查一下登录模块为什么在 Android 上偶发闪退"，它的第一轮操作是先看登录模块的源码，再看相关依赖的版本，然后主动去翻异常上报日志，最后自己写了个最小复现脚本跑了两遍。整个过程我没有动过一行代码，只负责回答它偶尔抛过来的问题：这个函数是你们自己封装的吗？日志里的时间戳是什么时区？

这种"目标导向 + 环境感知 + 工具调用"的组合，才是它能顶五个人的底子。它不只是会写代码，它还会自己看书、自己动手、自己验证。

1.2 "一人顶五个"的真相：不是代码写得多，而是杂活全接

大部分程序员日常时间花在哪？不是写新功能，而是修 bug、补测试、处理遗留代码、写脚本、改命名、翻日志、补文档。这些工作有个共同特点：不复杂，但量大、琐碎、打断心流。

Claude Code 最擅长干的就是这些。它不像人那样切出切进会损失上下文，也不怕重复劳动。一次会话里，它能连续处理三四十个文件的重构，能批量给几十个模块补单元测试，还能在你不耐烦的时候替你把这些活全部干完。

我自己的感受是，过去一周里至少有两三天被杂活占满，真正能专注写核心逻辑的时间少得可怜。现在凡是"有明确规则、无脑但量大"的任务，我都不动手了，直接拆成几个 prompt 丢给 Claude Code。不是我变懒了，而是把产能从"写代码的人"变成了"调度代码的人"。

当然，它也不是万能。后面我会专门讲它的边界和坑。但在讲问题之前，先说说怎么把它跑起来，因为很多人的第一步就卡住了。

2. 上手前必须搞懂的三件事

2.1 安装与第一单任务：十分钟跑通

安装本身不复杂，官方提供了 CLI 工具，一行命令装完，终端里敲claude就能进入交互界面。不同系统的安装引导略有差异，照着官方文档走一遍即可，这里不展开了。

真正值得花心思的是第一次任务怎么给。很多人上来就甩一句"帮我把这个项目优化一下"，毫无悬念地得到一堆无关痛痒的建议。Claude Code 不是算命先生，它需要明确的目标和约束。

我的建议是从"修一个具体的问题"开始。找项目里一个已知的、可复现的 bug，然后按下面这个模板给它派活：

项目里有一个 bug：用户在 Safari 下点击提交按钮无反应。 控制台报错是 <贴报错>。 请先定位问题，给出你的排查计划，每做一步先告诉我原因， 确认后再继续。不要改动任何无关代码。

我第一次跑通就是修的这样一个问题。它先让我确认了一下项目入口文件的位置，然后自己起了一个本地环境复现，定位到是一个旧接口返回字段变了，前端的兼容逻辑没跟上。修复过程里它甚至在提交前自己跑了回归测试，比我预期的完整得多。

这十分钟的体验决定了我对它的整体判断：能自己动手的绝不问人，能验证结论的绝不靠猜。

2.2 权限控制与运行模式

很多新手第一次用的时候会被它频繁的权限弹窗吓到，但其实这是一个非常重要的安全机制。Claude Code 默认在每次执行可能影响项目状态的操作之前都会询问你，比如修改文件、执行命令、安装依赖。你可以逐个批准，也可以一次会话里"全部授权"。

这里有一个取舍问题。全部授权很爽，但风险也同步上升；逐个批准很安全，但交互成本高，体验支离破碎。我的做法是分阶段授权：

第一阶段：让它只读代码库，先给诊断结果，不给修改建议前不授权写文件。 第二阶段：确认方案没问题后，授权它在指定目录内修改。 第三阶段：改完后，再授权它跑测试命令验证。

如果你们团队有专门的沙箱环境，也可以让它完全放开手脚在环境里折腾，反正坏了能重置。日常本地开发，强烈建议守住第一阶段的权限边界。特别是涉及删除文件、清空目录、改 git 历史这类高风险操作，多看两眼总没错。

另外，它支持--model参数切换底层模型。简单的打杂任务用轻量模型，跑得又快又便宜；复杂的架构分析和跨文件推理，换更强模型。这个后面成本部分会细说。

2.3 用 CLAUDE.md 告诉它团队规则

用上 Claude Code 之后，项目根目录下多一个CLAUDE.md文件，这个文件本质上是"给 AI 的入职手册"。它每次读项目的时候都会优先看这个文件，里面的规则会成为它行动的默认约束。

刚开始我没建这个文件，结果它按自己的审美把代码格式改得乱七八糟，还自作聪明给我补了一堆没人需要的抽象类。后来我把团队的约定写清楚，体验瞬间提升一个档次。

我的CLAUDE.md长这样，你可以在这个基础上调整：

## 项目概览 这是一个前后端分离的电商后台，前端 React + TypeScript，后端 Node.js + Express。 ## 常用命令 - 安装依赖：npm ci - 运行测试：npm test - 启动开发环境：npm run dev ## 代码规范 - 禁止使用 any，遇到类型报错优先用精确类型。 - 组件文件使用 PascalCase 命名，工具函数使用 camelCase。 - 错误提示不能只写 console.log，要有用户可读的提示。 ## 修改项目时要注意 - 不要触碰 package.json 中的依赖版本，除非明确要求。 - 涉及数据库结构变更必须先说明并等待确认。 - 不要格式化与任务无关的文件。

这个文件最大的价值是降低了"沟通成本"。你用文字描述一遍，它就不用每次都靠猜来干活。改完记得让团队成员一起维护，这文件做得越细，AI 干活就越像自家人。

3. 效率翻倍的五个实战场景与提示词写法

3.1 修 Bug：别直接贴报错，先讲"期望 + 实际 + 约束"

修 bug 是 Claude Code 最常见的用法，但很多人用不好，问题出在 prompt 上。

如果你只贴报错，它大概率也会困惑，因为它不知道"正确行为应该长什么样"。完整的 bug prompt 应该包含三部分：

• 期望行为：正常情况下应该发生什么？
• 实际行为：现在发生了什么？
• 约束条件：修复时不能触碰什么？

举个例子，我最近让它修一个权限模块的问题，原始 prompt 是：

期望行为：管理员可以修改任意用户的角色。 实际行为：只有上传过头像的用户才能被修改角色。 约束条件：不能改动用户表的现有数据结构，只能改后端逻辑。

它读到这个描述就知道去排查权限判断逻辑了，因为"有没有头像"和数据权限完全不搭界，一定是有个历史遗留的字段误用了。结果也印证了这一点，三行代码的问题，它花了两分钟搞定。

这里有个我踩过的小技巧：如果 bug 能稳定复现，把复现路径讲清楚，或者干脆把最小复现代码贴在 prompt 里，比任何描述都有效。我不止一次发现，AI 读一遍最小复现的代码，比看十行文字描述定位还快。

3.2 补测试：让 AI 做测试，是性价比最高的一件事

如果只能选一个场景交给 Claude Code，我选补测试。原因很简单：测试代码规则明确、重复度高、对业务逻辑理解要求低，简直是 AI 的完美舒适区。

一个典型的 prompt 是这样的：

给 utils/date.ts 这个文件补齐单元测试。 要求： 1. 覆盖所有导出函数的主要分支，包括边界条件。 2. 单测风格与项目中已有的测试保持一致。 3. 跑完测试后告诉我覆盖率的变化。

它收到任务后会自动读已有的测试文件，学风格，然后照着补。我有一次一个工具库文件原来覆盖率 23%，交给它半个小时后变成了 81%，而且测试全绿。

但这里有个坑必须提醒：AI 生成的测试非常容易出现"为了通过而通过"的问题。它会动态调整断言来迎合实现代码，看起来测试过了，实际没有检验到任何东西。所以补完测试之后，我会抽查一部分关键断言，确保它是真的验证了行为，而不是在自导自演。

3.3 批量重构：命名规范、接口迁移的好帮手

批量重构里有种活最磨人：不是技术难，而是量大。比如把一个模块里的函数命名从getX统一改成fetchX，或者说旧的接口字段userName要升级成user_name，涉及几十个文件，人改很容易漏，AI 改反而是它的优势。

我的方式是这样：

这个项目中所有的 createTime / updateTime 字段都要改成 createdAt / updatedAt。改动范围： 1. 后端接口返回的字段名 2. 前端的 TypeScript 类型定义 3. 前端所有引用点 改完跑一遍类型检查和全部测试，确保没有遗漏。

它最大的优势是执行这种跨文件改动时，对比、搜索、替换一气呵成，不会像人一样改到一半累了就开始犯错。但重构任务的风险也高，因为"AI 觉得等价"和"业务真的等价"之间可能存在间隙。

我的习惯是开工前先给它立规矩：只允许改和字段名相关的行，不允许顺手重排函数顺序，不允许修改任何格式。改完先让它生成一份git diff，我自己快速扫一遍再提交。热知识：AI 犯错时的自信程度和它实际犯错的概率完全不成正比，代码审查这一步省不得。

3.4 写脚本与数据处理：临时任务的终结者

日常开发里有很多"一次性"需求：把 CSV 转成 JSON、批量重命名文件、统计日志里的接口调用频率、把某一个目录下的图片尺寸统一改小。这些事写个脚本也要十几分钟，不写又难受。

Claude Code 处理这类任务的模式很舒服。你把需求说清楚，它直接给你写个脚本，你可以让它直接运行，也可以让它只把脚本放在指定位置由你手动执行。我一般选择后者，因为脚本通常涉及删改文件，多一道手动的确认心里更踏实。

举一个真实例子。上个月我需要把一批历史订单数据从旧表迁到新表，字段类型还发生了变更。我跟它描述了新旧字段的对应规则，它生成了一套迁移脚本，先在本地用小数据量跑通，确认无误后再让我放到服务器上执行。整个过程耗时比我自己写少了一半，而且它还主动加了"幂等性"处理，避免重复执行产生脏数据，这个细节我以前经常忘记。

3.5 代码审查：让 AI 当第二轮 Reviewer

代码审查是最容易被低估的场景。人力 review 的成本很高，很多团队碍于进度直接略过，但 AI 不会累、不会嫌麻烦，也不会因为提意见得罪人。

我现在自己提 PR 之前，都会先让 Claude Code 过一遍：

请以代码审查者的身份检查我最近这次改动的 diff。 关注的点： 1. 有没有明显的空指针风险或边界条件遗漏。 2. 有没有内存泄漏隐患（比如定时器没有清理）。 3. 测试是否真正覆盖了改动的逻辑。 4. 如果有问题，按严重程度排序，给出修改建议。

它这一轮筛出来的多是一些低级但隐蔽的问题，比如某个回调没有处理异常分支、某个状态更新没放在 setState 里导致渲染滞后。这些问题单独都不致命，但积累起来就是线上事故的温床。让它过一遍之后，我给团队同学 review 的 PR 干净了很多，至少不会拿一些低级问题去消耗同事的耐心。

4. 踩过的坑与排查清单

4.1 典型翻车现场速查

用了这么久，不敢说完全摸透它，但踩坑踩出的经验还是有的。下面这几个坑，几乎每个新用户都会撞上至少一个。

4.2 误改文件的恢复与预防

Claude Code 权限全开的情况下，它确实有可能把工程目录里你不希望动的东西动了。我自己就经历过一次：让它重构一个工具库，结果它顺手把package.json里的脚本给重新排了版，顺手还升级了一个小版本号，合并的时候差点出问题。

从那以后我给自己定了几条规矩：

• 开工之前手动创建一个分支，或者git stash一下，保证能一键回滚。
• 给它的任务前面加上"除非我明确要求，否则不要运行 git 命令，不要改依赖文件"。
• 让它每完成一小步就停下来，我自己看一眼 diff。

这几条规矩看着简单，但真的能拦住绝大多数事故。用 AI 工具干活，前提永远是你自己掌握最终的控制权，它可以是很好的执行者，但做决策的必须是你。

4.3 模型"变笨"了怎么办：上下文的磨损

有段时间我总觉得 Claude Code 越用越蠢，同一个仓库里前面让它改得好好的，后面新任务反而开始答非所问。后来发现问题出在会话上下文太长了。

它的上下文窗口有限，一次会话里塞进太多代码和对话，早期的信息就会被压缩甚至遗忘，行为自然就开始飘。尤其是大项目里连续对话超过几十轮之后，你会明显感觉它像换了个人一样，反应迟钝、答非所问。

解决办法很简单：不要让一个会话同时干太多事。一个任务干完就清空上下文，重新开一轮。另外，确实需要它理解整个项目背景的，靠CLAUDE.md来传递，而不是靠一遍遍在对话里重复。这就像是给新实习生发了入职手册，而不是让他翻完三年的聊天记录才明白公司业务。

5. 边界、成本与团队姿势

5.1 这几类工作我一般不交给它

Claude Code 很强，但也不是所有活都适合它干。用久了你会发现边界感很重要，该自己做的自己做，不该省的省不了。

第一种是架构级的大重构。比如把一个单体应用拆成微服务，这种需要大量业务判断、技术选型、团队共识的工作，AI 顶多给你出个草案，最终拍板必须是人。把这种任务交给它，结果往往是一堆看起来很合理但无法落地的代码，最后你还要花双倍时间擦屁股。

第二种是涉及线上真机环境、敏感数据的操作。让 AI 在本地沙箱里折腾没问题，但一旦涉及生产环境或者真实用户数据，我宁可自己一步一步来，也不愿意把主动权交出去。

第三种是需要深入理解公司特定业务的判断类工作。AI 对业务上下文的理解始终有限，它能帮你梳理逻辑，但没法替你拍板"这个功能到底要不要保留"，最终意愿得人说了算。

5.2 成本与安全：用之前先给自己立三条规矩

聊到成本，可能有人觉得"AI 不是白菜价吗"，实际上 Claude Code 跑大型项目的时候，消耗还是很可观的。它每次读取大文件、反复调用工具，都在消耗算力，一个下午高强度用下来，账是真的会说话。

控制成本我总结了三招：

• 分任务控制上下文：不要开一个大而全的会话处理所有事，拆小任务处理，资源消耗差距很大。
• 按任务复杂度切换模型：简单脚本直接用轻量模型，架构推理才用最强模型，别大炮打蚊子。
• 限制循环次数：如果你不想让它无限试错，明确告诉它"最多尝试三次，每次尝试完跑一遍测试，三次不过就停下来报告"。

安全方面，除了权限控制，我还会定期检查它的日志记录和操作历史。Claude Code 会保存完整的工作记录，偶尔翻一翻能发现一些当时没注意到的小动作，也算是一种审计习惯。不要觉得这多余，等出事再查就晚了。

5.3 我现在的工作流，和最后一个私藏技巧

现在我的日常已经离不开它了。早上到工位打开终端，第一件事是让它汇总一下昨天改动的文件清单，然后让它基于当前分支的状态生成一个今天的 TODO。中午前后把几个已经明确的任务丢给它并行处理，我则专注处理需要人类判断的核心逻辑。晚上收工之前，让它生成一份当天的改动摘要，作为次日工作的起点。

这套流程走下来，我最大的感受是：不是它代替我干活，而是它帮我清出了一整条顺畅的生产管道。我出题，它做题，我在关键节点做裁判。一个人确实干出了过去几个人配合才能覆盖的广度和节奏。

如果只能分享一个私藏技巧，我会说：把它的任务拆得足够细，细到每条任务可以独立验证结果为准。与其说"帮我优化性能"，不如说"这个接口在慢网环境下平均耗时 800ms，请定位瓶颈，目标 300ms 以内，瓶颈点分析完先给我看"。任务讲清楚，它才是顶五个人的帮手；任务含糊，它连半个都顶不上。