企业官网建设流程全解析

前两天接手一个旧服务，我决定用 Claude Code 把里面一个“年久失修”的模块重构掉。启动会话时我底气十足——200K 上下文，四舍五入不就是一个中型仓库的全部代码么？直接通读，横扫千军。结果十分钟后我对着屏幕沉默了很久：它把一个只存在于它想象里的配置文件当成了事实依据，然后基于这个假配置改了十几个文件的引用。我回头梳理整个会话，发现问题不是出在 200K 上，而是出在“我以为 200K 能解决上下文管理”这个想法上。

这篇文章写给所有在真实项目里折腾 Claude Code 的人。无论你只是装了个客户端想写点小脚本，还是打算让它处理一个你维护了三年的老仓库，这篇内容都会告诉你：200K 上下文到底能做什么、不能做什么，以及怎样配置才能让这个数字真正为你工作。

先说结论：200K 救不了你，是因为上下文管理从来不是一个“容量”问题，而是一个“密度”和“注意力”问题。后面我会用实测数据和配置模板把这句结论解释清楚。

1. 200K 上下文，夸海口之前先算清楚这笔账

1.1 数字换算：200K token 到底能装下什么

200K token 约等于 15 万英文单词。如果换成中文，按每个汉字约 1.5 到 2 个 token 计算，大概是 10 万到 13 万个汉字，差不多是一本两百页的书的体量。听起来确实很惊人。

但一个真实项目是什么量级？随便拿一个中型 Java 服务举例：业务代码五万行，加上 pom 依赖、自动化脚本、SQL 迁移文件、接口文档、配置文件，上千个文件是很正常的事。把这些全丢给模型，它不但装不下，还会在寻找特定信息时被彻底淹没。

更关键的一点是，Claude Code 并不是默认把整个仓库塞进上下文的。它是一个 Agent，通过工具按需读取文件。所以你看到的“200K”只是容量的上限，而不是模型一开始就通读了你的仓库。很多第一次用的人以为让 Claude Code 干活就等于把整个项目灌进去，这是最大的误解。

我做了一次粗略换算：一个 30 万行代码的中等仓库，如果全部以纯文本形式塞进上下文，大约需要 400 万到 600 万 token。200K 连它的 5% 都不到。就算只看业务代码不看依赖和生成物，也要 100 万 token 起步。所以“整仓通读”在数学上就不成立，更不用提模型注意力分配的问题了。

1.2 放得进不等于记得住：长文本注意力衰减

就算你舍得花钱，真把几十万 token 塞进去了，模型也未必能有效利用。业界有个被反复验证的现象叫 lost in the middle：当输入文本很长时，模型对开头和结尾内容的召回率明显高于中间段落。

你可以这么理解：就像你一边吃满汉全席一边记菜名，菜越上越多之后，你最后能复述的通常只有第一道开胃菜和最后一道甜品，中间那些硬菜全成了背景噪音。

在实际的 Claude Code 使用中，这个现象的直接表现就是：你明明在一个 50K token 的会话里提供了完整的中层模块代码，它却抓着你开头提到的旧接口不放，或者歪曲了文件中间某个关键注释的意图。这不是 Claude Code 独有的问题，而是所有长上下文模型都存在的物理规律——上下文越长，模型分辨关键信息位置的能力越弱。

延迟也会随上下文线性上涨。我实测过同一个模型在 10K 和 100K token 输入下的首 token 响应时间，后者大概要慢两到四倍。当你面对一个需要反复修改代码的交互式 Agent 时，这种延迟会积累成非常糟糕的使用体验。

1.3 记得住不等于分得清：噪音与指令污染

比注意力衰减更隐蔽的问题是“分不清主次”。上下文里塞满了日志、堆栈、配置文件、第三方包源码——模型会把这些全部当作可能相关的背景噪音。你让它修登录模块的报错，但它上下文里有上百行无关依赖代码，它就会产生“主题漂移”，开始默认你在讨论整个系统。

我遇到过一次最离谱的情况：想让它清理一个工具函数的循环引用，结果因为它上下文里有另一个模块的完整实现，它顺手给那个模块“优化”了一段看起来很像重构、实际破坏了接口约定的代码。教训很清楚：你给得越多，它发挥空间越大，但你控制方向的难度也越大。

真实项目的有效信息密度通常低于 5%，剩下的 95% 都是噪音、无关内容和中间产物。把低密度的 200K 塞给模型，不如把高密度的 20K 喂给它。

注意：上下文容量是“上限”而不是“推荐值”。绝大多数任务用不到 200K，如果次次都奔着上限去，你只是在同时对抗成本、速度和注意力衰减这三座大山。

2. 实测中的真实瓶颈：不只是容量，是钱、速度和噪音

2.1 账单：一次满上下文操作要吃掉多少钱

让“容量无限”的幻想破灭的第一件事是账单。以 Opus 级别模型为例，输入大约每百万 token 15 美元，输出大约每百万 token 75 美元。如果按 200K 的输入算一次，光输入就是 3 美元。一次重构任务通常需要三四个来回，输出 token 也会迅速累积到几十 K，加上工具调用反复读文件，一个上午烧掉二三十美元并不夸张。

更值得警惕的是，Agent 模式下费用是“自动累积”的。它每执行一次 grep、cat、ls，结果都会写进上下文。你人不在旁边盯着，它可能十分钟内把整个项目目录翻了个底朝天，而这一切都在悄悄计费。我用 Sonnet 模型跑过一整天小步任务，最后账单高得让我立刻去查了历史记录。

给一个简单价格对照（价格会更新，但计费逻辑不变）：

关键点：上下文大小和成本成正比，而 Agent 会自己放大这个比例。你放任它自己翻文件，它就会把“工本费”翻成“工程费”。

2.2 速度：长上下文会把交互变成等待游戏

长上下文带来的第二个体验打击是速度。模型需要处理更长的注意力计算，首 token 时间被明显拉长。在实际编码场景里，你往往是改了代码、保存、然后让 Claude Code 继续改。如果上下文是 150K 而不是 15K，一次“继续”可能等上一两分钟。连续几个来回，整个下午就耗在进度条上了。

更麻烦的是，Claude Code 的 Agent 循环本身有超时机制。当单次工具操作或回复生成时间过长，流程可能被判为失败而重试。我在长会话里反复遇到超时，重试不但解决不了问题，反而让上下文再膨胀一圈，进入恶性循环。

我的经验是：如果会话超过一定上下文占用，或者明显感觉到回复变慢，直接开新会话，带上压缩后的摘要，不要恋战。长上下文不是你的资产，而是你的负债。

2.3 噪音：Agent 会亲手把你的上下文弄脏

前面提到了成本，这里重点说“脏”是怎么来的。Claude Code 是 Agent，它会自主决策调用哪些工具。默认情况下，工具输出会全部进入上下文，而模型并不擅长区分哪些输出对当前任务真正有用。

于是会出现这种场景：你只想让它给你写一个正则表达式，它却先 ls 了根目录，然后 grep 了整个 src，再 cat 了三个可能相关的文件。任务还没开始，上下文已经被大量无关输出占满。

我在本地实测中见过最夸张的一次：一个“把 config.ts 里某个错误提示改一下”的小任务，最终产出了接近 150K token 的上下文，其中 90% 以上的内容与目标文件无关。因为上下文膨胀，后续每次回复速度明显变慢，它还开始“回忆”起一堆不存在的历史修改。

所以我强烈建议：第一次使用 Claude Code，先搞清楚怎么限制工具调用范围，再考虑怎么把代码塞给它。工具白名单才是第一生产力。

3. 让 200K 真正救命：一套可复制的配置流程

3.1 把文件系统当外置大脑，路径比内容更重要

正确的做法是把大体积内容留在磁盘上，给 Claude Code 指路，而不是搬运。Claude Code 本身支持按需读取文件内容，所以你要做的是让它知道“去哪里找什么”，而不是“把所有东西都读进来”。

打个比方：你在公司里给新同事一份部门文件索引，而不是把一整柜资料都搬到他工位上。文件索引能让他精准找到目标文档，而搬资料只会让他坐在纸堆里发呆。

我推荐的起步方式是在项目根目录创建 CLAUDE.md（后面细说），在里面写清楚：这个项目的技术栈、构建命令、哪些目录是核心、哪些地方是雷区、当前任务的入口文件在哪。Claude Code 每次会话都会自动加载这份文件，相当于给它一个“项目大脑”的索引。之后它需要细节时，会自己用 Read、Grep 工具去查。

有一个很实用的配置项：在启动命令里限制允许的工具。

claude --allowedTools "Read, Grep, Glob, Bash(list_files=true)"

这样可以把工具调用限制在最小集合，避免它动不动就 ls、cat 大目录或执行非必要命令。你还可以配置禁止列表，使它在执行某些操作前必须先询问你，防止“自说自话地翻遍整个仓库”。

3.2 CLAUDE.md：一份真正有效的项目记忆模板

下面是一套我经过多次迭代后验证有效的 CLAUDE.md 结构。不需要照抄，但建议保留核心章节顺序。

# 项目概述 一句话说清楚项目是什么、服务谁、代码仓总体结构。 # 技术栈与命令 - 语言 / 框架 / 构建工具版本 - 如何安装依赖：npm install / poetry install - 如何跑测试：npm test -- --run - 如何启动：npm run dev # 目录路由 - src/：业务源码 - src/services/：对外服务层，禁止直接改 DAO - src/models/：领域模型，实体变更需同步迁移脚本 - docs/：设计文档，不放代码逻辑 # 关键文件 - src/config.ts：全局配置入口，改这里要同步环境变量模板 - src/db/schema.prisma：数据库 Schema，改完必须跑迁移 # 代码风格与约定 - 使用 TypeScript strict 模式，不允许 any - 日志统一用 logger.info，不要 console.log - 错误信息统一为“操作 + 原因 + 建议”三段式 # 已知雷区 - 不要修改 generated/ 目录下的文件，会被覆盖 - vendor/ 下的第三方包不要动 - 修改公共 API 时必须同步更新 OpenAPI 文档

这份文件的意义在于：它让模型在最开始就知道哪些可以动、哪些不能动、出错该怎么查。当模型带着 CLAUDE.md 的全局认知再去读文件时，它不会再把整仓翻一遍，因为大部分问题都可以通过“CLAUDE.md + 精确读取少量文件”解决。

实操心得：CLAUDE.md 不是写给人看的，是写给模型看的。所以不要写“本项目提倡代码整洁”这种空话，要写“class 名用 PascalCase、工具方法放 utils/ 下、禁止直接改数据库 Schema”。模型只认指令，不认口号。

3.3 任务拆解与“一段一议”的会话习惯

有了 CLAUDE.md 还不够，你得把自己的工作方式从“一次性交代”改成“小步快跑”。一个任务拆解下来大概是这样。

第一步，把目标用一句话写进会话开头。例如：“修复 src/services/order.ts 里 createOrder 的库存校验逻辑，库存不足必须抛 BusinessException，不允许部分创建。”

第二步，让它先读入口文件和依赖的接口签名，而不是让它自己全仓扫描。你可以用 @ 引用指定精确文件路径：“先看 @src/services/order.ts 里的 createOrder 依赖哪些方法，列出函数签名，再开始改。”

第三步，让它“先出方案再动手”。这看起来浪费 token，实际能帮你省掉大量返工。方案确认后，再让它修改最小代码集。

第四步，测试完毕后，用 /compact 压缩上下文，然后开新会话继续下一步。一个复杂项目不要试图在一次会话里从头做到尾。每完成一个原子任务就“换号”，用摘要衔接，比一直拖着一个又慢又贵的长会话高效得多。

具体操作上，当你觉得对话开始变慢、或者模型开始重复提及之前的内容时，输入：

/compact

它会自动压缩当前对话内容，生成一份精炼版摘要。如果压缩后模型还是糊涂，就 /clear 彻底清空，然后手动补充下一步任务描述。我现在的习惯是：每次大节点做完，主动开新会话，把上一轮的结论复制进 CLAUDE.md 的“当前迭代记录”里。这比让模型自己回忆一整天的工作靠谱太多了。

4. 常见问题与避坑速查表

4.1 上下文爆了，回答开始胡说八道

表现：模型开始引用根本不存在的文件或函数，对修改建议前后矛盾。

原因：上下文里塞了太多被工具产出污染的无关内容，有效指令被淹没。

处理：先 /compact，把当前目标重新用一句话声明。如果还不行，/clear，重新给一个更小范围的提示词，并带上必要文件的路径。

经验：长会话出现“幻觉式修改”，往往不是模型不行，而是它“忘事”了。这时候不要跟它争论，直接开新局。

4.2 改错了文件，如何快速回滚

Claude Code 内置了 /rewind 命令，可以回滚到上一个检查点。它的底层保存了每次工具操作的记录，所以你可以精确恢复被错误修改的文件。

同时我强烈建议：跑 Claude Code 之前，先确认仓库处于 git 干净状态。每完成一个小任务就 commit 一次，这样 AI 真抽风了，只需 git checkout 掉那一两个文件。

git checkout -- src/services/order.ts

这比让 AI 自己解释“刚才为什么这么改”省心太多。记住：先把安全网铺好，再让 Agent 撒欢跑。

4.3 它频繁读文件，但读不到正确位置

表现：模型在长上下文里反复 grep 同一个关键词，却忽略你明确指定的文件路径。

原因：路径拼写错误、目录中有大量生成代码干扰 grep 结果、CLAUDE.md 里缺少目录路由。

处理：给它精确的相对路径，并配置 ignore 规则排除生成目录。在 CLAUDE.md 中明确写“xx 功能在 xx 文件里”，给它一张地图，而不是让它靠猜。

经验：你让它“看一下登录模块”，它可能去看 login 目录下二十个无关文件；你让它“Read src/auth/AuthService.ts 第 100 到 200 行”，它立刻明白该干什么。

4.4 对话越来越慢，而且频繁超时

表现：同样一个修改，在 10K 上下文时几秒响应，在 150K 时要等一两分钟甚至超时重试。

原因：上下文长度直接影响模型计算量，而 Agent 循环又叠加了工具调用时间。

处理：停止当前任务，/compact 压缩上下文。如果还慢，直接 /clear 开新会话。把已完成部分和下一步目标浓缩成摘要写进新会话。

经验：我的个人阈值是——上下文占用超过 80K 时开始计划“换号”，超过 120K 坚决不继续干活。压缩、搬摘要、新开会话，这三步永远是长上下文最好的朋友。

4.5 模型自顾自翻目录，刷了一堆无关输出

表现：你让它改一个函数，它先 ls 根目录，再 cat 整个配置文件夹，然后又去读一个超大的多语言包。指示灯一转，上下文从 10K 跳到 60K。

原因：Agent 自主决策时，倾向于多读多看以获得“安全感”。在真实项目里，这种安全感是企业成本的大敌。

处理：用上面说的 --allowedTools 限制工具；在配置里禁用不需要的工具；给每个会话设定较小的上下文预算，超过后人工介入。

经验：限制工具不是限制 AI 能力，而是在给它划清边界。这就像你给强力新员工分派任务时多说一句“你今天只改这几个文件，别的先别动”，效率反而更高。

我自己后来把 200K 当成“画布”而不是“题库”。它不是让你把整个仓库一次性扔进去，而是给你一块足够大的画布，让你在上面做规划、留余量、按需展开。真正救你的不是 token 容量，而是你在多大程度上愿意做上下文管理。现在我接手新项目的第一件事不是写代码，而是写 CLAUDE.md 和选白名单工具。磨刀不误砍柴工，这句话放在 AI 编程时代，依然成立。