clear-writing

✍️ 技术文档写作权威指南

融合Strunk经典写作规则与Divio文档框架,提供技术文档、README及API文档的结构化写作指南,助力打造清晰专业的技术内容。

收藏
13.1k
安装
3.1k
版本
v0.1.0
CLS 安全性认证2026-05-03
点击查看完整报告 >

使用说明

Clear Writing 是一款专注于技术写作与文档编写的结构化指南技能,旨在帮助用户产出清晰、简洁、专业的技术文档。该技能系统整合了William Strunk Jr.《风格的要素》经典写作法则、Divio文档分类框架以及现代技术文档最佳实践,形成了一套完整的写作方法论体系。

核心用法
该技能适用于所有面向人类读者的文本创作场景,包括但不限于技术文档、README文件、API文档、教程指南、提交信息、错误提示、UI文案及各类报告。其核心工作流围绕"撰写-审查-优化"展开:用户首先基于Strunk规则(主动语态、肯定句式、具体语言、删减冗词)起草内容,随后参照Divio框架选择适当的文档类型(教程、操作指南、参考文档或解释说明),最后通过内置的审查清单验证文档的准确性、完整性和可读性。对于上下文受限场景,技能还支持分派子代理进行专项编辑的协作模式。

显著优点
首要优势在于其权威性与实用性并重,将百年经典写作原则与现代软件文档实践相结合,既提供了"省略 needless words"等具体可执行的写作规则,又给出了README模板、API文档结构等即拿即用的工具模板。其次,技能特别针对AI写作痛点,系统梳理了"pivotal"、"delve"、"seamless"等陈词滥调清单,有效帮助用户避免生成式模型常见的浮夸文风。此外,其受众适配框架(初学者/中级/专家)和详细的代码示例规范(完整可运行、渐进式复杂度)确保了文档的实用性和包容性。

潜在缺点与局限性
作为纯静态文档型技能,Clear Writing 仅提供写作规范与模板参考,不具备自动化生成或实时校验功能,所有改进建议仍需人工实施。其次,其核心内容基于英文写作经典(Strunk's Elements of Style),虽技术文档原则具有普适性,但部分语法规则和表达习惯可能更适用于英文语境。此外,技能来源为个人开发者(T3级别),虽内容质量经审核可靠,但长期维护更新频率及社区支持规模相较于企业级产品可能存在不确定性。

适合的目标群体
该技能特别适合软件开发工程师、技术文档工程师、产品经理、开源项目维护者以及需要撰写技术博客、API文档或用户手册的内容创作者。对于希望提升技术写作专业度、避免常见文档反模式(如"文字墙"、过时文档、知识假设过高)的初学者,以及需要标准化团队文档规范的技术负责人具有直接价值。

使用风险
作为纯Markdown文档资产,该技能不存在代码执行、网络通信或数据隐私风险。所有内嵌代码均为静态示例,不含危险函数调用。主要风险在于文档示例中的命令或代码片段若被直接复制使用,需用户自行验证其适配性与安全性,但这属于常规的技术文档使用风险,非技能本身缺陷。建议用户在使用安装命令示例时保持常规安全意识。

安全解读

核心用法

Clear Writing 是一套完整的技术写作规范系统,融合了 William Strunk《风格要素》的经典规则与现代技术文档最佳实践。它覆盖六大核心场景:

1. 风格修正:强制使用主动语态、肯定句式、具体语言,删除冗余词汇(规则 10-18)
2. 文档结构:提供 README、API 文档、教程、架构文档等 7 类标准模板

3. AI 用语净化:系统识别并消除「pivotal」「delve」「leverage」「seamless」等 LLM 高频空洞词汇

4. 受众适配:针对初学者/中级/专家三级读者,调整语境深度与叙述策略

5. 代码示例规范:要求完整可运行、渐进复杂度、带语言标签的最小化示例

6. 发布前审查:10 项检查清单确保准确性、完整性、时效性

显著优点

  • 权威基础扎实:以百年经典《风格要素》为底层,经 Divio 文档框架、Wikipedia AI 检测研究等多重验证
  • 反 AI 模式精准:内置「Signs of AI Writing」参考文件,源自真实维基编辑对抗 AI 投稿的实战经验
  • 结构化极强:从单句规则到文档架构,从写作到审校,形成完整工作流
  • 上下文优化策略:提供「有限上下文」子代理模式,避免长文档挤占 token
  • 安全零风险:纯 Markdown 文档,无可执行代码、无依赖、无网络调用

潜在局限

  • 适用范围窄化:专注「人类可读 prose」,不覆盖代码生成、数据分析、多模态创作
  • 英语中心主义:Strunk 规则基于英语语法,中文等技术写作需本地化调整
  • 强制约束弱:作为指导框架而非强制 linter,依赖作者自律执行
  • 模板同质化风险:标准结构可能抑制创意文档(如叙事性技术博客)的灵活性

适合人群

| 角色 | 使用场景 |
|------|----------|
| 技术作者/文档工程师 | 建立团队写作规范,审校他人文档 |
| 开源维护者 | 撰写 README、贡献指南、API 参考 |
| 全栈开发者 | 写 commit message、PR 描述、错误提示 |
| 产品经理 | 输出需求文档、用户手册、帮助中心 |
| AI 辅助写作用户 | 消除 AI 生成文本的典型痕迹,提升可信度 |

常规风险

  • 过度简化:严格「删减冗余」可能导致技术细节丢失,需在清晰与完整间平衡
  • 风格冲突:团队若已有既定风格指南(如 Google Developer Style),需做规则映射
  • 维护成本:「永远不与代码同步更新文档」原则理想化,实际需配套 CI 检查
  • 示例 URL 误用:文档中的 api.example.com 虽仅为演示,但新手可能直接复制尝试

clear-writing 内容

references文件夹
elements-of-style文件夹
手动下载zip · 71.7 kB
01-introductory.mdtext/markdown
请选择文件