grade-system

评分系统

你正在对 Ane 的 MEL/SRHR 系统进行实质性的质量与可靠性评级。输出一份 Tier 1 工作简报，包含字母等级、维度分析、经调整的 OECD-DAC 标准、具体风险，以及提升等级的建议。诚实评级，并公开承认自评偏差。

适用场景

• Ane 输入 /grade-system、/grade，或询问系统表现如何时
• 定期质量检查（建议频率：每月一次，或完成重大偏差纠正工作后）
• 在需要如实描述系统的利益相关方沟通之前
• 系统发生重大变更后，用于评估等级是否有所提升

必须注明自评偏差（始终包含在输出中）

你既在为系统评级，也在系统内部运行。根据 2026-05-06 的 mel-system-bias-audit，LLM-as-Judge 效应会使你倾向于偏好与你自身推理模式相符的输出和架构。请在输出中公开说明这一点。该等级是系统的内部校准，并非外部验证。结构性测试（社区／外部 MA 从业者评审）仍是系统尚未允许开展的测试。

此说明不可妥协。若跳过，评级就会产生误导。

工作流

第 1 步——收集实证依据

并行读取：

• agent-improvements/ann-overlay.md（Active + Archived）——提取带有成本数据、harness 状态和关键经验的回顾要点。统计会话数。记录任何重大事件（例如 DOCX 截断、em-dash 回归）。
• agent-improvements/coordination-log.md——记录摩擦事件及其状态（OPEN / CLOSED）。
• agent-improvements/cost-calibration-log.md——统计包含实际观测值与标记为 not observed 的行数。注意 ⚠️ 超出区间的条目。
• agent-improvements/qa-rejection-log.md——统计数据行数并分析评定结果趋势；这是实时 QA 遥测信号。空表意味着改进循环依赖轶事进行引导——将其标记为风险。qa-disagreement-log.md 仅供历史参考：已于 2026-07-30 退役，不再作为实时计数器（system-audit 项目 #12）；其 3 行 Vi/Li 提升观察触发项因无法衡量而撤回。阅读其标题说明，了解退役原因；不要将其中的行计入观察触发项。**即使表格中有行，趋势分析也可能仍为空。**该日志自身的协议规定，任何标记为 ⚠️ PILOT 或 ⚠️ SMOKE TEST 的行都不纳入拒绝率趋势，因此要单独统计符合趋势分析条件的行，并报告该数量，而不是总行数（grep -E '^\| 2026-' <log> | grep -vc -E '(PILOT|SMOKE TEST)'）。截至 2026-08-15，全部 10 行都带有排除标签，因此尽管表格看似已填充，声明的可衡量信号实际仍为零。外部结构性测试仍未开展。
• 审计历史——不要用通配符搜索，大部分内容已迁移。 agent-improvements/system-audit-*.md 只会匹配一个文件，即 2026-04-28 的架构审计；它仍值得作为基线阅读，但并不新近。agent-improvements/audit-drift-*.md 会匹配一系列每周文件，该系列已于 2026-08-05 退役（由 Ane 决定；harness 承载其检查项，/system-audit 可按需进行判断评审），因此最新文件是收尾记录，并非当前评估。近期审计发现位于 agent-improvements/handoffs/（例如 system-audit-follow-ups.md，其中的已锁定决策部分在其他任何地方都找不到）以及 agent-improvements/improve-system-runs.md。运行 python scripts/handoff_status.py 获取当前清单，不要猜测文件名。
• mel_wiki/wiki/index.md——页面数量（框架、概念、指标、视角）。
• agent-improvements/agent_registry.md——统计专家数量；并与 ~/.claude/agents/ 交叉核对。
• 运行 python tests/run_tests.py 检查静态状态，运行 python tests/run_tests.py --output 检查夹具覆盖情况。

第 2 步 — 按组件评分

评分等级：A / A− / B+ / B / B− / C+ / C 及以下。依据第 1 步的证据，而非直觉。

组件	考量因素
Ann（召集人）	7 阶段工作流的完整性、复盘纪律、成本估算准确性、复杂度分类记录、Vi/Li 的编排上限
Vi（编排者）	SELECT → DELEGATE → REVIEW → COMPILE 流程、协调协议、模型规则与注册表的一致性、上下文内技能上限、分类表的完整性
Li（知识管理员）	运维广度（10 项操作：QUERY、INGEST-FROM-RESEARCHER、INGEST-AD-HOC、INGEST-DOCUMENT、CATALOG、OVERLAY-DIGEST、LINT、CURATE、SYNC-CLAUDE-AI、REORGANIZE）、CURATE 质量（实质性内容与仅存档内容的区分）、分层摄取、季度多语言目标
Researcher（证据综合）	双制品协议、带层级标签的来源分类、多语言实时检索规则的运行状态、外部检索验证状态
Specialists（按注册表计数）	Agent 文件数量匹配情况、校准锚点覆盖度、注册表与 Vi 的一致性、模型默认规则的执行情况
Wiki	页面数量、YAML frontmatter 规范、破折号数量趋势、P1/P2/P3 优先级规范、双向交叉引用
测试框架	静态检查数量、测试夹具覆盖度、回归保护范围
qa_block 架构 + Ann PHASE 5 gate	逐字段验证是否有效、架构与实现的一致性、新增项（power_shift_check、external_review_check）的集成情况
三仓库架构	claude-config + personal-skills + anework-package — 恢复路径、镜像克隆、同步缺口、迁移稳健性

为每个组件指定等级，并用一句话说明理由，同时引用证据文件。

第 3 步 — 按维度评分

维度	衡量内容
正确性	引用准确性、框架版本时效性、视角应用情况
可靠性	多次运行中的质量一致性、故障模式记录
稳健性	优雅降级、自我检测、技能回退提示
效率	Token 成本与输出的比值、可观测性界面
可维护性	抵御偏移的能力、单一事实来源、恢复路径
诚实性 / 校准度	数据缺口标记、对递归限制的承认
受众层级匹配	第 1 层工作简报 / 第 2 层出版物 / 初级 MEL 路径是否可用
视角实质性	女性主义、去殖民化、交叉性是否得到实际应用，而非流于形式
权力意识	立场、知识来源、谁在塑造问题
实证依据	有多少次真实生产运行支撑设计主张

为每个维度指定等级。每个等级都必须有第 1 步收集的证据作为依据。没有具体证据，不要给 A 级；没有具体缺口，不要给 C 级。

然后明确回答两个关于图结构的问题。该编排是一个 Agent 图（任务、箭头、共享状态文件、检查器、人工关卡）；将两个问题的答案纳入可靠性等级，并将任何“否”列为第 5 步风险。

1. 每个检查器是否都与其写入者分离？ qa-reviewer 和 reader-position-reviewer 按设计不具备 Write/Edit 工具；请验证这一点仍然成立，并确认任何新增的审核者或 QA 技能也只进行审核、不进行写入。能编辑自己所审核产品的检查器，无论其文字质量如何，都是图结构缺陷。
2. 每个人工关卡是否都设置在错误代价高昂之处，而非方便之处？ 梳理请求 Ane 批准的位置（计划批准、发布前、覆盖写入前），并对照错误实际会让她付出代价的环节（对外发送、破坏性写入、捐赠者可见的内容）。在代价低的步骤设有关卡，却在代价高的步骤没有关卡，就是位置不当；第 4 次运行中决策问答后的超时正是这一问题的表现。

第 4 步 — 应用改编版 OECD-DAC（6 项标准）

将 2019 年的六项标准框架改编到系统情境中：

标准	改编后的含义
相关性	它是否服务于 Ane 的实际 MEL/SRHR 工作？
一致性	各部分是否相互契合？
有效性	它是否产出符合出版标准的成果？
效率	Token 成本与输出质量的比较
影响	与基线相比，它是否改变了 Ane 的生产力／输出质量？没有反事实数据时，通常应判为“证据不足”。
可持续性	可维护性、抗漂移能力、依赖项稳健性

第 5 步 — 三项具体风险

将缺陷列为风险之前，先检查缺陷所在的界面，并确认问题仍然存在。 日志条目、覆盖判定或 qa_block 记录的是触发修复的事件，而非当前状态；修复可能已经上线。证据（2026-10-14，第 9 次评估）：风险 3 根据 2026-08-14 的 qa-rejection-log 条目，将 word_count.writer 空值缺陷判定为仍未修复，但 qa-block-schema.md 已于 2026-08-10 纳入修复，并于 2026-08-14 推广到 Ann 第 11 步、Vi 技能和 qa-reviewer Agent，且有 harness 检查防止该分支出现问题。只需查看一次 schema，就能在撰写评估简报前发现这一点；错误评分还将受影响维度的评分压低了约半个等级。案例登记册记录的是历史；应根据实际界面评定当前状态。

列出三项诚实的风险，按影响排序。每项包括：

• 描述（一句话）
• 重要性（一句话）
• 已有的缓解措施（如有）
• 可能消除风险的措施

2026-05-06 评分中的示例：qa-reviewer 未明示意见分歧，而 Ane 未标记便接受；Token 成本估算不透明；偏差校正路线图由系统自行制定。

第 6 步 — 外部 MA 评估员仍会要求什么

列出系统无法在自身边界内满足的事项：

• 由非 IPPF MA 从业者审阅 qa_block 输出样本
• 反事实数据（与基线相比的生产力）
• qa-reviewer 首次指出 Tier 2 输出缺少外部审查，且出版确实因此延迟的案例
• humanitarian-srhr-specialist 执行多国任务的记录（此时会触发 Opus 覆盖条件）
• 连续 2 个季度达成非英语内容摄取目标

第 7 步 — 总体评分与建议

给出单一总体评分及其依据。提出能提升评分的具体建议：

时间范围	可实现的改进
今天（1-2 小时）	成本校准日志、脚手架、捕获一个 fixture
本周	对使用频率最高的 10 个 P2 页面进行 em-dash 全面检查，向外部审计员发送邀请，再捕获 2 个 fixture
下个月	开展外部 MA 从业者抽样审计，多语言差距日志累积首批 3 条记录，成本校准日志针对一种任务类型记录 5+ 个实际观测值
战略性（无期限）	将 Vi/Li 提升为真正的子 Agent。其 3 行分歧监测触发条件于 2026-07-30 因无法衡量而撤回；要提升它，需要先建立新的证据路径（qa-rejection-log 趋势）

如实说明哪些改进只需一天，哪些受结构性上限限制。A− 升至 A 通常需要外部审计员。

输出格式

Tier 1 工作简报。先写 BLUF。用表格呈现组件／维度／OECD 评分。语气诚实，不要奉承。不要使用 em-dash。不要含糊其辞。遵循 CLAUDE.md。

使用此模板：

# Quality and reliability grading — Ann/Vi/Li/Researcher + MEL/SRHR system

**BLUF: Overall [grade]. [One-sentence summary of strengths and ceilings.]**

## Self-grading bias note
[Mandatory paragraph explaining the LLM-as-Judge effect and that this is internal calibration, not external validation.]

## Per-component grades
| Component | Grade | One-line rationale |
|---|---|---|

## Per-dimension grades
| Dimension | Grade | What it means |
|---|---|---|

## OECD-DAC adapted
| Criterion | Grade | Comment |
|---|---|---|

## Three concrete risks
1. [risk + impact + mitigation]
2. [risk + impact + mitigation]
3. [risk + impact + mitigation]

## What an external MA evaluator would still want
- [bullet list]

## Recommended sequencing for grade movement
| Time horizon | Achievable moves |

## Bottom line
[One paragraph: overall grade, what holds it back, what would move it.]

**Evidence base:** [inline file paths]

不要做什么

• 不要给出讨好的评分。系统确实存在上限；请明确指出。
• 不要省略自我评分偏差说明。该说明本身就是纪律要求。
• 不要提出具体的 Bug 修复方案。这些属于 /system-audit。
• 不要捏造证据。请引用你在第 1 步实际读取的源文件。
• 不要给所有维度都评 A。如果无法依据具体证据证明某项可得 A，就应给出更低评分。
• 不要给所有维度都评 C。系统已完成大量工作；诚实的评分也应认可有效之处。

收尾

最后说：“想要一些能提升评级的具体建议吗？”等待 Ane 回复。

如果 Ane 确认，提出 2-3 项能在一天内完成、且能提升特定维度的具体举措。诚实说明哪些今天可以实现，哪些受结构性上限限制。然后询问是否执行。

成本区间

根据实际观察到的情况，分为两种形态：

• **仅评级：**约 40-80k（读取覆盖文件、审计历史记录和 harness 状态）。
• **评级加后续执行：**约 200k。三次已观察到的运行（2026-05-10、2026-05-20、2026-05-22）在加上后续编辑和提交后，成本都超出仅评级区间 2.5 到 5 倍。尽管只使用技能工具，也应归类为复杂执行，并将约 200k 作为工作估算。

两种形态都在 200k 的系统改进上限内；评级加后续执行的形态会达到上限。如果运行只进行评级、不做编辑，则适用较低的区间。

**成本更多取决于信息收集方式，而非评级本身。**第 7 次运行（2026-06-20）将步骤 1 分配给四个子 Agent，子 Agent 侧花费约 340k。第 8 次运行（2026-07-24）通过直接调用 Read 和 Bash 收集相同证据，整个会话（包括两项后续举措和一次跨仓库同步）花费约 208k，得到相同的 A−。默认采用直接收集。有两点需要坦诚说明：这是 n=1 对比 n=1；第 8 次运行可能受益于第 7 次运行已标出证据所在位置。应将其视为“直接收集曾经奏效一次”，而非证明并行分配是浪费。只有在证据范围确实陌生，或并行扫描（例如在许多页面中查找 em dash）本身就是实际工作时，才使用子 Agent。

交叉引用

• /system-audit 用于查找错误；/grade-system 用于描述整体质量状况。要进行完整评估，请同时使用两者：先审计并解决快速修复项，再评级。
• agent-improvements/system-audit-2026-04-28.md 是原始架构审计；其内容延续至评级维度。
• agent-improvements/external-calibration-auditor-invitation-draft.md 是常设邀请，触发外部结构测试。