omk 为谁做、解决什么问题
这是 omk 的定位说明 —— 在读架构、统计、三阶段之前，先讲清楚 omk 是给谁用的、替他们解决什么。所有设计决策（默认值、存储归属、命令形态）最终都该能回溯到这一篇。
一句话
omk 把「一段知识输入（prompt / skill / RAG / agent）好不好、能不能发布」从拍脑袋、口头判断，变成可比的、带证据的决策 —— 先检查 artifact 是否值得测，再固定模型、只变知识输入，用统计严谨的尺子量出差异。
解决的问题：两层
「好不好」其实是两个叠在一起的问题。
下层 —— 改动是真进步，还是噪声？ 你改了一版 prompt / skill，新版分更高，但这是真的变好，还是评测本身的随机波动？这是最常被问、也最好懂的那句：「你改完，真的变好了吗？」omk 用 Bootstrap 置信区间、长度去偏、（配人工 gold 时）Krippendorff α 给一个带不确定性的 verdict，而不是两个孤零零的分数。
上层 —— 这段知识到底有没有用，值不值得有？ 再往上一层：这个 skill 真的让模型变强了，还是模型本来就会、它只是把已有能力换了个说法？一个 baseline-vs-skill 的对比，可能测的是「必要性」（模型缺这块知识）而不是「质量」（skill 写得好）—— 两者都能给出漂亮的 verdict 数字，却回答着不同的问题。这层是 construct validity 问题，决定一段知识值不值得维护下去。（详见 用例设计科学性指南。）
下层是作者每次发布前问的，上层是采纳方 / 平台决定「要不要用、留不留」时问的。omk 的两层尺子，对应两种人。
第一条工作流
omk 的第一条工作流，是知识载体的发布前闭环：
改了一个 skill / prompt / agent artifact
→ doctor：结构、依赖、可测性是否过关？
→ eval：在同一批用例上是否打赢 baseline？
→ report / Studio：下一步具体该改哪里？
→ 决定发布 / 不发布这是主干。observe 在有真实使用记录之后很重要，但它不是 omk 第一价值的前提。凡是能让 doctor 和 eval 在「能不能发布」这个时刻更可信的方向，都应该优先于只增加一个新展示面。
为谁做的
主：知识输入的作者 / 维护者。 在迭代一个 prompt / skill / RAG / agent，需要回答「我这版改动是真进步吗、能发布吗」。omk 的第一承诺是 doctor → eval 的发布准备闭环：先让 artifact 值得测，再和 baseline 对比，看 verdict，然后决定修还是发。
第二支柱：采纳方 / 平台治理团队。 在决定「我们团队要不要用这个外来 skill、该批准 / 留着哪些 knowledge input」。他不信作者自带的 benchmark，拿自己的用例跑一遍再定，并把「采用了什么、凭哪条证据」沉淀成可追溯的决策档案（见 证据门控管理）。这不是附属功能 —— 治理门禁引用的是同一套 eval report 证据结构（reportId），只不过采纳方跑的是自己的用例；是同一把测量学尺子在团队尺度的延伸。
明确不是为谁做的：纯使用者。 从公开源装一个 skill 来用的人，不会去评测它 —— 他没用例集、没测量意图，评测对他是纯负担。omk 不为这个人设拧任何设计。会跑评测、会生成报告的，永远是上面两种人（作者在自己的 skill / benchmark 仓，采纳方在自己的用例仓）。这条直接决定了一件事：评测产物默认落在评测者的项目工作区，而不是任何人的安装目录。
三阶段分别服务谁
omk 的 doctor / eval / observe 三阶段，人群覆盖面不一样：
- doctor（检查） —— 发布前健康门禁。作者在相信 eval 前先跑；采纳方装完也会跑一下「这 skill 是不是坏的」。两边都用。
- eval（评测） —— 发布判断核心。它需要用例集和测量意图，所以属于作者迭代和采纳方采购；被动使用者不碰。
- observe（观测） —— 发布后的反馈闭环。它从真实 session trace 里挖缺口，应该反哺下一轮用例，但不能替代受控 eval，也不应该成为新用户第一步必须理解的入口。
边界：omk 不做什么
- 不独立裁定知识真伪。 omk 不提供独立的真理来源、不替你裁定一段知识本身对不对；它依据你给的用例、断言和 gold 衡量结果 —— 事实正确性能测，但标准由你定。
- 不服务被动使用者。 见上。
- 不在变量里掺模型。 固定模型、只变知识载体，才能把差异归因到知识本身 —— 这是「可比」的前提，不是限制。