AI

两种账单，两种形状 主机账单是容量。你加 CPU、带宽、存储，表针跟着流量曲线走；看过一个月，下个月能猜到几个百分点以内的误差。 token 账单是行为。两个流量完全一样的团队，账单可以差 20 倍——因为一个团队每次请求带 12,000 token 的检索上下文，另一个只缓存了 400 token 的系统提示、其余什么都不带。同样的用户、同样的功能，账单天差地别。 这不是定价的猫腻，而是计量方式决定的：你按 token 付费，而 token 数量是设计决策。 让花费变跳的三个效应 1. 输入通常远多于输出，两者单价还不一样。 在多数对话与检索功能里，输入 token 是输出的 5～20 倍，而输出 token 的单价往往是输入的几倍。所以「我们只生成一小段回答」这句话，对成本没有任何说明力。 2. 缓存输入是另一套费率。 供应商对重复出现的输入给更便宜的价格——固定的系统提示、不变的长文档、大段指令。忽略缓存，就等于每次请求都为同样的 3,000 token 付全价。 3. 每次请求的上下文能差一个数量级。 一个每轮都追加对话历史的总结任务，等于每次都把整份记录重新发一遍。成本增长比轮数更快：第 20 轮很贵，是因为第 1 到 19 轮又在账单上出现了一次。 重试和工具调用还会再加一个在任何用量图表里都看不见的乘数：一次失败后重试的调用会计费两次；每轮调四个工具的 Agent，每轮计费五次。 杠杆，按收益排序 团队的第一反应通常是去换模型。那很少是最大的杠杆。建议按这个顺序试： 先砍上下文。 删掉检索到却不影响答案的文档、限制回溯的历史长度、把永不变的部分放进缓存。这往往是单项收益最大的一步。 限制输出长度。 直接要求形状（「三条要点，不要前言」），而不是给一个宽松的 token 上限。模型生成的那 900 token 客套话，是你在付费。 不紧急的走批次。 夜间补数、回填、评测这类任务通常可以接受更慢但更便宜的路径。 最后才换模型。 把摘要任务降级到更小的模型确实是省钱——但这是在前面三步已经压小的那个数字上，再省一次。 上线前先估一遍 你需要每次请求的两个数字：输入 token 与输出 token。功能已经上线，就直接从 API 返回里读，不要估。还没上线，只能先猜： 每月成本 ≈ 每天请求数 × 30 × (输入 ÷ 1M × 输入单价 + 输出 ÷ 1M × 输出单价) 猜的时候有两个坑：一是平均数会掩盖最贵的那次请求（一份长文档的 p95 请求可能是中位数的 30 倍，而账单正是它决定的）；二是多轮功能让平均数失去意义，因为每一轮都拖着完整历史。 ...

这是协作问题，不是技术问题 这个场景在各个团队反复上演：有人打开了 Agent，看着它干活，然后某一天发现只读开关不见了，或者在你还在看第一个 diff 的时候它还在继续改。一小时后分支上有四十个改动，一半跟任务无关，没人说得清 src/legacy/ 为什么被动过。 接下来的抱怨总是同一句：我已经不认识这份代码了。 严格说，这不是 Agent 的 bug，而是一条从没被写下来的规则，正在被一次次事故发现。 写一段更长的提示词解决不了 第一反应通常是写更长的 prompt：「不要改无关文件、不要删测试、不要动部署配置」。它能撑过这个 session，然后就消失了。 提示词是「每个 session、每个人」的；放在仓库里的文件会被每一次 session、每一位同事、每一个你换用的 Agent 读到——更关键的是，它可以像代码一样被 review。团队只需要在一个 PR 里吵一次，而不是每次被 Agent 吓到才吵。 四道护栏，按收益顺序 1. 规则文件。 AGENTS.md（或 CLAUDE.md，或你的 Agent 从项目根目录读取的那个文件）定义什么叫「做完」：哪些指令才算验证、哪些路径不能碰、哪些事绝对不能自作主张。短到人也会愿意读。 2. 权限清单。 三份清单，结构比语法更重要： 清单 放什么 例子 allow 只读操作，加上项目本来就会跑的 test / lint / build Bash(pnpm test:*) ask 会改写历史、安装依赖、连网的行为 Bash(git push:*) deny 机密文件、正式环境配置、部署流程、破坏性指令 Read(./.env) 没列到的一律回到「问人」。真正要避免的失败模式是：权限宽到没人愿意读。 3. 保护路径。 机密文件、正式环境配置、数据库 migration、CI 定义都要被明确点名，规则文件和 .gitignore 里各写一份。这一步把「判断题」变成「机械检查」——而只有机械检查能扛住截止日期。 4. 合并前的审查清单。 护栏判断不了设计好坏，所以清单负责补位：diff 是不是超出了这个任务该有的规模、有没有删掉或放宽测试、有没有把错误悄悄吞掉、总结里的数据是否都能对应到某次命令输出。 护栏生成器 可以用一份短表单产出上面这四份文件——命令、允许路径、保护路径、要强制的规则——并且跟随页面语言切换中英文。 护栏做不到什么 说清楚边界比夸大宣传重要，因为夸大最容易让团队信错东西： ...

一种没人及时发现的失误 让 AI 总结一条 CI pipeline，你会得到一段很整齐的话：lint 阶段 42 秒、build 3.5 分钟、整条 pipeline 16.4 分钟、比上周快 18%。读起来像一份报告。两个小时后才有人发现 build 从来没有花过 3.5 分钟，而失败率是从另一周抄来的。 这段话看起来没有任何可疑之处。问题就在这里：编造的数字和真实的数字，排版上完全一样。 为什么模型会这样 AI 在写总结时并不是在查你导出档里的行，而是在生成「最像下一个词」的内容——而「像」不等于「有出处」。两种失误最常见： 编造：那里需要一个数字，于是就生成了一个。「失败率 2.4%」会出现，是因为 pipeline 总结里通常有失败率，而不是因为 2.4% 真的存在。 漂移：数字本身是真的，但在流转中变了样——被四舍五入两次、秒和分钟换算错、从相邻的行/周/项目里串了行。 这两种都能通过人工审阅，因为审阅看的是文字逻辑，不是算术。 五分钟核验流程 1. 留原始导出，不要只留摘要。 把 CSV、日志、SQL 查询结果交给 AI。如果来源本身就是摘要，就没有东西可以核对了。 2. 把每个数字都当成需要出处的断言。 一条实用规则：没有来源行号，就不进报告。 这跟新闻业要求引用出处是一个道理，只是用在算术上。 3. 先对单位，再对数值。 1500 ms、1.5 s、0.025 min 是同一个时长。AI 总结里大量「看起来错」的数字其实是单位或四舍五入造成的，而真正编造的数字就藏在这片噪声里。 4. 留出容差。 摘要里保留三位有效数字的数值不可能和原始的 4183000 完全相等。设一个小的相对容差（1% 是个合理默认值），超出容差的判定为「待核实」，而不是直接判错。 5. 把「待核实」和「错误」分开。 待核实代表你贴的来源里找不到它——它可能是对的，只是来自你还没提供的数据；但在找到那个来源之前，它不能进报告。 AI 数字核验器 把第 3～5 步自动化了：把 AI 回答和来源一起贴进去，它会抽出每个数字、归一化单位与倍数量词、逐一比对，并把找不到出处的标红，同时给出对应的来源行号作为证据。 标红之后做什么 按影响从大到小处理，并给每个数字归类： 现象 常见原因 处理方式 完全找不到，但量级合理 编造 删掉，或者要求给出出处 差几个百分点 四舍五入、口径不同、周期不同 确认统计周期再用 只在单位换算后才匹配 摘要产生的偏差 可以用，但要写清单位 匹配到相邻但不同的行 串行 改正，并复查相邻数字 这套方法的边界 比宣传更重要的是说清限制：核验工具确认的是可追溯性，不是真实性。 ...