做一期播客，最耗时间的往往不是说话。录音软件要启动，音视频要剪好，五个平台各有各的上传流程，网站还需要一份可检索的文字稿。这些环节里没有一行代码，过去每一件都要人去点。
这是一期节目从录制到发布走过的实际路径。需要先说明的是，它是一次回顾性的经验整理，不是一份操作教程：工具、界面和平台的规则都在变化，单个案例也不构成可复现的配方。它能说明的是，Computer Use 补上了哪些环节，又把什么留给了人。
写代码之外的环节，过去全靠人点
Agent 进入日常工作后，写代码这件事本身已经高度自动化，问题出在前后两端：录制要打开本地软件，发布要操作一堆不熟悉的后台。这些步骤无法通过写代码完成，只能停下当前任务，切换成人工操作。流程被打断的时间，几乎全部消耗在这里。
一次实际的做法是直接把电脑交给 Codex：启动录音软件这样的事，不再自己研究菜单在哪里，而是由 Agent 去移动鼠标、点击完成。剪辑同理——图形界面的剪辑软件用不顺手时，改用 FFmpeg 的命令行处理，反而落回 Agent 本来就擅长的工作方式。同一批体验里，还有人把两个 iOS 应用和 Obsidian 插件的上架资料逐项提交，全部交给 Agent 完成，自己只做验收。
这类委托的价值在于取消切换。任务不再因为“这一步不是代码”而中断，人也不必为每个软件重新学一遍操作。
五个平台，一次发布
第一期节目要上五个平台：小宇宙、B 站、Spotify、Apple Podcast 和 YouTube。负责发布的人此前没有用过其中任何一个平台的创作者后台，也没有逐一研究各平台的功能差异，只提出需求、准备素材，上传和填写由 Agent 完成。
这种做法改变的不只是时间。一个人维护五个平台，过去意味着五套各自的手续；每接入一个新平台，成本都会再涨一次。当操作本身可以委托，平台数量就不再直接等于工作量，选择上哪些平台时可以更多考虑受众，而不是操作成本。
值得注意的是成本结构的另一面。这次发布和网站搭建，用的是当期刚发布的新模型——单价更贵，但试错的次数明显减少，一次就做对的概率更高，总的开销反而可控。模型省下的 Token 和省下的人时，最终是同一件事。
网站与可检索的文字稿
发布之外，网站承担了另一部分工作。每段文字稿带稳定的锚点，文本里出现的关键词可以点击、聚合到同一个标签下，听众从任何一段话都能回溯到出处。这类功能在通用播客产品里并不常见，定制开发的门槛过去很难跨过；这一次，网站连同发布一起被列进了同一份委托列表。
对一期播客来说，可检索的文字稿意味着内容可以被单独引用。文章讨论某段对话时，可以直接链接到确切的段落，而不是笼统地指向一期节目——本文末尾的链接就是这种用法。
一次没有答案的限流
流程也不是全都顺利。五个平台都发布成功，其中一个平台在用 Agent 发布之后出现了限流。原因没有核实过：可能是对内容的判断，可能是对发布方式的识别，也可能与自动化操作无关。把限流直接归因于自动发布，目前只是当事人的一种猜测，不能写成平台确认的处罚原因。
这次经历引出的讨论倒是值得记下：如果平台要抵制低质内容，针对内容本身审查，比针对发布动作审查更合理——同样的几个真人录的节目，不会因为发布方式不同就变成低质内容。这仍是一种主张，不是对任何平台规则的描述。
人还剩下什么
回顾整条链路，人保留的位置有三处：决定做什么内容、准备和把关素材、对最终结果验收。发布到哪些平台、以什么顺序、要不要发，都由人授权。Agent 负责的，是授权之后从启动软件到点击提交的全部动作。
这份经验的样本只有一期节目和一位操作者，结论应该停在个案的范围内。它能说明的是：当写代码之外的操作也可以委托，流程中最耗人的部分从“操作”转移到“决定”。至于哪些平台会长期接受这种方式、不同类型的节目还能省下多少时间，都还需要更多期数来回答。