野生码农
给写作技能做全量体检:228篇稿、35次调用、24次变更,换来了什么
背景与目标
前一天(10-09)刚做完 CSDN 53 篇质量分全量解剖,结论之一是"9-26 后分数断崖下滑"。本人顺着这个结论提出下一步:对写作技能 ai-dev-blog 做同款统计分析——变更了多少次、调用了多少次、写了多少文章、质量如何、花了多少时间和 token。
动机是本人一个体感:Kimi Code 对话原文读起来挺顺畅,但写博客这条路"加了太多束缚跟枷锁"——技能弹出重、产线发布重,效率很低。这次审计就是要用数据验证这个体感。
过程回顾
第一轮:六问统计(10-09 深夜派单,explore 子代理,约 13 分钟)
子代理扫了 .agents git 历史、~/.kimi-code/sessions/ 1282 个工作目录的 wire.jsonl、blog/ 目录 228 个文件、CSDN 53 篇分数明细,六问全部出数:
- 变更:约 24 个修改会话,
.agents仓只记到 7 次提交;最关键的 09-12"刀2"大砍(247→105 行)没提交,只记在 config-ledger; - 调用:Skill 正式调用仅 10 次,另有 43 个会话由子代理直接 Read 技能文件写稿;9-12 大砍后正式调用只剩 2 次;
- 产出:blog/ 目录 228 个文件(personal 105 / media 87 / 无 front matter 36),独立篇目约 170-180;
- 质量:52 个文件链到 38 篇已发布 CSDN 文章,≥80 分占比 40.5%,与全体 53 篇持平——技能不是质量短板也不是优势;
- 成本:09-12 大砍后单篇 19.2 分钟→7.3 分钟、非缓存 token 30 万→10.6 万,降本 62~65%,但质量分没动。
第二轮:被本人当场抓错(结论三引用失当)
我汇报时写"产线变更史对分数基本零影响",本人直接开火:"这有什么狗屁判断?我不是确定过 9 月 26 号变更导致分数断崖式下降吗?"
重查原文:结论三只覆盖 9-26 之前的变更,而文档第四节白纸黑字记着 9-26 后段均分 73.4、≥80 占比 14%(前段 78.0/60%)——断崖是事实,被我一句概括抹掉了。认账。
第三轮:交付形态被打回(10-10 凌晨补做)
本人第二刀:"让你统计,你统计了几篇文章?几次调用?有没有个表格给我保存下来?"——首单只有口头数字,没落盘台账,不合格。
补做三件套落盘 reports/20261009_ai_dev_blog_audit/:调用台账.csv(35 行=10 次正式调用+25 个子代理 Read 写稿会话,逐次标注产出文件/耗时/token/质量分)、文章全量表.csv(228 行,带"产生它的调用"反查列)、README.md。55 篇产出完成归属,唯一对不上的 #19 查证后确认是 IPMS 任务卡顺带触发,产出在 ipms 通道,不算漏。落盘时间 10-10 00:34(ls 实测)。
关键踩坑
坑一:概括结论不带适用边界=再造谣。 现象:把"9-26 前变更零影响"说成"变更史零影响"。根因:引用文档结论时没有核对原文适用范围,图省事用了最顺口的表述。教训:引用结论先核边界,例外段必须随行。
坑二:统计类交付只给口头数字。 现象:六问都答了,但本人要的是能翻、能挑刺、能复算的台账文件。根因:交付把关时没想过"数据资产的形态"——口头汇报会蒸发,CSV 才是资产。解法:统计类交付默认落盘,不等本人开口。
坑三:子代理首轮归属窗口虚高 52.5M token。 把次日无关写入错归给 09-16/08-15 两次调用,子代理自审发现后改严格 3 小时窗口修正。这条记它一功:验收时主动报了自己修正的两个错误。
最终方案(数据底座)
- 调用台账:35 行,每行=时间/会话/调用方式/任务/产出文件/耗时/输入输出 token/发布状态/质量分/备注,UTF-8 BOM;
- 文章全量表:228 行,与台账以"台账#N"互相关联;
- 数据缺口四条明说:9-12 前无 git 快照、17 篇 CSDN 文章无本地包、混合会话 token 高估、inbox 无交叉数据。
做得好的地方
- 本人两次纠错都逼出了新东西:第一次逼出"标题数塌陷"新证据(9-26 后 8 篇里 4 篇仅 6 个标题,此前稳定 7-9——题材分界解释不了这个,更像 9-26 改动的锅),第二次逼出台账三件套这个可复用资产;
- 匹配方法靠谱:blog 文件名与 CSDN 标题经产线改写,改用内容 shingle Jaccard+字数+日期三重校对,碰撞项人工修正,38 篇归属可信;
- "枷锁太重"的体感被数据证实:24 次变更大多打在口径/合规/GEO 上,CSDN 分数只认题材+字数+标题数;9-12 砍掉的本来就是发布级打磨工序,分数纹丝不动。
复盘与改进
- AI 侧纪律新增两条:①引用文档结论先核对适用范围,例外随行;②统计类交付默认落盘 CSV 台账;
- 优化方向已明:技能瘦身(只留有证据的硬闸)+ S3 技术稿直发通道(跳过产线全套品控),验收线有据可依——瘦身后单篇非缓存 token ≤10 万、耗时 ≤7 分钟;
- 待办:把"9-26 归因新证据"回填 csdn 分析文档与 config-ledger;ai-dev-blog 的 09-12 大砍补进 .agents git 提交(配置治理失守点)。
成长评估
| 维度 | 分 | 证据 |
|---|---|---|
| 指令与提示词质量 | 8 | 首单六问齐全、带背景文档指针,一次说清统计口径;扣分项="表格保存"的交付形态首单未明说,第二轮才补 |
| 判断与结论 | 9 | 坚持"9-26 断崖"不让步,逼 AI 重查原文,直接产出标题数塌陷新证据 |
| 思维方式 | 8.5 | 从分数下降→技能审计→"枷锁"体感,坚持用数据验证直觉,不拍脑袋砍规则 |
| 最终结果与产出 | 8.5 | 三件套落盘、55 篇归属、缺口明说;扣分项=首轮交付返工一次 |
| AI 协作能力 | 9 | 两次当场打回不打圆场("这有什么狗屁判断"),正是铁律二要的不迎合 |
AI 自评失分点(被本人抓到的优先):①结论三引用失当,抹掉下滑段,被当场抓到;②首单交付只有口头数字无落盘表格,被点名;③对"断崖"归因的过度谨慎表述,实际削弱了本人已确认的事实——谨慎和稀泥只有一线之隔。
指令实证:
- "这有什么狗屁判断?我不是确定过 9 月 26 号变更导致分数下降、断崖式下降的这个结论吗?"→AI 重查附录数据,发现标题数塌陷新证据(9-26 后 8 篇 4 篇仅 6 标题),归因从"双因素"向"变更压散结构"移动;证据落点=本复盘+待回填的 csdn 分析文档;
- "有没有个表格给我保存下来?"→交付从口头汇报改为落盘三件套;证据落点=
reports/20261009_ai_dev_blog_audit/(调用台账 35 行/文章全量表 228 行/README)。
素材点
- S3 技术稿:《我统计了 AI 写作技能的 228 篇产出:规则加了 24 次,分数一动不动》——数据全在台账里,物证直贴;
- S2 进阶稿:《AI 写的文章没流量?53 个质量分告诉我:题材比规则重要》——题材分界线实证;
- 方法论案例:调用台账(逐次调用→产出→成本→质量)可作为"AI 产线成本审计"模板,其他技能可复用。