omk 为谁做、解决什么问题
这是 omk 的定位说明。在读架构、统计、三阶段之前，先讲清楚 omk 帮谁做什么决策，以及这些决策在什么范围内成立。所有设计决策（默认值、存储归属、命令形态）最终都应该能回溯到这一篇。
一句话
Observe. Measure. Know. OMK 让 AI 应用的知识改动有据可依。它不为知识给出脱离上下文的统一质量分，而是帮助需要承担改动后果的人，在明确的目标用户、任务、模型和验收标准下，判断一次知识改动是否带来了值得发布的增量价值。
先明确：不存在脱离上下文的「好知识」
人们对知识的理解、偏好和要求天然不同。同一份 prompt / RAG / skill / agent / workflow，可能适合新手却打扰专家，可能在一种模型上有效却在另一种模型上退化，也可能提高质量但增加了无法接受的成本。
因此，评测结论必须依附于一份明确的评测契约：
- 为哪些用户和任务评测；
- 使用什么模型、runtime 和环境；
- 用哪些用例、断言与人工 gold 表达预期；
- 对成本、延迟、安全性和稳定性有哪些约束。
这份契约不一定对应单独一个配置文件，而是由项目的用例集、运行配置和发布门禁共同构成。评测用例不是中立的真理，而是这份契约的可执行表达。omk 不消除人与人之间的标准差异；它把标准和适用范围显式化，再让同一契约下的版本改动可以比较。报告里的「可以发布」准确含义是：在当前模型、评测用例和验收标准下，现有证据支持发布。
解决的问题：两个不同决策
「好不好」通常混合了两个需要分别设计评测的问题。
改动有效性 —— 这次改动是真进步，还是噪声？ 你改了一版知识输入，新版分更高，但这是真实增益，还是评测本身的随机波动？omk 用 Bootstrap 置信区间、长度去偏，以及配人工 gold 时的 Krippendorff α，给出带不确定性的 verdict，而不是两个孤零零的分数。
增量价值 —— 对目标用户和任务而言，这段知识值不值得维护？ 一个 baseline-vs-skill 对比可能测的是「必要性」（模型缺少这块知识），也可能测的是「实现质量」（这份 skill 是否有效表达了它）。如果模型本来就会，写得再漂亮的 skill 也未必产生增量价值；如果用例不代表目标任务，显著提升也不能外推。这是 construct validity 问题。（详见用例设计科学性指南。）
这两个问题可以复用同一套测量基础设施，但不能被压成一把万能尺子。作者发布新版时主要关心改动有效性；采纳方决定是否引入外部知识时更关心增量价值。
第一条工作流
omk 的第一条工作流，是知识载体的发布前闭环：
改了一个 skill / prompt / agent artifact
→ doctor：结构、依赖、可测性是否过关？
→ eval：在当前评测契约下是否获得可信增益，并且没有违反约束？
→ report / Studio：证据适用于哪里、失败在哪里、付出了什么代价？
→ 决定发布 / 不发布这是主干。observe 在有真实使用记录之后很重要，但它不是 omk 第一价值的前提。凡是能让 doctor 和 eval 在这个有明确上下文的发布时刻更可信的方向，都应该优先于只增加一个新展示面。
当前为谁做：两个待验证的目标人群
主要目标：需要持续发布知识改动的作者和维护者。 不是所有写过 prompt 的人，而是知识载体会被重复使用、多人共享或持续版本化，并且错误改动会带来回归、额外成本或运行风险的人。他们需要回答：「这次改动对目标任务是真进步吗，值得发布吗？」
第二目标人群：需要承担采纳后果的团队和平台维护者。 他们决定是否引入、保留或升级外部知识输入，不能只相信作者自带的 benchmark，而要用自己的任务、约束和用例重新评测，并把「采用了什么、依据什么」沉淀成可追溯的决策档案（见证据门控管理）。
明确不是为谁做的：被动使用者。 从公开源安装一个 skill 并直接使用的人，通常没有用例集和测量意图，评测对他只是额外负担。omk 不要求这个人群承担评测工作。评测产物默认落在评测者的项目工作区，而不是被动使用者的安装目录。
这里描述的是 omk 的产品假设，不是已经被市场证明的事实。尤其是团队治理是否会成为第二支柱，取决于真实团队是否愿意建立自己的评测契约并持续使用，而不是文档能否把逻辑讲通。
什么才算需求得到验证
有人认同「知识改动应该有证据」，不等于他愿意投入时间做评测。更强的产品信号是：
- 维护者愿意拿一个正在发生的真实改动，而不是演示样例来评测；
- 他愿意创建或复核代表自己要求的用例；
- 报告中的证据实际改变了发布、回退或补用例的决定；
- 下一次改动发生时，他会主动再次运行 omk。
这篇文档只能说明 omk 认为谁应该受益。这些人是否真的在意到愿意承担评测成本，必须由持续复用来验证。产品优先级应该先服务能出现上述行为的人，而不是为一个逻辑上可能存在、实际上尚未出现的人群扩建功能。
三阶段分别服务谁
omk 的 doctor / eval / observe 三阶段，人群覆盖面不一样：
- doctor（检查）：发布前健康门禁。作者在相信 eval 前先跑；采纳方也可以用它排除结构、依赖和可测性问题。
- eval（评测）：发布判断核心。它需要评测契约和测量意图，所以属于作者迭代与采纳决策；被动使用者不需要运行。
- observe（观测）：发布后的反馈闭环。它从真实 session trace 里发现现有契约没有覆盖的知识缺口，反哺下一轮用例，但不能替代受控 eval，也不应该成为新用户第一步必须理解的入口。
边界：omk 不做什么
- 不提供通用知识质量排名。 不同用户和任务可以得到不同结论；omk 比较的是明确契约下的版本，不是跨场景的绝对高低。
- 不把结论外推到评测契约之外。 用例没有覆盖的人群、任务、模型和约束，报告不能替你作出承诺。
- 不独立裁定知识真伪。 omk 不提供独立的真理来源，也不替你裁定一段知识本身是否正确；它依据你给的用例、断言和 gold 衡量结果。事实正确性可以测，但标准由你提供。
- 不服务被动使用者。 见上。
- 不在变量里掺模型。 固定模型、只变知识载体，才能把差异归因到知识本身。这是「可比」的前提，不是限制。