关于 ste-zh
ste-zh 是一项将受控写作原则用于中文文本的技能,面向需要清晰、可核对内容的作者。它提供结构规则、词汇方向、改写流程和确定性检查脚本,并强调保留原意与情态。
主要功能
- 01Strict 与中文-顺两种模式
- 02中文句式与段落规则
- 03含糊表达扫描清单
- 04改写流程与输出格式
- 05ste-lint-zh.py 确定性检查
适用场景
- 01澄清工具描述与报错文本
- 02编写供 Agent 解析的指令
- 03检查中文技术文档
- 04查看改写前后差异
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ lemonhall/ asd-ste100-skill-zh --skill ste-zh安装后在 Claude Code 中输入/ste-zh确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
.gitignoreLICENSENOTICE.mdREADME.mddocs/wechat-article.mddocs/images/make-covers.pyREADME.mdprompt-cover.txtdocs/images/run-02/request.jsoninspection.jsonexamples/after-only.mdbefore-after.mdreferences/writing-rules.mdscripts/ste-lint-zh.py详细介绍
来自项目 README受控中文技术写作(ASD-STE100 中文化)
ASD-STE100 是航空业为了「维修工不可能读错」而做的受控英语:一个词只有一个意思,一句话只有一种结构。 本技能把同一条纪律搬到中文,读者换成没有追问机会的另一方:另一个 agent、翻译管线、非母语读者、 半年后的你自己。
中文的歧义来源和英语不同。英语主要栽在「一个词多个意思」和「一句话多种结构」上;中文主要栽在四件事: 虚动词(进行 / 加以 / 作出 + 名词)、套话(需要注意的是、在一定程度上)、同义轮换 (用户 / 客户 / 使用者 混用)、一句串三件事(用分号、破折号、「并且 / 同时 / 从而」串起来)。 所以下面的规则按中文重写,不是把英文规则逐条翻译过来。
规则分两类,本技能只能把其中一类做到「可核对」:
- 结构规则:讲句子形状,读完描述就能执行,可以放心硬性套用。
- 词汇规则:需要一个受控词表才算标准。中文没有(也不该有)官方词表,所以词汇规则降级成 「方向」——挑最普通、最常见的说法,并在输出里说明这是方向而不是合规声明。
什么时候用
- 一段中文说明、报错、日志、工具描述读起来含混、术语堆砌、或者绕。
- 文本要交给另一个 agent、翻译管线、非母语读者解析,读错有代价。
- 你在写 prompt、system message、工具描述,想在模型看到之前先消掉歧义。
- 你想要前后对照,看清违反了哪条规则、改完为什么更好。要就说 —— 默认输出只有改写后的正文。
不用在:创意文案、营销文案、文学、需要语气与节奏的地方。受控中文是故意平淡、字面化的。
两档模式
改写前先选档。用户没说就按文本类型推断,并在输出里用一句话说明选了哪档。
Strict(严格) —— 程序步骤、报错信息、工具与函数描述、agent 间指令、安全相关文本。 凡是读错有代价的地方,全部规则执行,包括硬性句长上限和「一词一义」。
中文-顺(STE-flavored) —— README、PR 描述、变更日志、解释性文章。结构规则全执行, 词汇规则只作为方向:句长上限、主动语态、简单体貌、不用分号、去名词化、去营销形容词都保留, 但不锁死用词 —— 说明文需要一点弹性,全锁死读起来像换了个作者,而不是变清楚了。
两档和「结构 / 词汇」这条分界线是同一件事的两个方向:分界线说的是哪些规则不依赖词表也能核对, 两档说的是对某类文本该执行到哪一步。
结构规则(执行)
| 规则 | 这样做 | 不要这样 |
|---|---|---|
| 主动语态 | 脚本删除临时文件。 | 临时文件被脚本删除。(施事未知或无关时才用「被」) |
| 一句一动作 | 打开文件。读第 3 行。 | 打开文件并读第 3 行,然后检查是否匹配。 |
| 句长 | 指令句 ≤ 25 字;说明句 ≤ 40 字 | 一句话套三层从句 |
| 不用分号连接动作 | 拆成两句 | 「先做 A;再做 B」 |
| 名词短语 ≤ 3 层 | 燃油泵阀门 | 高压燃油泵进口阀门总成 |
| 不省略成分 | 未备份的文件会丢失。 | 文件未备份将丢失。(哪些文件?) |
| 保留情态 | 「请求可能已失败」照写 | 把「可能」升级成事实「请求失败」 |
| 段限 | 一段一主题,≤ 6 句 | 一段里塞三件事 |
| 顺序用列表 | ≥ 3 步或 ≥ 3 个条件用编号 / 项目列表 | 把步骤塞进一句 |
词汇规则(方向)
| 规则 | 这样做 | 不要这样 | 为什么弱 |
|---|---|---|---|
| 一词一义 | 同一个动作全篇只用一个动词(一直用「检查」) | 检查 / 校验 / 核对 / 确认 轮着用 | 「同一文档内一致」可核对;「哪个词才是受控词」没有中文标准 |
| 动词优先 | 分析日志。 | 对日志进行分析。 | 「进行 + 名词」在任何场合都该改成动词,这一条可以放心执行 |
| 去营销形容词 | 删掉,或换成可测量的说法 | 无缝、强大、赋能、闭环、极致、一站式 | 界定「哪些词算营销」是判断,不是规则 |
| 术语首次定义 | 保留必要术语,首次出现时给一句定义 | 直接抛黑话,后面全靠猜 | 允许项目术语表,但得有人维护它 |
| 具体化 | 3 秒内重试 2 次 | 快速重试若干次 | 「若干 / 一些 / 相关」是否可接受取决于场景 |
体貌(中文的「时态」)
中文没有时态,但体标记会泄漏信息:已经……了、正在……中、……过。受控写作默认用最简表述 (「任务已结束」写成「任务结束」),但有当前相关性时必须保留:
- 「任务已完成,结果可以直接读」≠「任务完成过」。前者是状态,后者是历史。
- 「请求可能已失败」里的「可能」是作者给出的置信度,是内容,不是修饰。
凡复合体貌承载了简单体貌给不出的信息(当前相关、或情态),保留它,并在输出里标注这处偏离。 其余地方按规则简化。
扫描清单
下面六种是中文机器味的绝大多数来源。每一种都是机械的:你能指出具体的词或标点,不需要审美判断。 改写之前先把六条都扫一遍。
- 同义轮换 —— 同一件事在一篇里换了好几个名字(用户 / 客户 / 使用者)。读者分不清是一个东西还是三个。 改法:定一个名字,全篇用它。
- 套话堆叠 —— 需要注意的是、值得一提的是、在一定程度上、某种意义上、不难看出。删掉,或直接说事。
- 名词化 —— 动作被冻成名词(进行 / 作出 / 加以 / 予以 + 名词)。改法:用动词(「进行分析」→「分析」)。
- 营销形容词 —— 宣称质量而不给出证据:无缝、强大、赋能、闭环、极致、丝滑、一站式、颠覆、领先。 改法:删掉,或换成撑得起这句话的测量值。
- 长句串联 —— 用分号、破折号、「并且 / 同时 / 从而 / 进而」把好几件事串成一句。改法:一句一件事。
- 翻译腔 —— 「基于……的情况下」「对于……而言」「这是一个……的事实」「不仅……而且……而且」。 改法:说清主语和动作,其余删掉。
流程
- 选档(Strict / 中文-顺)。只有用户要规则表时才说明选了哪档,见「输出格式」。
- 通读一遍原文,先弄清它改完之后还必须说什么。没读懂不要动笔。
- 逐句走。对照「结构规则」「词汇规则」两张表与「扫描清单」标出每一处违规。中文-顺档中标出词汇规则
但不强制。机械首查可以跑
scripts/ste-lint-zh.py(stdin 或文件参数,--json出结构化结果): 它查分号串联、超长句、名词化、营销形容词、套话、同义轮换、被动语态、复合体貌、含糊词、半角标点。--baseline N容忍 N 处硬违规(用于存量文档接入);--disable 规则名,规则名关掉指定规则。 - 重写每一处违规句,原意一个字不能变。如果改短会丢掉必要的精度(安全条件、范围限定、数字),
保留长的写法并在输出里标注,而不是悄悄简化。
- 动笔前先看情态。 「可能 / 也许 / 有时 / 倾向于」承载作者的置信度,置信度是内容。 改短却把「可能」升成事实,那不是简化,是换了一个结论。这是受控改写最常见的翻车方式, 因为句长上限最容易引诱人删掉的正是这些词。
- 不要添加原文没有的事实。改写之后读起来更顺,是因为它补了一个原因、频率或机制 —— 那已经不是改写。
- 按「输出格式」给出改写后的正文。档位选择与规则分析留在内部,除非用户要看。
- 原文本来就合规,就直说合规,不要硬改。
输出格式
默认:只给改写后的正文。 多数调用方要的是能直接粘进工具描述、报错串或 prompt 的结果。 把改写后的文本单独打印。不要加技能介绍、档位声明、违规计数、变更摘要、规则表,也不要结尾再问一句 「需要我解释吗」。
唯一允许的附加:第 4 步故意保留了较长的写法时,在正文后加一行,前缀 保留原样:,
写明保留的短语和会丢掉的精度。没有这种情况就不加。
用户要求时:规则表。 当用户说「给我看 diff」「违反了哪些规则」「解释一下改了什么」「前后对照」, 输出这张表:
| 违反的规则 | 原文 | 改写后 |
|---|---|---|
| 名词化 | 「对日志进行分析」 | 「分析日志」 |
| 分号串联 | 「先开票;再发货」 | 「先开票。再发货。」 |
档位:Strict。共 7 处违规。
表后加一行说明故意没有改的地方和原因(通常是:改短会丢精度)。
边界
会做:
- 把含糊、啰嗦的中文改写成短句、单义、主动语态的句子。
- 默认只给改写后的正文;用户要求时列出用到的规则。
- 保留原文的每一个事实、条件、范围限定。
- 保留每一处情态的强度,不添加原文没有的断言。
- 给必须保留的术语提一行术语表写法。
不会做:
- 声称符合某个官方中文受控词表 —— 中文没有这样的标准,本技能只提供规则与方向。
- 改写创意、营销、说服性文案 —— 那里的语气和留白才是重点。
- 为了短而悄悄删掉安全条件、例外、范围限定 —— 会标注这个取舍。
- 把「可能已失败」改成「失败」,把「可能是 X 导致的」改成「X 是原因」 —— 丢情态就是换结论。
- 保证「合规文档」。这是受控写作思路的通用清晰化工具,不是认证工具。
- 把空内容变有用。受控写作修的是形式,不是内容。一段空话改完会变成一段干净、简短、 标点正确的空话。文本本身没东西可说,就直说,不要粉饰。
- 为了短牺牲可读性。删字不是目的,消歧才是。压到某个程度之后,省下的时间会被读者重新花回去 —— 句子没有歧义就停手,不要追求最短。
附加资源
references/writing-rules.md—— 规则全集:结构规则、词汇规则、中文特有的坑、与上游 ASD-STE100 九节 53 条的对应关系,附引用。examples/before-after.md—— 前后对照例子:工具描述、报错信息、agent 间指令、状态汇报、 PR 描述、README。scripts/ste-lint-zh.py—— 仅用标准库的确定性 linter。硬违规超过--baseline(默认 0)时退出码 1; 建议类发现(被动语态、复合体貌、含糊词、半角标点)永不导致失败;--disable关闭指定规则。 它永远不挑情态(可能 / 也许 / 大概):那是内容不是风格,--selftest里有「请求可能已失败」必须干净的断言。