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