Research Literature Interpretation

Research Literature Interpretation

把单篇论文压缩成读者能复述、质疑和迁移的解释链：旧方法为何受限，作者改变了什么，机制为何可能有效，证据支持到何种强度，代价和失效条件是什么。

主动取舍比篇幅重要。页码、章节和图表只服务复核，不支配叙事。

范围与文件边界

• 仅处理单篇论文；发现、筛选和去重交给 research-literature-radar，多论文综合交给综述技能。
• 确认标题、作者、年份、venue、版本、DOI/arXiv ID、一手 URL、访问日期和可读范围。版本冲突并列记录，不擅自裁决。
• 优先阅读摘要、引言、结论、方法、关键图表/图注、消融、失败案例、附录和代码说明，再深挖影响结论的部分。只有摘要或图表时，交付证据地图并收缩结论。
• 只用合法可访问的一手材料和可靠跟进来源；不绕过访问限制，不执行未知代码。区分静态阅读、实际运行和作者自报结果。
• 默认写入 docs/papers/<friendly-id>/<friendly-id>.md。已有笔记默认修订或追加，不覆盖用户内容；不改 raw/ 或 .bensz-api/research-literature-radar/catalog.jsonl。中间材料放本轮 .bensz-api/。

流程

输入

按用户请求和配置文件提供必要输入；缺失信息应明确列出并停止依赖该输入的步骤。

执行步骤

• 仅将本 Skill 的设计缺陷（流程漏判、输入契约不完整或环境假设错误）视为可上报 bug；用户数据错误、第三方服务抖动、用户主动改源码和模型偶发波动不属于此范围。
• 发现设计缺陷时先脱敏记录到 ~/.bensz-skills/bugs/，当前任务继续；只有用户明确要求公开上报时，才使用本机 gh api 直传，不 clone 仓库。
• 不收集用户名、主机名、工作目录、密钥、令牌、Cookie 或其它无关隐私；不得直接修改用户本地已安装 Skill 的源代码来“顺手修 bug”。

版本唯一来源为同目录 config.yaml:skill_info.version；本文件只描述稳定工作契约，不重复易变配置。

确定读者要做的判断

明确读者水平、目的（理解、选型、复现、批判或迁移）和论文类型。从标题、摘要、引言、结论、核心图表与相关工作提出主线，再回查方法；不要逐节抄目录。

提炼不超过三个核心命题

只保留“若为真会改变判断”的论文特有命题。内部按以下链条核查，正文不机械显示字段：

Claim → Why → Mechanism → Evidence → Alternative → Boundary → Verdict

链条缺口意味着继续取证或缩小结论，不能用背景填补。

重建机制

按“输入/状态/输出 → 信息如何保留、丢弃、读取 → 计算如何实现”解释。公式或证明只保留关键前提、构造、结论和直觉；细节放可选核查层。类比、事后重建须标为“教学类比”“我的解释”或“基于文本的重建”。

按论文类型调整镜头：

• 方法/系统：瓶颈、表示/协议改变、端到端收益；拆分模块、规模、训练配方、实现和部署成本。
• 理论/证明：前提、关键构造、结论；检查依赖、适用域、反例和最脆弱假设。
• 实证/因果：比较对象、识别策略、效应量与不确定性；检查混杂、功效、数据和外推。
• 分析/数据集：测量对象、数据/标注假设、发现；检查泄漏、代表性和指标有效性。
• 综述性单篇：范围、组织原则、综合结论；检查纳入标准、遗漏和反方证据。

建立证据链并压力测试

优先针对性任务/定理、公平对照、辨识力强的消融和论文内失败结果。数字只有改变判断时才保留，并附指标、比较对象、规模、预算、硬件或误差；未报告就明说。

每个命题都要有最近的替代解释和削弱条件。设计最小反事实：去关键部件、匹配参数/数据/计算、换分布/评价或匹配实现效率。不得把相关性、单一 benchmark、作者自述或混合系统收益升级为因果机制。

写成一个分层版本

交付笔记必须以 interpretation_contract: research-literature-interpretation-evidence-v1 开头，并在 frontmatter 保存 source_id、evidence_depth（normative/fulltext/abstract/web/source）、read_scope、stable_citation、question、method、key_results、limitations 和 supports_or_refutes。这些字段是证据索引，不替代正文；fulltext 不得与仅摘要读取范围同时声明。旧笔记只能用 --allow-legacy 做只读检查，不能作为新运行的完整解读证据。

首屏用 3–6 句交代问题、改变、最强证据和最大边界。正文按“问题 → 改变 → 机制 → 证据 → 代价/边界 → 检验”展开，可按论文合并或省略不适用部分。

使用渐进披露，不按读者类型重复正文。短段落先给白话直觉，再给术语和技术核查；**加粗** 与 > 只突出改变判断的内容，不能代替论证。

写作前完整读取 移动端与分层写作指南。阈值以 config.yaml:style 为准；交付时运行：

python3 scripts/validate_notes.py --style <note>
# 旧笔记仅兼容读取，不用于新运行完成认证：
python3 scripts/validate_notes.py --allow-legacy <note>

机械检查不能替代科学复核。

交付前确认：

• 首屏可复述旧瓶颈、关键改变、最强证据和最大边界。
• 主线是“问题—机制—证据—边界”，不是章节或表格摘要。
• 每个核心命题都有区分性证据、最近替代解释和削弱条件。
• 机制解释信息流、表示或计算，而非只列模块。
• 已检索论文内负面结果、失败条件、成本和重要未报告项；常识 caveat 不冒充论文证据。
• 事实、作者主张、重建、类比和待验证判断在正文中归属清楚。
• 数字带必要协议，锚点能回到图表/公式/定理，正文没有审计日志腔。
• 手机读者能迅速定位精髓；入门读者先得直觉，硬核读者可沿公式/协议/锚点下钻，正文不重复。

答不上来就继续取证、收缩结论或列为未解决。只有内容门全部通过才能设 status: complete。

用户要求自我改进或任务风险较高时，最多三轮，每轮只修最影响判断的问题，并在任务工作区记录“发现—删改—复查—仍未知”：

1. 主线：让独立 agent 用两句话复述；若成了目录/摘要，重写开头和机制。
2. 证据：逐条问结果区分了什么、条件和反例是什么，删除流水账。
3. 读者：检查术语、类比、边界、来源层次、迁移问题、版本和锚点。

通过内容门即停止；仍不足只做一次定向修订并披露未知。

输出

输出 Skill description 所承诺的交付物，并明确格式、路径和失败返回形式。

输出管理

临时产物写入任务工作区，正式交付物写入项目约定位置；未经授权不覆盖或删除已有文件。

校验

完成后执行 Skill 已有的静态检查、脚本验证或人工复核，并记录通过标准。

失败与恢复

保留错误证据和已完成产物；仅在输入、环境或外部依赖恢复后从最近的失败步骤重试。

约束

结尾列一手 URL、访问日期、阅读版本/范围和可靠跟进链接；没有就说明。来源层只记录事实和核查路径，不代替解释。不要复制整篇论文、泄露密钥或用户资料；删减不得移除会改变判断的前提、对照、反例或证据边界。

公共硬约束

• 任务需要落盘时，使用唯一的 ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ 根目录；共享材料放入 shared/，Skill 专属材料放入该 Skill 的 input/、output/、log/。
• 正式交付物、源代码和正式计划按项目约定保存，不写入任务工作区；未经授权不覆盖、删除、迁移或远程写入。
• 项目维护变更检查 BAC 可用性并记录需求、AI 产出、工具结果、文件改动和验证摘要；BAC 只做过程审计，不替代署名、责任或合规判断。
• 不记录 API Key、访问令牌、密码、Cookie、环境/凭据文件、私有 Prompt、身份信息、本地用户名、主机名或不必要的大体积原始数据。
• 文件路径必须规范化并限制在授权项目范围内；外部 URL、子进程和网络访问遵循最小权限，防止路径遍历、SSRF 和命令注入。
• Skill 版本唯一记录在自身 config.yaml:skill_info.version；公开 API、协议、目录或配置变更同步文档与 CHANGELOG.md。
• 仅将 Skill 或 Bensz 基础设施本身的设计缺陷交给 bensz-collect-bugs；先脱敏写入 ~/.bensz-skills/bugs/，当前任务不中断，只有用户明确要求才公开上报，禁止直接修改用户已安装的 Skill 源码。

<!-- End of canonical common constraints. -->

Skill 专属约束

不得超出本 Skill description 和上方流程所声明的范围；不将未验证的信息伪装成确定结论。