mcpField
S
ste-zh

ste-zh

github.com/lemonhallドキュメント8143 回インストール4 週間前に更新
リポジトリ

ste-zh について

ste-zhは、制御された文章作成の原則を中国語に適用するスキルです。明確で確認可能な表現を必要とする執筆者向けに、文構造の規則、語彙の指針、改稿手順、決定的な検査スクリプトを提供し、意味とモダリティの保持を重視します。

主な機能

  1. 01Strictと中文-顺の2モード
  2. 02中国語の文・段落規則
  3. 03曖昧表現の確認リスト
  4. 04改稿手順と出力形式
  5. 05決定的なste-lint-zh.py検査

活用シーン

  1. 01ツール説明やエラーメッセージの明確化
  2. 02エージェント向け指示の作成
  3. 03中国語の技術文書の確認
  4. 04改稿前後の差分確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/lemonhall/asd-ste100-skill-zh --skill ste-zh

インストール後、Claude Code で/ste-zhを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

.gitignore
LICENSE
NOTICE.md
README.md
docs/
wechat-article.md
docs/images/
make-covers.py
README.md
prompt-cover.txt
docs/images/run-02/
request.json
inspection.json
examples/
after-only.md
before-after.md
references/
writing-rules.md
scripts/
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 次快速重试若干次「若干 / 一些 / 相关」是否可接受取决于场景

体貌(中文的「时态」)

中文没有时态,但体标记会泄漏信息:已经……了、正在……中、……过。受控写作默认用最简表述 (「任务已结束」写成「任务结束」),但有当前相关性时必须保留:

  • 「任务已完成,结果可以直接读」≠「任务完成过」。前者是状态,后者是历史。
  • 「请求可能已失败」里的「可能」是作者给出的置信度,是内容,不是修饰。

凡复合体貌承载了简单体貌给不出的信息(当前相关、或情态),保留它,并在输出里标注这处偏离。 其余地方按规则简化。

扫描清单

下面六种是中文机器味的绝大多数来源。每一种都是机械的:你能指出具体的词或标点,不需要审美判断。 改写之前先把六条都扫一遍。

  1. 同义轮换 —— 同一件事在一篇里换了好几个名字(用户 / 客户 / 使用者)。读者分不清是一个东西还是三个。 改法:定一个名字,全篇用它。
  2. 套话堆叠 —— 需要注意的是、值得一提的是、在一定程度上、某种意义上、不难看出。删掉,或直接说事。
  3. 名词化 —— 动作被冻成名词(进行 / 作出 / 加以 / 予以 + 名词)。改法:用动词(「进行分析」→「分析」)。
  4. 营销形容词 —— 宣称质量而不给出证据:无缝、强大、赋能、闭环、极致、丝滑、一站式、颠覆、领先。 改法:删掉,或换成撑得起这句话的测量值。
  5. 长句串联 —— 用分号、破折号、「并且 / 同时 / 从而 / 进而」把好几件事串成一句。改法:一句一件事。
  6. 翻译腔 —— 「基于……的情况下」「对于……而言」「这是一个……的事实」「不仅……而且……而且」。 改法:说清主语和动作,其余删掉。

流程

  1. 选档(Strict / 中文-顺)。只有用户要规则表时才说明选了哪档,见「输出格式」。
  2. 通读一遍原文,先弄清它改完之后还必须说什么。没读懂不要动笔。
  3. 逐句走。对照「结构规则」「词汇规则」两张表与「扫描清单」标出每一处违规。中文-顺档中标出词汇规则 但不强制。机械首查可以跑 scripts/ste-lint-zh.py(stdin 或文件参数,--json 出结构化结果): 它查分号串联、超长句、名词化、营销形容词、套话、同义轮换、被动语态、复合体貌、含糊词、半角标点。 --baseline N 容忍 N 处硬违规(用于存量文档接入);--disable 规则名,规则名 关掉指定规则。
  4. 重写每一处违规句,原意一个字不能变。如果改短会丢掉必要的精度(安全条件、范围限定、数字), 保留长的写法并在输出里标注,而不是悄悄简化。
    • 动笔前先看情态。 「可能 / 也许 / 有时 / 倾向于」承载作者的置信度,置信度是内容。 改短却把「可能」升成事实,那不是简化,是换了一个结论。这是受控改写最常见的翻车方式, 因为句长上限最容易引诱人删掉的正是这些词。
    • 不要添加原文没有的事实。改写之后读起来更顺,是因为它补了一个原因、频率或机制 —— 那已经不是改写。
  5. 按「输出格式」给出改写后的正文。档位选择与规则分析留在内部,除非用户要看。
  6. 原文本来就合规,就直说合规,不要硬改。

输出格式

默认:只给改写后的正文。 多数调用方要的是能直接粘进工具描述、报错串或 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 里有「请求可能已失败」必须干净的断言。

コメント