论文五步通

概述

概述

本技能把一次学术写作任务拆成五个可独立调用、也可串行编排的阶段，每个阶段有明确的输入、输出和验收标准。阶段之间通过文件交接，不依赖会话记忆，因此每个阶段都可以在全新会话中独立运行，也便于企业环境下的审计与回放。

• research 研究：主题 → 研究简报 + 文献清单
• write 写作：研究简报 → 论文草稿
• review 评审：论文 → 结构化评审报告
• revise 修改：论文 + 意见 → 修改稿 + 审稿回复信
• finalize 定稿：修改稿 → 定稿 + 修复清单

五个阶段也可由 pipeline 模式一键串行执行，详见「pipeline 模式」一节。

各阶段详解

阶段 1：research（深度研究）

用途：给定研究主题或问题，产出结构化研究简报，为写作阶段提供素材基础。

输入：研究主题或问题（文本）。可选：学科领域、目标篇幅、语言偏好。

流程：

1. 解析研究问题，拆解成 3–5 个子问题。
2. 围绕子问题检索文献（可用工具：WebSearch / WebFetch / arXiv / Google Scholar 等任一可用渠道）。
3. 对每条重要文献生成单条记录：题名、作者、年份、来源、方法要点、核心发现、与本研究问题的相关点。
4. 每条记录标注置信度（高/中/低，依据来源类型与交叉验证情况）。
5. 汇总成研究简报：研究问题、子问题拆解、当前领域共识、争议点、研究缺口、初步定位声明。

输出：research/00-brief.md（研究简报）与 research/lit-index.md（文献清单）。

验收标准：

• 子问题覆盖研究问题的全部主要方面，无明显遗漏的分支
• 无法溯源到来源的判断必须标注置信度，且不得在后续简报中被当作「已验证事实」引用
• 文献记录至少包含（若可得）：题名、作者、年份、来源、方法、发现、相关点、置信度
• 领域共识与争议点各自至少有 2 条文献支撑（若确实无法达到，明确说明原因）

阶段 2：write（论文撰写）

用途：基于研究简报（或用户自备素材）撰写论文章节或全文。

输入：研究简报（或用户自备素材）+ 写作指令（目标结构、篇幅、引用格式）。

流程：

1. 确定论文结构。无特殊要求时默认：Abstract、Introduction、Related Work、Method、Experiments、Discussion、Conclusion、References。
2. 按章节推进：先产出一版章节要点，再展开成段落。
3. 每写完一个主要章节，对照研究简报自查：是否有观点缺乏支撑、是否有过度声称、引用是否真实对应。
4. 引用采用「作者-年份」行内提示 + 文末统一列表，格式依用户要求（APA / IEEE / GB/T 7714 等）。

输出：paper/01-draft.md（草稿）。长文可按章节存为 paper/01-draft-XX.md。

验收标准：

• 结构完整，包含所有必选章节
• 每条引用真实对应文末列表，无悬空引用
• 论断与支撑证据强度匹配，不做「单一结果 → 广泛结论」的跳跃
• 术语全文一致（同一概念不混用多个名称）

阶段 3：review（同行评审式质检）

用途：对草稿执行同行评审式的多维度质量检查，产出可操作的修改意见。

维度与权重：

1. 技术正确性（30%）：概念、方法、推理、数据的使用是否正确
2. 证据与引用（25%）：引用是否真实、准确、未被过度声称
3. 结构与逻辑（20%）：结构是否服务论证、段落衔接与论点推进
4. 语言与规范（15%）：学术语体、术语一致、格式一致
5. 原创性判断（10%）：与既有文献相比的贡献表述是否恰当

流程：

1. 通读草稿，按五个维度逐项检查。
2. 每条意见按固定格式记录：[维度] [位置] [严重度: major/minor] [修改建议]。
3. 意见按严重度排序：major 必须全部列出，minor 可合并同类。
4. 综合以上形成总体评价与「接受 / 小修 / 大修 / 拒稿」建议。

输出：review/02-report.md（评审报告）。

验收标准：

• 每条意见均可定位（能指到章节 / 段落 / 句子），可操作（给出具体修改方向），且分清「必须改」与「建议改」
• 技术正确性意见必须依据具体领域知识，不得泛泛而谈
• 总评与分维度意见不矛盾（总评「接受」时不得存在未处理的 major 意见）

阶段 4：revise（按审稿意见修改）

用途：针对评审报告中的意见，对论文进行系统性修改，并产出审稿回复信。

输入：论文草稿 + 评审报告（或用户提供的审稿意见）。

流程：

1. 逐条解析审稿意见，归并重复项后建立修改清单，编号 R1、R2……每条标注处理策略（采纳 / 部分采纳 / 有理由不采纳）。
2. 按清单逐条修改正文，修改处自然融入原稿，不留修改痕迹。
3. 每条意见对应生成回复：做了什么、改在哪里（章节 / 段落）、为什么（若不采纳，说明理由）。
4. 全文一致性复查：术语、交叉引用、编号、参考文献条目与正文引用是否同步更新。

输出：paper/03-revised.md（修改稿）与 review/03-response.md（回复信）。

验收标准：

• 每条意见都有对应回复，无遗漏
• 回复中「改动位置」与修改稿中的实际改动一致
• 不采纳的意见必须给出具体理由，不得只写「已修改」
• 全文一致性复查结果记录在回复信末尾（术语 / 引用 / 编号无漂移）

阶段 5：finalize（定稿）

用途：对通过评审并完成修改的论文做最后的整体润色与规范统一。

输入：修改稿（或任何需要定稿的学术文档）。

流程：

1. 术语表核对：同一概念全文用词统一。
2. 编号系统核对：章节、图表、公式、附录编号连续且交叉引用正确。
3. 引用核对：文内引用与参考文献列表双向对齐，无单侧悬空。
4. 版式规范核对：按用户指定的格式要求（或默认学术通用规范）统一标题层级、图表标题、缩写首次定义等。
5. 对发现的问题就地修复，并记录修复清单。

输出：paper/04-final.md（定稿）与 paper/checklist.md（修复清单）。

验收标准：

• 修复清单列出定稿过程中发现的每一个问题及修复方式
• 定稿不引入任何新观点、新引用、新数据（定稿只做一致性与规范性修复，不做内容扩展）
• 引用双向对齐核对结果可复核

文件交接约定

阶段之间通过文件交接，不依赖会话记忆。推荐目录结构：

project/
├── research/00-brief.md        # 阶段1输出：研究简报
├── research/lit-index.md       # 阶段1输出：文献清单
├── paper/01-draft.md           # 阶段2输出：草稿
├── review/02-report.md         # 阶段3输出：评审报告
├── paper/03-revised.md         # 阶段4输出：修改稿
├── review/03-response.md       # 阶段4输出：回复信
├── paper/04-final.md           # 阶段5输出：定稿
└── paper/checklist.md          # 阶段5输出：修复清单

每个交接文件头部带元信息块：

---
task: <任务名>
stage: research
generated: <ISO8601 时间>
depends_on: []
---

后一阶段启动时，先读取前一阶段输出文件的元信息块，校验 depends_on 与实际可用文件是否一致。不一致时停止并报告缺失项，不要在缺依赖的情况下凭空补数据。

研究简报（00-brief.md）、评审报告（02-report.md）、回复信（03-response.md）的骨架见 templates/ 目录，生成输出文件时以其为基础填充。

pipeline 模式（全流程编排）

用户说「跑一遍完整流程」或明确要求 research → write → review → revise → finalize 全链路时，按以下方式编排：

1. 五个阶段顺序执行，阶段间按上文约定交接文件。若用户素材已包含研究简报，则跳过 research 阶段。
2. review 阶段中发现的 major 意见，在 revise 处理完成后，再对修改稿执行一轮轻量 review（只检查 major 意见是否真正解决，不重新全面评审）。轻量 review 结果写入 review/02-report-round2.md，只包含未解决或新发现的问题；major 全部解决时此文件写明「无遗留」。
3. major 意见全部解决后进入 finalize。用户把「major 未清零不得进入定稿」设为硬性要求时，pipeline 在 major > 0 处停下并报告，等用户指令再继续。
4. pipeline 中途失败（如检索中断、工具不可用）时，按已完成的最后一个阶段保存现场，报告失败点与已生成文件清单，不要静默丢弃任何阶段输出。
5. 完成后向用户报告各阶段输出文件清单与各阶段耗时。

模式速查

除 pipeline 全流程外，各阶段可独立调用。触发说法与模式映射：

上表是默认映射，不具排他性：如「整理参考文献」在语义上更接近 finalize 的引用核对子步骤，应按语义归入对应阶段的子步骤，而不是生搬硬套。

企业计费接入

本技能面向企业付费调用场景，各阶段入口和出口都会产生可计量的调用事件。平台侧（如 workbuddyskill 商店）可按以下方式接入计量与授权：

1. 授权校验：平台在调用前校验用户的订阅状态与配额，未授权时由平台拦截，技能本身不做二次校验（避免与平台计费逻辑重复）。
2. 计量事件：每次进入某个模式（含 pipeline 及其内部各阶段）记为一个计量事件，事件属性包括：task_id、mode（research / write / review / revise / finalize / pipeline）、stage_index（pipeline 内的第几个阶段，独立调用时为 null）、timestamp。
3. 计量上报：本技能自带上报脚本 scripts/meter.py。若环境中配置了 WORKBUDDY_METERING_URL 环境变量，则每次模式调用结束时执行该脚本向该地址 POST 一次 JSON 事件；未配置时脚本直接退出，不影响技能正常运行。
4. 流水审计：所有阶段输出文件（含元信息块）构成可审计的任务流水，企业用户可按 task_id 回溯完整执行链路。

平台侧计费字段建议见 manifest.json 的 billing 配置节，可按商店实际定价策略调整计费模式（按次 / 按阶段 / 按订阅）。

使用边界

• 本技能是研究与写作流程的辅助工具，产出的文稿必须由使用者做最终审查；作者对最终提交内容负有全部学术与合规责任。
• 文献检索结果存在时效性与来源可信度差异，重要引用请在正式使用前人工复核原文。
• 本技能不代写考试答卷、不伪造数据或作者身份、不协助违反学术诚信规范的操作；遇到此类请求时明确拒绝并说明原因。

💳 付费前置检查与 X402 支付流程

本技能为 SkillHub Pay Skill，由后端支付服务实现微信支付 X402 门控（402 → 查单 → 履约）。AI 调用前必须完成以下流程，未支付不得输出任何论文五步通付费内容：

前置检查

调用本 Skill 前，检查当前 Agent 是否已安装 weixinpay 支付插件（SkillHub 客户端内置）：

• 已安装：可继续提供付费服务
• 未安装：提示「当前 Agent 暂不支持微信支付付费能力」，终止流程

工作流程（支付触发）

第一步：请求资源

POST https://www.jishangtech.com/skills/researchforge/demo/skill/invoke
Body: {"query": "用户的查询内容"}

第二步：处理 402 响应

服务返回 HTTP 402 时，提取 Header 中的 WeixinPay-Required（支付码）与 X-Out-Trade-No（订单号），两者都必须保存

第三步：发起支付

将 WeixinPay-Required 值作为 paymentCode（即 payment_code），调用 weixinpay_pay 发起微信支付

第四步：支付成功后获取资源（⚠️ 必须执行）

POST https://www.jishangtech.com/skills/researchforge/demo/skill/invoke
Headers: WeixinPay-Required + X-Out-Trade-No（第二步保存的订单号）
Body: {"query": "原始查询内容"}（body 与第一步完全一致）

⚠️ 第四步是最容易被 Agent 遗漏的一步：不携带 X-Out-Trade-No Header 重试，就永远拿不到付费内容。

重试机制

支付成功后，以与第一步完全一致的请求体重试一次；若仍返回 402，说明网络或订单同步延迟，引导用户稍后重试，不重复扣费。

订单号传递与异常处理

• 已支付但未返回核心结果 → 凭 X-Out-Trade-No 查单补发，不二次收费
• 支付取消 / 超时 → 终止并提示
• 返回 NOT_PAID → 支付尚未完成：等待数秒后携带同一 X-Out-Trade-No 重试（指数退避，最多 3 次），不要换新订单号重复发起支付（避免订单冲突 / 重复扣费）
• 返回 REFUNDED → 服务异常已自动退款：向用户说明「该服务暂时无法提供内容，已自动退款至原支付账户」，终止流程，不要再支付或重试
• 返回 FULFILL_AND_REFUND_FAILED → 服务异常且退款失败：建议用户联系客服
• 未确认支付前，严禁输出任何论文五步通付费内容