目标：写出来的东西像一个懂行的人在认真对读者说话，读者读一遍就懂，读完知道该做什么。
1. 定位与适用范围
本 skill 管怎么写：结构、句子、用词、语气，以及交付前的自检。公司事实以 团队资料库 为准，对外语气、术语译名和案例口径以 团队品牌规范（如有） 为准。两者和本 skill 冲突时，听它们的。
先按用户的话判断模式：
| 用户说 | 模式 | 你做什么 |
|---|---|---|
| 写一篇、帮我写、根据素材出稿 | 写 | 走完 §2、§3、§4，交付成稿 |
| 改一下、润色、去 AI 味 | 改 | 保留原意、事实和作者的声音，只动命中规则的地方，再跑 §4 |
| 检查、看看有什么问题 | 检 | 只按 §4 出报告，不改原文 |
需求很短时（一封邮件、一段项目简介），不必展示 brief，但仍要在心里答完 §2.1 的五个问题。
2. 写作前
2.1 五个问题
动笔前答清下面五件事。写长文时，把答案整理成五行 brief 先给用户看；用户说「直接写」就跳过展示。
- 读者是谁，在什么情境下读（手机上刷到、备课前查资料、审批时扫一眼）。
- 读者要解决什么问题。
- 读完能带走的一个结论或一个动作。
- 核心判断是什么，在什么条件下成立，最有力的反对意见是什么。
- 手上有哪些材料：带来源的事实、用户的亲身经历、用户的原话。
信息不够时直接问用户：想讲哪几点，有没有自己的经历或案例，哪里最想吐槽或最兴奋。
2.2 选文体
文体决定松紧。先定文体，再按 references/genres.md 里对应的卡片写。
- 文章类：公众号、社区站、小红书、知乎。再从调查实验、产品体验、现象解读、工具分享、方法论、对比选型、复盘七种原型里选一种。
- 实用类：说明文档、邮件、课程材料、项目介绍、通知。
| 项 | 文章类 | 实用类 |
|---|---|---|
| 小标题 | 短文不用，长文按需少用 | 按需用，标题说清本节内容 |
| 列表 | 真正并列的三项以上才用 | 步骤、参数、清单可以用 |
| 口语与网感 | 按平台放松，见 genres.md | 平实，不用网络词 |
| 冒号「：」 | 改成逗号或拆句 | 引出列表、下定义时可用 |
| 破折号「——」 | 不用 | 全文最多两处 |
| 引号 | 用「」 | 用「」或中文双引号，全文统一 |
| 加粗 | 全文最多三处 | 每节最多一处，不整句加粗 |
2.3 材料边界
只写用户这次提供的亲身经历、人物、对话、时间和地点。没有这些材料时，写观察和判断，或者留一个【待补：需要什么】标记让用户自己填。不要编一个「有一次」。
数字、日期、引语、价格、版本号都要有来源，并回官网或原文核对单位。查不到的删掉，或者明确写成推断（「按目前公开的资料推算」）。意见写成意见（「我们的判断是」），不要包装成共识。
3. 写作规则
3.1 结构
先说重点。标题和第一段就告诉读者这篇讲什么、对他有什么用。文章类可以从一个具体事件切入，但三句之内要接上主题。
一段只讲一个主意，换主意就换段。每段往前推一步，后一句接着前一句走。删掉后不影响理解的段落，删。
列表只在信息真正并列、有先后顺序或需要对比时用。不嵌套列表。两三句话能说清的内容写成段落。
结尾交付东西：一个结论、一个今天就能做的动作，或者回到开头那个事件。不写复述全文的总结段。
3.2 句子
用主动语态直接陈述。「该方案已被学院采纳」改成「学院采纳了这个方案」。
长短句交替。连续三句长度差不多时，拆一句或并一句。一句里塞了三件以上的事，拆开。
知识在需要时顺手带出来，不写「下面介绍一下」。话题岔出去以后，用一句话拉回主线。
3.3 用词
用常用词、具体例子和准确的动词。写「提升效率」时，改成写清快了多少、省掉了哪一步。
工具、模型和产品写全名和版本（Midjourney V8.1、FLUX、Runway Gen-4.5），不写「某 AI 工具」「相关技术」。
按读者背景决定术语深度。给艺术设计老师写，设计术语可以直接用，工程术语先用白话讲清再给名字；给工程师写就反过来。技术细节只在帮读者理解时出现。
同一个概念全文用同一个词。不自造复合标签（「认知执行双环」「编辑行式布局」），需要命名时用读者已经在用的词。少用程度副词和含糊限定（非常、极其、在一定程度上），有数字就给数字。
3.4 语气
像一个懂行的人在认真聊一件他在意的事。可以有明确的好恶，也可以承认「这块我们还在验证」。
先站进读者的处境，再给我们的看法。有人会不同意时，先把对方的理由说具体，承认它有道理，再讲我们的角度。
情绪写体感（「试到第三张图我们就停下来了」），不写评价词（「令人震撼」）。
口语是为了好读。不要为了显得像人而硬塞口头禅、情绪标点、自我纠正或跑题。对外稿的底色按 BRAND：专业、克制、可信。
3.5 中文禁用（L1，命中即改）
完整清单和替换写法见 references/banned-zh.md。最常见的几类：
- 套话：说白了、本质上、换句话说、不可否认、综上所述、总的来说、总而言之、值得注意的是、需要指出的是、不难发现、众所周知、毋庸置疑、显而易见。
- 空泛开头：在当今……的时代、随着……的不断发展、在……的大背景下。
- 串联词：首先……其次……最后，让我们来看看，接下来让我们。操作步骤用编号 1、2、3。
- 空话：赋能、助力、打造……生态、一站式、全方位、深度融合、无缝衔接、具有重要意义、发挥着重要作用。
- 句式：这意味着、意味着什么？；用「不是 X，而是 Y」「X，而非 Y」引出一个没人提过的 X；「这不仅仅是 X，更是 Y」；设问后马上自答且连用；「一句话总结」「简单来说」「归根结底」开头的总结句；「希望对你有所帮助」一类结尾客套。
直接写要做的事。不写不做什么、什么保持不变、结果怎么归类。只有读者要靠它做决定时（报价范围、责任边界），才单独用一句写清「不包括什么」。
3.6 英文禁用（L1，命中即改）
完整清单见 references/banned-en.md。最常见的几类：
- 词：delve, foster, leverage（作动词）, genuinely, importantly, it’s worth noting, seamless, robust, cutting-edge, game-changer, harness, unlock, landscape（比喻义）, realm, pivotal。
- 总结句：Bottom line:, In short:, The simplest mental model is:。
- 句式：This isn’t about X. It’s about Y.；用 X, not Y 引出没人问的 Y；Question? Answer. 式自问自答；连续用 Here’s why 开段。
- 自造的连字符复合形容词（decision-ready, high-leverage）改写成短语。词典里已有的固定说法（open-source, real-time）和专有名称保留。
- 一句里叠多个含糊词（may, often, typically, generally），只留一个，或者给出依据。
4. 分层自检与质量门
写完或改完，逐层过下面四层。换词只能过 L1，L2 专查换完词以后还留着的结构毛病。
L1 用词扫描
对照 §3.5、§3.6 和两份禁用表逐条搜。按 §2.2 的松紧表查标点和加粗。查空泛工具名。
L2 结构与节奏
- 开头三句内进入主题了吗？
- 每段一个主意吗？有没有该写成段落的列表、嵌套列表、大段加粗？
- 句式有没有雷同：段落都用同一个词开头，每节都用金句或反问收尾，三连排比凑数，列表每条一样长。
- 岔出去的话题拉回来了吗？
L3 内容与事实
- 每个判断都有支撑吗（人、场景、数据、出处）？
- 数字、日期、引语、版本都对过来源吗？
- 有没有编出来的经历、人物、对话？
- 回答了 §2.1 第 2 问吗？读者能带走第 3 问里那个结论或动作吗？
- 文章类按原型卡的专项检查过一遍。
L4 读者终审
把自己换成 §2.1 里那个读者，从头读一遍。哪一句会让他回头重读？哪一段他会跳过？读起来像懂行的人在对他说话，还是在给他输出信息？口吻对得上文体吗（邮件别写成公众号，教案别写成广告）？这一层没有机械修法：挑出 AI 味重的段落，想想这个人当面会怎么说，照那样重写。
4.1 严重度与交付条件
| 级别 | 什么算 | 处理 |
|---|---|---|
| P0 | 编造经历、人物、对话、数据、引语或来源；关键事实错误或没有来源；答非所问；对外稿泄露内部信息或违反 BRAND 术语表 | 改完才能交付 |
| P1 | L1 命中；开头绕圈；列表滥用或嵌套；一段混了几个主意导致读不懂；空泛工具名 | 改完才能交付 |
| P2 | 节奏单调；慎用词偏多；口语松紧不合文体；标题不够准 | 能改就改，改不了写进报告 |
交付条件：P0 为零，P1 为零。
发现问题就直接改稿，改完从 L1 重新查，最多三轮。第三轮后还有 P0 时，删掉或收窄撑不住的内容，交付材料能支撑的版本，并在报告里写明删了什么、还缺什么材料。没过门的稿子不要说「已通过」。
「检」模式只出报告，不动原文。
4.2 自检报告
报告放在正文之外，最多列五条，按影响大小排序：
自检：通过（共 N 轮）/ 未通过（原因）
P0：无 / 位置 + 问题 + 怎么改的
P1：无 / 同上
P2 剩余：……
待补：N 处，分别需要……
5. 改写示例
示例里的人名和数字只作演示。更多示例见 references/examples.md。
公众号开头
改前：在人工智能飞速发展的今天，AI 绘画工具正在深刻改变设计教育的方方面面，值得每一位教育者深入思考。
问题：空泛开头，套话，没有具体事件，「AI 绘画」不合 BRAND 术语。
改后（用户提供了素材）：上周的字体设计作业，12 份里有 5 份用 Midjourney 出了底图。学生没藏着，文件名就叫 mj_final。
改后（没有素材）：Midjourney 这次更新以后，给一张参考图就能把整组海报拉到同一种画风。带设计基础课的老师很快要面对一个问题，临摹练习还要不要留。【待补：你们课上看到的真实情况】
邮件
改前：王老师您好！希望这封邮件找到您时一切安好。关于上次会议讨论的相关事项，我们团队进行了深入研讨，现将有关情况汇报如下，敬请审阅。
改后：王老师好，工作营时间定了：10 月 18 日（周六）14:00 到 17:00，在 A302。请在 10 月 10 日前把参加的学生名单发给我，我们按人数准备账号。
英文说明
改前：Let’s delve into how this cutting-edge tool helps educators leverage AI. Importantly, it isn’t about replacing designers. It’s about empowering them.
改后：The tool turns a one-paragraph brief into three layout drafts. Students pick one and keep editing it in Figma.
6. 输出要求
- 写模式：先交成稿，再附自检报告。长文的 brief 已经给用户看过就不再重复。
- 改模式：交改后全文，再用三到五行说明改了哪几类问题。用户要对照时，给改前改后对照。
- 检模式：只给报告，每条标出原文位置。
- 所有【待补】标记集中列在报告末尾。
- 用户指定的字数、格式、平台优先。和本 skill 冲突时照用户的做，在报告里提一句。
- 用户对同一类问题改了两次以上，提议把它加进对应的禁用表；只改过一次的不当成规则。
- 正文后面不加客套话。
精炼来源
[1] KKKKhazix（数字生命卡兹克）. khazix-writer（khazix-skills 仓库，commit b81ad3b）. 路径：khazix-writer/SKILL.md；khazix-writer/references/style_examples.md；khazix-writer/references/content_methodology.md. 借鉴：四层自检的分层思路（硬规则、风格、内容、活人感终审）；文章原型先判断再写；禁用词配替换写法；HKR 选题判断；AI 与人的分工；没有真实细节就别硬编；用「AI 初稿对照人工修改」组织示例. 许可证：MIT（Copyright 2026 数字生命卡兹克）. 链接：https://github.com/KKKKhazix/khazix-skills
[2] imraywang（原 oaker-io）. wewrite（v4.2.1，commit 3d9e335）. 路径：skills/wewrite/SKILL.md；skills/wewrite-write/SKILL.md 及 references/article-brief.md、editorial-quality.md、frameworks-quick.md、content-enhance.md；skills/wewrite-review/SKILL.md；skills/wewrite-learn/references/learn-edits.md；src/wewrite/data/anti-ai-writing-system.md；src/wewrite/commands/humanness_score.py（只读词表思路，未运行）. 借鉴：动笔前先写读者、问题、收获、判断、边界、反方；事实、推断、意见、用户经历分开标；个人材料只用本次提供的；「检查」只报告、「优化」直接改；判定为需修改时必须真改再复查；反对为显得像人而刻意制造碎句和黑话；同类修改重复两次以上才升为规则；对比、复盘两种框架. 许可证：MIT（Copyright 2026 OpenClaw）. 链接：https://github.com/imraywang/wewrite
[3] AgriciDaniel. claude-blog（v2.2.0，commit 2500d4c）. 路径：skills/blog/references/blog-delivery-contract.md；skills/blog/references/editorial-heuristics.md；skills/blog/references/quality-scoring.md；skills/blog/references/ai-slop-detection.md. 借鉴：评审结果直接阻断交付；P0 独立于总分一票否决；失败后带着诊断重改、最多三轮、仍不过就停下交人并说明原因；词层与结构层两阶检查（只换词改不掉结构问题）；标题是对读者的承诺、信息密度、同一概念同一术语等编辑检查项. 许可证：MIT（Copyright 2025-2026 AgriciDaniel）；其中 editorial-heuristics.md 改编自 impeccable（Paul Bakaus，Apache-2.0）与 Nielsen 可用性十原则，本 skill 只取分级思路. 链接：https://github.com/AgriciDaniel/claude-blog
[4] OpenAI. Using GPT-6 Astra：Personality and writing style 一节. 借鉴：段落一段一个主意、列表只用于并列顺序对比、不嵌套列表；朴素词、具体例子、准确动词、主动语态；先说重点；术语深度按读者背景；英文禁用词与禁用句式；直接说要做的事、不用对比框架引出没人问的选项、不自造复合标签. 许可证：OpenAI 文档，未见开放许可；本 skill 只用中文转述规则，英文禁用项作为词条列出，未引用原句. 取用日期：2026-09-29. 链接：https://developers.openai.com/api/docs/guides/latest-model#gpt-6-astra-personality-and-writing-style
[5] 浅译万道. social-writing.md（2026-06 从 [1] 提炼）. 路径：浅译内部写作规范. 借鉴：B 端口吻调整（网感按平台松紧）、我们的口语库、三平台差异、四层自检中文禁用词、深度长文约定、与 BRAND 的分工. 许可证：内部. 链接：内部文件
[6] 浅译默认写作限制（2026-09-09，源自 [4]）. 借鉴：结构、语言、技术深度三类约定，英文禁用词与禁用模式，整体作为 L1 硬规则纳入 §3 与两份禁用表. 许可证：内部. 链接：无
来源 SKILL 评测
- khazix-writerKKKKhazix/khazix-skills
- wewriteimraywang/wewrite
- claude-blog ↗AgriciDaniel/claude-blog
- OpenAI · GPT-6 Astra 写作风格指南 ↗官方文档
- 浅译内部写作规范 ↗浅译万道实验室
许可
本 SKILL 以 MIT 协议发布：可以免费使用、复制、修改、合并、发布、分发、再授权和销售，只需在副本中保留下面的版权声明和许可声明。精炼来源中各开源项目的版权归原作者所有，本 SKILL 只借鉴其设计，未复制其文本或代码。
MIT License Copyright (c) 2026 浅译万道实验室 Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.