sspai-writing-style - SKILL.md Agent Skill

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 阶段：标题（时间）。**加粗重要概括或观点。**展开细节」格式描述演变
引用排布：开场引用→佐证引用→对立引用→收尾引用，各司其职不堆砌

检查清单

写完文章后，对照以下要点检查：

导语是否以个人经历或具体问题开头（而非「本文介绍」）
是否使用了行内链接（而非引用式链接），且所有提到的文章/工具/人物都附带了链接
中英文之间是否有空格
中文引号是否使用「」
代码块是否标注了语言类型（技术类文章）
是否有至少一处双语引用
脚注是否自然且有信息量
结语是否从具体上升到抽象
是否提到了跨平台替代方案（技术类文章，如适用）
观点类文章：是否呈现了多方观点而非一边倒
观点类文章：是否在段落内主动引入反驳再化解（而非只讲自己的立场）
数字和区间用 en dash（–）而非连字符（-）
加粗是否克制，强调短句是否放在段落中部而非开头
整体语气是否像朋友分享经验（而非教科书或社论）