做企业级AI Agent的时候，几乎每个人都会踩同一个坑。

Demo阶段，所有人关心的都是效果——”能不能跑通？””回答准不准？””看起来聪不聪明？”没人盯成本。

等到系统真正跑起来，账单甩到你脸上的时候，你才会感受到——

Token 就是 Agent 时代的电费。而说到省 token，大部分人上来就盯着 prompt 写短点、加个缓存——这些当然有用，但它属于末端的小修小补。真正的省，在架构和治理决策的关口上。

我给你拆成四个层级，从前到后，越靠前越剩的多。

第一层：权衡适用于Agent的场景

这是最容易被跳过的一层，也是最省钱的一层。

现在 Agent 太火了，火到什么程度呢？很多团队一上来就把所有任务都包成 Agent。但 Agent 的本质是什么？是”让大模型自己决定下一步做什么”。大模型每一次生成都带着概率和随机性——这既是它智能的来源，也是它成本和不确定性的来源。

所以判断标准其实特别朴素——

流程固定的，用 Workflow。路径不确定的，才用 Agent。

什么叫流程固定？简单说就是你能提前把它画成一张流程图。

工单分类路由、固定格式的信息抽取、按模板生成回执、定时报表汇总——这些事儿步骤是确定的，不需要让模型思考。该调模型的环节调一次就行了，其余靠规则流转。

这一刀砍下去，token 消耗可能直接腰斩。而且结果更稳定、更可控——LLM的本质还是概率预测，这样也可以减少模型突然”灵光一现”走偏了的情况。

那什么场景必须上 Agent 呢？事先画不出完整流程图、下一步依赖上一步结果的那种开放式任务。比如做一个调研——下一步搜什么、要不要深挖，取决于上一步查到了什么。比如一个故障排查——先看日志，然后根据日志内容决定是查数据库还是查配置文件。

这种”走一步看一步”的活儿，才值得为 Agent 的灵活性付那个溢价。

一个很容易踩的坑：Agent 拆太碎了

就算你确定了某个场景该上 Agent，也不意味着要把它拆成一大堆小 Agent 互相调用。

为什么？因为多 Agent 之间每一次交接，都要传上下文、都要发生一次模型调用。拆得越碎，Agent 之间的沟通就越重。

我见过一个特别典型的案例——把一个本来可以一次完成的任务，拆成了四个 Agent：”规划 Agent → 检索 Agent → 分析 Agent → 总结 Agent”。结果光是它们之间互相传话、反复确认，就烧掉了比干活本身还多的 token。

正确的做法是：该上 Agent 的整体场景上 Agent，但内部的子步骤如果是确定的，就在这个 Agent 内部用 Workflow 式的固定逻辑串起来，别拆成更多子 Agent。Agent 负责那个不确定的主干决策，确定的枝节用 Workflow 收进来。

能用 Workflow 的别上 Agent，非上 Agent 不可的，也别拆太碎。

第二层：别全程顶配，按场景分模型

确定了哪里真的需要模型之后，第二个决策是：每个环节用哪个模型？

很多人有个惯性思维——”全程用最好的”，从头到尾顶配。只要你看账单衡量一下消耗和产出，就能很明显觉得需要有分级：

难活派给贵的、聪明的；简单活派给便宜的、够用的。

那些真正需要强推理、容错率低的环节——复杂决策、高质量代码生成——值得上最强模型，因为这里质量直接决定成败，省不得。而那些大量常规的、确定性高的环节——分类、抽取、格式化、简单问答——用便宜模型完全够用。在高频调用下，这一项省下来的可能是数量级的差异。

但有个重要的例外

对小公司、小团队来说，有时候第一版直接上最贵的模型，反而是对的。

为什么？因为 Agent 落地的初期，最大的风险不是成本，而是员工不信任它、觉得它不聪明，然后直接弃用。这个阶段，让员工第一次用就感觉到”这东西是真聪明”，建立起信任，比省那点钱重要得多。而且小公司的文件体量、调用量通常不大，贵模型和便宜模型的绝对费用差距其实很小——你省下的几十块钱，可能换来的是整个团队对 AI 的抵触。

所以这一条要辩证看：成本优化是为业务服务的，不是为省钱而省钱。判断标准永远是”这一步的钱花得值不值”，而不是”贵的就浪费”。

分诊机制：便宜模型当前台，贵模型只看专家号

“按场景分模型”是原则，落地的时候你需要一个具体的机制来执行它。这个机制叫”分诊”。

逻辑跟医院一模一样——不是所有病人一来就挂专家号，而是先经过分诊台。一个便宜、快速的小模型先接住所有任务，简单的它自己当场处理掉，只有真正复杂、它拿不准的，才升级转交给贵模型。

那么问题哪些问题用便宜的，哪些问题用贵的呢？

轻量模型

• 文本分类、意图识别、打标签
• 固定格式的信息抽取
• 简单问答、改写、摘要
• 格式转换（表格↔文字、文字→JSON）

强模型

• 复杂推理、多步逻辑决策
• 高质量代码生成、复杂系统设计
• 长程 Agent 任务、复杂工具调用编排
• 多模态理解（图/音/视频）
• 高价值、低容错的对外场景

为了更直观的举例，我把市面上常见的大模型对照关系做成一张表（方向仅供参考，以最新版本和实测为准）：

第三层：给 Agent 装个”刹车”

说完主动省token的场景，还需要防失控。

Agent——尤其是多个 Agent 互相调用的时候——有个非常真实的危险：它可能陷进某种循环，或者越想越深，在你不知道的情况下，几分钟烧掉一大笔 token。大模型的随机性意味着，你没法百分百保证它每次都规规矩矩地停下来。

• 预算熔断。给一个任务设 token 上限，烧到这个数就强制暂停，转人工确认——”这个任务已经花了 X，要不要继续？”
• 轮次上限。给 Agent 之间的对话或调用设最大轮数，比如来回超过 N 轮还没收敛，就停下来交给人判断，而不是让它无限自循环。
• 关键节点的人工确认。在那些”一旦做错代价很大”或”即将触发大量后续调用”的节点，插一个人工确认的卡点。

与其事后看着账单心疼，不如事前给它划好不能越过的红线。不仅是省钱，也是控风险。

第四层：给每个 Agent 装个”电表”

省 token 不是一次性动作，是个持续迭代的过程。而迭代的前提是可观测。

一个非常实用的做法是：给每个 Agent——甚至每个任务——配一个 token 仪表盘，清清楚楚显示：这次任务烧了多少 token、花在哪个环节、调用了哪个模型、花了多少钱。

有了这块”电表”，很多优化才有据可依：你能看到哪个 Agent 是吞金兽，知道该优先优化谁。你能发现某个环节其实用便宜模型就够，做模型降级。你能定位某类任务总是异常地贵，去查是不是 prompt 设计或流程有问题。

看不见的成本没法管理，先让它可见。

再补几个多 Agent 协同的省钱小技巧

前面四层是骨架。既然聊到多Agent协同，再补几个更细的思路：

• 上下文别无脑全量传递。多Agent协作最隐蔽的浪费，是Agent之间传信息时，把完整对话历史一股脑全塞过去，越往后越臃肿。让上游 Agent 只传”结论/摘要”，而不是”全过程”——下游要的是结果，不是你整个思考过程的草稿。
• 结果缓存与复用。多个Agent在一个任务里，很可能重复检索同样的内容、重复问同样的子问题。建一个共享的结果缓存，相同的子任务直接复用上次结果，别重复付费。
• 设计【停】的卡点。多Agent讨论协作时，容易出现”已经得到足够好的答案了，但它们还在反复确认”的情况。设计一个机制，一旦判断”答案已经足够”就主动收敛结束。很多token是浪费在”已经够了但还在继续”上的。

写在最后

回头看这四层，你会发现一个挺有意思的规律：

省token省得最多的地方，几乎都不在“技术细节”里，而在“架构和治理决策”里。

要不要用Agent、用什么模型、给不给它装刹车、能不能看见它花了多少——这些都是在设计AI产品架构就该想清楚的判断。等到上线之后才想起在 prompt里抠字数，那是末端的小修小补，省不出量级的差异。

Token 是Agent时代的电费。而真正会省电的人，不是天天盯着电表抠那一度两度，而是在装修的时候就把电路设计对了。

生成式AI的商业化叙事，正面临三年来最深刻的一次自我审视。从以补贴换用户、月包订阅隐藏成本，到按Token计费引爆企业账单危机，AI行业用三年时间完成了一次商业化的三级跳——而一场潜在的价格战，可能让整套变现逻辑再度归零。

据《华尔街日报》报道，OpenAI正在考虑大幅下调向用户收取的Token费用，以从竞争对手Anthropic手中争夺企业客户。据知情人士称，此举部分是为“抢占先手”，OpenAI预计Anthropic也将采取的类似降价行动。OpenAI首席执行官Sam Altman近期在一场活动上承认，AI使用成本已成为”一个巨大问题”，并表示将”帮助人们用更少的支出获得更多价值”。

这一消息的时机格外敏感。OpenAI本周已秘密提交IPO申请，Anthropic同样处于上市倒计时阶段。与此同时，彭博Silicon Data LLM Token支出指数已连续7个交易日下跌，创今年1月以来最长连跌纪录，折射出市场对AI账单可持续性的深层焦虑。报道直言，价格战将直接侵蚀两家公司的利润率——而两家公司目前均已因AI系统所需的庞大算力亏损数十亿美元。

这场讨论的核心，不再只是一次降价决策，而是一个更根本的问题：当”Token消耗越多越好”的叙事走到尽头，AI行业下一个商业化故事将由谁来讲，又将如何讲。

01、初始三阶段：从月包补贴到Token账单

生成式AI的商业化，在短短三年内经历了清晰的三段演变。

第一阶段，月包和年包订阅奠定行业基调。2023年2月，OpenAI推出月费19.99美元的ChatGPT Plus，开创大模型C端付费先例；百度、阿里、腾讯随后跟进，固定月费订阅成为初级商业模式的标配。

第二阶段，补贴大战全面爆发。为拉高ARR（年度经常性收入）这一融资估值的核心锚点，各家厂商转向大规模补贴：谷歌为学生免费提供15个月Gemini Advanced，OpenAI推出首月1美元的Team版会员，字节跳动豆包以”比行业价低99.3%”的定价入场，百度宣布核心模型免费。补贴的本质是以亏损换增长——据报道，微软在GitHub Copilot订阅模式下平均每位用户每月亏损超过20美元，部分重度用户月亏损高达80美元。

第三阶段，是按量计费的强制切换。2026年6月1日，微软宣布GitHub Copilot所有计划正式转向基于Token用量计费，月费19美元直接转化为等额Token额度。这一改变，将被订阅制长期掩藏的真实成本摆上台面——据Reddit社区用户测算，一次智能体编程会话可消耗30至40美元，单月套餐在单次使用中即告耗尽。

02、账单失控：当Token比人更贵

Token按量计费的落地，将企业AI支出的真实面目完整呈现。

企业端的账单数字触目惊心。Uber首席运营官Andrew Macdonald在2026年5月公开表示，Token消耗的增长与产品实质改善之间，”这条线还不存在”，并为此专门造了一个词：”tokenmaxxing”（Token极大化），形容员工为刷使用量而执行无价值任务。

更直接的数据是：Uber仅2026年前四个月就耗尽了全年Token预算；Salesforce预计全年付给Anthropic的费用将达约3亿美元。

Anthropic自己的开发者文档显示，使用Claude Code的开发者平均成本约为每个工作日13美元，90%的用户每日成本低于30美元——折算下来，一个10人开发团队仅Token费用一年就可能超过75600美元。

投入产出比同样令人警觉。企业数据平台Entelligence.AI汇总2444家企业的数据后发现，每投入1美元的AI Token费用，仅有18美分产生了触达用户的实际价值；44美分用于修复AI自身引入的Bug，27美分流向返工，11美分消耗于审查摩擦。

面对失控的账单，企业端已开始主动管控。亚马逊叫停了内部AI使用排行榜，要求员工”不要为了用AI而用AI”；微软计划逐步停用部分关键产品部门员工的Claude Code订阅。高盛指出，部分企业用于AI Token的支出已占其员工总人力成本的10%，未来几个季度这一比例可能进一步攀升。这不是需求消失，而是AI支出的粗放时代走向终结。

03、第四幕：价格战打响，OpenAI考虑大幅降价

正是在这样的背景下，价格战的导火索被点燃。

据《华尔街日报》报道，Altman的降价考量直接由追赶Anthropic的压力所触发。Anthropic的收入近期大幅增长，旗下编程工具Claude Code在软件工程师群体中走红，这家成立五年的初创公司估值甚至首次超过OpenAI。

然而，这场价格战的代价将异常沉重。价格若大幅下调，将进一步压缩两家公司本就为负的利润空间，而竞争格局提供的空间极为有限。

而投资者长期以来识别出的底层风险是，OpenAI与Anthropic的产品具有高度可替代性，客户可以轻易从一家转向另一家——这意味着降价即便短期留住客户，也无法真正构建护城河，只是延缓了份额流失。

这一困境还通过云计算巨头与AI实验室之间的财务循环向外传导。

据The Information汇编的企业披露文件，OpenAI和Anthropic合计占微软、甲骨文、谷歌和亚马逊约2万亿美元未来云服务承诺的逾半数。若降价引发收入预期下修，这条传导链条将双向承压。

美国神经科学和人工智能专家Gary Marcus说道：“这进一步暴露了OpenAI的脆弱，也表明了它面临的困境有多严重。一旦OpenAI走下坡路，很可能会拖垮英伟达、甲骨文、Coreweave等公司。局势正在迅速恶化。”

多空分歧在华尔街公开对峙。摩根大通TMT分析师Mark Schilsky认为，当前账单焦虑不过是”通往更高支出的最小减速带”：若每百万Token均价下降，但美国公司AI付费渗透率持续上升，总体Token用量在数学上必然大幅增加；加之代理式AI（agentic AI）将单任务Token消耗推升至传统问答模式的数倍，长期总支出料将显著高于当前水平。

高盛半导体分析师Jim Covello则持更为悲观的立场，认为当前产业链繁荣几乎将所有价值导向半导体公司，这一现象”在历史上前所未有且不可持续”，一旦企业直面按量计费的真实价格，支撑GPU采购和模型训练的资本流动将面临逆转。

04、第五幕：Token经济学的下一个故事？

价格战之后，AI行业商业化的下一章尚未写就，但轮廓正在浮现。

Citadel证券的报告提供了一个方向性框架：分层收费与按稀缺性定价。其核心逻辑是，推理密集型前沿AI不会消失，但会越来越集中在少数有能力承担算力成本的大型企业手中；对更广泛的企业而言，在物理约束缓解之前，更简单的模型可能是更具生产力的路径。这意味着AI使用将走向分层——高价值、复杂任务继续使用前沿模型，日常任务、批量任务则转向廉价模型或本地模型。

摩根大通则持相对乐观的判断：即便单位Token价格下降，智能体AI（agentic AI）的普及将使每个任务的Token消耗倍增——现有数据显示，业务agent化后每个任务的Token消耗可变为原来的3.5倍——总体支出规模仍有望继续扩大，当前的账单焦虑或许只是”通往更高支出的最小减速带”。

Nebius首席营收官Marc Boroditsky提出了”valuemaxxing”的概念，主张行业从追求Token消耗最大化，转向使每个Token真正产生价值。这一方向正逐渐成为行业共识——但真正的商业落地，仍需要AI实验室找到一套既能反映真实成本、又能被企业客户接受的定价体系，而这正是当前所有争论尚未解决的核心命题。

然而，在这场价格战中，最被忽视的变量或许是中国模型。

据美国企业支出管理平台Ramp的6月数据，DeepSeek已登顶美国企业软件订阅增速榜首。Ramp首席经济学家Ara Kharazian特别强调，这并非开源模型的本地部署，”企业在直接通过DeepSeek收发数据”，是真实付费的直连使用——他坦言”没有料到美国公司会去用DeepSeek”。据第三方测算，DeepSeek V4-Pro的API均价约为GPT-5.5的十分之一，约为Claude Opus 4.7的十一分之一。

OpenAI与Anthropic两虎相争，最终受益的，可能是那个早已将”普惠定价”写入基因、且不需要向IPO投资者交代利润率的玩家。这或许不是这场价格战最受欢迎的结局，但正在成为越来越难以忽视的现实。

作者：徐超

来源：硬AI

2026年世界杯还没揭幕，几家AI公司先在场外较上了劲。

这届世界杯扩军到48支队、104场比赛，是史上规模最大的一届，也顺理成章成了各家大模型秀肌肉的舞台。

6月8日，Kimi正式下场，玩法跟别人不太一样。

它没有只发条预测、截张图就了事，而是用Agent集群调度300个子Agent，对104场比赛逐场做赛前预测、赛后复盘。在冠军的预测上，Kimi并没有否认西班牙、法国仍是热门候选，但提出德国队“可能被市场低估”，有可能“爆冷”夺冠。它甚至还公开喊话其他大模型，一起来预测、同场检验。

Kimi小组赛预测图

更加另类的是，预测文章里的第一句话就是：“我们的预测很可能是错的”。它认为，AI不该被包装成永远正确的系统，应当更透明地讲清自己的能力边界。

办这场活动，当然有商业上的考量，拉新、导流，给刚上线的Kimi Work攒一波声量。但Kimi这套又是公开预测、又是邀人挑错的操作，更像是在向“包装万能”的AI行业潜规则发起挑战，它想让更多人看清，今天的AI到底能做什么、又做不到什么。

这恰恰是很多人忽略的一点。如今我们已经习惯让AI查资料、写方案，甚至替我们拿主意，可真要依赖AI做判断，光有答案还不够，还得知道这个答案有几分靠谱。

于是问题来了：我们嘴上都说想要AI说实话，可它真说出“我没把握”时，我们究竟会更信它，还是掉头去找那个顺着你说、给你信心的AI？

诚实，对一家AI公司来说，到底是加分项，还是劝退项？Kimi想用104场世界杯球赛，把这个问题摆上台面。

01.Kimi为什么敢押德国队？

先说说用户能怎么参与这场活动。

从6月9日起，登录Kimi，选一支自己支持的主队，这支队每赢一场，参与的人就可以瓜分一个总额1万亿的Token奖池；德国队要是赢球，所有用户还有机会参与瓜分额外10亿Token池。这些Token能直接用于刚上线不久的Kimi Work。这是一个面向知识工作者的本地Agent，能帮用户建站、做PPT、查金融和法律资料等等。

活动一宣布，已经有球迷开始畅想今年夏天的生活：白天把一部分工作丢给Kimi Work；深夜凌晨熬夜看球，再让它陪着算哪支球队赢面更大。工作、看球两不误。

Kimi Work

福利之外，Kimi这次最让人意外的，是它押注德国队可能“爆冷”夺冠，认为它是被市场低估得最明显的强队之一。

按Kimi报告，西班牙、法国、阿根廷都处在热门区间，但德国的特殊之处在于：按博彩市场的赔率倒推，它的夺冠概率约为7.4%；但Kimi模型校准后给到11.3%，两者相差3.9个百分点。

Kimi为什么认为德国被低估？它的判断来自几条分析链路的交叉验证。

最直接的线索，是市场共识和球队基础实力指标之间存在错位。按转会市场的阵容身价算，德国排世界第四；但按市场隐含概率看，德国只排第七。拿巴西做个对照就清楚了：它的阵容身价比德国低（世界第六），市场给出夺冠排序却是世界第四。

按照这个逻辑，市场对巴西偏宽容，对德国偏苛刻。报告把原因归结为“近因偏差”：人对最近发生的坏事，总是记得格外清楚。德国连续两届世界杯小组出局，球迷和庄家都有“心理阴影”了，导致市场可能没有充分考虑一些新变量。比如，教练纳格尔斯曼接手后，高位逼抢的打法回来了；穆西亚拉和维尔茨这条年轻轴线，也解决了“控球多威胁少”的老毛病。

Kimi在报告里也承认，德国这3.6个百分点的正向偏差，可能是市场低估，也可能是模型高估，真正答案要等比赛验证。

Kimi的活动宣布以后，有人叫好，评论区有人说：“敢预测就是一种勇气，无论最后结果是否正确”。也有人等着看笑话，留言说：“德国队夺冠我把球吃了”。更多人则在边上等着数它猜中了几场。猜砸了就是“AI果然不懂球”，偶尔押中，又会被说成“蒙的”。

但用“德国是否夺冠”来评价Kimi的预测能力，并不准确。它押的不是“德国一定能夺冠”，而是“市场低估了德国队”，这是两码事。Kimi的判断是否成立，不能只看德国有没有捧杯，还要看它在淘汰赛走到哪里、面对强队的表现如何，以及赛后复盘中，模型给出的11.3%是否比市场隐含的7.4%更接近真实表现。

Kimi的这种做法，在AI圈里并不常见。平时AI展示能力，要么是在发布会上放段demo，演示永远一气呵成，要么从案例库里挑几个成功的摆出来，个个无懈可击。这些事后都能修饰、能筛选，外人根本无从证伪，它没拿出来的那些失败，我们永远看不到。

而Kimi选了世界杯这个谁也无法作弊的场子，104场预测结果，对了错了都摆在明面上，想赖也赖不掉。它甘愿冒着“当众出丑”的风险，到底图什么？

02.AI为什么集体“装神”，又为什么有人开始“认怂”

要回答这个问题，得先看清楚整个行业的默认玩法。

AI预测赛事，最安全的做法是随大流。足球充满偶然，跟着主流押西班牙、法国是最稳的，猜中是意料之中，押错也是大家一起错，没有哪家会被单独苛责。

可正是这套“随大流”的做法，多年来已经把AI预测做成了一门娱乐性大于实用性的营销生意。

回看历史就知道：2018年俄罗斯世界杯，主流AI集体看走眼，微软、百度、多家投行与学术AI普遍把西班牙、德国、巴西，列为夺冠前三热门，结果冠军是法国。

2022年卡塔尔世界杯，几家机构的AI看好阿根廷夺冠并押中，但也有押错的，比如半岛电视台AI看好法国，且全场次命中率都不算高：半岛电视台58.7%，538（FiveThirtyEight）为57.1%，比乱猜强些，但离“神准”差得远。

战绩如此一般，为什么各家还抢着预测？这背后有多层原因。

最表层，预测不需要担责，赛前抛出预测赚波关注，猜错了也没什么代价。

其次是用户在用脚投票。我们嘴上说想要诚实的AI，可真到用的时候，多半会下意识选那个“听起来更自信”的AI。

而最深层，藏在模型被训练出来的方式里。如今的大模型，是靠人类一条一条打分调教出来的。人对“肯定、完整、好听”的回答打高分，对“我不知道”打低分；连给模型测分的榜单，也大多是答错扣分、空着零分。这样反复训练下来，模型就被喂出了一种本能：宁可编一个像模像样的答案，也不愿承认“我没把握”。甚至有研究发现，AI比人更爱顺着用户、附和一句“你说得对”，它被调教出的首要目标是让你满意，而不是对你诚实。

放到公司层面，这就成了一个典型的“囚徒困境”：单看每一家，把话说满、多拉用户是理性选择；可当所有人都这么做，整个行业的可信度就被一点点透支了。从ChatGPT刚火时“AI无所不能”的论调，到后来幻觉频出、翻车不断，公众的信任度一路下滑。过去五年，全球公众对AI的信任度从61%降到53%；凯捷研究院今年初调研了15个行业、约1500名高管，超过七成担心AI的安全性、可解释性与可靠性尚未得到充分验证。

面对这个困境，Kimi换了一套衡量预测好坏的标准。它给出的不只是预测结果，还给每场比赛标了高、中、低三档置信度，并且交代得很清楚：高置信度那批，它历史上能对85%到90%；中等的掉到55%到65%；低置信度的，准确率不高。

它这么做，是想把用户的注意力从“它单次有没有命中”，转向“它报出来的置信度和实际正确率是否匹配”。这在统计学里叫“校准”（calibration）。

拿天气预报来类比，更容易理解。预报说今天70%下雨，结果没下，你能说它预报错误吗？不能，单独一天说明不了什么，概率描述的是长期频率。真正的检验方法是，把它说过“70%下雨”的所有日子汇总，如果实际降雨占比接近70%，概率校准就是良好的。

AI也是同样的道理。模型一味输出绝对化结论，属于置信度失准、高估了自身能力。它每“猜中”一次，都是在给“AI可信度”埋雷，因为长期会误导用户全盘信任，一旦模型失误，无论是实际影响还是口碑信誉，都会付出更大的代价。

明白了概率校准的逻辑，再来看Kimi的做法就更容易理解。它没有回避自身短板，还在报告里公开展示了过往赛事的预测成绩：2018、2022两届世界杯，论单场胜负的命中率，它的模型不但没赢过博彩市场，还略低一点（2018年是58.4%对60.1%，2022年差距更大）；几场最著名的冷门，沙特赢阿根廷、日本接连赢德国和西班牙，它都没押中。需要说明的是，这是全部场次的命中率，和前面高置信度那批85%以上的准确率，并不是一个口径。

Kimi甚至承认：受模型误差所限，它报出的西班牙基准概率16.5%也不精确，按历史回测中的平均误差来粗略理解，真实概率甚至可能在6.5%-26.5%这样更宽泛的区间。报告里还有句提醒：任何号称能给出比这更精确数字的模型，要么是过度自信，要么是在藏着掖着自己的不确定性。别家比的是精确，Kimi却反过来提醒你“要警惕”。

不仅如此，Kimi还试图推动整个行业改变现状，公开邀请其他大模型下场预测。行业陷入“囚徒困境”，根源在于各家互不参照。可要是大家都在同一批比赛中同步公开预测结果，高下自然一目了然。104场下来，谁更靠谱、谁夸大其词，用户自有判断。长此以往，“诚实”不再是劣势，反而会成为行业的基本准则。

当然，这暂时只是Kimi的一厢情愿，有没有同行响应还不确定。但Kimi传递出的态度很明确：AI不是万能的，AI公司也没必要装成万能。坦然讲清自身能力的边界，才是AI企业应有的担当。

03.拿万亿Token，考一场作不了弊的试

话说回来，第一个把“AI可能会错”摆上台面，需要勇气，也得承担风险。对于Kimi来说，主动自曝短板、公开不确定性，会不会把用户“吓跑”？如果104场赛事预测的整体准确率不高，会不会被扣上“AI不懂球”的帽子？明知存在用户认知和舆论的风险，Kimi还是这么做了，背后大概有两点考量。

一方面，是技术上有底。

kimi展示的Agent集群过程

不同于传统大模型只是输出结论、模糊推理过程的预测，Kimi这300个Agent各管一个维度：有的看球队基础实力，用Elo评分（一种按历史战绩动态计算的实力分）和FIFA（国际足联）排名打底；有的算进攻和防守质量，靠xG（预期进球）这类指标；有的专门研究战术之间怎么相互克制；有的盯赛程、天气、长途奔波这些场外因素；还有的紧盯赔率变化，从市场和模型的偏差里找线索。

每个Agent都会给出判断、佐证数据、置信程度，还会附上“反方意见”，最后由模型融合校验，生成最终预测概率。关键在于，它摒弃了“少数服从多数”的投票逻辑，反而将模型内部的分歧本身当作重要的决策信息，最大化还原赛事预测的不确定性。

就拿德国这个重点案例来说，模型专门派了五个Agent从不同角度研判，其中一个的任务就是“唱反调”，专门推演德国的翻车风险：比如，回归的门将诺伊尔已经40岁高龄、德国队的高压逼抢战术在高温环境下可能拖垮体能。

与此同时，Kimi不只挑球迷爱听的说。对眼下被市场热捧的英格兰队，它判断“被高估了”；对所有模型一致看好的热门球队，它也特意提醒，热门共识也不等于确定性结论。

为了做到坦诚，Kimi甚至把“自己可能猜错的原因”做了归类，包括数据滞后、假设失效、临场意外等，同时明确了赛后复盘迭代的标准化流程。

种种细节看下来，这场赛事预测，并非随意输出的娱乐性推演，而是一次准备充分、逻辑完整的专业建模实践。

另一重考量，是它对用户需求变化的一次押注。

AI正越来越多地替人做决定：帮你看体检报告、审核合同、判断钱往哪儿投。这些场景容错率极低，错一次的代价可能是真金白银，甚至是健康。

这时候，一味顺着你说、主打“让你满意”的AI，恰恰需要警惕，因为它一旦出错，你可能连提前防备的机会都没有。反过来，敢说“不确定”、“不知道”的AI，至少给你留出了自己判断和兜底的余地。

AI用得越深入，“诚实”就越是刚需。这也和它一直以来的定位保持一致，比起陪聊娱乐，Kimi更多被用在写代码、做研究、处理复杂任务上。越是这种较真的场景，用户越需要一个肯交底的工具。不靠“装神”，AI照样有价值。

Kimi网站首页截图

除此之外，本次活动里还有一个有意思的设计：每进一球，Kimi就向中国足球捐10亿Token，用来支持基层、校园和青训的教练用上AI工具，预计覆盖一万多人。

这一笔捐赠，其实和它看好的德国队遥相呼应。德国主帅纳格尔斯曼今年38岁，靠数据和建模重新武装这支老牌强队。这种数据能力，过去是职业顶级球队才用起的奢侈品。Kimi想做的，是把数据能力输送到中国校园和基层的球场中去。

这些Token能不能真帮上中国足球，是另一回事。但它给出了一个行业方向：AI的终极价值，不是制造精准预测的噱头，而是过去属于少数人的数据和技术，让更多人用得起。

04.结语

足球是世界上最难预测的运动，没有之一。一张红牌、一次VAR改判、门将一个神扑、一场突如其来的暴雨，都可能改写比分。

正因为算不准，世界杯才成了检验“诚实”最好的考场。在这里，AI可以假装胸有成竹，然后被打脸；也可以从一开始就坦承自己有几分把握、可能错在哪儿，再把每一步推理展示出来。Kimi选了后一种。

德国队到底是否被低估，7月自有分晓；可“AI该不该更诚实”这个问题，没那么容易有答案。Kimi至少先迈出一步，用一种能被验证、甚至可能被打脸的方式，告诉更多人：AI并非万能。这个问题的答案，其实不在AI，而在我们。我们最终会使用怎样的AI，取决于今天的我们更愿意为哪一种买单。

1个月烧出5亿美元账单！

近日，科技圈曝出一桩惊天乌龙。据Axios报道，一家企业在短短1个月内，竟然在Claude上刷爆5亿美元！

原因令人哭笑不得：管理层在给员工开通Claude账号权限时，忘了设置使用额度上限。

其实，AI账单爆仓的远不止这一家。

今年4月，一名谷歌云用户因公开服务中遗留的API key被滥用，原本只有7美元预算的账户，一夜之间收到了1.8万美元的账单。

这个倒霉用户名叫Jesse Davies，是一名澳大利亚AI顾问、Agentic Labs创始人。他给自己的Google Cloud账户设了两道保险：一个10澳元（约7美元）的预算预警，一个1400美元的硬性消费上限。

据Tom’s Hardware报道，攻击者发现了他几个月前从AI Studio发布的一个Cloud Run服务，发了6万多个请求，两道保险都没拦住：账单计算有延迟，等系统反应过来，金额已经飙到了1.8万美元。

5月中旬，开源项目OpenClaw的创始人Peter Steinberger在X上贴出一张截图：30天，OpenAI API账单130万美元。

他的团队只有三个人，但他们指挥的100个Codex智能体在并行跑：30天烧掉6030亿个Token、跑出760万次请求。还好，这130万美元并非他自掏腰包。

Steinberger今年2月加入了OpenAI，这130万美元被当作一次内部实验：

测试如果不考虑Token成本，AI编程能跑到什么极限。他补充道，这是Codex「Fast Mode」（高速档计费）的结果，关掉之后大约30万美元。

更早一些，Uber的CTO Praveen Neppalli Naga也曾向The Information承认，公司4月份就把全年的Claude Code预算烧光了，他们的COO也公开表示，AI成本越来越「难以自圆其说」。

5亿、130万、1.8万，金额虽然差出几个数量级，却指向同一个事实：

在智能体时代，失控的密钥、昼夜无休的智能体军团、忘了设上限的账号：任何一个，都能让你的Token账单一夜刷爆。

AI账单为什么会爆仓？

答案主要藏在计费方式的变化里。

从今年4月起，OpenAI的包月计费方式开始转向按Token用量计费。

4月2日，Codex计费从按消息估算改成按Token用量对齐：输入、缓存输入、输出三类Token分开算。4月23日，这套规则扩展到所有Enterprise、Edu、Health、Gov方案：月费里那笔看不见的折扣被抽掉了。

GitHub也紧随其后，刚刚官宣：所有Copilot套餐从2026年6月1日起，转向按用量计费。旧的高级请求逻辑作废，换成AI额度，按输入Token、输出Token、缓存Token的实际消耗，对照每个模型的API费率结算。

GitHub官方解释了这么做的原因：

现在一个快速的聊天提问，和一次跑好几小时的自主编码任务，用户花的钱一样多。GitHub一直在替那些跑重度任务的用户买单，但这套模式已经不可持续。

AI智能体崛起之前，聊天和补全成本差不多，月费兜得住。

智能体崛起之后，一次任务能连续跑几小时、改动整个代码库，重度用户和轻度用户的成本差可以拉到几个数量级。月费制在这种差距面前，直接崩了。

消息一出，Reddit和X上一片哗然。

一位ID为JBusu的开发者晒出了账单截图，直言新定价「就是个笑话」。原本28.12美元/月的开销，按新制要付746.01美元，他已决定退订，「这个价格，我自己租云服务器都还便宜」。

另一名用户截图更夸张，费用从50美元一路狂飙到3000美元，他说没想到定价这样离谱，「还有人继续订阅吗？」

不过也有Copilot老用户出来反驳：这些极端账单多半是vibe-coder（凭感觉编码者）们不把烧Token当回事给烧出来的，未必能代表正常使用。

一位老用户在评论区留言：「我整天都在用，月底基本不超额，很难相信这是工作复杂度的差异。」另一位则更直接：「就是有人要全自动的YOLO模式开发，让AI随便跑。这种浪费被剔除，对其他人反而是好事。」

有一点必须清楚：GitHub没有废除月费，基础订阅价格并没有变。真正变的是额外用量、智能体任务、更贵的模型调用，从此进入用量计费。

被冲击最大的，是那些靠Copilot跑长链任务的重度智能体用户。

被自己人玩坏的排行榜

月费失守，一面是平台改了计费规则，另一面是用AI的人，自己也在拼命烧。

5月，Business Insider报道，Amazon下线了一个名叫KiroRank的内部AI使用排行榜。

该报道援引知情人士的话称，这个榜单悄悄催生了一种奇怪的工作方式：部分员工为了在榜单上多爬几位，会去刷一些并不解决实际问题的Token消耗，纯粹为了排名。

事情曝出之后，Amazon高级副总裁Dave Treadwell直接向全员喊话：「别为了用AI而用AI。用它去解决客户问题，解决业务问题，去创新。」

这事虽然有点荒唐，但毫不意外。当「烧Token」能上榜，员工自然就会去烧Token。

硅谷给这种现象起了个专门的名字：Tokenmaxxing（极限烧Token），把消耗量当生产力。

Axios的报道里也提到，有CTO发现员工拿AI模型查天气、写日常邮件，简单到不行的事，套上最贵的前沿模型，账单就能悄无声息地飞涨。

KiroRank并非Amazon官方考核体系，而是员工自发搭的非正式工具。但它清楚地暴露了一个经典的管理学规律：当KPI设错的时候，人就会用最聪明的方式钻空子。

把「用了多少」等同于「干得好不好」——这正是这一轮AI浪费的制度性根源。

算Token账的人，已经在赚钱

Token账单焦虑的另一面，有人悄悄把它做成了生意。

第一条路：用上下文喂饱AI。

Glean正是Arvind自家公司。它做的就是企业AI工作助手：把分散在公司各处的知识统一打通，让员工的AI直接拿到上下文，不必再四处翻箱倒柜。AI少绕路，烧的Token自然就少。

这套机制让Glean的年度营收15个月翻三倍，跨过3亿美元，客户包括Databricks、Reddit、Samsung。

第二条路：把活分给对的模型。

模型路由初创公司Factory AI干的就是这件事：自动把每个任务派给最合适的模型，简单任务走便宜档，复杂任务走顶配。Arvind也讲过：路由做对了，能省10倍。

这两条路殊途同归：让AI干活，但别让它乱烧。

学术圈的研究，也在为这种转向奠基。

https://arxiv.org/pdf/2604.22750

2026年4月的一篇arXiv论文，第一次系统拆解了智能体编码任务到底怎么烧钱。

结论一：智能体任务的Token消耗，可达普通代码推理和代码对话的上千倍，推高成本的主因是输入Token。

结论二：同一个任务跑多次，Token消耗能差出30倍。

结论三：更高的Token消耗，并不必然带来更高准确率。精度往往在中等成本处见顶——再往上烧，钱花了，效果反而饱和。

论文还发现，前沿模型连预测自己要烧多少Token都做不到，普遍低估真实成本。

你以为多花钱就能多办事。实际是钱花了，活不一定更好，预算还算不准。

当AI账单开始赶超人力成本

「这是我记忆中第一次，技术成本开始和人力成本持平。」

5月29日，Glean CEO Arvind Jain在接受CNBC记者Deirdre Bosa采访时这样讲道。

英伟达应用深度学习副总裁Bryan Catanzaro的观察也印证了这一点。

他在Axios访谈里提到：对于他的团队来说，算力成本已经远远超过员工薪资。

类似的现象正在多家公司浮现：从做企业AI的Glean，到卖AI算力的英伟达，再到用AI的Uber，都在重新审视这笔账。

在Arvind看来，历史上技术只是企业整体成本里很小的一块，但现在AI成本已经能追平工资单了，很多企业的年度AI预算通常都是一到两个月就烧光。

过去一年，AI使用率是被崇拜的指标：多用就是先进，烧Token就是拥抱未来。现在，许多企业开始反思那句朴素的话：这些烧掉的Token，到底换来了什么？

免费包月畅用的窗口期，恰恰正在此时关上。

接下来，摆在所有开发者面前的是这样一个问题：如何精打细算，让每一个Token发挥出最大价值。

未来真正的赢家，毫无疑问将是最先学会算Token账的那个。

作者：ASI启示录

来源：新智元

前阵子，被观众誉为“国产爱死机”的、由国人创作者Mx-Shell制作的AI视频短片《丧尸清道夫》，在国内外视频平台迅速走红。全片虽无一句对白，却依靠恰到好处的配乐、行云流水的运镜，以及机器人主角“屏幕表情”的微妙变化，将废土世界中的孤独与温柔刻画得入木三分。

B级片式的狂野脑洞与宇宙级的浪漫想象，搭配上专业的视觉叙事，让这部单人耗时十天、Token成本仅三千元打造的AI短片打破了文化壁垒，以千万级的总播放量，成为了当代AI视频的标杆级作品。

令人称奇的是，Mx-Shell并非影视或游戏行业的科班出身。他来自云南宣威，公开资料里，他自称中专学历，此前主要靠自学音乐、摄影和AI视频创作。纯靠视听直觉加上一点镜头经验的“野路子”，就完成了这次AI视频的内容输出。

随着作品的全球走红，大批的资本与产业力量也被Mx-Shell的创作才能所吸引。不仅好莱坞AI影视圈的导演发来邮件洽谈，国内多家影视公司和AI大模型平台也纷纷向其抛出橄榄枝。

不过，Mx-Shell并没有如大多数人预想的那样加入好莱坞电影公司，根据他的个人社交账号显示，Mx-Shell是Yoroll的签约游戏创作者，他也很快发布了游戏公告和海报，称这款《丧尸清道夫》AI互动视频游戏已经在制作阶段，将和Yoroll平台共同开发和发行。

对于部分读者来说，Yoroll可能还是一个相对陌生的名字。但在当下的游戏与AI大模型交汇赛道上，它是近期AI互动内容方向中较受关注的新团队之一。

作为新加坡AI公司LinearGame的旗下平台，Yoroll（yoroll.ai）在今年硅谷的GDC与NVIDIA GTC双会场初次亮相。它首创了将世界模型与互动视频相融合的解决方案，凭借一套内嵌在编辑器内的完整生产工具，将传统游戏管线中动辄近千万元的研发门槛，直接压缩至十万元量级的低成本。

其背后的全球化团队，不仅集结了前《The Walking Dead: Survivors》制作人、《影之刃》前客户端主程，更有曾在好莱坞顶级工作室深耕近二十年、主导过《权力的游戏》《对马岛之魂》的Telltale工作室前Story Lead，以及爆款真人互动剧《完蛋！我被美女包围了》的核心主创。

除了豪华的跨国正规军班底，在内容生态的排兵布阵上，Yoroll也已经初步进入了实战阶段。在第一方游戏内容上，推出了多款游戏的PV和试玩版，包括星际探索游戏《Star Junkers》、末日逃亡作品《Dead Reckoning: Reborn》、电竞恋爱游戏《VOW：谁说带妹不能拿世界冠军？》、民俗恐怖解谜游戏《民国诡事》，在Steam上获得了数万心愿单，还孵化出了让零经验外部创作者在一周内手搓出百万播放的UGC爆款《华君传》。

如今Mx-Shell《丧尸清道夫》的游戏官宣，也间接帮助Yoroll向业界释放了招揽全球顶尖AI创作者的积极信号。AI短片的爆款可以诞生在社媒，社媒爆款的下一站会是互动视频游戏吗？Yoroll又是以何种方式，定义AI游戏的互动娱乐体验？带着这些疑问，游戏那点事近日邀请到了Mx-Shell本人以及Yoroll创始人Heath进行了一场对话。

（在刚刚结束的戛纳国际电影节上《丧尸清道夫》的短片和游戏也获得了好莱坞导演们的广泛关注）

在交流中我们能感受到，面对行业机遇，Mx-Shell代表的是发散的“野生创意”与“直觉驱动”；而Heath所输出的，则是试图将这一切收束的“工业化平台”与“系统性解法”。两者的思想碰撞，恰好回答了当下行业最关心的问题：在AI带来技术平权之后，好创意的商业化落地，路在何方？

（以下为采访Q&A，为方便阅读，部分内容已做调整）

伯乐与千里马

游戏那点事：《丧尸清道夫》爆火后，两位有何感想？

Mx-Shell：我最大的感受就是，整个人突然忙得不可开交了，心情倒没有太大的起伏。看着网络上各种赞誉，我很清楚自己的技术水平，这部作品如果回归到工业标准来看算不上最顶尖，它只是完成度较高、质量不错的一部AI短片。这里面能有今天的反响，运气踩中了极大的比重，甚至可以说是某种被老天爷选中的玄学吧。

Heath：我觉得这意味着AI视频创作真正跨过了一个决定性的临界节点。当一个没有太多影视或者游戏科班背景的普通创作者，能仅靠工具触达这种作品质量高度时，内容创作的“科技平权”已经落地，UGC内容的爆发指日可待。

游戏那点事：作品走红后，好莱坞的导演、国内头部的影视公司和各大模型平台都给Mx-Shell发去了邀请，大部分合作都被拒绝了。为什么IP游戏化合作能够得以推进呢？

Heath：Yoroll作为一个主打UGC的互动视频游戏平台，在海内外短视频平台建立了一套敏锐的AI创作者发掘机制。在这次爆火之前，我们其实就和Mx-Shell建立了联系，邀请他成为了Yoroll平台的AI创作者。片子爆火后我们看到评论和弹幕里出现大量粉丝想要玩到游戏版，加上Mx-Shell本人也认同做游戏会有更大的内容包容度，于是我们一拍即合，在极短时间内就敲定了游戏化改编的独家发行权。

从产品侧的直觉来看，这个片子天生自带游戏基因，里面的射击打丧尸、飞船探索、机器人主角等设定，都是玩家在商业游戏市场里很受欢迎的品类。

Mx-Shell：我是一个比较凭感觉走的人，我喜欢和最早找到我、最早认定我的人合作。在《丧尸清道夫》还没有今天这个热度的时候，Yoroll的团队就已经毫无保留地展现出了对这个作品的喜爱和信任。我挑合作伙伴不看背景有多显赫，也不看制作团队规模有多庞大，我只认准一点：你是不是懂我的伯乐？

另外，做游戏的设定，Yoroll能够把我原作中那些废土式的戏谑、甚至一部分稍微狂野血腥的画面原汁原味地保留下来，这一点对我来说非常重要。

游戏那点事：作为非科班出身的摄影师，Mx-Shell是如何完成这次跨界制作的？

Mx-Shell：最早接触AI视频的契机其实很偶然，我姐姐家新开了一家酒店，还在装修期，手里完全没有任何实拍的宣传素材。当时为了做装修效果图，我就琢磨着能不能用AI把它们变成动态视频，那次应该算是我完整接触AI工具的入口点，纯粹是出于兴趣吧。

大家现在看到的是，我作为一个非科班出身的人做出了这个作品。但我认为，底层的能力也并不是一蹴而就的。我以前玩过音乐、也是一名摄影师、拍过微电影，每天都在维持高强度的阅片量。

AI生成视频虽然是虚拟的，但在影像创作的原理上，它和传统实拍终归是有所相通的。构图的张力、镜头的推拉摇移、故事的视觉叙事以及后期的剪辑卡点，这些都需要长期的审美沉淀，不是随便在键盘上敲几个字就能出来的。遇到不懂的专业概念，我也得去网络上看各位老师分享的干货教程，一切都有迹可循。

Heath：这也是Yoroll想要向行业证明的逻辑，现在对创作者来说是一个很好的时代。我们团队的核心愿景，就是通过生成式AI和Agent工具链，“让人人都可以成为小岛秀夫和李安，做出好玩又好看的互动内容”。

其实，游戏工业发展史上许多伟大的创意，本来就诞生于普通玩家和爱好者。比如风靡全球的DOTA，最早也不过是普通玩家在《星际争霸》和《魔兽争霸3》里手搓出来的地图，后来才由冰蛙发扬光大。当技术不再成为束缚想象力的枷锁，学历和过往经验都会退居幕后，好奇心、执行力与纯粹的创意，才是未来内容创作真正的通票。

游戏那点事：现在这么多资源找过来，你有计划离开云南，去一线城市或者海外发展吗？

Mx-Shell：我只想留在云南家乡，从来没想过去别的地方。在自己觉得舒适的地方创作就挺好的，大家喜欢我的作品，也不用非把我放到什么特定的地方去。

我只是一个普通的AIGC爱好者，外界给予我的期待，确实让我感受到了一部分压力，这迫使我必须对往后的创作更加认真负责。我希望能先静下心来，用下一部作品让大家重新检验我的实力。

工业容得下赌徒

游戏那点事：《丧尸清道夫》的实际制作成本和周期是多少？在Yoroll的管线里，这种低成本模式是如何运转的？

Mx-Shell：综合不同平台的会员和积分，我这部片子的算力成本折算下来在3000元左右。工期方面，之前报道说是10天，但严格来说，我做第一个镜头是5月1日凌晨，初版成片5月8日下午就发布了，实际的极限工期只有一个星期左右。

Heath：这个数据是非常颠覆的。在传统管线中，要实现高品质的3D游戏，需要庞大的美术团队和产研团队，角色建模、贴图、骨骼动作绑定、动捕、3D场景搭建、动画演绎、光效渲染等，极其费人费钱，动辄需要几百万的成本和两三年的开发周期。

但现在，采用原生的AI视频生成方式后，创作者只需要输入提示词和参考图，整个庞大的3D管线就被直接砍掉了。在Yoroll平台上，我们将游戏的开发周期直接压缩到了两三个月，而核心开销只剩下人力成本，以及Token生成费用。一款2小时体量的互动游戏，研发门槛可以直接压缩至10万元量级。

游戏那点事：AI生成的不可控性会对创作带来影响吗？Yoroll的工具链如何包容并收束这种发散性创作？

Mx-Shell：我恰恰觉得AI的不可控会给我带来惊喜。我常有一种赌徒心态，比如飞船离开地球的镜头，其实一次就抽中了理想画面，但我依然会多跑几次，去赌会不会有更惊艳的结果。

在创作思路上，我一开始并没有完整的剧本，整个状态是“做一点、想一点、写一点、改一点”。这反而放宽了限制，有时候就算AI没完全按提示词走，只要画面感觉好，我就直接采用，甚至会顺着它去修改后续的剧情走向。

Heath：针对Mx-Shell这样依赖视听直觉、高度发散的创作者，Yoroll提供了多种不同梯度的模式来包容。

对于想要放飞创意的创作者，平台有“端到端”模式：只需要输入几句想法，AI就能全自动帮他改写成分支故事线并匹配玩法，一键打包。

对于想要精细打磨的专业创作者，我们也提供“Copilot”模式，支持在每一个环节通过提示词进行反复精修。我们的逻辑不是去限制创作者的直觉，而是提供诸如剧本改多分支故事线、3D参考空间等专业细分工具，用高工业化程度的底层系统帮他们把天马行空的创意稳稳落地。

游戏那点事：具体到《丧尸清道夫》的游戏化落地，原作最核心的精髓是什么？将强玩法融入视频，技术门槛在哪？

Mx-Shell：我最想保留的是机器人的“独特性”。它有自主意识，性格上也有反差——它看似是个机器，实则像活生生的人；它可能不怕丧尸，反而会害怕其他奇怪的东西。我认为这种性格反差是原片的精髓。

Heath：我们非常认同这一点。我们内部曾主导过《对马岛之魂》、《行尸走肉》剧情开发的北美资深游戏剧情策划也深度参与了这个项目，我们希望将原片中那种放荡不羁、类似《死侍》的松弛感贯穿全篇。

玩法上，我们会加入分支选项、探索解谜，以及射击打丧尸、骑鸵鸟奔跑的QTE等玩法组件。技术上最大的难点，在于“叠加在视频上的玩法”，如何把视频生成与游戏底层逻辑顺滑地融合。

游戏那点事：这种复杂的玩法联动，不懂代码的创作者，真的能在平台上独立跑通吗？

Heath：在平台预设的玩法组件范围内，是可以的。在代码层面，我们屏蔽了极度复杂的底层参数。创作者不需要写一行代码，只需在后台修改填入简单的数值逻辑，比如“3秒内命中5次”，再替换对应的UI贴图即可完成，门槛非常低。

本质上，我们会将专业游戏策划在剧情构建、数值系统以及商业化付费点设计上的经验进行“蒸馏”，转化为标准化的技能包（Skills）内置到平台上。普通创作者在凭直觉创作时，背后其实是由这套专业的工业化AI管线在兜底支撑。

游戏那点事：《丧尸清道夫》的游戏化目前推进到什么阶段了？大概什么时候能让大家真正玩到这款作品？

Mx-Shell：进度方面已经完成了初期的立项和试玩版开发。包括游戏剧本和玩法设定都已经梳理好了，我们一起配合协作，确认最终效果。

Heath：在发行规划上，我们为它制作一个多端的版本，除了上架Yoroll的官方消费端平台，也会在Steam、手机端甚至小程序上发布。目前时间点的规划是在今年的Q3，就可以正式上线让大家玩到了。

得益于平台上预置的各种AI组件和功能，我们将传统游戏动辄需要两三年的开发周期，直接压缩到了两三个月就能够完成。很期待成品与大家的正式见面。

最珍贵的溢价

游戏那点事：《丧尸清道夫》中有大量黑色幽默和戏谑感的表达，目前AI真的能理解人类这种微妙的情感吗？

Heath：客观来说，目前的AI在生成文本创意时仍有局限性，大概能达到70分的水平。特别是对于玩梗、致敬桥段的理解，AI往往会写出比较生硬的“冷笑话”。

另外，目前AI生成长剧本主要存在几个明显问题：一是剧情容易枯燥，缺乏人类编剧的铺垫和强反转设计；二是长文本容易出现“记忆丢失”，导致前后文设定出现偏差。

针对这些问题，我们会通过RAG等技术手段，结合资深编剧的人工精调，来注入“灵魂”，确保最终内容足够有趣。

游戏那点事：Yoroll的Roll-01世界模型是用来解决什么问题的？

Heath：Roll-01是我们一款专用于游戏和互动娱乐方向的世界模型。我们会针对特定的游戏品类进行后训练，以优化视觉效果和交互的实时性。

它本质上是一个实时生成的“视频流模型”，是将空间信息内化在了视频流里，而不是传统的3D场景模型。未来的形态会是“预生成的视频”来提供核心叙事和故事代入，遇到自由探索环节，则交给实时生成的模型来动态呈现。

游戏那点事：这种低成本、高产能的生产模式，短期内会对传统的3A游戏工业造成冲击吗？Yoroll面对大模型底层厂商，核心的护城河在哪里？

Heath：赛道不同，短期内不会冲击传统的3A大作，因为3A在画质一致性、操作手感、底层玩法系统上非常成熟。生成式AI率先冲击和取代的，会是中小团队制作的叙事类游戏、互动影游、互动短剧以及传统的休闲/超休闲品类游戏。

至于护城河，大模型公司追求的是基模的通用性，多维度服务短视频、影视、广告和游戏，我们与他们更多是合作关系。Yoroll的护城河在于很多模型公司不会做的重度游戏组件，包括复杂分支剧本、庞大数值系统、专业编辑器以及消费端的分发和变现系统。

从内容生产端到消费端形成闭环，让海量用户游玩数据反哺模型优化的这种数据飞轮，才是我们的核心竞争力。

游戏那点事：从产品形态来看，你们期望Yoroll最终成长为一个怎样的分发平台？

Heath：我们希望将其打造为一个全新的“可玩视频”（Playable Video）平台。它和当今市场上常见的Steam、Roblox、短视频或流媒体平台的运转逻辑都不太一样。

在产品形态上，既有适合大众的“分类榜单系统”，又有适合分发长尾UGC内容的“Feed流推荐系统”。未来是UGC生态，如何让海量的长尾内容被精准推送到对应的玩家手里，推荐系统是关键。

游戏那点事：习惯了高爽感短视频内容的用户，愿意耐心去买断或花时间玩这类AI游戏吗？现阶段怎么打破核心玩家对AI生成的抵触心理？

Heath：我们核心关注的是将观众从“旁观者”转变为“参与者”。长短内容的消费并不矛盾，平台上既会提供偏短剧化、节奏快的高爽感内容，也会容纳需要沉浸代入的长线互动影游。

关于核心玩家的抵触心理，其实玩家发自内心抵触的从来不是AI技术，而是廉价、敷衍、缺乏尊重的内容。比如花高价买游戏却体验到质量粗糙的AI资产。就像大家看到《丧尸清道夫》，基本都是惊叹于它的故事和视觉展现。只要AI能协助做出好内容，并制定合理的定价，根据我们的访谈调研，玩家是愿意买单的。

此外，未来盈利模式也将走向分层：长叙事的高品质作品依然适合买断制、章节DLC和内购；而几分钟一局的互动小剧或陪伴轻游戏，广告变现、会员或流量分成将是更优解。

游戏那点事：随着创作门槛的降低，平台是否设有质检标准，来防止低质AI内容的泛滥？

Heath：除了常规的涉黄涉暴等安全红线外，我们不会在质量上设置主观判断的限制，因为大众的审美是千人千面的。

我们将评判权完全交给用户，依靠软性的推荐算法去调控。大众越认可的作品曝光越大，不被喜欢的自然拿不到推荐流量池，让市场自己去完成优胜劣汰。

游戏那点事：假如未来大家都能用AI快速做出游戏时，什么才是拉开作品差距的核心竞争力？两位对目前的独立创作者有什么建议？

Heath：产能过剩的时代，拉开差距的核心来源于更好的创意、审美和世界观。具体落地到游戏中就是独有的Art（美术风格）、能引发共鸣的Story（好故事）以及极具趣味性的Gameplay（玩法设计）。AI只会降低生产的门槛，却会把好内容的竞争门槛拔得更高。

这可能是过去十年里，独立创作者最值得兴奋的时刻。AI显著降低了资金和技术壁垒，不再需要懂代码和拥有庞大团队，只要有表达欲和判断力就有机会脱颖而出。

我想给创作者的生存建议是：初期可以选择被验证的大众题材，但随着竞争加剧，可以考虑去服务那些被巨头忽视的长尾、小众爱好，不仅容易收获粉丝用户，也很容易在细分生态里赚到钱。

Mx-Shell：说到底，打铁还需自身硬。如果真想一战成名，自身的实力积累肯定是必要前提。能有今天的反响，或者说“被老天爷选中”，运气占了很大比重，但也不能把这当成常态。

在创作者和AI之间，真正的造梦者永远是执行的那个人。AI在我眼里是伙伴，但在本质上依然是帮助人类完成繁琐工作的工具。同样的工具在不同人手里会发挥截然不同的效果，工具本身不重要，它握在谁的手里才重要。

作者：西泽步

来源：手游那点事

最近，我在给甲方做demo的时候，用了seedance2.0的模型，在所有的节点都搭建完成的时候，我看了一下最后的生成的积分消耗，折合人民币39元……

老实讲，我一顿晚饭可能都没这么多，但是不用又没办法，seedance2.0的效果确实很好，尤其是图生视频，配合image2直接屌炸了。

但是，我很好奇，我们一直在使用这些模型，却从来没有想过他们背后的计算规则，虽然都知道是消耗Token，但是却很疑惑为什么视频生成普遍那么贵？以及厂家的商业逻辑，为什么不同模型厂商的定价还不一样，有的厂商几乎就是白嫖，而有的却贵的离谱还有人想要用。

所以今天这篇文章主要来解释token的消耗以及帮大家看懂MaaS（Model as a service）的商业模式

要理解Token消耗，你必须先理解Token本身。这不是一个可以跳过的前置步骤——Token是整个AI计费体系的基石，不理解Token，后面所有的计费规则、成本逻辑、优化策略都会像空中楼阁一样站不住脚。

大语言模型（如GPT-4、GLM-4）并不直接理解文字——它们只理解数字。你输入一段中文，模型需要先把这段中文”翻译”成一串数字，处理完之后，再把数字”翻译”回中文返回给你。这个翻译过程中的最小单位，就是Token。

打个比方：你跟一个只会英语的翻译官说话，你说”你好”，他需要先在脑子里把”你好”翻译成”Hello”，理解你的意思后，再用英语回答，最后把回答翻译回中文告诉你。在这个过程里，翻译官不是逐字翻译的，而是按照他自己理解的”意义单元”来切分——有时候一个字就是一个单元，有时候两个字的词是一个单元。Token就是模型眼中的”意义单元”。

更准确地说，Token是模型词表（Vocabulary）中的一个条目，是大模型自己的语言，当你和他沟通的时候，它需要理解你并且对你进行不同程度的输出，这一部分就会消耗模型能量，而Token就是供给。

那”1000个Token大概等于多少字？”其实不是一个固定数字，而是一个范围，因为不同语言、不同内容的Token化效率不同。一个实用的估算方法：对于中文文本，你可以用”1个汉字 约= 1.3个Token”来粗略估算。也就是说，一段1000字的中文文章，大约消耗1300个Token。但这个估算只适用于”正常文本”——如果你的文本包含大量代码、公式、特殊符号，Token数会显著增加。

讲完token的基本概念之后，我们需要理解三个不同类型的模型消耗规则，这一部分我主要参考了火山引擎的大模型价格的文档，链接为：https://www.volcengine.com/docs/82379/1544106?lang=zh。

由于火山官方的模型有很多，但这里我只例举最常用的几种，从实际使用的场景来看我把它们分为：文生文模型、文生图模型和文生视频模型这三种。

文生文模型（如GPT-4、GLM-4、Claude）的计费核心是”分别计算输入和输出的Token数量，然后乘以各自的单价”，公式也相对简单：

总成本 = (输入Token数 × 输入单价) + (输出Token数 × 输出单价)

总成本 = 视频时长(秒) × 每秒单价

每秒单价 = 分辨率系数 × 帧率系数 × 模型溢价

其中输入部分包括三部分内容：

1. 系统提示词（SystemPrompt）：你给模型设定的角色和行为规则，如”你是一个专业的法律顾问”。通常100-2000Token。
2. 历史对话（Conversation History）：之前所有的对话内容，包括用户提问和模型回复。随着对话轮次增加，这部分Token会不断累积。值得注意是，历史对话会不断叠加和累积，好处是它会记住你的信息，每一次的回答会更精准，当然代价也很明显，就是上下文窗口的带来的巨大增加而导致的Token消耗也会变多。
3. 当前用户输入（User Message）：用户本次发送的内容。

输出Token（Output Tokens）只有一部分：

模型生成的回复：模型针对用户输入生成的全部文本内容。

但是通常来说，输出的定价一般都会高于输入的定价，原因在于推理过程的计算量差异。大模型的推理过程分为两个阶段：

1. Prefill阶段（预填充）：处理输入Token。这个阶段可以并行计算——模型同时”阅读”所有输入Token，计算速度很快。你可以把它想象成”一口气读完一篇文章”，虽然文章很长，但你可以快速扫完。
2. Decode阶段（解码）：生成输出Token。这个阶段必须串行计算——模型每次只能生成一个Token，每生成一个Token都需要参考之前所有的Token（包括输入和已生成的输出）。你可以把它想象成”逐字写文章”，每写一个字都要回头看看前面写了什么。

因为Decode阶段是串行的，每生成一个Token的计算量远大于Prefill阶段处理一个Token的计算量。具体来说，生成一个输出Token的GPU计算时间，大约是处理一个输入Token的5-10倍。这就是为什么输出Token的单价是输入Token的2-5倍。

我认为这个问题可以简单的去理解，好比如你阅读一本书，和你自己去写书一样，前者对于大脑算力的消耗会更小一些，而后者要涉及到创作和灵感，也更费脑，你可以一目十行，也可以一天读完一本书，但是你不能在短期内创造出一个好的作品。

文生图模型：

文生图模型（如image2、seedream）的计费方式与文生文模型完全不同——它不是按Token计费，而是按”张”计费。你输入一段文字描述，模型生成一张图片，你付一张图片的钱。

为什么文生图不按Token计费？因为文生图的成本主要不在”理解文字”上，而在”生成图片”上。理解你的Prompt可能只需要几百个Token，但生成一张1024×1024的图片，需要模型在像素级别进行数百万次的计算。所以，文生图的计费单位是”张”而不是”Token”——文字输入的Token消耗相对于图片生成的计算成本可以忽略不计。

不过，文生图的”按张计费”并不是一个固定价格——它受到多个因素的影响，其中最重要的是分辨率和推理步数。

分辨率是影响文生图价格的最主要因素。分辨率越高，图片的像素越多，模型需要计算的数据量就越大。1024×1024的图片有约100万像素，2048×2048的图片有约400万像素——像素量翻了4倍，计算量也近似翻了4倍，所以价格也相应增加。

这一步和后面讲到的视频模型相同，因为推理步数（Inference Steps）是另一个影响价格的因素，但在主流API中通常不直接暴露给用户。推理步数是指扩散模型（Diffusion Model）从纯噪声逐步去噪到最终图片的迭代次数。步数越多，图片质量越高、细节越丰富，但计算时间也越长。大多数API默认使用30-50步，如果你需要更高质量（如80-100步），可能需要支付额外费用。

还有一个容易被忽略的因素：图片数量。很多平台默认一次生成多张图片（如4张），让你选最好的一张。这意味着你实际支付的是4张图片的价格，而不是1张。Midjourney就是这种模式——一次生成4张，如果你只要1张，也需要付4张的钱。印象中Nano banana也是默认一次性出四张图的，很多国产模型也是优先出两张，这个需要特殊情况来定，主要还是使用的习惯不同。

视频生成模型：

按 token 单价 × token 用量=按 token 单价 × (输入视频时长+输出视频时长) × 输出视频的宽 × 输出视频的高 × 输出视频的帧率/1024

文生视频是当前所有AI生成模式中成本最高的——一段5秒的1080p视频，价格可能相当于生成50-100张同分辨率的图片。

主要也是因为计算量的指数级增长。一张1024×1024的图片有约100万像素需要计算；一段5秒24fps的1080p视频有120帧，每帧约200万像素，总共需要计算2.4亿像素——是单张图片的240倍。而且视频还需要保证帧与帧之间的时序一致性（不能前一秒是白天下一秒变黑夜），这增加了额外的计算复杂度。

更具体地说，视频生成的计算成本来自三个维度：

1. 空间维度：每帧图片的像素量，由分辨率决定。4K视频每帧的像素量是720p的9倍。
2. 时间维度：视频的总帧数，由时长和帧率决定。10秒30fps的视频有300帧，5秒24fps的视频有120帧。
3. 一致性维度：保证帧间连贯的额外计算。这是视频生成独有的成本，图片生成不需要。

不过也有一些别的部分会影响到整体视频生成的token消耗：比如是否输入包含图片和视频，包含的话就会很耗时更高，同样token消耗也更高，这也侧面说明了文生视频的成本远低于图生视频，因为前者这一块的文本token几乎可以忽略不计。

这里我有一个建议：就是现在很多模型推出了fast版本，为了弥补视频生成时间慢、token消耗大的问题而解决的，1因此大家在用视频的时候，尤其是在前期可以优先去使用一些fast 模型，同时降低画质的帧率，在给到的提示词、图片和人物参考不变的情况下，看看最终出来出来的效果如何，在空间上、一致性上是否存在较大的误差，如果在此基础上没有太大问题，可以重新给出一个branch，然后生成优质高清的视频，如果有问题，那就要回溯，查询每一个步骤的图片和提示词。这样整体的成本可以极大降低，反而提高了生产效率。

大模型的成本主要由五部分组成：

1. PU算力成本（约55%）：这是最大的成本项。训练一个大模型需要数千张GPU运行数月，推理服务需要持续运行GPU集群。一张NVIDIA H100 GPU的价格约20-30万元，一个千卡集群的硬件投入就超过2亿元。加上训练成本（GPT-4级别的模型训练一次约1亿美元），算力成本是压在每家厂商头上的大山。
2. 电力和散热成本（约15%）：GPU是电老虎——一张H100的功耗约700瓦，一个千卡集群的功耗约700千瓦，相当于一个小型工厂的用电量。数据中心的电费和散热费用是持续支出，且随规模线性增长。
3. 研发人力成本（约15%）：顶尖AI研究员的年薪在百万美元级别，一个核心团队（50-100人）的年人力成本就超过5000万美元。而且人才极度稀缺，各家厂商在抢人上的投入不亚于抢GPU。
4. 数据成本（约10%）：高质量训练数据的采集、清洗、标注成本不菲。尤其是专业领域数据（法律、医疗、金融），获取成本更高。
5. 利润（约5%）：当前大多数厂商的API利润率并不高，部分厂商甚至亏本运营——用低价换规模，期待规模效应降低成本后盈利。

从图中可以看到，不同厂商的价格差异巨大——DeepSeek的输入价格只有GPT-41/18。

这种价格差异是怎么产生的？

因素一：推理优化技术的差异。这是价格差异最大的来源。推理优化包括量化（降低模型精度以减少计算量）、蒸馏（用大模型训练小模型以降低推理成本）、投机解码（用小模型预测大模型的输出以加速推理）等技术。DeepSeek之所以价格极低，核心原因就是它在推理优化上做到了极致——通过MoE（混合专家）架构和多头潜在注意力机制，把推理成本降到了同级别模型的1/10以下。

因素二：算力成本的差异。海外厂商（OpenAI、Anthropic）主要使用NVIDIA GPU，价格高且供应受限；国内厂商部分使用国产GPU（如华为昇腾），成本更低。此外，中国的电价和人力成本也低于美国，进一步降低了运营成本。

因素三：定价策略的差异。这是”非成本”因素，但对价格影响巨大。OpenAI和Anthropic采取”高价值定价”——它们认为自己的模型质量最好，应该收更高的价格，用高利润支持持续研发。DeepSeek采取”渗透定价”——用极低价格快速获取用户和市场份额，建立生态壁垒。国产模型（通义千问、GLM-4）介于两者之间——质量接近海外模型，但价格更低，以性价比竞争。

但是每家厂商都面临这个两难选择：降价可以获取更多用户和消耗量，但会压缩利润空间；维持高价可以保持利润，但可能流失价格敏感的用户。当前的市场格局是：头部厂商（OpenAI、Anthropic）选择维持高价，因为它们有质量优势和品牌溢价；追赶者（DeepSeek、通义千问）选择低价，因为它们需要用价格换市场。如果所有模型的能力趋同（即用户觉得用哪个模型都差不多），那么价格就会成为唯一的竞争维度，最终走向价格战。这就是为什么各家厂商拼命在模型能力上做差异化——OpenAI强调推理能力和多模态，Anthropic强调长文本和安全对齐，DeepSeek强

调性价比和代码能力。差异化是避免价格战的唯一武器。字节的see dance2.0由于在模型能力上的提升，导致其他厂商无法与其抗衡，进而形成垄断的局面，对于c段用户，他们会不断的购买会员和算力充值，相反企业会选择接入火山引擎的借口，但是门槛会更高。相比于其他模型厂商求着别人使用他们的模型，字节在AI视频领域似乎没什么压力。这里也作为补充，云厂商的模型销售（Maas）不同于传统的SaaS的销售逻辑逻辑，大模型是一个前期投入成本极高但是边际成本极低的行业，这也就意味着厂家需要在一开始投入大量的算力和人力在研发上，但是一旦商业模式跑通或者实现盈利，那么整个的研发和和基础设施投资都会被摊薄。在火山内部，token的消耗量也是作为业务发展的核心指标，类似于传统电商的GMV。

最后就是，开源模型的存在，给闭源模型的定价设定了一个”天花板”——如果闭源模型的价格远高于自部署开源模型的成本，用户就会选择自部署。所以闭源模型的定价必须考虑开源模型的竞争压力。这也是为什么DeepSeek敢于定这么低的价格——它知道自己的开源版本已经设定了价格上限，不如主动把API价格降到接近开源自部署的成本，把用户留在自己的生态里。

动手 LLM Wiki 前，建议你先想明白这些结尾，我提了五个问题：规模天花板、超长文档、成本、冷启动、Lint 幻觉。然后说了 qmd 能解。但 qmd 只是一个搜索引擎——怎么把它接进 LLM Wiki 的工作流里，怎么设计 CLAUDE.md 让 LLM 真正按规矩干活，怎么让 200 页的论文不崩不丢不断，这些才是整套系统真正要解决的部分

时隔两周，我终于把这套方案盘清楚了，今天就来填这个坑

为什么用 qmd

如果只是做一个简单知识库，其实有很多方案。你可以直接用 Obsidian 搜索，可以用 ripgrep，可以用向量数据库，也可以搭一套 RAG。但我这个场景有几个很具体的要求

第一，知识主要以 Markdown 文件存在。原始文章、整理后的 wiki 页面、概念页、实体页、综合页，全部都在本地文件系统里。qmd 对这种文件系统式知识库很顺手，不需要一上来就搭数据库、服务端、API、权限系统。文件放进去，索引建起来，就能搜

第二，我需要混合检索。只用向量检索会遇到一个问题：语义大概能找，但精确词经常不稳。比如CLAUDE.md、raw_sha256、BM25、search-chunks、某个论文标题、某个命令名，这些东西用精确匹配更可靠。qmd 支持 BM25 和向量检索，再加上重排序，刚好适合技术文章、论文、笔记、代码说明这类材料

第三，我需要让 LLM 可以稳定调用。Claude Code 这类工具很适合操作本地文件，但前提是命令要简单、语义要清楚。如果把一堆底层检索参数直接暴露给 LLM，它很容易乱用。qmd 的能力可以被封装成几个稳定命令，比如wiki search、wiki get、wiki find-related、wiki search-chunks，这样 LLM 不用理解所有底层细节，也能稳定完成任务

第四，我需要处理超长文档。很多文章不是三五千字，而是几十页甚至两百页。如果每次都让 LLM 读全文，成本高、上下文容易爆、还会丢细节。qmd 的块级检索可以让 LLM 按主题去找原文中的相关段落，一次只读几个块。这样长文档也能拆开处理

第五，我想要本地、轻量、可迁移。整个知识库就是文件夹，Git 可以管版本，Obsidian 可以看图谱，qmd 管检索，LLM 管编译。没有很重的工程依赖，也不会把系统绑死在某个云服务上

所以 qmd 在这套方案里的定位很清楚：它是本地知识库的检索底座。它不负责替你理解知识，也不负责替你设计知识结构。它只负责一件事：当知识库变大之后，帮 LLM 找到该看的东西

整体架构：四层就够了

整个系统可以拆成四层

1. 用户层决定读什么、问什么、哪些内容值得沉淀
2. LLM 层执行 ingest、query、lint，按照 CLAUDE.md 的规矩维护
3. wikiCLI 层用 bin/wiki 封装 qmd，提供稳定命令文件
4. 系统层保存 raw 原始文档、wiki 页面、shared 跨域页面、qmd 索引

这里最关键的是 CLI 层。LLM 不直接操作 qmd 原始命令，所有动作都走bin/wiki。原因很简单：qmd 的能力比较底层，参数组合也多，直接让 LLM 调用容易出错。封装之后，LLM 只需要理解几个语义化动作

比如日常查询用：

wiki search “self-attention”

ingest 前找相关页面用：

wiki find-related “Transformer 架构”

长文档按块搜索用：

wiki search-chunks “positional encoding”

读取文档用：

wiki get “wiki/concepts/self-attention.md”

这样一来，LLM 操作知识库时就像在使用一组稳定 API，而不是每次临时拼复杂命令。系统越大，这层封装越重要

目录怎么设计

我把目录分成三块：bin/、shared/、instances/

bin/里放统一的 wiki CLI。shared/放跨域共享的页面，比如实体、跨域概念、桥接页面。instances/下面放不同知识域，每个域有自己的 raw、wiki 和 CLAUDE.md

大概结构是这样：

qmd_llm_wiki/

├── bin/

│ └── wiki

├── shared/

│ ├── entities/

│ ├── concepts/

│ └── bridges/

└── instances/

├── formal/

├── natural/

├── technical/

├── mental/

├── social/

└── philosophy/

每个实例里面的结构基本一致：

technical/

├── raw/

│ ├── articles/

│ ├── papers/

│ └── assets/

├── wiki/

│ ├── sources/

│ ├── entities/

│ ├── concepts/

│ ├── synthesis/

│ ├── _wip/

│ └── log.md

└── CLAUDE.md

raw/放原始文档，原则是只读不改。wiki/放 LLM 维护后的页面。sources/是来源摘要，concepts/是概念页，entities/是人物、组织、产品这类实体页，synthesis/是综合分析，_wip/用来保存超长文档 ingest 进度，log.md记录知识库操作历史

这个结构的好处是清楚。原始资料和整理结果分开，单篇文章和跨文章概念分开，当前域和共享层分开。后面做检索、lint、维护都会轻很多

qmd 初始化时要做什么

qmd 的核心概念是 Collection，可以理解成一组被索引的文件。我们要做的第一步，就是把不同目录注册成不同 Collection

不要把整个 wiki 文件夹粗暴注册成一个集合。因为 source 页面、concept 页面、entity 页面、raw 原文的用途完全不同。查询时，你可能只想搜整理后的 wiki；ingest 时，你可能想找相关 concept；查证据时，你可能只想搜 raw；长文档处理时，你还需要搜 raw 的块级索引

所以更好的做法是按用途注册，比如：

technical-sources → technical/wiki/sources/*.md

technical-concepts → technical/wiki/concepts/*.md

technical-entities → technical/wiki/entities/*.md

technical-synthesis → technical/wiki/synthesis/*.md

technical-raw → technical/raw/**/*.md

shared-entities → shared/entities/*.md

shared-concepts → shared/concepts/*.md

shared-bridges → shared/bridges/*.md

这样后面命令就可以非常清楚。wiki search默认搜当前域的 wiki 页面，wiki search –raw搜原始文档，wiki search-cross搜所有域和 shared 层，wiki search-chunks专门搜 raw 里的文档块

初始化时还要给每个 Collection 加 context description，也就是告诉 qmd 和重排序模型：这个集合里装的是什么。比如 source 页面是一篇文档的摘要，concept 页面是概念解释，raw 是不可修改的原始资料。这个信息会影响检索质量，因为系统不仅要知道“哪些文本相似”，还要知道“用户这个问题更应该去什么类型的页面里找”

初始化完成后，执行 reindex，让 qmd 建索引和向量嵌入。后面每次新增或修改文件，都需要按需重新索引，否则检索结果可能滞后

wiki CLI 要封装哪些命令

CLI 不需要做得很复杂，核心命令够用就行。我的思路是把命令分成六类

第一类是初始化和维护：wiki init、wiki reindex、wiki status、wiki collections。新建知识库时先 init，再 reindex，然后用 status 看状态。新会话开始时也建议先跑 status，让 LLM 了解当前库的规模和最近变化

第二类是检索：wiki search、wiki search-cross、wiki search-lex、wiki search-vec。日常大多数问题用wiki search就够了。跨域问题用wiki search-cross。遇到专有名词、命令名、文件名，用wiki search-lex。遇到模糊问题，用wiki search-vec

第三类是 ingest 专用检索：wiki find-related。这个命令的参数应该比普通 search 更宽松，比如返回更多结果、阈值更低。因为 ingest 时宁可多看几条候选页面，也不要漏掉一个应该更新的旧概念

第四类是超长文档：wiki search-chunks、wiki wip-list、wiki wip-done。长文档不能全文读，要按主题搜块。WIP 文件负责记录处理进度

第五类是文档取回：wiki get、wiki bulk。wiki get用来读取单个页面或 docid，wiki bulk用来批量读取某一类页面，比如 lint 时批量检查 sources 或 concepts

第六类是日志和版本：wiki log、wiki log-recent、wiki save。每次 ingest、修复、综合分析，都应该写日志。知识库是长期资产，必须能回头看自己做过什么

这套 CLI 的设计原则是：命令数量不要太多，每个命令的语义要稳定，LLM 能看懂，用户也能看懂

CLAUDE.md 才是系统的操作手册

qmd 解决检索，CLI 解决调用，CLAUDE.md 解决行为规范。它告诉 LLM：你是谁，你能做什么，不能做什么，遇到不同任务怎么走流程，页面应该怎么写，什么时候需要问用户

每个域都应该有自己的 CLAUDE.md。里面至少包含几块内容

第一，角色定义。你要告诉 LLM，它是这个知识库的维护者，用户负责决定读什么、问什么，LLM 负责摘要、交叉引用、归档和维护。这里一定要写两条红线：不要修改 raw 下的原始文档，不要改写 log.md 的历史记录。raw 是事实来源，log 是审计记录，这两个地方不能乱动

第二，知识库定位。这个部分很重要。比如技术域就要写清楚：它关注人工系统的构造方法，以有效性为评价标准。算法的具体实现归技术域，算法的可计算性证明归形式域，技术的社会影响归社会域或哲学人文域。边界越清楚，LLM 越不容易乱放内容

第三，新会话启动流程。LLM 每次开始工作时应该先运行wiki status、wiki log-recent、wiki wip-list。这样它知道当前知识库状态、最近做过什么、有没有没完成的长文档任务。否则每个新会话都像失忆重来

第四，Ingest 流程。标准流程可以设计成：先读取 raw 文档，再用wiki find-related找已有相关页面，然后和用户确认重点，再写 source、concept、entity、synthesis，写完立刻wiki get验证，最后wiki log和wiki save。这个流程写进 CLAUDE.md 后，LLM 就不会每次自由发挥

第五，Query 流程。用户提问时，先 search，再根据结果 get 关键页面，需要原始证据时搜 raw，需要跨域时 search-cross，回答时标注依据和不确定性。这样回答会更稳

第六，页面格式。source 页面怎么写，concept 页面需要哪些字段，entity 页面怎么维护，synthesis 是否要写反面证据，wikilink 怎么命名，这些都要写清楚。LLM 最怕抽象要求，最好给具体模板

CLAUDE.md 的维护方式也很简单：一开始不用追求完美，先写一版能跑的。ingest 第一篇文章后，看哪里不满意，就把规则补进去。不要一次改很多条，一次改一条，改完用下一篇文章测试

Ingest 一篇普通文章怎么跑

普通文章，也就是几页到几十页以内，可以按这个流程走

第一步，把文章转成 Markdown，放进raw/articles/。raw 里的文件尽量保持原样，不要让 LLM 改它

第二步，让 LLM 读取原文：

wiki get “raw/articles/xxx.md”

如果文章比较长，可以先读 snippet

第三步，让 LLM 提炼文章主题，然后找已有相关页面：

wiki find-related “文章核心主题”

这一步很关键。没有这一步，LLM 很容易每篇文章都新建一堆页面，最后知识库变成碎片堆。先找相关页面，才能判断哪些概念要更新，哪些实体已经存在，哪些内容需要合并

第四步，让 LLM 先给你一个 ingest 计划。它应该说清楚：这篇文章会生成哪个 source 页面，可能更新哪些 concept，是否需要 entity，是否值得写 synthesis，有哪些地方需要你判断重点。你确认方向后，再让它写

第五步，写入 wiki 页面。source 页面保存这篇文章的摘要、关键论点、证据、提取出的概念和实体。concept 页面保存跨来源积累的概念理解。entity 页面保存人物、组织、产品等实体信息。synthesis 页面保存多篇文章之间的综合判断

第六步，写完就验证。让 LLM 用wiki get把刚写的页面读回来，检查 frontmatter、wikilink、内容完整性。如果有问题，当场修

第七步，记录日志并保存版本：

wiki log ingest “文章标题”wiki save “ingest: 文章标题”

这套流程一开始看起来比“直接问 LLM 总结文章”麻烦，但差别在于：总结是一次性输出，ingest 是把文章变成知识库的一部分。后面你再问相关问题，这篇文章会和其他页面一起参与检索和推理

200 页论文怎么处理

长文档是这套系统最值得设计的地方。一个简单原则：超过一定长度的文档，不要全文塞给 LLM

处理长文档应该分三步

第一步，先做准备。让 LLM 读取文档摘要、目录或者前几段，判断这篇文档应该拆成哪些主题。比如一篇 Transformer 论文，可能拆成 self-attention、multi-head attention、positional encoding、encoder-decoder、training strategy、evaluation、和 RNN 的对比

然后创建一个 WIP 文件，放在wiki/_wip/里。这个文件记录文档路径、主题列表、已完成主题、待处理主题、已创建页面、已更新页面。它的作用很简单：防止跨会话断掉之后不知道做到哪里

第二步，按主题处理。每次只处理一个主题，用：

wiki search-chunks “self-attention” -n 5

qmd 会在 raw 文档的块级索引里找最相关的几个片段。LLM 读这些片段后，更新对应 wiki 页面。处理完一个主题，马上更新 WIP，把这个主题从 pending 移到 completed。不要等所有主题都读完再写，因为长文档 ingest 很容易中途被上下文、网络、会话长度打断。每处理完一个主题就落盘，系统就可恢复

第三步，全部主题处理完后，再做汇总。让 LLM 搜一下这些主题之间的关系，必要时写 synthesis 页面。最后用wiki wip-done标记任务完成，再写日志

这套流程解决的核心问题是稳定性。长文档最怕三件事：上下文爆、处理中断、读了前面忘了后面。分块检索加 WIP 续传，可以把一个大任务拆成多个小任务，每个小任务都能独立完成、验证、保存

Lint 怎么做

Lint 的目标不是让 LLM 判断内容真伪。内容真伪需要来源、证据和人的判断。Lint 主要抓结构问题

比如：

• YAML frontmatter 缺字段
• wikilink 指向不存在的页面
• 页面正文太短，像没写完
• 两个 concept 页面太相似，可能重复
• raw 文件被意外修改
• 页面太久没复查
• 命名格式不统一

这些问题应该用程序检查，不要让 LLM 自己凭感觉看。wiki lint可以自动跑一遍结构检查，生成报告。报告出来后，LLM 可以协助修复，但是否合并、是否重命名、是否删除重复页面，最好由用户确认

这里最重要的一项是 raw 完整性。source 页面里可以记录原始文件的 SHA-256。如果 raw 文件后来被改了，lint 就能发现。因为 raw 是整套系统的事实底座，一旦被污染，后面的 wiki 页面都不可靠

六域分类只是我的方案

我这套系统用了六域分类：形式域、自然域、技术域、心智域、社会域、哲学人文域。这个分类的核心想法是按“命题”分，不按“学科”分

比如一篇讲 AlphaFold 的文章，按学科分会很纠结：它到底算 AI、计算机、生物学、化学，还是科学哲学？按命题分会清楚一些。模型架构和工程实现属于技术域，蛋白质折叠机制属于自然域，科学发现方式的变化可能属于哲学人文域，产业影响可能属于社会域

六域的大概判断是这样的：

1. 形式域：真值由公理推演决定，比如数学、逻辑、可计算性理论
2. 自然域：描述客观物质过程且可证伪，比如物理、化学、生物、神经机制
3. 技术域：描述人工系统怎么构造，以有效性评价，比如工程、软件、AI 系统实现
4. 心智域：描述个体主体的功能性经验和行为规律，比如认知、注意力、情绪、心理机制
5. 社会域：描述多主体互动形成的结构、规则和事件，比如经济、政治、制度、历史
6. 哲学人文域：处理意义创造和元反思，比如哲学、文学、艺术、宗教、文化研究

但这只是我自己的分类方案，不一定适合所有人。有人可能更适合按项目分，有人适合按业务线分，有人适合按写作主题分，有人适合按“产品、技术、商业、认知、社会”这种更轻的方式分。重点不在于一定要用六域，重点在于你要有一套稳定的分类边界，让 LLM 知道内容该放哪里

如果你不想一开始就搞复杂，可以只建一个 technical，或者只建一个 personal。等内容多了，再拆域。知识库分类最好从你的真实使用场景长出来，不要为了完整而完整

shared 层怎么用

只要你有多个域，就会遇到跨域问题。比如 OpenAI 这个实体，在技术域会出现，在社会域会出现，在哲学人文域也可能出现。再比如信息熵，在形式域、自然域、技术域都有不同含义。重复写三遍会乱，硬塞到某一个域也会别扭

shared 层就是为了解决这个问题。它可以放三类页面

第一类是 shared entities，比如 OpenAI、Claude、Transformer、某个作者、某个机构。第二类是 shared concepts，比如信息熵、复杂性、反馈、系统、模型这类跨域概念。第三类是 bridges，用来记录两个域之间的连接

bridge 页面不需要写得很复杂，它只要说明：A 域的哪个概念和 B 域的哪个概念有关，它们为什么有关，相似在哪里，差异在哪里，各自链接到哪些页面

这样做的好处是，跨域关系不会污染单个域的边界，也不会丢失。你在 Obsidian 里看图谱时，也能看到不同知识区域之间的桥

Obsidian 和 Git 的角色

Obsidian 在这套系统里更像 IDE。你可以用它看 wiki 页面、看 wikilink、看图谱、做人工编辑。qmd 负责搜，LLM 负责维护，Obsidian 负责可视化和人工阅读

Git 负责版本控制。每次 ingest、lint 修复、synthesis 更新，都可以提交一次。这样你能回看知识库的变化过程。如果 LLM 哪次改坏了，也可以回滚

这两个工具都很朴素，但很重要。知识库不是聊天记录，不能只存在会话里。它应该落到文件系统里，能被搜索，能被版本管理，能被人打开阅读

怎么从零搭建

如果你想自己做一套，最小版本可以这样来

第一步，安装 qmd

npm install -g @tobilu/qmd

第二步，建目录。先不要追求六域完整，选一个你最常用的领域，比如 technical。目录里放 raw、wiki、CLAUDE.md。wiki 下面建 sources、concepts、entities、synthesis、_wip、log.md

第三步，写一个最简单的bin/wiki。先只封装几个命令：init、reindex、search、get、find-related、search-chunks、log、status。不要一开始就写 580 行，先让核心流程跑起来

第四步，注册 qmd Collection。把 raw、sources、concepts、entities、synthesis 分开注册。给每个 Collection 写清楚 context description

第五步，写 CLAUDE.md。先写角色、禁区、ingest 流程、query 流程、页面模板、新会话启动流程。规则不要太抽象，尽量用具体例子

第六步，找三篇最近读过的文章试跑。第一篇主要用来暴露问题，第二篇用来调整 CLAUDE.md，第三篇看流程是否稳定。这个阶段不要追求知识库规模，重点是把 LLM 的行为调顺

第七步，加 lint。先检查最简单的：frontmatter、broken wikilink、stub 页面、raw 文件是否被改。后面再慢慢加重复概念、过期页面、跨语言重复这些检查

第八步，处理长文档。等普通文章流程稳定后，再加search-chunks和 WIP 机制。不要一开始就拿 200 页论文测试，会让你很难判断问题出在流程、分类、命令还是文档本身

这个顺序很重要。先做最小闭环，再扩展能力。最小闭环就是：放入文章 → LLM ingest → qmd 检索 → 更新 wiki → log 记录 → 下次能搜到

这套方案解决了什么

回到开头的五个问题

1. 规模天花板怎么解？靠 qmd 检索。知识库大了之后，LLM 不再扫描全量文件，而是先 search，再 get 相关页面
2. 超长文档怎么解？靠 search-chunks 和 WIP。长文档按主题拆开，每次只读几个相关块，处理完一个主题就落盘
3. 成本怎么降？靠检索前置。查询时不读全库，ingest 时不扫全量页面，长文档不读全文。LLM 的成本花在真正需要理解和写作的地方
4. 冷启动怎么过？靠 CLAUDE.md 和前三篇文章调校。先写一版规则，拿真实文章跑，发现问题立刻补规则。不要幻想一开始就完美
5. Lint 幻觉怎么处理？内容判断不要交给 lint，结构问题交给程序。broken link、frontmatter、stub、raw hash、重复页面，这些都可以自动查

这五个问题都没有被“自动消灭”。更准确地说，这套架构给了它们一个可控的处理方式。知识库系统很难一劳永逸，关键是每个问题出现时，你知道它属于哪一层，该用什么机制处理

写在最后

这套 LLM Wiki 的核心，其实可以用一句话概括：把读过的东西，编译进一个长期可维护的知识系统里

qmd 负责让 LLM 找得到资料，CLAUDE.md 负责让 LLM 按规矩办事，CLI 负责把操作变稳定，文件系统负责让知识真正落地，Obsidian 和 Git 负责让它可视化、可回滚、可长期维护。它们各自只做一件事，但组合起来，就能形成一个比较完整的个人知识编译系统

如果你只是想临时问答，普通 RAG 或文档问答工具已经够用。把文档丢进去，问几个问题，拿到答案，这种场景没必要搞得太重。但如果你想把长期阅读、研究、写作沉淀成自己的知识资产，希望一篇文章读完之后，不只是生成一次总结，而是能进入你的概念体系、问题体系和写作素材库，那这套方案会更适合

当然，六域分类只是我自己的设计，不需要照搬。有人适合按学科分，有人适合按项目分，有人适合按业务线分，也有人适合按“技术、产品、商业、认知、写作”这种更贴近日常使用的方式分。真正值得参考的不是六域本身，而是背后的实现思路：原始资料和整理页面分层，检索和写作分层，规则和执行分层，短文档和长文档分流程，人工判断和程序检查分工

所以刚开始不用想太复杂。选一个你最常读的领域，找三篇最近读过的文章，先把 ingest 跑通。第一篇用来暴露问题，第二篇用来调整 CLAUDE.md，第三篇基本就能看出这套流程适不适合你。知识库不是搭出来就完成的东西，它会随着你的输入持续生长。真正重要的不是第一版多完美，而是它能不能在你持续阅读、持续提问、持续写作的过程中，一直长下去

这篇没有把所有代码逐行贴出来，因为代码本身不是重点，重点是把完整的构建思路讲清楚：为什么用 qmd，目录怎么拆，CLI 怎么封装，CLAUDE.md 怎么设计，普通文章怎么 ingest，长文档怎么续传，Lint 怎么检查，分类方案怎么调整。理解了这些，你完全可以按自己的使用习惯搭一套

造AI的讲故事，用AI的看账单。

01

2026年有个明显的趋势，大模型能力持续进化，人工智能的话题降温，AI用户吐槽Token太贵。

短暂进入理性阶段，开始冷静的看问题。

越来越多的用户意识到：整天想着磨刀提效率，并不能解决关键问题。效率上去了然后呢？自然是优化Token的成本。

互联网公司和从业者，对新技术的热情十年如一日。

AI对工作流和业务的支撑，覆盖和触及的场景越来越多，Token的账单也越来越长，AI能力转化为生产力，是否具备性价比，付费的人似乎也说不清楚。

虽然Token的价格透明，但消耗过程的价值很难衡量。

当可用的AI产品够多，用户的选择空间很宽泛，可以通过合理的组合配置，以此降低AI的使用成本，这也是对DeepSeek预期高的原因。

能力够用和价格够便宜，也会倒推其它模型跟着降本。

02

衡量Token的消费是否值得，主要看谁在用和怎么用？

以在职的互联网公司说，业务涉及线上协作和线下交付，覆盖的场景宽泛且相对复杂，存在大量重复细碎的事项，三种岗位对AI重度依赖。

线上宣传的运营，在线获客的销售，全栈开发的产品团队。

互联网企业依赖线上流量，过去流行追热点拍素材，现在的运营用视频大模型，可以快速复刻全网热点梗。

销售接触到的客群广泛，很多线索用机器人同步，就是上半年爆火的养龙虾，在企业中找到各种落地的场景。

研发人员清一色的全栈工程师，产品也会直接编程出效果图，大量的文档和开发任务，全部交给AI去完成。

在悄无声息的进程中，AI重构组织的协作模式。

为避免Token被无故浪费，不同角色提供不同的模型会员，并不激进的要求全员使用，也不排斥AI并且保持理性。

但Token账单必须在预算之内，每笔投入都有明确的业务场景。

03

以最熟悉的研发领域看，在诸多AI工具的选择上，有三种常见的组合模式。

第一种：纯正的Claude工具和模型，是消耗Token预算的主力，每人每月的账单全部过千。

第二种：AI IDE工具搭配模型，主流是Codex和Cursor两款，每人每月的账单500左右。

第三种：各类工具混搭使用，主流和冷门的都有涉及，其中以Claude搭配DeepSeek为主，账单控制在200上下。

有个魔幻的现象：不同方式堪称年龄段的缩影。

从近一年的实践经验说，个人对AI工具的排列组合，主打一个高中低全覆盖。

Claude模型充值Key密钥，但没有作为主力工具，偶尔用来分析复杂的技术问题，会员以ChatGPT和Cursor为主，再搭配几款免费的打下手。

抛开生产力方向，主要是Claude搭DeepSeek模型，纯粹的喜欢这两款产品。

很难衡量不同组合的性价比，虽然模型的水平有明显差异，但使用者的自身能力会弥补，AI拔高职场新人的专业能力，同时也在放大经验的价值。

Token账单为过程付费，企业只为打工人的结果买单。

04

不同AI工具的组合方式，会对Token账单带来直接影响，如何使用会产生间接的影响。

初次使用AI编程产品，所有操作都用提示词下指令，最多半天就会玩到限额，随着免费Token的额度收紧，付费使用成为主流模式。

用户边吐槽边付费，边考虑如何节流降本。

首先分析任务的价值，更复杂价值更高，自然值得用更强的模型。

在产品研发领域：业务分析与架构设计，最能体现决策的价值，需要高质量的Token投入；重复性编码与文档呈现，更加考验执行的效率，可以适当降低Token的质量。

其次理解模型交互原理，主要是上下文和输入输出，合理控制信息的密度，能明显降低Token消耗速度。

最后设计工程的规范和规则，减少模型自由发挥的空间。

当然别忘记自己的专业和经验，积累在大脑的知识永久免费。

从个人使用AI的习惯来说，合理的搭配工具组合，并且平衡自己和AI的分工，可以较好的控制Token流速。

在真实的工作场景中，任务虽然由AI执行，但核心模块都会手动验收，质量和效率必须亲自把关。

05

社媒有个共鸣很强的话题，随着AI深入和重构工作流，忙完一周甚至是一天，脑腐的感觉特别强烈。

毫无疑问情况属实，最近也在尝试更换思路。

此前聊过的实践案例，在轻量级的项目中，用Codex把业务和产品研发，融合在一起全流程管理，三人具备共识的情况下，协作效率和产出质量非常高。

围绕这个案例认真反思：是否该重新设计工作流？

脑腐的原因来自AI进程，多个AI处于工作模式中，思路自然也要跟随变换，AI虽然减少重复的工作量，但是它的执行效率，也在驱动用户不断加速。

提交一个任务的间隙，会浏览更多的信息，甚至去管理另一个任务。

如果重新定义流程，让AI按照指定的规则运行，注意力放在设计的框架中，观察输入和输出的完整过程，应该能够减轻脑腐的感觉。

更令人脑腐的问题是：不管如何编排流程，AI都会在过程中加速进化，并且还留下一堆账单。

我认识一个写后端的哥们儿，将将入坑 Claude Code 那阵子，跟打了鸡血似的，把市面上能找到的 skill 一口气装了 8 个。代码生成的、数据库迁移的、写测试的、画架构图的、解释报错的、查 API 文档的，他说自己这是”武装到牙齿”。

装完那天他在群里发：以后写代码省心了，token 也省了，官方都说渐进式披露能省 98%。

一个月后他在群里又发：API 账单涨了三成多，咋回事？

他自己琢磨了好几天没琢磨明白，最后干了一件挺反人类的事——把那 8 个 skill 卸载到只剩 2 个。下个月账单回落。

我听完这事儿心里咯噔一下。这不就是当年大伙儿装 Chrome 插件那剧本么——装的时候觉得自己赚了，用的时候发现浏览器越来越卡，最后清空插件那一刻才意识到，原来卡的不是 Chrome，是自己。

对了，我那哥们儿用的是 API，不是订阅版，所以每个 token 对他来说都是真金白银。你要是 Pro 用户感知可能没这么强，但机制是一样的，往下看就明白了。

这篇要说的就是这事儿。skill 不是不省 token，是它省 token 的方式跟你想的不一样。官方文档把好的那一面写得明明白白，issue 区里一片”为啥没省”的哀嚎也是真的。这中间的落差，不是 skill 这个机制有毛病，是用 skill 的人没搞清几件事。咱挨个唠。

一、skill 到底是个啥？跟你天天写的 prompt 差在哪

要把 skill 省不省 token 这事儿讲清楚，得先把 skill 是个啥讲清楚。我发现很多人把 skill 当成 prompt 的”豪华版”——这个理解是错的，错得还挺离谱。

prompt 你天天写。一个问题来了，你敲一段话，把背景、要求、格式、例子全塞进去，发给模型。模型读完，回你一段。这事儿完了，下一个问题来了，你又得重新敲一遍——或者把上一段 copy 过来改几个字。

prompt 是消耗品。你每次发问，它就被烧一次。烧的就是 token。

skill 不一样。skill 是你提前把一套”知识 + 流程 + 规范”打包好，挂在那儿。它有个名字、有段描述、有个正文。平时它就躺着，啥也不干。等你某次问题碰到了它管辖的领域，模型自己判断”哦这事儿归它管”，再把它的正文调出来用。

打个比方你就明白了。prompt 是你每次出门都得现穿一遍的衣服——没洗的脏的湿的，每次都得翻箱倒柜重新搭一套。skill 是你衣柜里挂好的成套西装——平时不动它，要正式场合了，往身上一套就出门。

差别看着小，账算起来差得远。

prompt 是显性消耗。你写多长，模型就读多长，烧多少 token 一目了然。这块儿没啥可讨论的，写多了费、写少了省，谁都懂。

skill 是隐性常驻。skill 的正文确实是按需加载的——你不碰它它就不出场。但它的描述不一样，描述是常驻的。你每发一次问题，模型都得把所有装着的 skill 描述扫一遍，决定要不要召唤谁。

这就是 skill 省 token 跟 prompt 省 token 走的不是一条路。prompt 省 token 靠”写得短”，skill 省 token 靠”挂得准”。挂得准，正文按需加载，省得明明白白。挂得不准，描述常驻烧钱，还可能误召唤把正文也拽出来，赔了夫人又折兵。

所以那些把 skill 当成”加强版 prompt”的人，第一步就走偏了。他们以为 skill 像 prompt 一样越多越好——多装一个就多一种能力。其实 skill 像衣柜——装太多衣柜挤不下，每天找衣服都费劲。

总之，这俩根本就不是一个路数的东西。搞不清楚这个，后面说啥都绕。

二、官方说的渐进式披露，省的是哪一段，没省的是哪一段

skill 省 token 这事儿，官方文档说得挺漂亮，叫渐进式披露。听着像个学术名词，其实意思特简单——东西按需要逐步亮出来，不需要的时候不亮。

具体怎么省呢？你想象一下没 skill 的时代，怎么干活的。

你要写一个 Python 测试，又想让模型遵循团队的某套规范——比如必须用 pytest、必须有 fixture、必须 mock 数据库、必须覆盖边界用例。这些规范加起来三五千字。没 skill 之前你咋办？把这三五千字全塞进 prompt 里，每次提问都塞一遍。一天问十次，烧三五万 token，光这一项。

skill 来了之后，这套规范你打包成一个 skill，挂在那儿。你下次只要问”帮我写个测试”，模型一看描述，哦这归”Python 测试规范”这个 skill 管，把它的正文加载进来，开始干活。

省在哪？省在你没问到的那 99 次问题里，这三五千字一个 token 都没烧。

这个机制是真的。官方没骗人。

但官方没说透的是另一面——描述是常驻的。

每个 skill 都得有个描述，告诉模型”我是干啥的、啥情况下该召唤我”。这个描述虽然短，几十到一两百 token 不等，但它每一次对话都在场。你装一个 skill，对话上下文里就常驻一段描述。装五个，常驻五段。装二十个，常驻二十段。

这就是那个”长账”。

单次对话里这点描述塞进去无关痛痒，比起一个完整 skill 正文动辄几千 token，确实是九牛一毛。但只要你装得多、用得勤，它就在那儿默默累加。

我估摸着算了一下——这数字不精确，你别拿去跟官方掰扯，但逻辑是对的：假设每个 skill 描述平均 80 token，你装了 20 个，每次对话光描述这块就 1600 token 常驻。一天跟 Claude 唠 50 个来回，那就是 8 万 token 在烧”我有这些 skill 待命”这件事——而其中也许只有 5 个 skill 当天真的被召唤过。

剩下的 15 个，整天躺着收”挂号费”。

所以渐进式披露省的是变量——skill 正文按需加载，没用到的就不烧。但它没省常量——描述是固定开销，装多少就常驻多少。

省了大头，还是省了。这账长期看大概率是赚的。但前提是——你装的 skill 真的会被用上。如果你装了一堆”以备不时之需”，结果两个月一次都没召唤过，那这堆 skill 的描述就是纯纯的烧钱常量，半点用没有。

这就解释了开头那哥们儿账单为啥涨。他装的 8 个 skill 里，大概有一半儿是”看着挺酷就装上”的——画架构图的、画 ER 图的、生成单元测试覆盖率报告的，这些他实际工作里一个月用不上一次。但它们的描述每天每时每刻都在他的上下文里站岗。

所以 skill 省 token 是真的，但它只在你真用得上的那部分身上省钱。装多了，省的没省那么多，烧的反而比想的多。但这还不是最离谱的——最离谱的是下面这件事。

三、烂描述比不装还烧钱——误触发是隐形税

刚才说常驻的描述每天躺着收挂号费，那是温和的烧法——一点一点烧，你不细看账单根本注意不到。

下面这种烧法是暴力的——一下子就给你撅好几千 token，你都不知道为啥。

这事儿叫误触发。

误触发的原理特简单：你的 skill 描述写得模糊，模型分不清啥时候该召唤它。本来不归它管的问题，模型一犹豫，也把它召唤进来了。这一召唤可不是召唤个描述，是把整个 skill 的正文——动辄几千上万 token——全部塞进上下文。

你问一句”今儿天气咋样”，结果它给你召唤进来一个写测试的 skill。这 skill 正文五千字，全是 pytest 怎么用、fixture 怎么写、mock 怎么 mock。跟天气有一毛钱关系吗？没有。但这五千字已经塞进去了，已经烧了。

这就是隐形税。你交了钱，连个吭都没听见。

烂描述长啥样？我光凭记忆就能给你列出一堆，但最常见的就这几种。

一种是描述太宽泛。比如有个 skill 叫”代码助手”，描述写的是”帮助处理各种代码相关问题”。这描述等于没写——啥问题不算代码相关？你随便问一句”我这函数咋优化”，它跳出来；你问一句”数据库咋选”，它也跳出来；你问一句”Linux 命令怎么用”，它还跳出来。这 skill 一天召唤十几次，召唤进来又没派上用场——因为它根本不是为这些具体场景准备的。

还有一种是关键词堆砌。有些人写 skill 描述跟写 SEO 标题似的——把所有沾边的词都堆上：”Python、JavaScript、Go、Rust、TypeScript、代码生成、代码审查、性能优化、bug 修复、架构设计……” 堆得越多，模型越分不清重点。结果就是只要问题里有任何一个词命中，它就跳出来。

最隐蔽的一种是意图模糊——描述只说了”做什么”，没说”什么情况下不该用”。一个好的描述应该是”当用户问 X 类问题、且不是 Y 情况时召唤我”。但大部分人写的描述只有前半句，后半句省了。模型没有边界，就只能宁可错杀不可放过。

这几种烂描述合起来一个效果——你装了一堆 skill，它们互相之间没有清晰的边界，每次对话都在抢着出场。出场不仅没解决问题，还每次给你白烧几千 token 的正文。

我那哥们儿账单涨三成，大头其实就在这儿。他装的 8 个 skill 里有 3 个描述写得稀烂——”帮你写更好的代码””提供专业建议””解决你的开发难题”——这描述比没描述还坑，因为它让模型完全无法判断边界。结果就是几乎每次对话都把这仨揪进来，每次都烧三千多 token，三千多 token 啥也没干，就是白塞了一段不相干的指令。

skill 描述写不好，不是没省钱的问题，是反过来比不装还烧钱的问题。不装它，你顶多是 prompt 写得长点儿——你写多少烧多少，明明白白。装了它写得烂，你每次对话都被一个莫名其妙的 skill 正文”加塞”，你都不知道自己付的是啥钱。

这事儿听起来挺玄学，其实有个挺简单的自检方法——你打开 Claude 跟它聊一天，每次它召唤 skill 的时候你都问一句”刚才召唤这个 skill 是必要的吗”。聊一周下来你心里就有数了——哪几个 skill 出场频率高得离谱，那就是描述有问题，得重写或者直接卸载。

可大部分人不会这么干。大部分人装上 skill 就完事儿了，从来不回头审。所以才有那么多人抱怨”skill 不省 token”——不是它不省，是你自己装了几个会偷东西的二房东，还纳闷自己钱包咋瘪了。

四、和 MCP 比一比，你才看清 skill 到底省在哪

说到这儿得插一句——skill 跟 MCP，我见过太多人混着用，混完了账单双倍涨，还不知道咋回事。这事儿得单说。

咱先把这俩拆开看。

MCP 是工具调用协议。它解决的问题是——模型本身没有的”动作能力”，比如查天气、读文件、调数据库、发请求。装一个 MCP，相当于给模型递了一把锤子。它需要锤东西的时候，把锤子拿起来用一下。

skill 是知识装载机制。它解决的问题是——模型本身没有的”专属知识或流程”，比如你团队的代码规范、某个项目的架构图、某个行业的术语表。装一个 skill，相当于给模型挂一本你们公司的内部手册。它需要查的时候，翻出来对一下。

MCP 是工具，skill 是手册。这俩性质就不一样——前者让模型能干事儿，后者让模型知道事儿。

烧钱的逻辑也完全不一样。

MCP 省的是动作 token——本来模型要费一大段文字描述”我现在要去查天气，怎么查呢，先 curl 这个 API，然后解析返回的 JSON……”，有了 MCP 它直接调一个函数，几个 token 搞定。省的是描述动作的那段啰嗦。

skill 省的是上下文 token——本来你要把团队规范打在每次 prompt 里，几千字常驻，有了 skill 这几千字平时挂着，需要时才进场。省的是反复贴长文档的那段冗余。

这俩省的根本不是同一段。

那啥叫混着用双倍烧钱？

我见过最典型的一种用法——把 MCP 当 skill 用。比如有人写了个 MCP，里面塞了一大坨团队规范文档，让 Claude 每次调这个 MCP 就把规范拉出来。表面上看挺聪明——MCP 是按需调用的嘛，平时不在上下文里。

问题是 MCP 调用一次就完整塞进上下文。你这不就是把一个本该用 skill 解决的”知识装载”问题，硬塞进了一个 MCP 的壳里？结果就是每次调用都把几千字规范塞进去——而真要写 skill 的话，模型可以只加载相关的几段。

反过来也有——把 skill 当 MCP 用。比如有人写了个 skill 叫”调用内部 API”，正文里全是各种 API 的 URL、参数、示例。Claude 召唤这个 skill 把正文加载进来——加载进来又能咋样？它还是没法真的去调那个 API，它没工具啊。这事儿本该用 MCP 解决的——给它一个真正能发起请求的函数。结果你给了它一堆没用的文档，加载一次烧一次。

这俩用反了，等于花了两倍的 token，干了一半儿的活儿。

正确的活法是——动作的事儿归 MCP，知识的事儿归 skill。你要让 Claude 真的去做一件事，写 MCP。你要让 Claude 知道一件事，写 skill。这俩配合起来才不冲突。

说白了就是，别混用。混了吃亏的是你自己。

五、真正烧 token 的从来不是 skill，是用 skill 的那个人

技术机制是冷的，使用习惯是热的。

skill 这个机制本身没啥可争论的——它就是个按需加载的封装层。它不会主动多烧你的钱，它的所有行为都是被动响应。响应啥？响应你怎么配置、怎么描述、怎么管理。

同一个 skill，给两个不同的人用，账单能差出好几倍。

一个人装之前会想——这玩意儿我是真用得上吗？一周能用几次？描述边界清楚吗？跟我现有的 skill 有没有重叠？想清楚才装。装完一周回头看——这周用了几次？没用上的那次是不是误触发？描述需不需要调？

另一个人装之前不想——这玩意儿看着酷，先装上。出问题再说。装完一个月——账单涨了。账单涨完——抱怨 skill 不省 token。

你看，俩人面对的是同一个 skill，得到的是俩世界。差别在哪儿？差在敢不敢卸载。

我那哥们儿最后干的事儿，就是把那 8 个 skill 卸载到 2 个。卸载的过程他跟我说挺难受的——每卸一个都觉得”万一以后用得上呢”。但他后来想明白了——以后用得上的时候再装回来，比每天让它白白烧着钱强。

会装 skill 的人现在满地都是。点几下鼠标的事儿，谁不会。

会卸载 skill 的人少。因为卸载这事儿要求你承认——我之前装这个就是冲动消费。

承认这事儿挺难的。装的时候你脑子里全是”以后用得上”的幻想，卸的时候你脑子里全是”万一用得上”的恐惧。装是加法，卸是减法。AI 工具时代大部分人只会做加法。

但 token 这账，加法是要付钱的，减法才是省钱的开始。

写描述这事儿也一样。一个 skill 描述好不好，不在于词多不多、看着专不专业，在于你有没有想清楚它的边界——它要管啥、不管啥、什么情况下绝对别召唤它。这件事的难处不在于技术，在于你愿不愿意花一下午时间，把这几行字反复打磨。

大部分人不愿意。装 skill 三十秒，写描述五分钟，从此以后让模型自己慢慢误触发去吧——反正烧的不是自己电费。

但 API 账单是自己付的。

所以这篇文章绕了一大圈，结论就这一句话——skill 省不省 token，从来不是 skill 这个东西本身的问题，是你这个人有没有认真配置它的问题。

你愿意花时间想清楚装啥、卸啥、描述咋写、跟 MCP 咋分工——它就老老实实给你省钱。

你不愿意——它就老老实实给你烧钱。

中间那只手是你的。

最后说回开头那哥们儿。他卸载完之后，剩下的 2 个 skill 一个是”团队代码规范”，一个是”项目架构上下文”。这俩他每天都用十几回，描述写得也清楚——只在跟当前项目代码相关的提问里召唤，其他场景一律不出场。

省下来的钱呢？他拿去续了个 Pro 订阅。

这就是 AI 工具时代一个挺扎心的事儿——你以为你在用工具，其实工具在筛选用人。

会用的人越用越省，不会用的人越用越亏，机制是同一个。

你抱怨 skill 不省 token 那个样儿，跟当年抱怨 ChatGPT 答得烂那个样儿，是一回事儿。问题从来不在它身上。

中，今儿就唠到这儿。下次再有人跟你说”装 skill 能省 98% token”——你别急着装，先问他一句：你 skill 描述写得咋样？

梁文锋又出手了，而且还是二连降价。

4月25日，DeepSeek-V4-Pro开启限时2.5折优惠，输入价格（缓存命中）降至0.25元/百万tokens。

业内还没反应过来呢，结果4月26日晚间，DeepSeek就再次降价。

全系API输入缓存命中价格直接降至首发价的1/10。

叠加限时折扣后，V4-Pro的缓存输入低至0.025元/百万tokens, V4-Flash降至0.02元/百万tokens，创下全球大模型价格新低。

这是个什么概念呢？

上海译文出版的《挪威的森林》，全书约20万字。将整本书命中缓存后喂给DeepSeek-V4-Pro，那么其总成本不到1分钱。

DeepSeek这次降的，不只是token的单价。它是把“长文本、长代码、长知识库”这些原本最烧钱的AI应用场景，全都打入了价格的谷底。

01 摸着DeepSeek过河

DeepSeek两天两降，这不是简单的价格战。

先用限时折扣测试市场承受力和服务器负载，紧接着对缓存命中这一高频场景实施永久性降价。尤其是对于RAG知识库、智能客服、文档分析等缓存命中率超过60%的应用场景，成本可以直接下降90%以上。

DeepSeek研究员陈德里在社交媒体上确认，输入缓存降价是永久性的，并打上了“AGI for Everyone”的标签。

虽然说国内所有AI公司，几乎都是摸着DeepSeek过河，但DeepSeek这波降价之后，却并非所有人都担心。

尤其是大厂，他们压根不在乎DeepSeek降价。

这是因为，大厂卖API的本质，是卖背后的一整套服务。大模型API只是用来引流的，真正赚钱的是背后的计算、存储、数据库等云服务。

以阿里云为例，4月15日算力卡涨5%-34%、存储涨30%，但同时又愿意代理DeepSeek。关键点就在于，即便是客户使用DeepSeek，他们依然离不开阿里云的算力和存储。

阿里、腾讯、字节这些AI大厂，他们靠的是生态和平台赚钱。

真正难受的是智谱、MiniMax和月之暗面这样的中间层。

智谱AI在4个月里已经连续三次涨价。2月代码订阅套餐上调30%,3月旗舰API上调20%,4月8日再次上调10%，累计涨幅83%。调价后，GLM系列编程场景缓存命中Token单价已接近Claude Sonnet 4.6的水平。

智谱CEO张鹏的解释只有一句话：“瓶颈在算力，不在客户。”

在首份财报中，智谱公开了自己的商业逻辑公式：AGI商业价值=智能上限×Token消耗规模。

对于智谱这个上市公司来说，算力是稀缺资源。智谱的API年化收入（ARR）在过去12个月暴涨60倍至17亿元，Token调用量在价格上涨83%的背景下仍增长400%。

问题不是客户不愿意付钱，而是现有算力已经接近满载，继续低价只会让服务质量下降。与其通过价格战抢来大量低价值客户，不如提高价格筛选出高价值客户，把有限的算力用在刀刃上。

月之暗面和MiniMax的特点是量大便宜，当DeepSeek把API价格打到这么低，这两家或多或少都会有些难堪。

但月之暗面的K 2.6以及MiniMax即将发布的M3模型，性能都要高于DeepSeek-V4-Pro。他们在客户群体上可能会和DeepSeek有交集，但很难形成全面冲突。

促使DeepSeek降价的原因或许来自于融资，此前DeepSeek曾传出100亿美元估值，如今随着阿里、腾讯入局，估值进一步拉高至200亿美元。

估值拉高以后，融的金额也就多了，同时梁文锋也需要用市场、收入来证明DeepSeek达到估值所对应的高度。

所以即便DeepSeek是在赔本赚吆喝，也并不会让人感到非常意外。

对于上市公司来说，API就是核心收入，压低API价格就等于降低毛利。

更关键的是，如果承认“我们也要降价才能竞争”，就等于承认“我们没有技术护城河”。但如果坚持高价，又必须拿出足够有说服力的差异化价值。

DeepSeek降价的本质是他们找到了对应的客户。

梁文锋不需要DeepSeek有最强的性能。

无论是企业客户还是个人客户，模型的性能和使用体验之间有一道鸿沟。模型的性能跑分是它的上限，但是我们只需要我们能用到的部分。

只要有足够多的开发者和企业知道“还有这么便宜的选择”，整个行业的定价体系就会被重构。就像当年小米手机对智能手机市场的冲击一样，不是销量第一，但改变了所有人对“合理价格”的预期。

而且梁文锋也意识到一个问题，那就是AI就是基础设施，就和柴米油盐是一样的，那么价格战就变得在所难免，最终，AI也会像云计算一样走向“规模经济+薄利多销”。

在这个逻辑下，谁的成本结构更优、谁的技术迭代更快、谁能更早实现规模效应，谁就能活到最后。

02 DeepSeek给国产AI芯片替代讲故事

更关键的是，DeepSeek已经适配华为昇腾生态。

DeepSeek官方透露，目前Pro版本的服务吞吐受限于高端算力，预计下半年昇腾950超节点批量上市后，Pro的价格还将大幅下调。

所以这次价格下降，还只是预告而已。

昇腾950超节点通过集群方案弥补了单卡制程差距。

单颗昇腾910C芯片的BF16性能仅为英伟达Blackwell单芯片的约三分之一，但通过超节点集群方式，单个CloudMatrix 384集群的BF16总性能反而是NVL72的1.7倍，总内存容量为后者3.6倍，总内存带宽为后者2.1倍。

这还只是算力的方面，考虑硬件成本，事情就会更有意思。

华为昇腾950PR的定价约7万元人民币，英伟达同级别H200约合人民币25万元。根据英伟达AI在X上发布的信息，DeepSeek的确可以部署在英伟达Blackwell架构芯片上，不过这个成本更高，约为40万元人民币。

如果我们按FP8精度来算，昇腾950PR是7万元/PFLOPS，英伟达H200是6.31万元/PFLOPS。昇腾950PR毕竟是一张推理卡，如果我们按照推理专用的FP4精度来算，昇腾950PR是4.49万元/PFLOPS，英伟达B200是4.44万元/PFLOPS。

DeepSeek这次降价，砍在了缓存命中的价格上。

这个场景的特点是，模型不用每次重新理解全部上下文，大量重复输入可以复用，压力主要集中在推理吞吐、显存/内存带宽、调度和缓存管理上。

换句话说，它不是最依赖“单卡训练峰值”的场景，而是更适合通过国产芯片集群、工程优化和规模化调度来摊薄成本的场景。

那么我们如果把单卡的性价比优势放到大规模集群部署里，结果又会如何呢？

以100卡集群为例，国内常用的英伟达H20方案裸卡成本为1000万，13台服务器主机286万，加上机柜等，总价约为不到1500万元。同规模华为昇腾950PR的方案约为1000万出头。

昇腾950PR的单卡功耗（600W）比H20（350W）高，但单位算力功耗低65%，相同算力下对电力和制冷的需求大幅降低，基建投入显著减少。

并且，1张昇腾950PR的推理吞吐量约等于2.2-2.8张H20。这就导致实际上昇腾方案可能要比英伟达H20的方案节省60%到70%。

而大模型的API价格，很大程度上取决于硬件成本。那么DeepSeek打折，也很可能带动一波国产AI芯片销量。

连DeepSeek都开始大规模使用国产芯片，整个产业链就会被激活。云厂商会增加国产芯片的采购，芯片厂商会加大研发投入，开发者会适配国产生态。

华为昇腾、寒武纪、海光信息、摩尔线程、沐曦股份、昆仑芯、平头哥真武、天数智芯8家国产AI芯片品牌在DeepSeek-V4发布当天就完成了适配。

在DeepSeek-V4发布当天，AI算力芯片板块股价大涨。在A股，海光信息以8.2%的增幅领涨、寒武纪增幅为2.23%，在港股，天数智芯的涨幅达到9.54%。

这是一个正向循环。

当然，这并不意味着国产算力已经全面替代英伟达。训练侧仍然更依赖高端GPU、成熟软件栈和大规模集群经验DeepSeek真正走通的路径，可能不是“一夜之间替代英伟达”，而是先在推理侧、缓存场景、长文本应用里，把国产算力的性价比优势释放出来。

芯片只是第一层。

真正决定国产算力能不能吃下这波需求的，是软件生态。模型能不能稳定跑在昇腾上，推理框架能不能适配，算子有没有优化，开发者迁移成本有多高，才决定了这条路是“能演示”，还是“能商业化”。

DeepSeek的价值在于，它不是一家边缘模型厂商做适配，而是一个头部模型亲自把流量和需求带进国产算力生态。

03 梁文锋仍然需要给DeepSeek找商业模式

梁文锋真正的杀招不在于“便宜”，而在于“定价”。

梁文锋在用DeepSeek的影响力，让市场形成一个新的认知：“如果DeepSeek这个级别的模型已经能做到这个价，别家为什么还要卖这么贵？”

一旦这个锚点形成，其他厂商就陷入了两难。跟价，利润空间被压缩；不跟，就必须向客户解释“我贵在哪里”。

梁文锋曾在2024年表示：“我们只是按照自己的步调来做事，然后核算成本定价。我们的原则是不贴钱，也不赚取暴利。这个价格也是在成本之上稍微有点利润。我们降价一方面是因为我们在探索下一代模型的结构中，成本先降下来了，另一方面也觉得无论API，还是AI，都应该是普惠的、人人可以用得起的东西。”

他认为，只有让AI真正普惠，才能激发出足够大的应用市场。也只有应用市场足够大，技术迭代的飞轮才能真正转起来。

便宜可以打开市场，但便宜本身不是商业模式。

DeepSeek不能一辈子靠超低API价格活着。

API价格打到这个程度，短期内可以制造影响力，吸引客户，不过它很难成为一家长期公司的全部收入来源。

尤其是大模型推理本身仍然消耗算力、电力、带宽和运维，价格越低，调用量越大，对基础设施的压力也越大。

低价可以是入口，却不应该成为终点。

DeepSeek的目标，是成为中国AI开发者的“默认底座”。

只要足够多的应用和agent以DeepSeek作为基座模型开发，那么DeepSeek就掌握了入口。

API收入只是第一层，模型标准、开发者生态、企业部署、算力适配、云厂商合作，才是梁文锋想要的商业化空间。

DeepSeek更大的商业化机会，可能在企业私有化部署。

对于金融、政务、制造、能源这些行业来说，价格不是唯一问题，数据安全可控才是核心问题。

它们未必会长期使用公共API，但会愿意为一套能部署在自己机房、自己云环境里的模型系统付费。

梁文锋可以把开源模型作为入口，把企业级部署、调优、运维、安全、权限管理、知识库接入变成真正的收费服务。

如果DeepSeek长期只停留在模型层，它仍然会被卷入无休止的价格战。模型能力会被追赶，API价格会继续下降，开发者也会在不同模型之间切换。

真正能提高商业化上限的，是应用层产品，比如agent和CLI。

所以我始终认为，DeepSeek的低价API，应该不是梁文锋心里所想的商业化答案，更像是一个入口。

它先用价格打穿市场，再用开源建立生态，再用企业服务、私有化部署、云厂商合作和应用产品去承接价值。

这才能把“底座”的价值最大化。