最近很忙，写的很慢。写这个比做项目和教程难多了。
然后如果想看实操可以看 【木子狸的指北指南】01 Octopus 的部署与使用 系列。
前两篇随笔，聊了“贵族专制”——即作开发者对架构的绝对主权，也聊了“拒绝的艺术”——即学会对 AI 生成的代码说不。这次讲讲优雅的代码。也算是如何进行具体实现。不过也是原理方向的，不会在此系列做具体的详细项目过程。
问题
代码的维护，在 AI 时代越发困难。正如我在 【木子狸的Vibe Coding随笔】序——既是草稿，也是成品 中谈到，当我们在某一时刻试图修改/添加一个微小的逻辑时，修改的代码便会，牵一发而动全身。这是我们为什么需要约束，同时需要优雅的代码。
优雅只是为了保证产品和你自身的生存。
管道与原子工具
“让每个程序就做好一件事。如果有新任务，就重新开始，不要往原程序中加入新功能而搞得复杂。”
Unix/Linux 中，ls 用于列出文件，grep用于查找文本，wc用于计数，每个命令有着自己专门负责的功能。单独看可能很简单，但是像搭积木一样的管道组合能带来无穷的威力。
现状
我们在 Vibe Coding 的时候都有一种通病——贪婪。我们希望有比没有好。我们往往会给出一个宏大的提示词。比如“帮我写一个贪吃蛇游戏，要有积分系统，要有排行榜，要能换皮肤，还要适配移动端。”
你要 AI 就给。 AI 一次性负责了逻辑，交互，适配，架构。试图在有限的上下文中，满足我们无限的欲望。
这一行为产生的代码，在《代码整洁之道》中，被称为“上帝对象”——一种承担了过多责任，规模过大的代码。这种代码违反了单一责任原则。你可以将其看作一个眼不见心不烦的抽屉，将所有东西都扔进去。
在 Vibe Coding 中，除非你完全不在乎可维护性，同时坚信模型能力的提升速度能超过你出现问题的速度。不然一旦逻辑出错，AI 生成的黑盒代码会使人无从下手。
解决？
一个优雅的软件是可以拆分为各种更小的原子化工具的。也就是说模块化的，它要求每个部分都足够简单，力求一眼看穿。
所以我们得强迫 AI 遵循这种物理层面的约束。 比如：
- 工具 A： 只负责计算坐标的“纯逻辑函数”。它不关心屏幕长什么样，只负责
(x, y) + direction = new (x, y)。 - 工具 B： 只负责把一组坐标数组“映射”成 Canvas 像素。它不关心游戏逻辑，只负责画框。
- 工具 C： 只负责监听键盘并把按键翻译成“方向信号”。
这种优雅，本质上是对复杂性的分而治之。
文本
“期待每个程序的输出都会成为另一个程序的输入… 弃用二进制格式，文本流才是一切。”
这个想法和我的 【木子狸的随机思考】01 狸OS 不谋而合。在 Unix 的管道里，无论 ls 还是 grep，它们之间交流的语言永远是简单的、直观的文本。
现在 Markdown 也是好起来了，让不怎么接触的人也用上了。这种格式真的算是 AI 的宝藏，方便人进行操作，也方便 AI 读取。
现在我的 狸OS 便是使用了 Markdown 进行了构建，结合自己写的 CLI 用于操作汇总整合。我能看见我做了什么，AI 做了什么，脚本做了什么。我给 AI 了一个专门记录的 Markdown，用于记录我让 AI 干了什么，遇见了什么问题，我和 AI 是一起怎么解决的。
我让 AI 输出 JSON 格式，然后调用我的 CLI，使用规范的脚本和JSON数据，对 Markdown 进行可复现的增删改查，而非 AI 直接读取然后输出。
机制与策略
“策略同机制分离，接口同引擎分离。”
简单来说，机制（Mechanism）是“怎么做”，策略（Policy）是“做什么”。
- AI 擅长机制：它知道怎么调 API、怎么写循环、怎么做正向或反向的算法。
- 而我们必须掌控策略：业务逻辑该怎么走，什么时候该报错，什么时候该跳过。
最平庸的代码，是把策略硬编码在机制里。比如 AI 写的发送邮件功能，里面混杂了“只有 VIP 才能发”的判断。 优雅的做法是： 让 AI 造一个纯粹的、没有任何主见的“发送功能”（机制），而“谁能发、什么时候发”的规则（策略）由我们通过配置文件或简单的逻辑注入。
我们的策略决定了工具使用的方向——当机制足够纯粹时，用户就能通过组合创造出开发者意想不到的用法。这也是 Vim 等工具能被用户玩出花的原因：它们提供了足够优雅的机制，没有限制用户的策略。
最近也是越来越喜欢 CLI/TUI 这种工具了。
也是个千字小短篇
来交流啊，随时问我都行。思考是在交流反驳中相互印证的。
