Vibe-Coding an Attention 深度访谈

主持人在开场中介绍 Steve Newman 的背景：他是资深软件工程师，曾创建 Writely，后被 Google 收购并演变为 Google Docs；如今则负责 Golden Gate Institute for AI、Curve 大会以及 Second Thoughts 专栏。主持人说明，这次访谈虽然也会谈到智能爆炸、机器人和气候等宏观 AI 问题，但主体其实是一次“show-and-tell”，即 Steve 个人 AI 工具箱和编码实践的拆解。主持人还解释了自己为何想做这期节目：他已搭建了基于 Claude Code 的个人生产力栈，但仍希望从一位自 1985 年起就持续编程的老牌工程师身上，学习更成熟的工作流设计方式。

Steve 解释说，自己目前的大部分构建都不是机构正式业务，而是晚上和周末推进的个人工具项目，总数大约有 15 个，几乎都属于“个人生产力”范畴。其根本动机是过去两年 AI 和世界局势带来的严重信息过载：他每天会收到大量 Substack、博客、newsletter、Twitter 动态和群聊消息，光是试图跟上就要花去大量时间，更别说再做综合判断。针对这一问题，他先做了一个聚合式阅读工具，把 newsletter、播客等内容统一拉入 RSS 读取器，并为每条内容预生成两层摘要，方便自己每天快速判断哪些值得深读。接着，他又构建了一个更复杂的系统，将邮件、Slack、Signal、WhatsApp 等消息统一接入，用 LLM 判断是否紧急，只把需要立即处理的内容显示在第二块显示器上，作为“注意力防火墙”。

主持人接着追问这些工具背后的目标函数，即一个项目成功后，使用者的生活究竟会发生什么变化。他强调，自己的理想并不是单纯沉迷于 agent 配置，而是希望减少坐在电脑前的时间，换回更多运动和户外活动，同时不失去对重要事务的掌握。Steve 认同这一点，并补充说，自己在开发“注意力防火墙”时，其实在完成约四分之三后，才真正意识到自己在造什么；此前更多是朝着一个模糊方向不断迭代、边做边理解。他把这一状态概括为整个行业都在经历的“寒武纪式爆发”：没有既定剧本，大家都在边摸索边发明。对于主持人关于“上下文处理”的提问，Steve 也坦率承认，自己的 newsletter 摘要器目前采用的是最朴素的方法：直接把全文或播客转录喂给模型做静态摘要，并没有构建个性化阅读历史或跨内容去重系统；但在实践中，这种简单方案已经足够有用。

在广告插播后，Steve 转向另一个重要分野：很多人已经开始让 AI 不只是读取和筛选信息，而是直接对邮件和数字生活内容采取行动，例如代写、代回或执行工作流。但他自己还没有走到这一步。原因一方面是项目复杂度更高，另一方面则是安全和可控性问题。他把自己形容为在这类工具上相当保守的人：除非真正理解其行为边界，并且确信可以信任，否则不会轻易部署。主持人则表示，自己本来并非安全保守派，过去对计算机安全甚至接近“疏忽”，但在把 AI 接入个人全部写作和他人发送的信息之后，心态明显改变，因为这不再只是自己的数据，而涉及对他人交付给自己的信息承担照管义务。

在这一大段中，讨论继续围绕“如何让 AI 工具真正可用”展开，重点落在信息安全、系统完整性和工程可维护性上。主持人此前在开场中提到，Steve 的工具箱不仅包含阅读和注意力管理，还包括通用日志系统、Chrome 扩展和用于查看多个 coding agent 状态的仪表板。这里的关键思路是：AI 工具并不应建立在模糊、不可追踪的自动化之上，而需要像传统软件系统一样具备日志、可观察性与调试能力。Steve 所采用的做法，是把错误、状态变化和跨应用流程统一记录下来，让 Claude 这类模型不仅参与生成代码，还能借由日志帮助定位和修复问题。与之相伴的是严格的信息接入边界：不同应用、通信渠道和自动化组件需要明确知道哪些数据能被读取、哪些步骤能被执行。整体上，这部分展示的是一种成熟工程师对 AI 工作流的改造方式——不是追求最炫的自治能力，而是优先建立能追责、能恢复、能 debug 的基础设施。

访谈中段逐渐凝聚出 Steve 的核心方法论，即主持人在开场中称为“anti-token maxing philosophy”的思想。其基本立场是，不应为了让 agent 更忙、更长上下文、更复杂流程而优化系统，而应始终围绕人类使用者的真实收益来设计。Steve 关注的是：如何减少无意义切换、如何把专注时间还给自己、如何在不牺牲判断力的前提下压缩信息处理成本。由此衍生出的工具——无论是阅读摘要器、注意力防火墙、工作流扩展还是 dashboard——都不是为了展示 AI 自主性，而是作为人的认知外骨骼。主持人与 Steve 都强调，目前大家仍处在大规模试错和自定义爆发期，因此最值得借鉴的不是某个固定模板，而是这种先问‘我想让生活和工作发生什么改变’，再决定技术如何介入的思路。

随着展示继续，话题延伸到界面层与使用场景层。主持人在开场已提示，Steve 还分享了移动端和语音接口的使用方式，以及通过 Chrome 扩展自动化常见操作。其总体思路并不是把一切集中在单一聊天窗口，而是根据任务类型给 AI 安排最合适的入口：桌面端适合深度 coding 与状态监控，阅读工具适合早晨快速筛选信息流，而移动端和语音则服务于碎片化场景中的捕捉、查询和轻量交互。这样的个人界面策略，体现出 Steve 把 AI 视为一套分布式环境而非一个统一应用：不同组件各司其职，通过日志、消息筛选和自动化钩子连接起来。结果不是一个万能超级助手，而是一个逐渐长出来的、贴合个人习惯的数字工作台。

在访谈后段，讨论回到更广义的 AI 发展判断。主持人在片头就指出，Steve 也会谈到一些最重要的开放问题，包括我们距离由递归自我改进驱动的智能爆炸究竟还有多远、机器人相对数字 AI 会滞后多少，以及 AI 是否会显著影响气候变化。结合 Steve 在整场访谈中展现出的气质，这部分并非耸动式预言，而是偏谨慎、 grounded 的分析框架：一方面承认数字 AI 的能力扩张速度惊人，另一方面也强调现实世界部署、执行可靠性、物理系统与安全问题会让很多能力落地更慢。气候问题则被放在双重视角下看待：AI 既可能提高效率、推动科研与系统优化，也会带来算力消耗和基础设施扩张的代价。

在接近结束时，主持人把整场讨论的价值落回到行动层面：他建议听众不要只是听完，而应像自己那样，直接把访谈转录交给 Claude Code 或 Open Claude，让模型识别出其中最能增强自己工作流的点子，并立即实现。主持人也分享，自己在录制之后已经做出了新的播客生产 UI，并在着手一些 hooks 和个人 Chrome 扩展。这个收束非常贴合全场主题：Steve 展示的并不是一套需要完整复制的标准答案，而是一种以个人瓶颈为起点、借助 AI 快速试做并持续演化的构建方法。真正重要的不是复刻 Steve 的工具，而是用类似思维，找出最困扰自己的摩擦点并开始动手。