원클릭으로
reliable-model
当创建、修改、解释、诊断或验证模型、规则、评分系统、预测、参数选择、机制假设或研究结论时,请使用此技能。它要求同时具备先验依据与实证验证来评估可靠性,并区分可靠结论与黑箱相关性、空洞叙事、事后线索及不可靠主张。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
当创建、修改、解释、诊断或验证模型、规则、评分系统、预测、参数选择、机制假设或研究结论时,请使用此技能。它要求同时具备先验依据与实证验证来评估可靠性,并区分可靠结论与黑箱相关性、空洞叙事、事后线索及不可靠主张。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
当生成或探索性工作可能失败、需要多次尝试、涉及众多约束、需要验证,或会产生不应污染主 Agent 上下文的中间发现时,主动使用本技能。 本技能运行一个整洁的主智能体循环:主 Agent 只负责协调,将上下文导出到文件,派发创建者/审查者 SubAgent,将重试过程留在主上下文之外, 并且只接收工件路径以及 PASS / RETRY / FAILED 审查说明。
用于每一项编程任务,以控制流程复杂度。对于任何创建或修改代码的任务,还应使用 clean-agent 协调模式,让创建者和审查者 SubAgent 将 clean-code 作为共同的代码规范。它强制执行复杂度门禁,将每个分支视为新增的逻辑路径,要求有明确的业务理由,尤其适用于实现和代码审查。
每当用户要求编写、重写、缩短、澄清、审查、润色、重构或改写文档及任何面向人类的说明性文本时,请使用本技能。对于任何创建或修改文档的任务,还要使用 clean-agent 协调模式,使创建者和审查者 SubAgent 将 clean-doc 作为共同的沟通规范。它把信息转化为针对特定受众和决策情境的目标导向型沟通,优先考虑读者的语言和风格,并且只保留与决策相关的信息。
强制执行 CZ 的 Git 和 GitHub 交付风格,包括 gitmoji 提交、受保护的 main、仓库本地 worktree、仅 Squash 的 Auto Merge、拉取请求监控、GitHub Actions 验证和安全清理。每当 Codex 设置或更新 GitHub 仓库、创建功能 worktree、准备或发起拉取请求、跟进拉取请求直至合并并完成 Actions,或执行相关 Git 工作流时,都应使用本技能。
当代码运行缓慢、超时、被终止、消耗大量 CPU、执行长时间批处理作业、进行参数扫描、训练模型、处理大型数据集、运行模拟,或目标规模运行时间未知时,使用本技能。它指导智能体逐步探测运行时间,在可行时进行在线 N-T 进度插桩,采用固定超时采样,执行 N-T 扩展估算,并在尝试目标规模前作出全规模运行的通过/不通过决策。如果进行了优化,它要求保留慢速版本的规范输出,证明语义逐字节等价,并在通过并行投入更多 CPU 前优先消除无效工作。本技能不封装性能分析工具,也不提供通用优化方案;它负责判断应全规模运行、停止,还是转入性能分析和原则性优化。
当任务涉及困难推理、原因不明、无法解释的观测、失败的假设、模糊诊断、复杂系统、涌现行为、调查规划,或当前解释空间不完整的任何情形时,请使用此技能。此技能应用递归残差推理:将尚未解释的内容保留为显式残差,把该残差扩展为下一个推理空间,并生成一条从观测到结论、行动或有界停止原因的可追踪路径。
| name | reliable-model |
| description | 当创建、修改、解释、诊断或验证模型、规则、评分系统、预测、参数选择、机制假设或研究结论时,请使用此技能。它要求同时具备先验依据与实证验证来评估可靠性,并区分可靠结论与黑箱相关性、空洞叙事、事后线索及不可靠主张。 |
使用此技能判断一项模型主张是否源自可靠的过程。这里的可靠性是指认知可靠性:结论更有可能在产生它的观测之外仍然成立。
核心规则:
可靠模型 = 先验依据 + 实证验证
简要表述:
解释防止黑箱。
验证防止空洞叙事。
将此技能用于涉及以下内容的任务:
按以下顺序工作:
观测或目标
-> 先验依据
-> 模型或解释设计
-> 实证验证
-> 双支柱可靠性判断
-> 结论等级与残余风险
不要先查看结果、指标或局部改进,再编造一个听起来自然的解释。如果已经看过结果,应将该解释标记为事后解释,并降低结论等级,直到它获得有力的独立依据或独立验证。
先验依据回答:
在看到结果之前,为什么这个模型应当合理?
创建、更改或解释模型时,应陈述:
如果唯一理由是“结果有所改善”,那么这个想法还不能算作可靠模型。应将其视为事后线索。
实证验证回答:
该模型在可能推翻它的检验中是否确实有效?
不要依赖单个有利结果。根据具体情况检查:
有力的验证必须可证伪:说明哪些证据会削弱或否定模型、哪些失败必须披露,以及何时应下调模型等级或重新估计模型。
分别判断两个支柱。
| 状态 | 先验依据 | 实证验证 | 判断 |
|---|---|---|---|
| 黑箱模型 | 弱 | 强 | 结果可能有用,但机制尚不明确。暂时不要称其为可靠模型。 |
| 空洞叙事模型 | 强 | 弱 | 解释合理,但证据不足。应将其视为假设。 |
| 低可靠性模型 | 弱 | 弱 | 机制和证据都不充分。不要推进该主张。 |
| 可靠模型 | 强 | 强 | 模型事先看来合理,并经受住了实证检验。 |
绝不要用实证成功替代先验依据。也绝不要用听起来合理的故事替代验证。
当用户要求创建或更改模型时,使用以下结构:
1. 目标或现象
2. 先验依据
- 机制假设
- 输入、结构、规则和参数的来源
- 决策时可用的信息
3. 模型设计
- 规则或模型行为
- 范围与边界
- 预期改进与可能的退化
4. 实证验证计划
- 样本外或独立验证
- 细分群体、时间窗口或上下文稳定性检查
- 指标、基线、消融和失败案例审查
5. 可靠性关卡
- 先验支柱是否足够有力?
- 验证支柱是否足够有力?
- 泄漏或选择偏差风险是否已受控或已披露?
6. 结论等级
如果任务需要修改代码,也应在实现之前识别先验依据和验证计划。不要把事后选择编码成仿佛一开始就确定的设计原则。
将解释分为三类:
已知机制:在看到此结果之前已有支持。
事后候选解释:在看到此结果后提出;有用但尚未证实。
残差:当前解释空间尚未解释的部分。
然后报告:
1. 观测到的现象
2. 可用的先验机制
3. 候选解释与可证伪预测
4. 支持性证据与反面证据
5. 尚未解释的残差
6. 后续验证步骤
不要把每项解释都当作已确定的原因。应明确标记事后推理。
先验支柱:
验证支柱:
研究过程:
使用明确的结论等级:
| 等级 | 条件 | 允许的表述 |
|---|---|---|
| 可靠模型 | 先验依据充分、验证有力且没有未受控的泄漏 | 在所述边界内,机制合理性与实证结果均已得到确认。 |
| 候选模型 | 一个支柱有力,另一个尚不完整但可检验 | 很有前景,但仍需更多依据或独立验证。 |
| 事后线索 | 主要在看到结果后发现 | 有用的诊断信号;单凭这一点并不可靠。 |
| 假设 | 解释有力但数据不足 | 合理的机制,等待实证确认。 |
| 不可靠模型 | 两个支柱都薄弱,或泄漏使证据失效 | 在重新设计之前,不要推进该主张。 |
可接受:
此规则有明确的先验机制,实证验证也提供了确认性证据。剩余风险包括选择偏差、边界条件以及已测试范围之外的失败案例。
可接受:
这是一个积极的事后线索。它提示了一种可能的机制,但在获得更有力的先验依据或独立验证之前,还不能算作可靠模型。
避免:
指标有所改善,因此模型是可靠的。
避免:
这个解释听起来合理,因此不需要验证。
避免:
该模型可以在决策时执行,因此研究过程不存在偏差。
目标不是让解释更漂亮,也不是让指标更好。目标是使模型结论可解释、可检验、可复现,并如实说明其失效边界。