别再喂整个Notebook！代码差异法省下95% Token

为什么你的Token账单在燃烧？

如果你习惯在Jupyter Notebook里写代码，然后直接把整个.ipynb文件丢给Claude Code或Codex CLI做评审，可能已经发现成本高得离谱。一位Kaggle开发者实测发现，一个notebook动辄消耗约3万tokens，来回问几次，账单就失控了。

问题的根源在于.ipynb本质是JSON，里面塞满了单元格输出（日志、图片）和元数据，而LLM真正需要的往往只是代码本身。这位开发者在Qiita上分享了一套组合拳，把每次评审的token消耗压到1k–1.6k，降幅超过95%。

rss source: I Stopped Feeding Whole Jupyter Notebooks to LLMs and Cut Tokens by Over 95% (Claude Code / Codex CL

核心技巧：只传代码单元格差异

剥离输出与元数据

作者写了一个脚本，自动丢弃notebook中的输出和metadata，只提取代码单元格。这一步直接砍掉了绝大部分冗余体积——毕竟LLM看代码评审时，不需要知道你上一次运行打印了什么日志。

.ipynb文件本质上是一个JSON文档，遵循nbformat规范，其顶层结构包含cells数组、metadata对象和nbformat版本号。每个cell又分为cell_type（code/markdown/raw）、source（源码行列表）、outputs（仅code cell）和metadata。outputs里可能嵌套text/plain日志、image/png的base64编码（一张截图动辄数十万字符）、application/vnd.plotly等富媒体，这些对内联AI评审而言完全是噪声。此外每个cell的execution_count、collapsed等元数据也在悄悄膨胀体积。理解这层结构就能明白：真正承载逻辑的只有code cell的source字段，剥离其余部分是一次无损于评审质量、却极大压缩上下文的操作。

只输出与上一版本的diff

更巧妙的做法是：脚本只输出相对于上一版本的差异。对于迭代式开发，每次改动其实很小，传全量代码毫无必要。diff把“本次改了什么”精确地呈现给模型，上下文更干净，评审也更聚焦。

diff（差异比较）是版本控制中的基础概念，通常以统一格式呈现：以-开头表示被删除的行、+开头表示新增的行，@@标记变更所在的代码块位置及行号。对LLM而言，diff的价值不只是省token——它把模型的注意力约束在“本次改动了什么”上，避免全量代码中大量未变逻辑稀释评审焦点。这与人类code review的习惯一致：评审者看的是pull request的patch，而非整个仓库。在notebook场景中，由于单元格可以任意增删、重排、修改，diff粒度通常落在cell级别，再对cell内部的源码行做行级diff，兼顾准确性与压缩率。

超长行用长度+哈希替代

Notebook里常见超长字符串（比如嵌入的prompt模板），直接传会占用大量token且影响可读性。脚本将超过300字符的行替换为“长度+哈希值”——LLM只需要知道这行内容变了没有，无需看到全文。

读写视图分离

作者还提出了一个工程习惯：把notebook里冗长的prompt字符串拆到独立的.txt文件，形成一份“阅读视图”。实际运行的notebook保持单文件不变，而给LLM评审时传阅读视图。执行与阅读两个角色分开，两边都清爽。

用命令行调用AI编程助手

Claude Code：禁用工具，只喂摘要

通过claude -p可以单次问答、不走交互界面：

claude -p --max-turns 1 --disallowedTools "Bash,Read,..."

关键点在于禁用文件读取等工具，只传你自己准备好的摘要。否则模型会主动去读仓库里的文件，token消耗立刻反弹。把主动权收回来，成本才可控。

claude -p中的-p即--print，是Claude Code的非交互模式：把提示词作为参数或标准输入传入，模型输出结果后直接退出，不进入多轮对话的REPL界面，因而非常适合脚本化调用。--max-turns 1限制模型最多只进行一轮推理与工具调用循环，防止其在禁用工具后仍尝试重试。--disallowedTools则是一份黑名单，可逐项列出禁止调用的工具名（如Bash、Read、Grep、Glob），被禁用的工具不会出现在模型的可用工具清单中。Claude Code默认具备自主读写文件、执行命令的能力，这是它作为编程代理的卖点，但在“只评审我传给你的摘要”这一场景下反而成为成本漏洞——模型会主动去仓库里翻文件补全上下文。用黑名单收窄权限，才能把上下文边界牢牢控制在调用方手里。

Codex CLI：标准输入传问题

Codex CLI通过npm安装：npm i -g @openai/codex。当浏览器登录失败时，作者发现用设备码认证可以绕过：

codex login --device-auth

提问则通过标准输入传入：

echo "Your question here" | codex exec --skip-git-repo-check -

Windows PowerShell的坑

日文乱码：三处编码都要设UTF-8

在PowerShell中把日文prompt管道传给CLI，会出现乱码。解决方案是把输入、输出和$OutputEncoding三处全部设为UTF-8：

[Console]::InputEncoding  = [System.Text.Encoding]::UTF8
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding           = [System.Text.Encoding]::UTF8

这个问题对所有非ASCII字符（包括中文）同样适用，Windows用户值得提前配好。

Windows PowerShell的管道编码问题源于其历史包袱：Windows控制台默认使用系统代码页（如中文环境的GBK/CP936、日文环境的CP932），而现代CLI工具普遍按UTF-8读写标准输入输出。当文本经过管道时，PowerShell会用$OutputEncoding指定的编码把字符串编码成字节流喂给子进程，若该值仍是旧代码页，非ASCII字符就会在编码转换中损坏并显示为乱码。三处设置分别对应管道的不同环节：[Console]::InputEncoding控制控制台读取输入的编码，[Console]::OutputEncoding控制控制台显示外部程序输出的编码，$OutputEncoding控制PowerShell向外部程序管道写入时的编码。三者统一为UTF-8，才能保证非ASCII字符从输入到输出全程不被错误转码。

不能用&串联命令

PowerShell不支持cmd风格的&命令串联，会报AmpersandNotAllowed错误。从cmd迁移过来的人容易在这里翻车。

这套方法的适用边界

需要说明的是，这套方案建立在“迭代式评审”的工作流上——你先写代码，再让模型看增量改动。如果是首次让模型理解整个项目结构，diff策略就不适用了，此时仍需提供一定量的全量上下文。另外，禁用工具虽然省钱，但也意味着模型无法自行验证代码在仓库中的实际依赖关系，评审深度会打折扣。

对于频繁与LLM往返的notebook开发者，这仍然是一个投入产出比很高的优化：一个几十行的脚本，换来95%以上的token节省。

要点回顾

传代码单元格diff而非整个notebook，token从约30k降至1k–1.6k
超长行用长度+哈希替代，既省token又保留“是否变化”的信息
claude -p配合--disallowedTools禁用工具，防止模型自行读文件
Codex CLI登录失败时改用codex login --device-auth
PowerShell处理非ASCII文本需三处编码统一为UTF-8