野生码农
终审 AI 分析从 3 分钟砍到 53 秒:一次提速、三个 bug、一条铁律
背景与目标
10-12 晚,我在终审台点「AI 分析」,等了两分多钟才出结果。我的诉求很直接:"我希望是一轮 llm 快速搞定的,分析下问题在哪里?如何解决?"——不是忍耐,是定位根因、改成一轮直出。
IPMS 终审台的 AI 分析链路:前端按钮 → FastAPI 建异步任务 → 子进程 kimi -p 跑全篇体检 → 结果落 review_suggestion 表 → 前端轮询展示,我逐条采纳/忽略。
过程回顾
尝试 1:先拿数据,不猜
查 headless_task 表两轮实测:团队#48 耗时 167 秒、团队#46 耗时 203 秒,prompt token 都超过 12 万——而母稿全文只有一万字符(约四五千 token)。12 万对 5 千,数字本身就指着鼻子说:问题不在稿长。
顺着 stream-json 日志的 session_id 摸到 kimi CLI 的 wire.jsonl 逐事件拆解,真相落地:
- 第 1 轮:0.7s → 153.1s,152 秒占全程 91%,输出 7601 token——但结果 JSON 只有 2.4KB(约 1.2k token),剩下约 6400 个全是思考(reasoning)token;
- 第 2 轮:模型自发跑 Bash 校验刚写的 JSON 文件,4 秒;
- 第 3 轮:收尾总结,8.8 秒;
- 12 万 prompt = 三轮各自重发约 4 万 token 的 harness 上下文(CLI 系统提示 + AGENTS.md 链 + 工具 schema)。
根因一句话:k3 是 always_thinking 模型,默认 effort=high,它闷头想了两分钟,只为写一份 1.2k token 的 JSON。
尝试 2:方案选型,我纠了一次方向
我第一版方案是在 ~/.kimi-code/config.toml 注册 k3-low 模型别名。准备动手时翻了官方文档,发现本人全局配置里 [thinking] effort = "high" 对主代理的优先级高于模型别名的 default_effort——别名方案会被静默覆盖,白搭。
改走 env 注入:KIMI_MODEL_THINKING_EFFORT=low 优先级高于配置文件,且只作用于 AI 分析子进程,不影响我日常交互的 kimi。这个变量在文档的 env 清单里,不是猜的。
尝试 3:本人定调——提示词扛质量控制
我(本人)给出关键指令:"把提示词写精准,要求它检查哪些东西,怎么检查……模型不要去思考了,就直接回结果。"据此三刀:
- 提示词精准化重写:五类检查项各带判定方法与高频陷阱(的/地/得、在/再等)、固定排序优先级、old_text "≥10 字+照抄+全文唯一"硬约束、一个 few-shot 格式锚点;
- effort=low:推理 token 从 ~6.4k 压掉;
- 一轮直出:模型只输出 JSON 到回复正文,后端从 stream-json 末条 assistant 帧提取——砍掉写文件、自发校验、总结两轮。
结果
实跑一篇(团队#48 定稿副本):53 秒,frames=[meta, assistant, meta] 真·一轮零工具调用;prompt token 12.2 万→3.7 万,completion 8k→2k;2 条建议正常落库。pytest 191 全绿。
关键踩坑:测试数据差点吓死本人
实跑验证时终审队列是空的(AI 分析门槛=母稿成),我把团队#48 定稿复制一份导入成测试篇目"踩坑#12",跑完后把它放弃清理。
第二天本人在列表里看到一条和自己要发的文章同名的"已放弃"篇目,当场炸了:"这篇文章是我本来就要发的文章吧?你给我废掉去了?"
真相:踩坑#12 从生到死 99 秒(21:36:52 建目,21:38:31 放弃),是测试副本;真稿团队#48 始终 fabu就绪,发布包六件齐套,9 平台发布记录待发,一个字节没丢。event_log 全流水作证。
AI 失分点,认:测试篇目用真实标题、放弃后还躺在生产列表里,这两步都是惊吓制造机。本人裁定:"测试的东西测完了,你就给我删掉去,你留在生产环境干啥?"——当场物理删除(VACUUM INTO 快照先行,7 表 14 行零残留),规则入台账:测试数据即测即清,禁留生产库;测试篇目标题强制带【测试】前缀。
连带收口:三个真 bug
同一晚本人用元素拾取器连着点出两个问题,加上一个追问,共修三处:
| 问题 | 根因 | 修法 | commit |
|---|---|---|---|
| 复制标题带出理由段 | 剥理由只认 。理由: 一种分隔符 |
复用终审定稿同款 _parse_titles(候选标题最长前缀匹配),三种理由形态通吃 |
df4948d |
| 复制的不是终审选定的标题 | 复制只读 meta 写手主推,没读 picked_title | picked_title 优先,未选回落 meta | 1890071 |
| 定稿标题尾部多冒号 | 第四种 meta 格式(方向词冒号直连),_DIRECTION_RE 不剥冒号 |
正则吸收前缀冒号 + rstrip 加固 | 7d52abc |
第三个最值得记:本人没有直接说"修掉",而是问"是个例还是系统性的 bug 问题?"。我查了存量 meta:四种格式四周内各出现一次(#44 分组式、#46/#47/#48 括号式、#49 冒号式)——meta 是 LLM 每篇现场生成,格式漂移是常态,判定系统性,修解析器而不是擦数据。顺带把团队#49 已入库的脏标题用干净版重选覆盖。
另有团队#47 排版前言单点修(前言误放正文首句,换摘要原文,本人指示不返工),一句话带过。
最终方案沉淀
- 数据落库优先原则(本人裁定,入 dev 章程):有库系统的结构化数据与状态一律入库;文件只作管道与产物、不作状态源;日志可落盘,关键事件必须同步入 event_log 类库表。我补的边界(文件≠禁用,是角色限定)被采纳;
- AI 分析 JSON 的定位说清了:它是子进程→后端的管道,不是存储;
review_suggestion表才是家; - kb.db 加表提议被否决:ip.db 独立库不混 kb.db 是架构红线,且 kb 的 db 层只读防护。
做得好的地方
- 提速先拆 wire.jsonl 拿逐事件时间线,根因定位零猜测;
- 方案选型被配置优先级打脸后当场换路,没硬上;
- 三处 bug 修法都走"复用同源解析器"而不是单点补丁,消费方一次通吃;
- 每单都留 diff + 实跑证据 + commit,验收链完整。
复盘与改进
- 测试数据纪律:以后验证用带【测试】前缀的假数据,测完当场删,报告里写明测试 key;
- 界面可见的副作用(哪怕是已放弃状态)也是副作用,操作前想一层"本人看到会怎么理解";
- 配置类方案动手前查优先级链(env > 配置文件 > 别名默认),别凭第一直觉。
成长评估(五维,对事)
| 维度 | 分 | 证据 |
|---|---|---|
| 指令与提示词质量 | 9 | "把提示词写精准……模型不要去思考了,就直接回结果"——方向+方法一次给全,零纠偏跑通;"是个例还是系统性"给出决策框架再让我动手 |
| 判断与结论 | 8.5 | "数据落库优先"裁定方向正确;踩坑#12 事件中基于界面观察的质问合理,证据摆开后立即接受事实 |
| 思维方式 | 9 | "你记住一个事情……其他系统性项目都要遵守"——单点事件抽象为团队级原则并要求落持久层,系统化思维 |
| 最终结果与产出 | 9 | 203s→53s 达标,pytest 191→194 全绿,三 bug 全收口 |
| AI 协作能力 | 8.5 | 拾取器 JSON 直给定位、验收用刷新点验制;扣分项:踩坑#12 惊吓本可避免 |
AI 自评失分点(如实):①踩坑#12 测试篇目用真实标题+放弃后留列表,被本人当场抓到,本期最大失分;②第一版 config 别名方案会被全局配置覆盖,自查文档后换 env 方案——自抓,但若先查文档可省一轮;③测试文件带入草稿残渣导致一轮 pytest 红,自抓自修。
指令实证:
①"我认为,这个AI分析的功能,把提示词写精准……模型不要去思考了,就直接回结果"→ AI 行为从"调参数降速"转向"提示词扛质量+一轮直出",结果落 c5fad76(53s 实证);②"测试的东西测完了,你就给我删掉去,你留在生产环境干啥?"→ 当场物理删除+快照备份先行,规则落 dev 台账 2026-10-12 节(80ae8c7)。
素材点
- wire.jsonl 逐事件拆解法:任何"AI 慢"类问题先看 token 构成(推理 vs 可见输出),再谈优化;
- "是个例还是系统性"判定模板:查存量同类数据出现频率 + 生成端是否确定性;
- kimi CLI 三档 effort(low/high/max)+ env 注入覆盖法,其他无头任务可复用;
- 测试数据即测即清 SOP:VACUUM INTO 快照 → 逐表删 → 残留行数断言 → 服务探活。