读书笔记 · 约 18,690 字 · 预计推送 2 部分

《Unix 编程艺术》选读：对个人 CLI 工具与脚本设计仍有效的原则（精读） 未开始

目录

题记与说明

一、七维提取

1. 核心问题

这本书要回答的大问题：Unix 为什么能用"简单零件"拼出长期可靠的系统，而这门手艺为什么传不进教科书？ Raymond 开篇即定位：Unix 哲学"不是一种形式化的设计方法……它是自下而上的，不是自上而下的。它是务实的，植根于经验"（"The Unix philosophy is not a formal design method… It is bottom-up, not top-down. It is pragmatic and grounded in experience."，ch01s06）。全书做的事是把 Unix 文化中"半反射式的专家知识"（implicit half-reflexive knowledge）显式化成可传授、可复用的设计规则。

本选读的子问题：当作者=唯一用户=唯一维护者时（个人 CLI 工具与脚本），这 17 条规则和一套接口模式里，哪些是持久有效的纪律，哪些已被 20 年的实践修正？

2. 主要主张

（1）纲领：三句话 + 四条原则。 管道发明人 Doug McIlroy 的两段原话被 Raymond 奉为源头（ch01s06）：

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
（写只做一件事并把它做好的程序；写能互相协作的程序；写处理文本流的程序，因为那是通用接口。）

更早的 [McIlroy78] 版本四条里，对个人脚本最有杀伤力的是这条：

(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information… Don't insist on interactive input.

（2）17 条规则（ch01s06 原文全录，此处保留英文题目与关键限定）：Modularity（简单零件 + 干净接口）、Clarity（"Clarity is better than cleverness"）、Composition（"Design programs to be connected to other programs"）、Separation（"Separate policy from mechanism; separate interfaces from engines"）、Simplicity（"add complexity only where you must"）、Parsimony、Transparency（为可检视与调试而设计）、Robustness（"Robustness is the child of transparency and simplicity"）、Representation（"Fold knowledge into data so program logic can be stupid and robust"）、Least Surprise（"In interface design, always do the least surprising thing"）、Silence（"When a program has nothing surprising to say, it should say nothing"）、Repair（"When you must fail, fail noisily and as soon as possible"）、Economy（"Programmer time is expensive; conserve it in preference to machine time"）、Generation、Optimization（"Prototype before polishing. Get it working before you optimize it"）、Diversity（"Distrust all claims for 'one true way'"）、Extensibility（"Design for the future, because it will be here sooner than you think"）。

（3）一句话总纲（ch01s07 全文核心）："All the philosophy really boils down to one iron law, the hallowed 'KISS principle'."

（4）接口五指标（ch11s03）：Raymond 用 concision（简练）、expressiveness（表达力）、ease（易学）、transparency（透明）、scriptability（可脚本化） 给接口风格定位，并强调"它们是比较级，不是绝对值"；核心洞察是人类和程序对同一指标的成本函数不同——可脚本化让"打包日常流程、不再手动执行"成为可能，"这是其他软件环境里没有的、安静但巨大的生产力放大器"。

（5）CLI 的存在理由与 crossover point（ch11s04）：CLI 在电传打字机死后仍存活，理由有二——对复杂任务表达力更强、可脚本化（可组合）。代价是高记忆负担、低易学性；但"Resistance to CLI interfaces tends to decrease as users become more expert"——高频使用者会跨过 crossover point，此后简练与表达力变得比省记忆更值钱。问题规模一大（"fetch and save the pages corresponding to a given list of fifty URLs"），天平就向 CLI 倾斜。Mike Lesk 的抱怨至今通用："他们没法对一百或一千个文件做同一件事；我想写脚本，但没有任何支持。"

（6）最少惊讶规则的操作化（ch11s01）："Do the least surprising thing"——因为人的注意力只有一个焦点，接口上的惊讶会把注意力从任务本身夺走。具体策略："只要可能，允许用户把接口功能委派给熟悉的程序"（用 $EDITOR 而非内嵌编辑器），以及"委派不了就模仿"（When you can't delegate, emulate——实现子集也要用众所周知的命令集）。"新奇是进入的门槛；它把学习负担压在用户身上，所以要把它最小化。"

（7）配置的五个位置与生命周期律（ch10s02）：经典 Unix 程序启动时按序查五处——/etc run-control → 系统环境变量 → 用户主目录 dotfile → 用户环境变量 → 命令行开关，"后（更局部）的设置覆盖先（更全局）的"。选哪种机制的判据是偏好数据的预期生命周期："在每次调用之间很可能变化的偏好，用命令行开关；很少变但应归个人控制的，用主目录的 run-control 文件；需要站点级设定而不许用户改的，放系统空间。"（clig 2021 版给出同构的优先级表：Flags > 环境变量 > 项目级 .env > 用户级 > 系统级。）

（8）run-control 语法规则（ch10s03）：支持 # 注释；"不做阴险的空白区分"——元规则是"文件的解释不应依赖人眼看不见的区别"；把连续空行/注释行当一行；词法上做简单的空白分隔 token；引号与反斜杠转义照 C 惯例。.netrc 案例的评语直指要害：透明性"节约的是远比机器时间宝贵的人力资源——让人不需要读手册、用普通文本编辑器就能读懂并修改"。

（9）接口设计模式库（ch11s06–07）：filter / cantrip / source / sink / compiler / ed / roguelike，以及"分离引擎与接口"（"这大概是 Unix 最具特色的接口设计模式"）、configurator/actor、spooler/daemon、driver/engine、client/server、CLI server、语言式接口，最后是 polyvalent program（核心逻辑做成有文档 API 的库 + CLI/GUI/脚本三种薄壳）。应用总则是 ch11s07 的第一句话："为了便于脚本化和管道化，明智的做法是选择尽可能简单的接口模式——即通往环境的通道最少、交互性最低的那种。"对 cantrip 模式的忠告尤其适合个人脚本："Unix 设计者学会抵抗诱惑，在 cantrip 就够时不去写更交互的程序……好的风格要求你先努力为工具找到 cantrip 设计，再屈服于写交互界面的诱惑。"filter 设计另有三条细则：宽进严出（Postel）；"过滤时，永远不要丢弃你用不着的信息"；"过滤时，永远不要添加噪声"——日期默认用 ISO8601。

（10）clig 的 2021 年修正案（对读书）：①定位变了——"过去的命令行是机器优先的……今天的命令行是人类优先的：一个基于文本的 UI"；②Rule of Silence 被软化为"Display output on success, but keep it brief"——"完全什么都不打印很少是最好的默认行为，但通常宁可偏少"；③新事实——"无论你在写什么软件，都可以百分百确定：人们会以你没预料到的方式使用它。你的软件*必将成为*更大系统中的一个零件——你唯一能选的，是做一个行为良好的零件"；④工程细则：stdout 出数据 / stderr 出消息、退出码 0/非零、--json、--plain、NO_COLOR、进度条、超时可配置、crash-only、XDG 配置目录。

3. 方法

4. 数据与证据

（1）书内证据形态：定性案例 + 当事人引语，无量化对照实验。最有力的一段引语是 Ken Thompson 的："One of my most productive days was throwing away 1000 lines of code."（我最有生产力的日子之一，是扔掉 1000 行代码的那天。）配套的还有 Kernighan & Plauger 的"90% of the functionality delivered now is better than 100% of it delivered never"与 Knuth 的"Premature optimization is the root of all evil"（ch01s06）。书内也有自我修正的痕迹：Postel 的宽进严出后面紧跟着 McIlroy 的反向警告——"The original HTML documents recommended 'be generous in what you accept', and it has bedeviled us ever since… It is the *specifications* that should be generous, not their interpretation."（慷慨应该在规范里，而不是实现里。）

（2）跨时代印证：clig（2021）全文几乎逐条接续书的规则，并在 Output 一节直接引用 McIlroy 原话；其"future-proofing"一节把书的 Rule of Extensibility 换算成现代约束："Subcommands, arguments, flags, configuration files, environment variables: these are all interfaces, and you're committing to keeping them working."（子命令、参数、旗标、配置文件、环境变量——这些全是接口，你都在承诺让它们持续可用。）这证明书中"接口即承诺"的思想在 18 年后仍是 CLI 社区的操作共识。

（3）本地复验（2026-11-05 实跑，Git Bash on Windows）——验证书中的约定在当前主流工具里仍是硬通货：

检查命令输出印证的规则
退出码约定true; echo $?exit=0clig"成功返回 0"；脚本可据此判断成败
失败要出声ls /definitely-not-here-12345; echo exit=$?ls: cannot access … No such file or directory + exit=2Rule of Repair（fail noisily, ASAP）
流分离ls /definitely-not-here-12345 2>/dev/nullstdout 干净、错误只在 stderr、exit=2Rule of Silence 的管道前提：数据与消息分道
帮助约定rg --help | head -4ripgrep 15.1.0 (rev af60c2de9d) + 用法正文discoverability / ch11s05"直观 = 可发现 + 透明 + 最少惊讶"
机器可读输出rg --json "def " extract_html.py | head -2逐行 JSON（{"type":"match","data":{…,"line_number":5,…}}）ch11s06 filter 细则 + clig --json 约定

（4）充分性评估：作为"原则仍然有效"的论证，证据链是充分的（一手文献 + 当事人引语 + 两代从业者共识 + 本机可复现）；作为"原则最优"的论证则不充分——书里没有任何受控对照或量化比较，这一点两代作者都不讳言。

5. 结论

  1. 仍然有效的硬核（2003 → 2026 基本未动摇）：一做一并（one thing well + 可组合）、文本流作为通用接口、接口五指标、最少惊讶、按生命周期放配置、透明性先于聪明、失败要早要响、先原型后优化、"扔代码"是最强优化、把知识折进数据、为未来留版本与扩展缝。
  2. 需要修正的（对照 clig）：Rule of Silence 从"成功时一言不发"修正为"简短报告，宁少勿多"；机器优先修正为人类优先；Postel 宽进在输入边界修正为"尽早校验、尽早退出"（clig："Check early and bail out before anything happens"），慷慨留给规范而不是解析器；dotfile 约定修正为 XDG ~/.config；--json/--plain/NO_COLOR/超时是文本流哲学在结构化数据时代的补丁而非背叛。
  3. 对个人工具的总结论：这 17 条里对单人场景最值钱的不是"怎么做大系统"，而是把半年后的自己当作陌生用户来设计——书末原话："You'll be there in the future too, maintaining code you may have half forgotten… When you design for the future, the sanity you save may be your own."

6. 局限

7. 对我的启发（落到 nightshift 与个人脚本）

  1. nightshift 管线本身就是一条 Unix 文本管线：notes/*.md + matrix.csv 全是纯文本、可 grep、可 diff、可被下一个未知程序消费——这正是 McIlroy 第 (ii) 条的活体实现；本条笔记的命名协议（日期 + 唯一前缀 knowledge-d2f37j93-4）就是 Rule of Extensibility 里"永远带版本号"的落地形态，维护它。
  2. 写脚本先找 cantrip/filter 形态：参数进、数据出、exit code 汇报成败；把交互需求包成外层薄壳（ch11s06：cantrip 够用就不要交互式）。逐条对照我刚写的 extract_html.py：无交互、文件参数进、文本出——形态正确，但没做 exit code 和 stderr 纪律（异常直接 traceback 到 stderr 也罢，但成功时静默、失败时信息量不足），下一步给它补 try/except → stderr 消息 + exit 2。
  3. 流纪律：数据 → stdout，进度/警告 → stderr；长任务先在 100ms 内打印点东西（clig："Responsive is more important than fast"）；成功输出宁少勿多，配 -q/--verbose 旋钮；颜色尊重 NO_COLOR 与非 TTY。
  4. 配置三放：每次变 → flag；跨会话不变的个人偏好 → 用户级配置（现代对应 XDG ~/.config，Windows 对应 %APPDATA%/$PROFILE）；项目级 → 进版本控制的文件（如 Makefile/package.json）。避免把任何一层的值硬编码进脚本。
  5. 把知识折进数据：文件名编码日期与前缀、markdown 头部字段化、CSV 带列头、日期一律 ISO8601——"program logic can be stupid and robust"，让明天的脚本能蠢而稳地解析今天的文件。
  6. Engine/interface 分离的个人版：核心逻辑写成可导入的库函数，CLI 只是薄壳；这样 workflow 编排层（比如本会话所在的动态工作流脚本）可以直接 import 复用，而不必去解析人类输出。
  7. 对 agent 时代的再发现：clig"对话即常态"（"The user is conversing with your software, whether you intended it or not"）在 LLM agent 场景被放大——exit code、stdout/stderr 分离、--json 恰好是 agent 判断成败所需的全套读数。个人脚本做好这几件事，就自动获得了"可被 agent 驱动"的属性，无需另写适配。
  8. 最强优化是 delete key：个人工具最容易犯的不是性能错，而是为想象中的需求堆积复杂度。Thompson 的 1000 行 + Kernighan 的 90% now——先让今晚的管线跑通，别为"以后可能要"预先搭架子（Rule of Extensibility 明说这不是加用不上的功能，是"让以后加的时候容易"）。
  9. 两条元教训：①规则是经验归纳，冲突时回到五指标和用户（自己）的实际成本函数仲裁，别把任何一条当教条（Rule of Diversity）；②"interfaces are commitments"——给我自己的脚本起名字、定参数、定输出格式时，默认它会被半年后的我或某个 workflow 无限期依赖，改格式要走"新增不改旧"的 additive 路线。

二、原文引述精选（均已在来源页面核对）

McIlroy 纲领（ch01s06）

"Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
"(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information."

复杂度与健壮性（ch01s06）

"The only way to write complex software that won't fall on its face is to hold its global complexity down — to build it out of simple parts connected by well-defined interfaces, so that most problems are local and you can have some hope of upgrading a part without breaking the whole."
"Bugs often lurk in the code for handling special cases, and in the interactions among parts of the code intended to handle different special cases."
"Text streams are to Unix tools as messages are to objects in an object-oriented setting."

Postel 与其警告（ch01s06）

"Be liberal in what you accept, and conservative in what you send."
— Doug McIlroy 反向警告："It is the *specifications* that should be generous, not their interpretation."

原型与优化（ch01s06）

"90% of the functionality delivered now is better than 100% of it delivered never."（Kernighan & Plauger）
"Premature optimization is the root of all evil."（Knuth）
"One of my most productive days was throwing away 1000 lines of code."（Ken Thompson）

未来与维护者（ch01s06，Rule of Extensibility 结尾）

"You'll be there in the future too, maintaining code you may have half forgotten under the press of more recent projects. When you design for the future, the sanity you save may be your own."

一句话总纲（ch01s07）

"All the philosophy really boils down to one iron law, the hallowed 'KISS principle' of master engineers everywhere."

配置生命周期律（ch10s02）

"For preferences which are very likely to change between invocations, use command-line switches. For preferences which change seldom, but that should be under individual user control, use a run-control file in the user's home directory."

run-control 元规则（ch10s03）

"The metarule is that the interpretation of the file should not depend on distinctions a human eye can't see."

.netrc 评语（ch10s03）

"It economizes the far more valuable resource that is human time, by making it likely that a human being will be able to read and modify the format without having to read a manual or use a tool less familiar than a plain old text editor."

最少惊讶（ch11s01）

"Novelty is a barrier to entry; it puts a learning burden on the user, so minimize it."
"Wherever possible, allow the user to delegate interface functions to a familiar program."
"When you can't delegate, emulate."

脚本化的价值（ch11s03）

"Unix programmers, administrators, and users develop a habit of thinking through the routine procedures they use, then packaging them so they no longer have to manually execute or even think about them any more… It is a quiet but tremendous productivity booster not available in most other software environments."

GUI 的暗面（ch11s04，引 Gentner & Nielsen《The Anti-Mac Interface》）

"As the number of actions or objects increases, direct manipulation quickly becomes repetitive drudgery… Instead of an executive who gives high-level instructions, the user is reduced to an assembly-line worker who must carry out the same task over and over."

"直观"的分解（ch11s05）

"When people say a user interface is *intuitive*, what they mean is that it (a) is discoverable, (b) is transparent in use, and (c) obeys the Rule of Least Surprise."

模式选择总则（ch11s07）

"To facilitate scripting and pipelining… it is wise to choose the simplest interface pattern possible — that is, the pattern with the fewest channels to the environment and the least interactivity."

cantrip 忠告（ch11s06）

"Good style therefore demands that you try to find a cantrip design for your tool before giving in to the temptation to write an interactive interface that will be harder to script."

filter 三细则（ch11s06）

"Be generous in what you accept, rigorous in what you emit."
"When filtering, never throw away information you don't need to."
"When filtering, never add noise."

引擎/接口分离（ch11s06，引 Owen Taylor）

"[T]he secure setuid program is a 500 line program that does only what it needs to, rather than a 500,000 line library whose essential task is user interfaces."

clig 对读（2021）

"A core tenet of the original UNIX philosophy is the idea that small, simple programs with clean interfaces can be combined to build larger systems."（clig · Philosophy）
"Today's command line is *human-first*: a text-based UI that affords access to all kinds of tools, systems and platforms."（clig · Foreword）
"Your software *will* become a part in a larger system—your only choice is over whether it will be a well-behaved part."（clig · Philosophy）
"Humans come first, machines second."（clig · Output）
"It's rare that printing nothing at all is the best default behavior, but it's usually best to err on the side of less."（clig · Output）
"The user is conversing with your software, whether you intended it or not."（clig · Conversation as the norm）
"Subcommands, arguments, flags, configuration files, environment variables: these are all interfaces, and you're committing to keeping them working."（clig · Future-proofing）
"Abandon a standard when it is demonstrably harmful to productivity or user satisfaction."（Jef Raskin，clig · Chaos 引）

三、个人 CLI/脚本落地清单（本笔记的操作产出）

#清单项出处
1优先把工具做成 cantrip 或 filter：无交互、文件/stdin 进、stdout 出、exit code 汇报ch11s06/07
2数据走 stdout，进度/警告/错误走 stderr；成功时输出简短（宁少勿多），留 -q/--verbosech01s06 Rule of Silence + clig Output 修正
3失败尽早、出声、带可行动信息；退出码 0/非零并区分主要失败模式ch01s06 Rule of Repair + clig Basics/Errors
4配置按生命周期三放：flag（每次变）/ 用户级配置文件（少变）/ 版本控制内项目文件（项目稳定）ch10s02 + clig Configuration
5文件格式自描述且可扩展：头部字段、列头、ISO8601 日期、版本号或自包含子句ch01s06 Rule of Extensibility + ch11s06 filter 细则
6输出不丢信息、不加噪声；需要人类可读装饰时给 --plain/--json 逃生门ch11s06 + clig Output
7颜色/动画尊重 NO_COLOR 与非 TTY；给下游程序干净的默认clig Output
8核心逻辑库化、CLI 薄壳；参数与输出一旦发布即承诺，改动走 additivech11s06 separated engine/interface + clig Future-proofing
9委派优先（$EDITOR、已有工具），委派不了就模仿知名约定ch11s01
10先原型后优化；删除代码是最强优化；防"特例滋生 bug"ch01s06 Optimization/Robustness

四、检索与验证过程记录

← 资料库今日播报 →