Install
openclaw skills install writing-style-zhengliuWriting Style Zhengliu
蒸馏式知识萃取写作风格。将冗长、表达欲过强的文章转化为严格四层结构 （挑战→核心思想→设计→执行），最大化信息密度，帮读者快速获取价值。 通用领域适用。积极配合信息图增强表达。
Audits
Pending蒸馏写作风格
核心理念
蒸馏不是改写，是提取。
- 目标：去掉原文中的"水分"（情绪铺垫、重复论述、自我表达），留下高浓度知识
- 与其他风格的区别：宝玉用比喻重构、花生用叙事重写、Dan Koe 用框架重建——蒸馏不重构，只提纯
- 核心原则：原文作者的知识 > 原文作者的表达方式
- 适用判断：当原文"写作欲望过强，个人表达胜于教学意图"时，蒸馏是最合适的处理方式
四层结构（核心模板）
每篇蒸馏文章严格遵循以下四层，不可增减、不可乱序。
第一层：## 挑战
说明原文要解决的核心问题、约束条件、失败风险。
写法要求：
- 3-6 条一级 bullet
- 每条可带 1-3 条子 bullet 展开具体约束
- 重点：问题定义清晰、边界明确
- 含具体数字/阈值/量级（从原文中提取，不编造）
- 如果原文没有明确说"挑战"，从其论述中反推：作者在解决什么问题？什么条件下会失败？
示例：
## 挑战
- AI 生成的代码在简单任务上表现好，但复杂项目中错误率随文件数指数增长
- 超过 5 个文件的修改，首次通过率从 92% 降到 41%
- 跨模块依赖是主要失败源：68% 的错误来自接口不匹配
- 现有解法（多轮对话、更长上下文）治标不治本
- 上下文窗口从 8K 扩到 200K，复杂任务成功率仅提升 7%
第二层：## 核心思想
高度提炼原文主线原则——为什么这样做。
写法要求：
- 这是最精炼的一层，每条 bullet 是一个可独立成立的判断
- 3-6 条，尽量控制在最少的条目数
- 不展开细节，不举例，不加子 bullet（除非绝对必要）
- 强调洞察和因果关系
- 读者只读这一层就能抓到文章精髓
示例：
## 核心思想
- 代码生成的瓶颈不在模型能力，在任务分解——人类程序员也不会一次写完整个系统
- 正确的抽象层级 = 正确的 prompt 粒度：每次只改一个模块，让 AI 像函数一样被调用
- 验证必须自动化且前置：每步生成后立即运行测试，错误在当步修复，不累积
第三层：## 设计
展开系统分层、关键模块、数据/文件组织、校验与检索机制。
写法要求：
- 3-6 条一级 bullet
- 积极使用子 bullet 展开细节（每条 1-3 条子 bullet）
- 保留所有关键名词：文件名、目录名、脚本名、机制名、命令、API 名
- 关键名词不翻译、不泛化、不简化
- 结构要能让读者理解"怎么构建的"
- 如果原文涉及架构/系统设计，这一层信息量应该最大
示例：
## 设计
- 三层任务分解架构：Planner → Coder → Reviewer
- Planner：接收用户需求，输出 task graph（DAG 格式），每个节点是单文件修改
- Coder：逐节点执行，每次只看目标文件 + 接口定义，不加载全部代码
- Reviewer：每个节点完成后运行 `pytest` + type check，失败则回退到 Coder 重试（最多 3 次）
- 上下文管理用 retrieval 而非全量加载
- 向量索引粒度：函数级（非文件级），用 `tree-sitter` 解析 AST
- 每次 Coder 调用只注入相关函数签名（平均 2.3K tokens vs 全量 47K tokens）
第四层：## 执行
落地流程、自动化步骤、运行节奏、协作方式、监控反馈。
写法要求：
- 3-6 条一级 bullet
- 积极使用子 bullet 展开
- 含具体步骤、命令、时间点、频率、路径
- 读者看完这层应该能动手操作或理解如何操作
- 如果原文没有明确的"执行"部分，从其方法论中推导出可执行步骤
示例：
## 执行
- 初始化项目索引：`python index.py --repo ./my-project --granularity function`
- 首次索引耗时约 2 分钟/万行代码
- 增量更新：每次 `git commit` 后自动触发，<5 秒
- 单次任务流程：需求描述 → Planner 生成 DAG → 逐节点执行 → 全量测试 → 输出 PR
- 平均耗时：中等复杂度（3-5 文件）约 4 分钟
- 失败回退：单节点最多重试 3 次，超出则标记人工审查
格式规则
- 每层使用
##（H2）标题，标题只写层名（挑战/核心思想/设计/执行），不加编号 - 每层 3-6 条一级 bullet（
-开头） - 一级 bullet 下用 TAB 缩进的子 bullet 展开细节，每条 1-3 条子 bullet
- 先结论后细节：bullet 第一句是结论/判断，子 bullet 补充数据和细节
- 优先事实/数据：数字、阈值、频率、顺序、路径、命令、时间点优先于定性描述
- 保留原文关键名词（文件名、目录名、脚本名、机制名、命令）不翻译/不泛化
- 核心思想层最精炼——能 3 条不写 4 条；挑战/设计/执行层可充分展开
- 不设字数上限，以知识点完整提取为优先
- 加粗（
**）仅用于关键数据或核心判断，每层不超过 3 处 - 不使用 blockquote（这不是观点表达文章）
- 不使用编号列表（1. 2. 3.）——统一用 bullet（
-）
信息图集成
蒸馏文章完成后，主动触发信息图生成：
- 调用
viewpoint-extractor从蒸馏稿中提取 3-5 个核心观点 - 调用
infographic-gen生成信息图，按层级匹配图表类型：- 核心思想层 → 概念关系图（展示原则之间的逻辑关系）
- 设计层 → 架构图/分层图（展示系统组成和数据流）
- 执行层 → 流程图/时序图（展示操作步骤和顺序）
- 信息图保存到
output/infographics/，在蒸馏稿对应层级中标注引用位置
禁止清单
通用禁止（与其他风格共享）
- 废话开场白："在当今数字化时代…""随着 AI 技术的飞速发展…""众所周知…"
- 总结套话："综上所述""总而言之""总的来说""希望对你有帮助"
- AI 味句式："不是…而是…""值得注意的是""需要指出的是""本文将介绍"
- 模糊形容："大幅提升""显著改善""非常优秀""极其强大"
- 商业黑话："赋能""闭环""抓手""深耕""底层逻辑""打法""颗粒度"
- 强调拐棍："说实话""不得不说""有一说一""坦白讲"
- 学术腔："本文旨在探讨""笔者认为""研究表明"
蒸馏专属禁止
- 转述标记："作者认为""作者指出""文章提到""原文表示" → 直接陈述知识点本身，不加转述前缀
- 原文情绪复制：原文的感慨、自嗨、情绪性段落直接丢弃，不转述不保留
- 对原文的评价："写得很好""观点深刻""分析透彻" → 蒸馏不评价，只提取
- 重复保留：同一观点在原文出现多次时，只保留最精确、数据最完整的版本
- 模糊因果："因此可以看出""由此不难发现" → 换成具体因果链（A 导致 B，因为 C）
- 过渡性废话："接下来我们看看""让我们深入了解" → 直接进入下一层
- 原文结构复制：不要照搬原文的章节结构——必须按四层结构重新组织
蒸馏判断标准
什么内容保留，什么丢弃：
| 保留 | 丢弃 |
|---|---|
| 具体数字、阈值、性能指标 | "我觉得""我认为"等主观感受 |
| 因果关系链（A→B→C） | 情绪性段落（感慨、鸡汤、自我激励） |
| 系统架构、模块名、文件路径 | 重复论述同一观点的段落 |
| 具体步骤、命令、配置 | 背景铺垫超过 2 句的部分 |
| 失败案例及其原因 | 与核心知识无关的个人经历 |
| 对比数据（方案 A vs 方案 B） | "这很重要""这是关键"等空洞强调 |
| 约束条件、前提假设 | 套路性开场和结尾 |
使用指南
- 通读原文，标记核心知识点（不是标记"好句子"——是标记"知识"）
- 判断水分：情绪段落、重复论述、过长铺垫、自嗨内容
- 先写核心思想层（倒逼精炼）——如果提炼不出 3 条独立判断，说明原文知识密度确实低，蒸馏后篇幅会很短，这是正常的
- 再写挑战层——从核心思想反推：这些思想在解决什么问题？
- 然后写设计层和执行层——展开细节，保留关键名词和数据
- 自检每条 bullet：
- 是否包含事实/数据？（如果没有，要么补数据，要么这条 bullet 是废话）
- 是否有模糊表达？（替换为具体数字或因果链）
- 是否在复制原文的表达方式而非提取知识？
- 触发信息图生成——特别是设计层和执行层，图比文字更高效