AMPLIFIER / J-SYSTEM16 SEP 2026
人类 × AI③｜写法篇：把台阶补回去的七条规矩
上一篇说了病：AI 写的东西句句都对，可句子之间断着，你得自己去补每两句的连接。这一篇说怎么治。
`ctx.message.text` 就是你这次敲的字，不含被引用的内容。Telegram 把被引用的消息放在另一个字段（`reply_to_message`）里，而网关只读了它的 `from.id` —— 只用来判断「这条是不是在回复机器人」，正文一个字都没取。
SEVEN 01 七条规矩 |
ONE THING 02 一段一事 |
DISTORT 03 比方会失真 |
我想先说清一件事，免得下面六条被当成文风建议。这不是让 AI 写得漂亮一点，是让它把一部分工作从你身上挪回自己身上。 连接关系这件事总得有人做。写的人不做，读的人就得做。
AMPLIFIER / 01
六条可以检查的规矩
这里得先自己交代一句，不然上一篇刚说过的话在这儿就自相矛盾了。上一篇讲工作记忆只挂得住三四样东西，说「要点一二三四五」并不清晰。而我这就摆出六条。
区别在于用途。下面这六条不是写来一遍读懂的，是写来事后逐条核对的——它属于清单，不属于文章。清单要的是能查、能勾，多几条不碍事；文章要的是能一口气读下去，那才受三四样的限制。这两种东西混着用，是很多规矩文件明明写得很全却没人真按着做的原因。
第一条，一段只讲一件事。
判据不是字数，是这个：读完这一段，你能不能用一句话说出它讲了什么。说不出来，通常不是因为它深，是因为它装了两件事。那就切开。
第二条，把连接词写出来。
因为、所以、也就是说、反过来看、更要紧的是。这些词不提供新事实，它们提供关系。省掉它们，你就把拼接的活转给了读者，而读者未必拼得跟你一样。
第三条，抽象之后必须跟一个具体。
说完一条道理，接一个例子、一个数字、一个比方。比例大概一比一。只给道理，读者点头但用不上；只给例子，读者记住故事忘了结论。
第四条，允许过渡句存在。
「先退一步」「这一点比上面那条更要紧」——这类句子不带信息，但它们交代方向，也让脑子喘口气。AI 会把它们当冗余删掉，因为在它的标准里不带信息就是浪费。那条标准得改。
第五条，强调只留最重要的一处。
加粗三十处等于没加粗。一段文字里如果每句都在喊，读者就不知道该看哪句，只好全都用力读——那比不加粗更累。
第六条，不要用符号代替句子。
箭头、星号、表格，都是把关系外包给排版。排版能表示「这两个东西有关系」，但表示不了「是什么关系」。表格适合放可以横向比较的数字；一旦你拿它放判断，它就只是把三句话摆整齐，关系还是断的。
AMPLIFIER / 02
一个真实的前后对照
空讲六条没用，我拿自己同一天写的两版当例子。内容完全一样，都是在解释「为什么你引用的那段话我看不到」。
第一版是这么写的：
每一句都准确，一个错字都没有。而读它的人只回了四个字：我没看懂。
第二版：
你在 Telegram 发一条消息，Telegram 其实把它装进两个格子：一个格子放你这次新打的字，另一个格子放你引用的那段原话。而我们的程序这些年只去开第一个格子，第二个格子它从来没碰过。所以你引用了一大段，我这边收到的只有你新打的那几个字。
这一版一遍就通了，而且读完当场就做出了决定：去把那段代码改掉。
差别在哪？第一版给的是字段名，第二版给的是一个能在脑子里看见的画面。第一版每句之间没有连接词，第二版用「而」「所以」把三步串成一条线。第一版对一个程序员是最短路径，对一个不写代码的人是一堵墙。
值得注意的是，第二版并没有更短——它比第一版还长了一点。易读和简短是两件事，而我之前一直把它们当成一件。
AMPLIFIER / 03
写完之后只自检一个数
你自己重读一遍，数眼睛往上飘了几次。
零次，说明关系都交代清楚了。三五次，说明有几处台阶被拆了，回去补。十次以上，别改了，重写。
这个数好用，是因为它量的是读者的负担，而不是写者的完整度。完整度能被检查，所以它永远会赢；读者的负担没人检查，所以它永远被牺牲。给它一个数，它才进得了验收。
AMPLIFIER / 04
但这套方法有代价，不说清楚就会被滥用
代价一：文字会变长，密度会被稀释。
台阶是要占地方的。对一个已经懂的读者，这些台阶就是噪音——他要的是密度，你给他铺路，他只会觉得啰嗦。所以这六条不是普适规则，它是一个关于「写给谁」的选择。写给同行看的技术规格，密度优先；写给一个注意力有限、要据此做判断的人，台阶是必需的。
顺着这条往下，有两种场合明确不该用它：
一种是写给机器或程序员的精确规格。那里字段名比比方准确，术语就是最短路径。
另一种是落盘的规则文件和验收清单。那些东西是拿来查的，不是拿来读的——要能被搜索、能逐条核对，写成散文反而更难用。
代价二，而且这一条更危险：把「易读」当成可以不准确的许可。
打比方一定会失真。而一个失真的比方比一句听不懂的术语更坏，因为读者以为自己懂了，然后带着一个错的图像往下走。
我自己刚犯过。前几天我给一个不写代码的人解释 Telegram 的引用功能，说「Telegram 把你的消息装进两个格子，程序只开了第一个」。他一下就懂了，还当场拍了改代码的决定——从沟通上说这个比方是成功的。
但它不准确。真实的结构不是并列的两个格子，是一个消息对象里套着另一个消息对象。我那个比方为了好懂，把嵌套改成了并列。这次没出事，因为下一步动作不依赖那个区别。可如果哪天有人要据此判断别的事，那个错的图像就会开始害人。
所以第七条，也是压住前六条的一条：比方之后要标一句它在哪儿失真。
一句就够——「实际结构比这个复杂，这里只取它像的那一面」。这句话看起来是在给自己留退路，其实它是在给读者留一个把手：将来他要往深走，知道该从哪儿撬。