# Conversation Synthesis Skill v3

目标：把长期对话整理成真正被思考过的文章，并让 Skill 能从修改中持续进化

这个 Skill 用于把长期、多轮、不断搜索、质疑、补充和修正的对话，整理成一篇真正有观点、有证据、有推理推进、有个人质感的文章、研究笔记、分析稿或探索总结。

它的目标不是：

• 复述聊天记录；
• 罗列搜索结果；
• 把用户说过的话重新排版；
• 制造很多“金句”；
• 写成一篇看起来很完整、实际上没有推进问题的 AI 长文。

最终文章应该让读者感觉：

这个问题真的被一个人持续想过、查过、怀疑过、修正过。

同时，这个 Skill 本身也应该能够从后续文章修改中学习。

但这种学习必须遵守一个重要原则：

Skill 更新的目标，是提炼可迁移的通用规则，而不是把某一篇文章的具体修改硬编码进 Skill。

---

第一部分：Skill 自身的更新规则

这一部分优先级最高。

以后任何一次根据实际文章修改这个 Skill，都必须先遵守这些规则。

---

1. Skill 更新必须追求“通用化”，不能追求“记住这一篇文章”

从一篇文章的修改中提炼经验时，先问：

这个问题只属于当前文章，还是以后其他主题的文章也可能出现？

例如：

用户说：

“这里一个词一行，看起来很碎。”

不能直接把 Skill 更新成：

“AI、机器人、芯片这类词不能一行一个。”

真正应该提炼的是：

长文中，如果多个短词、短语或短句可以自然组成一句话，就不要为了制造节奏拆成大量独立行。

前者是文章定制。

后者才是通用 Skill。

---

2. 新规则加入 Skill 前，必须通过“通用性测试”

一条经验进入 Skill 前，至少问四个问题：

A. 它是否与当前文章主题无关？

把“劳动”“AI”“职场”“政策”等具体主题替换成另一个领域，这条规则是否依然成立？

B. 它是否能应用于至少两种不同类型的文章？

例如同时适用于：

• 社会观察文章；
• 产品分析；
• 技术研究笔记；
• 商业分析；
• 个人经验总结。

C. 它解决的是写作机制问题，还是一次性的内容偏好？

例如：

“所有可核验数字都应该检查来源”

是机制规则。

“这篇文章不要讨论某个案例”

是局部内容判断。

D. 它能否被明确执行或检查？

“文章要更好”

不能作为 Skill 规则。

“章节标题脱离正文后仍应能说明本节内容”

可以成为 Skill 规则。

只有通过这些检查的内容，才应该进入通用 Skill。

---

3. 区分三类反馈：通用规则、任务规则、局部修改

用户修改文章时，先判断反馈属于哪一类。

第一类：通用规则

适合进入 Skill。

例如：

• 可核验数字要有可靠来源；
• 不必要的一词一行会破坏长文阅读；
• 用户修改某处后应全文检查同类问题；
• 标题应该独立表达章节内容。

第二类：当前任务规则

只对这一篇文章或这一类稿件成立。

例如：

• 这篇文章希望增加反讽；
• 这篇文章使用第一人称；
• 这篇文章不要学术论文口吻。

这些规则可以应用于当前任务，但不能自动升级为 Skill 的永久通用规则。

第三类：局部修改

只修改具体一句、一个案例、一个数字或一个章节。

例如：

“这句话应该改成‘我没地方去，就坐在电动车上刷手机’。”

这是内容修订，不是 Skill 规则。

---

4. 不允许因为新经验而静默删除旧规则

更新 Skill 时，上一版本中已经存在的规则默认全部保留。

不能因为新版本重新组织结构，就无意中遗漏：

• 原有事实核验规则；
• 原有用户真实性规则；
• 原有反例检查；
• 原有链接处理；
• 原有结构要求；
• 原有风格限制；
• 原有最终检查。

重写不等于重新发明。

更新前应先建立“旧规则清单”。

更新后逐项确认：

• 保留；
• 合并；
• 改写；
• 拆分；
• 建议删除。

任何旧规则不能无声消失。

---

5. 合并规则可以，但必须保留原规则解决的问题

两个规则重复时，可以整合。

但不能因为文字变短，就丢掉其中一个规则原本防止的问题。

例如：

旧规则A：

不要大量使用一个词一行。

旧规则B：

不要用短句堆叠制造PPT感。

可以合并成：

长文正文默认使用连续 prose；避免不必要的单词独立成行、短句堆叠和PPT式排版。

但必须确认：

• 单词一行的问题仍被覆盖；
• 短句堆叠的问题仍被覆盖；
• PPT式排版的问题仍被覆盖。

---

6. 如果新旧规则存在冲突，不允许模型自行决定删谁

出现以下情况时：

• 新规则与旧规则方向相反；
• 两个规则不能同时满足；
• 合并以后会改变旧规则含义；
• 必须在“更详细”与“更简洁”之间做长期取舍；
• 用户过去明确要求过A，现在的新经验似乎要求B；

应该把冲突明确列出来，让用户决定。

例如：

旧规则强调尽量保留搜索资产。
新经验强调删除不推进主线的资料。
建议整合为“先完整回收，再按主线相关性筛选”。
是否接受这种合并？

涉及规则去留时，用户拥有最终决定权。

---

7. Skill 更新必须说明“为什么改”

任何新增、合并或建议删除的规则，都应该能回答：

它解决了什么重复出现的问题？

不要为了让 Skill 看起来更完整而无限加规则。

每条规则至少对应一种明确失败模式，例如：

• 文章像PPT；
• 事实缺来源；
• 用户修一句但全文同类问题没改；
• 标题脱离正文看不懂；
• 研究很多但主线越来越散。

---

8. 单篇文章不能轻易改变 Skill 的整体风格

一次文章要求：

“更讽刺一点。”

不能把 Skill 永久改成：

“所有文章都应该增加反讽。”

一次文章要求：

“第一人称写。”

不能改成：

“Conversation Synthesis 默认第一人称。”

除非多个不同任务都证明这是稳定、跨场景有效的规则。

---

9. Skill 的规则要尽量描述“判断方法”，而不是固定答案

较差：

每篇文章写17个章节。

更好：

章节数量由问题链决定，不为了整齐固定数量。

较差：

每篇文章最后都回到深圳早上八点。

更好：

如果文章从具体场景开始，结尾可以考虑回到这个场景，并用全文得到的新理解重新解释它。

Skill 应该教会模型判断。

不是给模型一张固定模板。

---

10. 示例只用于解释规则，不能反过来成为模板

Skill 中可以有例子。

但所有例子都应理解为：

“展示这个规则如何运作。”

不是：

“以后照这个句子写。”

示例里的：

• 行业；
• 国家；
• 人物；
• 数字；
• 主题；
• 语气；

都不具有约束性。

---

11. Skill 更新应维护版本差异

每次正式更新 Skill 时，应能回答：

新增了什么？

合并了什么？

哪些规则只是重新表述？

有没有规则被建议删除？

有没有冲突等待用户决定？

如果用户只要求最终完整版本，可以不在正文里展示完整 changelog，但更新过程内部必须做这个检查。

---

12. Skill 不应该无限膨胀

新经验不代表一定要新建一个章节。

优先顺序：

1. 能否加入已有规则？
2. 能否扩展已有检查项？
3. 是否真的需要成为独立规则？

如果两个规则本质相同，应整合。

Skill 的目标是：

覆盖更多失败模式，同时保持可执行。

不是规则越多越好。

---

第二部分：先理解对话，而不是马上写文章

---

13. 先还原“问题链”，不要按聊天时间顺序复述

正式写作前，先内部重建讨论过程：

最初的问题
→ 第一次追问
→ 新经历或反例
→ 搜索与证据
→ 原判断被修正
→ 新矛盾出现
→ 问题继续推进
→ 当前真正需要回答的问题

聊天是时间顺序。

文章需要的是逻辑顺序。

每一个章节都要能够回答：

为什么现在必须谈这一节？

---

14. 先确定文章最终真正回答的问题

不要一上来就写。

先用一句话完成：

这篇文章最终真正想回答什么？

长期对话里，最初的问题经常只是入口。

文章真正有价值的部分，往往是：

原问题最后发生了什么变化？

如果中心问题还不清楚，继续整理，不急着写。

---

15. 区分五类内容

写作前把重要内容内部分类：

事实

有外部来源可以核验。

用户判断

用户明确表达过的观点。

推演

根据事实和用户经历进一步推导。

假设

合理，但尚未得到充分验证。

未解决问题

现阶段没有足够证据回答。

最重要的原则：

叙事顺畅，不等于事实成立。

---

第三部分：保护用户真实性

---

16. 不替用户说话

不能把：

“我怀疑可能存在这种问题。”

改成：

“事实证明就是这样。”

不能把：

“我正在考虑。”

改成：

“我决定了。”

不能把助手自己产生的观点塞进用户第一人称。

如果证据或态度不确定，允许保留：

• 可能；
• 我更倾向于；
• 至少说明；
• 现有证据支持；
• 目前还不能证明。

---

17. 用户最新表达优先

用户后续修正过：

• 场景；
• 情绪；
• 强度；
• 因果关系；
• 具体用词；

以后版本都应优先采用最新版本。

不要因为重新生成全文，又自动回到旧措辞。

---

18. 保留具体经验，不要过度文学化

真实的动作往往比抽象语言更有力量。

优先保留：

• 时间；
• 地点；
• 动作；
• 当时想到什么；
• 发生了什么变化。

不要把具体体验润色成空泛“高级表达”。

---

19. 个人经历是问题入口，不是社会统计

个人经历可以用于：

• 提出问题；
• 提出假设；
• 展示机制；
• 提供真实场景。

但不能直接从：

“我经历过。”

跳到：

“社会上的人都这样。”

如果要扩大到社会层面，应继续找：

• 数据；
• 调查；
• 研究；
• 制度；
• 他人样本。

---

第四部分：管理信息资产

---

20. 建立信息资产清单

长期对话中可能积累：

• 数据；
• 法律；
• 政策；
• 官方文件；
• 学术论文；
• 案例；
• 国外制度；
• 网站；
• 工具；
• 社区；
• 搜索关键词；
• 方法；
• 模板；
• 工作流；
• 未完成的研究线索。

正式写作前先回收。

避免因为重新组织文章而无意丢失重要信息。

---

21. 信息资产先回收，再筛选

“不能丢”与“不能全塞”同时成立。

每条资料进入正文前问：

1. 是否支撑核心判断？
2. 是否改变问题理解？
3. 是否提供重要反例？
4. 是否防止重大误解？
5. 是否为读者提供后续行动价值？

如果都不是，可以不进入正文。

---

22. 信息太多时分级

建议内部划分：

核心证据

缺少它，重要判断站不住。

重要补充

让判断更完整、更准确。

反例或限制

防止结论过度扩张。

后续资源

值得保留，但不必进入主线。

边缘信息

正确，但与中心问题关系弱。

优先级通常是：

推动问题变化的信息 > 核心证据 > 关键限制 > 后续资源 > 一般背景。

---

第五部分：证据与来源

---

23. 对可核验事实做证据覆盖审计

以下内容只要能够找到可靠来源，第一次出现时原则上应提供来源：

• 具体数字；
• 百分比；
• 法律规定；
• 政策；
• 研究结论；
• 国外制度；
• 机构定义；
• 重要历史事实；
• 具体公共案例。

写完以后全文扫描：

每一个重要数字，来源在哪里？

每一个“研究发现”，论文在哪里？

每一个法律结论，法条在哪里？

每一个国外制度，官方说明在哪里？

---

24. 来源有优先级

默认优先：

法律原文 / 政府文件 / 官方统计
>
原始论文
>
权威国际组织
>
高质量研究机构
>
可靠媒体
>
行业媒体
>
论坛 / 社区 / 个人经验

社区更适合证明：

有人这样讨论或体验。

不适合承担核心制度事实。

---

25. 链接放在最需要它的位置

重要事实第一次出现时即可提供来源。

不要让读者：

先读十页，

最后再去参考文献里猜哪条支持哪句话。

同时避免：

• 每一句都挂链接；
• 同一个链接重复很多次；
• 链接比正文更抢眼。

---

26. 观点不需要假装成文献

以下内容通常不需要强行找链接：

• 用户亲身经历；
• 用户价值判断；
• 明确标注的推演；
• 修辞；
• 文章总结。

目标是：

事实可验证，观点可追踪，文章仍然能读。

---

27. 不能把相关写成因果

研究说：

A 与 B 相关。

不能写成：

A 导致 B。

除非研究设计真的支持这种因果强度。

写作时特别检查：

• “导致”；
• “造成”；
• “证明”；
• “必然”；
• “就是因为”。

证据强度不够就降级表达。

---

28. 搜索结果需要主线相关性检查

一项研究即使很有意思，也不一定应该写。

每加入一段资料都问：

删除这一段以后，中心判断会改变吗？

如果不会，并且它还明显拖慢文章：

• 压缩；
• 留链接；
• 放补充材料；
• 删除。

不要让文章变成：

搜到了很多，所以全部写进去。

---

第六部分：推进思考

---

29. 每个重要判断问三遍

依据是什么？

数据、法律、经历、研究还是推演？

所以呢？

它改变了哪个问题？

真正想说什么？

能否说成一句明确的话？

如果最终只能写：

这个问题很重要。

说明还没想透。

---

30. 主动寻找反例和限制

每个核心判断都问：

在什么情况下它不成立？

例如：

某种制度通常有利。

继续问：

对所有职业都适用吗？

是否存在新的风险？

成本由谁承担？

反例不是为了机械平衡。

是为了确定结论边界。

---

31. 遇到二元问题，主动寻找中间态

如果讨论自然形成：

• A / B；
• 进入 / 退出；
• 全部 / 没有；
• 自由 / 控制；

继续问：

是否存在连续谱？

是否存在第三种制度安排？

是否只是市场目前没有提供中间产品？

很多有价值的洞见，来自找到0和1之间的选项。

这是一种通用分析方法，不限于任何具体主题。

---

32. 主动识别系统激励

如果大量个人行为反复出现，继续问：

系统正在奖励什么？

系统正在惩罚什么？

人的行为是不是对激励的适应？

但要区分：

机制解释

和

已经被数据证明的因果。

---

33. 制度分析要检查实际资源是否对称

不能只写：

双方都有某项权利。

继续问：

• 谁掌握信息？
• 谁承担举证？
• 谁有专业人员？
• 谁熟悉程序？
• 谁能承担拖延？
• 谁承担时间成本？
• 谁更容易放弃？

纸面平等和实际使用能力是两件事。

---

34. 制度建议要检查副作用

每提出一种治理、监测、技术或组织方案，都继续问：

它会不会制造新的问题？

例如检查：

• 隐私；
• 监控；
• 形式主义；
• 数据造假；
• 合规成本；
• 权力滥用；
• 新的不平等。

好的方案不仅解决原问题。

也要防止新问题变得更糟。

---

35. 政策建议必须尽量落到机制

不要只写：

应该加强重视。

继续回答：

• 谁负责？
• 做什么？
• 数据从哪里来？
• 多久一次？
• 谁能看到？
• 如何保护隐私？
• 出现异常以后怎么办？
• 如何避免被游戏化？

越接近执行，建议越有价值。

---

第七部分：文章结构

---

36. 先内部生成多个标题

正式写稿前，内部产生至少5个候选标题。

一个标题尽量同时具备：

• 讨论对象；
• 核心矛盾；
• 信息增量。

不要只追求：

• 情绪；
• 文艺；
• 猎奇；
• 学术感。

标题必须与正文真正匹配。

---

37. 小标题必须独立成立

只读目录时，应该大致能知道文章在讲什么。

避免：

真正的问题

另一种可能

这里还有一个问题

优先：

为什么X会产生Y？

某种制度解决了什么，又留下什么？

标题应该承担导航功能。

---

38. 章节跟着问题变化，而不是资料分类

较差的结构：

数据

法律

国外案例

论文

因为这是资料分类。

更好的结构：

为什么原来的解释不够？

哪些证据改变了理解？

如果旧方案有问题，还有哪些中间方案？

每一节应该推进问题。

---

39. 新概念从问题中长出来

先有：

现象或矛盾。

再引入：

一个能够解释它的概念。

不要为了展示研究量，突然塞入一堆新术语。

---

第八部分：写作风格与排版

---

40. 长文默认使用连续 prose

文章应该像文章。

如果多个短语能自然写成一句话，就不要拆成大量单独行。

连续出现三行以上极短内容时，检查：

真的需要列表吗？

如果不需要，合并。

---

41. 列表只在结构上真的有价值时使用

适合列表：

• 步骤；
• 清单；
• 对比；
• 独立选项；
• 检查项；
• 分类。

不适合：

• 普通叙述；
• 制造节奏；
• 人为强调；
• 把正常段落切碎。

---

42. 控制金句密度

文章不能每段都像社交媒体海报。

避免过量：

• 粗体；
• 单句成段；
• 极短反问；
• 排比；
• “不是X，而是Y”；
• 一词一行。

默认节奏：

事实 → 解释 → 推理 → 判断 → 必要时强调。

---

43. 接地气来自具体，而不是来自口语填充词

接地气指：

• 有人；
• 有动作；
• 有成本；
• 有现实后果。

不是反复出现：

说白了；

本质上；

其实就是。

尽量让抽象问题落到可理解的现实结构。

---

44. 反讽只能建立在事实矛盾上

好的反讽：

两个现实事实放在一起，本身就荒诞。

差的反讽：

为了显得尖锐而猜测别人动机。

原则：

先把事实写稳，再让矛盾自己产生讽刺。

---

45. 犀利不等于武断

有足够证据时可以直接。

没有证据时必须保留边界。

不要为了气势提高因果强度。

---

46. 避免常见 AI 味

警惕高频使用：

• 本质上；
• 真正；
• 核心；
• 值得关注；
• 重新定义；
• 范式；
• 赋能；
• 从某种意义上。

也警惕结构化成瘾：

• 每段三点；
• 每节都总结；
• 每一页都金句；
• 过多加粗；
• 过多反问。

AI 感往往不是因为某个词。

而是因为：

所有段落都被加工得过于整齐。

---

47. 直接说，不绕

如果一句能说清楚，就不要三句铺垫。

优先：

问题在于……

而不是：

在进一步对这一问题进行分析以后，我们可以发现一个值得注意的现象……

---

第九部分：结尾

---

48. 结尾必须完成“问题升级”

结尾不是重复前文。

至少应该回答：

• 开始时在问什么？
• 哪个理解后来发生了变化？
• 现在最可信的判断是什么？
• 还有什么不知道？
• 下一步真正应该问什么？

---

49. 从具体场景开始的文章，可以考虑回环

如果开头使用一个具体经历，可以在结尾重新回来。

但不能原样重复。

应该用整篇文章得到的新理解重新解释这个场景。

回环只是一种结构工具。

不是所有文章都必须使用。

---

50. 最后一段要真的“结束”

避免：

这个问题值得进一步思考。

如果前文已经进行了深入讨论，这种结尾相当于没结尾。

最后应该给读者一个：

• 判断；
• 新问题；
• 方法；
• 选择；
• 或更准确的认识。

---

第十部分：用户修改时如何处理

---

51. 不只改用户指出的那一句

收到修改反馈以后，先问：

这是局部问题，还是暴露了一个全文级错误？

例如用户指出：

某一处换行太碎。

应该检查全文有没有同类排版。

用户指出：

某条研究缺来源。

应该重新检查全文证据覆盖。

---

52. 修订采用“反馈 → 抽象 → 扫描 → 修正”的流程

具体反馈
→ 判断它属于局部修改 / 当前任务规则 / 通用规则
→ 如果可泛化，提炼通用问题
→ 全文搜索同类失败
→ 批量修改
→ 检查旧反馈是否被恢复
→ 重新通读

---

53. 当前文章的反馈，不自动等于 Skill 更新

这是非常重要的一条。

文章修改完成以后，再单独判断：

哪些反馈值得进入 Skill？

不能在修稿过程中自动把每个用户意见都写成永久规则。

---

第十一部分：最终质量审计

---

54. 证据审计

检查：

• 重要数字是否有来源？
• 法律是否有正式来源？
• 政策是否有原文？
• 研究是否尽量有原论文？
• 国外制度是否有当地官方资料？
• 相关是否被误写成因果？
• 时间敏感数据是否过期？

---

55. 用户真实性审计

检查：

• 是否替用户下结论？
• 是否把助手观点塞进第一人称？
• 是否弱化或夸大用户情绪？
• 是否遗漏用户后续修正？
• 是否把旧措辞重新写回来？

---

56. 结构审计

检查：

• 只读标题能否理解文章路线？
• 每节为什么出现在这里？
• 有没有资料很多但与主线关系弱的章节？
• 有没有突然出现的新概念？
• 有没有章节可以删除而完全不影响文章？

---

57. 文章形态审计

检查：

• 有没有一词一行？
• 有没有不必要列表？
• 有没有PPT式排版？
• 有没有金句密度过高？
• 有没有连续大量加粗？
• 链接是否影响阅读？
• 文章是否像正常长文？

---

58. 逻辑强度审计

检查：

• 事实、判断、推演有没有混在一起？
• 是否过度推断动机？
• 是否主动寻找反例？
• 是否检查了中间态？
• 是否考虑了制度副作用？
• 是否把纸面制度等同于实际可用制度？

---

59. 结尾审计

检查：

• 有没有只是重复摘要？
• 问题是否发生升级？
• 是否真正回应开头？
• 是否留下更准确的问题？
• 最后一段有没有把文章收住？

---

第十二部分：默认工作流

读取完整对话
↓
提取用户最新真实表达
↓
还原问题链
↓
确定最终中心问题
↓
区分事实 / 用户判断 / 推演 / 假设 / 未解决问题
↓
建立信息资产清单
↓
按重要性和主线相关性筛选
↓
寻找反例、限制和中间态
↓
生成多个候选标题
↓
设计可独立理解的小标题
↓
完成第一稿
↓
补回重要证据和来源
↓
删除不推进主线的资料
↓
检查资源不对称和制度副作用
↓
修正文体、排版和AI味
↓
完成结尾与问题升级
↓
证据审计
↓
用户真实性审计
↓
结构审计
↓
文章形态审计
↓
逻辑强度审计
↓
最终输出

---

第十三部分：Skill 自身更新的默认工作流

以后根据新文章经验修改本 Skill 时，使用另一套流程：

收集新反馈
↓
逐条判断：局部修改 / 当前任务规则 / 通用规则
↓
只有通用规则进入 Skill 候选区
↓
进行跨主题通用性测试
↓
建立上一版规则清单
↓
检查新规则是否已有旧规则覆盖
↓
优先整合，不盲目新增
↓
检查是否会削弱或删除旧规则
↓
若存在规则冲突或取舍，列给用户决定
↓
形成新版
↓
逐项核对上一版规则：保留 / 合并 / 改写 / 建议删除
↓
确认没有静默丢失
↓
输出完整新版

---

第十四部分：更新 Skill 时的保留原则

默认情况下：

旧规则 = 保留

除非：

• 已被更通用的新规则完全覆盖；
• 与其他规则重复；
• 已被证明有害；
• 用户明确决定删除。

即使准备删除，也不应直接删除。

应先标记：

建议删除：原因……

交给用户决定。

---

第十五部分：什么不应该进入通用 Skill

以下内容通常不要永久写入：

• 某篇文章的具体标题偏好；
• 某个具体行业；
• 某个国家的具体政策；
• 某个案例是否保留；
• 某一句个人经历应该如何表达；
• 一次性的语气要求；
• 某次用户要求增加或减少某章节；
• 某个具体数字；
• 某一个网站。

Skill 应该保留：

为什么某种处理方式更好。

而不是：

上一次具体怎么改。

---

第十六部分：判断一条新规则是否值得永久保留

一条新规则如果同时满足越多条件，越值得进入 Skill：

• 多篇文章都可能遇到；
• 与具体主题无关；
• 能解释明确失败模式；
• 能被操作化；
• 能被最终检查发现；
• 不会过度限制其他文体；
• 与已有规则不重复；
• 能提高事实准确性、逻辑质量或阅读体验。

如果只满足：

“这篇文章这样更好。”

先作为任务经验，不急着永久写入。

---

第十七部分：Skill 更新的用户决策权

以下情况必须让用户决定：

• 删除已有规则；
• 两条规则无法兼容；
• 合并会改变原规则含义；
• 新规则明显改变 Skill 整体风格；
• 从“默认行为”改成“禁止行为”；
• 从“建议”升级为“必须”；
• 从通用规则改为特定风格规则。

Skill 可以建议。

不能替用户决定长期规则方向。

---

第十八部分：最终标准

一篇好的 Conversation Synthesis 应该做到：

不替用户说话。

用户后续修正不会在重写中消失。

个人经历具体，但不会冒充社会统计。

事实、判断、推演和假设能够区分。

数字、法律、政策和研究可以核验。

重要信息资产不会无故丢失。

无关资料也不会因为搜过就硬塞进正文。

会主动寻找反例、限制和中间态。

会考虑纸面制度与现实资源的不对称。

会检查一个解决方案是否制造新的问题。

标题有信息量。

小标题能够独立导航。

正文像文章，而不是PPT。

强调有节制。

反讽建立在事实矛盾上。

证据不足时敢于承认不知道。

结尾完成问题升级，而不是机械总结。

最重要的是：

读完以后，原来的问题应该变得更准确。

而不是只让人觉得：

“这篇文章资料很多，排版也很整齐。”

---

第十九部分：这个 Skill 自己也必须满足同样的标准

这个 Skill 的每一次更新，也应该做到：

从具体问题提炼通用经验，而不是记住具体文章。

不因为加入新规则而静默丢失旧规则。

重复规则优先整合，而不是无限膨胀。

规则冲突时让用户决定，不擅自取舍。

示例用于解释，不变成硬模板。

每条规则都应该对应一个真实的失败模式。

能够说明为什么新增、为什么合并、为什么保留。

最终目标不是制造一个越来越长的规则库。

而是让这个 Skill 随着真实写作经验不断变得：

更通用、更稳定、更少重复、更难犯同类错误。