企业官网建设流程全解析

那条推文我前后看了三遍，标题里直接写着“万赞心得”，作者自称是 Agent CTO，聊的全部是 Claude Code 实战心得。第一遍看觉得是在炫技，第二遍才发现人家是真的把 Claude Code 当成了一套完整的工作方法论，第三遍我决定把整篇推文精校成中文，再结合自己这几个月的实践，在真实项目里逐条验证。这篇“中文精校版”就是这么来的——不是简单翻译，而是把几十条推特经验消化成可以直接照着做的清单，并且额外补了一堆我在 AI Agent 开发里亲测踩过的坑。

如果你最近在折腾 Agent 开发，或者只是听说过 Claude Code、还没想清楚它到底能干什么，这篇值得看完。它不是官方文档的复读，而是我和那位推主共同验证过的实操心得。适合的人群很明确：想把 Claude Code 插进日常工作流的开发者、正在搭 Agent 框架的工程师、以及所有受够了“人工改几十个文件”这种脏活的人。

1. 为什么一个管 Agent 的 CTO 会专门写 Claude Code

1.1 它真正解决的痛点是“长链路脏活”

做 Agent 开发的人应该都有同感：大部分时间不是在写算法，而是在处理“把 A 模块接到 B 模块”“改完这个配置发现另一个地方没同步”“代码能跑但一并发就崩”这类脏活。一个像样的 Agent 项目，随随便便就是几十个文件，里面有工具调用、记忆管理、路由逻辑、外部 API 对接，改一个点往往牵动一整条链路。

我在好几个项目里最耗时的就是这种多文件协同修改。传统 IDE 的补全插件在这种场景下几乎没有帮助，因为它只盯着你光标所在的这一小段代码，根本不知道整个项目的上下文。Claude Code 不一样，它是跑在终端里的一个智能体，有权限读文件、改文件、执行命令，看到报错之后还能自己再跑一遍验证修复结果。那位推特博主反复强调的核心观点是：这玩意儿不是“给你补全代码的输入法”，而是“会自己动手的结对工程师”。我当时看完那句，心里第一反应是“说得夸张了”，但真正用了一个月之后，我觉得他说得还保守了。

Claude Code 擅长的是把“需求→读代码→改代码→跑命令→看报错→再修”这条闭环自己走完。传统 AI 编程工具是“你负责拆解，它负责补全”，而 Claude Code 是“你把目标说清楚，它负责把中间那段最脏的路走完”。这恰恰是做 AI Agent 时最需要的辅助——因为 Agent 项目本身就是一堆逻辑链路拼起来的，每一步都涉及大量跨文件改动。

1.2 Claude Code 和 AI 补全插件根本不是一类东西

很多第一次接触 Claude Code 的人都会拿它跟 Copilot、Cursor 的补全功能对比，这其实从一开始就跑偏了。补全插件是“你能写，它帮你加速”，顶多帮你生成本地函数、补个单元测试，但它不会主动去翻你的项目结构，也不会因为你在改 A 文件而顺手把 B 文件的引用同步改掉。

Claude Code 的定位完全不一样。它默认你有一定的编码能力，它干的活是“工程师”而不是“输入法”。举个我常用的例子：有一次我需要把一个单体 Python 服务拆成几个模块，涉及十几个文件的 import 调整和配置迁移。如果用补全插件，我得自己打开十来个文件，逐个复制粘贴再改逻辑；但用 Claude Code，我只需要把目标说清楚，它会自己列出受影响文件清单，逐个修改，然后跑测试确认没有破坏原有功能。中途我还能随时喊停、看它的计划，甚至可以让它把所有改动写进一个 diff，我检查完再决定合不合并。

这也是“为什么是 Agent CTO”来写这套心得的原因：做 Agent 的人天然对“智能体如何拆解任务、如何管理上下文、如何自主行动”有深刻理解。Claude Code 的核心与 Agent 是同构的，他会把 Claude Code 当成一个真实的 Agent 来调教，而不是当成 IDE 插件来安装。

1.3 什么情况下它真的物有所值

我整理了最适合用 Claude Code 的几类场景，供你对照：

• 多文件重构和架构调整：拆分模块、迁移目录、统一错误处理等。
• 接入第三方 SDK 和 API：比如给 Agent 项目接模型服务、接向量库、接外部工具，需要大量查阅文档并编写胶水代码。
• 修复疑难 bug：把完整报错丢给它，让它从报错点反向追踪代码逻辑。
• 生成测试和边界用例：让它理解现有代码后，补上你没想到的异常分支。
• 跨语言脚本处理：比如要写一个 Python 脚本批量改 JSON、再生成 TypeScript 类型定义这类活。

不适合的场景也很明确：超大型仓库且你明确要求它“全仓扫描”时，容易上下文爆炸；涉及严格合规审查的核心模块，AI 改完必须人工逐行 review；再就是你自己都不知道需求是什么，指望 Claude Code 帮你把模糊想法变成产品——它能做原型，但不能替你做产品决策。

2. 上手 101：从安装到跑通第一个真实任务

2.1 安装与认证：官网下载和命令行两种姿势

安装本身没什么复杂的，我给出两种最主流的方式。第一种是直接用 npm 安装，这是社区里最常用也最方便升级的方式：

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

第二种是去官网下载安装包，适合不太喜欢用 Node.js 生态的开发者。安装完之后，第一次运行claude会引导你完成认证。个人使用可以直接用 Claude 账号登录，走订阅额度；如果是团队使用或者有自动化需求，更推荐设置环境变量ANTHROPIC_API_KEY，这样在 CI 里也能跑。

提示：改完环境变量记得重启终端。我试过在 session 里直接 export，然后发现同一终端里运行没问题，但是 IDE 内置终端一开就提示认证失败，折腾了半天才反应过来是环境变量没同步过去。

另外一个容易忽略的点：如果你公司网络环境里有自定义证书、或者某些安全软件拦截了终端进程的 HTTPS 请求，第一次连接时可能报证书错误。这种情况不是工具的坑，是网络环境的问题，需要让你的 IT 部门把 Anthropic 的域名加白，而不是反复重装。

2.2 第一次启动：让它先读代码再动手

很多人第一次用claude进入项目后，张嘴就是“帮我在这个项目里加一个登录功能”——然后发现它表现得很差，于是得出“Claude Code 也不过如此”的结论。真实原因很简单：你还没给它建立上下文，它就进入了一个几千个文件的仓库，根本不知道你这个项目是干什么的、技术栈是什么、代码组织有什么约定。

我实测下来的正确姿势是：进入项目后，先别急着布置任务，让 Claude Code 先读一遍项目结构。

cd your-project claude

在对话里先输入类似这样的话：“请先浏览项目根目录和核心配置，告诉我这个项目是干什么的、技术栈是什么、目录结构有什么特点。暂时不要改任何代码。”它会自己去读package.json、README、src/目录等，然后给你一个概览。这个步骤有两个价值：第一，它能建立对项目的初步理解，后续回答准确率明显提升；第二，你能通过它的回答看出它是否理解了这个项目的领域——如果连项目用途都说错了，那你得在后续 prompt 里补充背景，而不是默认它能“猜对”。

2.3 我推荐的三个起步命令：/init、/clear、/compact

Claude Code 内置命令很多，但我真正每天都在用的其实就三个。

第一个是/init。这个命令会在项目根目录生成一个CLAUDE.md文件，里面记录项目的结构、技术栈、常用命令、代码约定等信息。这是 Claude Code 的“项目记忆文件”，每次新会话启动时它都会自动读取。我建议每个项目都跑一次/init，哪怕它生成的初版内容不完整，之后你可以自己慢慢补充。

第二个是/clear。这个命令把当前会话的上下文清空，相当于让 AI “失忆重启”。当你发现对话已经聊偏、或者换了一个完全不相干的任务时，不要犹豫，直接/clear。旧聊天记录留着只会在后续任务里造成干扰，甚至让 AI 觉得你还在做上一个需求。

第三个是/compact。这个命令会把当前对话历史压缩成摘要，保留关键信息，释放上下文空间。它适合长任务进行到中途，你不想丢失前面的关键决策，但又需要腾出空间继续干活的情况。用/compact比/clear温和，相当于“让 AI 重新读一遍会议纪要再继续”。

2.4 和 IDE 的关系：VS Code 能用，PyCharm 也能用

网上搜“Claude Code 前端开发插件”“PyCharm 支持 Claude Code 吗”的人特别多。我先给结论：Claude Code 本质是终端工具，所以任何能开终端的 IDE 其实都能用。VS Code 有官方扩展，集成了终端面板和代码跳转，体验最顺滑；PyCharm 虽然没有官方扩展，但它内置的 Terminal 面板同样能跑claude，只是没有代码上下文联动，选中代码发给 Claude Code 之类的功能会弱一些。

我的习惯是不把 Claude Code 当成 IDE 插件用，而是单独开一个终端窗口，让它跟编辑器并行。需要改哪个文件，我在对话里用@src/xxx.ts明确指给它看。这样反而干净——AI 修改和人工修改不会同时出现在同一个文件上，不会出现“你刚改完，AI 又覆盖了”的尴尬情况。如果你真的要在 VS Code 里用，注意同一时间只让 AI 负责一个文件，不然 git diff 里全是互相覆盖的记录。

3. 实战示范：用 Claude Code 从零搭一个 Agent 项目

3.1 需求写法的差别：给方向而不是给答案

我以一个真实做过的项目为例：搭一个“读取 RSS 源，自动抓取文章并调用大模型生成摘要，最后输出 Markdown 文件”的小 Agent。刚开始我犯了一个几乎所有新手都会犯的错，直接把需求说成“帮我写一个 Python 程序”。Claude Code 确实是写了，但它只给我一个 main.py，里面所有逻辑挤在一起，完全没有扩展性。

后来我参考那条推文里的经验，换了一种说法：“在server/目录下新建一个 Agent 服务，读取 RSS 源，抓取文章正文，调用 LLM 生成摘要，输出 Markdown 文件。技术栈用 FastAPI + httpx，抓取和摘要逻辑分成独立模块。先给我一个实施计划，我确认后再动手。”

差别在于：我给了明确的技术约束、目录约束和流程约束。Claude Code 不是搜索引擎，它是执行者。prompt 里的模糊程度会直接转化为代码里失控的复杂度。你把边界画得越清楚，它产出的代码越接近你脑子里那个“合格工程师应该交出来的东西”。

3.2 让它先出实施方案：文件结构和任务拆解

在收到上面的描述后，Claude Code 给出了一份实施计划，大概这样：

1. models/source.py —— RSS 源的数据模型 2. services/fetcher.py —— 抓取 RSS 和文章正文 3. services/llm.py —— 调用大模型生成摘要 4. main.py —— 调度入口，支持单次执行 5. tests/test_fetcher.py —— 抓取模块的单元测试

我当时没有直接说“开始吧”，而是追问了几个问题：“RSS 里文章链接失效了怎么处理？”“LLM 调用失败要不要重试？”“Markdown 输出路径怎么定义？”这些属于边界条件，你得在动手之前逼它想清楚，而不是等写完了再补。这个过程其实和我平时带初级工程师做技术方案评审一模一样：先看计划，再抠细节，最后才放行。

等方案确认了，我会补一句：“先创建目录骨架，再开始写文件，每完成一个模块就提交一次 git。”这句话能让整个实施过程处于“随时可以回退”的状态，在中途发现问题时不用从零再来。

3.3 进入执行：我如何把报错“喂”给它

执行阶段最大的问题是：AI 写代码不可能一步到位，基本都会跑出几个报错。很多人在这一步又重新变回“人工坐席”——把报错信息抄下来，自己去搜索，再让 AI 改。这完全没发挥出 Claude Code 的价值。

我的做法是把报错完整丢回去，同时给它约束它的格式：“这是运行 pytest 时的完整报错，帮我定位根因并修复。先解释原因，再给修改方案，不要直接动手改。我会先看完你的解释再决定是否执行。”这样它在给出修复动作前会先思考，而不是像无头苍蝇一样改一行跑一次。

另一个小技巧是：让它把修改控制在最小范围。我会加一句“不要顺手重构无关代码”，否则它很容易把周围函数也“优化”一遍，让 review 成本飙升。这种约束对 AI 来说非常重要，因为 AI 天然倾向于“顺手美化一切”，而在真实项目里我们需要的是最小且安全的改动。

3.4 让 AI 写自己的测试，然后我们互测

功能跑通后，我做的第一件事不是庆祝，而是让它给自己写测试。这个测试不只是覆盖“正常情况”，更重要的是覆盖“异常情况”。我会故意在需求里埋一个变体，测试它的边界感：比如“如果某个 RSS 源里有一条文章的链接是空的，怎么处理？”然后让它围绕这个边界写测试。

这套测试写完，我会故意改一些边界条件再跑，看看它能不能识别出“需求变了”。这步能暴露很多 AI 在理解上的固定模式：它往往会按照“最常见的情况”去写逻辑，而不是“最健壮的情况”。在 Agent 项目里，这种边界兜底能力决定了一个系统能不能从 Demo 走到生产环境。这也是我理解推文里那句“让 AI 替你写测试，然后你再测试它的测试”的真实含义。

4. Twitter 万赞心得里最值钱的经验，我逐条验证过的

4.1 上下文预算思维：API error 400 maximum context到底怎么来的

搜“claudecode apierror 400 maximum context”的人非常多，这是 Claude Code 新手最容易撞上的报错，本质就是：你的请求内容超过了模型上下文窗口的上限。你让它在一次对话里读的代码越多、聊得越长，就越容易触顶。

那条推文里最值钱的观点之一是“上下文预算”思维：从一开始就把上下文当成一个有限的临时工作台，你要决定哪些文件被放上去。不要对它说“读一下整个项目”，而要说“读一下src/services/下面这几个和支付相关的文件，用 @ 指出来”。这样每次让它动工，它都知道重点在哪，而不是把整个仓库塞进工作台然后卡死。

我自己的补救流程基本是这样：先/compact压缩对话历史；如果还报错，就/clear开新会话；然后检查是不是自己让它一次读的文件太多，调整 prompt 改成@精确引用。这个流程治好了我 80% 的 400 报错。剩下 20% 是某些项目真的太大、单文件太长，这种情况需要手动拆文件或者把业务拆成更小的子模块。

4.2 让 Claude Code 每完成一个里程碑就主动提交

推文原文有一句话我记得很牢：“每一步都提交，你随时可以退回。”这句话听起来简单，但真正做到的人很少。大多数人在用 Claude Code 时都是“等它全部改完再一起看”，结果它改了 20 个文件，跑不起来了，你根本不知道是哪一步开始坏的。

我给它的系统规则是：每完成一个逻辑单元就执行git add + git commit，commit message 自己写，但必须遵循 Conventional Commits 格式。每提交前先跑一遍 lint 或关键测试，失败就不准提交。这个规则让整个过程完全可回溯，我的 review 压力也小了很多。说白了，这已经不是“调一个 AI 工具”了，而是在用工程管理的手段给 AI 的工作流建红绿灯。

4.3 用 CLAUDE.md 把项目常识固化下来

CLAUDE.md 是整个 Claude Code 体系里我认为最被低估的能力。你可以把它理解成“项目的长期记忆”或“给未来 AI 的工程 Wiki”。每次新会话启动，Claude Code 都会自动读取这个文件，相当于每个 AI“实习生”上岗前都会先读一遍你的团队文档。

我团队里的 CLAUDE.md 会包含这几块内容：技术栈和版本、目录结构说明、常用命令（dev/build/test）、代码规范（缩进、命名、import 排序）、已知的坑（比如某个模块初始化必须先设环境变量，否则 SSL 报错）、禁止事项（不要直接改 migration、不要动 production 配置）。这些东西写下来之后，新人用 Claude Code 的产出质量直接提升了一个档次，因为它再也不会问“你们这个项目用不用 TypeScript”这种蠢问题了。

4.4 Agent 开发里“记忆”的问题，Claude Code 给了一个轻量方案

在 Agent 项目里，“记忆”是个热门词。很多人一上来就上向量数据库、搞 embedding、建外挂知识库。但那位推主给出的建议其实非常务实：先用纯文本文件当记忆。别急着上重武器。

实际操作就是：让 Claude Code 在项目里维护一个docs/decisions/目录，每次做了重要设计决策就写一个文档；维护一个CHANGELOG.md，把完成的任务和踩过的坑记下来。这些文件既是给团队看的文档，也是给未来 Claude Code 会话的“外部记忆”——下次开新会话，它能通过读这些文档迅速恢复上下文。我在好几个中小型 Agent 项目里试过，效果很好，省掉了搭建和维护向量库的巨额成本。

5. 避坑实录：我踩过的坑和绕路方法

5.1 一次400 maximum context的完整排查链路

有一次我在一个老项目里用 Claude Code 做跨模块重构，聊到第 40 多轮时突然报了一个API error 400 maximum context，整个会话当场废掉。我当时的排查过程是这样的：

第一步，先看报错出现的位置。报错发生在一次让它“重新读一遍 models 目录下所有文件”的请求之后，我立刻意识到是自己让它读的文件太多，加上前面的聊天记录已经很长，上下文肯定触顶了。第二步，我试了/compact，依然报错，因为压缩之后它还要保留前面几十轮的计划细节，空间依然不够。第三步，我直接/clear，然后把我刚才让它读的文件清单重新只用@精确指定，每个文件控制在必要范围，问题解决。

这个案例完整还原了 400 报文的所有标准动作：能/compact就/compact保历史，不行就/clear开新会话，重点是之后修改引用方式避免复发。类比的比喻是：工作台只有这么大，你塞太多工具，新的零件就只能堆地上，最后只能停工。上下文预算就是“桌面管理”的工夫，桌面干净，干活才快。

5.2 前端项目里“该用 IDE 插件还是 CLI”的取舍

前端开发者经常搜“Claude Code 前端开发插件”，想的是能在编辑器里点两下就自动改样式、抽组件、修类型问题。我的建议是：日常逐行补全交给 IDE 里的 AI 插件，整块活儿交给 Claude Code。它更适合从“这整个页面用了三套间距体系，帮我统一成设计系统里的变量”这种全局性的任务，而不是边写边补全。

我也试过在 VS Code 里同时开着补全插件和 Claude Code 扩展，结果非常混乱。补全插件会在我输入的每一行后面给建议，Claude Code 则时不时把整个文件重写一遍，两者经常会互相覆盖。后来我给自己定了一条铁律：一个文件同一时间只能交给一个 AI 工具。要么人工改，要么 Claude Code 改，绝不同时开工。这样省掉了我大量反复清理 git diff 的时间。

5.3 接入 DeepSeek 等第三方模型的尝试与真相

社区里有很多人问“Claude Code 能不能接入 DeepSeek”，这个问题背后其实是省钱和合规的需求。我确实也试过改API_BASE_URL把其他模型接进来跑，体验确实能跑通基础对话，但一到真实项目就现原形：工具调用（tool use）经常不稳定，代码修改越来越多地出现“前后不一致”，同一个函数改了几次之后连它自己都兜不住。Debug 这种问题比省下的 token 贵得多。

我的结论是：想省钱可以理解，但如果你拿 Claude Code 来干正经开发，核心链路还是建议用官方模型。第三方模型更适合拿来实验或处理纯文本任务，别让它主导工位。这个道理跟买车差不多——发动机和车身可以选配，但刹车和转向系统最好还是原厂的。

5.4 Claude Code 和 Codex 的选择逻辑

自从 OpenAI 的 Codex 火起来之后，每天都有人问“该用哪个”。我把两个都重度用过，做一个简单的对比：

我的使用方式：新项目从零起原型，用 Codex，因为生成速度和代码风格更轻快；老项目重构、Agent 项目、需要把 AI 当“团队里读代码的那个人”时，用 Claude Code。它们不是替代关系，更像是不同工种的员工：一个擅长快出活，一个擅长盘全局。

6. 从个人工具到团队基建：Skills 和共享约定

6.1.claude/目录里能放什么

Claude Code 的项目级配置主要藏在.claude/目录里。我自己常用的结构大致是这样：

.claude/ settings.json # 项目级设置，包括权限和默认行为 commands/ # 自定义斜杠命令 skills/ # 项目专属技能定义

settings.json可以配置权限清单，比如允许读取哪些目录、不允许执行哪些命令；commands/里可以放团队自定义的斜杠命令，比如/review表示“走一遍团队审查清单”；skills/则可以把“这个项目的发布流程”写成一个可复用的提示包。这个目录建议提交到 git，让整个团队共用一套配置。我第一次搭完这套东西后，最大的感受是：团队的 AI 使用经验终于从个人脑瓜变成了公共资产。

6.2 Skills：让工具学会你项目的专属操作

社区里对 “Skills” 讨论很多，我理解的核心就是：把“这个项目应该如何被 AI 协作”的规则显式化。举个例子，我们的 Agent 项目里有一条规则：发布前必须跑一遍全部测试、更新 CHANGELOG、确认没有把调试 log 打进生产包。我过去需要每次都手动在 prompt 里提醒，而现在这些规则写进 skill 之后，Claude Code 会在关键节点自动触发对应检查。

不过我不建议一上来就写十几个技能包。我见过有人把团队规范拆成了二十多个 skill，结果每次对话都要加载大量上下文，反而拖慢速度、增加 400 报错概率。正确姿势是先写两三个最高频的、最容易出错的流程即可，跑顺了再慢慢加。

6.3 团队 SOP：让所有人和所有 AI 都遵守同一套规则

最后是我认为最关键的一步：把 CLAUDE.md 和.claude/纳入版本控制，作为团队级基础设施。新人加入项目，拉下代码，跑通claude，读到的规则和老人完全一致。这样 AI 的行为边界就变成了“团队共识”的一部分，而不是某个人自己的小技巧。

我们团队在 CLAUDE.md 里专门写了一节“禁止事项”：比如 AI 不能碰数据库迁移目录、不能修改生产环境配置、不能绕过 lint 强制提交。这些规则不是写给新人看的，是写给“对项目一知半解的 AI 实习生”看的。有了它们，AI 的自主性才能安全地放在一个可控的笼子里。

7. 最后说点实话

用 Claude Code 这半年，我最大的变化不是代码写得快了，而是开始敢接完全陌生的项目。以前接手一个从没看过的代码库，至少要花一两天通读核心模块才能动手；现在我会直接让 Claude Code 先读一遍，然后坐在那儿听它给我讲这个仓库的结构、隐患、可疑设计，再让它顺着几个关键链路跑一遍，比我前三天的人工翻代码效率高很多。

但我也想把丑话说在前面：不要神化它。它本质上是一个“很会读代码的高级实习生”，需要你给指令、给边界、给验收标准。我从那些写出万赞心得的推主身上学到的共同点，其实不是他们用的工具多高级，而是他们把“上下文预算”和“任务拆解”这两件事做到了极致。工具永远在变，这套方法论不会过时。