Imported from nblvguohao/video (.claude/skills/sci_writer/SKILL.md). Install upstream with npx skills add nblvguohao/video --skill sci_writer. Copyright stays with the author.

sci_writer — 案例主线实证论文写作流水线

这个技能封装了一套已经跑通过一次完整实践的方法：给定一个真实公司/产业/案例作为主线，在只能通过网页检索摘要 + 公开数据集 + 学术检索工具取数的受限环境下，产出一篇有定量核心、诚实报告局限、并按目标期刊格式撰写好的研究型论文初稿及投稿包。

它不是一个可以直接套模板生成论文的脚本；每次调用的证据维度、研究问题、统计模型都因案例而异。这个技能给你的是方法论骨架 + 已验证的基础设施（证据核查规则、评审团设计、期刊格式提取流程、DOCX/PDF 构建脚本），你需要用 Workflow 工具（先加载 workflow-authoring 技能）为具体案例现写每一阶段的脚本。

何时用、何时不用

用它：用户要写一篇以某个真实企业/产品/事件为案例、有数据分析、要投特定期刊或分区的论文，且需要从零收集证据、凝炼选题。 不用它：用户只要润色一段已有文字（转 nature-polishing）；只要文献综述无原创分析（转 lit-cartography）；用户已有明确选题和数据、只要帮忙写作（直接进 Phase 4）。

核心原则（贯穿六个阶段，务必先读）

1. 零编造。任何数字、文献、机构名、项目名找不到就写"未找到/未确认"，绝不能靠"合理推测"填补。每条事实必须带来源 URL、检索词、置信度（高/中/低）。这是整个流水线能不能被信任的前提。
2. 诚实优先于完整。统计结果不显著、样本量不够、识别策略被数据否决，都要如实写"提示性""不可判定""此设计不成立"，而不是想办法讲圆。审稿人和编辑最痛恨的是"过度承诺"，不是"承认局限"。
3. 案例是分析对象，不是主角。反复检查：这篇论文读起来像不像企业软文？如果案例只有正面事实，去找负面事实（财务问题、监管处罚、失败的业务线、媒体质疑）——真实案例几乎不可能只有正面面，找不到往往说明证据收集不够。
4. 每个阶段先摸清环境能力边界，再定方法，不要预设。不同容器/会话的网络白名单、WebSearch 配额、可用的学术 MCP 工具都可能不同。Phase 1 的第一步永远是探测这些边界。
5. 多代理独立性是质量的来源，不是速度的来源。多个提案人、多个评审、多个核查员之所以有用，是因为他们互相不知道对方的结论，能暴露单一视角看不到的问题。压缩阶段（比如跳过评审直接采用第一个提案）会系统性地漏掉这一点。

六个阶段总览

详细方法见 references/phase1_evidence.md … references/phase5_review.md；references/worked_example.md 是一次真实实践（以"荃银高科"为案例的水稻种业论文）的浓缩记录，遇到不确定的地方可以对照它校准尺度。

Phase 1：证据收集

第一步永远是环境探测，不要假设网络和工具可用性：

• 用 curl -sS -o /dev/null -w "%{http_code}" 批量探测目标站点（公司官网、行业数据库、出版社站点、学术 API）是否被代理拦截；记录哪些可达（常见例外：github.com/raw.githubusercontent.com 往往在被拦截列表里例外，可用 git clone --depth 1 拉公开数据汇编仓库）。
• 用 ToolSearch 探测哪些学术 MCP 工具（Consensus、Elicit、Scholar Gateway、Undermind、PubMed、Amass 等）真正可调用、配额是否已耗尽——不要等第 20 次调用失败才发现。
• 把探测结果写成一份"工具与环境约束"说明，后续所有并行代理的 prompt 都要包含这份说明，否则它们会各自重复踩坑、浪费配额。

设计证据维度（通常 8–12 个），覆盖：

• 案例主体的基本面（财务/规模/组织，逐年面板）
• 案例主体的核心产出/产品组合（若有可分析的"产品级"数据，这是定量核心的候选来源）
• 研发/项目/合作网络
• 商业模式与产业链位置，主动找负面证据
• 行业与政策背景、同行对照
• 学术文献扫描（至少两个子方向：方法学范本 + 理论框架）
• 案例主体在学术文献中的直接记载（哪怕稀少也要如实报告数量）
• 数据可行性探针——这是最容易被跳过但最重要的一步：抽样检验"如果要做定量分析，这个变量能不能真的拿到、覆盖率多少、缺失是否随机"，而不是等写方案时才发现拿不到。
• 目标期刊预扫描（详见 Phase 3，但可以在这里先起步）

用 Workflow 并行执行：把维度拆给独立的 agent() 调用（同一批用 parallel()），每个维度要求 15–30 次检索直到边际收益趋零，并返回结构化的 key_facts（含数字+来源）与 gaps。做完一轮后加一个完整性批评者（读遍所有证据文件，找出最重要的缺口）和事实核查（对决策关键的数字用独立视角重新检索验证，默认"查不到就当作可疑"）。

关于"公开数据集"的意外来源：很多行业存在被第三方汇编到 GitHub 的公开记录（监管公告、审批文件、行业协会名录等）为结构化/半结构化数据。当官方数据库站点被拦截时，搜索 github <领域关键词> 数据集/dataset 往往能找到替代来源；拿到后用 Python 脚本解析、并独立验证解析的准确率（抽样与原文比对），不要盲信第三方汇编的质量。

识别案例主体的记录（当结构化字段不可靠时）：如果依赖的数据源里"申请人/主体"字段有系统性缺失（例如某几年整体缺失），不要放弃——检查是否有其他稳定的身份标记（品牌前缀、专有代号、命名规律），并用有标签的子集验证该规则的精确率与召回率再推广使用，同时保留系统识别方法的证据文件。

产出汇总进 evidence/00_INDEX.md：每个文件的摘要、核心数字速查表（附来源与置信度）、可用数据集清单、方法学范本与理论框架文献各列若干篇、已知矛盾与待确认事项。

Phase 2：主题与创新点评审团

不要自己一个人定题目。做法：

1. 写一份 plan/BRIEF.md，把 Phase 1 的硬约束、核心数据集、探索性发现、限制、竞争性文献警示、期刊候选清单浓缩给提案人看（提案人不应该重新读全部证据文件，那样会各自跑偏）。
2. 在合成前，先做一轮真正的探索性统计（如果有定量数据）——自己动手跑几个基本模型看看有没有稳健的信号，这能大幅提高后续提案的质量,也能让评审有的放矢。别指望提案人凭空跑出好结果。
3. 派出 3–5 个独立提案人，各自从不同角度（如：本学科视角、产业组织/经济学视角、政策评估视角、机制整合视角）提出完整方案：题目、一句话论点、创新点（必须写明"相对哪篇最接近的文献新"，并要求用学术检索工具核实该文献是否真实存在——不能凭空断言"尚无人做过"）、数据方案、方法、图表清单、目标期刊、可行性与新颖性自评分。要求提案人实际运行一些统计代码验证可行性，不能只写"应该可行"。
4. 派出 3 个视角不同的评审（例如：期刊编辑视角看契合度与"软文"风险、统计视角亲自复核关键估计量、新颖性视角亲自核实占位文献是否存在），各自打分（建议维度：novelty/feasibility/fit/rigor/generality，加权求和）并各自返回"最佳方案 id"。
5. 评审的统计复核不是走过场——安排至少一位评审去真正重跑提案里声称的关键结果，用不同的子集/口径检验其稳健性。这一步经常会发现提案自述的数字与独立复算不符，或者关键结论对某个非随机缺失的年份/子样本极度敏感。这正是多评审设计要抓的东西。
6. 你自己（主协调者）读完全部方案与评审后再做一次独立复算验证评审提出的关键分歧点，然后合成：plan/00_decision_log.md（评审汇总、被否方案及具体原因、嫁接清单）、plan/01_theme_and_innovation.md（最终题目/论点/创新点/本文不主张的事项清单）、plan/02_research_route.md（变量表、模型设定、论证地图、章节契约、图表清单、风险登记）。

关于"创新点"的检验标准：一条创新点如果经不起"审稿人一句话否定"就不算数。让评审明确写出"审稿人最可能用来否定这条创新点的一句话"，然后看你能不能答得上来。答不上来就换角度或降级表述。

Phase 3：目标期刊评估

不要只靠一次检索就下结论。核实清单：

• 该刊在用户要求的分区体系当年版本中的确切分区（大类+小类），多个来源交叉印证；某些分区体系近年可能改版或换名，检索时要留意"是否已停更/改版"。
• 影响因子、JCR 分区、年发文量、审稿周期、是否 OA/APC。
• 范围契合度是最容易被高估的一项——不要只看"这个学科方向听起来对不对"，去找该刊官方公布的 Aims and Scope 原文，逐句核对你的论文框架（尤其是跨学科论文，比如"用农学数据做产业经济分析"）是否真的落在范围内。找不到官方原文就明确标注"待确认"，不要脑补。
• 检索该刊近 2–3 年是否发表过主题最相近的论文，作为"可发表性证据"，每篇给完整引文。
• 提取投稿格式规范：文章类型与字数上限、摘要结构与字数、关键词数、是否需要 Highlights/Graphical Abstract、章节结构、图表规范、参考文献格式（给出至少一条期刊论文的完整格式示例）、声明部分要求（数据可用性/利益冲突/作者贡献/资助）、投稿系统。

产出 plan/03_target_journal.md（候选对比表 + 最终选择 + 理由）与 plan/04_format_spec.md（完整撰写规范清单，每条注明来源）。

Phase 4：撰写

• 按 02_research_route.md 里的章节契约（每节的 purpose / allowed claims / forbidden claims / inputs）分节并行撰写，契约本身就是防止"结果部分开始下结论""讨论部分编造新数字"的机制。
• 写作规范：先立论点（每段首句是主张句，随后证据，末句给边界）；主张不得超出证据（探索阶段标注过"不能支持"的说法禁止出现在正文）；每个数字必须能在表格/结果文件/证据索引中查到出处；避免 AI 腔套话；负面事实必须如实呈现，不能被稀释成正面表述。
• 整合阶段统一图表编号、术语、数字格式，再交给独立的参考文献核验员逐条用学术工具核实（作者/年份/题名/期刊/卷期页/DOI 是否一致），核实不了的文献从正文移除并记录。

Phase 5：投稿前审查

• 多个独立审稿人视角（如"技术严谨性"、"原创性与是否像宣传"、"可读性与期刊契合"）分别写审稿意见，格式与 nature-reviewer 技能的输出结构类似。
• 独立的格式合规审查（逐条对照 04_format_spec.md）、数字一致性审查（正文/摘要/图表/表格互相核对，必要时重算）、参考文献多源核验（nature-ref-verifier 的方法可以直接借用）。
• 一位修订负责人把所有意见落实进 v2 版本，写变更日志；一位终审校对做 diff 比对确认改动与日志一致、无意外改动，然后跑 scripts/build_docx.py / scripts/build_pdf.py 生成投稿文件并抽查排版。
• 产出投稿包：cover letter、highlights、图表说明、声明文件、投稿清单、版本历史。

基础设施（bundled resources）

• scripts/build_docx.py：把 Markdown 手稿转换为期刊风格的 .docx（Times New Roman、双倍行距、自动插入图片、表格）。用法：python3 build_docx.py manuscript.md out.docx [--pdf] [--line-numbers]。如果容器里 LibreOffice 不可用（很常见），--pdf 会自动跳过转换，改用下面的脚本单独生成 PDF。
• scripts/build_pdf.py：不依赖 LibreOffice，用 PyMuPDF 的 Story 排版引擎直接从 Markdown 渲染 PDF。用法：python3 build_pdf.py manuscript.md out.pdf。
• scripts/workflows/：Phase 1–5 各阶段的 Workflow 脚本范式（不是可以直接套用的成品——里面的证据维度、变量表都要按新案例重写，但并行结构、schema 设计、"先探测环境约束再执行"的模式可以照搬）。写新脚本前务必先读 workflow-authoring 技能。

一次真实实践的关键教训（浓缩自 worked_example.md）

• 后台 Workflow 任务会在会话挂起/切换模型时被杀掉——如果发生这种情况，改用前台的 Agent（run_in_background: false 或默认异步但主动等待通知）保持会话活跃，直到该阶段完成。
• 学术检索 MCP 工具的配额经常比预期更快耗尽（尤其 Consensus/Elicit 这类商业化工具），要在 Phase 1 早期就摸清哪些工具真正可持续使用一整个项目，把主力放在那里（WebSearch + GitHub + 免费的学术 MCP 通常是最可靠的组合）。
• 多个并行代理可能重复劳动或产生冲突（比如两个工作流都在写同一个证据维度）——如果并行度较高，主协调者要定期检查 journal / 进度，及时停掉冗余任务。
• 数据集里一个看似很小的解析问题（比如某个字段的正则匹配窗口太窄）可能让覆盖率被低估十几个百分点，进而影响后续所有统计结论——统计评审阶段独立复算原始数据、而不是只读方案里的数字，是这个流水线里性价比最高的一步。