13.1M token，426条消息，10天密集使用Claude Code——产品经理Bekah Hawrot Weigel把整个过程录了下来，逐帧复盘。她原本想优化效率，结果挖出一个被集体忽略的成本：alignment tax（对齐税）。简单说，就是你和AI互相"对暗号"的时间。
她算了一笔账：实际推进任务的时间不到40%，剩下超过60%花在建立共同语境、澄清需求、验证结果、修正偏差。这些环节没有直接产出，但没有它们，任务根本跑不通。Weigel把这叫"对齐税"，和"心流"（momentum）形成一对张力。
对齐税长什么样
Weigel的日志里有个典型片段：她描述一个需求，Claude返回答案"接近但不完全对"；她修正，Claude调整；她验证，发现文件名不匹配；她修复引用，检查目录，最终确认。这套循环，她每天都在经历。
拆解下来，她同时在做两件事：一是任务本身，二是建立任务依赖的共享语境。第二件事就是对齐税——额外循环不花在产出上，而花在让双方"活在同一个现实"里。心流让人上瘾，对齐税让人想摔键盘。但两者往往交织在一起，难以切割。
更隐蔽的是，对齐税会伪装成"正常沟通"。Weigel发现，自己多次陷入同一类陷阱：假设Claude知道某个文件的上下文，结果它其实没读；假设它理解了指令的优先级，结果它按字面执行。每次假设失败，都要额外回合修补。
为什么我们会低估它
Weigel的观察很直接：人类倾向于用产出衡量会话成败——任务完成、代码提交、文档发布。只要终点到达，过程里的摩擦就被自动合理化。但数据不会说谎，13.1M token里藏着大量"无效中间态"。
她把对齐税的来源归为几类：上下文丢失（模型忘记 earlier 对话）、假设错位（双方对"简单"的定义不同）、验证成本（必须人工检查才能确认结果可用）。这些都不是bug，是当前架构的固有特性。
一个反直觉的发现：token消耗和实际进展并不线性相关。有些会话token飙升是因为反复对齐，有些会话token精简是因为上下文刚好对齐。Weigel建议把"对齐效率"单独作为指标，而非只看总token或总时长。
怎么缴更少的税
Weigel的应对策略偏向工程化。她开始给Claude更结构化的上下文：显式列出相关文件、定义术语、前置约束条件。效果立竿见影——对齐回合减少，但前期准备时间增加。这是个权衡。
另一个技巧是"验证前置"：在指令里直接嵌入验收标准，让Claude自我检查。比如不说"优化这段代码"，而说"优化这段代码，要求运行时低于X毫秒，并通过Y测试用例"。把隐性预期变成显性约束，减少后期返工。
她还实验了"会话分片"：长任务拆成多个独立会话，每个会话重置上下文、明确目标。代价是失去连续性收益，收益是降低上下文漂移风险。没有银弹，只有场景适配。
心流与税的博弈
Weigel坦承，自己最初被AI协作的"速度感"吸引——那种想法快速变成原型的爽感。但10天数据让她清醒：心流时刻确实存在，但和对齐税交替出现，整体效率被后者大幅稀释。
她的核心建议不是消灭对齐税，而是让它可见。记录会话、标注摩擦点、量化非任务时间——只有先看见，才能优化。她开源了自己的日志模板，鼓励更多人做同样的事。
「下次你完成一个AI会话，先别急着标记'productive'。」Weigel写道，「问问自己：实际推进任务的时间占比多少？如果低于一半，你可能在缴一笔没意识到的税。」
这笔税，你上个月缴了多少？
热门跟贴