mcpField
A
academic-writing-skills

academic-writing-skills

github.com/wenyuchiou文档处理165139 次安装今天更新
代码仓库

关于 academic-writing-skills

academic-writing-skills 是一套用于规划、撰写、审阅和修改学术稿件的技能指南。它帮助作者保留证据与既定决策,按任务范围选择检查方式,并协调稿件章节及配套文件。

主要功能

  1. 01按范围和稿件阶段分配任务
  2. 02依据主张与证据规划段落
  3. 03检查证据、推论和主张边界
  4. 04协调正文与配套文件
  5. 05应用研究设计专属审阅指引

适用场景

  1. 01规划或修改稿件章节
  2. 02核对主张是否符合现有证据
  3. 03协调完整稿件与补充材料

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/wenyuchiou/academic-writing-skills --skill academic-writing-skills

安装后在 Claude Code 中输入/academic-writing-skills确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

agents/
openai.yaml
assets/
icon.svg
manuscript_state_template.json
references/
banned_words.md
comment-scoped-revision.md
conclusion-and-abstract.md
discussion-and-limitations.md
evidence-context-cases.md
execution-and-acceptance.md
figures-tables-and-supplements.md
independent-reader-review.md
introduction-and-study-context.md
lifecycle-and-routing.md
methods-and-assumptions.md
overlay-contract.md
professor-teaching-cases.md
prose-and-citation-editing.md
results-and-explanation.md
reviewer-red-team-and-release.md
reviewer-response-workflow.md
state-and-authority.md
study-design-adapters.md
universal-integrity.md
scripts/
audit_candidate_text.py
audit_docx_structure.py
audit_handoff.py
audit_manuscript_state.py
audit_prose_patterns.py
audit_text_consistency.py
init_manuscript_state.py

详细介绍

学术写作技能

基本原则

在保留作者的证据、预期含义和已敲定的决策的同时,使学术论证清晰、可复现、前后一致,且不超出证据所能支持的范围。绝不编造结果、机制、引文、元数据、分析或领域要求。

将稿件视为不断演进的证据系统,而非彼此孤立的文字。遵循作者的写作顺序,但如果后续证据对早期章节产生影响,就重新审视这些章节。

确定任务路径

首先识别:

  • 所请求的操作:规划、起草、审阅、修订、校对或确认是否已具备就绪条件
  • 成果范围:句子、段落、小节、章节、整篇稿件、补充材料或投稿材料包
  • 变更影响和可用的核验来源,分别于成果范围加以判断
  • 稿件类型和研究设计
  • 生命周期阶段和审阅成熟度
  • 权威来源、当前文件和历史参考资料
  • 用户锁定的措辞、事实、术语和决策
  • 是否授权编辑,或任务是否仅限于诊断

对于范围明确的文本工作,使用轻量模式。对于整篇稿件整合、配套文件协调或发布就绪认证,使用项目管理模式;在该项目中处理局部工作时,复用现有的项目管理上下文。项目管理上下文不会把段落编辑变成整篇论文审计。根据所请求的操作、文本范围、变更影响和来源可用性,按照 lifecycle-and-routing.md 确定检查路径。

在项目管理模式下,阅读 state-and-authority.md,并复用等效的项目记录。只有在持续协调确实需要记录且尚无记录时,才使用 scripts/init_manuscript_state.py 初始化项目状态模板。不要为一次性编辑创建项目管理机制,也不要仅仅因为开始了新一轮对话就重新初始化状态。

如果用户提供了项目术语,或持续写作需要共享词汇表,则使用 state-and-authority.md 中的术语流程;在该项目中进行局部工作时也适用。写作前阅读相关的已确认条目;将新建议与已确认选项分开,并区分已配置的扫描结果与词汇表的完整性。

确认期刊方向、格式和风格

对于面向期刊的规划、实质性重组、图表和参考文献格式设置或投稿检查,首先确认目标期刊、文章类型、读者群体和发表阶段。使用 overlay-contract.md 中的 Venue Profile,区分科学方向、已核实的要求、风格示例和项目偏好。复用当前的期刊配置文件;应用变更或不确定的官方要求前,先行核实。仅限语法的编辑不会触发期刊重新选择或整套材料审计。如果尚未选定期刊,则建议应保持暂定,不得虚构合规性。

将展示指南和覆盖层契约中的 ABM 示例作为以来源为依据的推理辅助,而非全期刊通用模板,也不将其视为对原论文的认证。

对于扩展大纲请求,阅读 professor-teaching-cases.md 中的段落开篇格式和示范框架。优先遵循作者提供的示例;通过实际或拟议的段落开篇句使论证易于理解,并在相关位置附上引文和证据需求。只有在用户请求摘要、审稿意见回复或展示示例时,才使用该文件中的其他案例;不要加载所有示例,也不要把仅限语法的编辑扩大为章节审阅。

遵循稿件生命周期

将工作映射到以下生命周期,但不要强行让最终文章的顺序与写作顺序一致:

  1. 确立项目权威性、稿件类型和目标投稿期刊
  2. 编写扩展大纲、引言、研究缺口、问题和计划贡献
  3. 编写研究背景、数据、理论和方法
  4. 根据已核实的分析、图、表或来源证据构建结果
  5. 编写讨论、替代解释、启示、局限和未来工作
  6. 根据已稳定的证据图谱综合撰写结论
  7. 根据当前稿件重新拟定标题、摘要、要点和概要
  8. 核对参考文献、并行编写的补充材料、元数据和投稿文件
  9. 对确切的交付文件执行发布检查

在每个阶段,都要检验以下两个方向的相关对齐情况:

  • **自上而下:**目的或研究缺口 → 问题或目标 → 方法 → 预期证据
  • **自下而上:**来源证据 → 结果 → 解释 → 贡献和摘要主张

阅读 lifecycle-and-routing.md,了解阶段关卡、审查成熟度、非 IMRAD 路由和变更影响类别。

规划、起草或重组引言或研究背景部分时,请阅读 introduction-and-study-context.md。该文档指导章节功能和内容安排,不规定固定段落数量或强制文章结构。范围有限的语言编辑则使用局部行文检查。

规划或编写方法部分,或实质性澄清某个情境的来源、理由或假设状态时,请阅读 methods-and-assumptions.md。要区分数值或规则的来源、其应用假设,以及验证证据。将假设示例用作推理辅助,而非已核实的研究事实。

仅在所请求的读者功能或受影响的依赖项需要时,加载其余指南:

每章完成或进行重大修订时,都要执行 lifecycle-and-routing.md 中的章节收尾盲点检查。此检查点为必需项;应根据研究设计、内容和证据选择诊断问题。对于仅涉及语法的编辑,不要执行完整的章节审查,也不要声称已穷尽地发现所有未知问题。

根据明确的写作约定起草

在起草大纲、章节或段落之前,先明确其读者功能、核心论点或问题、可用证据、推论边界,以及与相邻内容的衔接关系。对于段落,使用以下简明约定:

  1. 功能:该段落必须达成什么目的
  2. 论点:最窄且站得住脚的核心观点
  3. 证据:支持该观点的来源、结果、引文或推理
  4. 展开:如何解释证据,而不额外引入机制
  5. 衔接:引出下一段的关系

起草或进行实质性改写之前,先按照 universal-integrity.md 进行起草前逻辑检查:同时检查段落内部的推进逻辑,以及相邻段落之间的关系。根据请求范围匹配检查深度;局部编辑不需要重新规划整个章节。

只有在约定和信息顺序都连贯后,才能起草。起草后,将段落与约定逐项对照,并重读其前后段落。如果段落的功能、证据或位置有误,不要只把它润色得更流畅。

对于由评论或选区驱动的编辑,先按照 comment-scoped-revision.md 操作:核实当前选中的文本和完整评论串,区分阅读范围与编辑范围,并将确切的候选文本与授权边界进行对照。不要用整个段落替代选区,也不要因为较广泛的明确指令锚定在标题上,就将其误解为只要求修改标题。

对于实质性起草或格式化文件编辑,在起草之前先阅读 execution-and-acceptance.md。采用其中的读者阅读路径以及图注/正文/补充材料分配,然后在首次交付前完成其规定范围内的检查。保留作者的主要比较,再呈现依赖于它的亚组或模型细节;这并不意味着必须遵循一种通用的比较顺序。

使用该指南中的阶段检查清单,将大纲、起草前规划、编辑后检查、章节收尾和全文审阅与具体记录关联起来。局部交接保持简洁,并在章节/全文审阅节点扩充记录;复用共享项目状态,不要另建一套术语表或检查清单体系。

将句与句之间的读者连贯性作为首次交付前及任何实质性修改后的高优先级验收门槛。对于流程描述,使用 工作流交接测试;将读者发现与扫描结果区分开来。对于局限性文字,还要应用 discussion-and-limitations.md 中的约束与缺陷分类:描述有文档依据的边界及其影响;对于可修正的错误,应予以纠正,而不是将其重新描述为局限性。纯语法层面的局部编辑不需要纳入这项扩展检查。

还要明确预期读者可能具备的知识。对于跨学科论文和审稿人回复,假设读者了解更广泛的研究领域,但不了解研究内部术语、模型顺序、数据转换或早期起草过程。在需要之处提供读者所需的最低限度背景;不要让读者从后文自行推断。

对于明确要求的独立可读性审阅、依赖概念理解的实质性章节,或反复出现的理解障碍,请加载 independent-reader-review.md。使用其中限定范围的冷读者流程和实例,找出首次出现时未作解释的术语;不要对纯语法编辑强制进行多 Agent 审阅,也不要将 AI 读者角色说成是人工验证。

应用通用完整性关卡

始终在请求范围及直接受影响的依赖项中考虑这些关卡。判断其适用性;不要因每次局部编辑就重新运行所有整篇论文检查:

  1. **权威性:**依据已确认的来源得出事实;不要根据格式或旧稿推断作者角色、经费、样本量或方法。
  2. **契约:**保留已锁定的研究缺口、任务、问题、结果、贡献和明确的非主张,除非用户授权进行语义变更。
  3. **对齐:**将受影响的问题或目标与其方法、证据、实质性回答和推论边界联系起来;在整篇论文审查时检查完整映射。
  4. **方法与证据完整性:**提供足够的细节,以便理解证据是如何产生的,以及哪些假设限定了推论。
  5. **主张范围:**区分方向、幅度、不确定性、显著性、等效性、因果关系、机制、预测和可推广性。
  6. **跨材料同步:**将实质性变更同步到所有受影响的章节和配套材料。
  7. **版本完整性:**明确一个有效发布版本,并将其与历史引用区分开来。
  8. **发布完整性:**只要仍存在高严重级别的阻碍项或尚未解决的必需来源,就不要使用 FINAL、VERIFIED 或 SUBMISSION_READY。
  9. **文稿完整性:**每个概念使用一个术语;使用 prose-and-citation-editing.md 检查跨学科可读性和名词链清晰度;区分必要的技术性重复与可避免的措辞重复;检查段落之间的衔接,不要用同义词轮换来掩盖重复。

阅读 universal-integrity.md,了解段落、摘要、结论、证据、术语、引用和四轮审查规则。

选择研究设计适配器

根据研究设计选择适配器,而不是根据学科标签。仅加载 study-design-adapters.md 中相关的部分:

  • 定量观察性研究或调查研究
  • 实验或准实验
  • 定性研究
  • 混合方法
  • 计算模型或模拟
  • 基于 AI/LLM 的研究
  • 证据综合、综述或荟萃分析
  • 理论、概念、框架、方法或数据论文

如果研究设计确实为混合型,则结合使用适配器。将适配器检查视为需要论文证据回答的问题,而不是认定某种方法使用不当。

安全地叠加外部要求

将提供的领域技能、审稿人评分标准、教授检查清单、报告标准或期刊指南作为叠加要求应用。应用前阅读 overlay-contract.md。

将叠加规则分类为:

  • 研究设计要求
  • 领域惯例或技术检查
  • 审稿人偏好或语气
  • 投稿场所要求
  • 项目特定事实或决定

切勿将叠加规则提升为通用规则。如果叠加规则与证据、作者指示、伦理要求或可辩护的推论相冲突,应保留证据并报告冲突。要求解释“为什么”并不代表可以提出缺乏依据的机制。

应用已登记的项目工作流

当项目、文件夹、论文或用户请求指出 Survey paper、PiDS 或 WC_vX 论文时,应将已安装的 survey-paper-wcvx 技能与这些通用完整性关卡结合使用,作为项目状态和审稿轮次的叠加要求。将该项目的文件名、作者身份、优先级方案和版本规则保留在项目叠加要求中。

处理审稿人回复

对于答辩信、审稿意见回复文档,或对导师编辑过的回复草稿进行修订,请阅读 reviewer-response-workflow.md。 结合当前稿件状态和提供的实验室示例,使用其中的意见台账、回复顺序、证据、交叉引用和格式化文档检查。明确区分面向审稿人的文字、稿件或补充材料的修改,以及给导师的内部回复。较高层次的综合回复可以引导读者查看后续细节,但对某个问题的第一段实质性回复必须说明为回应该意见所做的修改、证据、解读、对稿件的影响,以及仍需明确的边界。

控制实质性修改

编辑前,先对每项拟议修改进行分类:

  • **A 类 — 语义约定:**研究空白、任务、问题、结果、贡献、因果或验证框架
  • **B 类 — 证据或方法:**数据、样本、模型、分析、数字、图、表、局限性
  • **C 类 — 元数据:**作者、所属机构、资助、角色、声明、仓库链接
  • **D 类 — 表层修改:**语法、标点、格式、局部清晰度,不涉及科学内容变更

宣布修改完成前,请运行相应的影响扫描。A 类修改通常需要重新审视整个证据链和所有摘要。B 类修改需要重新审视受影响的方法、结果、解读、可视化内容、补充材料和摘要。C 类修改需要重新审视所有投稿材料和元数据字段。D 类修改需要进行局部语义差异检查和格式化文件检查。

未经受保护上下文检查和修改后差异检查,不要对公式、字段代码、引用、XML 或元数据进行全局替换。

将确定性审计作为证据,而非判断

对于受管理的项目,请在适用时使用捆绑脚本:

  • scripts/audit_manuscript_state.py:验证状态完整性、来源链接、问题对齐、维度覆盖情况和发布阻断项
  • scripts/audit_text_consistency.py:从受支持的文件中提取文本,并扫描已登记的锁定字符串、禁用变体和事实冲突
  • scripts/audit_prose_patterns.py:报告完全重复内容、重复的开头和短语、套话,以及可能过度使用的非技术词语;不据此断定文本由 AI 撰写
  • scripts/audit_candidate_text.py:根据当前项目术语、禁用变体和行文特征,扫描确切的拟议段落并记录其哈希值
  • scripts/audit_handoff.py:可选地验证依赖范围的覆盖记录和确切文件哈希值;COVERAGE_COMPLETE 不代表编辑或科学认证
  • scripts/audit_docx_structure.py:使用确切的标签名称检查 Word OOXML,包括修订、修订作者、批注、带父级链接的回复、回复作者、字段和占位符
  • scripts/run_regression_tests.py:使用捆绑的失败用例验证审计工具

将脚本发现视为诊断信息。编辑前,请结合上下文检查每处匹配。脚本报告无异常,也不能替代实质性阅读。

在交付前核查确切候选稿

最后一次措辞修改后,冻结将要交付的确切段落或内容。复用相关的有效状态条目和适用的叠加规则,包括在受管理项目中进行本地工作时。不要仅仅因为无关的项目历史或审计配套文件存在,就加载它们。然后,根据所请求操作的要求和修改影响,按相应深度执行以下步骤:

  1. 将确切候选稿与其写作约定、已锁定的含义、证据和相邻段落进行比较;
  2. 检查新增、删除或语义受影响的引文是否与其论断及参考文献列表相符;对实质性段落的审查还应检查保留的论断是否仍有引文支持,而仅涉及语法的工作应保留已核实且未更改的支持,并说明任何核查限制;
  3. 对确切候选稿本身进行术语、禁用变体、重复、套话和项目不建议用语检查;
  4. 结合上下文检查并处理每项确定性问题,或记录作者明确批准保留该问题的理由;以及
  5. 记录已核查的候选稿;若有确定性候选稿审计可用,则记录其哈希值。

在首次交付草稿前,使用 execution-and-acceptance.md 记录针对读者理解、累积推进,以及每个受影响的图注、已保存布局、投稿场合格式依据和新的编辑/回复身份的具体定位问题。记录可简要写在文内或复用现有项目记录;JSON 非必需。缺失或无法进行的检查仍属于未完成,而非已通过。语言扫描的 PASS 绝不能替代这些检查。可以交付附有明确限制的临时草稿,但不得将其称为已全面核查或符合期刊要求的成稿。

修改散文时,请从 prose-and-citation-editing.md 中选择适用的功能性检查:衔接、保留功能的精简、自然的学术文风、论断与引文的一致性、可观察到的套话或类似 AI 的特征,以及破折号/连字符风格。修改标点时需要保持含义,而不需要重新进行文献审计。将诊断结果视为判断参考,而非普遍禁令或作者身份检测依据。

对于实质性的稿件章节、摘要、答辩回复,或明确要求的禁用词审计,还应对照 banned_words.md 检查确切候选稿。将每个匹配项视为需要结合上下文判断的提示,而非必须自动删除的内容或 AI 作者身份的证据;并应优先遵循任何项目特定的写作约定或术语覆盖规则。

通过此关后进行的任何编辑都会使核查结果失效。若要称措辞已核查、定稿、润色完成或可直接粘贴,请重新执行所有受影响的候选稿检查。若只审计了较早的草稿、周围的稿件或未更改的源内容,绝不要声称 academic-writing-skills 已通过。

完成四轮不同的审查

审查整篇论文或投稿材料包时,请从头到尾完成四轮审查。对重要小节或章节进行修订时,请将这四轮审查应用于该单元及其受影响的依赖项;范围有限的语言编辑则使用局部候选稿关卡:

  1. **论证与结构:**读者需求、目的、问题、组织结构、段落开头和贡献。
  2. **证据与范围:**方法、数据、结果、图、表、引文、不确定性、主张力度以及跨文件传递情况。
  3. **学术写作:**清晰度、自然的主语、术语、必要与可避免的重复、句首多样性、可观察到的套话、段落衔接、句法、时态、语态和符号规范。切勿仅凭文风就将文字判定为 AI 生成。
  4. **交付完整性:**摘要、参考文献、编号、元数据、准确的文件名、修订痕迹、视觉呈现和发布阻断项。请大声朗读修订后的文字,或模拟日常口语阅读。如果某个句子由研究人员说出来会显得不自然,或只有重读后才能明白其含义,请调整句法、指代对象或信息顺序,同时保持学术语言的严谨性。

如果后续一轮发现实质性问题,请修正并重新执行所有受影响的上游和下游检查。不得将先前的审查轮次视为仍然有效。

每次检查结束时都进行功能完整性回顾

每次审查、修订轮次、审计或发布检查后,在报告完成情况前,务必明确回顾任务的功能覆盖情况。请自问:

  1. 是否覆盖了所要求的生命周期阶段和范围内的每项产物?
  2. 是否保留了锁定的含义,并参考了正确的权威来源?
  3. 所有受影响的问题、方法、结果、解读、局限性和摘要是否仍保持一致?
  4. 是否运行了所有相关的研究设计适配器和叠加规则,且未将其误作普遍假设?
  5. 变更影响扫描是否覆盖上游、下游和配套文件依赖项?
  6. 是否仍存在未知事项、无法获取的来源、未解决的问题、豁免或高严重性阻断项?
  7. 是否在适用时使用了确定性、结构性和视觉检查,并说明了这些检查的局限?
  8. 检查的是准确的交付文件,而非中间副本吗?
  9. 准确的编辑后候选稿是否通过了适用的项目规范检查?所有发现是否已解决,或已说明理由并明确保留?

请根据双方约定的范围回答这些问题,而非涵盖所有可能的产物。如果必要答案为否或未知,请继续开展范围内安全可行的工作,或报告相关限制。请区分已检查、不适用、超出所请求范围和来源不可用/未经核实;被排除的检查不算通过。切勿将此回顾简化为笼统的“所有检查均已通过”。

请阅读 reviewer-red-team-and-release.md,了解反向遗漏测试、问题严重性、就绪标准和最终报告格式。

处理格式化文件

对文件格式进行操作和视觉核验时,请使用专用的文档、电子表格、演示文稿或 PDF 技能。本技能负责学术完整性;它不能替代特定格式的渲染、修订痕迹或 OOXML 工作流。

报告结果

开篇说明就绪状态和剩余阻断项。仅报告实际执行过的检查。请说明:

  • 修改了什么,保留了什么
  • 科学含义、证据、数字、引文或元数据是否有变化
  • 检查了哪些产物和生命周期关卡,哪些不适用、超出范围或未经核实
  • 未解决的问题、无法获取的来源或明确豁免
  • 功能完整性回顾的结果

如果证据仅支持部分审查或有条件的审查,就不要将稿件称为最终稿。

评论

支持 Markdown