improve-system

改进系统 — 有度量的改进循环

从系统自身的纠正历史中挖掘反复出现的失败模式，跟踪拒绝率指标的趋势，并提出有针对性的编辑。**只提出建议，绝不自动应用。**这是针对无法度量的工作调整后的自动研究循环：以聊天历史中的纠正作为代理信号，以 QA 拒绝率作为趋势指标（video-insights 改进 #5，2026-06-12）。

范围边界

• /system-audit 用于查找需要一次性修复的具体 bug 和偏差。/improve-system 用于查找多次运行中反复出现的行为模式，并将其转化为长期规则。
• /li curate 用于将 Agent 覆盖层整合为技能差异（门槛为 3 次及以上运行）。不要重复这项工作：如果某个模式的证据仅存在于覆盖层中，请注明“通过 CURATE 流转”，而不是在此起草差异。本技能的独特范围是 QA 日志、拒绝率指标以及会话历史中的纠正。
• /grade-system 用于评估整体质量状况。本技能衡量纠正情况和支出，不进行评估。
• 仅凭日志无法在此裁定模型路由问题——请参阅下文的“路由问题”。
• 没有指标的改进循环只是形式主义。每次运行都要报告指标，即使没有提出任何建议。

步骤

1. 收集信号（工作文件夹，平行读取）：

   • agent-improvements/qa-rejection-log.md — 裁定结果、重新委派次数、原因（主要指标）。
   • agent-improvements/qa-disagreement-log.md — Ane 或 Ann 推翻 QA 裁定的情况。
   • agent-improvements/cost-calibration-log.md — 估算值与实际值的偏差，以及每个会话行中编号的校准信号列表；这是系统最丰富的纠正渠道。每一行都包含 5 到 9 条编号信号，指出出了什么问题、误诊了什么，以及在源头修复了什么。读取自上次运行以来追加的每一行的信号列表，不要只看成本列。Run 5（2026-07-31）的证据：三个列出的直接模式渠道均无结果，而 3 行中的 19 条信号涵盖了该次运行发现的所有模式。该表格是文件的最后一部分（于 2026-08-05 重构，Run 7 P4，因此追加到文件末尾的内容会进入该表格）；最新的行位于表格末尾。
   • agent-improvements/{ann,vi,li,researcher}-overlay.md 中的 ## Active Improvements 部分。
   • .remember/recent.md 和 .remember/today-*.md — 会话历史中 Ane 在对话里所做纠正的代理信号。
   • agent-improvements/pre-flight/*-lessons-learned.md — 四类经典交付物的直接模式纠正信号。目前大多数工作都由个人直接完成（不涉及 Ann/Vi 协作），因此 QA 拒绝日志按设计会缺少记录；直接交付物的纠正记录在这些日志中。读取 agent-improvements/pre-flight/ 下的所有 *-lessons-learned.md。
   • 在时间窗口内创建或更新的反馈记忆 — 四类日志之外所有内容的直接模式信号。对非经典交付物（Excel 工具、运维文档、试点计划、邮件、技能）的纠正会记录在会话记忆目录中的 feedback_* 记忆里，而不是类目日志中。按修改时间列出文件（对记忆目录运行 ls -l --time-style=+%Y-%m-%d），并读取时间窗口内的 feedback_* 条目。Run 2（2026-07-17）的证据：连续 10 周类目日志没有条目，而反馈记忆中记录了 3 次真实纠正。
   • agent-improvements/improve-system-runs.md — 之前的运行记录（避免再次提出已被否决的事项）。

2. 跟踪指标（四项信号）。

   • 编排运行（qa-rejection-log）。 报告：记录的编排运行总数、发生重新委派或判定非 PASS 的占比、最常出现的 3 个原因、与上一次运行数据相比的变化趋势。此日志仅用于 Ann/Vi 编排。如果在明确执行了编排的会话之后日志仍为空，则结论是“收尾步骤 4b 的日志记录失败”——这是日志缺失。但如果这段时间处理的是直接模式任务，日志为空就是预期情况，并非故障——下结论前先确认实际模式（检查会话历史和 cost-calibration-log，查看这段时间内是否有编排运行；确认日志的创建日期早于预期运行的日期）。

   • 直接模式修正，经典类别（飞行前经验教训日志）。 对每个 *-lessons-learned.md，报告这段时间内的条目数和反复出现的修正主题。这四份日志（ToC、指标框架、评估设计、证据简报）仅在相应类别的交付物实际交付时才会填充——如果这段时间没有此类交付物，日志为空就是预期情况，并非故障。按相同方式跟踪趋势：同一主题的重复修正增多，说明规则未被执行。

   • 直接模式修正，其他所有情况（反馈记忆）。 报告这段时间内创建或更新的 feedback_* 记忆数量及其主题。如果这段时间的工作类型不属于上述四类日志涵盖的范围，这就是直接模式的实时信号。记忆中反复出现的主题 = 候选模式；如果某项修正与某条现有反馈记忆的规则相符，则属于规则未被执行的失败，应赋予更高权重。

   • 直接模式修正，校准信号（cost-calibration-log 行）。 报告自上次运行以来追加的行数，以及这些行中编号信号的数量，然后按主题归类这些信号。若某条信号指出的规则已存在，则与反馈记忆一样，应将其视为规则未被执行的失败。工作类型变化不会让此渠道沉寂，因为 /wrap-up 会为每个会话写入一行，而这是其他三类信号所不具备的特性。

3. 归类模式。 一个模式需要在多个运行或日志中至少出现 2 次。单次出现属于观察项，应列出但不采取行动。用一句话描述每个模式，并注明其出现记录。

4. 提出编辑建议。 对每个模式，注明目标位置（CLAUDE.md 规则、技能编辑、Agent 编辑、检查清单、反馈记忆，或用于禁止事项的 PreToolUse 钩子）、拟议措辞，以及对指标的预期影响。将所有建议以编号列表呈现，然后等待 Ane 对每项作出批准、拒绝或暂缓的决定。

5. 仅应用已批准的项目。 使用 Edit 工具，并限定编辑范围。目标文件已存在时，应用 mel_wiki/wiki/concepts/edit-preservation-protocol.md。

   编辑规范文件，绝不编辑生成的镜像。 此技能写入的几个目标是由同步脚本重新生成的镜像：claude-ai-shareable-export/* 由仓库根目录中同名文件生成，.claude/skills/<name>/SKILL.md 由 personal-skills 副本生成，.claude/agents/* 由 ~/.claude/agents/ 生成。对镜像的编辑在下次同步前会保留，之后便会无提示地消失。编辑导出、镜像或缓存目录下的任何文件之前，先查明其生成来源（在同步脚本中 grep 文件名），然后编辑对应的源文件。证据：第 4 次运行将 claude.ai 范围门控的变更写入 claude-ai-shareable-export/，随后 sync_shareable_export.py 在同一轮中将其覆盖。 当获批的修改涉及技能或 Agent 文件时，关闭本次运行前要重新运行测试框架。 SKILL_BUDGETS（tests/run_tests.py）中的行数预算会限制这些文件，因此新增规则可能导致超限，而只有在最后运行测试框架时才会暴露失败。请从该字典读取当前预算，不要想当然；数值会变化。修复超限时，应将新增内容并入相邻段落，绝不要删减你未编写的内容。证据：第 3 次运行中，vi 的单次重试规则让文件超出两行，并导致后续又提交了一次。

6. 结束本次运行。 将带日期的摘要（指标数值、发现的模式、提案 + Ane 的决定）追加到 agent-improvements/improve-system-runs.md（若文件不存在，则创建并添加 # Improve-System Run Log 标题）。然后标记维护周期：python ~/.claude/hooks/maintenance_due.py --mark improve-system 2>/dev/null || true。

支出审计模式——Token 实际花在哪里

在支出触发词（“where are my tokens going”“token audit”“why was that session expensive”“context optimisation”）出现时运行，或在第 2 步发现值得解释的成本异常趋势时运行。只读：输出是一份 Tier 1 工作简报；唯一允许的写入是自愿添加一行待办事项。此模式整合自 token-economy-audit 待办事项（2026-08-05）；2026-07-30 的手动审计是其证据基础。

1. 在当前会话中计算始终加载的基础开销；绝不要引用存储的数值。 汇总用户和项目的 CLAUDE.md、MEMORY.md 的实时大小、技能 frontmatter 总量、Agent frontmatter 总量，以及 SessionStart 注入内容。此处尤其要遵守计算数值规则：本轮没有计算过的支出数值属于 ⚠️ 数据缺口，而不是数字。
2. 通过 ctx_execute_file 将 agent-improvements/cost-calibration-log.md 作为数据集挖掘；绝不要使用 Read。 该文件超过 140k 个字符，large_read_gate hook 会拒绝无界的 Read。提取每行的 $/1k-output、缓存写入比率，以及每个 "Calibration signals" 区块，整理成驱动因素表。已知的三个驱动因素（输出量、缓存写入、先写规格再清除）都只能通过从头到尾阅读日志才发现；开展审计就是为了避免再有人手动重复这一过程。
3. 按（节省 × 置信度）/ 工作量对杠杆排序。 将每个杠杆标为质量中性、质量提升或取舍。提出取舍时，必须明确说明具体牺牲了什么。
4. 不可优化的部分——长期规则。 绝不要为了节省 Token 而删减长期指令。基础开销并非成本所在：缓存读取占 93–99%，维持它只需花几美分，而其中的规则正是保障输出质量的关键。支出取决于编写的字数以及进入上下文的新字节；有效杠杆是减少返工，而不是降低严谨度。手动审计很可能会首先删减 CLAUDE.md，而这正是以质量换取几分钱的改动——本模式的存在就是为了避免这种做法。

路由问题——开展试点，绝不要根据日志直接裁定

挖掘结果若引出了模型路由问题——例如某种修正模式指向特定模型层级、Haiku 层级候选模型、存疑的 Opus 升级规则，或评审模型比较——不要根据修正日志或成本记录作出结论。按照 mel_wiki/wiki/concepts/routing-pilot-method.md 开展有预置缺陷的盲测试点：密封答案、在各类门控中植入约 10 个缺陷、预先声明通过标准，并以未命名的异步 Agent 方式启动，使每组的 Token 用量可观察。注册表（agent-improvements/agent_registry.md § Routing tiers）要求，任何新增 Haiku 层级模型前都必须记录试点结果；试点结论若移除了某项升级规则，重新启用前也必须进行复测试点。试点结论应作为 PILOT 行写入 cost-calibration-log.md，并进行相应的注册表编辑——与其他提案一样，通过第 4 步提出该编辑。

危险信号 — 发现自己在做这些事时请立即停止

• 在 Ane 批准某个具体项目之前就进行任何编辑。“她肯定会批准”不等于批准。
• 因为“感觉很熟悉”，就把单次出现的情况提升为一种模式。
• 运行日志显示 Ane 已拒绝某个项目，却没有新的证据就再次提议。
• 没有打印指标数值就报告“系统运行正常”。
• 引用本轮未计算出的下限、支出或成本数值（支出审计模式）。
• 根据日志而非植入缺陷的试点来解决模型路由问题。

借口	事实
“修复很简单，直接应用就行”	对常设规则进行简单编辑也会累积影响；必须先获批准。
“数据稀少，但模式很明显”	单个数据点只是轶事。将其记为待观察事项。
“日志为空 = 记录干净”	qa-log 为空，可能是日志记录损坏，也可能是没有编排的直接模式时段。下结论前先核实是哪种情况（是否运行了编排？日志是否早于预期运行时间？），并查看经验教训日志和成本日志中的校准信号，确认是否存在直接模式信号。