别等论文写完再“去 AI 味”：给 DeepSeek Harness 加一个论文 Writing Guard

最近在用 DeepSeek Harness（DSH）做论文写作和返修时，我一直在想一件事：

写代码时，我们已经习惯了 ESLint、Type Checker、Test 和 CI。Agent 写出来的代码不会直接提交，而是要先经过一层确定性的质量检查。

但当 Agent 开始直接修改论文、维护 LaTeX、处理 reviewer comments 时，写作这一层往往缺少类似机制。

于是我做了一个 DSH 插件：

dsh-plugin-writing-guard

当前版本为 v0.5.2。

它是一个面向学术写作的 deterministic linter。规则通过本地正则和统计执行，不联网，也不需要额外调用 LLM。它关注的不是给论文计算一个“AI 率”，而是持续检查 manuscript 中容易暴露机器化写作习惯、返修过程以及不恰当学术表达的具体位置。(GitHub)

项目地址：

github.com/xmutfyh/dsh-plugin-writing-guard

一、为什么论文 Agent 也需要 Linter？

先看一个很常见的场景。

你让 Agent 帮忙修改论文，最后得到这样的内容：

This is not merely a technical improvement,
but a fundamental transformation.

We believe that the proposed method…

Rather than simply improving accuracy…

As requested by the reviewer,
we have updated the methods.

这些句子逐句看，未必存在语法错误。

问题出现在整篇文章的尺度上。

有些结构会被模型重复使用，有些表达在短时间内密度异常，还有一些本来属于返修信、内部笔记或者修改说明，却被带进了最终 manuscript。

比如：

As requested by the reviewer…

放在 rebuttal 里非常自然。

如果它出现在论文正文中，就值得在投稿前处理掉。

这类问题和拼写错误不一样，也很难靠传统 Grammar Checker 完成。

Writing Guard 做的事情很简单：

Agent 修改论文
↓
Writing Guard 审计
↓
定位具体写作问题
↓
把反馈交给 Agent
↓
继续修改

它更像论文工作流里的 Lint 层。

二、Writing Guard 会检查什么？

当前规则主要覆盖以下几类学术写作问题。

这里有一个很重要的设计：

单独出现一个词，并不会直接被判成问题

例如：

leverage

本身当然可以出现在正常的论文中。

rather than 也一样。

所以 Writing Guard 对频率类规则使用的是：

最低出现次数
+
每千语言单位密度

只有两个条件同时达到阈值才提示。英文规则使用英文词数作为分母，中文规则按照 CJK 字符数计算，双语文本不会简单混在一个总字符数里稀释。

例如当前规则中：

rather than
≥ 4 次
且 ≥ 1.0 / 千英文词

破折号
≥ 5 次
且 ≥ 0.5 / 千英文词

LLM 高频关联词
≥ 2 次
且 ≥ 0.4 / 千英文词

中文套话
≥ 8 次
且 ≥ 2.0 / 千字

因此，一篇 500 词的摘要和一篇 12000 词的完整 manuscript 不会使用完全一样的粗暴次数标准。

这也是 Writing Guard 和普通“AI 高频词表脚本”差异比较大的地方。

三、它知道自己正在检查什么文档

学术写作里，同一句话是否合适，很大程度上取决于文档类型。

Writing Guard 支持 document profile：

manuscript
rebuttal
cover_letter
review
notes
unknown

例如：

As requested by the reviewer…

在：

rebuttal

中属于正常表达。

在：

manuscript

中则会作为修改过程残留处理。(GitHub)

writing_audit 可以显式指定 profile，也可以结合文件路径自动判断。

所以检查逻辑不是简单的：

发现关键词
→ 报警

而是：

这是什么文件？
↓
这句话出现在什么环境？
↓
对应规则是否应该生效？

对于论文 Agent 来说，这一步非常关键。

毕竟 manuscript、rebuttal 和内部 notes 本来就不应该遵循完全相同的写作纪律。

四、正文、标题、参考文献、公式会分开处理

如果直接对整个 .tex 或 .md 文件跑正则，很容易产生大量误报。

举个例子。

假设参考文献中有一篇论文标题包含：

delve

显然不能因为 References 出现这个单词，就认为作者的正文存在异常 LLM 用词。

Writing Guard 会先对文档进行 preprocessing，把内容划分成不同 segment：

prose
heading
reference
code
math
table

不同规则只扫描对应的内容类型。(GitHub)

例如：

LLM 高频表达
修改过程残留
学术文体
↓
prose

而：

冒号标题
↓
heading

References、代码块、数学公式和表格默认不会被正文类规则直接扫描。(GitHub)

这使 Writing Guard 可以开始回答一个比“有没有这个词”更重要的问题：

这个表达出现在论文的什么位置？

五、它还知道自己位于哪个章节

除了 segment，Writing Guard 还支持论文 section detection，例如：

Introduction
Methods
Results
Discussion
Conclusion

这使一些规则可以基于论文结构判断，而不是单纯计算全文词频。(GitHub)

一个典型例子是 limitation。

论文在 Discussion 中说明研究局限很正常，甚至是规范学术写作应该包含的内容。

真正值得注意的是，同一类防御性表述是否反复散落在 Introduction、Methods、Results、Discussion 等多个区域。

Writing Guard 的 limitation-dispersal 因此关注跨章节分布，而不是看到 limitation 就提示。(GitHub)

这类规则特别适合 Agent 写作，因为模型很容易在不同章节重复“提前解释”和“提前防御”。

六、报告不仅告诉你“命中了”，还告诉你应该多认真看

不同规则的确定程度并不相同。

例如：

As requested by the reviewer

出现在 manuscript 中，通常是一个相当明确的修改过程残留。

而某个 LLM 关联词密度偏高，只能说明：

这里值得人工复核

因此规则带有：

confidence:
high
medium
low

同时还有：

evidence:
literature
style-guide
heuristic
project-specific

最终报告可以显示类似：

🔴 HIGH · conf high

让用户区分确定性较强的问题和统计意义上的提示。(GitHub)

我很喜欢这种方式。

Writing Linter 最重要的能力之一，其实是知道什么时候应该提醒，什么时候应该保持克制。

七、两个核心工具：writing_rules 和 writing_audit

插件目前向 DSH 提供两个主要工具。(GitHub)

writing_rules

它负责提供当前写作纪律。

可以在 Agent 开始改论文之前先调用：

先使用 writing_rules 阅读 manuscript 写作规则，
再修改当前论文。

这样 Agent 在生成阶段就能获得约束。

writing_audit

这是实际执行审计的工具。

可以检查文本，也可以直接检查文件，并指定对应 profile。

例如：

使用 writing_audit 检查当前 manuscript。

或者：

只告诉我当前论文中的 high severity 问题。

v0.5.2 中，writing_audit 也支持按调用传入项目自己的 projectResidueTerms。(GitHub)

比如团队内部可能存在：

老板修改版
投稿前版本
最终实验
内部测试
第三轮修改

这类词没有必要加入所有用户的默认规则，但可以针对自己的论文项目进行检查。

八、真正适合 Agent 工作流的，是自动 Audit

手动执行 Audit 很简单。

但如果每次 Agent 写完文件之后都需要用户再说一句：

请检查刚才的修改

整个流程还是比较割裂。

所以 Writing Guard 可以监听 DSH 的 write / edit 操作。

当论文相关的：

.md
.tex
.txt

文件发生写入后，插件自动运行审计，并通过 additionalContexts 把需要注意的问题交给 Agent 的下一轮上下文。(GitHub)

工作流就变成了：

Agent 写论文
↓
write / edit
↓
Writing Guard
↓
出现新的写作问题？
↓
有 → 下一轮提醒 Agent
无 → 保持安静

这种体验已经比较接近代码开发里的持续 Lint。

九、Incremental Lint：只告诉 Agent 真正发生变化的东西

自动审计如果设计不好，会产生另一个问题：

上下文污染。

假设 manuscript 中已经有 10 个问题。

Agent 修改一个无关句子之后，如果系统再次把同样的 10 个问题完整发送一遍，很快就会产生大量重复信息。

因此 Writing Guard 会按文件保存审计状态：

~/.dsh/plugins/dsh-plugin-writing-guard/state.json

每次写入后比较前后结果，只关注增量。(GitHub)

例如：

新增 1 项
已解决 4 项
仍存在 8 项

当前逻辑大致是：

没有变化
→ 不注入

只有旧问题消失
→ 不持续打扰

出现新的问题
→ 把新增项和建议交给 Agent

完整问题清单依然可以随时通过：

writing_audit

手动获取。(GitHub)

这一点对长时间运行的论文 Agent 很重要。

一个好的守卫不应该反复提醒你早就知道的事情。

十、当前 v0.5.2 对长论文会话做了哪些设计？

对于持续运行的论文 Agent，Writing Guard 目前使用稳定的问题 fingerprint 来追踪同一个 lint issue。

即使同一段中的其他文字发生变化，只要实际命中的问题仍然存在，它依然可以被识别为同一个问题，而不会在增量结果中反复制造“新增项”。(GitHub)

同时可以配置：

maxAutoInjectPerTurn: 2

限制每轮最多自动向 Agent 注入多少次审计信息。

论文文件识别同样采用了更严格的路径边界规则，避免普通 notes 或包含相似字符串的文件被误当作 manuscript。当前 profile detection 也能够覆盖 manuscript、reviewer comments、notes 和 revision response 等不同项目文件。(GitHub)

这些机制最终都服务于同一个目标：

让 Writing Guard 常驻，但尽量不打扰正常写作。

十一、安装

当前仓库已经提交构建后的 lib/，从 GitHub 安装无需本地编译。(GitHub)

直接执行：

dsh plugin –profile web add dsh-plugin-writing-guard

然后重启：

dsh web

也可以使用 GitHub tarball：

dsh plugin –profile web add https://github.com/xmutfyh/dsh-plugin-writing-guard/archive/refs/heads/master.tar.gz

默认配置已经适合大部分论文写作场景：

– id: dsh-plugin-writing-guard
config:
autoAuditOnWrite: true
mode: conservative
autoAuditMinSeverity: high
maxAutoInjectPerTurn: 2
verboseByDefault: false
autoBrief: false
projectResidueTerms: []

其中可以选择：

conservative
balanced
strict

不同模式控制自动提醒的严格程度。(GitHub)

如果是第一次使用，我更建议从：

conservative

开始。

完整问题需要时手动 Audit，自动流程只处理更重要的内容。

十二、它适合解决什么问题？

Writing Guard 比较适合下面这些工作流：

DSH + 论文
DSH + LaTeX
英文 manuscript 修改
中文毕业论文
reviewer comments 返修
rebuttal / response letter
长期维护的论文知识库

尤其当 Agent 开始拥有直接写文件权限之后，它的价值会更加明显。

以前我们使用聊天模型，大部分流程是：

提问
↓
复制答案
↓
人工粘贴
↓
人工检查

现在 Agent 可以直接：

读取论文
修改多个文件
处理审稿意见
写入 LaTeX
继续下一轮修改

人工已经不再逐句经过每一次生成。

这时，把一部分确定性的写作纪律交给工具执行，会比不断在 prompt 里重复：

不要有 AI 味
不要使用套话
注意学术表达

更加稳定。

十三、为什么我把它叫 Writing Guard？

它并不试图替作者决定：

这句话是不是 AI 写的？

它处理的是更具体的问题：

这句话是不是修改过程残留？

这个修辞是不是已经重复得太多？

这个表达放在 manuscript 中是否合适？

这条 limitation 是正常讨论，
还是已经散落到多个章节？

这个问题值得直接处理，
还是只需要人工复核？

这些判断比一个简单的“AI probability”更容易解释，也更容易直接用于修改。

结语

当 Agent 开始参与论文工程以后，我越来越希望写作工作流也能拥有和代码开发类似的质量控制层。

代码有：

Formatter
Linter
Type Checker
Test
CI

论文工作流未来也可以逐渐拥有：

Writing Lint
Citation Check
Claim Validation
Reference Check
Format Validation

dsh-plugin-writing-guard 做的是其中的 Writing Lint。

它把一些原本只能写进 prompt 的“写作纪律”，变成一个可以持续执行、可以解释结果、可以自动反馈给 Agent 的工具。

以后让 DSH 修改论文时，我希望工作方式很简单：

Agent 负责写。

Writing Guard 负责看。

有值得处理的问题，就提醒。

没有问题，就继续写。

如果你正在用 DeepSeek Harness 写论文、维护 LaTeX 或处理返修，可以试一下：

dsh plugin –profile web add github:xmutfyh/dsh-plugin-writing-guard

当前版本：

v0.5.2

项目：

github.com/xmutfyh/dsh-plugin-writing-guard

欢迎反馈真实论文中的误报、漏报和新的 writing lint 场景。