💡 深度解析

技能（skill）系统如何将交互经验转化为可复用 artefact？存在什么风险与治理需求？

核心分析 ¶

问题核心：如何把一次性交互转成长期可复用的 skill，同时避免把错误或敏感信息固化下来。

工作方式（依据 README）：OMC 会从会话中抽取可复用的 skill 文件，保存在 .omc/skills/，并在合适场景自动注入，这使得调试经验和修复模式能够被版本化与共享。
优势：
速度提升：复用已有 skill 降低重复劳动并缩短解决同类问题的时间。
一致性：团队共享 skill 有助于保持处理模式一致。
主要风险：
质量漂移：自动抽取的 skill 可能包含不完备或错误的方法，若未经审查被注入会放大问题。
敏感数据泄露：会话中若包含凭证或业务敏感信息，自动持久化会造成泄露风险。
版本兼容性：不同项目/代码库对 skill 的依赖可能导致意外破坏。

重要提示：自动化复用不是无风险的“捷径”，必须配合治理策略才能把收益变为可靠的长期资产。

总结：技能系统是把经验工程化的关键能力，但需要审查、敏感信息防护和版本治理以防止自动化带来的隐患。

87.0%

为什么采用 CLI + tmux 的本地 worker 运行时？这种架构的优势与局限是什么？

问题核心：选用 CLI + tmux 作为执行层，意图实现低运维成本的按需并行 worker，同时避免长期驻留服务带来的资源浪费。

重要提示：tmux 模式降低运维门槛但增加对终端熟悉度的要求，部署前请验证模型 CLI 与 tmux 版本兼容性。

总结：CLI+tmux 是一个面向快速迭代和轻量化运维的合理设计，但需要在企业化场景中补充长期存储、审计与跨平台支持。

86.0%

作为新用户，上手成本和常见部署问题有哪些？如何降低学习曲线并成功部署？

问题核心：项目宣称“零学习曲线”，但实际依赖多项环境与流程配置，这对新用户构成摩擦。

重要提示：在企业环境使用前，务必确认 license 与发布策略，若无明确信息请慎重。

总结：通过封装化安装、模板化示例和小规模试点，可以把上手成本和风险降到可控水平，从而顺利部署。

86.0%

项目所称的“智能模型路由”与并行化如何在实际使用中节省成本与提高效率？

问题核心：如何在保证输出质量的前提下，用不同能力/成本的模型组合来降低整体消耗并提高并行吞吐？

工作机制：OMC 通过任务分解与模型路由，将简单、可模板化的子任务分配给轻量模型（如 Haiku），将需要深度推理的子任务交给强模型（如 Opus）；同时支持并行化执行（tmux panes）和三模合成 /ccg 来汇总不同模型的观察。
节省路径：
减少强模型调用次数：把低复杂度工作用低成本模型处理，降低每次执行的 token 花费。
并行化提高吞吐：并行 worker 处理多个子任务，缩短总作业完成时间。
合成提高单次决策质量：/ccg 可以在关键场景用多模型交叉验证，从而减少后续返工成本（尽管短期 token 使用上升）。
成功依赖项：
准确的任务分类/复杂度判断，以避免把需要深度推理的任务交给轻量模型。
实时成本与质量监控，用于调整路由阈值。
回退与重试策略，当轻量模型输出不满足质量标准时自动升级到强模型。