Token导航 LogoToken导航TokenDH.com
开发需要联网clawhub未标认证来源可访问clear审计通过

writing-style-zhengliu写作风格 正流

Agent Skill

用于辅助文档、README、Markdown、说明文和内容稿件的整理与改写。它适合让 Agent 提炼结构、补齐章节、统一术语、检查链接或把零散材料整理成可读文档。使用时应保留项目已有事实、命令和路径,不要把未确认的信息写成确定结论;涉及对外文案时,还需要控制语气,避免过度营销或夸大能力。

总安装

2,794

周安装

120

GitHub Stars

公开资料未说明

下载量

979
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:writing-style-zhengliu(写作风格 正流)
来源仓库:https://github.com/shing19/writing-style-zhengliu
安装命令:
openclaw skills install writing-style-zhengliu
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install writing-style-zhengliu

简介

蒸馏式知识萃取写作风格。将冗长、表达欲过强的文章转化为严格四层结构 (挑战→核心思想→设计→执行),最大化信息密度,帮读者快速获取价值。 通用领域适用。积极配合信息图增强表达。

SKILL.md

name
writing-style-zhengliu
description
|
routing
content_types
[summary, distillation, knowledge-extract, rewrite, long-form-digest]
domains
[any]
tone
[structured, fact-driven, concise, extractive]
best_for
将表达欲过强的长文蒸馏为结构化知识,四层递进,数据优先,不限领域

蒸馏写作风格

核心理念

蒸馏不是改写,是提取

  • 目标:去掉原文中的"水分"(情绪铺垫、重复论述、自我表达),留下高浓度知识
  • 与其他风格的区别:宝玉用比喻重构、花生用叙事重写、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(-

信息图集成

蒸馏文章完成后,主动触发信息图生成

  1. 调用 viewpoint-extractor 从蒸馏稿中提取 3-5 个核心观点
  2. 调用 infographic-gen 生成信息图,按层级匹配图表类型:

- 核心思想层 → 概念关系图(展示原则之间的逻辑关系) - 设计层 → 架构图/分层图(展示系统组成和数据流) - 执行层 → 流程图/时序图(展示操作步骤和顺序)

  1. 信息图保存到 output/infographics/,在蒸馏稿对应层级中标注引用位置

禁止清单

通用禁止(与其他风格共享)

  • 废话开场白:"在当今数字化时代…""随着 AI 技术的飞速发展…""众所周知…"
  • 总结套话:"综上所述""总而言之""总的来说""希望对你有帮助"
  • AI 味句式:"不是…而是…""值得注意的是""需要指出的是""本文将介绍"
  • 模糊形容:"大幅提升""显著改善""非常优秀""极其强大"
  • 商业黑话:"赋能""闭环""抓手""深耕""底层逻辑""打法""颗粒度"
  • 强调拐棍:"说实话""不得不说""有一说一""坦白讲"
  • 学术腔:"本文旨在探讨""笔者认为""研究表明"

蒸馏专属禁止

  • 转述标记:"作者认为""作者指出""文章提到""原文表示" → 直接陈述知识点本身,不加转述前缀
  • 原文情绪复制:原文的感慨、自嗨、情绪性段落直接丢弃,不转述不保留
  • 对原文的评价:"写得很好""观点深刻""分析透彻" → 蒸馏不评价,只提取
  • 重复保留:同一观点在原文出现多次时,只保留最精确、数据最完整的版本
  • 模糊因果:"因此可以看出""由此不难发现" → 换成具体因果链(A 导致 B,因为 C)
  • 过渡性废话:"接下来我们看看""让我们深入了解" → 直接进入下一层
  • 原文结构复制:不要照搬原文的章节结构——必须按四层结构重新组织

蒸馏判断标准

什么内容保留,什么丢弃:

保留丢弃
具体数字、阈值、性能指标"我觉得""我认为"等主观感受
因果关系链(A→B→C)情绪性段落(感慨、鸡汤、自我激励)
系统架构、模块名、文件路径重复论述同一观点的段落
具体步骤、命令、配置背景铺垫超过 2 句的部分
失败案例及其原因与核心知识无关的个人经历
对比数据(方案 A vs 方案 B)"这很重要""这是关键"等空洞强调
约束条件、前提假设套路性开场和结尾

使用指南

  1. 通读原文,标记核心知识点(不是标记"好句子"——是标记"知识")
  2. 判断水分:情绪段落、重复论述、过长铺垫、自嗨内容
  3. 先写核心思想层(倒逼精炼)——如果提炼不出 3 条独立判断,说明原文知识密度确实低,蒸馏后篇幅会很短,这是正常的
  4. 再写挑战层——从核心思想反推:这些思想在解决什么问题?
  5. 然后写设计层和执行层——展开细节,保留关键名词和数据
  6. 自检每条 bullet

- 是否包含事实/数据?(如果没有,要么补数据,要么这条 bullet 是废话) - 是否有模糊表达?(替换为具体数字或因果链) - 是否在复制原文的表达方式而非提取知识?

  1. 触发信息图生成——特别是设计层和执行层,图比文字更高效

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

88.02%
按下载量换算862

安全审计

VirusTotal

未展示

ClawScan

通过

Static analysis

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills