| name | sspai-writing-style |
| description | 基于 Tom Ben 在少数派发表的文章的写作风格，将用户提供的观点、素材或大纲组织提炼成一篇完整的少数派风格文章。适用于：(1) 用户提供零散观点或素材，需要整合成文章；(2) 用户有技术主题想要撰写教程或评测；(3) 用户希望以务实、有深度的风格输出内容；(4) 用户想写观点评论、行业趋势分析或个人反思类文章。当用户提到「写文章」「少数派风格」「sspai」「写一篇教程」「技术博客」「写评论」或者要把素材整理成文章时，都应该使用这个 skill。 |
少数派文章写作风格指南
本 skill 的目标是帮助用户以 Tom Ben 在少数派（sspai.com）上的写作风格撰写文章。Tom Ben 的文章涵盖技术教程、工具评测、数据分析，也包括对行业趋势的观点评论和个人反思。文章以问题驱动、深度务实、跨学科视角著称，读者群体通常是对效率工具、生产力和科技趋势感兴趣。
使用流程
- 阅读用户提供的素材（主题、大纲、要点、代码片段等）
- 如果素材不完整，向用户确认关键信息（文章类型、目标读者、核心观点）
- 阅读
references/style-patterns.md 获取具体的格式模板和写作范例
- 按照下面的风格指南撰写完整文章
文章结构
每篇文章遵循以下骨架，但根据文章类型灵活调整：
---
title: 文章标题
date: YYYY-MM-DD
categories:
- 分类1
- 分类2
---
导语（1-2 段）
## 章节一
正文内容…
## 章节二
……
## 结语/总结/小结/反思
总结与反思…
导语：以个人经历切入
导语是整篇文章的钩子，Tom Ben 几乎从不以「本文将介绍……」开头，而是用一个具体的个人经历、一个实际遇到的问题、或一个有趣的观察来引出主题。这样做的目的是让读者觉得「这不是一篇说明书，而是一个人在分享他真实的经验」。
好的导语模式：
- 「我在做 X 的时候遇到了 Y 问题」→ 引出工具/方法
- 「前段时间看到一个有趣的 Z」→ 引出分析/讨论
- 「某天突然冒出一个想法」→ 引出实验/探索
正文：节奏感是关键
文章类型不同，正文的节奏也不同：
技术教程类的节奏是：问题→方案→代码→解释→结果→局限
- 用一两句话说清楚要解决什么
- 推荐的工具或方法，附上链接
- 给出实际可运行的代码块
- 对代码中的关键参数逐一说明
- 截图、输出示例或 GIF
- 讨论局限与替代方案，保持诚实
观点评论类的节奏是：现象→多方观点→个人经历→分析→立场
- 描述一个现象或争议（引用推文、文章、论坛讨论）
- 呈现不同立场的代表性观点（双语引用尤其适合这里）
- 穿插自己的亲身经历作为论据
- 用数据、案例或逻辑分析推进论证
- 给出自己的立场，但保持开放（「我的看法是……但也许我错了」）
工具评测/数据分析类参见 references/style-patterns.md 中的对应模板。
结语：从具体到抽象
结语不是简单地「总结全文」，而是从技术细节中跳脱出来，做一点更宏观的思考——可以是对工具哲学的反思、对工作方式的感悟、或者一个相关的跨学科联想。结语也常以一句引用收尾。
语言风格
基本原则
- 语言：简体中文为主，技术术语保留英文原文（如 CLI、API、PDF、OCR）
- 语气：像一个懂技术的朋友在聊天，不是在写教科书。专业但不端着，有个人观点但不说教
- 句式：长短句交替，避免连续的短句或长句。偶尔用一个很短的句子来制造节奏感
- 段落：尽量避免单句段落或过短段落（除非为了强调）。同时避免段落过长导致阅读疲劳
- 分隔线：正文中不使用
--- 水平分隔线，用章节标题来分隔内容
- 链接：使用行内链接，不使用引用式链接。文中提到的每个工具、文章、人物尽量都附带链接
- 英文原文：避免在正文中出现超过一句的英文。引用外文观点时优先使用中文翻译，在括号中附关键短语的英文原文。在关键处可以添加英文原文；引用块（blockquote）中允许包含英文原文，格式为中文翻译在前、英文原文在后（用
--- 分隔）
标点与排版
- 中文引号使用「」而不是 "" 或 “”
- 句号、逗号等标点符号放在引号「」外，例如「AI 提升了效率」。而不是「AI 提升了效率。」
- 中英文之间加空格：
使用 Homebrew 安装
- 英文专有名词首字母大写（特殊名称除外）：
Pandoc、Keyboard Maestro
- 加粗用于强调核心观点或关键概念，不要过度使用，不要对中文使用斜体（英文可以斜体）
- 偶尔用
删除线 做幽默的旁白（如「说的就是你 Python」）
- emoji 偶尔使用，不要过多（一篇文章 2-4 个足够）
脚注
脚注用于补充说明、有趣的旁白、或者不想打断正文节奏的额外信息。脚注标识符同样使用 3 位随机字母数字组合。
正文中这样写：
macOS 都预装了 Curl，因此不需要额外安装 [^hks]。
文档末尾或段落下方放脚注内容：
[^hks]: 比如 Homebrew 就使用的是 Curl 来下载软件。
脚注的语气可以比正文更随意，甚至可以夹带一点私货或吐槽。
双语引用
在引用英文名言、评论或文献时，优先只呈现中文翻译，在翻译后的括号中附上关键短语的英文原文即可。避免在正文中出现超过一句的英文原文。如果英文原文确实重要且较短（一句以内），可以使用 blockquote 格式呈现中文翻译，并在括号中附上英文关键词。
正如 Kustov 所写：「学术界是这个星球上最因循守旧的机构。」
Vincent 在复盘中总结得很好：「AI 让我更快了，但没有让我更聪明。」（AI made me faster, not smarter.）
>
> ---
>
> 引用式链接的意义并不在于它们更容易书写，关键在于使用引用式链接可以大大提高 Markdown 源文件的可读性。
内容风格
工具推荐的态度
- 优先推荐开源和免费工具，但不排斥付费软件
- 提到工具时给出 GitHub 或官方链接
- 说明安装方法（尤其是
brew install）
- 提及跨平台替代方案（macOS/Linux/Windows）
- 保持诚实：说优点也说缺点
代码块（技术类文章适用）
并非所有文章都需要代码块。观点评论类文章可以完全没有代码。但如果文章涉及技术操作：
- 始终标注语言类型（
shell、python、r、applescript 等）
- 代码中加中文注释解释关键步骤
- 展示完整的命令及其输出（用
$ 前缀标注命令行输入）
- 对复杂命令的每个参数逐一解释
插图
你可以在文章合适的位置插入图片，如果不能直接提供图片，可以用占位符说明图片位置和内容。
跨学科视角
Tom Ben 的文章经常将技术话题与更宏观的思想连接起来。这不是刻意为之，而是源于真正的好奇心：
- Unix 哲学（「让程序只做好一件事」）
- DRY 原则（Don't Repeat Yourself）
- 引用 Hacker News、Stack Overflow 上网友的精彩评论
- 偶尔引用哲学家（维特根斯坦）、社会科学研究
- 引用 xkcd 漫画
谦逊与开放
- 使用「抛砖引玉」的姿态，承认自己的方法可能不是最优解
- 「如果你有更好的方法，欢迎分享」
- 承认自己的局限：「由于数据的可获取性，我只能……」
- 偶尔自嘲：「这个烂尾工程」「面向 Stack Overflow 编程」
文章类型适配
根据素材类型调整写法，详见 references/style-patterns.md：
- 教程类（最常见）：问题→工具→代码→解释→截图，手把手教读者
- 工具评测类：功能概述→亮点逐一分析→定价→用户反馈→个人建议
- 数据分析类：缘起→数据收集→可视化→解读→反思
- 工作流类：整体流程→各环节工具选择→实际操作→踩坑经验
- 观点/评论类：以个人经历引入话题→梳理多方观点（支持者、反对者、中间派）→穿插自己的实际经验作为论据→引用推文、博客、论文等一手素材→给出个人立场但保持谦逊→用跨学科视角升华。这类文章不需要代码块，但仍然需要尽可能多地插入原始链接引用来支撑论证
观点类文章可采用的写作技法
- 多层次论证：用「N 个层次」框架拆解现象，从表层到深层逐步递进
- 段落内自我反驳：主动引入对立观点再化解，而不是回避反例
- 阶段叙述：用「第 N 阶段：标题（时间）。**加粗重要概括或观点。**展开细节」格式描述演变
- 引用排布：开场引用→佐证引用→对立引用→收尾引用，各司其职不堆砌
检查清单
写完文章后，对照以下要点检查：
