version: "1.0.1" name: writing-for-people description: 写或改任何会离开这个对话的字之前加载：落成文件的、发给别人的、进仓库或文档的。评论、code review、给别人的回复、帖子、邮件、文章、个人陈述、发言稿、给评审看的材料、README、release note、文档、代码注释、commit message、PR 描述都在内。他会转手发出去的字在内，哪怕写在给他的回复里：他问「这封邮件我该怎么回」，要的那句就是本 skill 的活。真正不在内的只有两种：说完就停在这个对话里、他不会转发的话；给后来的 session 当规则读的指令文件（skill、CLAUDE.md），那归 writing-instructions。最容易漏的是应答式写作：回评论、回 issue、回邮件、在聊天软件里回别人，被人问一句答一句，感觉像在说话不像在写东西，检查根本不会触发。短不豁免，一句话的回复也要过，越短的字 AI 腔越集中（"Happy to"、"Let me know"、"Feel free to" 全长在短回复里）。被动不豁免，别人先开口不改变性质，发出去的仍然是署他名字的字。Use before writing or editing any text that leaves this conversation for a file, a repository, a document or another person, including a line he asked for so that he can send it on. Only what stops inside the conversation is outside it.

<!-- 本文件和 writing-reviewer.agent.md 里 「」 是自指标记（章节名、要照抄的模板、句式术语），“” 才是普通引语。往这两份文件加中文时照这个分工走，别把既有的 「」 统一成 “”。 -->

写给人看的字：先定读者，再去痕迹

目标：先定读者是谁、他拿去做什么，那一步决定内容留什么删什么；然后才让它读起来像一个真人在认真说话，而不是一台被调教得过度光滑的机器。

全文三个代词各指一个人：「他」是署名的那个人，你替他写；「读者」是收这段字的人；「你」是你，写字的模型。

成稿之后逐条数的表（英文换词表和套路清单、按形状认的、中英文 tell、字频上限、标点、重写阈值、写他自己时的扫词和扫人名）不在这份文件里，在 ~/.claude/skills/writing-for-people/writing-reviewer.agent.md。这里放的是写的时候就要定的判断，其中几条成稿后还会被那边再数一遍。

动笔前：先定读者和文体

进代码和仓库的一律英文：代码注释、文档、提交信息、PR/issue 评论、GitHub review，除非他另说。邮件、发言稿、个人陈述、文章按读者定语言，不受这条管。对话用什么语言不影响这一条。

底下所有清单都是减法：告诉你删什么，从不问你写给谁。清单能查出病灶，查不出姿态。 最难看的那几句往往一条规则都不违反，只有把读者放进来才看得见。

动笔前先在回复里写出一行「读者=X，他拿去做Y，落地载体=Z，档位=W」，不写进稿子。 这一行是这一步的产物：四样都写上，回复里没有它或缺一样，这一步就没做。读者不是“用户”，是具体的人和处境： 谁读、读者要向谁交代、会不会被转给第三方。写下之后查五样：

1. 称谓。给本人看的东西，不能用第三人称直呼其名转述读者说过的话

（“小王之前提过” → “贵方此前提出”）。文中出现一个人名，全篇称谓一起看。

1. 关系边界。按他说明的关系、双方已有交流和当前场合拿捏亲疏。不要为了显得温暖，

擅自假定读者的私人处境、内心需要，或替对方安排生活；私人关怀要有相应的交往基础。

1. 姿态。有没有在评价读者负责的东西？开口先给对方的产品打分（“你们这套框架是对的”），

而同一份文档后面还要向读者要资源，姿态就错了。改成描述，别下判词。

1. 读者读完要做什么。读者要拿去向上汇报，别留“你说了算”的口气；

读者要批钱，别把设计写成现状。

1. 读者解不解得开。你手上那套内部语汇，读者一个字都没有。逐词扫，每个专有名词问一句

“读者见过这个词吗”。四类常见：

• 内部编号与代号：阶段号、实验名、机器名。对你是名字，对读者是乱码
• 以“今天/上次/之前”为坐标的时间：读者不知道是哪天，更不知道之前是什么样
• 没有指代的“我们”：公开场合它不指任何人，读者无法判断是谁
• 只有你知道基准的比较：“另一套环境也一致”，谁建的、独立于什么，

读者无从判断这句话有多重 判据：每个专有名词，读者要么在自己的代码库里见过，要么我在同一段里定义过。 两者都不是就是泄漏。先问这个细节读者要不要，再问怎么说，多数时候答案是不要， 整条删掉句子反而更硬。换名字常常只是把乱码换成废话：读者本来不知道那个名字， 换完仍然不知道那个描述指的是哪一个，而这两样读者都不需要。 确实要留的，才换成读者能自己核对的描述：把内部编号换成那件事本身， 把“今天那个错”换成报错原文。 反过来同样成立：读者熟的东西不要展开。 给一个内行解释这个内行天天在用的概念， 既占了读者的时间，又等于说你不确定读者懂不懂。名字直接用，解释删掉。

这条容易漏，因为写的时候那些词对你是透明的，你不觉得它们是“词”， 它们就是事情本身。

读者是别人、且不止一句话的，这段字就走文件：文件里只放要发的内容，过一遍本 skill， 再把路径给他供他改；要发的那一版仍然整段贴进回复里，send-gate 的令牌只认回复里出现过的 文字。你的判断和理由照常写在回复里。一句话的回复直接写在回复里，单独成段，同样过本 skill。读者是他自己（分析、解释、给他的判断）才直接写在回复里。

读者是别人时，一条细节该不该留，看读者没有它能不能走到终点。 读者要照着做的东西 （版本号、报错原文、路径、参数、复现步骤）是内容，一条都不能省；让读者自己得出结论的 那些具体事实，同样是内容。该删的是为一个你已经写出来的结论再补的佐证， 和你一步步怎么得到它的过程。 同一份测量数据，issue 里少了它对方复现不出来， 批预算的消息里摆上它就是让人替你复核。

这类多余细节最常来自替对方预演追问：这个数对方会不会问、这句对方会不会驳， 于是每句挂一条佐证。删归删，留下的里面读者要照着做的那些，照「发之前」核。

他交代你怎么写，不是要发的内容。 他说“体现主动性”，那是给你的指令；草稿写成 "I wanted to be proactive, so I've been working out a couple of directions" 就把指令 原封搬了出去，收件人读到的是你在执行谁的要求。只说结果就够："I've been working out a couple of directions and want your read on them."

这种漏靠查抄发现不了，因为指令很少被原样搬过去，多半是换成你自己的话回来。 判据：这句话里有没有哪一层，只存在于他交代你的话里，事情本身没有？

文体：先定档位，写完对照。

• 这张表是例子不是分类法。 载体千奇百怪，表里三行盖不住；遇到没列的（宣传物料、

名录、网页简介、别人的幻灯片）就照读者和场合现判，别硬套最近的一行，同一种载体也能 两种写法，一张海报第一人称写得好的有的是。要定的是这一份给谁看、读者在什么场合读到。

• 判断的落点是这段字最后停在哪，不是你把它递出去的地方。 传递管道（聊天软件、邮件、

issue 回复）几乎总比落地载体口语，照管道定档就一路写散：一段要放进对外展示物的简介， 哪怕是在聊天软件里发给对接人，也按正式方案写。

• 标题也算文体。正式文体的标题是名词短语（“当前进展”），不是说话口气

（“先说我们手上现在有什么”“这块怎么做”）。一份文档的标题要么全是名词短语， 要么全不是，别混着来。

• 方向是“像真人写的正式文字”，不是“像真人说的话”。把正式文档改口语是另一种改坏，

和下面「最高优先」是同一条。常见翻车：为了去 AI 味，把“团队日常工作都在上面进行” 改成“天天在上面干活”。

最高优先：不要过度纠偏（硬约束）

去 AI 味不等于把文字改散、改口语、改水。这是最常见的反向翻车。

• 保留：好的正式语感、经过思考的判断、排比、诗意、克制的修辞。
• 只动：确认的句式痕迹和堆砌，做行级精修。不要从头重写已经认可的内容。

重写还是精修由 writing-reviewer 的命中数判定；没派它的时候默认精修，要重写得自己数到 阈值（阈值在它的 Verdict 一节）。

• 改完问一句：语气是不是被降级了？如果原来是“考究的书面体”，改完变成“随口聊天”，那是改坏了。
• 功能性格式不是 AI 味，别扫掉：论文/仓库/文档的超链接、行内代码、必要的章节引用是信息，真人恰恰会加。要扫的是装饰性格式（加粗轰炸、emoji 标题、PPT 式小节），不是让文字裸奔成纯文本。

「不是X而是Y」默认删，改成普通正面陈述。只有通过承重测试的留下，一篇最多 1–2 个， 零个是常态、也是合格。 承重测试：

• 把 X 那半句盖住，只留 Y。这段的意思缺不缺一块？缺 = 承重，留；不缺 = 装饰，删。
• 读者真有可能相信 X = 承重；X 是没人主张过的说法 = 稻草人，删。

改完还要问第二句：限定词还在吗？ 删改会顺手带走限定范围的那半句， 而改完之后每个字都是你自己挑的、读起来完全通顺，所以比事实错误更难发现。

• 「需要 X」→「只要 X 就行」（必要变充分）
• 「如果 Y 就做 X」→「只有 Y 才做 X」（触发变排他）
• 「大部分节点」→「节点」（范围没了）
• 「他建议」→「他要求」（言语行为变了）
• 「装了 X 才能跑」→「因为装了 X 所以能跑」（前提变因果）

命中就把限定词加回去，哪怕加回去读着笨。

元规则不推翻明令。 限定词回填和下面的「警惕更严谨」都只管新出现的判断；凡是本 skill 或 writing-reviewer 表上点名要删的（稻草人的 X 半句、段尾升华、换词表里的词、写他自己时 自我缩小的限定词）和点名要核的（「发之前」那些）已经判过，照删照做，别拿这两条把它们捞回来或绕开； reviewer 标为「可能命中」的除外，那一条要你自己判。

警惕每一次“变得更严谨”

防御每次换一个正面的名字出现，所以“我这是不是在防御”问不出答案：问的那一刻它已经改名了。

判据是要实例，不是要名字。 名字它随时能编，所以别问“你在防什么”，问这一份稿子里，这件事这次会发生吗。不是“这类事情发生过吗”，那永远有；是这一次、这个读者、这段字。答不上来就是防御，不管它当时叫什么：删。

写他自己的时候，不要预先让步

主语是他，或他参与过的工作时（CV、bio、申请、cover letter、项目简介、README、talk abstract），不要加缩小他贡献的限定词。这是他给对外写自己的东西定下的常规：不做防御性表述。

问经验、问做过什么的地方，用同等或更具体的内容去答。 I co-lead an RL training project 是拿身份答了一个问工作的问题，读者还得顺手去想另一个 lead 是谁。改法是直接说那件事本身：他建的是什么、训的是什么、修好了什么。改完只准更具体，不准更模糊，I work on X 比 I co-lead X 松，那是降级。

形状是同一个：没人要求，主张却比事实小。 补一条没人问过的信息，或者挑一个比实情窄的说法，都是这个。形态：

• 写出一个协作产物的规模，然后主动交代他本人只做了其中多小的一部分。动词已经是 co-developed 了，那个比例纯属白送。改法：说他做了什么，删掉比例。
• led one case study，而 led the case study 同样为真。one 悄悄暗示“众多之一”，定冠词什么都没让，也什么都不花。
• 挑一个比实情窄的说法自称：把「递归自我改进」缩成「其中在线的那一侧」，把整段工作缩成「我花时间最多的那部分」。窄的那个并不更准确，只是更小。别人对这件事的保留不是缩小的理由：合作者给自己文档标的 hype、内部还没定的命名、谁谁说过不够新颖，那是他们的判断，不是他的自述，搬进来等于替读者先打了个折。
• co-led X with <人名>。删的是 with <人名>，动词不动。判据是这个读者认不认得出那个名字：认得出，它是内容，写上；认不出，它只是一个解不开的专有名词，而这里的改法和「读者」第 5 条不同：那一条要你换成读者能核对的描述，这里换出来的 with a collaborator at another lab 只是把同一件事写长，直接删。体裁本身要求署名的场合（README 的贡献者、论文的致谢、共同作者名单）不适用这一条，那里的名字是署名规范。

这两遍扫描（扫词、扫人名）由 writing-reviewer 做；不派它的稿子（见「发之前」的不派清单）自己做。

这条和防御性堆砌是同一个错误的两种形态。 发送前的那份谨慎是关于要不要发的；让它渗进正文，一头是缩小自己的贡献，另一头是给一个常规请求配上数据和佐证，因为在替对方预演反驳。两头都回到「一条细节该不该留」那条判据。

逐句删完还要看整体：一件小事就用小事的分量说。 每句单看都必要，合起来仍然可以是错的分量： 一个常规请求配上背景、数据和时间线，就变成了一份需要审批的提案，而对方要做的只是点一下。 标尺不靠估摸长短，用他自己的先例：翻出他以前办成同一件事的那条消息，照那个形状写， 并在回复里说明照的是哪一条。一句话办成过的事，不写成一段。

开头和结尾

开头不清嗓子。 一句话独立成段/成句，作用只是宣布下一句要说什么、本身不载信息的，删： “先说这个平台是什么。”“这里要讲三件事。”“X 不是重点。重点是Y。”（等于英文的 "Here's the thing" / "Let me break this down"。）删掉这一句，后面那句几乎总是能独立站住， 站不住才说明它真载了信息。

最后一句几乎总要重写。 两种坏法：

• 总结式：把前文重说一遍，不推进任何东西。
• 悬空式：最后一句是个标签或半截计划（“第一批先跑通”），说了动作，没说结果，

也没说要对方做什么，读着像话没说完。

正式文档的最后一句只落在三处：请求（要对方做什么）、承诺（我们接下来给什么、 什么时候）、或者干脆没有结尾段：正文说完就停。

先查第三种。 如果诉求、时间安排这些已经各自成节，再加一段收尾就是纯重复， 连同它上面那条 --- 一起删。想写结尾段这个冲动本身就是“每段都收个漂亮尾巴”的 AI 本能。升华、展望、“这套模式还可以推广到…”一律删。

跑步机测试（写完自检）

逐段问“这段到底新增了什么？”，什么都没推进的删掉。随便交换两个正文段照样通顺， 说明这几段之间没有顺序关系：合并，或者重排出一个顺序。

中文标点（机械换一遍）

它在语义层之下，靠“写得用心”修不掉，只能定稿前机械扫一遍。任何一段会离开这个对话的 中文都算：发给别人的、落成文件的、进仓库的，包括在聊天软件里回别人的一句话。

换成哪个：,→， .→。 :→： ;→； ?→？ !→！ ...→……。 并列项之间是顿号 、 不是逗号；书名篇名用 《》，不用引号也不用斜体；外国人名分隔用 ·。 破折号不在这张表里，因为它根本不该出现：别把半角 -- 换成 —— 了事，删掉它，改用逗号、句号或冒号。

引号：中文用 “”，套引号里层才用 ‘’，别用 "，也别和 「」 混着来。 英文句子里仍然是 "；中英混排的文档两套各归各。

不动的地方：代码、路径、URL、参数名、数字（含 12:30）、整句英文引文。 括号看里面装什么：英文或代码就 (transformative use) 半角带空格，中文就 （见上一节） 全角。

落成文件的定稿前跑一遍，肉眼漏得比想象中多：

python3 ~/.claude/skills/writing-for-people/scripts/cjk-punct.py --fix <文件>

脚本只换 , ; : ? ! 和括号、引号这几对；句号、省略号、顿号、《》、· 它不碰，要肉眼过。 还没落成文件的（聊天回复、issue 评论）就自己对着上面逐条过，命中几处写进回复里那行扫描记录（见「发之前」）。

代笔人格（以他的身份写 comments/页边笔记/消息时）

写的不是“assistant 的话”，是这个人会说的话。

• 禁服务业结尾："say so" / "let me know" / "feel free to" / "flag me if" / "happy to" / “尽管说”。assistant 腔的第一标志。真人笔记要么直接问("do we want both in?")，要么陈述完就停。
• 页边笔记是钝的：改了什么、为什么、需要对方做什么，三件事说完就完。不铺垫、不客套、不总结。
• 语域（正式程度和用词）向低不向高：小写开头、缩写、省略主语都比“考究的完整句”更像真人笔记。

发之前

第一步，派 `writing-reviewer`。

给人读的字，在它落地之前（发出、提交、写进文档之前，不只是给他看之前）把草稿 全文交给 writing-reviewer subagent，连同你那行「读者=X，他拿去做Y，落地载体=Z，档位=W」 一起交，它的扫人名和加粗判断靠这行才知道读者和档位：评论、邮件、帖子、README、release note、 文档、给评审看的材料、公开仓库里的 PR 描述，以及任何 at 了某个人或整段写给某个 reviewer 的字 （一句话的除外，见下）。它手上有穷举用的东西：英文换词表、 英文套路清单、按形状认的、中英文 tell、字频上限、标点、写他自己时的扫词和扫人名。

它返回命中位置和改法，不改稿。判据类的不派给它：读者是谁、姿态、承重测试、限定词 有没有被删掉，那些要在写的时候就定，事后没人替得了。同一版草稿只派一次：它返回的改法 应用完就结束，应用改法产生的新字按「读者」第 5 条和它那几张表自查，不再回派；改稿累积成 新的一版才派新的一次（见「改稿」）。

没人细读的仓库记录不派：commit message（在哪个仓库都一样）、私有仓库里的 PR 描述、 没有 at 人的 issue 正文、只写版本号的 tag。私有与否查 gh api repos/<owner>/<name> --jq .private，不凭感觉；这条只看 .private，和 send-gate 的隐私审计（按谁能打开这个仓库算） 不是同一条判据。tag 正文里写了发布说明，就是给人读的，照派。 一句话的即时回复也不派，at 了人也不派：短不豁免检查，只豁免这一趟往返。 不派不等于不查。 不派的时候，那几张穷举表要自己过：它们都在 ~/.claude/skills/writing-for-people/writing-reviewer.agent.md 里，逐节过一遍再写。 扫完在回复里写一行：过了哪几张表、命中几处，零处也写；没有这一行，这一步就没做。

第二步，读者要照着做的，才核。

上面所有清单查的是怎么写。这一节查写的是不是真的，但只对一类细节较真：读者要拿去用的 那些。一句话读起来完全正常，里面的函数名、版本号、行号却是错的，对方照着复现不出来， 或者更糟，去查了一个不存在的东西。

要核的，判据是“读者会拿它照着做、换个值就会换个决定，或者它断言的是读者自己的东西”：

• 引用对方代码里的名字：函数、文件、配置项、行号。对方一搜就知道你有没有编
• 版本号、日期、提交号：尤其是“X 在 Y 之前发布”这种推理，整条结论压在两个日期上
• 读者要照着复现的数字：次数、耗时、参数。写“3/3 一致”就得真跑过三次
• 对方项目的行为描述：“你们这个检查不会捕获它”，说错就是当众指摘错了地方

给量级的数字不用核。 成绩、规模、比例这类点缀，读者拿它形成印象，不会拿它对第三位小数。 为了把一个点缀数字核精确而回源，是净赔：那个精度读者本来就不需要。点缀写成约数不是含糊，也不是造假，编一件没发生的事才是。

也只有这类细节，才需要在发之前再核一遍。 写的时候是先写后查，先落笔的那个版本会锚住你， 查证于是变成“确认我写的对不对”。 其余的，写完就是写完了。

真该核的那些，核完别把源头的措辞一起搬回来。 论文里的基线名、代码里的变量名、工单号， 在它们自己的文档里自明，搬到你这段字里是乱码；又因为刚查过、有出处，读起来是安全的， 自查扫不到。核完回写的那一句是新写的字，要重过「读者」第 5 条。

核了什么、该核而没核成的，回复里各一句，不写进正文；无可核项也说一句。 不该核的不用报，那些写完就是写完了。 正文是给收件人看的，在里面标一句“这个我没验证”，是把你的过程摊给了一个不相干的人。

改稿

改稿是另一个大漏。一份已经过检的文档，感觉是“过了”的状态，之后再改就不检查了。 但每一次 Edit 都是新写的字，而真实工作里绝大多数写作是改不是写。

两条硬规定：

• 过检状态不继承。改一处就重过那一处所在的句子；改动累积到三五处就是新的一版，整篇重过

一遍，reviewer 再派一次，扫描记录那行重写。

• 发现一处，扫全篇同类。对方指出的是实例，要修的是模式：称谓错一处 → 全文称谓

都看；标题口语一个 → 整套标题都看；一句改口语了 → 全篇语域都看。 逐处打补丁的代价是对方连着指出三四次同一类错误，每次都以为是新问题。