SOP · 大轮次默认深挖阈值¶

主题：wrapup-deep-analysis-20261011 日期：2026-10-11 类型：C 类变更（改全局规则 + 改 skill 文本，均为常驻加载）

1. 背景¶

build 轮 c595ab78 实测 41 步 / 0.535 元 / 9.2 min。深挖（selfcheck.py --last 1）显示：成本 66% 在输出侧，其中思考占输出 71%；且存在可避免项（「改后补备份」被迫写 ~200 行重建脚本、单步输出 13 462 tok 全轮最大；大范围 Glob 全量列举；同一文件分 5 段读）。用户裁定：大轮次应默认深挖并把优化项沉淀，不要靠人想起来。

2. 目标¶

在 rule-agent-efficiency.md §收尾自查增一条判定阈值：本轮 时间墙 ≥5 min 或费用 ≥0.4 元 → 不等异常，收尾后默认追加一次深度拆解（据输出构成 / 输出 TOP3 / 未命中 TOP3 归因，列时间与成本的可优化项，有项即记 optimization-backlog.md）。ops-execution-efficiency/SKILL.md 加一行指针，保持单一源不漂移。

3. 前置条件¶

python3；cwd = token_proxy 根（深挖命令 cost_audit/selfcheck.py 依赖 logs/）。
无外部依赖、无权限变更。

4. 影响范围¶

单机、无需停服。两个文件均属常驻加载（规则 / skill），改动同会话下次请求即生效、几乎无额外 miss。
触及：~/.trae-cn/user_rules/rule-agent-efficiency.md（§收尾自查加 1 条）、~/.trae-cn/skills/ops-execution-efficiency/SKILL.md（加 1 段指针）。

5. 分步操作¶

步骤 1：规则 §收尾自查增触发阈值¶

注意事项与坑：阈值必须高于日常轮次（单轮步数 P50=6 / P90=35），否则会为小轮深挖买单；口径与既有「异常才展开」并列，不等异常。

cd ~/Documents/services/token_proxy
grep -n '大轮次默认深挖' ~/.trae-cn/user_rules/rule-agent-efficiency.md    # 预期 命中 1 行

步骤 2：skill 加指针（单一源不漂移）¶

grep -n '大轮次默认深挖' ~/.trae-cn/skills/ops-execution-efficiency/SKILL.md  # 预期 命中 1 行

步骤 3：深挖命令可用性核对（阈值命中时实际会跑的）¶

python3 cost_audit/selfcheck.py --last 1     # 预期 输出「输出构成 / 输出 TOP3 / 未命中 TOP3」

6. 验证¶

grep -c '大轮次默认深挖' ~/.trae-cn/user_rules/rule-agent-efficiency.md        # 预期 1
grep -c '大轮次默认深挖' ~/.trae-cn/skills/ops-execution-efficiency/SKILL.md   # 预期 1
python3 cost_audit/selfcheck.py --last 1                                      # 预期 正常出报告

实测：两处 grep -c 均 1；selfcheck.py --last 1 正常输出（本轮即以它完成对 build 轮的深挖）。

7. 回滚¶

备份位置：wrapup-deep-analysis-20261011/backup/，逐条登记见 backup/README.md。

cd ~/Documents/services/token_proxy
TS=20261011-164154
cp -p wrapup-deep-analysis-20261011/backup/trae-cn/user_rules/rule-agent-efficiency.md.bak.$TS ~/.trae-cn/user_rules/rule-agent-efficiency.md
cp -p wrapup-deep-analysis-20261011/backup/trae-cn/skills/ops-execution-efficiency/SKILL.md.bak.$TS ~/.trae-cn/skills/ops-execution-efficiency/SKILL.md

回滚后验证：两处 grep -c '大轮次默认深挖' 应为 0。

8. 风险说明¶

风险	缓解
阈值偏低 → 为小轮深挖买单	设于 5 min / 0.4 元，高于 P90 轮（35 步）；待标定项 `optimization-backlog.md` #56
深挖本身增成本	深挖只 1 条命令 + 归因结论；相比"看不见瓶颈"的代价，成本极低
两处文本漂移	规则为单一源，skill 只放一行指针

附录 · 交付物与回滚点¶

交付物	路径	说明
触发阈值	`~/.trae-cn/user_rules/rule-agent-efficiency.md` §收尾自查	时间墙 ≥5 min 或费用 ≥0.4 元 → 默认深挖
指针	`~/.trae-cn/skills/ops-execution-efficiency/SKILL.md`	指向规则，单一源
挂账	`optimization-backlog.md` #55（改前先备份）、#56（阈值标定）	本轮深挖产出
回滚点	`wrapup-deep-analysis-20261011/backup/`	台账 `backup/README.md`

9. 追加（2026-10-11）：成本分析判定文案修正¶

动因：baseline_check.py 的「成本分析」末句原是一行二元判断——top 类 ≥50% → 「集中在 X，下轮可压」，否则 「较分散」。用户指出：①「下轮可压」反复出现却看不到落地；②「较分散」没有任何解释口径。

回答①（落地在哪）：落地机制早就存在——merge-guard 的判据 A/B/C/D/E/F/I/K/L/M/N/R/S/T/U/H 就是「下轮可压」的运行期注入，且全部非拦（ENFORCE_MARKS 已清空）。缺的只是文案没点名指向它。不是缺机制，是缺指针。

回答②（较分散）：它从来不是「正常 vs 可优化」的判定，只是「无单类 ≥50%」的补集——所以看着"没说法"是对的。真正的可压信号在 「未合并」列（可并类未合并块，step_profile 口径），不在成本分布。

改法（cost_audit/baseline_check.py，备份 backup/cost_audit/baseline_check.py.bak.*）： - 新增 COVER_JUDGE：动作类 → 覆盖它的判据（读/搜→A/B/K；跑→E/T/N/S/H；改→C/I/R；增→F；删→D；外部→webfetch-guard；计划/编排/等待→无）。 - 三分支文案： - 集中且可并 → 集中在 X（N%）→ 落地=判据 …（运行期非拦提醒） - 集中但不可并 → 集中在 X（N%），但该类不可并（无对应判据）→ 非可压点（修正原「下轮可压」对不可并类的误导） - 分散 → 无单类主导（最大 X N%、前二 M%）——分散本身不判可压性；是否可压看本表「未合并」列

验证：三分支合成用例（跑 75% / 编排 90% / top 40%）输出符合预期；py_compile rc=0；实盘 wrapup.py 输出已随之更新。

回滚：cp -p backup/cost_audit/baseline_check.py.bak.<TS> cost_audit/baseline_check.py。

来源：/home/rain/Documents/services/token_proxy/wrapup-deep-analysis-20261011/SOP.md ｜最后更新：2026-10-11 17:19（由 build/sync.py 同步，请勿在站点侧修改）