企业官网建设流程全解析

1. 九月这波更新，到底改了什么——先给结论和定位

如果你这段时间一直在用 Claude Code，应该能明显感觉到：九月份的版本迭代节奏明显加快了，而且改动的方向不再是单纯的“多模态、长上下文”这些硬参数，而是开始认真收拾工程化、可维护性、长时间任务可靠性这些老问题。说得直白一点，Claude Code 从“一个能跑通 Demo 的终端玩具”，开始往“能接手真实项目的生产力工具”方向走了。

这次更新里，最抓眼球的三个点分别是：AGENTS.md 被正式“认”了，也就是说项目级规则文件终于成为一等公民，不再是你写在 README 里求 AI 看一眼的备注；长任务支持暂停后接上，跑了一半的批处理脚本、代码迁移、批量重构，中断之后还能找到断点继续跑，不用从头再来；插件体系从“能装”进化到“能管”，市场、列表、启停、卸载都齐了，不再是装完就靠玄学运行。

先说结论：这三件事其实指向同一个核心需求——Claude Code 正在解决“用起来很爽，但一上规模就崩”的尴尬。

之前的 Claude Code 确实强，但真实项目里你总会遇到几个特别窝火的情况：规则文件写了半天，它在某些子任务里根本不认；一个跑了两小时的迁移任务，因为一次网络波动就归零；插件装了一堆，结果互相之间怎么关、怎么排查全靠命令行考古。九月的更新，基本上就是对着这些痛点逐一下刀。

对于刚接触的人，这一版的意义在于：你不再需要靠各种“技巧”去哄着 AI 干活，而是可以像管理一个真实团队成员一样，给它写清楚规则、让它干活干到一半能暂停、给它装工具还能随时卸。这篇文章我就按这三个主线展开，顺带把社区里大家最近高频踩坑、高频搜索的那些点也一并梳理掉——包括 AGENTS.md 和 context.md 什么关系、长任务恢复具体怎么操作、插件管理命令长什么样，以及国内用户最纠结的安装、卸载、存储位置、接入 DeepSeek 之类的问题。

2. 认认真真认了 AGENTS.md：项目规则从“建议”变成“默认执行”

2.1 从 CLAUDE.md 到 AGENTS.md，到底改了什么

如果你是老用户，应该记得早期 Claude Code 的规则文件叫CLAUDE.md，放在项目根目录，AI 每次启动时会自动读取，相当于给会话设定一个“人设”和“约束”。后来 Anthropic 官方逐步推荐AGENTS.md这个名字，原因也很简单：这是为了让规则文件在不同 AI 工具之间通用。现在不只是 Claude Code，很多编码代理都支持读取 AGENTS.md 作为项目约定，你写一份规则，换工具也能接着用。

九月的更新里，AGENTS.md 不再是“建议使用”了，而是被完整纳入正式读取流程。具体表现是：项目根目录、子目录、用户全局目录这几个层级，都会按优先级依次读取。你可以在全局放一套通用的编码规范，然后在具体项目里放针对性的规则，甚至在某个子模块目录里再放更细的局部规则。

这里有一个很关键的点：AGENTS.md 的有效范围是按目录层级继承的。也就是说，如果src/下面有一个自己的 AGENTS.md，那 AI 处理src/里的文件时，会同时参考根目录和src/的规则，而且子目录的规则优先级更高。这个设计特别适合大项目——根目录约束整体风格，子目录约束模块内的实现细节。

2.2 context.md 和 AGENTS.md，别再混了

这次热词里好多人搜“agents.md context.md”，说明大家确实容易把这两个文件搞混。其实它们的定位完全不同。

• AGENTS.md是给 AI 看的“行为准则”，回答的是“你该怎么做这个项目”，比如代码风格、禁止事项、架构约定、测试要求。
• context.md或者说CLAUDE.md的很多用法，其实是在提供“背景信息”，回答的是“这个项目是什么、为什么要这样做”，比如业务背景、历史决策、上下游依赖。

在实际使用中，很多人把两者合并成一个文件，这也没问题，但我更推荐分开。我的习惯是：AGENTS.md里写死规则，用祈使句，比如“所有数据库迁移必须新增可回滚脚本”；context.md则写成叙事文档，记录关键决策背景，比如“本模块之所以用消息队列而不是同步调用，是因为旧方案重试逻辑太晦涩”。

为什么分开更好？因为 AI 对“规则”和“背景”的处理方式是不同层级的——规则会被当作硬性约束来检查，背景信息更多是辅助理解和推理。你如果全混在一起，AI 有时候会分不清哪句是必须遵守的命令，哪句只是描述。尤其是规则较多的项目，混在一个文档里，前面一条规则可能在后面就会被 AI 自己“推理”掉了。

2.3 AGENTS.md 的实际写法：以可验证为核心

九月更新后，AGENTS.md 的读取时机也发生了变化，它会在任务开始时，以及相关文件被读取时被反复参考，不再只是会话启动时读一次。这意味着什么？意味着规则文件写得越结构化，AI 遵守得越稳定。

我实测了几个写法的差异，差别真的很大。

如果你写：

请遵循项目的代码风格，保持代码整洁。

这种规则基本等于没写。AI 每次都要“猜”什么叫整洁，结果就是每段代码整洁的标准都不一样。

但如果你写成这样：

1. 所有 Python 函数必须包含类型注解，包括返回类型。
2. 禁止在业务代码中使用print，统一使用logger。
3. 数据库操作必须放在repositories/目录下，禁止散落在 service 层。

AI 的遵循率就会高很多。甚至更进一步，把规则写成“能被脚本检查的格式”，比如：

新增文件必须遵守mypy --strict检查，提交前运行uv run mypy .

这种写法利用的是 AI 对“可执行命令”的敏感度——它看到明确的命令，会偏向于真的去执行验证，而不是全靠记忆遵守。

再说一个层级设计。如果你和我一样同时在好几个项目里用 Claude Code，建议全局放一份“底线规则”，比如：

• 任何代码变更不得破坏现有测试。
• 禁止提交包含密钥或敏感信息的文件。
• 所有依赖变更必须更新 lockfile。

然后在每个项目里放带项目特色的规则。这样就算全局规则写得比较严，也不会和项目内规则冲突。这次更新之后，全局规则和项目规则的合并顺序基本固定了，默认是全局先读，项目内覆盖，不会出现 AI 只认全局规则、无视项目规则的尴尬。

2.4 一个容易踩的坑：AGENTS.md 的“记忆错觉”

这里必须提醒一句。很多人以为 AGENTS.md 是 AI 的“长期记忆”，写完一次，AI 就永远记得。其实不是。AGENTS.md 更像“每次开会的会议纪要”——AI 每次启动会话都会读一遍，但它并不会真的“记住”你改过的历史。

所以更新 AGENTS.md 之后，旧会话里 AI 可能还按旧规则跑，因为长会话的上下文可能已经缓存了旧的规则命中结果。建议的姿势是：改动 AGENTS.md 后，开新会话，或者至少用/clear重置上下文。不然你明明改了规则，AI 还是会沿用旧的，然后你开始怀疑 AI 的智商，实际上只是缓存机制在作怪。

另外，AGENTS.md 不要写太长。我有段时间把整个项目的架构说明全塞进去，结果发现 AI 在长任务中反而容易把规则和背景搞混。现在我的建议是：超过 200 行就拆分，硬规则留在 AGENTS.md，背景叙事放 context.md，细节文档用单独文件，在 AGENTS.md 里用一两句话引用来链接。

3. 长任务能暂停接上：Checkpoint 与恢复机制的实际体验

3.1 长任务为什么之前那么让人崩溃

用过 Claude Code 跑长任务的都知道，最崩溃的不是任务本身跑不完，而是跑了一半断了，然后一切归零。

常见的断点有这么几类：

1. 上下文窗口超限。任务太长，对话历史越积越多，最终触发长度限制，AI 开始丢信息，或者直接报错。
2. API 请求超时或网络中断。尤其是国内网络环境，时不时就给你断一下，重试机制扛不住大任务。
3. 终端会话意外关闭。比如电脑休眠、终端误关、SSH 断开。
4. 任务执行到一半，你发现方向错了，想回退到某个状态重新来。

九月的更新引入了一套基于Checkpoint 和会话恢复的机制，目的就是解决这些场景。简单说，Claude Code 现在会在任务执行的多个阶段自动记录检查点，你可以随时暂停、查看当前进度、跳到某个历史检查点，恢复之后继续跑。

3.2 核心命令与用法：不被写进 Release Notes 的细节

这次更新里，最常用的命令和参数大概是这些：

• claude --resume：恢复最近的会话。
• claude --resume <session-id>：恢复指定会话。
• /checkpoint：在会话里手动创建检查点。
• 会话中直接输/status或者查看当前目录下的.claude相关目录，可以看到更多会话信息。

我实测下来，恢复机制不仅仅是“把历史消息重放一遍”。它更像是给会话打了一个快照，恢复时会把当时的上下文、已选文件、执行状态尽量还原。尤其是搭配 Agent 模式跑多步任务时，恢复后的行为明显比之前“硬塞上下文”要稳定得多。

具体操作上，我的习惯是这样：

1. 启动长任务前，先确认当前版本支持 checkpoint。
2. 在任务中关键节点（比如每完成一个模块的批量修改），手动输入/checkpoint打个标记。
3. 如果中途断了，重新打开终端，先执行claude --resume看列表，找到目标会话和检查点，直接恢复。
4. 恢复后先让 AI 总结一下当前完成到哪一步，再继续下发后续指令。

这里有个小技巧：恢复之后，不要让 AI 直接闷头干活，先让它“汇报进度”。比如：

请根据当前上下文，列出已经完成的文件变更、未完成的步骤、剩余风险点。

这样做是因为恢复时虽然保留了检查点，但 AI 对“接下来该做什么”的优先级判断，可能会和你最后下发的指令有一点点偏移。让它先汇报，你再确认，基本上就能无缝接上。

3.3 检查点机制和 git 的区别

很多人会问，这跟 Git 分支和 commit 有什么区别？说实话，用途完全不同。

Git 是管理代码状态的，Checkpoint 管理的是AI 会话状态。你跑一个批量重构任务，中途 AI 改了 20 个文件，这 20 个文件的修改确实可以靠 Git 回退，但 AI 脑子里当时的“决策链条”“哪些文件还没处理”“下一步计划是什么”这些信息，Git 是保存不了的。Checkpoint 恰恰就是把这些“对话推理状态”也一起快照了。

所以更合理的用法是：Checkpoint 管 AI 的执行进度，Git 管代码的版本安全。两者配合，双保险。长任务跑到重要节点，先/checkpoint再做一次 Git commit，哪怕后面改歪了，也能回到一个比较干净的起点。

九月的更新还改善了“跨会话恢复”的行为。以前你恢复一个会话，很多时候只是把历史记录堆回去，但工具状态、文件修改记录、命令执行结果往往会丢失。现在恢复后，至少我常用的几个场景——批量改文件、跑测试、修 lint——都比较完整。不过，如果你用的是自定义 MCP 服务或者外部工具，恢复后偶尔还是需要手动重新确认连接状态，这点暂时不算完美。

3.4 长任务场景的实战建议

以我最近跑的一个“把旧 Python 项目迁移到 Pydantic v2”的任务为例，讲讲实际是怎么用的。

任务量大概是：60 多个模块，涉及模型定义、配置加载、序列化逻辑，还要保证现有测试通过。这个任务如果一口气跑，中途大概率会因为上下文太长而出问题。我的做法是：

1. 先把迁移规则写进 AGENTS.md，明确“禁止修改公共 API 签名，只调整内部实现”。
2. 把整个任务拆成三个阶段：模型层迁移、配置层迁移、测试修复。
3. 每个阶段开始时，新建会话并读取 AGENTS.md；阶段结束时打一个/checkpoint。
4. 第二阶段跑到一半，网络断了一次。重新打开终端，claude --resume，找到对应会话，恢复后让它先汇报完成情况。
5. 汇报发现它已经在改第 37 个模块，而且第 34、35 个模块的测试通过了。我直接说“继续从第 37 个模块开始”，整个恢复过程花了不到五分钟。

如果没有 checkpoint，这五分钟可能就变成“重新从头跑一遍”。对长任务来说，这个功能省下来的不只是时间，还有你盯着终端干等的精力。

另外，建议长任务别在默认配置下裸跑。官方文档里提到的enable_prompt_caching之类的参数和缓存策略，配合长任务恢复其实是有效的。热词里有人问“export enable_prompt_caching_1h=1这个配置有用吗”，我的实测结论是：对长会话、频繁切换任务的场景确实能减少 token 消耗，但对一次性短任务帮助不大。如果你经常跑长任务，建议开着。

4. 插件从能装到能管：插件生态走向成熟

4.1 以前装插件，真的全靠“考古”

Claude Code 很早就能装插件或者说扩展，但早期的体验确实不行。你从 GitHub 装一个插件，跑起来可能没问题，但一旦想看看装了哪些、想禁用某个插件、想卸载，对不起，命令不全，文档也稀碎。我记得有一阵子，大家只能靠/plugin碰碰运气，再不行就去翻源码。

九月的更新里，插件体系最大的变化不是“多了几个新插件”，而是引入了真正的插件管理生命周期。现在你可以在会话里直接列出所有已安装插件，查看版本，禁用、启用、卸载，还能配置插件市场。这意味着插件不再是“装完就听天由命”的野生态。

具体命令大概是：

• /plugin：查看插件列表和状态。
• /plugin install <市场名>/<插件名>或直接指定 git 仓库地址。
• /plugin uninstall <插件名>：卸载。
• 市场相关操作，用于添加和管理来源。

我自己的体验是：插件管理界面化之后，排查问题容易多了。以前插件报错，你根本不知道是插件本身的 Bug 还是和其他插件冲突。现在先/plugin看列表，禁用可疑的插件，逐个试，很快就能定位。

4.2 市场和本地插件：两种安装源，谁更靠谱

插件现在主要分两种来源：插件市场和本地/直接 Git 源。

插件市场的好处是集中管理，有统一的更新通道，类似 npm registry 的概念。你添加一个市场，然后从市场里安装插件，后续更新和卸载都比较规范。本地或 Git 源的好处是灵活，尤其是你自己开发的插件，或者还没上市场的插件，直接给路径就能安装。

我的建议是：能用市场的就用市场。因为本地装的话，升级得自己手动拉代码，而且插件目录一旦位置变了，旧配置就会失效。热词里有人搜“插件应该下载哪个”，其实答案很简单——先看市场里有没有，没有再看 GitHub。

说到目录位置，这里也顺便把大家经常搜的“Claude Code 存储位置”一起回答了。插件和配置通常放在用户目录下的.claude文件夹里，Linux 和 macOS 一般是~/.claude/，Windows 则在你的用户目录下对应位置。你可以直接进去看plugins、settings.json、marketplaces这些子目录。如果你怀疑插件加载异常，第一件事就是去.claude/plugins看看目录结构是否完整。

4.3 一个比较实际的例子：配一套自己的插件组合

我目前的插件组合大概是这样，供参考：

• 格式化和 lint类插件，挂在保存和提交钩子上，负责强制代码风格。
• 测试辅助插件，负责跑测试和汇总失败用例。
• 文档生成插件，用来在模块改动后自动更新相关文档片段。

这些插件的组合方式，不只是“装上就完事”。Claude Code 的插件可以暴露工具、钩子、命令，甚至可以定义自己的斜杠命令。你可以把插件的功能和 AGENTS.md 里的规则挂钩，比如规定“所有提交前必须跑一遍测试插件提供的验证命令”。

插件管理的另一个进步是权限控制。以前插件拿到能力之后，很多操作是不受控的，容易出现“插件偷偷改了不该改的文件”之类的惊吓。现在你可以更细粒度地控制插件的启用时机和权限范围。虽然不是每条命令都完美，但至少有一个可管理的入口。

4.4 插件的“坑位经济学”：装多了反而拖累

这里想多说一句。插件不是越多越好，至少在我的实测里，每个插件都会消耗一定的上下文空间，而且插件之间潜在的 hook 冲突，会随着数量增加而指数上涨。

所以我现在的插件管理原则是“少而精”：

1. 每个核心诉求只保留一个最佳插件。
2. 每个月至少清理一次不用的插件。
3. 新的插件先用/plugin install装上，跑一个真实小任务验证，不行立刻卸载。

卸载的时候有个细节：卸载插件后，它的配置文件和生成的缓存可能还在.claude/plugins里，如果你发现某些“残留”导致新插件异常，建议直接清掉对应目录再重装。

5. 那些没写进 Release Notes，但大家真正在折腾的事

5.1 安装、环境和“国家支持”相关的坑

这波热词里有一大堆关于安装的，“claude code 安装”“claude code 下载”“windows 安装 claude code”“claude code 中国下载不了”“卸载 claude code”等等。说实话，Claude Code 官方没有推出独立桌面版，它本质上是跑在终端里的工具，所以你在网上看到的各种“桌面版下载”，基本都是第三方封装的界面壳，质量参差不齐。

安装的推荐路径一直是 npm：

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

Windows 用户如果 npm 装了以后命令找不到，大概率是 Node 的全局路径没加到 PATH。Linux 和 macOS 上遇到“claude 找不到”的情况，先检查 npm 全局 bin 目录。卸载的话，npm 装的就 npm 卸载：

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

然后把用户目录下的.claude、.claude.json相关配置一起清掉，不然重装的时候会残留旧配置。

至于“might not be available in your country”的提示，这个属于官方账号、网络环境层面的服务可用性问题，不是终端工具本身靠“改配置”能解决的。社区里各种“国内下载”“国内如何使用”的教程，本质上都是围绕网络环境做处理，但这类操作是否合规、是否稳定，你自己要判断。我的建议是：先把工具本身跑通，再考虑账号和网络环境的问题，因为工具层面的问题往往和生产环境无关。

5.2 接入 DeepSeek 和 CCSwitch 的真相

热词里反复出现“claude code 接入 deepseek”“deepseek 接入 claude code”“ccswitch”。很多刚接触的人会误以为 Claude Code 只能连 Anthropic 官方模型，其实 Claude Code 的架构允许通过设置环境变量来指向兼容 Anthropic API 格式的端点，所以社区里有人用它接 DeepSeek、接其他兼容接口。

CCSwitch 这种工具就是帮你快速切换不同模型端点的配置管理工具。但这里我必须泼一盆冷水：Claude Code 的核心能力高度依赖 Anthropic 特有的系统提示词、工具调用格式、以及模型本身的指令遵循能力。你把它切到别的模型，意思能跑通，但自动纠错、代码编辑的精准度、插件的兼容性，大概率会打折。

我做过一次实测：同一个重构任务，官方模型和兼容模型跑出来的效果差距很大，特别是在多文件联动修改时，兼容模型经常改到一半就开始“自由发挥”。所以我的建议是，如果你确实需要用 DeepSeek 这类模型，可以试，但别把 Claude Code 的完整功能都寄托在第三方模型上；更适合的场景是拿来做简单问答、草稿生成，而不是复杂工程任务。

5.3 VS Code 和 IDE 集成：到底怎么弄

热词里“vscode 配置 claude code”“vscode 接入 claude code”“往 idea 里下载 claude code 插件应该下载哪个”也有不少搜索。现在官方推荐的方式是在 VS Code 里用终端跑 claude，加上官方提供的 VS Code 扩展，可以获得文件读取、语法高亮、校验提示等增强体验。而不是去装乱七八糟的“Claude Code 桌面版”。

装了 VS Code 扩展之后，你在 Claude Code 会话里引用文件时，终端会和编辑器联动，AI 修改文件后编辑器能自动刷新。这比纯终端体验好很多。JetBrains 系 IDEs 目前主要靠自己配，或者等官方插件。

IDE 集成这块，我个人的经验是：别过度追求 GUI。Claude Code 的核心操作还是在终端里，IDE 扩展只是辅助确认修改内容。你要是从头到尾指望它在 IDEA 里像 Copilot 一样飘提示，反而容易失望。

5.4 设置文件和存储位置：出了问题先看这里

很多人问“claude code settings.json”“存储位置”，其实就是和配置相关的。Claude Code 的配置主要在用户级文件里，常见的有：

• ~/.claude/settings.json：用户级配置。
• 项目级.claude/settings.json：这个可以放进 Git 仓库，团队共享。
• 环境变量：比配置文件优先级更高。

如果你改了配置没生效，百分之八十是因为层级问题。项目级设置会覆盖用户级，环境变量又覆盖文件。建议排查顺序是：先看有没有环境变量，再看项目级文件，最后看用户级文件。

还有一个大家常搜的“claude code 存储位置”，除了配置，就是会话和缓存数据。这部分一般也在~/.claude下，如果你的磁盘突然多了几个 GB，去清理一下历史会话和历史检查点，能释放不少空间。尤其是长任务恢复功能上线后，检查点文件会累计，我一般定期清理旧会话。

5.5 那堆搜“教程”“入门”的人，我推荐你先做这件事

很多新用户搜“claude code 使用教程”“claude code 怎么使用”，但实际上 Claude Code 最大的学习成本不是命令，而是怎么向 AI 描述清楚一个工程任务。

我的建议是，新手上路别急着学各种骚操作，先做三件事：

1. 在一个真实的小项目里，写一份 10 行以内的 AGENTS.md。
2. 跑一个多步骤任务，中途用/checkpoint暂停，再用--resume恢复。
3. 装一个插件，用/plugin看它是否被正确加载，然后卸载。

这三件事完整做一遍，你对 Claude Code 的理解会比看十篇教程都深。剩下的边缘功能，用到再查也不迟。

6. 个人体会与接下来的折腾方向

九月的更新里，我最欣赏的不是某一个功能，而是它开始承认“工具要能管理自己”这件事。AGENTS.md 是让规则可管理，检查点是让任务可管理，插件管理是让扩展可管理——这三个方向拼起来，Claude Code 才真正像一个能进入正式工程流水线的工具，而不是一个仅供尝鲜的命令行玩具。

从实际使用来看，我现在的项目工作流已经调整成：每个仓库必带 AGENTS.md，全局放底线规则；长任务必打检查点，批处理任务不再裸跑；插件数量控制在五个以内，每个插件都在 AGENTS.md 里写明“什么时候可以用、什么时候不该用”。

接下来我准备折腾的方向有两个。一是把 AGENTS.md 规则和 CI 流程绑定，让 AI 的规则遵守情况能被自动化检查，比如提交时校验 AI 生成的代码是否违反了项目内规则；二是系统测试一下不同插件市场之间的组合兼容性，看能不能找到一套比较通用的“大项目标配插件组合”。

如果你也在用 Claude Code，九月的这波更新值得你花半天时间重新把工作流梳理一遍。特别是长任务的检查点机制，看起来不起眼，但真正跑到那种“改了一百个文件、离结束还差一步”的任务时，你就知道它值多少钱了。