Paperzilla 研究简报技能

当用户需要以下两种工作流之一时，使用本技能：

• on_demand_discussion：围绕某一个 Paperzilla 项目最新论文展开讨论；检视其中一篇论文；获取其 Markdown 内容；进行摘要；解释该论文为何对“我们的工作”具有意义；并延续讨论
• weekday_brief：为某一个 Paperzilla 项目生成一份简洁的周中研究简报

这是一个构建在与核心 paperzilla 技能相同 Paperzilla 访问层之上的工作流技能。它应体现出明确的观点性与可复现性。

前提条件

• 确保已安装并完成身份认证的 pz CLI（即已执行 pz login）。
• 使用 OpenClaw 工具：
  • 用 exec 执行 pz 命令
  • 仅当用户明确要求将摘要/简报发送至聊天窗口，或当前 profile 明确要求定时对外投递时，才使用 message 工具

若未检测到 pz，请运行 which pz 并告知用户：需先完成环境配置，方可继续。

安全模型

• 本技能主要为Paperzilla 只读/初筛型技能。
• 仅可在 profile 明确批准的投递行为，或用户显式请求投递时，使用 message 工具。
• 不得在 profile 投递规则之外主动或未经请求地发送消息。
• 不得读取任意系统文件、无关环境变量或无关凭据。
• 假设 pz 已由人工通过 pz login 完成安装与认证。
• 假设 OpenClaw 消息通道已由宿主平台完成配置；本技能不获取、生成或修改任何凭据。

本技能所需输入

• 一个 Paperzilla 项目
• 一句简短的“我们的工作”描述（若该上下文尚未明确提供）

若任一信息缺失，请仅询问一次，并在后续整个工作流中复用该输入。

示例：

• Project: Agents evaluation
• Our work: we build evaluation infrastructure for coding agents.

传输规则

遵循当前 profile 所要求的传输方式。

CLI profile

使用 Paperzilla CLI（pz）。

核心命令：

pz project list
pz project 
pz feed  --limit 20 --json
pz rec  --json
pz rec  --markdown
pz paper  --json
pz paper  --markdown
pz paper  --project 
pz feedback  upvote
pz feedback  star
pz feedback  downvote --reason not_relevant
pz feedback  downvote --reason low_quality
pz feedback clear 

当需要结构化解析 Feed 或元数据时，请始终使用 --json 参数。

请清晰区分 Paperzilla 的对象模型：

• pz paper 表示权威论文（canonical paper）
• pz rec 表示某项目内的推荐条目（recommendation）
• pz feedback ... 表示对该推荐条目的项目级反馈

若某条目来源于 pz feed --json，请优先使用 pz rec 和 pz feedback，而非 pz paper。

CLI 中 Markdown 输出行为因命令而异：

• pz rec --markdown 可触发 Markdown 异步生成；若内容尚未就绪，将输出友好提示建议重试
• pz paper --markdown 仅在 Markdown 已就绪时返回内容

MCP profile

直接使用 Paperzilla MCP 工具。

核心工具：

• projects_list
• projects_get
• feed_get
• paper_get
• paper_markdown

推荐调用顺序：

1. 当项目缺失或存在歧义时，调用 projects_list
2. 必要时调用 projects_get 确认项目身份
3. 调用 feed_get 拉取最新 Feed 条目
4. 调用 paper_get 获取单篇论文元数据
5. 调用 paper_markdown 进行基于 Markdown 的分析

正确处理 paper_markdown 的状态响应：

• ready：使用返回的 Markdown 内容
• queued：告知用户仍在生成中，并建议稍后重试
• unavailable：说明当前不可用 Markdown 内容

通用行为规则

• 将 Paperzilla 的相关性判断与排序视为强先验，而非最终结论。
• 严格使用 Paperzilla 的术语：project、feed、Must Read、Related。
• 检视某篇论文时，须明确指出所使用的具体论文 ID 或推荐 ID。
• 严格区分元数据与主观解读。
• 解释相关性时，须紧扣用户实际工作场景，而非泛泛而谈其通用重要性。
• 除非用户明确要求，否则不得输出完整 Markdown 内容。
• 若用户明确请求 Paperzilla Markdown，则不得默认回退至 arXiv HTML/abs 链接。

模式 1：按需讨论（on-demand discussion）

当用户希望在聊天界面中开展交互式论文讨论时，启用此模式。

工作流

1. 确认项目及“我们的工作”上下文。
2. 拉取该项目 Feed 中的最新论文。
3. 展示最新或最具潜力的若干候选论文简表。
4. 当用户选定某篇论文后，首先返回其元数据。
5. 获取该论文或对应推荐条目的 Markdown 内容。
6. 进行摘要，涵盖：
   • 核心贡献
   • 方法论
   • 实验结果
   • 局限性
   • 对“我们的工作”的意义
7. 延续讨论，并给出如下建议之一：
   • 立即阅读
   • 标记为 Related 保留
   • 本周忽略

输出契约

首次 Feed 回复需包含：

• 项目名称
• 已检查的论文列表
• 每篇论文：标题、日期、来源，及其 Paperzilla 标签（Must Read 或 Related）

元数据回复需包含：

• 标题
• 作者
• 发表日期
• 来源
• URL
• 所使用的精确 Paperzilla 论文 ID 或项目级推荐 ID

Markdown 回复需包含：

• 核心贡献
• 方法论
• 实验结果
• 局限性
• 对“我们的工作”的意义

模式 2：周中简报（weekday brief）

当用户希望为某一项目定期接收一份简洁的周中研究简报时，启用此模式。

工作流

1. 确认项目及“我们的工作”上下文。
2. 加载该项目历史简报中已提及的论文记录。
3. 拉取 Feed 中最新论文。
4. 排除此前周中简报中已提及的论文（除非用户明确要求重新审视）。
5. 从剩余论文中筛选出值得提及的内容。
6. 对每篇入选论文，提供：
   • 一句简明摘要
   • 一句说明其与“我们的工作”相关性的陈述
7. 完成简报草稿或发送后，将所选论文的精确 Paperzilla ID 追加至该项目的“已提议论文”历史记录中。
8. 若无符合标准的新论文，须明确声明。

输出契约

每份周中简报均须包含：

• 项目名称
• 日期
• 本次检查的新论文数量
• 每篇入选论文：
  • 标题
  • 一句简明摘要
  • 一句说明其与“我们的工作”相关性的陈述
• 当无新论文入选时，须明确标注 No new papers today.

保持简报简洁、易于快速浏览。

对于周期性运行，Agent 必须持久化维护每个项目的“已提议论文”ID 记录。除非用户明确要求重新审视，否则不得在后续周期简报中重复提议同一论文。

按需反馈闭环

若用户希望优化后续推荐结果：

1. 针对推荐 ID 执行 pz feedback ... 命令。
2. 说明该反馈仅作用于当前项目。
3. 使用以下操作：
   • upvote：表示正向信号
   • star：表示最强正向信号
   • downvote --reason not_relevant：表示主题不匹配
   • downvote --reason low_quality：表示论文质量欠佳
   • feedback clear：清除已有信号

边缘情况处理

• 未提供项目：仅询问一次，随后继续流程。
• 未提供“我们的工作”上下文：仅询问一句简短描述，随后复用该输入。
• 无历史简报记录：视作该项目首次简报，初始化空的“已提议论文”历史，并持久化本次所选论文。
• 无新论文：明确报告，不得填充冗余内容。
• Feed 数据量过大：优先使用合理限制值，仅在必要时扩大范围。
• Markdown 生成延迟：当用户明确请求 Markdown 时，应多次重试；优先采用短轮询机制，而非立即降级。
• 论文 ID 存在歧义：回退至完整 UUID，或清晰重申所选论文。
• 外部投递请求：若用户未明确要求投递，且当前 profile 亦无投递要求，则禁止使用 message 工具。
• 权威论文 ID 与推荐 ID 混淆：若 ID 来源于 pz feed --json，则默认其为推荐 ID，除非有明确反证。

Agent 特定规则

请阅读并遵守当前 profile 所附带的 AGENT.md 文件。该 profile 文件定义了聊天界面、投递界面及调度行为。