huangwb8 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、作者自述或混合系统收益升级为因果机制。
写成一个分层版本
首屏用 3–6 句交代问题、改变、最强证据和最大边界。正文按“问题 → 改变 → 机制 → 证据 → 代价/边界 → 检验”展开，可按论文合并或省略不适用部分。
使用渐进披露，不按读者类型重复正文。短段落先给白话直觉，再给术语和技术核查；**加粗** 与 > 只突出改变判断的内容，不能代替论证。
写作前完整读取 移动端与分层写作指南。阈值以 config.yaml:style 为准；交付时运行：
python3 scripts/validate_notes.py --style <note>
机械检查不能替代科学复核。
交付前确认：
- 首屏可复述旧瓶颈、关键改变、最强证据和最大边界。
- 主线是“问题—机制—证据—边界”，不是章节或表格摘要。
- 每个核心命题都有区分性证据、最近替代解释和削弱条件。
- 机制解释信息流、表示或计算，而非只列模块。
- 已检索论文内负面结果、失败条件、成本和重要未报告项；常识 caveat 不冒充论文证据。
- 事实、作者主张、重建、类比和待验证判断在正文中归属清楚。
- 数字带必要协议，锚点能回到图表/公式/定理，正文没有审计日志腔。
- 手机读者能迅速定位精髓；入门读者先得直觉，硬核读者可沿公式/协议/锚点下钻，正文不重复。
答不上来就继续取证、收缩结论或列为未解决。只有内容门全部通过才能设 status: complete。
用户要求自我改进或任务风险较高时，最多三轮，每轮只修最影响判断的问题，并在任务工作区记录“发现—删改—复查—仍未知”：
- 主线：让独立 agent 用两句话复述；若成了目录/摘要，重写开头和机制。
- 证据：逐条问结果区分了什么、条件和反例是什么，删除流水账。
- 读者：检查术语、类比、边界、来源层次、迁移问题、版本和锚点。
通过内容门即停止；仍不足只做一次定向修订并披露未知。
输出
输出 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 源码。
Skill 专属约束
不得超出本 Skill description 和上方流程所声明的范围；不将未验证的信息伪装成确定结论。