academic-humanizer：让 AI 起草的论文和基金申请书保留学术精度
Strip AI-writing tells from papers and grant proposals (NSF/NIH), while keeping scholarly voice and tying claims to evidence. A skill for Claude Code, Codex, and MorphMind.
秒懂
- 它是什么？
- 这是一个 Claude Code skill，针对论文与 NSF/NIH 申请书做编辑处理，删除通用 AI 腔调但保留数字、引用与证据强度。它的价值在于「不做什么」，局限也在于此。
- 适合谁用？
- 适合的人群很具体：已经在用 Claude Code、Codex 或 MorphMind 起草论文或基金申请书，并且手上有一批自己以往被接收的论文或获批的申请书可以拿来校准声音的研究者。不适合的人同样具体：想用它规避 AI 检测的人（README 明确说不是为此设计），以及不做任何本地化就直接套用的团队，因为规则反映的是作者团队自己的行文习惯。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库最近一次提交在 75 天前。
- 用什么语言写的？
- GitHub 没有给出这个仓库的主要语言。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它针对的不是「AI 味」，而是精度流失
市面上叫 humanizer 的工具大多面向博客和营销文案，把文本改得更口语、更随意。把这个流程套到论文或 NSF 申请书上，第一个被抹掉的就是学术写作赖以成立的精确措辞。academic-humanizer 的出发点正好相反：它承认 AI 辅助起草会带来「In recent years...」这类空洞开头、膨胀的措辞和过长的句子，但处理目标是在清理这些腔调的同时，把数字、引用和论断强度原样留下。
README 里给的那组对照很能说明取向。改写前的版本堆了 remarkable success、cutting-edge、delve into、paving the way、transformative paradigm、revolutionize 一整套词，改写后变成「Continual learning matters, but today's methods stay empirical and their principles are unclear」，然后直接列出三个方向（adaptation、soft supervision、cross-domain knowledge）和两个验证场景。句子变短了，信息密度反而上去了。
目标用户是已经在用 AI 起草、又必须对投稿内容负责的研究者。README 的「Why we built this」写得很直白：作者团队自己写论文和申请书，用 AI 帮忙起草后发现草稿偏离了本人声音，于是拿 AI 草稿和团队已接收的论文、已获批的申请书做比对，人工梳理差异，据此定规则。这不是一个通用产品，是一个团队把自己写作习惯固化成检查表的结果。
六层规则的实际分工：从通用腔调到基金申请书
README 的 How it works 一节列出六层：通用 AI-tell 目录、学术专用 tell、保留学术惯例、claim 与 evidence 匹配、声音与目标期刊校准、基金申请书模式。前两层是删除，第三层是保护，第四层是约束，第五、六层是参数化。
第三层值得单独说，因为它决定了这个 skill 的边界。README 明确列出不动的东西：与证据绑定的 hedging、合适语境下的被动语态、we 的用法、定义、符号，以及全部引用。第四层则规定动词强度不能超过数据支撑，prove 要降为 show empirically，含糊的量级要变成带出处的区间。这两层合起来构成一个约束：改写只动表达，不动事实层。
第五层是声音校准，用法是在调用时提供自己以前的论文，让 skill 对齐风格。第六层单独为基金申请书准备，README 说它保留论文版会砍掉的 vision，并把主要精力放在前几页，理由是评审人打分就看这几页。这个判断本身是经验性的，README 没有给出支撑数据，只能算作者团队的实践总结。
六层之间的执行顺序和审计、改写循环写在 SKILL.md 里，README 只是概括。要真正评估这套规则是否适合你的领域，必须去读 SKILL.md 的原文，README 这一节的信息量不足以判断。
安装与调用：一条 git clone 加一个斜杠命令
安装只有一条命令，README 给的形式是：
git clone https://github.com/AIScientists-Dev/academic-humanizer ~/.claude/skills/academic-humanizer
克隆到 Claude Code 的 skills 目录即可。README 说明它本质是一个 SKILL.md 加若干示例文件，所以同样的内容也能作为 Codex 和 MorphMind 的 skill 或 system prompt 使用，做法是让 agent 指向 SKILL.md。
调用形式是斜杠命令加粘贴内容或文件路径：
/academic-humanizer [paste a section, or point at main.tex]
README 还给了可选的附加参数示例：「match my voice from prior_paper.pdf; target venue: ICLR」。也就是说声音校准和目标期刊校准是通过自然语言附加说明触发的，不是配置文件里的键值对。
仓库里能确认的路径有两个：SKILL.md 定义规则和审计改写循环，examples/before-after.md 收了更多前后对照，README 提到其中包含一个通用例子、一个 NIH Specific Aims 页面和一个已获批的 NSF CAREER summary。除此之外没有看到配置文件、依赖清单或 CLI 参数表。
「不改数字和引用」是承诺，也是需要你自己验证的部分
README 反复强调不改变任何数字和参考文献，这一条是整个工具可信度的支点。但要注意它是文档层面的承诺，不是可验证的机制描述。README 没有说明 skill 用什么方式保证数字不被改写，是逐条比对、还是靠规则约束模型行为。
从工程角度看，靠 prompt 规则约束模型不去动数字，属于软约束。真正稳妥的用法是在改写后自己 diff 一遍原文和改写稿，重点看所有数值、单位、引用编号和图表编号。README 没有提供自动校验脚本，所以这一步得手动做。
同样需要留意的是「no verb stronger than the data」这条规则。它要求把 prove 降级为 show empirically，把含糊量级替换成带出处的区间。这个动作本身需要判断力：哪个动词配得上当前证据，模型未必比你清楚。如果草稿里的论断强度本来就经过了仔细斟酌，自动降级反而可能削弱你想表达的东西。规则是死的，证据强度是活的。
声音校准依赖你的旧作，没有旧作就没有校准
第五层声音校准要求提供本人以往的论文。这对资深研究者不是问题，对刚起步的人就是硬门槛。README 里「Make it yours」一节建议 fork 仓库，指向几篇自己过去的论文，保留适合本领域的检查项，调整其余部分。这个建议本身承认了默认规则只反映一个团队的声音。
如果直接拿默认规则去改一个研究方向、写作习惯都不同的作者的手稿，结果可能只是把一种腔调换成另一种腔调。更麻烦的是，你很难察觉这种偏移，因为改写后的文本读起来确实更干净了。
README 对这一点态度坦诚，说「It is meant to be personalized, not a one-size-fits-all filter」。这句话应该被当作使用前提，而不是营销话术。没有可校准语料的使用者，要么先积累，要么接受默认规则带来的风格漂移。
和 blader/humanizer 的区别在于保留什么
README 的致谢部分交代了来源关系：这个 skill 复用了 blader/humanizer 的通用 AI-tell 目录，也就是第一层，并在此基础上为学术文本做了扩展。两者的差别不在删除哪些模式，而在删除之后保留什么。
blader/humanizer 面向博客、口语和百科类文本，这类文本里被动语态、hedging、we 的用法通常都是要清理的对象。academic-humanizer 把这几类明确列为保留项，因为它们在学术写作里有功能：hedging 表达证据强度，被动语态在方法描述里比主动更自然，we 是学术共同体的标准自称。同一个模式，在两类文本里的处理方向相反。
README 还提到 koaeraser/ARMS，那是一个覆盖选题到修订稿的自主流水线，范围比这个 skill 大得多。academic-humanizer 把自己定位成单点编辑：只做一遍编辑，不做选题、不做实验设计、不做稿件生成。这个自我限定是它的优点，也是它的天花板，指望它承担整条写作流水线的角色会失望。
维护成本、许可证与需要自己核实的地方
从仓库材料看，这个项目没有依赖、没有构建步骤、没有需要持续跟踪的上游库，维护成本主要落在规则本身。每次你调整 SKILL.md 里的判断标准，都要重新检查它对你既有稿件的影响，因为规则是自然语言写的，改动的影响面不像代码那样容易回归测试。
版本号在 README 徽章里显示为 0.3.2，本次抓取没有取到 release 记录，所以版本节奏无法判断。仓库未归档，最后推送时间在 2026 年 7 月。
许可证存在一处需要你自己确认的不一致：README 正文和徽章都写 MIT，但仓库元数据里的 license 字段是 NOASSERTION。这种情况通常意味着 LICENSE 文件的内容无法被自动识别为标准 MIT 文本，也可能只是识别失败。如果你打算 fork 后用于正式投稿流程，打开 LICENSE 文件核对一遍原文是必要的，这里不做法律判断。
关于伦理，README 有一段明确的声明：这是编辑辅助工具，不生成发现、不编造数据、不改引用，也不是为规避 AI 使用检测而设计；使用它不解除你向投稿venue 披露 AI 协助的义务。
基金申请书模式为什么把力气花在前几页
第六层是唯一带领域结构的层。README 说它保留论文版会砍掉的 vision，并把大部分处理量放在前几页，理由是评审人打分看的就是这几页。这个设计选择有明确的取舍：论文写作追求克制，申请书写作需要在开头建立说服力，同一段文字在两个场景下的最优形态不同。
README 提到这一层还包含 claim 与 feasibility 的匹配，也就是论断不仅要对应证据，还要对应可行性。这个约束比论文版的 claim↔evidence 多了一个维度。
但 README 同时划了边界：第六层提炼的是 NSF 和 NIH 申请书的结构中相对稳定的部分，具体的页面限制、格式要求和截止日期必须查官方来源。README 给出了三个链接：NSF 的 PAPPG、NSF CAREER 项目页、NIH 的 Write Your Application 指南。这个提醒很重要，因为基金申请的格式要求会变，任何把格式规则固化在 skill 里的做法都有过期风险，作者选择不固化。
examples/before-after.md 里的 NIH Specific Aims 和 NSF CAREER summary 两个例子，是判断这一层实际改写力度最直接的素材。在决定是否用于真实申请书之前，这两个例子值得逐句读完。
编辑结论
适合的人群很具体：已经在用 Claude Code、Codex 或 MorphMind 起草论文或基金申请书，并且手上有一批自己以往被接收的论文或获批的申请书可以拿来校准声音的研究者。不适合的人同样具体：想用它规避 AI 检测的人（README 明确说不是为此设计），以及不做任何本地化就直接套用的团队，因为规则反映的是作者团队自己的行文习惯。动手前先确认三件事：克隆后打开 SKILL.md 看第 4 层 claim↔evidence 的具体判定规则是否与你的领域匹配；检查 examples/before-after.md 里 NIH Specific Aims 那一例的改写幅度是否超出你能接受的编辑边界；核对 LICENSE 文件，因为 GitHub 的 license 字段显示 NOASSERTION，而 README 和徽章都写 MIT，这两处不一致需要你自己确认。
社区笔记