Back to Details

research-literature-interpretation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Research Literature Interpretation

Research Literature Interpretation

把单篇论文压缩成读者能复述、质疑和迁移的解释链：旧方法为何受限，作者改变了什么，机制为何可能有效，证据支持到何种强度，代价和失效条件是什么。
主动取舍比篇幅重要。页码、章节和图表只服务复核，不支配叙事。
Condense a single paper into an explanatory chain that readers can retell, question, and apply: why old methods are limited, what the authors changed, why the mechanism might work, the strength of evidence support, and what the costs and failure conditions are.
Active prioritization is more important than length. Page numbers, sections, and charts only serve for review, not to dictate the narrative.

范围与文件边界

Scope and File Boundaries

  • 仅处理单篇论文；发现、筛选和去重交给 
    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/
    。
  • Only process a single paper; leave discovery, screening, and deduplication to 
    research-literature-radar
    , and multi-paper synthesis to review skills.
  • Confirm the title, authors, year, venue, version, DOI/arXiv ID, primary URL, access date, and readable scope. Record version conflicts side by side without making arbitrary rulings.
  • Prioritize reading the abstract, introduction, conclusion, methods, key figures/captions, ablation studies, failure cases, appendices, and code descriptions, then delve deeper into parts that affect the conclusion. When only the abstract or charts are available, deliver an evidence map and narrow down the conclusions.
  • Only use legally accessible primary materials and reliable follow-up sources; do not bypass access restrictions or execute unknown code. Distinguish between static reading, actual execution, and results reported by the authors.
  • By default, write to 
    docs/papers/<friendly-id>/<friendly-id>.md
    . Existing notes are revised or appended by default, without overwriting user content; do not modify 
    raw/
    or 
    .bensz-api/research-literature-radar/catalog.jsonl
    . Intermediate materials are placed in the current round's 
    .bensz-api/
    .

流程

Process

输入

Input

按用户请求和配置文件提供必要输入；缺失信息应明确列出并停止依赖该输入的步骤。
Provide necessary input according to user requests and configuration files; clearly list missing information and stop steps that depend on that input.

执行步骤

Execution Steps

  • 仅将本 Skill 的设计缺陷（流程漏判、输入契约不完整或环境假设错误）视为可上报 bug；用户数据错误、第三方服务抖动、用户主动改源码和模型偶发波动不属于此范围。
  • 发现设计缺陷时先脱敏记录到 
    ~/.bensz-skills/bugs/
    ，当前任务继续；只有用户明确要求公开上报时，才使用本机 
    gh api
    直传，不 clone 仓库。
  • 不收集用户名、主机名、工作目录、密钥、令牌、Cookie 或其它无关隐私；不得直接修改用户本地已安装 Skill 的源代码来“顺手修 bug”。
版本唯一来源为同目录 
config.yaml:skill_info.version
；本文件只描述稳定工作契约，不重复易变配置。
  • Only design flaws of this Skill (process misjudgments, incomplete input contracts, or incorrect environmental assumptions) are considered reportable bugs; user data errors, third-party service fluctuations, users actively modifying source code, and occasional model fluctuations are not included in this scope.
  • When a design flaw is found, first record it desensitized in 
    ~/.bensz-skills/bugs/
    and continue the current task; only when the user explicitly requests public reporting, use the local 
    gh api
    to upload directly without cloning the repository.
  • Do not collect usernames, hostnames, working directories, keys, tokens, cookies, or other irrelevant privacy information; do not directly modify the source code of the Skill installed locally by the user to "fix bugs conveniently".
The only source of version information is 
config.yaml:skill_info.version
in the same directory; this file only describes stable work contracts and does not repeat volatile configurations.

确定读者要做的判断

Determine the Judgments the Reader Needs to Make

明确读者水平、目的（理解、选型、复现、批判或迁移）和论文类型。从标题、摘要、引言、结论、核心图表与相关工作提出主线，再回查方法；不要逐节抄目录。
Clarify the reader's level, purpose (understanding, selection, reproduction, critique, or application), and paper type. Propose the main line from the title, abstract, introduction, conclusion, core charts, and related work, then review the methods; do not copy the section by section.

提炼不超过三个核心命题

Extract No More Than Three Core Propositions

只保留“若为真会改变判断”的论文特有命题。内部按以下链条核查，正文不机械显示字段：
Claim → Why → Mechanism → Evidence → Alternative → Boundary → Verdict
链条缺口意味着继续取证或缩小结论，不能用背景填补。
Only retain paper-specific propositions that "would change judgments if true". Internally verify according to the following chain; do not mechanically display fields in the main text:
Claim → Why → Mechanism → Evidence → Alternative → Boundary → Verdict
Gaps in the chain mean continuing to gather evidence or narrowing conclusions, and cannot be filled with background information.

重建机制

Reconstruct the Mechanism

按“输入/状态/输出 → 信息如何保留、丢弃、读取 → 计算如何实现”解释。公式或证明只保留关键前提、构造、结论和直觉；细节放可选核查层。类比、事后重建须标为“教学类比”“我的解释”或“基于文本的重建”。
按论文类型调整镜头：
  • 方法/系统：瓶颈、表示/协议改变、端到端收益；拆分模块、规模、训练配方、实现和部署成本。
  • 理论/证明：前提、关键构造、结论；检查依赖、适用域、反例和最脆弱假设。
  • 实证/因果：比较对象、识别策略、效应量与不确定性；检查混杂、功效、数据和外推。
  • 分析/数据集：测量对象、数据/标注假设、发现；检查泄漏、代表性和指标有效性。
  • 综述性单篇：范围、组织原则、综合结论；检查纳入标准、遗漏和反方证据。
Explain according to "input/state/output → how information is retained, discarded, and read → how computation is implemented". Only retain key premises, constructions, conclusions, and intuitions for formulas or proofs; details are placed in the optional verification layer. Analogies and post-hoc reconstructions must be labeled as "teaching analogy", "my interpretation", or "text-based reconstruction".
Adjust the perspective according to the paper type:
  • Method/System: Bottlenecks, changes in representation/protocol, end-to-end benefits; split modules, scale, training recipes, implementation and deployment costs.
  • Theory/Proof: Premises, key constructions, conclusions; check dependencies, applicable domains, counterexamples, and the most fragile assumptions.
  • Empirical/Causal: Comparison objects, identification strategies, effect size and uncertainty; check confounding factors, power, data, and extrapolation.
  • Analysis/Dataset: Measured objects, data/annotation assumptions, findings; check leakage, representativeness, and indicator validity.
  • Single Review Paper: Scope, organizational principles, synthetic conclusions; check inclusion criteria, omissions, and opposing evidence.

建立证据链并压力测试

Establish Evidence Chain and Stress Test

优先针对性任务/定理、公平对照、辨识力强的消融和论文内失败结果。数字只有改变判断时才保留，并附指标、比较对象、规模、预算、硬件或误差；未报告就明说。
每个命题都要有最近的替代解释和削弱条件。设计最小反事实：去关键部件、匹配参数/数据/计算、换分布/评价或匹配实现效率。不得把相关性、单一 benchmark、作者自述或混合系统收益升级为因果机制。
Prioritize targeted tasks/theorems, fair comparisons, highly discriminative ablation studies, and in-paper failure results. Retain numbers only if they change judgments, and attach indicators, comparison objects, scale, budget, hardware, or errors; clearly state if not reported.
Each proposition must have the latest alternative explanation and weakening conditions. Design minimal counterfactuals: remove key components, match parameters/data/computation, change distribution/evaluation, or match implementation efficiency. Do not upgrade correlation, a single benchmark, author self-report, or mixed system benefits to causal mechanisms.

写成一个分层版本

Write a Hierarchical Version

首屏用 3–6 句交代问题、改变、最强证据和最大边界。正文按“问题 → 改变 → 机制 → 证据 → 代价/边界 → 检验”展开，可按论文合并或省略不适用部分。
使用渐进披露，不按读者类型重复正文。短段落先给白话直觉，再给术语和技术核查；
**加粗**
与 
>
只突出改变判断的内容，不能代替论证。
写作前完整读取 移动端与分层写作指南。阈值以 
config.yaml:style
为准；交付时运行：
bash
python3 scripts/validate_notes.py --style <note>
机械检查不能替代科学复核。
交付前确认：
  • 首屏可复述旧瓶颈、关键改变、最强证据和最大边界。
  • 主线是“问题—机制—证据—边界”，不是章节或表格摘要。
  • 每个核心命题都有区分性证据、最近替代解释和削弱条件。
  • 机制解释信息流、表示或计算，而非只列模块。
  • 已检索论文内负面结果、失败条件、成本和重要未报告项；常识 caveat 不冒充论文证据。
  • 事实、作者主张、重建、类比和待验证判断在正文中归属清楚。
  • 数字带必要协议，锚点能回到图表/公式/定理，正文没有审计日志腔。
  • 手机读者能迅速定位精髓；入门读者先得直觉，硬核读者可沿公式/协议/锚点下钻，正文不重复。
答不上来就继续取证、收缩结论或列为未解决。只有内容门全部通过才能设 
status: complete
。
用户要求自我改进或任务风险较高时，最多三轮，每轮只修最影响判断的问题，并在任务工作区记录“发现—删改—复查—仍未知”：
  1. 主线：让独立 agent 用两句话复述；若成了目录/摘要，重写开头和机制。
  2. 证据：逐条问结果区分了什么、条件和反例是什么，删除流水账。
  3. 读者：检查术语、类比、边界、来源层次、迁移问题、版本和锚点。
通过内容门即停止；仍不足只做一次定向修订并披露未知。
Use 3–6 sentences on the first screen to explain the problem, changes, strongest evidence, and largest boundaries. The main text is structured as "Problem → Change → Mechanism → Evidence → Costs/Boundaries → Verification", and can merge or omit parts that are not applicable according to the paper.
Use progressive disclosure and do not repeat the main text according to reader types. Short paragraphs first provide plain-language intuition, then terms and technical verification; 
**bold**
and 
>
only highlight content that changes judgments, and cannot replace arguments.
Read the Mobile and Hierarchical Writing Guide completely before writing. The threshold is based on 
config.yaml:style
; run the following upon delivery:
bash
python3 scripts/validate_notes.py --style <note>
Mechanical checks cannot replace scientific review.
Before delivery, confirm:
  • The first screen can retell the old bottleneck, key changes, strongest evidence, and largest boundaries.
  • The main line is "Problem—Mechanism—Evidence—Boundary", not a section or table summary.
  • Each core proposition has distinguishing evidence, the latest alternative explanation, and weakening conditions.
  • The mechanism explains information flow, representation, or computation, not just listing modules.
  • Negative results, failure conditions, costs, and important unreported items in the paper have been retrieved; common caveats are not passed off as paper evidence.
  • Facts, author claims, reconstructions, analogies, and pending judgments are clearly attributed in the main text.
  • Numbers come with necessary protocols, anchors can link back to charts/formulas/theorems, and the main text does not have an audit log tone.
  • Mobile readers can quickly locate the essence; beginner readers get intuition first, hardcore readers can drill down along formulas/protocols/anchors, and the main text does not repeat.
If unable to answer, continue to gather evidence, narrow conclusions, or list as unresolved. Only when all content gates are passed can 
status: complete
be set.
When the user requests self-improvement or the task is high-risk, perform a maximum of three rounds, each round only fixing the problem that most affects judgment, and record "Discovery—Revision—Review—Still Unknown" in the task workspace:
  1. Main Line: Ask an independent agent to retell in two sentences; if it becomes a table of contents/abstract, rewrite the opening and mechanism.
  2. Evidence: Ask one by one what the results distinguish, what the conditions and counterexamples are, and delete verbose accounts.
  3. Readers: Check terminology, analogies, boundaries, source layers, application issues, versions, and anchors.
Stop once the content gates are passed; if still insufficient, only make one targeted revision and disclose unknowns.

输出

Output

输出 Skill description 所承诺的交付物，并明确格式、路径和失败返回形式。
Deliver the artifacts promised in the Skill description, and clearly specify the format, path, and failure return form.

输出管理

Output Management

临时产物写入任务工作区，正式交付物写入项目约定位置；未经授权不覆盖或删除已有文件。
Temporary products are written to the task workspace; formal deliverables are written to the project's agreed location; do not overwrite or delete existing files without authorization.

校验

Verification

完成后执行 Skill 已有的静态检查、脚本验证或人工复核，并记录通过标准。
After completion, perform static checks, script verification, or manual review that the Skill already has, and record the passing standards.

失败与恢复

Failure and Recovery

保留错误证据和已完成产物；仅在输入、环境或外部依赖恢复后从最近的失败步骤重试。
Retain error evidence and completed products; only retry from the latest failed step after input, environment, or external dependencies are restored.

约束

Constraints

结尾列一手 URL、访问日期、阅读版本/范围和可靠跟进链接；没有就说明。来源层只记录事实和核查路径，不代替解释。不要复制整篇论文、泄露密钥或用户资料；删减不得移除会改变判断的前提、对照、反例或证据边界。
List primary URLs, access dates, read versions/scopes, and reliable follow-up links at the end; state if none are available. The source layer only records facts and verification paths, not replacing explanations. Do not copy the entire paper, leak keys or user data; do not remove premises, comparisons, counterexamples, or evidence boundaries that would change judgments during deletion.

公共硬约束

Public Hard Constraints

  • 任务需要落盘时，使用唯一的 
    ./.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. -->
  • When the task requires saving to disk, use a unique root directory 
    ./.bensz-api/task-{yyyymmdd-hhmm}-{short description}/
    ; shared materials are placed in 
    shared/
    , and Skill-specific materials are placed in the Skill's 
    input/
    , 
    output/
    , 
    log/
    .
  • Formal deliverables, source code, and formal plans are saved according to project agreements and not written to the task workspace; do not overwrite, delete, migrate, or write remotely without authorization.
  • For project maintenance changes, check BAC availability and record requirements, AI outputs, tool results, file changes, and verification summaries; BAC only performs process audits and does not replace attribution, responsibility, or compliance judgments.
  • Do not record API Keys, access tokens, passwords, cookies, environment/credential files, private prompts, identity information, local usernames, hostnames, or unnecessary large-volume raw data.
  • File paths must be standardized and limited to authorized project scopes; external URLs, subprocesses, and network access follow the principle of least privilege to prevent path traversal, SSRF, and command injection.
  • Skill versions are only recorded in their own 
    config.yaml:skill_info.version
    ; public API, protocol, directory, or configuration changes are synchronized with documents and 
    CHANGELOG.md
    .
  • Only design flaws of the Skill or Bensz infrastructure itself are submitted to 
    bensz-collect-bugs
    ; first record desensitized in 
    ~/.bensz-skills/bugs/
    , do not interrupt the current task, and only report publicly if the user explicitly requests it; do not directly modify the source code of the Skill installed by the user.
<!-- End of canonical common constraints. -->

Skill 专属约束

Skill-Specific Constraints

不得超出本 Skill description 和上方流程所声明的范围；不将未验证的信息伪装成确定结论。
Do not exceed the scope stated in this Skill description and the above process; do not disguise unverified information as definitive conclusions.