这周我把一条惦记了很久的工作流，终于磨到了接近 0 摩擦。
它表面上只是一个很普通的自动化问题：把 Plaud 录音拉到电脑，传到腾讯会议转写，再把文字稿接进后续总结和蒸馏链路。真拆开看，也就四步。
- 下载录音
- 上传转写
- 取回文字稿
- 进入总结和蒸馏
但就是这四步，我前前后后折腾了快一年，尝试次数不下 10 次，直到这周才真正跑顺。
所以这篇文章我真正想讲的，不是“我又做了个自动化”。而是另一件事：很多工作流之所以一直卡着，不是因为其中某一步不会写，而是因为你看问题的方式还没变。
这条链路为什么一直值得折腾
去年六七月，受鸭哥“赛博人生计划”的启发，我开始系统采集自己的日常信息。那时候“蒸馏”这个词还没像今天这么流行，但我已经在想一件事：能不能把每天真实发生的会议、对话、决策、卡点，持续沉淀成一个可用的 context 系统。
所以我买了 Plaud。因为平时会很多，我每天录音时长大多在 12 小时以上。
真正的难点从来都不在采集，而在后处理。每天十几个小时的录音，如果不能稳定转成文字、再稳定进入后续总结，它就只是另一种形式的“数据囤积”。
腾讯会议在这里很关键。它提供了一个相对稳定、而且几乎免费的转写入口。否则按我这个体量，真去按 API 成本硬算，根本不现实。
所以，这件事对我来说从一开始就不是一个可有可无的小优化，而是一条必须跑通的基础设施。
我经历了三个阶段
第一阶段：每天手工搞 1 小时
刚开始做这件事时，其实还挺兴奋。每天专门拿出 1 个小时，手工从 Plaud 下载录音，再上传到腾讯会议，等转写，最后把文字稿扔给 Gemini 做当日总结。
那个阶段只有 Gemini 顶得住。因为这么大体量的文字稿，别的模型上下文窗口都不太行。
那时候我的感觉是：虽然笨，但至少已经跑起来了。
第二阶段：改成每周集中处理，摩擦反而更大
后来我把节奏改成每周五集中处理一次。表面看像是优化，实际上摩擦更大了。
原因很简单。每天 12 小时大约会有 3 个文件，7 天就是 21 个文件。下载、上传、等待、盯状态，全都被批量放大。这个时候你会发现，批量处理带来的不是效率，而是更强的中断感。
我那时候试过浏览器 MCP，也试过 AI 浏览器。Comet 确实算其中最好用的一个，但还是不够稳。只要某个文件要下载 20 分钟，中间一断，就得人工接回去。
于是这条链路一直没法真正收口。只是后半段的“复盘总结”开始逐渐交给 Cursor 和 Claude Code 去做了。
第三阶段：这次终于做到接近 0 摩擦
这次真正完成的，不是某个脚本终于写对了，而是整条链路第一次作为系统跑通了。
Plaud 自动下载，自动保存，自动上传，等待转录，自动下载文字稿，自动总结，然后进入蒸馏序列。全程几乎不需要我介入。
做到这一步以后，我回头看才发现，真正关键的不是代码量，也不是自动化步骤数，而是背后有几件事情终于同时成熟了。
最后让我过关的，是四个变化
第一，基础设施终于到位了
如果没有一台 24 小时在线、登录态稳定、任务能持续跑的 Mac mini，这件事其实很难真正落地。很多自动化任务早期做不成，不是逻辑不对，而是运行环境一直停留在 demo 条件里。
我后来越来越觉得，所谓“把工作流做成系统”，第一步往往不是去补逻辑，而是先把基础设施补齐。机器常驻、状态持久、任务不断线，这些听起来都不是主角，但它们决定了你最后拿到的是脚本，还是基础设施。
第二，工具终于变得更适合被 AI 调用了
过去一年里，工具层本身也成熟了很多。无论是 Playwright，还是 Chrome 系列工具，对登录态保存、页面交互、长链路等待的支持，都比之前稳了不少。
很多人会把“过去没做成”解释成“自己不会做”。但不少时候，真相只是那一层工具能力当时还没成熟。时机没到，硬上只会把自己折腾得更烦。
第三，我开始从“工程解”转向“AI 解”
这是对我影响最大的一点。
我以前处理这种自动化问题，默认都是先按工程思路拆。脚本怎么写，状态怎么管，流程怎么控，异常怎么兜。这个思路当然没错，但它会天然把 AI 放在一个“辅助工具”的位置。
后来受到鸭哥一些实践和我自己在 OpenCode client 上尝试的影响，我开始换一个问题来想：
这个系统的核心控制面，到底应该是脚本，还是 Agent？
这个问题一变，设计空间就完全变了。后面我直接选了 OpenCode server 这条路，很多原来卡住的地方，一下就顺了。
所以我现在对这件事的判断很明确：AI+工程，和 工程+AI，真不是一回事。 顺序一换，系统中心就换了。
第四，我对 skill 的理解也变了
这次 workflow 跑通时，我顺手也在测试对应的 skill。中间当然还是有卡点。按我以前的习惯，我会立刻去问：“要不要针对这些卡点再补几条更强的约束？”
但这次我反而更确信另一件事：skill 的核心不是把 SOP 写满，而是围绕目标给 Agent 足够好的自由度和边界。
你如果每遇到一个局部问题，就往 skill 里加一条规则、补一个分支、再叠一层限制，短期看像是在修复，长期看其实是在把能力写死。最后 skill 会越来越重，越来越像流程图，而不是能力。
这次的结果说明，目标型的 skill 已经够用了。真正重要的是目标清楚、边界清楚，不是 SOP 无限加厚。
这件事真正重要的，不只是省掉 1 小时
如果只从“省时间”角度看，这条工作流的意义其实没那么大。真正重要的是，我重新确认了一件事：每日信息不能按周整理。
因为 context 是有时效性的。你这周真正在关注什么，卡在哪里，外部环境给了什么反馈，这些信号都在实时变化。隔一周再回头整理，归档也许还行，但蒸馏质量一定会掉。
所以我现在越来越相信，context infra 这套东西，不只是个人知识管理的问题。放到企业里也是一样。一个人的 context，不该只来自他和 AI 的 session 日志，还应该尽量贴近他的真实运行态。企业里的 context 构建，也不能只停留在文档层、汇报层、流程层，而应该更接近运行现场。
这也是为什么，这次工作流真的跑顺以后，我的第一感受不是“终于省了 1 小时”，而是“终于把一条真实世界里的 context 采集链路做成了基础设施”。
最后的判断
回头看，这件事能在这周真正落地，不是因为某一个脚本突然变神了，也不是因为某一个工具突然无所不能。它更像几个条件终于同时汇合了：
- 基础设施成熟了
- 工具能力成熟了
- 我自己的认知也变了
- 社区里已经有人把一些方向先跑出来了
这些条件少一个，可能都到不了今天这一步。
所以如果你手上也有一条反复折腾、总觉得“明明不复杂，怎么就是跑不顺”的工作流，我现在的建议不是立刻再补一个脚本，而是先问一句：
你缺的，到底是代码，还是基础设施；是工具，还是认知；是一个自动化步骤，还是整个系统的控制面。
很多问题，一旦问对了，答案会比你想象中来得快很多。