受控技术中文: 把啰嗦变成可机械检测的判据
我之前写过怎么判断自己写的东西有没有AI味, 那篇治的是人称、句长、加粗密度、抽象名词与同体裁对照这几项. 但还有一类问题它治不了: 句子本身太长、用词没信息量、范围说不清含不含端点. 这类问题属于精度, 不在句式这一层.
后来翻到一套现成的: 简明技术中文 (Simplified Technical Chinese). 它有 40 条规则、约 170 条词表, 句长阈值是按 350 万字真实技术文档校准出来的. 我把它拆了一遍, 又把能落地的部分接进了本仓的检查器.
0x00 它治什么, 不治什么
一句话: 它把"这段读着啰嗦"拆成一组可判定的判据, 每条都有阈值和误报率.
- 治: 技术说明、接口文档、操作步骤、机器撰写的解释性回答
- 不治: 营销文案、叙事文章、观点评论
最后一行是它自己写的. 它声明不适用于叙事文章和观点评论. 它声明的适用范围是技术说明、接口文档、操作步骤与机器撰写的解释性回答.
0x01 骨架: 先分句类, 再判据
整套方案先做分类, 再谈规则:
- 操作句: 指示读者执行动作, 通常以动词开头, 出现在编号步骤里
- 描述句: 其他句子
阈值、祈使句要求、被动语态检查全都依赖"这句是操作句还是描述句". 分类判错, 后面的阈值就会选错区间. 所以它的检查器里有一个 is_operation() 专门做这件事.
两套级别: 【必须】违反即不合规; 【建议】违反只提醒.
0x02 两个阈值, 有校准
操作句 30 字 350 万字真实文档的 85 到 90 分位
描述句 40 字 同分布 90 分位附近
段落 6 句 规范规则 3.2
定语 15 字 没有校准, 脚本查不出
字数怎么算: 每个汉字计 1, 每个连续拉丁字母串或数字串也各计 1 (API、v2.0、3000 各算一个字), 行内代码整体算 1 个字, 标点和空格不算. 「重启服务」计 4 字.
阈值不能随手改. 同一份规范被 answer-me-with-html 搬去做双语版时放宽成 35 和 45 字, 没有给理由. 我取有校准报告的那一组.
0x03 中文特有的歧义来源
规范专门列了一节, 说这些是英文受控词典搬不来的:
对配置进行修改 -> 修改配置 (进行 类名词化)
用于在系统启动时自动加载位于用户目录下的配置文件的模块
-> 拆成三句 (长定语)
10 MB 以内 -> 不大于 10 MB (端点说不清含不含)
可以跳过 -> 支持跳过 (许可与能力混用)
打开日志功能 -> 启用日志功能 (对象限定)
近期下线 -> 2026-12-31 下线 (相对时间)
反过来也成立: 英文有而中文不需要的规则是动词形态 (-ing 和过去分词)、冠词时态、词性限定.
0x04 最值得抄的一个设计: 词表自带「自动检查」列
词表分三部分, 每条都带一列「自动检查」, 只填「是」或「否」:
- 禁用词: 不用的词与替换方式
- 选词表: 同一意义只批准一个词 (
点击/单击/点按只留点击) - 一词一义: 批准词只按一个意义用 (
打开只用于文件窗口页面连接)
填「是」的脚本见到就提醒, 填「否」的依赖语境只供人看. 它把"能自动查"和"只能人看"分开声明, 而不是假装全都能查. 判据是: 自动检查的条目只保留精确率不低于 80% 的词.
本仓的套话词表原先只记了做法约定, 没有存证据. 我按这个思路把双向频次补进了数据层. 规则表本身还没有独立的「能自动查 / 只能人看」字段.
0x05 它主动声明查不了的规则
规范附录里列了脚本不查的规则, 连同实测精确率一起写出来. 这一节是它可信的来源:
缩写写法 精确率 0% 大小写差异几乎都来自代码与链接锚点
指代是否清楚 精确率 0% 指代词数量不能代表清楚程度
的 的数量 精确率 2% 不能代表定语长度
长定语 查不出 脚本量不出定语长度
正文串联步骤 40% / 30%
警告位置 19%
前置条件 12%
步骤里解释原因 34%
一句多事 53% 降为建议
双重否定 22% 降为建议
这条否定了"数『的』字"这种看起来聪明的土办法. 我原本以为连续多个"的"是长定语的可靠信号, 数据说不是.
0x06 应用之后还有人味吗
这是我最想先弄清楚的问题. 答案是:
它不会把你写的东西变成 AI 味, 但会让人味变淡, 淡向"说明书味".
先说为什么不会变成 AI 味. 受控写作的规则全是否定式的: 不许长句、不许虚动词、不许问句. 删东西永远不会生成特征. 而 AI 味来自生成套路 (破折号、不是X而是Y、凑数排比、抽象名词堆叠), 那些不是受控写作的产物. 两套病不在一条轴上. 这一条在本仓验证过: 同一篇笔记喂两套检查器, 交集只有句长一维, 用词与排版指纹各抓各的.
那"变淡"有多淡? 用作者自己的语料量:
进行 人写 blog+docs 1845 次 (其中 docs 1808 次)
问号 人写 docs 332 个, blog 6 个
进行 在作者手写的技术文档里有 1808 次. 按规范它该改成动词直用, 也就是 1808 处都要动.
这就说清了"淡"在哪. 人类味道的来源, 恰好是受控写作要删的东西:
短句碎断 . 而且不好用. 还有那个数量限制. 受控要求: 一句一事, 拆成编号步骤
设问推进 那么是否可以通用的? 不就是白嫖吗? 受控要求: 禁一切问句 (必须级)
自嘲括号 (说是不是故意的?) 受控要求: 条件写在动作前, 不放在括号里
语气词 学习到 倒排索引 的使用喵~ 受控要求: 无对应条款, 但语气词不属于技术语
省略号 然后出现八嘎了... 受控要求: 无对应条款, 但它就是"不确定语气"
受控写作让文本淡向一种手册味: 它是人味被削薄之后的形态, 不是另一种风格.
实用结论有两条:
- 写技术说明时用它, 收益最大 (句长、端点、术语一致性都是可查的)
- 写随笔和观点时别用. 它自己也这么声明, 不是我推出来的
0x07 它和本仓已有检查器是什么关系
本仓已有一套 AI 味检查器 hx_voice.py. 两套都拿同一篇真实笔记跑过:
simplified-technical-chinese 的 check.py 15 条 (必须 13, 建议 2)
本仓 hx_voice.py lint 14 errors, 23 warnings
交集只有句长一维, 且阈值不同 (40 字与 43 字):
维度 受控技术中文 hx_voice
句长硬线 是 (必须级, 40 字) 有软线 43 字, 只报 W
虚动词与端点歧义 是 否
禁用词 (其实 沉淀 众所周知) 是 否
破折号 否 是 (E 级)
表格禁用 否 是 (E 级)
抽象名词密度 否 是
助手口头禅 否 是
所以两者是互补, 不是替代. 一个补"说得够不够精确", 一个管"像不像人写的". 有冲突的只有句长阈值, 同一份文本不能同时用两套判.
0x08 落地到本仓: 只加了 1 个词
知道上面那条边界后, 能落地的东西比看起来少. 我按本仓 voice_rules.py 的既有约定 (只有"人写近乎不出现、AI 常出现"的词才算套话) 实测了一遍候选词. 约定是: 人写篇数占比须低于 2% (977 篇人写语料里少于 20 篇).
词 人写 (977 篇) AI (73 篇) 结论
沉淀 2 次 / 1 篇 67 次 / 23 篇 加 (约 30 倍差距)
其实 124 次 / 82 篇 55 次 / 31 篇 否决 (人写更多)
进行 1845 次 / 451 篇 15 次 / 5 篇 否决 (人写 100 倍以上)
颗粒度 3 次 / 3 篇 3 次 / 3 篇 否决 (无差距)
众所周知 7 次 / 7 篇 3 次 / 2 篇 否决
第一轮我凭印象判断"其实"和"进行"都该加. 实测把两个都打翻了: 它们是正常词, 只是我读到 AI 文本里的密度偏高而已. 若不跑统计就加进去, 会误伤作者 82 篇手写笔记.
合格的只有 沉淀 一个. 但它有个细节: 作者那 1 篇里是活用 (想着一定要沉淀下来!), 是具体动作而非空话. 所以我给它单开了一档, 只约束派生文章, 不管随笔.
实际改动的量: ai-docs/ 全量 article profile 由 1125 errors 升到 1174 errors, 多出的 49 处全是 沉淀, warnings 一处没变. 作者语料零误伤.
0x09 没做的, 与为什么
- 句长保持软警告, 不升级成失败线. 理由就是 0x06 的实测:
进行在 docs 里 1808 次、问号 332 个, 说明作者的技术文档本来就是这个句式. 升硬线等于把作者自己的写作习惯判违规 - 不搬虚动词、端点歧义、相对时间三族规则. 理由是它们在本仓正式笔记里近乎零命中 (
进行只有 15 次 / 5 篇, 且都是正常用词), 当前没有可验证的收益 - 不搬禁问句与禁表格. 前面算过代价: 本仓
ai-docs/有 237 个问号, 大多出现在转写稿里, 那是被引述的原话
回头看, 这套方案真正可迁移的是两条: 阈值要写校准来源; 规则要声明自己查不了什么. 后者在它的附录里做到了, 因为那一节列了精确率.
至于这套写法本身, 我更愿意把它当成一把尺子而不是一个风格. 尺子用来量说明文, 别拿去量随笔.
本文没有引用站内其它文档。
