Appearance
从死循环到自检工具 — WorkBuddy Auditor 诞生记
这是一个真实发生的故事。 从一个卡死两小时的下午开始，经历16轮迭代、四路专家审查，最终长出了一套可以给任何 WorkBuddy 做配置体检的自动化工具。
🔴 起点：那个卡死的下午
时间： 2026年5月12日 上午 9:42
发生了什么：
桔子打开 WorkBuddy，发了一条指令。屏幕上出现：「正在思考… 正在生成答案… 正在压缩上下文…」
等了10分钟，没动。半小时，还是没动。一两小时后，仍无任何响应。
第一反应是什么？
配置问题？模型抽风？网络故障？
这三个猜测都是错的。
🔍 诊断：不猜，去看日志
Artoo（WorkBuddy AI）的做法：直接读运行日志，不靠猜测。
09:42:26 正在压缩上下文... tokens=100202/100000 ← 超限，触发压缩
09:43:45 压缩完成。tokens=100202/100000 ← 压缩后……完全没变
09:43:45 正在压缩上下文... tokens=100202/100000 ← 立刻再次触发
09:43:45 压缩完成。tokens=100202/100000
09:43:45 正在压缩上下文... tokens=100202/100000
...（无限循环）关键发现： 压缩前100202，压缩后还是100202。零变化。
为什么压缩没有用？
展开看根因分析
WorkBuddy 每次对话，会把这些东西自动加载进来：
| 类型 | 内容 | 大小 |
|---|---|---|
| 配置文件 | SOUL.md + AGENTS.md + USER.md | ~32K token |
| 系统内置 | 工具定义 + 规则框架 | ~35–55K token |
| 固定开销合计 | 65–80K token |
WorkBuddy 的压缩机制：只压缩对话历史，不动系统配置。
所以：
- 压缩前：固定开销70K + 对话历史30K = 100K → 触发压缩
- 压缩后：固定开销70K + 压缩摘要5K = 75K，一句新话就再次超限
- → 永远无法逃脱
根本原因：models.json 缺少 maxInputTokens 配置 → WorkBuddy 使用默认100K阈值 → 系统固定开销已接近阈值 → 每次压缩都无效。
结论： 不是配置错，不是 AI 抽风，是 token 配置缺失导致的结构性死循环。
⚡ 修复：两件事，15分钟完成
| 修复项 | 做了什么 |
|---|---|
| 模型配置 | 给4个模型补上 maxInputTokens（各模型真实上限的60%） |
| 配置文件瘦身 | 把 32KB 的配置精简到 13KB，把详细规范移到「按需加载」的参考文件 |
修完，死循环解除。
💡 转折：修好了之后，桔子问了这个问题
「能不能有一个工具，提前发现这类问题——不是等出了事才知道？」
这一问，催生了 workbuddy-auditor。
值得学习的思维方式
从「修好」到「永远不会再出这个问题」 — 这是一次思维跃迁。
普通路径：出问题 → 找原因 → 修好 → 继续
更高效的路径：出问题 → 找原因 → 修好 → 建立机制，让这类问题消失
🛠️ 设计：把想法变成真正能用的工具
第一轮：用学术框架定义「好配置」
不靠感觉，先调研。桔子要求 Artoo 检索了现有的评估方法论：
| 框架 | 核心思路 | 理论来源 |
|---|---|---|
| 五维约束检测 | 5类约束逐项推理，找违规 | SlsDetector (TOSEM'26) |
| 影响链路分析 | 追踪「配置→行为→结果」因果链 | Pearl 因果推断 |
| 帕累托边界 | 三目标空间同时优化 | NSGA-II 多目标优化 |
| 反事实评分 | 问「删掉这条规则会怎样？」 | Rubin Causal Model |
| 信息效率比 | 有用信息 ÷ 总token | Shannon 信息论 |
| 弹性审计 | 5种压力场景注入测试 | Chaos Engineering |
这里用到了桔子自制的「Scrapling 策略工具箱」： 一个可以用静态/动态/无头浏览器三种模式抓取任何网页的 Skill。研究阶段通过它获取了 SlsDetector 论文摘要、LCWMS 规范文档等学术内容，并抓取了多个 Agent 配置最佳实践页面作为参照。
决策： 五维检测为主引擎 + 信息效率比为总览指标 + 影响链路为解释层。
第二轮：6种方案并排比较，用 Agent 指令一次生成
在确定了检测框架后，桔子没有让 AI「出一个方案」，而是用了这样的指令结构：
以我当前的配置逻辑与标准作为基线，生成一份自检工具。
我不确定如何做会比较好，请生成6种完全不同的方案——
信噪比、可解释性、可非侵入性、先验性都要有差异——
放在一个 HTML 文件里用网格排列，让我能并排比较。
每种方案标注它做了什么取舍。为什么这样写指令：
- 「基线定义清晰」→ 以当前配置为基准，不是泛泛评估
- 「强制化差异」→ 4个维度必须不同，不接受换词版本
- 「多维约束」→ HTML + 网格排列 + 每个方案标注取舍
第三至十六轮：从本能质疑到专家轮番拆解
这段时间的主旋律是：不要相信第一感觉。
写出第一版之后，桔子没有放行，而是用自然语言不断逼问：
「你现在是自己评自己，你怎么知道分数是准的？」
「如果10个同类问题集中在一个维度，会不会把其他维度的权重挤掉？」
「遇到不确定的项，不能只有对和错——你怎么处理边界情况？」
每一个质疑都会变成一轮检查：提问 → AI 找漏洞 → 发现问题 → 修复 → 再提问。不靠感觉，靠追问结构把问题逼出来。十几轮下来，工具的骨架越来越清晰。
然后，把审查这件事本身做成了一个可重复的结构。
通过 WorkBuddy 的专家模式，桔子分别邀请了四种视角参与评审——就像给工具做了一场四路会审：
| 专家角色 | 主要发现 | 改了什么 |
|---|---|---|
| 工具评估专家 | constraints.md 标题维度数写错；scoring.md 计数遗漏多项；输出示例与评分体系不同步 | 全部修复，保持输出一致 |
| 数据分析专家 | 10个同类小问题会「吃掉」其他类型问题的权重 | 改为按类型独立递减算法 |
| 性能测试专家 | C6-C9 检查项依赖 AI 主观判断，Flash 模型不确定时会乱给分数（评分仅 61%） | 引入三态判定：✅违规 / ❌不违规 / ⚠️可疑（疑罪从无） |
| 安全专家 | API Key 可能随报告泄露；修复建议可能误改关键配置（8项风险） | 加入脱敏机制、修复建议白名单、强制 diff 预览后确认 |
最后，用**达尔文技能优化器（Darwin Skill）**对工具本身做了一轮独立评分——让 AI 评估 AI 写的工具，绕开所有人工偏差。这一步是整个迭代链路的封底：前面所有改动都是人工发起的，达尔文提供了一个可重复验证的客观基准。
三轮自主优化，分数从 84.8 → 88.5
每轮只改一个维度，改完后由独立评分器打分，不涨分就回滚：
| 轮次 | 改了什么 | 分数变化 |
|---|---|---|
| R1 | 工作流步骤全部连续编号，更直觉 | +1.5 |
| R2 | 关键决策点加暂停确认，有拒绝 fallback | +0.7 |
| R3 | 模糊描述改为精确匹配规则（8个关键词 + 4文件归属口诀） | +1.5 |
📊 最终产物：一份配置体检报告 + 可操作的优化建议
运行 workbuddy-auditor 后，你会得到一个暗色主题的 HTML 报告，包含：
┌─────────────────────────────────────────┐
│ 配置自检报告 v2.1 │
│ ⚠ 保密 — 含系统配置信息 │
├──────────┬──────────┬────────┬─────────┤
│ 正确性 │ 效率 │ 综合 │ 帕累托 │
│ 99/100 │ 99/100 │ 99 │ 高效区 │
├──────────┴──────────┴────────┴─────────┤
│ 7维度条形图：V1 V2 V3 B1 B2 C1 S1... │
├────────────────────────────────────────┤
│ P0 违规（致命）：0 项 │
│ P1 违规（重要）：0 项 │
│ P2 违规（优化）：2 项 ⚠️可疑 │
├────────────────────────────────────────┤
│ 修复建议（按 P0 → P1 → P2 优先级） │
│ · 每条建议附具体修改方案 │
│ · 含预期效果说明 │
│ 操作：[预览] [逐条确认] [备份] │
└────────────────────────────────────────┘检查范围：46项指标，7个维度——包含 V1（maxInputTokens 配置）这个最关键的防死循环检查项。
报告不只是打分。最后一节是可操作的优化建议清单：按 P0 → P1 → P2 优先级排列，每条建议说明「改哪里、怎么改、改完会有什么效果」。你不需要猜该动什么，照着做就行。P0 问题执行前会强制 diff 预览，避免误改关键配置。
🎯 给你的启发：什么时候值得把问题做成 Skill？
从这个案例抽象出来的判断框架：
满足以下3条，就值得 Skill 化：
| 条件 | 说明 |
|---|---|
| ① 会反复发生 | 一次性的问题不值得建工具，同一个坑踩第二次就该 Skill 化了 |
| ② 有明确的「对」和「不对」 | 纯靠感觉判断的不适合，能写成检查规则的才适合 |
| ③ 多步骤、容易遗漏 | 三步以内靠记性就行；五步以上、有分支的做成 Skill 大幅降低出错率 |
从问题到 Skill 的路径：
遇到问题，读日志/找根因（不猜）
↓
修好之后，问：这类问题还会再来吗？
↓
描述清楚「好的状态是什么样的」→ 这就是检查标准
↓
让 AI 按这个标准帮你定期检查 → 这就是你的 Skill更好的 Skill 设计原则（从本案例提炼）：
- 自包含：所有信息说清楚，换一个人用也能得到同样结果
- 按需加载：常用规则放主文件，详细参考放附属文件，不淹没 AI 注意力
- 三态判定：不只是「对/错」，加入「可疑（人工核查）」，降低误判率
- 不可逆操作必须预览确认：修改文件前先 diff，逐条确认，自动备份
🔗 相关工具
本案例使用的工具：
- Scrapling 策略工具箱 — 研究阶段抓取学术内容和标杆案例
- 配置自检工具（WorkBuddy Auditor） — 本案例的最终产物
- 达尔文技能优化器 — 用于 Skill 的自主优化评分
案例来源：CASE-001（上下文压缩死循环诊断）+ CASE-002（workbuddy-auditor 创建流水）| 2026-05-12