wj-write

name	wj-write
description	当需要润色中文技术文档或博客草稿、统一 Markdown 格式、修正中英文排版、去除 AI 腔、按既有作者风格改写时使用。适用于 README、指南、方案、规范、内部文档、博客文章等 Markdown 或纯文本文件。即使用户只说"帮我改改这段文字""润色一下""排版有问题""校对一下""文字不太通顺""改改措辞""帮我看看这段""文字有点别扭""读起来怪怪的"也应触发。不适用于翻译任务、纯英文文档或代码注释。

Write

概述

在不改变事实、技术结论和文档范围的前提下优化中文文档。默认做保守润色，覆盖文档措辞、 Markdown 结构和中英文排版；只有用户明确要求“改写”“贴近我的风格”“去 AI 味”“重写开头或结构”时，才做更强的风格化改写。

何时读取引用

• 用户要求“按我的风格”“贴近博客语气”“按博客文风改写”时，先读 references/author-style.md。
• 用户要求“去 AI 味”“减少套话”“让文章更像人写的”时，先读 references/de-ai-writing.md。
• 两者同时出现时，两份都读；先保留作者风格，再清理 AI 腔。

工作流

1. 从 $ARGUMENTS 或上下文确定目标文件；无法可靠判断时，要求用户提供明确路径。
2. 通读全文，先判断这次是“保守润色”还是“风格改写”。
3. 把修改分成两类：
   • 直接修正：错别字、语病、标点、空格、术语不一致、标题层级、列表格式、代码块、表格和明显损坏的 Markdown。
   • 需要确认：会改变语气、结构、强调顺序或信息密度的改写。
4. 直接应用直接修正。
5. 仅在用户明确要求更强改写时，执行风格化重写；否则保留原有表达。
6. 完成后说明改动类别，并标出未处理的歧义点。

硬性约束

• 保留命令、路径、标识符、URL、API 名称、代码行为和技术结论。
• 不补事实、例子、风险、背景或结论，除非原文已有或用户明确要求。
• 不把作者原本有辨识度的表达统一成通用“标准答案”。
• 不为了显得自然而加入夸张口语、感叹号、悬念式开头或无根据判断。

默认写法

• 先说最重要的信息，再展开解释。
• 处理抽象主题时，可先给背景，再补一句话定义或核心判断。
• 同一段里如果已经给出结论，不再用近义句重复拔高一遍。
• 抽象判断后面尽快跟机制、条件、例子或配置。
• 优先使用主动表达、明确主语和具体动词。
• 段落保持短到中等长度；长段落及时拆开。
• 用粗体强调关键概念，不滥用强调。

格式与排版

• 标题层级连续，不跳级，不超过四级。
• 无序列表使用 -，有序列表使用 1.。
• 表格保持标准 Markdown 语法与对齐。
• 代码块使用三个反引号；能可靠判断时补语言。
• 命令、路径、参数、环境变量、标识符使用行内代码。
• 中文与英文、数字之间补半角空格。
• 中文正文使用全角标点；英文与代码字面量保持半角。
• 术语前后写法一致，不来回切换。
• 已有英文标题、双语标题、英文术语或固定缩写默认保留，不为”统一中文”强行改写。
• 图示、引用块、表格、Mermaid、相对图片路径默认保留，不为”统一风格”而改写结构。

输出

• 说明修改了哪个文件。
• 用简短列表概括改动类别。
• 若做了风格化改写，说明本次主要遵循了哪些风格规则。
• 说明哪些位置仍需用户确认。