别再晒 Token 了：我用 Claude Code 做项目，66.6M 也够用

我突然打开 Claude Code，看了一眼自己的 Token 消耗：

66.6M。

连 1 亿都没到。

再看看网上，有人动不动就晒几亿 Token，数字大得像在参加一场“谁的电费更高”比赛。

可问题是：

Token 用得多，真的代表你做得多吗？

我用 Claude Code 做过这些事：

• 做了 agentskillshub.top，目前有一定流量
• 搭建 jasonzhu.ai 和 Gosail Club，累计营收超过 2 万
• 参与 gosaillab.com 的合同撰写、规则设计等工作，帮助业务带来几十万营收

这些事情没有靠堆 Token 完成。

真正重要的，是你有没有把 Claude Code 接进真实项目里。

Token 不是战绩，交付才是

Token 更像是“油耗”。

它可以反映你和模型聊了多少、改了多少代码、反复调试了多少次，却不能直接说明项目质量。

你可以花 2 亿 Token：

• 反复讨论一个没人使用的产品
• 让模型重写几十遍登录页面
• 在需求不清楚的情况下不断补丁式修改
• 每次遇到报错都重新开一个上下文

也可以用 6000 万 Token：

• 做出一个能访问的网站
• 把业务规则写成可执行的文档
• 生成合同初稿并交给专业人士审核
• 把重复性的运营流程自动化

真正值得看的指标，是这些：

• 产品有没有上线
• 有没有真实用户
• 有没有带来收入
• 交付时间缩短了多少
• 你每天能不能少加班一小时

Token 数字很容易晒。

结果没那么容易。

我把 Claude Code 用在了哪些地方？

1. 从想法直接推进到网站

以 agentskillshub.top 为例，Claude Code 可以参与很多具体工作：

• 梳理网站信息架构
• 设计页面结构
• 编写前端组件
• 接入数据接口
• 处理部署问题
• 修改移动端样式
• 排查线上报错
• 根据用户反馈继续迭代

关键不在于“一句话生成完整网站”。

这种宣传听起来很爽，实际开发很容易翻车。

更稳的方式，是把任务切成一块块可验证的工作。

你可以这样下指令：

请先阅读当前项目结构，不要修改代码。
告诉我：
1. 项目使用的技术栈
2. 页面入口文件
3. 数据获取方式
4. 当前最可能影响首页加载速度的三个问题

等我确认后，再开始修改。

这一步很重要。

别让模型一上来就“自由发挥”。不然它可能把你的项目改成一场大型拆迁现场。

2. 把业务规则写成可以执行的东西

很多人的业务规则只存在于脑子里，或者散落在聊天记录、表格和语音消息里。

这种状态很危险。

新人接手看不懂，客户问起来说不清，团队执行时各有一套理解。

用 Claude Code 整理规则时，可以按下面的结构输入：

请把下面这套业务规则整理成一份可执行文档，要求：

- 明确适用对象
- 明确触发条件
- 明确例外情况
- 明确处理步骤
- 明确责任人
- 明确输入和输出
- 为每条规则补充一个真实场景示例

不要自行补充没有依据的规则。
遇到信息缺失，请单独列出“待确认问题”。

这类任务的价值很直接：

• 新员工更快上手
• 客服回复口径统一
• 产品需求更容易落地
• 开发人员少来回猜需求
• 后续可以继续接入自动化流程

一份写清楚的规则文档，往往比一段漂亮的宣传文案更值钱。

3. 合同撰写：让模型做初稿，不要让它替你拍板

Claude Code 可以辅助处理合同相关工作，例如：

• 根据业务背景生成合同初稿
• 提取双方权利义务
• 标记付款、交付、违约等关键条款
• 对比两个版本的差异
• 找出前后表述不一致的地方
• 把复杂条款改写成内部执行说明

一个可复用的提示词如下：

请根据以下业务信息生成合同初稿：

合作双方：
项目内容：
交付标准：
付款方式：
交付时间：
售后范围：
违约处理：
争议解决方式：

要求：
1. 用清晰、正式的中文
2. 把模糊内容列为待确认项
3. 单独列出可能产生争议的条款
4. 不要编造法律依据
5. 在文末增加“需人工审核清单”

注意，这里有一条底线：

AI 可以帮你起草、整理、检查，不能替代律师或专业人士做最终判断。

尤其是金额较大、责任复杂、涉及知识产权或劳动关系的合同，别把模型输出直接发给客户。省下的审核时间，不能拿来省掉审核本身。

一套更稳的 Claude Code 工作流

第一步：先交代项目背景

不要只说：

帮我做一个网站。

这句话的信息量太低。

换成：

我要做一个面向独立开发者的资源导航网站。
目标用户是有开发经验、需要快速寻找工具的人。
网站需要支持分类浏览、关键词搜索、详情页和提交资源。
第一版先追求简单、可部署、移动端可用。
请先帮我拆解功能，不要写代码。

模型知道的上下文越完整，后面的返工越少。

第二步：让模型先拆任务

可以要求它输出：

• 产品目标
• 页面清单
• 功能优先级
• 数据结构
• 技术方案
• 风险点
• 第一版不做什么

“第一版不做什么”特别关键。

很多项目不是做不出来，而是第一版就想塞进十几个功能，最后一个都没上线。

第三步：一次只推进一个小目标

例如：

现在只实现资源列表页。
要求：
- 使用现有项目技术栈
- 支持分类筛选
- 支持关键词搜索
- 移动端正常显示
- 不修改其他页面

完成后告诉我：
1. 修改了哪些文件
2. 如何本地测试
3. 还存在哪些已知问题

任务边界越清楚，代码越容易检查。

第四步：每次修改后都要验证

不要看到模型说“已完成”就直接相信。

你要让它自己跑检查：

请运行项目测试和构建命令。
如果失败：
1. 给出完整报错
2. 判断问题原因
3. 只修复与本次任务相关的问题
4. 修复后重新运行检查

开发中最浪费时间的场景，就是模型修了一个问题，又顺手制造三个新问题。

第五步：保留决策记录

每个项目都建议保留一个 DECISIONS.md 文件，记录：

• 为什么选择当前技术方案
• 哪些功能暂时不做
• 哪些业务规则已经确认
• 哪些问题仍然待定
• 哪些代码不能随意修改

以后你重新打开项目，Claude Code 能更快恢复上下文。

你也不用每次从头解释：“这个项目之前是怎么想的来着？”

Token 用得少，可能说明你做对了这些事

需求足够清楚

需求越模糊，模型越需要来回猜。

你反复说“感觉不太对”“再高级一点”“更有质感”，Token 很快就烧起来了。

上下文管理得好

把项目说明、技术约束、业务规则集中放进文档，模型就不用每轮重新听你讲一遍。

任务拆得合理

大任务容易失控。

小任务更方便测试、回滚和验收。

不把模型当搜索框

Claude Code 适合参与项目执行。

如果你只是不断问概念、让它写长篇解释，却没有实际落地，Token 消耗很高也很正常。只是这种消耗不一定产生价值。

常见误区清单

误区一：把 Token 数量当成努力证明

晒 Token 很容易带来一种“我今天干了很多事”的错觉。

可你真正应该问的是：

• 今天上线了什么？
• 哪个流程被自动化了？
• 哪个客户问题被解决了？
• 哪笔收入是这套系统带来的？

数字很热闹，结果更诚实。

误区二：让模型一次性改完整个项目

这通常会带来：

• 修改范围失控
• 原有功能被破坏
• 问题难以定位
• 回滚成本变高

把任务切小。每一步都能验收。

误区三：不看代码，只看页面截图

页面能打开，不代表项目健康。

你还要检查：

• 是否有明显报错
• 数据请求是否正常
• 权限控制是否存在漏洞
• 移动端是否能用
• 构建是否成功
• 敏感信息有没有提交到仓库

误区四：把 AI 生成内容直接用于高风险场景

合同、财务、隐私、权限、生产环境，都需要人工复核。

模型的语气可以很确定，事实却可能错得很坚定。

一份可以直接复制的项目提示词

你现在是这个项目的开发协作者。

项目目标：
用户对象：
当前阶段：
使用技术：
明确不做的功能：

工作规则：
1. 修改前先阅读相关文件
2. 不要擅自改变技术栈
3. 不要修改与当前任务无关的代码
4. 信息不足时先提问，不要自行编造
5. 每次完成后说明修改文件、测试方式和已知问题
6. 涉及删除、迁移、权限、支付的操作，必须先获得确认

当前任务：

验收标准：

这份模板不花哨，却能明显减少无效来回。

别只盯着 Token，盯住交付

66.6M Token 不是什么值得炫耀的勋章，也不代表使用量少到没有价值。

它只是一个过程指标。

真正有价值的是：

• 网站上线了
• 用户开始访问了
• 业务规则被整理清楚了
• 合同交付速度变快了
• 项目带来了真实收入

如果你每天都在晒 Token，却说不清自己交付了什么，可能只是把“忙碌”误认成了“进步”。

下次打开 Claude Code，别急着看消耗量。

先问自己一句：

我今天能不能让一个真实项目往前走一步？

这比多消耗几个亿 Token，靠谱多了。