@tw93/waza 3.25.0

package/skills/write/references/write-zh.md

@@ -0,0 +1,645 @@
+## 中文场景
+
+像资深工程师写技术长文，给同行讲清楚一条链路。自然、准确、不刻意。
+
+### 执行流程（先后顺序）
+
+按下面顺序改，不要反着来：
+
+1. 先保语义：先确认事实、逻辑、因果都不变。
+2. 再去 AI 味：删模板句、删讲解腔、删报告腔。**首先检查段末收尾总结句**（"这说明"、"到这里"、"可以看出"开头的重述句），这是最高频的 AI 痕迹，优先删。
+3. 再顺句子：解决拗口、断句过碎、节奏太硬。
+4. 最后调标点：减少不必要的括号、引号和短句句号连发。
+5. 术语只在必要处解释：首次出现可注解，后文不重复堆注释。
+6. 全文回读一次：优先改卡顿点，不为“更口语”硬改自然句。
+
+### 最高优先级：自然 > 风格化
+
+不要为了”像人说话”硬塞口语词、情绪词、俚语、感叹词。
+一句话如果已经自然、清楚、稳，就不要再往里加”其实 / 说白了 / 哈哈 / 谁能想到 / 我去 / 居然 / 太太太”这类词。
+
+**保留作者已用的口语词**：如果作者原文已经在用”很”、”其实”、”到底”这类自然词，不要替换成正式词。”最高优先级”是不要主动添加，不是要替换掉已有的。过度去口语化和过度口语化一样糟糕。
+
+### 默认模式：技术长文
+
+目标不是”更随便”，而是”更自然、更稳”。读起来像人写的，不是像报告，也不是像刻意模仿语音转文字。
+技术文默认是工程师对工程师，不是老师训人。少用命令式句子、审问式起手和居高临下语气。
+
+- 可以口语，但不要俚语化
+- 减少情绪词、感叹词、口头禅
+- 少用”说白了 / 其实 / 你会发现 / 谁能想到”这类推进词
+- 优先追求：清楚、稳、具体、节奏自然
+- 不要为了去 AI 味，把技术文改得像口播稿
+- 如果原句已经自然、准确、清楚，不要为了”更像人”继续改
+- 优先做减法：删解释腔、删总结腔、删多余转折，不要把润色做成重写
+
+**受众非工程师时的调整**：如果文章定位是产品 / 业务 / 运营受众，先去三类词：俯视词（"不懂技术的同学"）、命令腔（"你必须 / 一定要"）、过深术语（"原语 / 未命中 / 非工程团队"）。prose 走"我怎么用，你跟着试"路径，不要"系统梳理 + 框架表格 + 长段分析"。
+
+### 开头直接
+
+NO: 随着...的发展
+OK: 用了不到一个月后
+OK: 作为长期用户，我更关心...
+OK: 这次想把 X 这条链路讲清楚
+OK: 先说结论，再展开过程
+
+### 用词去正式化
+
+| NO: 不用 | OK: 用 |
+|---------|------|
+| 非常 / 极其 | 很 |
+| 值得注意的是 | 直接说结论 |
+| 综上所述 | 直接收尾 |
+| 例如 | 比如 |
+| 购买 | 买 |
+| 使用 | 用 |
+| 很多同学 / 不少同学 | 很多人 / 不少人 |
+| 这几个事 | 这几件事 |
+
+### 口语词慎用，不要靠它们制造“人味”
+
+下面这些词不是禁用，但默认不要主动加进去：
+
+- 太太太
+- 居然
+- 谁能想到
+- 于是乎
+- 我去
+- 哈哈
+
+`好比` 只在比喻真的有帮助时偶尔用一次，不要当成固定连接词。
+
+### 生动化：只在原句读不懂时才换
+
+默认不改。只有原句抽象到读者看不懂意思时，才换成更具体的表达。已经清楚的句子不要为”更形象”硬改。
+
+| NO: 过度形象化 | OK: 保持原句或微调 |
+|---------|--------|
+| 都在偷你的上下文空间 | 都是上下文成本（原句已经清楚） |
+| 绝对不能干的事 | 禁止事项（技术文不需要这种语气） |
+| 说白了，[结论] | 直接写结论，不加口语引导 |
+| X 就是”你怎么知道做对了”这个问题的答案 | 从问题或场景出发描述 X |
+| 这就是 X 的力量 | 删掉，让事实说话 |
+
+### 句式
+
+- 不用"首先...其次...最后"，用"一方面...另一方面..."
+- 段落可以长，但要一口气能读完
+- 不用强行断句
+- 禁止用破折号（双横线），用逗号或分号代替
+- 单独成段的一两句话，多半是上一段的收尾或下一段的引子，直接并进去，别让它孤零零
+- 四五个句号连发、每句都很短，读起来像在打电报，这时候把几句合成一个长句，或者用逗号连起来
+- 少用“先问问是不是 X”“你得先明白”这类起手，容易有训人感，改成“可以先看 X”“先确认 X”
+- 分析型技术文里，少用“第一、第二、第三”模板，除非在写操作步骤
+- 三个承重点如果关系很紧，优先写成一段自然段，不必强行拆成列表
+
+### bold 起手 + 句号 节奏
+
+`**xxx**。content` 这种「小标题 + 句号 + 解释」起手段落是 AI 模板感的高频源，**不论密度，默认换成 `**xxx**，content`**，让 bold 变成句子的承重词，而不是独立小标题。整段读起来是 prose，不是工整 bold 列表。
+
+```
+NO: **alias**。我在 .zshrc 里加了一行...
+OK: **alias**，我在 .zshrc 里加了一行...
+```
+
+例外：`**xxx**` 本身就是一个完整句子（如「**能跑不代表安全**」、「**准不准才重要**」），后面跟句号是正常句子结束，不属于"小标题"模式，保留。
+
+判断信号：bold 部分单独看是不是一个能独立成立的句子。是 → 句号；不是（只是个标签 / 短语 / 名词）→ 逗号。
+
+### 列表去 list 化的渐进策略
+
+技术长文里 bullet 列表过多会显得像 PPT。从 list 走到 prose 的渐进路径：
+
+1. 序号列表 1/2/3 → 改 bullets `- xxx`（去掉序号感）
+2. bullets `- **xxx**：content` → 改 bold 段落 `**xxx**，content`（去掉 list marker）
+3. 4+ 个 bold 段落 → 合成一个 prose 段落，每项用分号串起来（去掉 visual 切片感）
+
+中间停在哪一步都行，不必一步到底。判断信号：
+
+- 每条都有大段独立解释 → 适合 bold 段落
+- 每条 1 句话，关系紧密 → 适合 inline prose 串起来
+- 每条是平行规则、读者要扫一眼对照 → 保留 bullets 也行
+- 章节标题已经把列表的总结写出来了 → 内容部分尽量 prose 化
+
+序号 1/2/3 留给真正有顺序的：优先级、时间、流程步骤、reference 排序。
+
+### 标题设计
+
+标题格式三种，看结构选，不是统一用一种。
+
+**冒号格式**（主题：补充说明）适合：术语首次出现需要解释（ACI：工具是给 Agent 的交互界面）、主题加原则性结论（安全沙箱：边界比功能重要）。
+
+**一句话格式**适合：副标题只是弱标注、没什么信息量；两部分读起来断裂感强；副标题和主标题意思重复。
+
+NO: 幻觉放大：多 Agent 特有的坑（"特有的坑"是弱标注，删掉信息量不变）
+OK: 多 Agent 下幻觉会互相放大
+
+NO: 长程任务：跨上下文的工程问题（"跨上下文"和"长程任务"意思重复）
+OK: 长程任务的跨上下文挑战
+
+**标题里保留逗号**：先...再...顺序句（先修复评测，再修复 Agent）；对仗枚举（同步决策，异步 I/O）。
+
+**标题里逗号改冒号**："主题，副标题说明"这种格式，逗号换冒号更清晰（Prompt Caching，降低重复调用成本 → Prompt Caching：降低重复调用成本）。
+
+**标题里去冗余词**：「应该如何X」去掉「应该」，直接用「如何X」；副标题如果和主标题意思重叠，合并成一句。
+NO: 「Agent 评测应该如何做」 / 「工程实现应该遵循什么顺序」
+OK: 「Agent 评测如何做」 / 「工程实现遵循什么顺序」
+
+**标题不要做成名词并列**: 三个名词用顿号串起来，没有观点，读者不知道这节想说什么
+NO: 「蒸馏、专用化与持续迭代」 / 「数据、算法与系统」
+OK: 用一句有判断的陈述：「前沿模型发布后，训练链路还在继续跑」
+判断标准：标题能不能单独成立为一个有意义的句子，能就留，不能就改
+
+**标题要有判断，不只是名词**：好标题表明立场或结论，不只是列出主题词。
+NO: 「多 Agent 协作」（只说了主题）
+OK: 「多 Agent 协作让幻觉互相放大」（有判断）
+OK: 「评测先于 Agent，不然你不知道在修什么」（有立场）
+
+### 引号（""）
+
+引号不是强调键。不要因为某个词"感觉重要"就套上引号。
+同理，`「」` 也不要拿来做视觉强调。
+
+NO: 大模型最擅长"翻译"
+NO: 防止 Agent 通过改标准来"提升"分数
+NO: Agent 扫了一眼，觉得"差不多了"
+
+OK: 大模型最擅长按规格说明书做对照实现
+OK: 防止 Agent 通过改标准来刷分
+OK: Agent 扫了一眼觉得差不多，直接宣告完成
+
+引号只用于：直接引述他人说的话、系统输出内容、错误消息。
+
+### 括号（）
+
+括号里的内容超过 10 个字，多半说明它该待在正文里，而不是括号里。
+同一段里出现 2 处以上括号时，优先把至少 1 处改写进正文，避免读感变重。
+
+NO: 传统 APM（Datadog、New Relic 这类监控延迟和错误率的工具）基本帮不上忙
+OK: 这类只监控延迟和错误率的传统 APM 基本帮不上忙
+
+NO: 并发的正确用法不是多模型推理，需要并发的是（文件操作、网络请求、长耗时命令）
+OK: 需要并发的是文件操作、网络请求、长耗时命令，模型推理本身保持单线程
+
+可以保留括号的情况：术语首次出现的英文原词、简短数值范围（5~15%）、代码参数说明。
+
+### 分号（；）
+
+分号不是懒人句号。两个放在一起就是因为"感觉有关系"的句子，多半应该直接用句号断开。
+
+NO: File System State 开销只有 5~15%，几乎总是值得的；Verifier Agent 能提升 25~40% 精度，但成本增加 1.5~3 倍
+OK: File System State 开销只有 5~15%，几乎总是值得的。Verifier Agent 能提升 25~40% 精度，但成本增加 1.5~3 倍
+
+可以保留分号的情况：
+- 对仗句：只跑 Layer 2，评分标准会漂移；只靠 Layer 1，根本看不过来
+- 列表项分隔：本地 Shell 能处理的；只需静态知识的；还没验证过的
+- 中文枚举：一是…；二是…
+
+分号后面接转折词是典型错误，直接断句：
+> NO: `...也决定后训练有没有可以利用的空间；但它没有决定这个模型会不会听指令`
+> OK: `...也决定后训练有没有可以利用的空间。但它不决定模型会不会听指令`
+
+### AI 味检测：这几个模式要主动排查
+
+以下是高频出现的具体模式（举例，不完全）。读起来有同样 AI 味的句式一律适用。
+
+**1. 升华句**: 把具体工程观察上升到普适人生道理
+> NO: "很多东西都是这样，当初成立的假设，过一段时间回头看可能已经不成立了。"
+> OK: 直接给出具体建议，不升华
+
+**2. 对比句式**: AI 最爱的结构，出现频率高就有问题
+> NO: "不是…而是…" / "直觉上…但实际上…" / "X 本身没有价值，真正有用的是 Y"
+> NO: "X 已经不是瓶颈，Y 才是" / "X 不重要，Y 才真正...": "才是/才真正"变体同样是对比框架
+> OK: 直接说结论，不用对比框架铺垫。"代码生成不卡人了，真正费力气的是评审"比"代码生成不再是瓶颈，评审才是"自然得多
+
+**3. 重复核心观点**: 同一个道理在不同节出现 2-3 次
+> NO: 第 0 节说了，第 2 节总结处再说一遍，结语再升华一遍
+> OK: 说一次，后面直接引用或跳过
+
+**3b. 段内重复**: 同一段里把同一个意思用不同措辞说两遍
+> NO: "没有约束边界的 Agent 不是更自由，而是更容易在错误路径上跑很远都没人察觉。加约束，是给它一个出了错还能拉回来的余地，没有约束的 Agent 跑偏了都没人察觉。"（后半句和前半句说的是同一件事）
+> OK: 说一遍，够了。不需要用换一种说法再强调一遍
+
+**4. 引用+解释句式**: 先抛英文术语/名言，再解释
+> NO: "工程界有句话 'X'，对 Y 同样如此，..."
+> OK: 直接用破折号或口语解释：他们把这个叫 progressive disclosure，就是不要一下全给
+
+**5. 工整并列总结**: 每节结尾必有一句"三层缺一不可"型总结
+> NO: "三层缺一不可，只靠 A 没用，只靠 B 不够，单独拿出来都有漏洞。"
+> OK: 口语化：用下来感觉，少任何一层都会出问题
+
+**6. 瓶颈转移句**: 一眼 AI 博客
+> NO: "瓶颈从'X'转移到了'Y'"
+> OK: 直接说新情况：代码生成不卡人了，压力全压到评审这一侧，不用"瓶颈"这个词
+
+**7. 优先级结论句**: 听起来像教条
+> NO: "安全边界要比任何功能都先做好" / "是生产级别必须的"
+> OK: 说清楚为什么：能跑 shell 就能删库，安全得先来
+
+**8. 系统性定义开头**: 教科书格式
+> NO: "X 是对 Y 的系统性评估，包括测试用例、评分标准和自动化验证流水线。"
+> OK: 从问题或场景出发，不从定义出发
+
+**9. 完美并列 bold 标题**: 一组"有X，让Y而不是Z"结构
+> NO: 四个 bold 标题全是"**有明确的参照物，让 Agent 翻译而不是创造**"这种格式
+> OK: 每个点语气不同，或直接改成散文叙述
+
+**10. 顺序/重要性结论**: AI 喜欢用"所以"收尾说教
+> NO: "所以顺序很重要：评估工具可信，测量结果才有意义。"
+> OK: 直接说怎么做："怀疑 Agent 出了问题，先确认 Eval 没问题。"
+
+**11. 混杂段落**: 一段塞了多个不相关话题
+> NO: 一段里同时讲可观测性顺序、File System State 成本、Verifier Agent 精度、多 Agent 引入时机
+> OK: 每段只说一件事，其余拆到各自对应位置，没有对应位置的直接删掉
+
+**12. 章节引介过渡句**: 章节结尾或开头写一句引出/承接下一节的桥接句
+> NO: 「上面这些模式解决的是控制流怎么搭，下面再看另一个更工程的问题，系统为什么能跑稳。」
+> NO: 「X 保证了方向对了，执行完还得确认它真的做对了。」← "X 做完了，还有 Y"的机械衔接，只在宣告结构，没有信息量
+> OK: 直接删掉，章节标题本身已经承接
+
+**例外：这几类章节引导是必要的，不要删：**
+
+- **内容说明**：告诉读者这节为什么值得看，有实质信息量
+  > OK: 「这块很少有教程展开讲，但它很影响成本结构和设计取舍。」
+
+- **模式切换信号**：长文里从原则转向案例、从理论转向实操，读者需要知道内容性质变了
+  > OK: 「前面几节讲的是原则，这一节直接看 OpenClaw 怎么落地。」
+
+- **行动指引**：结尾给读者一个具体的下一步，不是在说文章做了什么
+  > OK: 「想知道自己的配置离这些原则差多远，跑一次 /health 是最快的方式。」
+
+判断标准：句子里有没有对读者有用的信息，有就留，只在宣告文章结构就删。
+
+**13. 收尾"给你答疑/给你答案"**: 文末或节末用「应该能给你答疑」收尾
+> NO: 「下面文章应该能给你这些问题答疑。」
+> OK: 省略，或改成：「读完这篇，这几个问题应该能有些答案。」
+
+**例外：图后说明段落不能以"重复"为由删除**
+图片的 alt text 读者看不到，图后的文字说明才是读者真正看到的解释。图后说明段不属于"收尾总结"，不要删。
+判断标准：如果删掉这段文字，读者就看不懂这张图，就必须保留。
+
+**14. 段末收尾总结句**: 一段刚解释完某个机制，结尾再加一句把刚才的意思重述一遍
+> NO: "这不只是设计选项，是资源约束的结果": 紧接在已经解释了具体代价之后
+> NO: "模型本身成了训练流水线里的工具": 刚解释完模型在给下一代产出训练数据
+> NO: "主流实验室基本都在用这类多阶段配方了": 四个阶段刚刚描述完
+> OK: 说完就停，事实本身已经说明一切，不需要再"总结"一遍
+> 识别信号：这类句子往往以"到这里"、"这说明"、"这本身就是"、"也就是说"、"可以看出"开头，或者是段落最后一句比其他句短且抽象
+
+**15. 英文术语首次出现后，后续一律用中文**
+- 首次出现：保留英文 + 中文注解，或中文前置 + 英文括注（`指令微调（Instruction tuning）`）
+- 后续出现：只用中文，不要英文/中文混用
+> NO: 第一次"冷启动 SFT（cold start）"，第五次还在写"cold start 让 RL 稳定启动"
+> OK: 第一次解释清楚，后面一律写"冷启动"
+- 例外：SFT、RL、MoE 这类已成行业通用缩写，可以全程保留缩写形式
+
+**16. 思考过程用了物理动作动词（翻译腔套路一）**
+
+接住、击穿、锋利、不崩、不爆、打穿、扛住、收紧、落地、推开、撑不住，这类词把抽象认知过程想象成了物理动作，骨架是英文（catch / pierce / sharp / break / blow up）。
+
+> NO: 「你这几条我都接住了。」「这个论证被击穿了。」「更锋利的重构：」
+> OK: 「你这几条我都收到了。」「这个假设不成立。」「换一种更准的讲法：」
+
+自检方式：写完一段，把所有动词圈出来，凡是中文日常不会这样用的，挨个换掉。
+
+**17. 形容词预判+冒号引出内容（翻译腔套路二）**
+
+「更干净：」「逻辑很清晰：」「问题很直接：」「结论很明确：」，形容词抢先下判断，冒号才引出事实。
+问题有三：抢走了读者自己评估的机会；形容词几乎总是多余的；后面的事实本身就能让读者得出那个感受。
+
+> NO: 「验证得比我预期的更干净：上下文不崩、成本不爆、状态可恢复。」
+> OK: 「数据把你的感觉证出来了：上下文不乱、成本压得住、状态能恢复。」
+
+改法：直接把形容词那一节删掉，只留后半句事实。如果非常想保留那个形容词，多半说明后面内容没讲清楚，要回头补内容。
+
+**18. 抽象名词做主语，形容词当结论（翻译腔套路三）**
+
+"X 的 Y 比 Z 更 W"这种骨架，主语是抽象名词（工程上的现实、这份数据、生态的成熟度），结论是形容词（难看、直接、漫长），中间系动词连接。读完不知道到底哪儿难看、难看在哪个环节。
+
+> NO: 「工程上的现实比这些数字难看。」
+> OK: 「这些数字只反映了采用面；真往下看各家怎么接，早就对不齐了。」
+
+改法：让人、动作、或具体对象做主语，让事实自己说话。凡是碰到"X 的 Y 比 Z 更 W"骨架，都应该重写。
+
+**19. 有稳定中文对译的英文词直接混入（翻译腔套路四）**
+
+context、state、cache、claim 这类词有现成中文对译：上下文、状态、缓存、断言。留着英文原词让读者每次切换都消耗注意力。
+
+> NO: 「context 不崩、成本不爆、state 可恢复、cache 命中率高。」
+> OK: 「上下文不会乱、成本压得住、状态能恢复、缓存命中得上。」
+
+判断标准：中文技术圈已有通用译法，就换中文；术语在中文圈还未收敛（如 prompt、embedding、tokenizer），保留英文合理。
+例外：SFT、RL、MoE 这类已成行业通用缩写，全程保留缩写形式。
+常见可替换词：context→上下文、state→状态、cache→缓存、claim→断言、runtime→运行时、contract→契约。
+
+**20. 对称粗体起句**: `**词语**。……` 连续出现 3 行以上即触发 AI 模板感。把第 4 个改成行内嵌入式粗体（`句子里加 **重点**`），打破节奏。
+
+**21. 挑战与未来展望模板段**: "尽管面临挑战，X 凭借 Y 仍将持续蓬勃发展，成为 Z 不可或缺的一部分。" 是 AI 最爱的收尾套路。
+> NO: "尽管面临挑战，X 凭借 Y 仍将持续蓬勃发展，成为 Z 不可或缺的一部分。"
+> OK: 直接说具体的挑战和具体的应对，不要"尽管…仍…"+"未来展望"的套路收尾。
+
+**22. 同义词循环**: 同一段里把同一对象用 3 种以上同义词替换，是 AI 重复惩罚机制的副产物。
+> NO: "主人公面临挑战。主角必须克服困难。中心人物最终获胜。英雄回到家中。"
+> OK: 选一个称呼用到底。"主人公面临挑战，最终获胜回到家中。"
+
+**23. 虚假范围**: "从 X 到 Y" 结构里 X 和 Y 不在同一尺度上，假装覆盖全光谱。
+> NO: "从大爆炸的奇点到暗物质的神秘舞蹈"（不是同一类对象）
+> NO: "从架构设计到团队文化"（跨域强凑）
+> OK: 直接列出真正涵盖的两三件具体事，或者只挑一件展开。
+
+**24. 知识截止日期免责声明残留**: AI 关于"截至 X 时间 / 根据可用信息 / 现成资料中没有广泛记录"的免责声明被原样粘贴到正文。
+> NO: "虽然关于公司成立的具体细节在现成资料中没有广泛记录，但它似乎是在 90 年代的某个时候成立的。"
+> OK: 要么查清楚直接写"成立于 1994 年"，要么不要写这一句。模糊免责声明本身就是 AI 痕迹，要删干净。
+> 注: 与「时效性事实加边界词」不同，那条是作者主动加边界（"截至 2026-04 我看到的是…"）；这条是 AI 自动生成的甩锅式免责。
+
+**因果/结论语气要像归纳，不像定论**
+技术文章里，判断方向没问题，但懂行读者看到”换来的是/就是从这里来的/是X的路径”这种语气，容易挑刺。改成归纳语气：
+
+> NO: “换来的是同等参数下更高的能力密度” / “性能差距就是从这里来的” / “也是能力解耦的路径”
+> OK: “公开结果显示，这类配方通常能换来更高的能力密度” / “从公开结果来看，差距通常是可观测的” / “一个关键原因是能力解耦”
+
+**术语列表需要”为什么值得记”的锚**
+一段里列出多个专有名词（muP、WSD lr、batch size 等）而不解释为什么读者该记住，更像点名单不像论证。加一句：
+
+> NO: “这些都开始出现在正式训练报告里。能看出来的一条线是，配方越来越细。”（只说存在）
+> OK: “这些细节之所以值得记，是因为它们正在成为同规模模型之间拉开差距的地方。”（说明为什么重要）
+
+**长段落拆分标准**
+一段超过 400 字、或塞了 3 个以上独立概念，移动端读起来会累，也容易冲淡最重要的那一句。拆分点：概念切换处加空行，不要因为”都属于同一主题”就塞在一起。
+
+**案例引入需要半句”为什么选它”**
+直接 zoom in 到具体案例（PARL、DeepSeek-V3 等）时，如果切换感突然，先加半句说明它代表哪条路线或设计选择，再展开细节。
+
+> NO: “Kimi K2.5 的 PARL 是这里最值得拆开的工程案例。它只训练 orchestrator...”（直接进细节）
+> OK: “Kimi K2.5 的 PARL 代表了一条新路线：只训 orchestrator、把 credit assignment 收到编排层。奖励信号分三类...”（先说代表什么）
+
+### 今日沉淀：工程技术文实战规则
+
+下面这组来自真实改稿回合，优先级高于”风格偏好”：
+
+- 删段之前先确认信息量。删除整段（不是单句）之前，确认这段没有在别处重复的技术事实、数据或逻辑。”删掉段末总结句”的规则针对结构性重复，不适用于展开新信息的段落。如果不确定，改成提议而不是直接删。
+- 先保语义，再去 AI 味。为了”更口语”改坏原意，属于失败改写
+- 括号和引号默认少用，但术语首次出现、歧义消解时要保留，不要为删符号牺牲清晰度
+- 句号密度要控。连续短句太多会像汇报提纲，适当合并成复句
+- 避免“训人式”表达：反问、命令、质问式开头都容易让读者产生被指导感
+- 避免抽象判词堆叠，优先写可观察事实、链路位置和具体影响
+- 结论不重复宣告。第 0 节说过的核心判断，后文不要再换措辞重复一遍
+- 保留作者的内在矛盾。如果原文在不同段落持有看似矛盾的立场（比如既推崇自由又强调纪律），不要替作者消解。时间性矛盾（早期 vs 近期观点）标注演化即可；领域性矛盾（工作 vs 生活的不同规则）保留两面；本质性张力（价值观的内在冲突）原样呈现，这通常是文章最有深度的部分
+
+### Summary 写法（新增）
+
+`summary` 先判断目标，不同目标写法不同：
+
+- 导读型：告诉读者“这篇会讲什么”，不提前讲完整结论
+- 总结型：概括“这篇讲了什么 + 得出什么结论”
+
+实操规则：
+
+- 导读型用“这篇会从 A 讲到 B，重点看 C”
+- 总结型用“这篇从 A 到 B，最后看到 C”
+- 不要混写，避免一段里既像导读又像结论宣判
+- 默认 2 到 3 句，信息完整但不铺满正文细节
+
+### 报告腔专项（新增）
+
+下面是最近高频替换，按“左边少用，右边推荐”执行：
+
+- `主要叙事` -> `大家通常用...来解释...`
+- `系统梳理` -> `从...一路讲到...`
+- `核心结论是` -> `最后会看到`
+- `逻辑分工 / 流程节点` -> `为了看分工 / 更细的版本`
+- `公开口径里` -> `按公开数据`
+- `共同模式已经很稳定` -> `能看到几个共同点`
+- `可以从三个角度看` -> `可以先看三件事`
+- `不需要读成 X` -> `不只是 X`
+
+补充：
+
+- 比较表达优先自然中文：`最清晰` 通常比 `最清楚` 更稳
+- 避免“句子评价句”，例如“这句话解释不了”，直接写对象本身“X 解释不了 Y”
+
+### 参考资料排列
+
+- 默认用单列表，不强制按“论文/博客/仓库”分类
+- 排序按承重程度，不按发表时间
+- 论文和官方技术报告优先，仓库与博客只保留高承重项
+- 数量以可读为先，通常 10 到 14 条比较稳
+
+### 最近确认的不喜欢的表达（新增）
+
+- 少用过重口语：`别掉链子`、`露过头`
+- 少用抽象主语：`团队`、`实验室`、`行业`；如果能直接写动作，就别先摆一个抽象主体
+- 少用讲解腔起手：`真拆开看`、`这背后是同一个变化`、`真正的问题变成了`、`真正关键的问题是`、`都在说明同一件事`
+- 少用训人感起手：`先问问是不是`、`你要先明白`、`先搞清楚再说`
+- 少用工程黑话式表达：`硬约束`
+- 少用半口语半讲稿的词：`摆出来`
+- 少用让步腔：`当然`（"预训练当然还是底座" → "预训练是底座"）、`这话不算错，但`、`这么理解不能说错，但`: 直接说结论，不要先让步再转折
+- 少用学术塑造感词：`塑形`、`塑造`（行为/方向/结果） → 用`调整`、`决定`、`影响`、`优化`
+- 少用空间位置词描述逻辑关系：`相邻` → 用`关系紧密`、`有交集`等说清楚实际关系
+- 少用空泛目标词：`聚焦`，直接写“重点写什么”“主要看什么”
+
+### 文章自说明句（默认少写）
+
+文章不该反复谈自己在做什么。默认直接进内容，必要时只保留 1 句路线提示。
+
+NO: `先给最短结论，就四句：`
+NO: `这篇真正想钉住的，就是这件事：`
+NO: `如果先只记一张表，可以先记住这六层：`
+NO: `脑子里还是那老三样：X、Y、Z`（代替读者做归纳）
+NO: `最常见的解释就是三件事：`（同上）
+NO: `拿一组具体数字看会更直观。`（宣告数据要来了）
+NO: `如果说...那...`（条件句引入段落）
+NO: `这篇文章接下来会从 X 讲到 Y。`（同上）
+
+OK: 直接进结论、进数字、进内容。结构交给标题和逻辑顺序，不要靠过渡句反复宣告。
+OK: 如果确实需要路线提示，只写一遍，避免在开头和结尾重复。
+
+### 术语注解不要扎堆
+
+多个术语同时首次出现时，括号注解会堆在一起，读起来很重。处理方式：
+
+- 把注解融入行文：`GRPO（组相对策略优化），而不是传统 PPO（近端策略优化）` → `这里的关键选择是 GRPO 而不是传统的 PPO`，注解分散到后文
+- 把首次介绍提前：在自然引出术语的地方加注，而不是在密集使用的地方一次性堆上去
+- 如果上下文已经说清楚了意思，括号注解可以完全省略
+
+### 图片引导语
+
+图片前的说明句不用「下图」，用「这张图」或「下面这张图」，避免每句都一样。
+
+### 图片节奏
+
+带图技术长文里，图片放哪儿决定整段读起来顺不顺。三条经验：
+
+**图当 TL;DR，列表/表格当详情**。图片放在「intro 一句话 + 图 + 列表」这个位置最舒服。把图丢在列表/表格末尾、紧贴下一个 `---` 的位置看着空，上面是序号 + 加粗也很丑。
+
+**图片 alt 要和正文 prose 对齐**。如果 alt 列了 6 项保号清单、prose 改成 5 项，要么改 alt、要么重画图，不能让两者错位。读者扫到的是图视觉 + 正文文字，alt 给搜索引擎和无障碍。
+
+**段末"为了平衡而加图"是 AI 模板**。图不是装饰节奏的工具。如果某段没自然想到画什么，就别凑图，文字密就让它密。
+
+### 技术文章额外规则
+
+**事实与可验证性优先于去 AI 味**
+技术文章先保准确、清楚、可验证，再追求自然。不要为了删 AI 味，把版本、环境、依赖、出处、复现条件、风险边界删掉。如果原文缺这些信息，不要编，可以保留问题或收敛语气。
+
+- 版本、平台、依赖会影响结论时，要保留或补全对应上下文
+- 引用“官方建议”“文档说明”“测试表明”时，要有具体出处；没有出处就不要写成定论
+- 命令、配置、代码不要只贴结果，要解释关键参数、关键路径和为什么这么改
+- 性能、安全、稳定性结论要说明观察口径，比如数据来源、测试环境、样本范围
+- 个人经验、单次排障、局部实验不能写成通用规律
+- 写方案时顺手补一句边界：什么时候适用，什么时候别这么用
+
+**时效性事实加边界词**
+价格、订阅档位、版本号、产品名、隐藏命令、发布时间这类容易过时的事实，加边界词写：「截至 2026-04」、「我这里看到的是」、「以当时显示为准」、「目前」。读者过两个月对着失效信息照搬时，能立刻看到这是哪一时刻的截图。
+
+**专有名词改前 verify**
+字体名（沧耳 / 仓耳 / 苍耳）、品牌名、书名、人名、产品名改之前先 grep 或查官网，不凭印象。事实类改动比风格类改动风险高，反而最容易拍脑袋下手。
+
+**开头不要放背景铺垫段落在最前**，比如"国内现在也有不少打着 X 旗号的产品..."这种定性背景，放到正文具体位置更自然，不要作为全文开场白。
+
+**技术术语解释不用分号并列**
+> NO: "系统提示的三层结构：身份定义，常驻、轻量；约束规则，常驻、精确；领域知识，按需加载。"
+> OK: 直接说："系统提示分三层：身份和约束规则常驻，领域知识按需加载。"
+
+**场景描述代替核心问题格式**
+> NO: "这类系统要解决的核心问题是：Agent 常驻服务器，同时需要..."
+> OK: "场景是：Agent 常驻服务器，要同时接多个渠道的消息..."
+
+**数据后不要加 AI 营销腔结论**
+> NO: "token 节省 37%，消除 19+ 次无效推理。"
+> OK: "token 从 15 万降到 2000，中间 19+ 次来回推理也省掉了。"
+
+**幻觉/错误原因不用学术解释框架**
+> NO: "原因在于 LLM 的中立性偏向。以'帮助、诚实、无害'为目标训练出来的模型，在群体讨论中天然倾向服从..."
+> OK: 直接说现象："LLM 训练目标是'帮助、诚实、无害'，在群体里就会倾向不反对多数人。一个说错了，后面的顺着走。"
+
+**不要用外来术语/模型名做比喻，除非读者肯定知道**
+> NO: "这就是瑞士奶酪模型的现实：每一层都有漏洞"
+> OK: "每一层都有盲区，叠在一起才够用"
+
+西方管理学模型名（瑞士奶酪模型、长尾定律等）、外语质量管理术语（Poka-yoke）在中文技术文章里多数人看不懂，去掉名字，直接说清楚那个道理就行。
+
+**多方案例并列时合并叙述，不要各自单独成段**
+同一个技术观察涉及 3 家公司/方案时，合并成一段，每家贡献一句话，读起来像分析而不是列表。
+> NO: 三段分别讲 Kimi、Cursor、Chroma 的做法，每段独立成段
+> OK: "三家承担的重点也很清楚。Kimi 用 PARL 解决...，Cursor 用 self-summarization...，Chroma 则把 prune_chunks 训成策略本身..."
+
+**有名字的来源自然融入句子，不要做括号注释或单独引用句**
+> NO: （根据 Philipp Schmid 的分析）今天 agentic model 报告共同模式已经很稳定
+> NO: 根据 Philipp Schmid 的研究，今天 agentic model 报告共同模式已经很稳定。
+> OK: "把 Philipp Schmid 对 Kimi、Cursor、Chroma 的归纳放在一起看，能看到几个共同点。"
+
+### 技术文章自检
+
+交付前快速扫一遍，优先看这些问题：
+
+- 这篇文章到底解决哪个具体问题
+- 版本、环境、依赖、上下文是否足够读者复现
+- 每段是否都有新信息，还是只是在换说法总结
+- 代码、命令、配置是否解释了关键部分
+- 结论有没有对应的证据、数据或来源
+- 有没有只讲收益，不讲代价、风险和边界
+- 有没有把个人经验写成所有场景都成立
+
+### Polish 后期残留 checklist（10+ 轮之后用）
+
+风格级 AI 味清干净后，还有一类「句子级残留」最容易被漏掉。每轮 polish 末尾按这 6 类扫一遍：
+
+**1. 叠词拗口**：同一句里出现两个意思接近的词（"也能上手用"、"也都"、"也是另外"）。识别：把句子拆成最小动作主谓宾，看哪个修饰是冗余的。
+
+**2. 缺逗号长句**：超过 25 字的句子里没有逗号断点，多半在某个时间状语 / 条件状语后漏了「，」。识别：朗读时想换气的位置就是该加逗号的位置。
+
+**3. 中英术语一致性**：同一篇里同一个常用词（copy / 复制、context / 上下文、setting / 设置）反复切换形态。识别：搜文中所有英文 token，看是否有对应中文已成主流，主流就统一为中文。
+
+**4. 突然出现的比喻 / 概念**：作者自己脑子里有的比喻（"工作台"、"水位"、"账本"）没在前文铺垫就直接用。识别：第一次出现的非通用比喻词，前一段必须有铺垫，没有就换通用词。
+
+**5. 「上 / 下 / 里」字残留**：「方案上都」「思路里」「概念上」这类介词残留是早期草稿的痕迹，删掉不影响意思。识别：搜「上都」「里都」「上的时候」。
+
+**6. 缺关键修饰**：某个名词第一次出现需要修饰才能区分性质（"Anthropic 官方推出的 Claude Design" vs "Claude Design"），漏了读者会和上下文混淆。识别：每个产品 / 工具名第一次出现，问一句"读者能否区分这是谁家的、跟前文工具的关系"。
+
+判断标准：1-3 类是字符级、5 分钟扫完；4-6 类要带上下文判断、需要全文回读。10 轮后 prose 大改不动了，时间就花在这 6 类残留上。
+
+### 默认禁用（举例，不完全，读起来有同样报告腔的一律适用）
+
+NO: 本文旨在
+NO: 主要叙事
+NO: 系统梳理（可改成“从 A 讲到 B”）
+NO: 核心结论是（可改成“最后会看到”）
+NO: 逻辑分工 / 流程节点（优先换成自然描述）
+NO: 公开口径里（可改成“按公开数据”）
+NO: 共同模式已经很稳定（可改成“能看到几个共同点”）
+NO: 可以从三个角度看（可改成“可以先看三件事”）
+NO: 值得注意的是
+NO: 综上所述
+NO: 随着...的发展
+NO: 非常 / 极其
+NO: 破折号（用逗号/分号替代）
+NO: emoji（任何场合，包括列表、标题、状态标记）
+NO: 这篇是整理出来的结果（冗余，删掉）
+NO: 有一个大背景值得先说（直接说）
+NO: 读下来有几个地方和直觉不一样，提前说一下（直接列）
+NO: 精准命中了 N 个条件
+NO: 瓶颈从 X 转移到了 Y
+NO: 是最常见的失败模式之一
+NO: X 本身没有价值，真正有用的是 Y
+NO: X 已经不是瓶颈，Y 才是
+NO: 两层/三层缺一不可
+NO: 用引号强调概念（"翻译""提升""完成了"）
+NO: 瑞士奶酪模型 / Poka-yoke（直接说道理，去掉模型名）
+NO: 孤立的单句段落（并进上下文）
+NO: 当然（让步腔，直接陈述）
+NO: 这话不算错，但 / 这么理解不能说错，但
+NO: 先给最短结论，就 N 句 / 这篇真正想钉住的 / 如果先只记一张表（文章自说明句）
+NO: 脑子里还是那老三样 / 最常见的解释就是三件事（代替读者归纳）
+NO: 拿一组具体数字看会更直观（宣告数据）
+NO: 如果说...那...（条件句段落引入）
+NO: 塑形 / 塑造行为（学术腔，用调整/影响/优化）
+NO: 下图（图片引导语，用「这张图」或「下面这张图」）
+NO: 聚焦（多为抽象目标词，改成”重点写什么”）
+NO: 拿来即用 / 装好就能用（拿来即用是营销词，自己介绍工具直接说”装好就能用”）
+NO: 翻倍 / 翻番（带数字渲染感）
+NO: 事半功倍 / 少走弯路（成语腔，前者更重）
+NO: 先立住（劝告腔，可改”注意一下”或直接陈述）
+NO: 归根到底就一件事（升华开头，pattern 1 升华句的典型）
+NO: 业务判断和用户感知是我们要守住的（抽象+集体语气，pattern 18 抽象主语）
+NO: 完全没关系（去掉”完全”两字更口语，”没事”更稳）
+NO: 把模糊性降到最低（学术抽象，改成”让它要猜的部分变少”这种动词具体）
+NO: 最好的 / 最适合 / 直接搞定 / 一句话就出（介绍自己工具的营销词，改成"我自己这么用 / 装好就能用 / 我攒了一套"）
+NO: 颗粒度（技术黑话，改成"粒度"或直接说"拆得更细"）
+NO: 家规（类比腔，直接说"规则"或"约束"）
+NO: 黑乎乎（口语过重，改成"偏暗"或"深色"）
+NO: 不可或缺（空泛形容，直接说依赖关系或删掉）
+NO: 奇妙之处（升华腔，直接说具体现象）
+
+---
+
+**底线：读起来像工程师把问题讲清楚，不是像教科书，也不是像汇报材料。**
+
+---
+
+### 对外发文专项检查
+
+公开发文（release notes、推文、博客、newsletter）交出去之前，额外扫三件事：
+
+**1. 身份和敏感信号脱敏**
+
+公开文章里不出现可反推作者身份的细节：雇主、地点、具体团队背景、简历式表述。技术决策可以具体，身份信息默认删。
+
+> NO: "作为在 X 公司做过大型系统的工程师，我发现..."
+> NO: "住在北京三年，接触了很多本地开发者，感受是..."
+> OK: "用下来感觉，这套方案在中小规模场景最稳。"
+> OK: 直接讲技术选择和依据，不交代简历背景
+
+**2. 不踩竞品**
+
+介绍自己产品时不主动贬低同类产品。功能不如别人的地方可以不提，不要拿来做反衬。
+
+> NO: "Cursor 那种全局索引很吃资源，我们没走这条路。"
+> NO: "不像 Typora，我们做的时候 X 问题想清楚了。"
+> OK: "我们的选择是只索引打开的文件，不做全局扫描。"
+> OK: 直接说自己做了什么、为什么，竞品不用出现
+
+**3. 用户感受先于功能清单**
+
+release notes 和推文里不要开场就列功能。先给一句场景或感受，再进改动细节。
+
+> NO: "V1.2.0: 新增 X 功能，修复 Y 问题，优化 Z 性能。"
+> OK: "改了两处之前用起来总觉得别扭的地方。一是..."