• AI 技能
• AI 写作
• 人工智能
• 深度研究
• AI 应用

导读

本指南解析 PaperSpine5 Skill 中 task-genre-research.md 这一篇体裁研究方法论文档：当用户交付的不是"期刊/会议论文"，而是数学建模竞赛论文、技术报告、课程报告、政策白皮书、课题 Proposal 等"以受众与评分标准为核心"的结构化文档时，如何先研究任务体裁、再决定写作结构。读完本文你将掌握体裁研究的标准流程（audience → evaluation criteria → required deliverable → exemplar structure → evidence standard → writing strategy）、genre_research.md输出模板的五张核心表，以及建模竞赛、技术/白皮书、Proposal 三种写作模式的差异化清单，并了解该方法在 PaperSpine5 配置与路由机制中的落地方式。

一、何时启用：识别"非期刊"的论文类任务

原文档开头明确了启用条件：当用户希望把"先学后写"的方法应用到"并非简单期刊/会议稿件"的论文类任务时，使用 Task-Genre Research。典型场景包括：

• 数学建模竞赛论文（mathematical-modeling contest papers）
• 技术报告（technical reports）
• 学位论文 / Proposal 风格报告（thesis/proposal-style reports）
• 评审报告（review reports）
• 政策 / 白皮书风格分析（policy/white-paper style analyses）
• 基金申请式叙述（grant-like narratives）
• 其他具备"目标受众 + 评价标准"的结构化文档

这类任务的共同特征是：它们同样有目标读者与评估准则，但评估逻辑与期刊同行评审并不相同。因此不能默认套用期刊的 IMRaD 结构，而要先完成"体裁研究"。

二、核心原则：体裁优先，而非结构优先

原文档给出的核心原则是先学体裁、再定结构，其推理链为：

audience -> evaluation criteria -> required deliverable -> exemplar structure -> evidence standard -> writing strategy

即：受众 → 评价标准 → 规定交付物 → 范例结构 → 证据标准 → 写作策略。每一步的输出都是下一步的输入，形成一条闭环的体裁推导链。

在此基础上，输出仍应保持动机驱动（motivation-driven），但这里的"动机"不再是"科学贡献"，而可以是：

• 问题目标（problem objective）
• 客户需求（client need）
• 决策问题（decision question）
• 评分标准（scoring criterion）
• 设计约束（design constraint）

换句话说，PaperSpine 一贯强调的"动机—论证—证据"主线依然保留，只是动机的来源和表现形式随体裁改变。

在仓库的 current-method-routing.json 中，该方法被登记为路由表条目，其 purpose 明确写道："全文；体裁研究、受众/评价/交付/证据链、建模竞赛变量与假设/验证、技术报告决策与不确定性、proposal目标/风险/预期。" 同时标注了适用约束："根据实际 scene/用户体裁解释适用子方法……普通期刊无需伪造竞赛指标。" 这印证了体裁研究是条件性方法：仅当场景确实属于非期刊体裁时才启用，期刊任务不应为了形式而强行套用。

三、体裁研究的产物：genre_research.md输出模板

Task-Genre Research 要求把研究结果保存为paper_rewriting_output/genre_research.md。原文档给出了完整的 Markdown 模板，写作时应完整遵循其五大部分：

# Genre Research ## Task Identity | Field | Content | |---|---| | Task type | | | Target audience/evaluator | | | Official rules/rubric/source | | | Required deliverable format | | | Length/page constraints | | | Language/style expectations | | ## Evaluation Logic | Criterion | What Evaluators Reward | What They Penalize | Writing Consequence | |---|---|---|---| ## Exemplar Learning | Exemplar | Why Selected | Section Order | Strong Moves | Transferable Pattern | Do Not Copy | |---|---|---|---|---|---| ## Genre-Specific Section Blueprint | Section | Reader/Evaluator Question | Required Evidence | Typical Move Sequence | Common Failure | |---|---|---|---|---| ## Writing Strategy - central objective: - required assumptions or constraints: - model/method/evidence chain: - validation/sensitivity/robustness requirement: - figure/table role: - final recommendation or conclusion role:

逐表解读：

1. Task Identity（任务身份）：回答"这到底是一份什么文档、写给谁、按什么规则评"——任务类型、受众/评审者、官方规则/评分标准来源、规定交付格式、篇幅/页数约束、语言与风格预期。
2. Evaluation Logic（评价逻辑）：逐条拆解每个评分标准"奖励什么、惩罚什么、对写作意味着什么"，把 rubrics 翻译成可执行的写作动作。
3. Exemplar Learning（范例学习）：记录每个被学习的范例为何入选、其章节顺序、强动作（strong moves）、可迁移模式，以及明确"不要复制"什么——范例学习必须学到评价逻辑，而不是表面排版。
4. Genre-Specific Section Blueprint（体裁专属章节蓝图）：针对该体裁的每一节，写下"读者/评审者的问题是什么、需要什么证据、典型动作序列、常见失败"。
5. Writing Strategy（写作策略）：以条目式收束全篇策略，包含中心目标、必要假设/约束、模型/方法/证据链、验证/敏感性/稳健性要求、图表角色、最终建议或结论的角色。

值得强调的是原文档中的一条纪律：该文件是体裁研究记录，不是结果清单；"计划不写成结果"是 current-method-routing.json 中对该方法的 review_check 之一。这与仓库中 research.md 的整体约束一致：记录实际读取的来源与实际计算的结果，不为凑"可复现性证据"而重跑脚本或编造分析。

四、模式一：建模竞赛报告（Modeling-Contest Report Pattern）

对于数学建模风格报告，原文档要求从规则与优秀范例中学习以下要素：

• 问题重述：把赛题提示词翻译成决策变量与目标（decision variables and objectives）；
• 假设：必须是必要、可检验的假设，而不是"仅仅为了方便"的假设；
• 符号表与变量定义：notation table 与变量说明；
• 模型构建：每个建模选择都要有清晰理由；
• 算法/求解过程：必须可复现（reproducible）；
• 验证：验证、敏感性分析、误差分析或稳健性检查；
• 优缺点：优缺点要与假设挂钩（strengths and weaknesses tied to assumptions）；
• 摘要/备忘录：若竞赛要求，给出简洁的 summary/memo；
• 图表：用图/表解释模型行为，而不是仅仅装饰结果。

原文档特别给出了一条重要告诫：

Do not over-academicize contest papers. Judges often reward clear problem decomposition, transparent assumptions, executable models, and persuasive validation more than literature-style novelty.

即不要过度学术化竞赛论文：评审往往更看重清晰的问题分解、透明的假设、可执行的模型和有说服力的验证，而不是文献式的新颖性。这条告诫与 scenario-competition.md 中的表述互相印证——"Competition writing should optimize for the stated evaluation criteria, not for generic journal style"（竞赛写作应针对既定评分标准优化，而非通用期刊风格）。

配套场景指南：Competition 官方资料清单

scenario-competition.md 给出了竞赛场景下需要查找并记录的官方来源清单：

• 竞赛官网（competition website）
• 规则（rules）
• 问题陈述（problem statement）
• 评分标准（scoring rubric）
• 提交模板（submission template）
• 页数限制（page limits）
• 资格与格式约束（eligibility and formatting constraints）
• 官方通知（official notices）
• 可得的高分/获奖范例（winning or high-scoring examples when available）

同时要求向范例学习：高分作品如何陈述假设、如何论证模型或方法、如何可视化结果、如何呈现敏感性/稳健性/局限性、如何写执行摘要或摘要。该场景指南在 current-method-routing.json 中登记为仅当configuration.scene=competition时启用，并强调"官方当届规则可追溯；不套期刊章法，不造获奖/评分保证"。

五、模式二：技术 / 白皮书报告（Technical/White-Paper Report Pattern）

对于技术报告、政策报告或决策报告，原文档列出以下要点：

• 识别决策者与决策问题（identify the decision-maker and decision question）；
• 分离事实、假设、分析与建议（separate facts, assumptions, analysis, and recommendation）；
• 把最具可操作性的结果放在前面（put the most actionable result early）；
• 用图表支撑决策（use figures/tables to support decisions）；
• 直白地陈述不确定性与实施约束（state uncertainty and implementation constraints plainly）。

这套逻辑与 scenario-report-review.md 的场景化指南配套：课程/部门/项目页面、作业说明、rubric、规定章节顺序、格式与引用要求、评审范围与期望深度、评分/评估标准都要记录；范例学习聚焦于"预期受众的知识水平、背景与贡献的平衡、证据组织方式、方法/文献的综合方式、在 rubric 下什么使报告有说服力"。该场景指南同样强调："Do not force reports into a journal-paper structure unless the target requires it"——除非目标体裁明确要求，否则不要把报告硬塞进期刊结构。

六、模式三：Proposal / 基金申请式文档（Proposal/Grant-Like Pattern）

对于 Proposal 风格文档，原文档列出：

• 制造紧迫感与契合度（create urgency and fit）；
• 定义可行的目标结构（define a feasible aim structure）；
• 把方法与风险、里程碑连接起来（connect methods to risks and milestones）；
• 展示预期成果与应急预案（show expected outcomes and contingency plans）；
• 避免写得好像结果已经存在（avoid writing as if results already exist）。

最后一条是 Proposal 写作最容易踩的坑：申请书的本质是"承诺将要做什么"，而不是"汇报已经做了什么"。这与 current-method-routing.json 对该方法的 review_check"计划不写成结果；缺验证报限制，不能自动分析"一脉相承——体裁研究阶段就应识别出这种结构陷阱，防止在正文中把计划包装成已完成的验证。

七、红旗清单（Red Flags）：体裁研究需要拦截的信号

原文档在末尾给出六条红旗，写作前应逐条自查，命中任何一条都说明体裁研究尚未完成：

• 结构错位：目标体裁奖励另一种结构，文档却沿用了期刊 IMRaD 结构；
• 问题重述空洞：问题被重述，但没有变量、约束或与评审者相关的目标；
• 假设通用化：假设是泛泛而谈、后面从未被使用；
• 模型无验证：模型被描述但从未被验证；
• 结果无落点：结果只被罗列，没有决策、建议或与评分相关的解读；
• 范例学习浅层化：范例学习只复制了表面排版，却错过了评价逻辑。

这六条红旗本质上是把体裁研究的五个模块（任务身份、评价逻辑、范例学习、章节蓝图、写作策略）转成了检查谓词：结构错位对应"评价逻辑"缺失，问题重述空洞对应"任务身份/评价逻辑"缺失，假设通用化与模型无验证对应"证据标准"缺失，结果无落点对应"写作策略"缺失，范例学习浅层化对应"范例学习"方法错误。

八、在 PaperSpine5 中的落地方式

Task-Genre Research 不是孤立文档，而是嵌入在 PaperSpine5 的配置、路由与研究模式体系中的：

1. 场景（scene）配置：intake.md 记录了任务配置字段表，其中scene字段的可选值为journal、conference、report_review、competition。也就是说，体裁研究在 PaperSpine5 中以"场景"形式出现在任务配置里；competition场景即触发 scenario-competition.md，report_review场景对应 scenario-report-review.md，此外还有 scenario-conference.md（截止期限驱动的同行评审场景）与 scenario-journal.md（期刊正式出版场景）。

2. 方法路由：current-method-routing.json 将references/task-genre-research.md登记为研究（research）、写作（draft）、评审（review）三个阶段都可选用的方法，并在 current_application 中注明："根据实际 scene/用户体裁解释适用子方法，全文读后在 notes 标适用；保存 research_mode 约束实验/新分析；普通期刊无需伪造竞赛指标。" 同时 current-method-routing.md 给出了从当前宿主读取该方法的命令方式：

python scripts/paperspine5_web.py host methods --local --task-id "<same-task>" --stage research --resource references/task-genre-research.md --format text --max-lines 100

3. 研究模式约束：research.md 定义了materials_only、required、agent_decide三种研究模式。体裁研究属于"公开文献/场域学习"的常态能力，在任何模式下都可进行；但是否执行新分析、是否重跑脚本则由research_mode约束——materials_only禁止新实验，required要求在授权素材内做最小必要分析，agent_decide则由 Agent 判断新分析是否实质回答缺口。这一点直接落到体裁研究的边界上：竞赛场景下"优秀例子不能授权新实验"（见 current-method-routing.json 对 scenario-competition 的说明），缺验证时应报告限制而不是自动补跑分析。

4. 评审纪律：体裁研究的产出在评审阶段使用——current-method-routing.json 对该方法的 review_check 是"对准评价任务且有证据；计划不写成结果；缺验证报限制，不能自动分析"。这意味着genre_research.md本身也要被复核：它是否对准了真实的评价任务、每一条结论是否有官方规则或范例证据支撑。

九、与其他参考资料的分工

Task-Genre Research 与仓库内多篇参考资料形成互补，写作时可组合引用：

十、实战自查清单

完成体裁研究并动笔之前，建议按以下顺序自检：

1. 是否已经识别受众与评价标准（而不是默认期刊评审）？
2. 是否把官方规则/评分标准翻译成了可执行的写作动作（Evaluation Logic 表）？
3. 是否从强范例中提取了可迁移模式，并明确标注了"不要复制"？
4. 是否为每个章节写下了"读者/评审者的问题 + 所需证据 + 典型动作序列"（Section Blueprint 表）？
5. 是否明确了图表角色——是解释模型行为/支撑决策，还是仅为装饰？
6. 是否逐条对照红旗清单：结构错位、空洞重述、通用假设、无验证模型、无落点结果、浅层范例学习？

如果以上全部通过，即可进入该体裁的正式写作；反之则回到体裁研究，补全缺失模块。这套方法的价值在于：它把"不同体裁要写得不一样"这句直觉，落实成了一条可执行的推导链、一张可复用的输出模板和一份可对照的红旗清单，从而让 PaperSpine5 的"先学后写"方法论在期刊论文之外的所有论文类任务上同样成立。

• AI 技能
• AI 写作
• 人工智能
• 深度研究
• AI 应用