STC 简明技术性中文

本 skill 按规范生成、改写和审阅中文。默认表达自然、简短、准确，同一个意思使用同一个词。规则在 rules/，词表在 dictionary/，路径都相对于本 skill 所在的目录。

默认表达方式

每次使用 STC，都必须同时执行以下要求：

• 用完整句子和自然语序，直接回答问题或交付结果。
• 删除客套、重复和无关解释，信息足够时停止。
• 保留事实、数字、名称、否定词、权限和真实不确定性。
• 根据任务展开。完整文稿和详细说明必须满足用户要求。
• 交付成品时，从采用的结果写起；制作与复核记录放在内部。
• 任务回执按 for chat 的 C10 分成“做完了”“需要你”“知会”，把用户动作单独列出。

这些要求内置于 STC，具体规则为 G14、G15、G20、G21、G22，以及当前场景的规则。

安装后的首次使用

用户选择通过链接使用时，读取 WEB.md，按网页引导确认规则读取情况和生效范围。

安装后的引导必须按 ONBOARDING.md 执行：提供默认使用选项和文档审阅体验，等待用户选择。

用户可以提供材料，也可以授权 agent 从当前项目挑选一份文档。审阅范围和修改动作以用户授权为准。

第一步：判断场景

动笔前先判断这次写的是哪类文字。按读者和用途判断：

• 一次任务包含几类文字时，必须对每一类文字分别判断。例如一份需求文档按 for document 写，文档里给出的按钮文字按 for web dev 写。
• 读者和用途都判断不清时，按读者判断：读者是模型，用 for instruction writing；读者是产品用户，用 for web dev；其余用 for document。
• 场景选择用于内部执行。用户询问方法或判断存在分歧时，再说明所用规则。

第二步：读规则和词表

1. 读 rules/for-all.md。通用规则对所有场景都适用。
2. 读第一步选定的场景文件。场景规则和通用规则不一致时，以场景规则为准。
3. 读 dictionary/avoid.yaml。只用 profiles 字段为空或包含当前场景的条目。
4. 写界面文字，或写警告、注意、说明这类提醒时，读 dictionary/recommended.yaml，动作词和提醒级别照表里的意思用。
5. 项目里有术语表时（文件名通常含 terms 或“术语”），必须照术语表写名称。

第三步：按用法处理

按用户请求生成、改写或审阅文字。

写

按规则写出文字，再完成语义复核。

改写

改写用户给的文字，保留原意：

• 必须保留原文的事实、数字、专有名称和引语。
• 必须保留表示把握程度的词：可能、也许、大概、通常。
• 程度词必须换成数字。原文和上下文里没有这个数字时，不得编造数字。这时删掉程度词，或写成“【待补：提升了多少】”，并在改写结果后列出所有待补项。原因：编出来的数字比含糊的形容词危害更大。
• 交付用户请求的内容。用户要求解释，或改动会影响使用判断时，再说明主要改动与依据。

审查

审查用户指定的材料。先给报告和具体改法；用户要求改写时再给修改稿，写回文件按用户已有授权执行。

报告必须按以下顺序写：

1. 用一句话说明主要问题，区分需修改项与待确认项。
2. 按原句分组，给出位置、原句、问题原因和具体改法。规则编号放在说明后面。
3. 单独列出需要用户补充的事实。缺少的数据和主体名称必须用“【待补：…】”标记。
4. 用户可以选择采用哪些改法。已选定的修改可以直接执行，不必再次询问。

汇报审阅任务的执行结果时，按 C10 写回执。审阅报告本身使用本节的结构。

不得直接把命令输出的逐行诊断当作交付报告。机器输出是审阅依据；agent 必须结合上下文判断指代、术语、事实和句意。警告只有经上下文确认后才能判定为问题。

检查命令默认提供可读报告。--format markdown 可生成 Markdown 报告；--json 为程序和 agent 提供结构化依据。

第四步：自查

普通对话按 C8 在发出回复前自查。对本次任务内写出的文件或用户指定的材料，能运行 Node.js 18 以上版本时，使用检查命令：

node <本 skill 目录>/tools/cli.mjs check <文件> --profile <场景> --anti-echo

用 npx @daimonia/stc init 安装时，本 skill 目录是 .claude/skills/stc/。文字不在文件里时，可以通过标准输入传给检查命令。检查命令报的错误必须全部改掉。Anti-Echo 疑点必须结合读者和页面复核：删除多余内容，或为必要内容记录具体保留理由。复核文件的格式见 tools/README.md。文本变动后必须重新核对。其他警告宜逐条判断。

语义复核

交付前必须逐项检查：

• 每句话都帮助当前读者理解、判断或操作；多余排除、制作说明和自证已删除（G20）。
• 页面实际显示的标题、正文、按钮、提示、图注和角标均已逐项审阅（W9）。
• 同一个东西只用了一个叫法（G1）。
• 没有“进行、加以、予以、作出、开展”加名词（G4）。
• 程度词和模糊量词已换成数字或具体事实；数据均有原文或上下文依据（G5）。
• 没有营销词、行话、套话和口号句式（G6、G7）。
• 一句只讲一件事，一句不超过 40 个字（G9、G12）。
• 表示把握程度的词没有被删掉（G15）。
• 句子自然、语法完整，长短随内容变化（G21）。
• 篇幅满足任务，必要步骤和风险信息没有被压掉（G22）。
• 对话没有重复结论、工具旁白或不必要的模板（C7、C8、C9）。
• 任务回执分清完成结果、用户动作和知会；用户动作有真实依据，交付物有入口（C10）。
• 人称符合场景：for document 和 for web dev 里没有“我们”“你们”；for web dev 里也没有“他”“她”“它”“大家”（D1、W1）。
• for instruction writing 里，强度词只有“必须、不得、宜、不宜、可、不必、能、不能”（I1）。
• 数字用阿拉伯数字并带单位；中文与英文、数字之间有空格（G18、G19）。

不改动的内容

• 引语和用户的原话，包括其中的人称。
• 代码、命令、文件路径、接口名。
• 品牌口号、法律文本。
• 英文文字。STC 只管中文；英文可以参照 ASD-STE100。

参考

• 规则总览与编号一览：rules/README.md
• 词表格式与类别：dictionary/README.md