企业官网建设流程全解析

1. 先搞清楚 token 到底在哪些环节被吃掉

很多人第一次认真看 AI 编程工具的账单时，都会有一个共同的困惑：明明只是让它改了个函数、补了段注释，怎么 token 用量就蹭蹭往上涨？我刚开始用这类工具的时候也这样，一个月下来账单比预期高出一大截，后来把调用日志一条条翻出来看，才发现钱根本不是花在"写代码"上，而是花在上下文搬运上。

要降成本，第一步不是急着换模型或者砍功能，而是先建立一张"token 消耗地图"。你得知道每一次请求里，哪些部分是真正必要的，哪些是被无意识塞进去的。

1.1 一次典型请求的 token 构成拆解

我拿一个最常见的场景举例：你让 AI 帮你修改某个业务函数里的一个 bug。看起来输入只有一句话，但实际发出去的请求往往包含这些东西：

• 系统提示词（system prompt）：工具自带的角色设定、行为规范、输出格式要求，通常几百到上千 token，而且每次请求都会重复发送。
• 项目规则文件：像.cursorrules、CLAUDE.md、AGENTS.md这类文件，很多工具会把它整份塞进上下文，哪怕这次任务只跟其中一小节有关。
• 打开的文件内容：你当前编辑器里开着的标签页，有些工具会默认全部带上，开十个文件就是十份代码。
• 检索到的相关代码片段：工具为了"理解项目"，会自动做代码检索，把匹配到的片段拼进上下文。
• 对话历史：之前几轮的问答记录，轮次越多累积越大。
• 你的实际指令：往往只占整个请求的百分之几。

我实测过一个中等规模的 TypeScript 项目，单次请求的输入 token 里，真正属于"我这次要问的问题"的部分不到 5%，剩下 95% 全是上下文。这就是成本失控的根源——你以为在为答案付费，其实大部分在为背景付费。

1.2 输入 token 和输出 token 的价格差

还有一个容易被忽略的点：输入和输出的计价通常不是一回事。多数模型输出 token 的单价是输入的几倍。这意味着两件事：

第一，让模型"少说废话"能直接省钱。如果你不限制输出格式，模型很容易给你写一大段解释、再贴一遍完整代码、再加一段总结，输出 token 轻松翻倍。

第二，长上下文不等于高质量输出。很多人有个误区，觉得塞得越多模型越聪明。实际上上下文过长会稀释关键信息，模型反而容易抓错重点，你还得多问几轮，成本进一步上升。

1.3 缓存机制：被低估的省钱利器

主流模型服务商基本都提供提示词缓存能力。原理很简单：如果请求的前缀部分和上一次完全一致，这部分就按折扣价计费，通常能便宜到原价的十分之一甚至更低。

这个机制对 AI 编程场景特别友好，因为系统提示词、项目规则这些内容每次都是一样的。但前提是前缀必须稳定——如果你每次都动态往前面插时间戳、随机 ID、变化的文件列表，缓存就永远命中不了。

我踩过的坑就是：早期在系统提示里加了一句"当前时间：{timestamp}"，结果缓存命中率几乎为零，白白多花了不少钱。把这类动态内容挪到请求末尾之后，账单立刻降下来了。

这张表不是精确统计，而是我根据多个项目日志归纳出的经验区间。你可以对照自己的使用习惯，看看哪一栏最超标。

2. 上下文管理：把"随手打开"变成"按需加载"

搞清楚 token 去哪了之后，最立竿见影的优化就是管住上下文。这一块的收益往往比换模型还大，而且不需要改任何代码。

2.1 关掉无关标签页这件小事

听起来很基础，但真的有效。我做过对比测试：同一个修改任务，编辑器里开着 12 个文件 vs 只开着 2 个相关文件，单次请求的输入 token 差了将近 3 倍。

原因在于很多 AI 编程工具默认会把"当前打开的文件"作为上下文的一部分。你开着的那十几个标签页，可能跟当前任务八竿子打不着，但它们照样被算进 token。

我的习惯是：动手让 AI 改代码之前，先花十秒钟关掉无关文件。这个动作几乎零成本，但长期下来省的钱很可观。如果你用的是支持"显式引用"的工具，那就更好——只把需要的那几个文件用@或类似语法引进来，其余一律不带。

2.2 项目规则文件要"瘦身"而不是"堆料"

项目规则文件（各种.rules、CLAUDE.md之类）是个双刃剑。写得好，模型少犯错；写得太长，每次请求都在烧钱。

我见过有人把整个团队的编码规范、架构文档、API 说明全塞进一个规则文件，动辄几千行。问题是这些内容每次请求都会重复发送，哪怕你只是问一个简单的语法问题。

我的做法是分层：

• 核心规则文件只放最高频、最通用的约束，控制在 100 行以内。比如"用 TypeScript 严格模式""不要用 any""注释用中文"这类。
• 专项规则拆成独立文件，按任务类型引用。比如做数据库相关改动时，才引入db-rules.md。
• 能删就删。规则文件里的每一条都要问自己：这条真的经常用到吗？用不到的果断删。

提示：规则文件里的示例代码特别占 token。如果一段示例有 50 行，但核心就 3 行，那就只留那 3 行。

2.3 对话历史该断就断

长会话是隐形成本杀手。很多人习惯在一个会话里连续问几十个问题，觉得这样"有上下文、连贯"。但实际上：

• 每一轮新请求都会带上之前所有轮次的历史。
• 历史越长，单次请求越贵，而且是指数级累积的感觉。
• 早期轮次的内容往往跟当前任务已经无关了。

我的经验是：一个任务一个会话。任务做完就开新的。如果中途发现跑偏了，与其在旧会话里纠正，不如开新会话把关键信息重新说一遍——后者通常更便宜也更准。

有些工具支持"压缩历史"或"总结前文"的功能，这个可以用，但要注意总结本身也要消耗 token，而且可能丢信息。我一般只在任务确实需要长跨度上下文时才用。

2.4 检索策略：别让工具"过度理解"你的项目

自动代码检索是个好东西，但默认配置往往过于激进。工具为了"全面理解"，会检索一大堆相关度不高的片段塞进上下文。

可以调整的方向包括：

• 限制检索返回的片段数量。默认可能是 20 条，调到 5-8 条通常够用。
• 提高相似度阈值。让检索只返回真正相关的，而不是"沾点边"的。
• 排除无关目录。node_modules、dist、测试快照、生成文件这些，一定要加进忽略列表。我见过有人没配忽略，结果检索把整个依赖包的代码都翻出来了。

这些配置一般在工具的设置里能找到。花半小时调一次，长期收益很大。

3. 提示词写法：让每一次请求都"精准打击"

上下文管好了，接下来是提示词本身。同样一个需求，写法不同，token 消耗可能差好几倍。

3.1 明确边界比堆砌背景更省钱

新手常犯的错是：怕模型不理解，就把所有背景都倒进去。结果请求又长又杂，模型还得从一堆信息里挑重点。

正确做法是给边界，不给百科。比如你要改一个函数，不要贴整个文件，而是：

• 说明这个函数做什么。
• 贴出要改的那一段。
• 说清楚期望的输入输出。
• 明确约束（比如"不要改函数签名""保持现有错误处理风格"）。

这样模型拿到的信息密度高，输出也更聚焦。我实测过，同样的任务，精准描述比"贴全文+泛泛要求"能省一半以上的输入 token，输出质量还更好。

3.2 输出格式约束能砍掉大量废话

前面提过输出 token 更贵。所以约束输出格式是性价比极高的操作。

几个实用的约束写法：

• "只输出修改后的代码，不要解释。"
• "用 diff 格式给出改动，不要重复未修改的部分。"
• "如果只需要改一行，就只给这一行。"
• "不要写总结段落。"

我特别推荐diff 格式。让模型只输出改动部分，而不是把整个文件重写一遍，输出 token 能直接砍掉一大半。尤其是改大文件里的小地方时，效果非常明显。

3.3 分步拆解 vs 一次性大请求

这里有个反直觉的结论：不是所有任务都适合拆成多步。

拆步的好处是每步上下文小、聚焦。但坏处是每步都要重新发送系统提示和部分背景，如果拆得太碎，重复开销反而更大。

我的判断标准是：

• 如果子任务之间共享大量背景，那就合并成一次请求。
• 如果子任务彼此独立，那就拆开，各自用最小上下文。

举个例子：让 AI 重构一个模块，涉及 5 个函数。如果这 5 个函数互相调用、共享类型定义，那一次性给它整个模块反而更省，因为背景只发一次。但如果只是 5 个互不相关的工具函数，那就一个一个来。

3.4 用"模板化指令"减少试错轮次

每一轮返工都是一次完整的 token 消耗。减少轮次的关键是第一次就说清楚。

我给自己整理了一套常用指令模板，比如"改 bug 模板""加功能模板""写测试模板"，每个模板里固定包含：任务描述、约束条件、输出格式、验收标准。用的时候填空就行。

这样做的好处是：不会漏掉关键约束，模型一次就能给到接近可用的结果，省下反复沟通的成本。模板本身也可以放进规则文件或快捷指令里，进一步减少每次输入的字符数。

4. 模型选择与调用策略：不是越强越好

很多人默认用最强的模型处理所有任务，这其实是很大的浪费。不同任务的难度差异巨大，用对的模型比用贵的模型更重要。

4.1 按任务难度分级选模型

我把日常 AI 编程任务大致分成三档：

关键洞察是：大部分日常任务其实落在前两档。真正需要旗舰模型的场景可能只占 10%-20%。如果你所有请求都走旗舰模型，成本自然下不来。

我自己的习惯是默认用中档模型，遇到它搞不定的再升级。这样既保证效率，又控制成本。有些工具支持"自动降级"或"按任务路由"，可以配置起来。

4.2 本地模型能承接哪些活

如果你有本地部署模型的条件，那简单机械类任务完全可以本地跑，边际成本几乎为零。

适合本地模型的任务包括：

• 代码格式化、命名规范调整。
• 生成简单的单元测试骨架。
• 写注释、写文档字符串。
• 简单的文本转换、正则生成。

这些任务对模型能力要求不高，本地小模型完全够用。把这类活从云端 API 分流出去，账单能明显下降。

不过要注意，本地模型也有它的局限：上下文窗口通常更小，复杂推理能力弱。所以分流要分对，别把难题丢给本地模型，结果反复返工，反而更费时间。

4.3 批处理与异步：把零散请求攒起来

如果你有大量相似的小任务，比如给一批文件统一加注释、统一改导入风格，那批处理比一个个来更省。

原因还是那个：系统提示和背景只发一次，多个任务共享。有些 API 还提供批处理折扣，价格更低。

我处理这类任务的流程是：先把所有待处理项列出来，整理成一个结构化输入，一次性发给模型，让它按格式返回所有结果。这样比开 N 个会话逐个处理省得多。

4.4 监控与告警：别等账单来了才知道

成本优化不是一次性动作，而是持续过程。我建议至少做两件事：

• 记录每次请求的 token 用量。很多工具和 API 都会返回用量数据，把它存下来。
• 设置用量告警。当日用量或月用量超过阈值时提醒自己。

有了数据，你才能知道优化有没有效果，哪个环节还在漏钱。我一开始嫌麻烦没记录，后来发现光靠感觉判断根本不靠谱——有些我以为很省的操作，实际 token 用量并不低。

5. 工程化手段：把省钱变成系统能力

前面讲的偏使用习惯，这一节讲怎么从工程层面把成本控制固化下来。这部分适合团队或长期项目。

5.1 建立项目级的 token 预算

给项目设一个 token 预算，就像设服务器成本预算一样。具体做法：

• 按功能模块或开发阶段分配预算。
• 定期回顾实际消耗 vs 预算。
• 超支的模块重点分析原因。

这听起来有点重，但一旦跑起来，团队对成本的敏感度会明显提升。我见过不少团队，一旦把 token 用量可视化，大家的用法立刻就变了。

5.2 把高频操作封装成脚本或快捷指令

重复性的 AI 调用最容易被浪费。比如每天都要让 AI 生成某种格式的代码，那就把它封装成一个脚本或快捷指令，固定好提示词和参数。

好处有两个：一是减少每次手写提示词的 token 和出错概率；二是可以统一配置模型、输出格式、缓存策略，避免每次都要手动调。

5.3 缓存与复用：相同请求不要问两遍

有些查询是重复的，比如"这个 API 怎么用""这个错误什么意思"。这类问题如果答案稳定，完全可以缓存起来。

简单做法是建一个本地知识库，把常见问答存下来，下次直接查，不用再调模型。复杂一点可以用向量检索，但那个本身也有成本，要权衡。

我的经验是：先手动积累。把反复问过的问题和答案整理成文档，团队共享。等积累到一定量，再考虑自动化。

5.4 定期审计：找出"隐形大户"

每隔一段时间，把调用日志拉出来做一次审计。重点看：

• 哪些请求的 token 用量异常高？
• 哪些会话轮次特别多？
• 哪些任务的返工率特别高？

返工率高往往意味着提示词写得不好，或者任务本身不适合交给 AI。找到这些"隐形大户"，针对性优化，效果比泛泛地"省着用"好得多。

我上次审计就发现，有个同事习惯让 AI 处理超长日志文件，单次请求动辄几万 token。后来改成先本地过滤再交给 AI，用量直接降了一个数量级。

6. 几个我踩过的坑和实测有效的做法

最后这部分不讲理论，只讲我自己踩过的坑和验证过有效的操作。这些细节在官方文档里基本看不到，但实际用起来差别很大。

6.1 动态内容放前面会毁掉缓存

前面提过一次，这里再强调：任何会变化的内容都不要放在请求前缀。时间戳、随机 ID、变化的文件列表、当前光标位置，这些统统往后放。

我早期有个习惯，喜欢在提示词开头写"现在是 X 月 X 日，我在做 Y 项目"。结果缓存永远命中不了。后来把这些挪到末尾，或者干脆去掉，缓存命中率上来了，成本明显下降。

6.2 大文件不要整份喂，先切再喂

处理大文件时，整份塞进去既贵又容易让模型抓不住重点。正确做法是先定位再喂。

具体操作：先用搜索或 grep 找到相关代码段，只把这一段（加上必要的上下文，比如函数签名和类型定义）交给 AI。这样输入 token 可能只有原来的十分之一，输出还更准。

6.3 让 AI 先"复述任务"再动手

这是个减少返工的小技巧。在正式让它改代码之前，先让它用自己的话复述一遍任务要求。如果复述错了，你立刻就能发现，改一句话就行，不用等它写完一大堆代码再推倒重来。

复述本身消耗的 token 很少，但能避免大量无效输出。我用了这个技巧之后，返工率明显下降。

6.4 输出长度要显式限制

不限制的话，模型倾向于"多说"。我现在的习惯是在提示词里明确写"回答控制在 X 行以内"或"只给结论，不要过程"。

对于代码任务，我一般要求"只给最终代码 + 一句话说明"。这样输出 token 能压到最低，同时信息也够用。

6.5 定期清理和归档旧会话

旧会话不仅占地方，有些工具还会把它们纳入检索范围，间接增加 token 消耗。我每个月会清理一次历史会话，把有价值的结论整理成文档，其余删掉。

6.6 别忽视"重试"的成本

网络波动、服务限流导致的失败重试，也会消耗 token。尤其是长请求，重试一次就是双倍开销。

应对办法：请求前检查网络状态，避免在高峰期发大请求，对失败请求做合理的退避重试而不是立即重发。这些偏运维的细节，长期看对成本影响不小。

6.7 一个真实的优化前后对比

拿我手上一个中型项目举例，优化前后的月度 token 用量大致是这样：

这些数字是叠加效果，不是简单相加。整体下来，同样的开发工作量，token 成本降到了原来的三分之一左右。而且因为提示词更精准、返工更少，开发体验反而更好了。

成本优化这件事，核心不是"少用 AI"，而是"用得更聪明"。把上下文管好、把提示词写准、把模型选对、把重复劳动自动化，钱自然就省下来了，效率还上去了。