企业官网建设流程全解析

我第一次用 Claude Code，是在一个周五的下午。那天我以为自己只是多装了一个 AI 编程助手，但两个小时后我发现，真正让我卡住的不是“它不会写代码”，而是“我没有把要改的代码讲清楚”。

连续三次让它改动一个模块的日志规范，它都照做了，但第三次把所有无关文件的 diff 一起混了进来。我盯着终端里那一长段变更，意识到一个更关键的问题：AI 编程工具真正的门槛，从来不是“它能不能写”，而是“你知不知道自己在验收什么”。

后来我又陆续试了别的 AI 编程工具，也看了大量关于 Claude Code、智能体和“AI 让编程成为过去式”的讨论。我越来越倾向于一个判断：编程并没有成为过去式，真正正在被淘汰的，是“一个人从零手写每一行代码”的工作方式。开发者这个角色，正在从“把想法写成代码的人”，变成“定义问题、调度智能体、验证结果的人”。

这篇文章不打算复述某个访谈的内容，我更想从工程实践的角度，把 Claude Code 这类终端智能体到底意味着什么、能解决什么问题、落地时会遇到哪些坑，拆开讲清楚。

1. Claude Code 不是“AI编程助手”，它是一次操作方式的迁移

先说一个很容易混淆的点。很多人把 Claude Code 理解成“又一个能在编辑器里帮你补全代码的 AI 插件”，就像 Copilot 或 Cursor 那样。但它的工作方式完全不一样。

1.1 从“聊天框给建议”到“终端里执行”：差别在哪

传统 AI 编程助手的工作方式是“对话式的辅助”：

• 你在编辑器里选中一段代码
• AI 在旁边给你补全建议或解释
• 你决定接不接受
• 最终修改仍然由你手动完成

Claude Code 不一样。它运行在终端里，是一个能直接操作项目的智能体。你可以让它读文件、改代码、执行命令、跑测试，然后根据命令行输出继续做下一步。

这意味着它不是一个“建议者”，而是一个“执行者”。它的工作流是：

1. 你描述一个目标
2. 它自己理解项目结构
3. 它找到相关文件
4. 它动手修改
5. 它执行测试验证
6. 它把结果反馈给你

这个差异非常关键。它改变了你和工具之间的协作方式：

• 过去：你写代码，AI 辅助你
• 现在：你描述目标，AI 执行，你验收

如果你只是想要“更快地写代码”，Claude Code 不一定是最好选择。它真正适合的场景，是“你已经知道项目要往哪个方向改，但希望有人替你把重复的改动批量做完”。

1.2 它真正改变的不是代码量，而是“谁来做决定”

很多人第一次用 Claude Code 会很兴奋，因为它能一口气改好几个文件。但兴奋过后往往遇到一个尴尬场景：它改完了，你看不懂。

这不是工具的问题，而是角色变化带来的新挑战。以前你写代码，每一步都是自己决定的，你自然知道每行代码为什么存在。现在你说“帮我重构一下这个模块”，它替你做了，结果只有它自己知道每一步为什么这么做。

所以 Claude Code 真正改变的是“决策权”的分布：

• 目标由你定
• 路径由它走
• 结果由你验

如果你没有足够的能力去验收结果，那么“效率提升”就会变成“事故放大器”。一个不会写代码的人，用 Claude Code 并不会变成程序员；一个会写代码的人，用 Claude Code 才能把重复劳动腾出来的时间，放到更高层的设计上。

这其实回答了为什么“AI 让编程成为过去式”这个说法不够准确。程序员的底层能力没有消失，只是在转移。

2. “编程成为过去式”这句话错在哪，又对在哪

“AI 让编程成为过去式”这种表达，在传播上很有吸引力，但它混淆了两件事：编程的“体力部分”和“脑力部分”。

2.1 被取代的是重复编码，不是思考

编程这项活动，从来不只是“敲代码”。它至少包含三层：

1. 理解问题：别人说的需求到底是什么意思，边界在哪里
2. 设计方案：为了满足需求，系统结构该怎么调整
3. 编码实现：把方案翻译成具体代码，处理语法、接口、异常

AI 编程工具，比如 Claude Code，取代的是第三层的大部分体力劳动。它可以帮你写循环、写条件判断、处理参数校验、补日志、写测试。但前两层，尤其是“理解问题”，AI 并不能替你完成。它只能听你说，而你说得是否准确，决定了它做得是否靠谱。

所以“编程成为过去式”正确的解读不是“程序员会失业”，而是“把想法转换成代码这件事，成本会大幅降低”。这就像表格软件没有消灭会计，反而让会计能做更多分析工作一样。编程本身不会消失，消失的是“为了完成一个功能，必须先花大量时间敲基础代码”的瓶颈。

2.2 能力转移：从“写得出”变成“说得准、验得住”

当代码生成变得容易，行业对开发者的能力要求会迁移。我把这种迁移概括为四个新能力：

• 意图表达力：能不能把目标讲得足够具体。你说“优化这个模块”，和你说“把订单模块中所有打印日志的地方改成统一 JSON 格式，并去掉包含用户手机号的日志”，效果完全不同。
• 系统判断力：AI 改了 A 文件，会不会影响 B 模块？你需要在代码层面看到依赖关系，而不是只看 diff。
• 验收执行力：它说“改完了”，你要怎么验证？跑测试、查日志、手动调用接口，这是新的基本功。
• 边界管理力：哪些改动可以交给 AI，哪些必须人肉改。比如涉及数据库迁移、权限逻辑、支付流程，我通常不会直接让 AI 一把梭。

这四个能力，其实不是“不会写代码的人也能学会”的技能，而是“本来就会写代码的人，在 AI 时代更有价值”的理由。Claude Code 这类工具不会让编程变成过去式，它让“只靠写代码吃饭”的人不得不往前多走一步。

3. 从安装到跑通：Claude Code 的真实落地路径

聊完理念，回到实操。Claude Code 安装和使用并不复杂，但有很多人卡在第一步就没进去。我在各种群里看到的热门问题，很大比例集中在安装报错、连接失败、API 配置和编辑器集成上。

3.1 安装与首次登录的常见方式

按照官方常见的安装方式，Claude Code 是一个 npm 包，可以在支持 Node.js 的环境中安装：

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

安装完成后，在终端输入claude，它会引导你完成登录。登录通常有两种主流方式：

• 使用 Claude 账号订阅登录，适合个人开发者
• 使用 Anthropic API Key，适合需要按量计费或已经有 API 配额的用户

如果你已经在用 Claude 的订阅服务，直接走浏览器授权会方便很多；如果你在团队或自动化任务里使用，API Key 方式更容易集成到脚本里。

这里有一个非常容易踩坑的点：安装路径和 Node.js 环境不一致。如果你之前用 nvm 或 fnm 管理 Node 版本，安装时用的 Node 和登录时用的 Node 不是同一个，会出现claude: command not found。解决方法不是反复重装，而是先确认：

which node npm config get prefix ls $(npm config get prefix)/bin

如果你想把 Claude Code 集成到 VSCode 里，可以不用额外装太多东西。直接在 VSCode 的集成终端里运行claude，它会出现在终端面板里，这样既能编辑代码，又能和智能体对话。也有第三方扩展能做更丰富的界面，但基础场景下终端其实够用。

3.2 “unable to connect to anthropic services”到底在查什么

我注意到这个错误提示在讨论里出现频率很高，类似unable to connect to anthropic services或failed to connect to api.anthropic.com。很多人第一反应是“工具坏了”，然后到处找重装方法。

实际上，这类错误大概率不是工具本身坏了，而是请求没有到达服务端。排查时我建议严格按下面这个顺序来：

1. API Key 是否有效。如果 Key 格式不对、已过期、没有绑定支付方式，都会导致连接失败。
2. 网络环境是否正常。在公司内网、受限网络、或某些网络策略比较严格的环境里，到 Anthropic API 的请求可能被拦截。
3. Node.js 版本是否过旧。Claude Code 对运行环境有最低版本要求，版本过旧会出现一些奇怪的请求失败。
4. 代理设置是否残留。如果你的终端配置里曾经设置过 HTTP 代理或全局代理，即使现在代理已经关了，环境变量可能还指向旧地址，导致请求走到一个不存在的通道。
5. 服务端临时波动。如果以上全部正常，那就可能是服务端问题。这种情况下可以等一会儿重试，或者查看服务状态页面。

不要一看到连接失败就去卸载重装。先确认 API Key、网络环境、Node 版本，这三件事解决掉八成问题。

3.3 VSCode 接入、第三方模型路由和本地化用法

Claude Code 的正常工作方式是通过 Anthropic 的服务。但在社区里，也有人尝试让它路由到其他兼容接口。这里要先说清楚：这种用法不是官方标准路径，属于社区实践，使用前你需要自己确认接口兼容性、数据隐私和稳定性。

常见做法是设置环境变量，把模型接口地址指向兼容 Anthropic API 格式的服务：

export ANTHROPIC_BASE_URL="https://your-compatible-endpoint.example" export ANTHROPIC_API_KEY="your-api-key"

这种做法在需要私有化部署、内网环境、或者希望对接其他模型时会有价值，但它和官方原生的服务质量、响应速度、工具调用成功率都不是一回事。如果你的核心目标是稳定完成开发任务，我建议先用官方服务跑通全流程，再考虑路由切换。

至于“本地部署”，也要区分一下。Claude Code 本身是客户端工具，它需要连接模型服务。普通的“本地部署”指的是把模型服务部署在你的内网环境，然后把 Claude Code 指向它。这要求你的内网环境必须有一个支持 Anthropic API 格式的模型服务。如果只是把 Claude Code 装到本地，但模型还是走云端，那不叫本地部署，只是本地安装。

4. 跑通一个最小智能体工作流：从单次指令到批量任务

很多人第一次用 Claude Code，会直接丢给它一个很大的任务，比如“帮我重构整个项目”。结果往往不理想。这不是工具不行，而是使用方式不对。

我更建议从“最小工作流”开始，先把流程跑通，再逐步扩大任务范围。

4.1 先给项目写一份 CLAUDE.md，而不是先着急写提示词

Claude Code 支持项目级的说明文件，常见命名是CLAUDE.md。这个文件相当于你给智能体的一份“入职手册”。

你可以在这个文件里写：

• 项目的技术栈
• 目录结构
• 常用命令（比如如何跑测试、如何启动开发环境）
• 代码风格约定
• 不允许 AI 动的目录或文件

它的价值在于：让 AI 在每次开始任务前，先了解项目背景，而不是靠猜。你可以理解为“先给目录，再按需展开章节”，这样它后面的操作会更稳定，也更不会偏离你的预期。

4.2 一个可复用的四步工作流：规划、执行、验证、收尾

我现在的习惯是，任何任务都按照四步走：

第一步：规划

先让 Claude Code 描述它准备怎么改。比如：

先查看 src/services/order.js 的当前结构，列出所有需要改动的函数，说明每个改动的理由，不要直接改。

这一步能拦截掉很多方向性错误。如果它连要改哪些文件都说不清楚，后面写的代码大概率也是错的。

第二步：执行

确认规划合理后，再让它动手。这个阶段我会明确允许范围，例如：

只改 src/services/order.js 和 src/utils/logger.js，不要动其他文件。

给 AI 划定边界，比自己事后后悔要高效得多。

第三步：验证

让它自己跑测试，然后你再人工检查 diff。你需要重点看：

• 它是否只改了允许改的文件
• 是否引入了额外的依赖
• 是否有删除或注释掉的代码没处理干净
• 日志格式是否真的统一了

第四步：收尾

让它总结这次做了哪些改动、为什么这样改、有没有遗留风险。然后把这次对话中有效的约束写回 CLAUDE.md，让它下次更稳。

4.3 单任务成功之后，再谈批量任务

单任务跑通，只能说明流程没有断。真正的考验是把多个任务串联成批量工作流。

比如，你要让 Claude Code 给项目里 100 个函数补文档，或者统一改所有 API 的错误返回结构。这时候要注意：

• 拆分批次：一次接到的上下文不宜过长，分批处理比一口气全量改更稳定
• 保留中间产物：每批结果都确认后再进下一批，不要等全部跑完才看
• 设置验收标准：比如“所有函数都必须有 docstring，且不能改动函数体逻辑”

如果批量任务执行到一半报错，优先检查是不是某个文件的格式或编码特殊，而不是怪工具。这种场景下的错误，往往出在单条数据的边界上，不是流程本身。

5. 从“会用”到“敢用”：开发者真正要补齐的能力

工具用得熟，不代表你在真实项目里敢放心交付。从“会用”到“敢用”，中间还隔着几个能力层。

5.1 四层排查链路：先分层，再动手

Claude Code 在项目里报错，新手容易慌，老手会先分层。我总结了一套针对智能体类工具的排查链路：

第一层：看流程层

任务是否完整执行了？还是中途断了？它最后输出的日志有没有明确报错？如果什么都没做就退出，先怀疑是提示词描述不清晰，或者它没有权限读取文件。

第二层：看输入层

输入给它的文件路径、文本内容、命令是否正确。比如路径里有空格或中文符号，很多工具会因为解析问题失败。还有文件编码，不是 UTF-8 的文件，内容读取出来后可能就是乱码。

第三层：看环境层

Node 版本、依赖包是否完整、命令是否在当前项目的虚拟环境中执行。大部分“我在本地能用，换个环境就不行”的问题，都出现在这一层。

第四层：看工具边界层

Claude Code 能不能访问某个网络接口？能不能执行某个命令？有时候它不是不想做，而是它的执行环境不允许。

排查时最忌讳“一上来就重装”。先确认是哪一层的问题，再用最小的方式修。

5.2 验收能力比写代码能力更值钱

当 AI 承担了大量编码工作，你的核心价值变成了“验收”。但验收不是随便点一下“它改得好不好看”，而是要形成一套自己的检查清单。

我一般会从几个角度验收：

• 逻辑正确性：它实现的功能是否真的符合需求，有没有遗漏边界条件
• 代码质量：是否引入了过度设计，或者过度删减
• 安全性：是否出现了不该出现的日志输出、硬编码密钥或 SQL 注入点
• 可维护性：之后别人接手时，能不能看懂它写的代码

这套验收能力，本质上还是传统的代码评审能力，只是它的应用对象从“同事提交的代码”变成了“AI 生成的代码”。如果你以前就不擅长做代码评审，那么 AI 编程工具只会让你的项目质量更快地滑向失控。

5.3 Claude Code 的适用边界和“不适合清单”

Claude Code 很强，但它不是万能的。如果忽略边界，它会把你的项目搞得更乱。

不适合它做的场景：

• 高敏感生产环境变更：涉及支付、权限、数据迁移等，建议人工改完再做老规矩的 Code Review
• 需求不清晰的任务：你自己都不知道要什么效果，AI 更不可能替你定义清楚
• 超大范围的静默重构：一口气改几十个文件，改动前后没有任何行为变化，这种任务很难验收
• 需要强业务领域判断的地方：比如活动规则、计费策略、风控逻辑，AI 不懂业务上下文

它真正适合的场景：

• 给老代码补注释、补文档、补类型声明
• 批量调整日志格式，统一错误处理
• 把重复出现的工具函数整理成公共模块
• 生成单元测试和集成测试的初稿
• 分析一个庞大模块，输出结构说明

一句话：适合把低风险、高重复、短反馈周期的任务交给它，高风险、强决策、长链路的任务留给人。

6. 如果要在团队里推智能体，先想清楚这四件事

个人用 Claude Code 是一回事，团队或者公司层面引入智能体流程是另一回事。

最近“智能体”这个概念很火，各种智能体平台、智能体框架也层出不穷。但很多团队推动智能体落地时，第一个月很兴奋，第三个月就搁置了。原因往往不是工具不够强，而是团队对智能体的定位从一开始就是错的。

6.1 目标是流程固化，不是“替代开发者”

如果你引入智能体的目标是“裁掉一半开发”，大概率要失败。但如果你把它当作“把团队的常规操作沉淀成一套可执行流程”，思路就对了。

比如你们团队经常要做“上线前检查代码规范”这件事。以前是人肉跑检查命令，看报告，然后逐个修复。现在可以让智能体自动执行检查、生成修复建议、由人来确认。这个动作重复 20 次后，它就不再是个临时操作，而是团队的一套固化流程。

这个“先临时操作，再固化成流程”，才是智能体真正越用越值钱的地方。

6.2 权限和安全边界

AI 智能体能执行命令，意味着它有很强的能力，也意味着它有很强的破坏力。

在团队里用它之前，先定好：

• 它能访问哪些仓库
• 它能执行哪些命令（比如是否允许它执行rm -rf）
• 它能不能推送代码到远程分支
• 它能不能读取生产环境的配置文件
• 它的日志和输出谁在监控

最稳妥的做法是，先给它最小权限跑通单个任务，确认输出合规后，再逐步扩大权限。不要第一步就让它操作生产分支。

6.3 可观测性与维护成本

智能体不是跑一次就不管的脚本，它会反复使用。所以你必须保证它的每次执行过程可观测：

• 它的输入是什么
• 它执行了哪些命令
• 它改了哪些文件
• 它失败时留下了什么日志

很多人以为“写了 prompt 就等于建了智能体”，其实 prompt 只是起点，日志、失败重试、输出检查、版本管理，才是工程化落地的关键。

6.4 智能体会变成“另一个同事”，而不是“一个更好用的工具”

如果推得足够深，你会发现团队里的智能体会逐渐形成一种“协作感”——它了解项目背景，知道哪些文件不要碰，知道测试怎么跑，也记得上次改过的约定。

这意味着它已经不只是工具，更像一个“只知道项目但缺少全局判断”的同事。这时候，团队需要有人专门维护它的“记忆”——也就是 CLAUDE.md 和各种流程文档。

谁负责维护它的知识库，谁负责处理它产生的错误，谁负责验收它交付的结果，这些角色如果没有提前定义，智能体落地的经验会很快衰减。

Claude Code 这类工具的出现，让我更确认一件事：AI 没有让编程成为过去式，它只是把编程中重复、繁琐、低认知的部分外包给了智能体，而把更需要判断力、责任心和系统思维的部分留给了人。

你想从它身上获得真正价值，不需要害怕它、不需要神话它，更不需要急着让所有人“必须学会它”。你只需要在一两个真正重复的项目任务上用起来，先跑通，再优化，最后把它沉淀成团队能长期维护的流程。

这或许才是这个阶段最务实的 AI 编程落地方式。