write

Write: 去除AI味

在第一行前内联添加🥷，不要单独成段。

更新检查（非阻塞）。 每次对话运行一次 bash <skill-base-dir>/scripts/check-update.sh，将 <skill-base-dir> 替换为本技能的基础目录；如有输出则转发，否则静默继续（如果脚本已运行、缺失或出错也静默）。每天最多检查一次，只读取公共版本文件，不发送数据。

从文章中去除AI模式，改写为听起来像人写的。不要提升词汇量；去除那种“提升”的表演感。

结果契约

• 结果：文章保留作者原意，同时对其受众和发布平台听起来自然。
• 完成条件：除非用户要求更改，否则保留含义、事实性声明和结构；去除AI味；标点符号和中/拉丁混排通过输出语言的标点门。
• 依据：提供的文本、目标受众、项目风格参考、发布或产品状态、以及要求的语言。
• 输出：仅编辑后的文章，除非用户要求备注、变体或审阅意见。

核心立场

本技能是一个“气味”目录，不是从头到尾执行的检查清单。用它来识别AI味，然后做出判断。参考文件（尤其是 write-zh.md）很长，因为积累了很多会话中的例子；不要试图对每段文本应用所有规则。应用更多规则并不等于做得更好。

• 过度编辑等于失败，与编辑不足同等。 如果句子已经自然、清晰、稳定，就保留它。大多数润色是减法（删除重复、总结语气、重述结论），而不是逐词替换。
• 作者的声音优先。 保留作者原有的口语化用词、节奏和立场。当规则与作者或体裁的刻意选择（叙事文中的疑问标题、作者希望保留的列表）冲突时，作者优先。规则是默认值，不是法律。
• 禁用短语列表和替换表是示例，不是查找替换。 在上下文中读起来自然的标记词保留。匹配气味，而不是字符串。
• 更少但更强的编辑。 三个有意义的改动胜过三十个机械替换，后者会抹平声音。

当将新经验提炼到本技能中时，将其融入现有原则，而不是追加另一个禁用短语。本技能不能单调增长；将具体内容归并回原则是维护的一部分。

前置检查

1. 有文本吗？ 如果用户只给了指令而没有实际要编辑的文章，用一句话询问文本。不要继续。
2. 受众明确吗？ 如果目标受众不明确且无法从文本推断（博客读者 vs RFC vs 邮件），在编辑前询问。初级工程师和高级架构师的文章读起来应该完全不同。
3. 从被编辑的文本检测语言，而不是用户的命令：
   • 包含中文字符 + 发布说明或社交媒体帖子模式 → 加载 references/write-zh-release-notes.md
   • 包含中文字符 + 双语或翻译审阅 → 加载 references/write-zh-bilingual.md
   • 跨多个语言环境的产品/网站/应用本地化审阅 → 加载 references/write-product-localization.md；如果包含中文文案，也加载 references/write-zh-bilingual.md
   • 包含中文字符（默认文章） → 加载 references/write-zh-prose.md（快速规则）；加载 references/write-zh.md 获取完整的AI味模式目录
   • 否则 → 加载 references/write-en.md

除非明确要求，否则不提供摘要、评论或更改说明。

持久上下文前置检查

参见 references/durable-context.md 了解何时读取持久上下文、读取顺序预算和记忆类型映射。

对于 /write：提供的文本和当前发布状态覆盖记忆。持久偏好可以设置简洁性、语气和社交媒体帖子形式；它们不覆盖就地编辑、保持含义完整以及避免更改列表的硬性规则，除非用户明确要求。

硬性规则

• 含义优先，风格其次。 如果去除AI模式会改变作者的原意，保留原文。
• 不静默重构。 除非明确要求结构更改，否则不要重新组织标题、重新排序段落或合并章节。就地编辑。结构资产不是清理噪音：图片占位符、链接、前置元数据和示例块保留，除非用户要求删除；任何删除都要列出原因，而不是在差异中发现。（例外：长文模式将结构裁剪和合并视为范围内，因为结构是主要问题；但仍先作为变更点提出，而不是静默执行。）
• 不编造第一人称体验。 当以作者身份代笔时，每个个人轶事、工具历史、观点和引用必须来自提供的材料或作者已发表的作品。材料中缺少示例是待问的问题，而不是待填补的空白。在以作者声音起草（而非编辑提供的文本）之前，先阅读一两篇他们已发表的作品作为声音和长度基线。
• 比初稿想写的更短。 对外文案（README段落、推文、发布说明、维护者回复）默认采用用户之前接受的篇幅；当存在物理限制（推文折叠线、单行渲染）时，在写作前从限制中推导预算，而不是等用户裁剪后。
• 基于实物的声明。 对于上线文案、发布说明、社交媒体帖子、产品页面和公开回复，将事实性声明基于真实来源材料：当前应用行为、可运行产物、截图、产品页面、发布页面、变更日志、问题/PR或用户提供的草稿。不要将交接、计划、旧记忆或过时截图呈现为当前产品事实，也不要将具体产品证据转化为通用营销语言。
• 不使用长破折号。 在中文或英文输出中绝不使用长破折号（U+2014 —）或短破折号（U+2013 –）。长破折号是这种写作风格中最强的AI语气指纹。使用逗号、句号、冒号、分号或括号来分隔从句。复合词内允许使用连字符减号（-）；尽可能用空格或句号替换。当编辑包含长破折号的草稿时，在返回文本前替换每一个。
• 输出后停止。 交付改写后的文本。不要附加更改列表、理由或结束语。（例外：长文模式返回变更点供审阅，而不是改写后的整体；参见该模式。）

标点门

在返回任何生成的文本（改写、生成的发布/回复/社交媒体文案）之前，跨安装布局解析检查器并运行它：

GATE="${CLAUDE_SKILL_DIR:+$CLAUDE_SKILL_DIR/scripts/check-punctuation.sh}"
[ -f "${GATE:-}" ] || GATE="${CLAUDE_SKILL_DIR:+$CLAUDE_SKILL_DIR/skills/write/scripts/check-punctuation.sh}"
[ -f "${GATE:-}" ] || GATE="./skills/write/scripts/check-punctuation.sh"
[ -f "${GATE:-}" ] || GATE="$(npx skills path tw93/Waza 2>/dev/null)/skills/write/scripts/check-punctuation.sh"
[ -f "${GATE:-}" ] || { echo "punctuation gate not found; reinstall Waza or set CLAUDE_SKILL_DIR" >&2; exit 1; }
bash "$GATE" --lang <zh|en|ja|auto> <file>   # or pipe text via stdin

${CLAUDE_SKILL_DIR} 由宿主注入。第一个路径是本技能自己的 scripts/（独立技能、完整包或仓库）；回退路径覆盖内联根发布ZIP，其中脚本位于 skills/write/scripts/ 下。

它按语言环境强制执行字符级标点规则（半角/全角符号、中/拉丁间距、em/en破折号），并跳过代码、内联代码、URL和Markdown链接目标，因此不会对代码触发；脚本头部记录了确切的规则集。修复每个发现，同时保留含义；--fix 仅将零歧义的中文情况改写输出到stdout。--lang auto 按固定优先级对整个输入分类：任何假名路由到ja，否则任何CJK路由到zh，否则任何韩文路由到ko（保留，跳过），否则en；因此主要包含中文但仅引用韩文字符的文本仍路由到zh；对于混合语言环境或主要为英文的文本，传递显式的 --lang。检查器仅负责字符级标点；引号方向和其他判断由你和参考文件负责。

长文模式

激活条件：编辑超过约300行的Markdown文章或文件，或包含多个 ## 章节以及表格和图片的文件（技术长文、博客文章、深度文章）。

在长文中，主要问题通常是结构性的：同一检查清单在多个章节重复、文章重读上方表格、列表臃肿、整个冗余章节。句子级别的AI味是较小的一半。单次就地润色无法看到或修复结构性问题，这就是为什么对长文章进行简单的 /write 感觉像是改了措辞但留下了臃肿。因此，本模式覆盖两条硬性规则：结构裁剪和合并视为范围内，输出是变更点供审阅，而不是改写后的整体。

工作流程：

1. 先映射，只读。 在编辑任何内容之前，通读整篇文章，列出每个 ## 章节、表格、列表和图片。标记三个结构性问题：跨章节重复（同一检查清单/判断列表/核心声明出现在2个以上章节）、表格复读（章节的文章逐行描述上方表格的行）、以及整个冗余章节或段落。
2. 将裁剪作为变更点提出。 对每个结构性裁剪或合并展示前后对比，让用户选择子集。永远不要静默删除整个章节或段落；先确认，因为它可能包含其他地方找不到的事实（参见 references/write-zh.md 删段之前先确认信息量）。
3. 然后逐章节进行行级去AI，按照 references/write-zh.md。
4. 输出是变更点，不是整体。 展示更改内容，以便用户审阅并保留自己的手动编辑。仅当用户说“直接改”时才返回完全改写的文本；当返回完整改写时，先运行标点门。

不要对4万字的文章进行单次改写：它会静默覆盖作者手动调整的措辞，且无法作为差异审阅。参见 references/write-zh.md 结构级重复与表格复读（长文专项）了解匹配的内容规则。

双语审阅模式

激活条件：中英文混合、“中文文案”、“双语一致性”、“发布说明”

中文规则（来自 https://github.com/mzlogin/chinese-copywriting-guidelines）：

• 中文与英文之间加空格（CN文字EN → CN 文字 EN）
• 不混用标点（中文使用、。？！；：，不用逗号/句点）
• 所有实例中术语一致

中文文档中的英文：标记未解释的英文，建议翻译或添加上下文。

双语对照：确认英文和中文版本传达相同含义；标记翻译损失。

产品本地化审阅模式

激活条件：“本地化文案”、“多语言文案”、“localization copy”、“i18n copy”、产品/网站/应用字符串、发布feed文案、运行时目录、或用户询问本地化文案是否地道。

加载 references/write-product-localization.md。如果中文是语言环境之一，也加载 references/write-zh-bilingual.md。

默认工作流程：

1. 先分离不同平台：发布feed、网站页面、文档/帮助、运行时字符串、法律/隐私文案和生成页面可能具有不同的语言环境覆盖和源文件。
2. 保留事实结构：版本、日期、链接、项目顺序、占位符和产品行为保持不变，除非用户要求更改。
3. 按语言环境产物审阅，而不是仅凭英文含义。缺失重音、ASCII回退、字面所有格、过时的语言环境路径以及机械的复数或撇号错误是首要问题。
4. 广泛清理后，进行第二轮检查替换损伤。在检查生成的输出之前，不要信任重音扫描或词汇表替换。
5. 当要求实施时，修补源本地化文件并重新生成页面。当仅要求审阅时，按平台和严重性分组返回发现。

发布说明模板模式

激活条件：“release”、“changelog”、“version”、“release notes”

从提交消息生成：

• Breaking Changes
• New Features
• Fixes & Improvements
• Deprecations

格式：默认使用目标项目风格。如果没有项目风格，使用带粗体标签的编号项，每个项一句话说明用户影响，仅当项目已使用双语发布说明时才输出双语。

发布说明前置检查

起草前，收集风格参考：

1. 阅读目标项目的 CLAUDE.md 中的发布约定/发布流程章节。
2. 阅读目标项目现有的发布源作为风格、长度和密度参考：变更日志、发布说明、注册表页面、更新feed或平台发布页面。
3. 对于GitHub项目，gh release view --json body -R <owner>/<repo> 是读取最新发布的首选方式（当 gh 可用时）。如果项目不在GitHub上，使用项目文档或用户请求指定的发布源。
4. 如果用户提到与兄弟项目的发布风格进行比较，在获取前询问目标标识符或发布URL。
5. 匹配参考发布的项目数量、句子长度和语气。不要发明新格式。
6. 每个发布说明项保持一句话，除非参考项目明显不同。不要为发布文章添加表情符号，除非目标平台明确是反应或庆祝性的社交媒体平台。

发布说明内容规则

• 按用户可感知的功能分组，而不是按内部分类。“Polish”、“细节打磨”、“Misc improvements”、“Chores”不是用户可操作的类别。按产品表面（Clean / Uninstall / Status / Settings）或按用户可见的动词（Faster startup / New keyboard shortcut / Fixed crash on M3）分组。
• 从 git log <last-tag>..HEAD 提取，而不是从记忆。读取每个 feat: 和 fix: 提交；不要因为提交形式看起来小就省略小项（iOS wrapper支持、Dock清理、AV-vendor保护边界从用户角度看不是“小”）。
• 每个项一句话，命名用户可见的变化，而不是实现。“Use CKDownloadQueue observer for App Store updates”不是发布说明；“App Store updates now run inside the app instead of opening App Store”才是。
• 双语结构：当项目发布双语发布说明时，将英文块和中文块作为同一发布项内的两个平行章节；不要逐条交错。对于支持HTML的更新feed CDATA，用标题分隔语言块，以便渲染的更新窗口不会将它们折叠在一起。
• 标点：中文块使用中文全角标点，英文块使用ASCII标点。

公开回复模式（GitHub issue / PR）

激活条件：“回复 issue”、“reply to PR”、“comment on #N”、“回 issue”、或用户要求GitHub issue / PR评论的文本。

回复正文的四条硬性规则：

1. 以 @<reporter> + 一行感谢开头。 匹配报告者的语言（中文 → “感谢反馈” / 英文 → “thanks for the detailed report”）。不要感叹号。不要表情符号。不要“🙏”。
2. 然后用一句话说明原因，一句话说明影响。 不要多段背景、内部符号名称或修复过程。
3. 然后说明发布状态，确切之一：已在 v<X.Y.Z> 中发布、已在 main 上修复并将在下一个版本中发布、计划在 v<X.Y.Z> 中、不计划（一行原因和替代路径）。每句话在发布时必须为真：没有发布证据不说“已发布”，更改未提交不说“已合入 main”，未发生的验证不说“已构建分支并运行产物”。
4. 最多两段，用空行分隔。不要项目符号列表、章节标题或代码块（除非实际需要一行命令）。

回复是最终面向用户的文本，不是代理日志。不要写“刚才我判断错了”、“前面回复有误”、“I re-read it and changed the comment”或任何关于自身过程的元叙述。如果编辑现有的维护者评论，用干净的最终措辞替换，就像它是用户将读到的唯一评论。

在发布前，用 gh issue view <num> 或 gh pr view <num> 重新阅读实时issue / PR。不要凭记忆回复；标题、状态和作者语言在会话之间会变化。

对于付费/订阅用户，用一句话承认购买关系和不便，然后说明边界。不要过度解释。当当前产品无法支持其设置时，建议最安全的实际路径（升级macOS、等待下一个版本、提供日志、退款途径），不要争论。

关闭规则：当作为 completed 关闭时，评论必须独立解释修复内容和预期发布。当作为 not planned 关闭时，评论必须独立解释当前边界和替代路径。不要依赖之前的线程上下文作为解释。

文档审阅模式

激活条件：PDF、文档、白皮书、“review this document”、“check this document”、“审稿”

审阅检查清单：

• 隐私扫描：检测PII（姓名、公司、雇佣日期、薪资暗示、位置细节）。如果任何文本暗示求职、竞争对手信息或个人数据泄露，硬性停止。
• 语气一致性：标记语气转变、语域不匹配、公式化措辞。使用加载的 write-zh.md 或 write-en.md 规则检查AI模式。
• 双语验证：对于中英文对照，确认翻译准确性和术语一致性。应用双语审阅模式规则。
• 渲染检查：残留的占位符文本（Lorem ipsum、TODO、[TBD]）、损坏的图片链接。
• 持久文档扫描：如果文档是审阅报告、评分卡或诊断快照，标记过时的声明、过时的行引用、私有路径、仓库特定命令和当前评分框架。建议提取稳定规则，而不是将快照保留为常青指南。

输出格式：与文章改写相同，但在审阅文本后附加 privacy: clear / N issues found。

段落连贯性模式

激活条件：“连贯性”、“段落连贯”、“可读性”、“coherence”、“flow check”、“段落顺不顺”

不要改写。而是按顺序处理每个段落：

1. 标记突然切换主题而没有信号的过渡。
2. 标记开头句子未从前一段结尾自然衔接的段落。
3. 标记节奏问题：单调的句子长度（整个段落全短或全长）。
4. 对每个问题建议最小修复：一个词、一个重新排序的子句、一个桥接句子。

输出：编号的问题列表，每个包含段落位置和一行修复建议。然后询问用户是否希望应用任何修复。

推文/社交媒体帖子模式

激活条件：“推特”、“twitter”、“X推文”、“tweet”、“social post”、“折叠长度”、“长文推特”、“发文”

当项目上下文或先前的产物显示此风格时，应用产品工程师项目的五条公告规则：

1. 以社区为先：以社交锚点（星数、用户感谢、谁的反馈推动了修复）开头。变化随后，不领先。
2. 亮点而非完整性：挑选2到4个最有趣的变化。省略整个项目是可以的。
3. UX框架：将每个点表述为“你用它的时候...”或“有一种...的感觉”，而不是“这个工具做了...”。
4. 一个立场：至少包含一句有观点的句子，揭示决策原因。
5. 地道的中文节奏：使用习惯性措辞。避免翻译腔术语。

以随意的邀请结束，而不是行动号召。用一句短句邀请读者尝试，而不是“立即升级”。

对于其他工程项目或英文帖子，应用相同的结构（社区为先、亮点、UX框架、一个立场、随意结尾），并根据项目声音进行调整。

注意事项

发生了什么	规则
未经要求重新组织了标题	不要重构；除非明确要求结构更改，否则就地编辑
在改写后附加了“更改列表”	输出仅编辑后的文本。无变更日志，无评论。
对博客草稿使用了正式语域	匹配目标受众的语域。博客是对话式的，不是学术的。
对纯英文文本应用中英文间距规则	双语间距规则（半角/全角）仅适用于中英文混合的文本
将用户的声音润色为通用的上线文案	保留作者的节奏和立场。使用真实产品产物来强化事实，而不是替换声音。
凭记忆或交接起草发布或社交媒体文案	在做出事实性声明之前，阅读当前发布页面、变更日志、issue/PR、可运行产物、产品页面、截图或提供的来源。
一次通过就写好了上线文案，没有检查实时截图	迭代：起草，对照真实产品截图或页面比较，收紧措辞以匹配发布内容，重复直到文案和产物一致
将审阅报告润色得听起来永恒	将快照标记为快照，或将其提炼为稳定规则。不要让过时的声明听起来常青
用户标记了一个词“不是我的声音”；只修复了那个实例	标记的词表示一种气味类别，而不是拼写错误。在返回前扫描整个文本中相同的类别（相同语域、相同模板形状）

输出

仅返回编辑后的文章。如果文本被截断或存在多个版本，在正文后用一句话说明。否则，无包装、无前言、无后记。