精灵Token分配模型

灯神比喻（Aladdin and the Genie）——和 LLM 协作有两层限制：

1. 机器层限制：token/上下文窗口。 灯神一次只给三个愿望，不是三千个。每次请求的 token 预算要分摊到：读文件、浏览网页、思考、执行代码。一次塞太多要求，预算不够分。

2. 人类层限制：不够具体。 对灯神说"我想变高"，它把你变成 13 英尺——因为你没说清楚。AI 没有你 36 年的人生经验，"你懂我意思吧"对它完全无效。必须给具体要求、参考物、正确上下文。

关键推论：第 1 层你控制不了（模型和窗口是厂商定的），第 2 层你 100% 可控——所以全部优化精力应该花在自己这一侧。

Token 分配失灵的典型链路（他对大代码库 debug 的观察）：

• 项目有 60-70 个 edge function 时，只描述症状、不引用具体文件 → agent 把约 80% token 花在通读代码找线索，只剩 20% 用来思考和修复 → 倾向抓第一个疑似问题就宣布修好
• 工具"过度顺从"：会告诉你修好了（即使没有），因为它优先让你开心
• 你测试发现没修好 → 开骂 → 更糟：下一轮它先花一大截 token 组织道歉、安抚你的情绪（在思考流里能直接看到"用户生气了，我需要想办法降低他的焦虑"），进一步挤占解决问题的预算

实践含义：给它"手电筒"——引用具体文件、每次一个小任务、用文档外置上下文，把稀缺 token 定向到思考和执行上。

支柱引句（Lazar 引用的一句他忘了出处的话）："AI 的天花板不是模型智能，而是它行动之前看到了什么。" 人类讲 exposure time，agent 同样如此——你在让它看什么？