| name | wj-write |
| description | 当需要润色中文技术文档或博客草稿、统一 Markdown 格式、修正中英文排版、去除 AI 腔、按既有作者风格改写时使用。适用于 README、指南、方案、规范、内部文档、博客文章等 Markdown 或纯文本文件。即使用户只说"帮我改改这段文字""润色一下""排版有问题""校对一下""文字不太通顺""改改措辞""帮我看看这段""文字有点别扭""读起来怪怪的"也应触发。不适用于翻译任务、纯英文文档或代码注释。 |
Write
概述
在不改变事实、技术结论和文档范围的前提下优化中文文档。默认做保守润色，覆盖文档措辞、 Markdown 结构和中英文排版；只有用户明确要求“改写”“贴近我的风格”“去 AI 味”“重写开头或结构”时，才做更强的风格化改写。
何时读取引用
- 用户要求“按我的风格”“贴近博客语气”“按博客文风改写”时，先读
references/author-style.md。
- 用户要求“去 AI 味”“减少套话”“让文章更像人写的”时，先读
references/de-ai-writing.md。
- 两者同时出现时，两份都读；先保留作者风格，再清理 AI 腔。
工作流
- 从
$ARGUMENTS 或上下文确定目标文件；无法可靠判断时，要求用户提供明确路径。
- 通读全文，先判断这次是“保守润色”还是“风格改写”。
- 把修改分成两类：
- 直接修正：错别字、语病、标点、空格、术语不一致、标题层级、列表格式、代码块、表格和明显损坏的 Markdown。
- 需要确认：会改变语气、结构、强调顺序或信息密度的改写。
- 直接应用直接修正。
- 仅在用户明确要求更强改写时，执行风格化重写；否则保留原有表达。
- 完成后说明改动类别，并标出未处理的歧义点。
硬性约束
- 保留命令、路径、标识符、URL、API 名称、代码行为和技术结论。
- 不补事实、例子、风险、背景或结论，除非原文已有或用户明确要求。
- 不把作者原本有辨识度的表达统一成通用“标准答案”。
- 不为了显得自然而加入夸张口语、感叹号、悬念式开头或无根据判断。
默认写法
- 先说最重要的信息，再展开解释。
- 处理抽象主题时，可先给背景，再补一句话定义或核心判断。
- 同一段里如果已经给出结论，不再用近义句重复拔高一遍。
- 抽象判断后面尽快跟机制、条件、例子或配置。
- 优先使用主动表达、明确主语和具体动词。
- 段落保持短到中等长度；长段落及时拆开。
- 用粗体强调关键概念，不滥用强调。
格式与排版
- 标题层级连续，不跳级，不超过四级。
- 无序列表使用
-，有序列表使用 1.。
- 表格保持标准 Markdown 语法与对齐。
- 代码块使用三个反引号；能可靠判断时补语言。
- 命令、路径、参数、环境变量、标识符使用行内代码。
- 中文与英文、数字之间补半角空格。
- 中文正文使用全角标点；英文与代码字面量保持半角。
- 术语前后写法一致，不来回切换。
- 已有英文标题、双语标题、英文术语或固定缩写默认保留，不为”统一中文”强行改写。
- 图示、引用块、表格、Mermaid、相对图片路径默认保留，不为”统一风格”而改写结构。
输出
- 说明修改了哪个文件。
- 用简短列表概括改动类别。
- 若做了风格化改写，说明本次主要遵循了哪些风格规则。
- 说明哪些位置仍需用户确认。
