Jev 写作质量检查：用规则评审 Markdown 与技术文档

把审美要求变成可复核规则

先选择文章用途：操作指南需要前置条件和可执行步骤，评论文章则可能允许修辞与个人语气。同一规则不应机械套在所有文体上。把“不要空话”拆成可观察的问题，例如是否给出具体动作、是否存在无出处的量化结论。

有些检查用普通程序更稳妥：损坏的链接、缺少必需标题或代码块语法，可以先用确定性检查完成。Jev 留给需要语义理解的部分。

逐行判断和全文评分怎样分工？

固定版本会为行级规则构建 Noul 问题，为文档级规则构建 Score 问题，再整理成行号和维度报告。行级适合指出一个具体问题，全文级适合检查前置条件、结构与任务完成度。

报告是修订的输入，并非工具已改好文稿。模型指出一句话含糊后，仍需作者补充真实信息；另一个生成模型可以拟稿，但不能凭空补充事实。

依据: slop-grader — grader.ts ↗

一个自定义规则的设计样例

以下为编辑编写的 Markdown 规则示意，依据项目规则格式；未执行语法校验或真实模型评审。它检查能否开始操作，而不是检测所谓“AI 味”的作者身份。

# Line Rules

## unexplained_action
Does the line ask the reader to change a setting without identifying what to change?

### Criteria
- **true**: A setting change is requested, but no setting or value is identified.
- **false**: The target is specified, or the line does not request a setting change.

# Document Rules

## prerequisites
How clearly does this setup guide state what the reader needs before starting?

### Criteria
- Required inputs and access are absent
- Some requirements are stated, but important ones are missing
- Required inputs and access are identifiable
- Requirements and a way to verify them are explicit

依据: slop-grader — README.md ↗

用正反例确认规则问对了问题

以下为合成验收样本，没有虚构评分。先让编辑给出判断，再观察模型误报是否来自上下文截断或规则定义。

从检查报告到修订闭环

先运行规则格式检查，再对允许发送的文稿做真实评审。项目的 --check 只验证规则语法，不调用模型，也不代表规则判断准确。保留文稿版本、规则版本、模型标识和报告，逐条确认误报后再改稿。

修改后优先重查原问题与受影响段落，同时比对专有名词、数值、引用和结论是否改变。不要为了让评分升高而删掉必要限制条件。未公开文稿会发送给所选 provider，输入范围应由作者决定。

依据: slop-grader — README.md ↗

常见问题

能自动去掉所有“AI 味”吗？它依据你给出的规则检查风格，不证明文本由谁创作，也不能保证读者感受一致。

能直接用于中文吗？该项目允许自定义规则，但已有英文或德文语法规则的存在不能证明中文效果。应单独编写中文例子、反例并校准。

适合直接卡住所有 CI 吗？建议先观察误报、保留复核，再让稳定且可解释的检查进入阻断流程。本站仅核对源码，未调用 Jev 为文稿打分。

接着看这些项目

继续阅读