Writing Style Zhengliu
蒸馏式知识萃取写作风格。将冗长、表达欲过强的文章转化为严格四层结构 (挑战→核心思想→设计→执行),最大化信息密度,帮读者快速获取价值。 通用领域适用。积极配合信息图增强表达。
MIT-0 · Free to use, modify, and redistribute. No attribution required.
⭐ 0 · 17 · 0 current installs · 0 all-time installs
by@shing19
MIT-0
Security Scan
OpenClaw
Benign
high confidencePurpose & Capability
名称/描述(蒸馏式写作)与 SKILL.md 中详尽的格式规则、四层结构和执行流程完全一致;没有要求与写作无关的二进制、凭据或配置路径。
Instruction Scope
SKILL.md 只给出详尽的写作与格式化规则,属于该技能的正常范围;唯一值得注意的部分是主动触发信息图生成(调用 `viewpoint-extractor` 和 `infographic-gen`)并将结果写入 `output/infographics/`——这是合理的工作流,但涉及调用外部生成器与写文件,用户应确认这些工具的实现和目标位置是否受信任。
Install Mechanism
无安装规范、无代码文件、instruction-only,低风险;静态扫描也无可执行内容可分析。
Credentials
不要求任何环境变量、凭据或敏感配置路径;SKILL.md 中也未指示访问与写作目的无关的系统凭证或外部服务凭据。
Persistence & Privilege
flags 显示默认行为(不强制常驻、可由用户调用、允许模型自主调用),无 always:true 或修改其他技能/全局配置的指令。
Assessment
总体来看这是一个内部一致的写作风格指南。安装前请确认两点:1) SKILL.md 指定的 `viewpoint-extractor` 与 `infographic-gen` 是你信任的本地/受控服务或其他已安装技能;如果这些是外部 API,请核实它们是否需要凭据并评估数据泄露风险;2) 输出路径 `output/infographics/` 会在代理可写的环境中创建文件,确保写入该目录符合你的隐私/合规要求。若不确定,可先用非敏感示例文本测试其行为。Like a lobster shell, security has layers — review code before you run it.
Current versionv1.0.0
Download ziplatest
License
MIT-0
Free to use, modify, and redistribute. No attribution required.
SKILL.md
蒸馏写作风格
核心理念
蒸馏不是改写,是提取。
- 目标:去掉原文中的"水分"(情绪铺垫、重复论述、自我表达),留下高浓度知识
- 与其他风格的区别:宝玉用比喻重构、花生用叙事重写、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 是废话)
- 是否有模糊表达?(替换为具体数字或因果链)
- 是否在复制原文的表达方式而非提取知识?
- 触发信息图生成——特别是设计层和执行层,图比文字更高效
Files
1 totalSelect a file
Select a file to preview.
Comments
Loading comments…
