1. 背景与连接

桌面上的音频系统是 Mac Studio、魅蓝 HD2 小尾巴，加一对漫步者 S3000MKII 书架音箱。

graph LR
    A["Mac Studio"] -->|Type-C| B["魅蓝 HD2 小尾巴"]
    B -->|"4.4mm 平衡输出"| C["4.4mm 转双 XLR 平衡线"]
    C -->|"XLR 左 / 右"| D["主箱 XLR 接口"]
    D -.->|"蓝牙"| E["副箱"]

Mac Studio 自带的 3.5mm 耳机孔也能出声，但和小尾巴差别不小：

• 设备定位：小尾巴是外置解码耳放；Mac Studio 内置的是一块集成音频接口。
• 音频芯片：小尾巴用双 CS43131 独立 DAC 芯片；Mac Studio 用苹果自研的集成音频 Codec。
• 输出接口：小尾巴有 4.4mm 平衡口和 3.5mm 单端；Mac Studio 只有 3.5mm 单端，支持高阻抗耳机自适应。
• 最高采样率：小尾巴支持 PCM 384kHz/32bit 和 DSD 256；Mac Studio 最高 PCM 96kHz/24bit。
• 抗干扰：小尾巴电路独立，供电和传输都在机箱外；Mac Studio 的耳机口在机箱内部，容易受主板和固态硬盘的高频信号影响。

对于 S3000MKII 音响，小尾巴比 Mac Studio 的耳机口更合适的地方有三处：

1. 概览

AI Coding 的关键是让模型在正确时间拿到正确上下文。
把散在文档、聊天记录、邮件和成员脑子里的细节归拢到一处，让模型按需使用。
这样才能早日实现 one-shot 开发( 许愿式开发 / 一句话需求 )。

这份指南覆盖四个阶段：

• 新项目：搭上下文底座。
• 老项目：补齐代码读不出的约束。
• 日常需求：沉淀和复用上下文。
• 团队：把方法变成可维护的工程约束。

适合正在用 Coding Agent 的工程师和技术负责人。全文偏操作。
新项目从第 2 节读起，老项目从第 3 节读起，日常需求看第 4 节，团队推广看第 5 节，长期维护看第 6 节。

先从 Agent 的入口文件开始。
AGENTS.md ( Agent 主流入口，cc 也支持了 )是 Agent 的地图，只回答「去哪里找」和「什么时候看」：

短信不算笔记，但同样是散在外面的一份记录。既然要把这些东西收敛到本地，便签之外顺手把它也拿下来。脚本在 GitHub 上：phone-cloud-data-export/flyme-sms。

魅族云的短信备份页面还在，地址 cloud.flyme.cn/browser/sms-list.jsp。我账号里 1595 个会话、7600 条消息，最早一条是 2007 年，最后一条停在 2022 年初。

网页版没有批量导出，只能一页页翻。这篇和魅族云便签、锤子便签是同一批，都用浏览器里跑脚本的办法把数据拿下来，再在本地转成 CSV 和 Markdown。

笔记散在好几个地方，魅族便签是攒得最多的一处。这轮的打算是把它们收敛到本地一个目录，来龙去脉写在锤子便签那篇里。脚本在 GitHub 上：phone-cloud-data-export/flyme-notes。

魅族云便签的网页版在 notes.flyme.cn。我账号里 605 条笔记，时间从 2014 年排到 2022 年，多数是当年在地铁上用手机随手记的。

这套导出也分两步：先在已经登录的页面里跑脚本抓原始 JSON，再在本地转成带 frontmatter 的 Markdown。Cookie 不出本机。

我的笔记一直散着。读书时记的放锤子便签，通勤路上随手写的放魅族便签，早年还有有道云笔记和 Notion。时间一长，自己都说不清哪条在哪儿，搜也搜不全。知识管理与消费里问过一句，散落各处的笔记、随想能不能有个地方统一管起来；工作的第一个十年里也提过，说想把所有数据整合到一起。

想把它们收敛到本地一个目录、用自己的方式管起来，就得先把每个来源的数据拿下来。锤子便签是其中一份，另外两份是魅族云便签和魅族云短信。脚本都开在 GitHub 上：phone-cloud-data-export/smartisan-notes，拿到就能跑。

锤子便签的云端在欢喜云 yun.smartisan.com。手机端早就停更，账号中心跳去了 snote.ink，那是字节接手后的另一套产品，和原来的便签不是同一份数据。

我账号里还有 370 条便签挂在旧接口上。产品在收缩，接口没有退场说明，能拿的时候先拿。导出分两步：抓原始 JSON，再转成带 frontmatter 的 Markdown。

DHH 在 Rails World 2026 上说，37signals 已经不再把手写代码当成正常业务。八个多月前，也就是 2026 年 1 月，他还在文章里写，自己做不到 90% 以上代码由 agent 写。

他现在维护 Omarchy，一个把 agent 接到系统里的 Linux 发行版。

我写过《AI 替代的是任务，不是程序员》，那篇讲被替代的是什么。这篇讲另一半：外包之后，资深工程师和架构师该留下什么。

具体实现和重复的操作可以交给 AI。质量、安全、合规和长期系统不行。架构师的新职责是决定哪些地方永远不能交出去。

程序员会不会被 AI 取代，这个问题被反复问了好几年。真到了日常的工作里，被替掉的是一部分任务：样板代码、重复修复、机械实现。审查、验收和判断留了下来，它们的成本并没有下降。

软件工程攒了几十年的实践，比如完整的回归测试、跟随代码演进的文档、清晰的模块边界和性能基准，一直没有真正普及。它们对人力的消耗太大，有交付压力时总是先被砍掉。AI 把执行成本降下来之后，这些实践第一次变得划算。

1. 概览

最近刷到一个视频，《怎么奴役一千人》。
视频的设定很简单：把一千个人放到一座与世隔绝的岛上，没有政府，也没有历史留下的权威，然后问一个问题，怎么让这一千个人长期服从一个人。
真正吸引我的是那座孤岛。现实里的统治变量太多，看不清哪一条在起作用。
把规模压到一千人，把外部世界拿掉，剩下的就是结构本身。

看完我有两个疑问：

• 这套东西有哪些零件，能不能拆成一套可以对照的框架；
• 它为什么在历史上总是短命，明明每一步看上去都有效。

现实世界也有不少这类事情，特别是退出成本高的领域。国家层面也有，比如 国家为什么失败。

1. 起因：一条视频

前阵子刷到一条视频，《大灭绝时代的生存指南：塔勒布思想述评》，讲纳西姆·塔勒布。
这条视频把《随机漫步的傻瓜》《黑天鹅》《反脆弱》《非对称风险》串成一条线，中间还补了休谟的归纳问题、演化论里的间断平衡，以及塔勒布本人在黎巴嫩内战的经历。

看完的第一感觉是：讲的人逻辑清晰。
在这之前我读过《随机漫步的傻瓜》，当时留下的印象是，大部分人做金融，判断水平和猴子扔飞镖差不多。

那为什么搞金融的人会推崇塔勒布，他有什么优点，怎么去深入了解不确定性？

推特网友@dontbesilent 说：
过去十年最重要决定，就是从北京到了广东
随着时间推移，这个决定的影响会越来越大
Paul Graham，城市与雄心（2008）

于是我把 Paul Graham 2008 年的《城市与抱负》翻出来读了一遍。
这篇文章讲的是城市怎么影响人，读的时候，也想起来自己的几段经历。