sspai-writing-style

name	sspai-writing-style
description	基于 Tom Ben 在少数派发表的文章的写作风格，将用户提供的观点、素材或大纲组织提炼成一篇完整的少数派风格文章。适用于：(1) 用户提供零散观点或素材，需要整合成文章；(2) 用户有技术主题想要撰写教程或评测；(3) 用户希望以务实、有深度的风格输出内容；(4) 用户想写观点评论、行业趋势分析或个人反思类文章。当用户提到「写文章」「少数派风格」「sspai」「写一篇教程」「技术博客」「写评论」或者要把素材整理成文章时，都应该使用这个 skill。

少数派文章写作风格指南

本 skill 的目标是帮助用户以 Tom Ben 在少数派（sspai.com）上的写作风格撰写文章。Tom Ben 的文章涵盖技术教程、工具评测、数据分析，也包括对行业趋势的观点评论和个人反思。文章以问题驱动、深度务实、跨学科视角著称，读者群体通常是对效率工具、生产力和科技趋势感兴趣。

使用流程

1. 阅读用户提供的素材（主题、大纲、要点、代码片段等）
2. 如果素材不完整，向用户确认关键信息（文章类型、目标读者、核心观点）
3. 阅读 references/style-patterns.md 获取具体的格式模板和写作范例
4. 按照下面的风格指南撰写完整文章

文章结构

每篇文章遵循以下骨架，但根据文章类型灵活调整：

---
title: 文章标题
date: YYYY-MM-DD
categories:
  - 分类1
  - 分类2
---

导语（1-2 段）

## 章节一

正文内容…

## 章节二

……

## 结语/总结/小结/反思

总结与反思…

导语：以个人经历切入

导语是整篇文章的钩子，Tom Ben 几乎从不以「本文将介绍……」开头，而是用一个具体的个人经历、一个实际遇到的问题、或一个有趣的观察来引出主题。这样做的目的是让读者觉得「这不是一篇说明书，而是一个人在分享他真实的经验」。

好的导语模式：

• 「我在做 X 的时候遇到了 Y 问题」→ 引出工具/方法
• 「前段时间看到一个有趣的 Z」→ 引出分析/讨论
• 「某天突然冒出一个想法」→ 引出实验/探索

正文：节奏感是关键

文章类型不同，正文的节奏也不同：

技术教程类的节奏是：问题→方案→代码→解释→结果→局限

1. 用一两句话说清楚要解决什么
2. 推荐的工具或方法，附上链接
3. 给出实际可运行的代码块
4. 对代码中的关键参数逐一说明
5. 截图、输出示例或 GIF
6. 讨论局限与替代方案，保持诚实

观点评论类的节奏是：现象→多方观点→个人经历→分析→立场

1. 描述一个现象或争议（引用推文、文章、论坛讨论）
2. 呈现不同立场的代表性观点（双语引用尤其适合这里）
3. 穿插自己的亲身经历作为论据
4. 用数据、案例或逻辑分析推进论证
5. 给出自己的立场，但保持开放（「我的看法是……但也许我错了」）

工具评测/数据分析类参见 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：

1. 教程类（最常见）：问题→工具→代码→解释→截图，手把手教读者
2. 工具评测类：功能概述→亮点逐一分析→定价→用户反馈→个人建议
3. 数据分析类：缘起→数据收集→可视化→解读→反思
4. 工作流类：整体流程→各环节工具选择→实际操作→踩坑经验
5. 观点/评论类：以个人经历引入话题→梳理多方观点（支持者、反对者、中间派）→穿插自己的实际经验作为论据→引用推文、博客、论文等一手素材→给出个人立场但保持谦逊→用跨学科视角升华。这类文章不需要代码块，但仍然需要尽可能多地插入原始链接引用来支撑论证

观点类文章可采用的写作技法

• 多层次论证：用「N 个层次」框架拆解现象，从表层到深层逐步递进
• 段落内自我反驳：主动引入对立观点再化解，而不是回避反例
• 阶段叙述：用「第 N 阶段：标题（时间）。**加粗重要概括或观点。**展开细节」格式描述演变
• 引用排布：开场引用→佐证引用→对立引用→收尾引用，各司其职不堆砌

检查清单

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

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