一、慢不是模型的锅,是技能的锅账单吓人,病根不在模型,在一个发福的配置文件。这篇复盘把动刀过程、两轮纠偏和口径立法全摆出来。这个配置文件叫 ai-dev-blog,是我自用的 AI 写作技能,本质是一个提示词配置(SKILL.md),告诉 AI 写复盘博客时按什么顺序取数、按什么流程写、按什么硬判据验收。它是我使用频率最高的技能,每天复盘、写稿都走它。9 月 12 日上午,它写完一篇团队重组的复盘稿,我的感受就一个字:慢。写是写出来了,但等的过程像在工地等一车迟到的混凝土。当天 8:50 前后,我开了个会话,派单给军师两件事。军师是我用 Kimi Code 扮演的总调度,整支数字员工团队的核心,负责出主意、定规矩、盯执行、扛定性,下文都用它指代。第一件事,把写那篇博客的时间账单和 token 账单算出来。我的原话是:token 不要虚报,假报,或者漏保。漏保就是漏报,我打错的字,但意思它懂。第二件事,对技能动刀。原话:流程太复杂,效率太低下了,限制太多。二、账单:19 分钟里只有 6 分钟在写字账单出来之前,我有心理准备。出来之后,还是超出心理准备。军师从 wire.jsonl 里逐条解析,不是估算。wire.jsonl 是 Kimi Code 每次会话在本地落的完整事件日志,每次 LLM 请求花了多少 token 都记在里面。路径长这样:C:/Users/你/.kimi-code/sessions/工作区ID/会话ID/agents/代理/wire.jsonl里面四类记录:turn.prompt、usage.record(输入分 inputOther / inputCacheRead / inputCacheCreation,加 output)、tool.call、file_history.tracked。注意,子代理的日志在同级 agent-N/ 目录,漏了就是漏报。实测账单如下:总耗时19 分 10 秒,文件实际写入只占约 6 分钟。也就是说,三分之二的时间没在给读者写字。34 次 LLM 请求,主代理 28 次,质监子代理 6 次。token 全口径总消耗2,680,425。全口径就是每次请求的完整输入含缓存读取再加输出,一笔不漏。35 次工具调用里 12 次是 Read,一大半在加载写作栈材料:33 种 AI 痕迹模式、爆款 DNA、人格置换、标题技能、rules 七节。质监岗判卷的子代理独占3.6 分钟,全口径 13.9 万 token。一句话:一篇复盘的写作环节,把整条产线的品控工艺全背在了身上。三、动刀:删什么、立什么、留什么当天(9 月 12 日)动刀。删掉的、新立的、保留的,一张表说清:处理内容全删写作栈五文件强制阅读、标题评分工作流、DNA 判据、humanizer 5 维评分、品控校验脚本、质监判卷、GEO 三件套、长尾工程、S1-S4 分档、分发配套新立固定取数顺序、资料收集 ≤12 次工具调用封顶、动笔前主题三件套保留不虚构铁规、数字溯源、私密红线、成长评估技能为什么会胖成这样?kb 检索立了功。kb 是我自研的本地知识库,带 FTS5 全文检索,一条 kb search 命令覆盖全库 1,570 条目、863 万字。查出来的来历:8 月一个月,加法喂出来的——8 月初加流量工程两节,8 月中全文重写强制读四件,加到 247 行,超预算 65%。配置文件会发福。这句话我记进了台账。质监岗判卷 3.6 分钟、13.9 万 token,优化它不如直接砍了它。砍工序比优化工序值钱。但要把话说准:砍的是技能内部的判卷环节,不是废除品控。yinliu 产线的品控终审照跑,两码事。四、两轮纠偏,军师栽了三个跟头砍完不是结束。我追了两轮,军师改了两次,每一处都值得说。第一个跟头,自我设限。技能里写了一句定位:初稿,不是成品。我直接否了:如果你能快速,准确,全面还能把文章写好,我直接发布,何尝不能当成品用?军师撤掉自我设限,验收标准从三条升到四条,加了写好。它认账:发布路由的决策是我的事,技能只对质量负责。我以为它会辩解,结果它把这条批评写成了自己的新规矩。第二个跟头,本地最优的工具没进设计。我追问:固定取数四步都没有基于本地知识数据库去分析,这样是否是效率低下的原因?军师没编答案:这篇的主因不是没查库,素材就在对话里,但取数靠整读文件确实是结构缺陷。随即把取数第三步改成 kb FTS5 检索优先,实测一条命令命中 5 条跨目录条目。第三个跟头,报账口径藏大头。军师最初报的主指标是非缓存增量,299,625。我当场质疑:我管你缓不缓存,输入输出所有的都必须得统计进去。验证下来,每次请求都把整个会话上下文重发一遍,缓存命中也是真实发送的输入。增量口径比全口径少报近 9 倍,差了约一个数量级。口径就此立死:token 统计 全量求和,输入含缓存读取加输出全部计入,增量口径只作备注。这条已经写进 AGENTS.md。算账本来只是动刀前的热身,没想到算账这件事本身也被修了一遍。五、修完的样子,和一条没砍干净的尾巴技能现状 106 行,定位成稿可直接发布,四条标准:全面、快速、准确、写好。取数链改成:对话、git 证据、kb FTS5 检索优先(命中才开文件)、个人背景,≤12 次工具调用封顶,默认禁联网。硬判据只剩三条:不虚构铁规、数字溯源三档、私密规划红线。质监岗判卷环节,全稿类删除,一道不留。目标账单:≤8 分钟、全口径 token 较 268 万基准降 ≥60%。注意,这是目标值,不是实测,待验证。下篇博客实测回填台账,7 到 14 天见分晓。治理落地:配置登记回预算内,台账落三条,三次提交(0407379a、10025750、5d492c25)在动刀当天上午 9:00 到 9:09 完成。丑话也说在前面。9 月 8 日的台账就记了近期变慢的诊断,刀拖到 12 号我发话才动,中间隔了四天。配置类技能体感变差应该触发自动复审,这条机制还没做。另外,AGENTS.md 路由表里 yinliu 产线品控终审仍带着质监岗,和技能新规冲突,是否同步砍,我还没拍板。六、这次拆骨,留下四条能带走的配置文件会发福:一个月加法加到超预算 65%,一次减法砍回 106 行。给配置文件做减法,不靠感觉,凭实测账单。别替使用者做决定:技能只对质量负责,初稿还是成品是人的路由决策,写进技能里就是自我设限。本地最优的工具要进设计:有 FTS5 全文检索却整读文件,等于家里有电梯还爬楼梯。统计口径藏大头:增量口径比全口径少报近 9 倍。token 账单只认全量求和。你的提示词配置文件,多久没称过体重了?FAQQ:全口径 token 到底怎么算?A:每次 LLM 请求的完整输入(含缓存读取)加输出,逐条求和。数据来源是 Kimi Code 本地落的 wire.jsonl 事件日志,usage.record 里输入分 inputOther、inputCacheRead、inputCacheCreation 三类,加 output 全部计入。子代理的日志在同级 agent-N/ 目录,漏了就是漏报。Q:把质监判卷砍了,质量谁管?A:砍的是技能内部的判卷环节,不是废除品控。yinliu 产线的品控终审照跑,技能侧留三条硬判据兜底。3.6 分钟、13.9 万 token 的判卷子代理,优化它不如直接砍了它。Q:kb FTS5 检索优先,普通人能抄吗?A:思路能抄:取数别整读文件,先检索,命中才开文件。我的 kb 一条 kb search 覆盖 1,570 条目、863 万字,实测一条命令命中 5 条跨目录条目。你用什么检索工具无所谓,检索优先于整读这条原则通用。Q:砍完之后真的快了吗?A:目标是 ≤8 分钟、token 降 ≥60%,但这是目标值,待验证,不是实测。下篇博客走新技能,实测账单一出来就回填台账,关注蹲数据。我是野生码农,AI 实战派。自研知识库、数字员工、软考备考、量化交易四个系统,全程公开复盘。本文所有内容均为本人 AI 实战的过程和结果,经 AI 整理后发布,无任何瞎编虚构内容。这篇来自《AI员工团队》系列,下一篇是新技能的首单实测:同一套写作流程,耗时和 token 账单对比见分晓;每月 30 日前后的月报栏目,真实数据全公开。关注我,看真的。野生码农AI实战 · 全网同名