使用频率最高的技能被我拆了:247 行砍到 106 行,质监岗直接开除

背景与目标

ai-dev-blog 是我使用频率最高的个人技能——每天复盘、写稿都走它。9 月 12 日上午它给我写了一篇《数字员工团队重组首测》,写完我的感受就一个字:慢。当天 8:50 前后我开了个会话,让军师干两件事:把写那篇博客的时间账单和 token 账单算出来("token 不要虚报,假报,或者漏保"),然后对这个技能动刀——"流程太复杂,效率太低下了,限制太多"。

目标很明确:技能要全面、快速、准确——全面把内容搞全,快速查资料快、结构快,准确把握主题方向和文章逻辑。

过程回顾

第一步:先算账,实测账单说话

军师从会话日志(wire.jsonl)里逐条解析,不是估算:

• 耗时 19 分 10 秒(08:24:23 技能触发 → 08:43:33 结束),其中文件实际写入只占约 6 分钟
• 34 次 LLM 请求(主代理 28 + 质监子代理 6),token 总消耗(全口径=每次请求完整输入含缓存+输出)2,680,425——首次请求输入即 196,327,峰值单次 213,038,"一次会话起步十几万"的体感完全属实
• 35 次工具调用的去向:12 次 Read 里一大半在加载写作栈材料(humanizer 33 种模式、爆款 DNA、人格置换、标题技能、rules.md 七节),zhijian_check 跑两遍,质监岗子代理判卷独占 3.6 分钟

一篇复盘的写作环节,把整条产线的品控工艺全背在了身上。

第二步:动刀,247 行砍到 105 行

删掉全部品控机器(写作栈五文件强制阅读、标题评分工作流、DNA 判据、humanizer 5 维评分、zhijian_check、质监判卷、GEO 三件套、长尾工程、S1-S4 分档、分发配套),立三条新机制:固定取数顺序、资料收集 ≤12 次工具调用封顶、动笔前主题三件套。保留不虚构铁规、数字溯源、私密红线、成长评估。

第三步:我两次纠偏,军师两次改

第一次:技能里写了"定位:初稿,不是成品"。我直接否了——"如果你能快速,准确,全面还能把文章写好,我直接发布,何尝不能当成品用?"军师撤掉自我设限,验收标准从三条升四条(加"写好")。

第二次:我追问两点——"质监砍了"(判卷子代理 3.6 分钟白烧);"固定取数四步都没有基于本地知识数据库去分析,这样是否是效率低下的原因?"军师诚实回答:这篇的主因不是没查库(素材就在对话里),但取数靠整读文件确实是结构缺陷。随即把取数第 3 步改成 kb FTS5 检索优先:一条 kb search 命令覆盖全库 1,570 条目/863 万字,实测命中 5 条跨目录条目——而这次改技能本身,kb 检索就立功了:查出这个技能的臃肿是 8 月一个月加法喂出来的(8-05 加流量工程两节、8-12 全文重写强制读四件),加到 247 行,今天一次减法砍回 106 行。

第四步:口径再纠一次——统计规则本身也被我否了

军师报账时把"非缓存增量"(299,625)当主指标。我当场质疑:"35 轮对话上下文显示都超 100K,一次会话起步十几万,还不算输出,你这个 30 几万的 token 是怎么回事?我管你缓不缓存,输入输出所有的都必须得统计进去。"实测验证我对了:每次请求都把整个会话上下文重发一遍,全口径 268 万,增量口径比全口径少报约一个数量级。口径规则就此立死:token 统计=全量求和,输入含缓存读取+输出全部计入,已写进 AGENTS.md。

关键踩坑

• 坑 1:配置文件会发福。现象:技能一个月从能用到 247 行超预算 65%;根因:每次翻车都往里加规则,从不做减法;解决:凭实测账单整段砍,不靠感觉。
• 坑 2:自我设限写进技能。现象:"初稿不是成品"的定位措辞;根因:军师把发布路由决策错当成技能自我定位;解决:技能只对质量负责,走产线还是直发由本人定。
• 坑 3:本地最优工具没进设计。现象:取数步骤整读大文件,排产规划当轮读两遍;根因:设计取数流程时没想到 kb 有 FTS5;解决:检索优先于翻文件,一条命令顶 3-5 次翻目录。
• 坑 4:统计口径藏大头。现象:报账主打"非缓存增量 30 万",全口径 268 万放次要位置;根因:套用计费侧惯例,没站在"实际处理量"立场;解决:本人裁定全量求和口径入章程,增量口径只作备注。

最终方案

技能现状(106 行,C:/Users/three/.agents/skills/ai-dev-blog/SKILL.md):

• 定位:成稿,可直接发布;四标准=全面/快速/准确/写好
• 取数:对话 → git 证据 → kb FTS5 检索(检索优先,命中才开文件) → 个人背景,≤12 次工具调用封顶,默认禁联网
• 硬判据只剩三条:不虚构铁规、数字溯源三档、私密规划红线
• 质监岗判卷环节:全稿类删除,一道不留
• 目标账单:≤8 分钟、全口径 token 较 268 万基准降 ≥60%,实测回填台账

治理配套:config-registry 回预算内,config-ledger 落三条,三次 commit(0407379a / 10025750 / 5d492c25,均在 09-12 上午 09:00-09:09);token 全口径规则入 AGENTS.md。

做得好的地方

• 我开场就要账单不要感觉("token 不要虚报"),军师逐条解析 wire 日志求和,数字全部可溯源——先算账再动刀,这次做对了顺序
• 三轮追问逐层下探:统计账单 → 定位措辞 → 工序 → 取数机制,每层都有处置落地,没有停留在抱怨;第四轮连统计口径本身也被揪出来修了
• 砍工序比优化工序值钱:质监岗 3.6 分钟/13.9 万 token(全口径),优化它不如直接砍了它

复盘与改进

• 刀 1(09-08)台账就记了"近期变慢"的诊断,刀 2 拖到 09-12 我发话才动——配置类技能的"体感变差"应该触发自动复审,不等我开口
• AGENTS.md 路由表里 yinliu 产线品控终审仍带"质监岗",与技能新规冲突——待我拍板是否同步砍
• 下篇博客实测验证:耗时/token 对比、kb 检索命中率,回填台账,7-14 天内见分晓

个人成长评估

指令与提示词质量:8.5。靶子完整、授权清晰、自带验收标准("统计下,用了多少时间,多少 token,token 不要虚报");扣 1.5:首轮没限定"动刀"的保留边界,军师自由裁量偏大,靠后两轮纠偏兜住。

判断与结论:9。"初稿定位没必要进技能"判断正确且一针见血;"kb 没用=效率低下原因"部分对部分错——该篇主因是品控机器,但结构缺陷的定性成立;token 全口径裁定正确,直接纠正了军师的报账口径。

思维方式:9。从一次"慢"的体感追到技能级改造,且连续追问不停在表层("这样是否是效率低下的原因"——逼出了取数机制的结构性修复);机制思维稳。

最终结果与产出:8。247→106 行、质监砍除、kb 检索入列、口径入章程、四 commit 落账;扣 2:验证项靠次日两篇实测回填,见真章前不打满。

AI 协作能力:8.5。纠错不含糊("这种描述没必要进技能"),拍板快("质监砍了");军师侧验收、台账、commit 闭环完整。

AI 自评失分点:①把路由决策写成技能自我定位("初稿不是成品"),被本人当场抓获;②取数节初版漏 kb FTS5——本地最优检索工具没进设计,被一问点破;③刀 1 诊断在 09-08 落账,刀 2 拖 4 天才动,响应滞后;④报账把非缓存增量当主指标,全口径 268 万被压到次要位置,被本人质疑后才立正。

素材点

• "19 分钟/268 万 token 写一篇博客"——技能臃肿的实测账单(全口径,单次请求峰值输入 21.3 万)
• 原话:"如果你能快速,准确,全面还能把文章写好,我直接发布,何尝不能当成品用?"——撤自我设限的定性判断
• 原话:"我管你缓不缓存,输入输出所有的都必须得统计进去"——token 全口径规则的来历
• 配置文件会发福:一个月加法加到 247 行超预算 65%,一次减法砍到 106 行
• 砍工序比优化工序值钱:质监岗判卷 3.6 分钟/13.9 万 token,直接开除
• kb FTS5 一条命令顶 5 次翻目录:1,570 条目/863 万字,检索优先于翻文件