【AI编程干货】Token成为硬通货后，我的7000字Claude Code精算准则

哈罗，你好呀，我是涛哥，上市公司程序员裸辞，All in AI，探索 AI 编程更多可能，主要使用 Claude Code 等 AI 编程工具进行开发，打造一人公司，立志在 AI 时代做出世界级产品。

这是一篇被Claude官方新增的周限制逼出来的干货分享文章！7000+字，耗时两天打造！觉得有用的话，请点赞、转发、关注呀。

这些天因为Claude官方把账号的周限制下降了非常多（跟之前相比差不多降了80%左右），导致现在token消耗非常快，体感上可以参考下面这位twitter用户发的短文：

我也是Claude code中转站的销售，10月份正是因为claude官方限制变严格了，导致大量的中转站的运营成本大幅上升，已经有很多中转站点关闭了。我销售的这个中转站虽然没有关，但由于运营成本上来了不少，能真正给到用户消费的token数量较之前已经下降了近一半（目前还在想办法解决，如果找到方法，使用额度还会恢复上来），和官方一样，也增加了周度限制。

虽然如此，但目前我还没找到比这个中转站性价比更优的选择。在这种token数据大幅降低的情况下，我们该如何最大限度发挥出Claude code的能力，又尽可能减少token数呢？

今天我就来和大家分享一些降低Token消耗、提升产出效率的具体手段。

理清需求

AI编程工具出来后，让很多新手误以为只需要简单地说几句话，告诉AI我想要什么系统，AI就能完完整整的开发出来，但是这是一个非常大的误会。

简单的几句话，生成一个简单的系统可以；

但是当系统一旦变得复杂，功能变多，你如果还是用不清晰、不明确的语言来要求它完成任务，

那么就会失去对代码的控制，从而陷入不管如何让AI改，AI就是听不懂，没办法完成任务的境地。

因此一定要在开发之前理清你的需求，我这里提供两个理清需求的的方法

方法一：和AI聊清楚

其实聊这个不一定必须用claude（毕竟成本高），你用国产模型也是可以的，比如：deepseek，kimi k2，glm 4.6，需求聊清楚后记得把里面的重要信息整理成一个需求文档，然后在让Claude code开发时提供给它，完成需求开发。

那么如何聊清楚呢？

我一般有这么几个步骤：

1. 我想开发一个网站，那么先让AI给我提供几个类似的站点。

比如我要开发一个菜谱网站，我会让它给我几个市面上按用户量排名靠前的几个站。

然后我去看看它们大概有哪些功能，先给自己建立一下感性认知，知道菜谱类网站中的核心功能有什么，有哪些栏目，数据又是怎么一步步流动的。

1. 让AI帮我分析同类目标网站应该需要有哪些功能

不同的菜谱网站，肯定有很多功能是通用的，这些功能属于是菜谱网站必须要有的功能，比如得有菜谱吧，对应的功能就是：添加菜谱，分页列出菜谱，展示菜谱的详情，编辑菜谱信息，删除菜谱。

上面这些功能直接可以让AI帮我列出来，它列出来的功能有些可能是我们需要的，还有些可能不是我们需要的，所以还需要根据自己心里的需求，去掉或者增加新的功能，做对应的调整。比如，要给每个菜谱添加点赞、收藏、评论功能

1. 添加个性化需求

这一步需要的专业性强一些，纯小白的话还是不要想着做创新了，能够把别人的网站照猫画虎做出来就已经很不错了。

通过前两步，菜谱网站的主要功能已经确定了，但是看起来太普通了。如果我做这个菜谱网站别的菜谱网站是一样的，没有一点区分度，没有一点创新，那用户为啥来呢？

所以我会给这个站点添加上AI功能，至于添加到哪里，我考虑把AI功能添加到输入菜谱阶段。根据第一步看的几个菜谱网站，传统的菜谱网站添加菜谱，每个字段都需要手工一个一个输进去，非常麻烦，所以我这个菜谱网站想解决这个问题，直接用AI来添加。同时，用户也可以直接通过转发某个做菜视频的链接，把这个菜添加到自己的私人菜谱里去。

因为我自己在家里做菜经常是去小红书上找些视频，照着做。既然小红书上那么多菜谱，而且许多做菜教程的点击率很高，想把这些菜加到菜谱网站中来，一个一个打字输入肯定非常慢。这时候用AI就可以非常好的提高效率。

那么，AI处理这个功能的具体流程就是：

1. 输入一个视频的url
1. 提交后进行下载，提取出视频中的音频
1. 对提取出来的音频做stt（音频转文本）
1. 把提取出来的文本给AI，让AI从这些文本中整理出菜的原料和做法等
1. 最后把AI提取的数据添加到数据库中

这一步不适合纯小白，建议等有了一定的经验了以后，再思考怎么做创新，先就做好仿造网站/软件的功能就行。

因为这一步首先是需要有一定的产品思维，能洞察用户需求，发现用户的痛点，才能提出需要创新的问题。（注：这一步必须需要由人来提出问题）

其次，还需要你对技术有一定的了解，你才能根据问题提出解决方案。（注：有了问题，AI能够帮助我们提出解决方案）

最后，提出方案以后还要设计出技术实现方案。（注：这一步需要我们对方案进行判断，需要对技术有一定的理解）。

以上就是通过和AI沟通来不断完善我们需求内容，下面再讲一个更加专业的方法：竞品分析。

方法二：竞品分析

竞品调研、竞品分析是我们做产品非常重要的步骤。竞品分析，简单说，就是系统地研究与你产品类似的其他产品（即竞争对手），我们需要对比分析竞品的优势、劣势、功能、用户体验、商业模式等，来作为自己的产品决策的依据。在自媒体IP打造中有一个概念是对标分析，这应该是最近似的理解了。

不是简单的看看别人的网站或APP长什么样，而是一套结构化的研究方法，通常包括：

• 寻找合适的竞争对手（直接竞争与间接竞争）
• 确立分析维度（eg：功能、内容、用户流程、设计、技术实现等，这里我们重点关注功能）
• 深度使用竞品程序
• 收集、整理和分析（对比）数据
• 提炼出核心洞察，指导自身产品的定位与开发

那么，如何进行一次简单的竞品分析呢？

对于个人开发者，我们不需要像专业的产品经理一样做一份上百页的报告，这里有一个简单的流程可以参考：

1. 寻找竞品（3-5个左右）
我们可以通过问AI或者去专业的网站流量数据监控站点（比如 SimilarWeb）查询。
1. 确定分析维度：在这里的需求方面，我们主要关注竞品的功能和使用体验就好。
1. 整理和输出
1. 市场现状：当前行业内容大家是怎么做的？
1. 用户痛点：目前竞品的解决方案中，有哪些地方让用户不爽。
1. 我的机会：我可以在哪些方面做得更好？有什么核心优势？

通过上面两种方法对需求进行梳理后，我们是可以得到一个需求文档的，这个文档对每个功能的描述应该是比较详细的，如果没有，那么可以让AI根据我们已经得到的信息去整理一个需求文档出来。

只有把需求描述清楚了，让AI构建了足够的上下文之后，它甚至能独立地帮我实现一个完整功能，甚至构建好整个项目。只有这样AI开发出来的程序才是符合我们需求的，而不是任由它自由发挥，最后给我们一个不符合预期的程序。

到此我们得到了一份清晰的需求文档。这份文档就像是我们的'建筑蓝图'，它定义了我们要盖什么样的'房子'。但光有蓝图还无法开工，我们需要一份详细的'施工计划'，将蓝图分解为一个个可以按序执行的具体任务。这就是我们接下来要做的------任务细化。

任务细化

在明确了整体的需求文档之后，我们需要将宏观的、复杂的需求拆解成一系列微小、具体、可以立即执行且易于验证的开发步骤。细化的、独立的任务能够让我们的开发体验更加友好，避免遇到意料之外的问题。

我们还是以上面的菜谱网站为例。开发一个菜谱网站是一个大指令，我们需要将这种大指令转化为如下细化任务：

• 创建数据库并完成菜谱部分API接口，包含recipes表，字段有id、title、ingredients、steps，查询接口要支持分页查询
• 根据已有的菜谱接口，开发前端组件，用于展示菜谱列表
• ......

这种细化的任务可以有效的突破AI的上下文窗口和理解的瓶颈，当前模型的上下文窗口都有一定的限制，你如果一次性给了很多的功能点或者很大的功能，它很可能无法理解全部的关联，导致生成的代码逻辑有问题、漏洞百出。而一个清晰的小任务，AI几乎都能理解并执行。

小任务的其他好处还有，你可以掌控AI的主导权，指挥AI去完成你完全理解的小目标，整个项目构建的节奏和代码结构完全在你的掌握之中。

可以实现渐进式开发和验证，大项目最怕的就是到最后才发现整个方向都错了，细化的任务允许你"小步快跑"，每完成一个任务，你都可以立即进行测试和验证。如果出了问题，也能够非常精准地定位到是哪个小环节出错了，并针对性的让AI修改，而不是在成百上千行代码中去寻找。

该如何着手进行任务细化呢？

在项目初始化完毕，整体项目技术栈和项目目录结构已经确定。我们就可以进行拆解了。

分层拆解：按照软件开发的自然层次进行第一轮拆解：

• 数据层：需要哪些数据库表？每个表有哪些字段？
• 后端/API层：需要哪些接口？
• 前端层：需要哪些页面？

这种分层方式是非常细粒度的，但是实际指挥AI编程时，我会将相关功能后端API层和数据库层放到一起，因为这样的功能颗粒度也不算大（大模型一次开发一个功能颗粒的API和数据库定义现在还是能hold住的），而且他们的联系非常紧密，数据库的表定义语句也不长，放在一起是完全可行的。

在后端接口完成之后，我再将接口请求的curl 代码和响应数据放到提示词内，让AI生成帮我完成前端页面的开发。

总的开发顺序就是自底向上：先创建数据库和后端模型、API，再开发前端页面和交互。

好了，现在我们已经把一个宏大的需求拆解成了一个个清晰的小任务。接下来，在把任何一个任务交给Claude Code之前，还有关键一步：谋定而后动。这意味着，不要急于把帮我开发XX功能这样的模糊指令丢给AI，而是先在提示词中完成以下三要素的规划。

谋定而后动

细化开发任务之后，不要急于让AI直接生成代码，而是先在提示词中清晰地规划好三要素：业务逻辑、相关文件、上下文信息。这是一种"先设计，后编码"的严谨工作流在AI编程中的具体体现。

• 写清楚逻辑：用精确的语言描述某个功能要做什么，输入的是什么、处理过程、输出以及能够想到的边界条件和异常处理。相当于是给AI编写了一份微型"技术规格说明文档"。
• 指明相关文件：明确告诉AI需要参考、修改或创建哪些具体的代码文件，包括他们的完整路径。
• 提供上下文信息 （省token小妙招）：如果新功能依赖于已有的数据结构、配置或接口，需要将这些关键信息直接提供给AI，而不是让它自己去代码库里寻找。

谋定而后动能够帮助我们避免AI在冗长的上下文中的"降智"行为（注意力分散）和巨大的token消耗。

主要作用

• 大幅降低token消耗：避免让AI进行全项目范围的"代码阅读理解"，每次交互都聚焦在最小的必要信息集上，使得每次对话都高效且低成本。

• 从根源上减少Bug：很多Bug的产生是由于沟通不清楚和误解。当我们每次把业务逻辑写得如同下方这个案例一样清晰时，AI几乎不可能出现理解上的偏差，从而从根源上避免逻辑Bug的引入。

提示词网站的一个案例：

go 复制代码

为了节省图片的传输流量成本，现在在 
internal\api\prompts.go 文件中的 
ListPrompts 函数中不要直接返回授权好
的oss地址，你应该根据 config\config.go 
中OSSProxySrvs数组定义的代理服务和权重
信息在ListPrompts函数中按权重分配给代理服务

图片也有两种规格，见 ListPrompts 中调用的
两种方式（原图和缩略图），需要传参数到代理
接口进行对应处理和下载

ListPrompts需要返回拼接好的图片代理的url
替代当前的直接oss签名地址

代理接口开发：
根据传入的图片路径和图片规则（原图or缩略图）
自动获取oss签名的url，然后下载到本地config.go
的OssCacheDir配置的目录中（保证路径和oss一致，
同时缩略图的尺寸也要放到文件名中，便于缓存命中），
然后返回图片给前端，如果命中了缓存，那么就不要
再请求oss下载了，直接返回就好。

需要参考 deply\prd\jenkins-pipline.groovy
的流水线文件，在docker中要将宿主机的 
/data/images 目录挂载到docker中，具体是
config.go的OssCacheDir配置中（默认是 /images 目录）

接口参考 internal\api\prompts.go 文件

• 打造可维护的代码：因为我们全程深度参与了每个模块的设计，我们对整个系统的架构和数据流有了非常清晰的认识。未来如果需要修改或扩展功能时，也能迅速定位并再次使用明确精准的语言指挥AI完成开发。

如何实践"谋定而后动"？

1. 明确任务目标
1. 提示词模版：现在需要修改[代码文件路径]中的[函数/组件名]，以实现[清晰的功能目标]。
1. 交代完整业务逻辑
1. "具体的实现逻辑是：首先......然后......需要判断......如果发生......则......最后返回......。"
1. 重要：要包含输入来源、处理步骤、输出结果、错误处理、边界条件。
1. 提供关键上下文
1. "这个功能需要用到 [另一个文件路径] 中定义的 [配置/数据结构/常量]。"
1. "请参考 [参考文件路径] 中 [类似函数/组件] 的实现方式。"
1. 给出明确的输出要求
1. "你只需要输出修改后的 [目标文件] 的完整代码。"
1. "请确保新代码与现有的 [某个模块] 风格保持一致。"

*注：案例可以参考主要作用这一节里面提供的提示词案例。

及时提交代码

因为我们拆分的任务颗粒足够小，每次完成并验证一个任务之后，一定要记得提交代码。

这可以避免将本次任务生成的代码与后一次任务的代码杂糅在一起。这种杂糅的问题，如果后面这次生成的代码不出问题还好，但是，如果后一次任务出现bug，并且在短时间内无法处理，那么就会影响上一次任务。

所以为了让各个任务独立开来，不要被互相影响，务必记得及时提交代码。

git提交代码命令示例：

csharp 复制代码

# 1. 检查当前仓库状态，查看有哪些文件被修改
git status

# 2. 将需要提交的文件添加到暂存区
#（可以用 . 添加所有更改，也可以指定具体文件）
git add .

# 或者添加特定文件：
git add 文件名

# 3. 再次检查暂存区状态，确认要提交的文件无误
git status

# 4. 提交更改并添加描述信息
git commit -m "描述你完成了什么任务或修复了什么"

在合适的时机执行 /clear

Claude code中的 /clear 命令用于将本次会话中的所有消息清空，相当于一个全新的会话，token将会重新开始计算。

因为我们的开发任务拆分足够细，所以我一般会在开发一个任务，并完成测试验证没问题时就执行命令将会话清空。

但如果下一个任务会依赖上一个任务的代码，或者有一定关联，这时我不会清空，具体可以自行把握，但是一定不要让回话长度过长，否则你的token会在燃烧。

恢复上次会话

Claude code中的/resume 命令可以用户恢复到之前的某次会话，让你可以继续从上一次位置开始交流。

我用这个命令的情况主要是在Claude官方或者中转站的接口出现异常时，然后我会打开一个国产模型，恢复到接口异常时的那个会话中继续进行交流。

除了在开发流程上精打细算，我们还可以从"工具"本身入手，进一步降低成本。下面这招"邪修省钱大法"，就是在需求明确、任务细化、提示词清晰的基础上，通过"降级"使用成本更低的模型，来实现极致性价比。

邪修省钱大法

这个方法我之前也分享过，在上面需求分析明确、任务拆分清楚、提示词写详细的基础上，我会判断这个任务的复杂度。根据任务的复杂程度，我会选择到底用哪个模型来驱动Claude code来进行开发，因为很多简单的需求/任务，压根不需要用非常强的编程模型，很多国产模型也可能胜任，我常用的模型有这几个：Deepseek、kimi k2、glm 4.6。

至于如何配置，可以参看我之前写过的这篇教程：70%成本降幅！不装软件混搭 Claude Code，我的年省 2500 元秘籍。详细介绍了如何在终端中配置不安装第三方插件快速切换不同模型使用Claude code。

GitHub仓库地址：github.com/samelltiger... ，现在第一个白嫖站点经常用不了，我换成glm 4.6了

其他必选项

这些技巧可以让我们的开发体验更好，token消耗进一步降低。

`/init` 命令

每次进入Claude code，在开始开发之前请先执行/init命令，这个命令会扫描当前项目的文件结构、依赖和配置，自动帮我们创建项目级的CLAUDE.md文件（如果已经有的话，则会补充内容到此文件），这个文件一般会包含项目架构、常用命令、代码规范、测试与环境说明等信息，可以看作是Claude的"项目说明书"。

这个文件可以让Claude在后续的对话中具备对项目的"全局理解"，可在同目录会话或子目录会话中直接引用，减少重复解释与上下文丢失。