企业官网建设流程全解析

前几天一个同事路过我工位，看我终端里密密麻麻全是文字，丢下一句：“你这是写代码还是跟电脑聊天呢？”我说：“你说对了，这一下午我真的一行代码都没写。”他以为我在摸鱼，实际上我正用 Claude Code 把一个老项目里的十几个文件做异步化重构，顺带把回归测试跑完，还补了一批单元测试。这大概就是今天想聊的核心：Claude Code 这个工具最厉害的能力，恰恰是让你几乎不需要亲手写代码。

很多人看到“Claude Code”这个名字，第一反应是“又一个代码生成器”。但我用了大半年之后，反而越来越确认一件事——它最值钱的用法，不是“帮我写一段代码”，而是让你彻底退到“提需求、定边界、做验收”的位置上。这篇文章不写代码，只讲清楚它到底是什么、我能用它在哪些场景里“不写代码”干活、它和 Codex 的区别，以及把那些安装、配置、接三方能力的坑都过一遍。

1. 一个“代码工具”最厉害的能力，反而是让你不写代码

1.1 Claude Code 到底是什么：它和聊天 AI、补全插件是三种物种

先纠正一个很普遍的误解。Claude Code 不是 VSCode 里的那种自动补全插件，也不是你把代码贴进对话框里让它“帮看看”的 AI 助手。它是一个跑在终端里的编程代理（agent），这意味着它能直接读你当前项目里的所有文件、能在你授权下执行命令、能自己编辑代码、能运行测试并读取报错，然后根据结果反复尝试，直到把任务做完。

打个比方。以前的 AI 编程工具像一本会说话的词典，你查一个词，它给你一个解释，用得好不好全靠你自己拼装。Claude Code 更像一个坐在你工位旁边的实习生，你交代清楚任务，它会自己去翻项目文档、翻代码、动手改文件、跑测试，最后把结果汇报给你。它不是一个“回答问题的窗口”，而是一个能接手整段工作的“执行者”。

这个区别非常关键。很多人装上 Claude Code 之后，习惯性地像用 ChatGPT 那样问“这段代码什么意思”，然后等它给一段文字解释。这当然能用，但属于暴殄天物。真正厉害的使用方式，是让它直接进入你的项目空间，替你完成“需要动手动脚”的工程任务。

1.2 为什么“一行代码都不写”反而是最强用法

标题里“一行代码都不写”这句话，我后来想了很久，它其实至少有三层含义。

第一层是用户侧。作为使用者，你确实不需要亲手敲业务代码了。你想让某个老接口改成异步，只需要描述需求和约束，剩下的扫文件、找引用、改调用链，全部由它完成。

第二层是执行侧。它虽然帮你写了大量代码，但对你来说，这些代码是以补丁、diff、文件修改的形式出现的。你真正要做的是审核它改了什么，而不是逐行敲出来。

第三层是认知侧，这层最容易被忽略。顶级用法是不再纠结“让 AI 生成某一段代码”，而是让它帮你理解整个项目的架构、模块关系、数据流和构建链路。你把注意力放到“这个系统现在是什么样、我希望它变成什么样”上面，写不写代码本身已经退居次要位置。换句话说，工具越强，你越要像一个架构师或产品经理一样思考，而不是像一个打字员。

2. 不写代码的日常：Claude Code 实际在替我做的五类工作

2.1 陌生项目速读：把一团乱麻讲成人话

我接手的旧项目，十个里面有九个是缺文档的。以前拿到一个陌生仓库，我习惯从 README 开始，顺着路由、中间件、模型一层层往下啃，快的半天，慢的两三天才能拼出全貌。

现在流程完全不同。在项目根目录启动 Claude Code，我敲的第一句话通常是：

先整体看一下这个项目的 README 和目录结构，然后告诉我这个项目大概做什么、 模块怎么分层、入口在哪里、用了哪些关键依赖，最后用文字梳理一条 从用户请求到数据库操作的完整链路。

它真的会自己去递归读文件，而不是等我一个个手动打开。几分钟后，它给我的结构说明比我自己翻一下午代码还要完整。我还经常追加追问：“这个get_user_factory函数到底被谁调用了？调用链是什么？”它同样能顺着函数引用一路查下去。

这种能力的意义在哪？在于把“读代码”的体力活完全外包了。人脑更适合做判断和取舍，不适合做全量扫描。过去读代码 80% 的时间都花在找和维护上下文上，现在这个时间被压缩到了几乎可以忽略。

2.2 重构与迁移：只描述目标，动手交给它

我记忆很深的一次，是重构一个存了好几年的工具脚本。里面到处都是urllib.request同步调用，还夹杂着大量time.sleep和变量命名混乱的函数。按老办法，我得开两个编辑器窗口，一边对照调用方一边改，改完再手动跑测试。

当时我在 Claude Code 里下了一个指令：

把 utils/http_client.py 这个文件重构为异步版本， 统一用 httpx.AsyncClient，失败重试三次并做指数退避， 但保持所有函数的公开签名不变，调用方不需要改动。 改完之后跑一遍 test 目录，把结果贴给我。

它花了大约两分钟，改完文件，还自己补了一个异步调用的示例。我git diff看了修改，基本不用动。整个过程我只说了一段话，没碰过键盘去写代码。

这类任务有一个经验：约束条件给得越明确，结果越接近预期。“保持函数签名不变”“调用方不需要改动”“失败重试三次”这种硬性边界，比“帮我优化这个文件”这种含糊指令有效十倍。

2.3 从报错到修复：一条龙排查链路

调试是老开发最耗神的事，也是 Claude Code 让我最惊讶的地方。有段时间一个测试偶发失败，日志里只有一句不痛不痒的异常信息，没有任何堆栈上下文。我自己排查得打好几轮日志才能定位。

后来我直接把完整报错贴给 Claude Code，补了一句：

看一下最近失败的测试和一些相关模块，找出可能导致偶发失败的原因， 先解释你的判断，再给出最小改动方案。

它顺着异常信息扫了相关模块，发现是一个全局连接池在 unittest 环境里被多个用例共享，触发了并发竞争问题。然后它把连接池改成了按需创建。那次修复之后，测试连续跑了一周都没有再复现。

这个案例说明一个道理：不要把 Claude Code 当成“只能写业务代码的生成器”，它在“定位问题—推断原因—修改验证”这条链路里的表现，往往比单点生成一段代码更惊艳。而且它的优势是整体项目上下文在手，不会像人一样排查到一半忘了别处的关联逻辑。

2.4 测试补全、代码审查、文档生成：最容易被低估的日常

除了大活，我更常用的是让它干各种“边角活”。比如，对一个没有几行测试的老模块，我直接说：

给这个模块补全 pytest 用例，覆盖正常输入、空输入、超大数值、异常输入， 以及一个边界条件的场景。写完后跑一遍，保证通过。

它会自己读模块逻辑，生成用例并执行验证。对很多团队来说，“补测试”永远排不上日程，但用这种方式，十分钟内就能把核心模块的覆盖率抬上去不少。

代码审查同样好用。我经常在 commit 之前丢一句：

帮我 review 一下当前工作区的改动，重点看并发安全、 不必要的全局状态、异常处理是否完整，以及有没有明显性能问题。

它会基于 diff 给出有参考价值的意见。虽然最后拍板还是我，但至少不会出现“提交完之后被同事在 code review 里挑出一堆低级问题”的尴尬。

还有一类容易被忽略的功能是写文档。生成 CHANGELOG、补充函数注释、把复杂的调用逻辑改写成说明文字，这种“不想干又不得不干”的活，交给它再合适不过。

2.5 示例代码讲解：读开源项目时最好的带教老师

最近热搜词里有一堆“示例代码讲解”“controlnet 代码详解”“九九网站代码大全”之类的搜索。我可以明确地说，Claude Code 在“读代码讲代码”这件事上，比任何聊天窗口都好用，因为它能直接打开那个文件，甚至打开文件所在的整个项目，而不是只能拿到你粘贴进来的片段。

比如你在开源项目里看到一段看不懂的模块，你可以说：

打开 examples/advanced_usage.py，逐段解释它在做什么， 重点讲清楚它和核心库的接口是怎么对接的，顺便说明每段代码为什么要这么写。

它会读原文件，还会带着你对项目里其他相关文件的理解去解释。这种感觉就像旁边坐了个“读过整个项目源码”的带教老师，而不是只能基于片段猜的助手。

3. Claude Code 和 Codex 到底差在哪：都跑过之后的真实感受

最近总有人拿“codex 和 claude code”“claude code 和 codex 有什么区别”当搜索词问，说明大家默认它们是同赛道竞品。我两个都实打实跑过一段时间，主观体验是：它们确实有点像，但差异比想象中大得多。

从我个人的实际体验讲，Claude Code 更像“长在你本地仓库里的编外同事”，你随时能喊一嗓子，它马上动手。Codex 则更像“你把任务外包给远程团队，等它交回一个 PR”。两者没有绝对的优劣，重本地深度开发、老项目重构、读陌生代码库，我选 Claude Code；重云端自动化、GitHub 集成、批量任务处理，Codex 也有它的位置。

版本迭代速度在 agent 领域非常快，任何“谁比谁强”的判断都有时效性。但有一点短期内很难改变：Claude Code 把“本地终端里的持续协作”这个体验做到位了，这也是我日常主力用它而不是另一个的原因。

4. 从安装到跑通：热词里关于“安装配置”的细节我都过了一遍

4.1 快速安装与最容易踩的坑

安装本身不难。macOS 和 Linux 上，最常见的方式是用 npm 全局安装：

npm install -g @anthropic-ai/claude-code

然后输claude启动，按提示登录即可。Windows 上同样可以用 npm 装，但如果你在 PowerShell 里遇到执行策略拦截，会先收到一条红色报错。解法是允许当前用户运行本地脚本：

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

然后再跑claude。还有一个高频问题是 Node 版本过低，agent 类工具普遍要求 Node 18 以上，如果你电脑上还是老版本，建议先用nvm切换到新版。

登录环节有个小提示：如果你是在企业内部网络或公司电脑上使用，订阅授权可能被组织管理员统一管控。热词里那句 “your organization has disabled claude subscription access for claude code” 说的就是这个情况。解决办法很直接：找管理员开通相关访问权限，或者切换到个人订阅环境完成鉴权。这不是工具本身的问题，而是账号权限边界问题，卡住的时候别反复卸载安装。

4.2 桌面版和 CLI 版：谁更适合“不写代码”的使用方式

最近“claude code 桌面版”也是个高频搜索词。桌面版和 CLI 的底层能力是一样的，但交互方式有区别：桌面版把对话、文件目录、diff 展示都放进图形界面里，对不习惯黑框终端的人来说非常友好。如果你是完全不想碰命令行的重度用户，桌面版能让你几乎全程用鼠标完成所有操作。

但如果你和我一样，日常本来就泡在终端里，CLI 版反而更顺手。它就在你项目目录里启动，改完文件立刻能用git diff看结果，不需要在多个窗口之间来回切。我的建议是：先装一个，用顺手了再决定要不要两个都留着。核心能力不取决于你选哪个壳，而在于你后面怎么跟它描述任务。

4.3 第三方模型接入和周边组件：cc switch、Ollama、DeepSeek 这些玩法怎么理解

热词里那串“claude code 接入 deepseek”“claude code + cc switch + ollama”“claude code skills 官方文档”，本质上都在问一件事：能不能让 Claude Code 不只用官方模型，或者让它更贴近自己的项目习惯。

先讲模型接入。Claude Code 支持通过环境变量替换 API 地址和密钥，所以只要某个模型服务兼容 Anthropic 的接口格式，就能接进来用。比如用官方 API Key 的方式配置 Anthropic 环境变量，或者接入 DeepSeek 的官方 API 接口，再比如本地部署 Ollama 跑一个小模型。这种玩法适合预算有限、或者数据敏感不想出本机的场景。但说实话，从我各自的实测来说，第三方模型在“复杂多文件重构”上的能力跟官方模型差距依旧明显。它适合做轻量任务和尝鲜，真要干重活，我建议还是以官方模型为主。

再讲 skills。官方文档里提到的 Skills，你可以理解成给 Claude Code 预置一套“职业培训手册”。你可以在项目里定义一套规范，比如提交信息格式、接口文档写法、代码风格要求、禁止事项，它会在后续每次会话里自动遵循。就像给新来的实习生先做了岗前培训再安排干活，效率完全不一样。这个功能我强烈建议团队都用起来，把规范沉淀成项目内的配置文件，每个成员启动时都能自动继承。

至于 cc switch，它解决的是“多套配置来回切换”的痛点。你可能有多个供应商的 API Key、多个模型服务、多套环境变量，手工改来改去很容易搞乱。cc switch 本质上就是一个配置切换器，让你像切换环境一样切换模型供应商。适合喜欢折腾的人，不是必需品，但折腾起来挺值。

还有一个词是 MCP，它解决的是“Claude Code 触达不到外部系统”的问题。默认情况下它只能操作文件、终端这类本地能力，但如果需要它去查数据库、操作浏览器、拉取监控指标，就需要通过 MCP 服务器作为“适配层”接入。你可以把 MCP 理解成外接设备的驱动：给装了什么驱动，它就能用什么设备。社区里已经有不少现成的 MCP 服务，接完以后，Claude Code 的能力会从“改代码”扩展到“替你查数据、看监控、发请求”的更广范围。

5. “不写代码”不等于“无脑放养”：我用 Claude Code 的工作流和边界

5.1 怎么“说话”才能让 AI 少返工：任务拆分与验收标准

很多人在第一次用这类 agent 时失望，原因往往不是工具不行，而是需求描述太模糊。你说“帮我优化这段代码”，它给你一个看起来合理的优化版本，说你没讲清楚性能要求、兼容范围、约束条件。这不能怪它，只能说你把一个需要明确验收标准的任务，甩成了一个开放式作文题。

我现在的习惯是把大任务拆成有验收标准的小块。比如重构登录模块，我会这样说：

第一件事：先梳理 login 模块现在的逻辑，用文字描述从参数校验到 最终写入 session 的完整流程，并标出风险点； 第二件事：把密码加密方式从 md5 迁移到 bcrypt，旧的 hash 保留兼容， 新注册用户一律使用新算法； 第三件事：为登录接口补充参数校验和单元测试，覆盖空密码、超长用户名、 不存在的用户三种情况。每一步完成都先跑测试，再继续下一步。

每一条子任务都有明确的完成标志。它不会自作主张把范围扩大，我也不会在验收时犯迷糊。所谓“不写代码”，背后其实是你把“思考怎么拆任务、定标准、做验收”这件事做得更细了。指令写得越清楚，返工越少，这才是真正省时间的地方。

5.2 用 CLAUDE.md 固化项目规范

我在每个长期维护的项目根目录下放一个CLAUDE.md文件，里面写清这个项目的技术栈、目录约定、测试命令、代码风格要求和禁止事项。Claude Code 启动时会默认读取这个文件，相当于每次开工前先自动“读了一遍项目文档”。

我曾经在一个项目里被它连续改了三次命名风格，后来才意识到是自己没把规范预先告诉它。写进CLAUDE.md之后，它生成的代码风格明显稳定了。如果你负责的项目有团队约定，强烈建议把这个文件当作一等公民来维护，收益远大于那几分钟的写作成本。

5.3 验收与安全检查：它改了代码，但责任在你

这是我最想强调的一点。Claude Code 是一个高效的执行者，但它不是业务责任人。它改完代码，你把 diff 从头到尾看一遍，这是必须保留的底线。我给自己定了三条强制规则：涉及数据库模型的修改，先检查迁移文件是否正确生成；涉及密钥或敏感配置的，确认 .env 文件没有被带进 diff；涉及并发和全局状态的，自己再独立 review 一遍，不看它的解释，只看代码本身。

有一次它把一个工具函数改得很漂亮，抽象层次明显提升，但我细看发现它把某个边界条件下应该抛出的异常静默吞掉了。这种业务语义层面的事情，模型再强也替你做不了最终决定。你可以不写代码，但你不能不写“思考”。

5.4 哪些场景我建议你别用 Claude Code

第一类是安全敏感的代码审计。如果公司对核心算法、密钥管理、鉴权逻辑有严格流程，那这类代码必须由真人逐行把关，AI 改完之后依然要走过完整的内部评审。第二类是教学学习场景。如果你还处于刷题学语法阶段，不建议把练习题直接丢给它生成答案，至少先自己实现一遍，再让它帮你 review 和优化。第三类是需要精确到字节级控制的底层代码。这种场景下，它的“自主发挥”往往不是加分项，反而可能引入不必要的抽象。

这里插一句：我不是说这些场景完全不能用，而是使用方式要变。学习时让它当“批改老师”，安全场景让它做“预审员”而不是“作者”，底层代码只让它生成草案、再由你逐行确认。工具是放大镜，不是免罪符，尤其是对你能力的放大。

最后说点个人体会

回到开头那个同事的问题。用 Claude Code 这段时间，我最大的变化不是“代码写得少了”，而是我愿意花更多时间去描述问题、拆解需求、设定约束条件。一个 agent 再聪明，它也不知道你脑子里那个“真正想要的系统”长什么样。所谓“一行代码都不写”，其实你写的是思路、边界和验收标准，这些比代码本身更值钱。如果你也想试试这个工具，我建议从一个小型旧项目开始，让它帮你做一次全量梳理，再顺手补几个测试。你会很快理解我说的“不写代码”到底是一种什么感受。