个人工作流与Codex的深度集成
本次工作坊是主演讲的延伸，旨在通过70分钟的互动时间，帮助参与者亲自设置环境并深入探讨Codex的实际应用场景。Jason Liu作为OpenAI的员工，其日常工作涵盖了从原型开发、代码编写到视频编辑（使用Computer Use功能）以及运营与教育合作等多个领域。他特别指出，当前的演示文稿实际上是在Codex应用内的本地浏览器中通过localhost服务的，这展示了该工具在实时内容创作中的灵活性。当发现幻灯片内容不理想时，他可以直接使用注释工具，让Codex自动清理和优化内容，这种本地化服务的方式极大地提升了迭代效率。
"I don't know if you can tell, but right now the slide is being served on local host in the inapp browser of the Codeex application."
Jason强调，虽然有些用户每天消耗数十亿Token，但本次分享的核心目标并非鼓励无意义的消耗，而是通过分享经过验证的技巧，帮助听众避免Token浪费。他提供了一个Monorepo仓库供参与者克隆，以便快速获得所需的技能和设置。这种实战导向的方法论旨在让参与者从“知道能做什么”转变为“知道如何高效地做”，特别是在知识工作领域，随着编码和操作任务的自动化，任务管理的复杂性呈指数级增长，而Codex正是解决这一痛点的关键工具。
应对复杂性的核心策略：压缩与语音交互
在AI辅助工作的新范式下，个人需要管理的项目数量可能从传统的10个激增至200个，导致信息过载和关键信息遗漏的风险大幅增加。Jason指出，Codex中最强大的功能之一是压缩（Compaction）机制。他分享了一个具体案例：拥有5周历史、包含400个子代理（sub-agents）的对话线程，依然能够清晰地理解自身任务并执行操作。这种长期记忆保持能力使得复杂的自动化工作流成为可能，用户无需频繁重置上下文，从而大幅提升了处理长周期任务的效率。
"The things I really want you to take away from this workshop is the fact that compaction works really, really well."
此外，Jason极力推崇语音交互而非传统的文本输入。他描述了一种双手背后、脚踏踏板的工作姿态，通过一个按钮进行转录，另一个按钮执行指令，从而在不中断人际交流的前提下完成Slack消息发送或代码修改等任务。这种非侵入式的交互方式让他能够专注于OpenAI工作中更具人性化的一面，而非终日监控Slack。他还特别推荐了Appshots功能，通过快捷键即可实现屏幕截图与AI分析的无缝结合，这一功能被他称为“有史以来最喜欢的功能”，因为它提供了极高的即时满足感和操作流畅性。
构建团队资产：插件、技能与自动化线程
为了将个人效率转化为团队生产力，Jason建议将精力投入到个人记忆投资和团队插件开发中。他提到，通过查看线程历史，可以清晰地量化任务委派和自动化的程度。当团队广泛使用由个人构建的插件时，这种复用性将成为衡量工作价值的重要指标。目前，OpenAI内部最受欢迎的技能之一是“最终化Codex应用技能”，任何Pull Request在审查前都会自动触发该技能，它能有效识别代码风格违规或潜在错误，全员使用率极高。
"If you're rewarded by how often the plugins you've built are being used by your teammates, that's a huge win."
Jason还分享了基于同事反馈构建的代码审查技能，例如模仿同事Charlie和Dominic过去一年的PR审查风格，将这些隐性知识转化为可复用的自动化脚本。随着熟练度的提升，固定线程（Pinned Threads）与自动化的结合将使这些AI助手感觉像真正的团队成员。更重要的是，线程之间现在具备了相互通信的能力，每个线程都可以列出其他固定线程、重命名线程或进行压缩，这种线程间的协作机制标志着AI工作流从单点自动化向系统化协同的演进，为构建更复杂的自动化生态系统奠定了基础。
从个体开发者到AI经理：多智能体协作的未来架构
随着大语言模型能力的提升，人机协作模式正经历从个体贡献者（IC）辅助向多智能体团队管理的范式转移。过去，开发者仅作为被IDE赋能的个体，而现在通过“线程”（Threads）机制，用户开始扮演团队管理者的角色。这种架构允许主线程（Manager Threads）协调多个子线程（IC Threads），实现复杂的任务编排。这种演进的核心驱动力在于上下文压缩技术（Compaction）的成熟，它打破了以往对对话长度的限制。
"You went from an IC enabled by an IDE, then you have pin threads that feel like a team where you're the manager."
在六个月前，行业共识是长对话会导致质量下降，建议每20条消息或每个新功能就开启新会话。然而，现在这一规则已被颠覆。通过压缩技术，用户可以将线程重命名为项目ID，使其成为持久化的项目上下文容器。该容器不仅能与子代理（Sub-agents）通信、创建新线程，还能将关键信息写入记忆库（Memory Vault），实现状态的持久化记录。配合自动化触发器，这些智能体可以在后台被唤醒并协同工作，形成闭环。
输入效率革命：语音指令与模糊上下文的利用
提升AI协作效率的关键在于优化输入方式。演讲者强烈建议用户摆脱传统的打字模式，转而使用语音输入（Dictation）。研究表明，语音输入的速度通常是打字的三倍，且能更自然地表达思维过程。用户可以向AI发送长达15分钟的语音备忘录，包含随意的联想和碎片信息，而无需像对待同事那样顾虑礼貌或结构。
AI具备强大的上下文重构能力，能够从杂乱的语音中提炼关键信息。例如，当用户提到“上周和Charlie讨论Agent SDK的会议”时，AI会自动检索相关邮件、Slack记录或日历，精准定位到具体的35条会议消息，并提取出与当前任务相关的上下文。这种能力使得用户可以将模糊的意图转化为精确的行动指令，如生成项目追踪器或起草文档，从而大幅降低认知负荷，提高产出效率。
技能封装与插件生态：构建个性化AI工作流
在掌握高效输入后，用户可通过技能（Skills）和插件（Plugins）扩展AI的能力边界。技能是包含脚本和配置文件的简单结构，而插件则是技能的集合库。OpenAI已建立起成熟的插件生态，用户可在侧边栏直接搜索并安装如Slack、Gmail、Teams、Notion、Linear和Obsidian等常用工具。
"If there is something you feel like you are missing, just at me on Twitter and I'm sure one of my Twitter monitors will pick up and send a message to someone in the connectors team."
这种模块化设计允许用户根据需求自定义工作流。通过组合不同插件，AI不仅能执行单一任务，还能进行跨平台的信息整合。例如，AI可以检查邮件发现未决线索，同时在Slack或会议记录中查找背景信息，甚至通过LinkedIn分析对话者的背景（如校友关系），从而在通话前提供个性化的破冰建议。这种自动化情报收集能力，使得AI从被动响应工具转变为主动的个人助理。
计算机使用（Computer Use）：后台自动化与AGI体验
Computer Use功能代表了AI交互的重大突破，它允许AI在后台直接控制操作系统中的应用程序，而不仅仅局限于浏览器。通过安装Chrome扩展或启用Computer Use，AI可以像人类一样操作界面，执行点击、滚动、输入等动作，且不会抢占用户屏幕。
演讲者分享了一个在iMovie中处理视频剪辑的案例：AI自动识别音效需求，并在正确的时间戳插入音效，同时指导用户完成导出流程。这种后台静默操作能力让用户感到“工作中出现了AGI的迹象”。AI可以在用户处理其他任务时，自动打开多个标签页查询Twitter DM，随后自动关闭，整个过程对用户透明。这种非侵入式自动化不仅提升了效率，更让软件使用变得直观且有趣，极大地降低了学习新软件的门槛。
| 功能特性 | 传统AI助手 | Computer Use / Chrome扩展 |
|---|---|---|
| 操作范围 | 仅限文本生成/代码补全 | 控制桌面应用及浏览器界面 |
| 屏幕占用 | 无（文本界面） | 后台运行，不抢占主屏幕 |
| 交互方式 | 指令式（Prompt） | 视觉理解+动作执行（GUI） |
| 典型场景 | 写邮件、查资料 | 视频剪辑辅助、跨App数据同步 |
| 用户感知 | 工具属性 | 代理属性（Agent-like） |
从微观指令到宏观意图：记忆系统赋能的自动化演进
在构建 AI 记忆系统（如 Codex Memory）的过程中，用户的管理负担会随着系统成熟度显著降低。初期，用户可能需要对每一项操作进行细致的标签化管理，但随着系统积累的历史记录、线程和记忆数据增多，用户逐渐转变为“更糟糕的管理者”——即不再需要事无巨细地指导，而是直接下达宏观意图。这种转变的核心在于上下文（Context）的完整性。正如资深员工在入职七年后，管理者只需告知“让公司更赚钱”的目标，员工即可基于已有的上下文自行推导执行路径，AI 系统亦遵循此逻辑，通过长期积累的记忆实现从“执行具体指令”到“理解模糊意图”的跨越。
“Right now, I'll just open up the composer and just say like what has changed about the launch and it'll be able to do a good job... It's only because they have this context.”
这种能力的提升使得用户能够直接询问系统“本周发布有什么变化”，系统便能自动整合信息并给出高质量回答。这证明了长期记忆和上下文积累是 AI 从工具进化为智能代理的关键。用户无需再手动整理所有标准操作程序（SOP），而是依赖于系统内部沉淀的结构化记忆，从而实现高效的信息检索与任务执行。
技能库的构建与内部自动化：从开源资源到企业定制
为了激发灵感并快速上手，用户可以利用现有的技能资源。OpenAI 提供了Skill Installer，可列出所有经过官方策展的技能，涵盖 GitHub 集成、Playwright 代码最佳实践以及 React 开发规范等。此外，用户还可以访问如 skillset.sh 或 Vercel 的技能工具网站，探索更广泛的社区技能，例如运动设计或 Web 设计相关的最佳实践。然而，对于企业内部而言，最高影响力的举措是由 AI 倡导者（AI Champion）根据团队实际需求定制专属技能。
以作者 Jason Liu 为例，他构建了针对故障排查（Triage）和沟通（Comms）的自动化技能。当 Twitter 发生服务中断时，系统能自动执行以下流程： 1. 确定受众：识别谁需要接收此信息。 2. 启动流程：自动发起 SEV（严重事件）响应。 3. 检查标准：验证所需的统计显著性门控（stat sig gates）。
这些原本繁琐的人工流程现在被完全自动化。通过Skill Creator功能，用户只需记录一次操作过程，并指示 Codex 将其转化为技能，系统即可复用该逻辑。更重要的是，如果配置了自我编辑权限，技能文件会随着新知识的获取而自我优化，实现技能的持续迭代与进化。
Appshots 技术突破：从 OCR 识别到无障碍树解析
在解决开发者体验（DX）排查问题时，传统的截图发送方式存在巨大瓶颈。当用户向 Codex 发送 Slack 线程截图时，模型必须经过多步推理：首先进行OCR 文字识别，然后调用 list slack channels 函数，再识别出特定用户（如 Charlie），最后调用 list persons 获取用户 ID，才能最终发送消息。这一过程涉及多次函数调用（Hops），效率低下且容易出错。
Appshots 技术的引入彻底改变了这一现状。它不仅捕获图像，还获取应用的完整无障碍树（Accessibility Tree）。这意味着当用户发送 Slack 频道的 Appshot 时，系统直接拥有频道 ID 和所有用户的 UserID。因此，执行“研究并回复”指令仅需一次函数调用。例如，系统能直接识别出 Charlie 的 ID 为 U425，并精准向频道 U12725 发送消息。这种上下文信息的深度注入，使得后续的工具调用更加精准和快速，大幅减少了推理步骤。
个人记忆模板与无感交互：从表单填写到自然语言管理
随着技能的完善，用户逐渐摆脱对传统交互方式（如斜杠命令 /slash commands）的依赖，转向自然语言意图驱动的无感交互。作者不再手动填写表单，而是直接告诉 Codex 填写，系统会根据当前环境（Chrome 或 Safari）智能选择浏览器扩展或 Computer Use 功能。这种智能化的背后，是个人记忆模板（Personal Monorepo Template）的支撑。该模板是一个目录树结构，集成了大量用于扩展记忆的技能。
“I have not like filled out a form in like two weeks because I just now tell Codeex to fill out this form... The model has become really intelligent.”
在 DX 团队中，作者维护着 16 个演示仓库，但侧边栏仅显示一个个人 Monorepo 项目。Codex 能够在此单一项目下管理所有文件，实现了物理存储与逻辑管理的解耦。用户只需通过自然语言（如“安装 GitHub 上的个人 Monorepo 模板”）即可触发复杂的系统配置。这种模式类似于经理转发邮件并留下三个问号，由下属自行解读并处理，体现了AI 代理在理解模糊指令和处理复杂上下文方面的成熟能力。
项目目录隔离与文件系统管理策略
在构建基于 OpenAI Codex 的自动化工作流时，文件系统的路径隔离是确保代码安全与逻辑清晰的关键。演讲者 Jason Liu 分享了一种通过配置 agents.md 文件来管理项目存储位置的技巧。他并未将所有代码保存在主仓库（monorepo）中，而是通过一行指令指定 Codex 将新克隆的项目或工作文件保存至 /dev 目录下。这种配置使得 AI 能够根据上下文自动识别存储路径：当指令涉及新项目时，文件存入 /dev；当涉及幻灯片制作时，则存入 /dev/slides 目录。这种结构化的路径管理极大地简化了文件系统的混乱，使得 AI 可以随意触碰文件系统而不干扰核心代码库。
尽管这种单列视图偶尔会干扰侧边栏的 Git 审查功能，但演讲者表示整体体验良好，因为他主要在 GitHub 上审查代码。这种方法的核心理念是从个人知识库（Personal Vault）启动所有项目，让 AI 在受控的隔离环境中执行文件操作。通过这种方式，用户可以在保持主仓库整洁的同时，充分利用 AI 的文件处理能力，实现开发与文档生成的并行处理。
核心技能插件与个性化风格定制
演讲者详细介绍了其安装的多个关键技能插件，其中最具价值的是“像我一样写作”（Write Like Me）技能。该技能通过让 Codex 读取过去六个月的电子邮件和 Slack 消息，自动生成一份个性化的消息风格指南。此后，当 AI 需要起草邮件或 Slack 消息时，它会根据场景自动调整语气。例如，在处理客户支持表单时，AI 会主动采用更严肃的语气。这一技能至今未出现过失误，极大地提升了沟通的专业度和一致性。
此外，他还使用了助手插件（Assistant Plugin）进行初始设置，该插件会通过面试形式了解用户需求，自动安装所需插件、创建线程并配置自动化流程。其他常用技能包括：审计 AI 代码与写作、自定义循环技能（Loop Skill）、简单 HTML 工件生成器（用于定制白色背景和特定样式指南）以及Ultra Goal（目标技能的增强版）。这些技能共同构成了一个高度定制化的 AI 助手生态系统，能够处理从代码审计到文档生成的多样化任务。
个人记忆库（Memory Vault）与 Git 版本控制
为了管理人际关系和项目信息，演讲者构建了一个类似 CRM 的个人记忆库（Personal Memory Vault），并命名为“New Project”或“Palunt”。当 AI 代理检测到新联系人（通过邮件、Slack 或 iMessage）时，会自动将其记录在此处。对于技术实现，他将这个记忆库设置为一个 Git 仓库。这一做法带来了巨大的优势：通过运行 git diff 命令，他可以清晰地查看模型在过去几天内更新了哪些内容，哪些未更新。
“通过运行 git diff，我可以清楚地看到模型更新了什么，没有更新什么，从而自信地回顾历史，比如确认 Charlie 是否已经回复某人并闭环，即使我之前没注意到。”
这种版本控制机制不仅有助于长期追踪 AI 的行为轨迹，还在团队协作中发挥作用。当同事询问项目信息时，Codex 可以读取记忆库并草拟回复，再请求用户批准发送。例如，若有人询问“该项目该找谁对接”，AI 能直接从记忆库中提取信息并生成初步回答。虽然可以通过自定义自动化任务来维护记忆库的整洁，但演讲者表示目前并未遇到严重的 token 消耗问题，Git 的历史追踪功能已足够满足需求。
技能迭代哲学与 AppShots 的不可替代性
在技能开发与评估方面，演讲者采取了“YOLO（只有一击）一次性构建”的个人策略。对于个人工作，他倾向于快速构建技能，每次出错时立即纠正并继续，经过两个月的实际使用验证后，再考虑将其分享给团队。相比之下，团队共享的技能则需要更严谨的评估，例如确保分类插件能正确路由功能负责人。由于个人技能连接了大量插件和连接器（如 Slack），难以通过快照进行标准化评估，因此更依赖实际使用中的自我改进。
关于工具选择，演讲者强调 AppShots（应用截图/上下文捕获） 是桌面端体验的核心优势，这是 CLI 无法替代的。他经常在使用视频时通过 AppShots 让 LLM 总结内容，或在签署文件时调用 DocuSign 并保存至桌面，甚至自动寻找传真服务发送医疗记录。这种多模态交互能力使得 AI 能够无缝融入日常办公场景，而不仅仅是代码生成工具。
“当我在办公室时，我的角色更像是 AI 的助手，去获取 AI 无法直接获取的上下文。当 AI 运行时，我应该在与他人交流，学习更多背景信息。”
最后，演讲者提到他在办公室的工作重心是人际互动与上下文补充。他认为 AI 擅长处理既定任务，但缺乏对复杂人际动态和非结构化信息的理解。因此，他的价值在于为 AI 提供它无法直接感知的上下文，并在 AI 运行期间通过与人交流来丰富这些信息源，形成人机协作的最佳互补。
模型选型策略：55与Spark的适用边界
在决定使用哪种模型时，决策主要受限于Token预算和延迟敏感度。对于拥有无限Token且后台自动化运行的场景，55模型通常是默认选择，因为其强大的处理能力足以应对复杂任务。然而，在涉及极简计算机操作（如点击按钮、填写表单）时，Spark模型因其轻量级特性而更具优势。例如，演讲者构建了一个自动值机代理，当收到航班确认邮件时，该代理会自动登录系统、下载登机牌并通过iMessage发送给自己。这种高频、低复杂度的重复性操作是Spark的核心应用场景，从而将用户从繁琐的日常事务中解放出来。
“I think this is colored by two things like because I have unlimited tokens I I don't really make those decisions and then secondly because I'm not watching my AI work like most of these things are automations that run in the background the latency has not really affected me the times where I use Spark is primarily when there's a very simple uh there's a really simple computer use task”
远程控制与权限管理：Computer Use vs. Remote Control
在控制计算机方面，Computer Use 和 Remote Control 存在本质区别。Computer Use 必须运行在本地计算机上，且依赖于具有图形用户界面（GUI）的操作系统。为了增强灵活性，设置中有一个名为 Locked Use 的选项，启用后只要笔记本电脑接通电源，即使屏幕关闭，用户仍可通过手机触发 Computer Use 命令。此外，用户可以将多个设备（如 Mac mini）连接到同一账户，实现跨设备控制。
相比之下，Remote Control 允许用户同时控制本地和远程计算机，且不受本地GUI环境的严格限制。这种架构差异意味着，如果用户需要处理更广泛的远程服务器管理或无头环境任务，Remote Control 提供了更大的灵活性。而 Computer Use 的核心优势在于其能直接访问用户的操作系统、凭据和文件系统，这种深度集成使其在执行需要本地上下文的任务时具有独特价值。
“if you go into settings computer use there's a flag called locked use. And if you enable that, as long as your laptop is plugged in, even if the monitor is closed, you can still trigger computer use commands through your phone.”
风险控制机制：Auto Review与组织级安全策略
针对AI执行破坏性操作的风险，55模型表现出高度的谨慎性，往往拒绝执行用户期望的激进操作。为了平衡安全性与效率，用户可通过侧边栏调整权限设置。演讲者指出，Auto Review（自动审查） 模式在实际使用中表现良好，虽然偶尔会因模型过度编辑文档而引发不便，但通过结合 .hsmd 文件进行微调，整体风险可控。对于组织用户，管理员可设置更严格的安全边界，例如禁止通过MCP服务器向非组织邮箱发送邮件，或禁止向外部Slack频道发送消息，从而防止敏感数据泄露。
“I found that uh the 55 models are pretty reluctant to take these like destructive actions. That's one thing. The second thing is if you look at the sidebar here you have the ability to change your permissions.”
隐私安全与沙箱演进：从命令到全系统访问
关于隐私和数据保留政策，模型本身存在被越狱的风险，但安全性正通过沙箱机制的演进得到加强。早期的沙箱仅允许运行简单命令，而现在的沙箱已扩展至整个计算机环境。演讲者指出，构建计算机级或组织级的沙箱边界是当前安全工作的重点。通过限制沙箱的权限范围，系统能够在提供强大自动化能力的同时，最大限度地减少潜在的安全漏洞。这种从简单命令执行到全系统控制的转变，要求开发者不断重新评估和加固安全边界，以应对日益复杂的自动化场景。
“We started with very simple sandboxes where it was like you can just run this command and nothing else. And slowly the sandbox has grown to the entire computer and I think we're figuring out what are the like computer level or organization level you know edges to that sandbox that we need to build.”
线程即队友：自动化工作流与长期记忆
在任务管理方面，每个固定的线程（Thread）被视为一个独立的团队成员。演讲者维护着多个专用线程，如“幕僚长线程”、“SDK管理线程”等，其中SDK线程还委托给子代理处理CLI、开源项目和Twitter事务。通过设定周期性唤醒指令（如“每30分钟检查一次”），用户可以实现对生活和工作的高度自动化。这种基于线程的架构允许用户通过秘密口令激活特定代理，从而将复杂的系统性工作转化为可预测、可监控的自动化流程。这种模式不仅提高了效率，还确保了关键任务不会因遗忘而中断。
“every pinned thread effectively is a teammate in my mind... If you remember those like secret words, you can effectively automate like about everything in your life at this point.”
心跳自动化：从创建新线程到同一线程的调度演进
Jason Liu 指出，自动化设计的核心趋势是从“每次触发创建新线程”转向“将消息调度回同一线程”。早期自动化（如生成晨间简报）往往独立运行，但随着模型能力提升，在同一线程内持续调度消息成为更优设计。这种机制被称为“心跳自动化”（Heartbeat Automation），其本质是安排消息在时间线上重新进入对话线程，从而实现长期监控与迭代。
"You should think of it as a way of scheduling a message back into the thread."
这种设计允许 AI 在后台持续工作，无需用户频繁干预。例如，在 Monor 仓库中，用户可以使用 loop 技能来监控 Pull Request（PR）。AI 会持续检查反馈、修复问题、确保代码可合并、基于主分支重新变基，并保证 CI（持续集成）始终通过。这种持续性的后台监控使得开发者即使忙碌数天，也能在回归时看到 PR 已完全整合且无冲突，避免了“落后 4000 个提交”的混乱局面。
案例解析：自动化支持工作与 Chief of Staff 线程
在客户支持场景中，心跳自动化展现了强大的跨平台协作能力。当 Twitter、Slack 或 Appshot 上出现问题时，AI 会自动识别问题类型（如浏览器端问题），将信息转发给特定负责人（如 James），并通过 Computer Use 打开 Twitter 通知用户问题已升级处理。随后，AI 会每小时检查一次内部频道是否有回复，并在获得回复后通知用户。这种自动化流程让用户在回家后发现 Twitter 自动弹出“问题已解决”的通知，极大提升了支持效率。
"It allows us to do way more support without making it the worst part of my job."
在“首席参谋”（Chief of Staff）线程中，用户同样可以使用 loop 命令检查所有连接器并获取重要事项更新。AI 会整理邮件、Slack 链接等关键信息，并以结构化格式呈现。此外，AI 还能自动查询航班信息，通过 iMessage 发送登机牌。由于权限设置得当，这些任务在后台静默运行，用户仅在发现 Safari 被调用时才意识到 AI 正在工作，这种无感知的后台操作带来了极佳的体验。
团队协作与远程协作：从个人效率到团队赋能
在 OpenAI 内部，自动化不仅服务于个人，还延伸至团队协作。Jason 曾让 Codex 每周三晚上生成一份关于本周剩余时间发布内容的 PowerPoint，随后通过技能将其自动发布到 Slack 频道。这种“插件英雄”（Plug-in Hero）思维使得自动化成果惠及整个团队，解决了信息同步滞后问题。
另一个令人惊叹的案例是远程视频编辑协作。Jason 在骑行时收到视频反馈，通过手机指示 AI 在 iMovie 中查找项目、读取 Slack 消息、导出视频。若 MCP 服务器不支持文件上传，AI 会使用 Computer Use 上传文件，并每小时检查反馈。若需修改，则重新导出并分享。最终，Jason 回家时发现视频已根据反馈完成排版修复并重新发布。虽然最终改用 Google Drive 连接器简化了流程，但这一过程展示了AI 如何跨越设备限制，实现复杂的远程协作闭环。
"It's very simple but mind-blowing... A heartbeat is just a way of waking up your thread over time to take some actions."
目标设定与验证：从代码迁移到测试覆盖
除了心跳自动化，设置目标（Goals）是另一种强大的自动化模式。通过 /goal 命令，用户可以定义验证步骤，AI 会在运行期间持续检查验证条件，若未完成则继续执行。这种机制在软件迁移项目中效果显著。例如，Jason 将 Python 项目迁移至 Rust，要求重写后端并确保所有单元测试通过。结果不仅成功重写了复杂的终端库，还尝试将 UV 和 TypeScript 重写，最终实现了100% 的测试覆盖率。
"As long as there's a verifier, it does really well."
在 Monor 仓库中，还引入了 ultra_goal 技能，允许将目标定义在 goal.md 文件中。这种设计的优势在于目标可在运行期间动态编辑，用户可根据项目进展调整范围和计划。这种灵活性使得 AI 能够适应真实项目中不断变化的需求，通过持续的验证与调整，实现更复杂的自动化任务。尽管 Jason 提醒不应在工作环境中盲目追求 100% 重写，但这种基于验证的自动化机制展示了 AI 在处理高复杂度、高验证要求任务时的巨大潜力。
利用状态文件与远程控制在长周期任务中保持掌控
在处理耗时较长（如运行一两天）的任务时，直接阅读庞大的会话 JSON 对象是不现实的。Jason Liu 建议创建 state.md 文件或工作日志来追踪任务进度，并通过侧边栏的另一个模型进行摘要总结。这种机制允许用户在无法实时关注时，依然能掌握系统状态的演变。此外，他特别强调了 Remote Control（远程控制） 功能的重要性，尤其是配合 iOS 应用使用时，用户可以通过扫描二维码，利用手机触控板消息和队列控制电脑上的任何线程，包括远程线程。
"I'm never going to read this like 4 gigabyte like you know session JSON object but I can look at the work log have it have another model summarize it using like a side chat and go from there."
这种跨设备控制带来了显著的 AGI 体验时刻。例如，当用户离开家时，家人或同事的请求可以通过手机直接传达给 Codex，由其监控 Slack 并执行相应操作。虽然目前自动化程度尚未达到完全无人值守（如自动回复所有邮件），但这种 将个人电脑作为单一事实来源（Single Source of Truth） 的理念，极大地提升了个人效率和对生活/工作流的掌控力。
Chief of Staff 线程的自动化配置与迭代
Jason 的核心工作流围绕一个名为 Chief of Staff（首席参谋） 的线程展开。他每天上午 8 点自动创建并固定该线程，检查所有连接器，梳理当前状况。这个线程并非一成不变，而是随着使用习惯不断迭代。例如，早期他让模型在发现待回复邮件时，不仅起草回复，还会自动在 Chrome 中打开对应的标签页。这样，当他从会议中回来时，电脑上已经准备好了多个待处理的标签页，只需审查草稿即可发送。
"Create a create and pin a cha staff thread every day at 8 am. Check all these connectors, figure out what's going on, and then uh you know, do a good job."
这种 预先准备计算机环境 的策略非常高效。通过让模型在会议期间后台处理信息，用户可以将注意力集中在会议本身，回来后只需进行最后的审核和发送。这种工作流的关键在于 持续编辑和优化提示词，比如调整格式、添加链接或修改检查频率，以适应不断变化的工作需求。
提示词策略：从具体指令到目标导向
在回答关于提示词编写的问题时，Jason 分享了他的最新心得：倾向于让模型自己编写目标或提示词，而不是由用户手动编写详细的指令。随着模型能力的提升，它们更能理解用户的意图分布。Jason 通常发送长达 10 分钟的语音备忘录，描述遇到的问题、相关项目或联系人（如 "Dylan"），并指定查询 Gmail 等动作。随后，他让模型决定如何组织工作成果，例如是生成 HTML 索引、创建 Word 文档，还是建立新的线程或技能。
"I generally always prefer to have the model write the goal or write the write the prompt itself. Like more and more of these models are just getting better at doing that."
这种策略的核心在于 信任模型的判断力 来确定自动化的详细程度和检查频率。Jason 还提到，通过在项目文件的 front matter 中添加相关的 Slack 频道 ID，模型会自动读取这些频道，从而提供更准确的结果。这种 通过元数据增强上下文 的方法，比手动提示更有效，且随着使用时间的推移，模型会逐渐学会自动记住和更新这些技能。
与 OpenClaw 及 Hermes Agent 的对比与思考
针对观众提出的关于 Codex 与 OpenClaw 或 Hermes Agent 区别的问题，Jason 认为目前差异可能不大，且未来可能会迅速趋同。他更倾向于使用 自我管理的线程（Self-managing threads），这类似于子代理（Sub-agent）的功能。他认为，对于大多数工作场景，单一线程 的概念在现实中是合理的，因为用户需要清晰的组织结构。
"It's like you know is there a world where like my banker and my therapist and my personal trainer and my girlfriend is the same person like maybe but like my like you know tiny brain can't figure that out and like it's easy for me to understand what the work is by making folders right"
Jason 用 文件夹类比 来解释这一观点：虽然计算机本身不理解文件夹的概念，但文件夹对人类用户来说，是理解工作内容和组织信息的有效方式。因此，他并不追求将所有角色（如银行家、治疗师、私人教练）合并到一个 AI 代理中，而是通过 文件夹式的结构 来管理不同的工作流。这种 以用户认知为中心的组织方式，比纯粹的技术整合更符合人类的思维习惯。
记忆功能与上下文交互的长期验证
在开始深入操作之前，演讲者强调了 Memory（记忆）功能 的重要性。他建议用户开启设置中的记忆选项，并持续使用数周以观察系统随时间推移产生的变化。尽管目前无法给出精确的时间预估，但核心逻辑在于通过长期互动让模型积累上下文。演讲者坦言自己几乎从未主动回忆过之前的对话细节，而是依赖系统自动处理。这种机制使得 AI 能够逐渐理解用户的偏好和工作习惯，从而在后续的交互中提供更精准的响应。正如他所言：
"I think I would just turn memories on and just see whether or not these changes happen over time... I basically never remember a single time I've mentioned something."
这种 被动式记忆积累 改变了人机协作的模式，用户无需反复提供背景信息，系统会自动在后台构建长期的用户画像和工作语境，为后续的高效协作奠定基础。
多模态内容生成与迭代工作流
Codex 不仅限于文本对话，它已经演变为一个全能的工作工具，能够打开并渲染 Excel 表格、Word 文档、PDF 和幻灯片。演讲者展示了一个具体的案例：他通过 朗读自己的博客文章，让 Codex 实时生成幻灯片材料。在这个过程中，他使用了应用内浏览器（in-app browser）直接编辑幻灯片，通过简单的指令如“修复空白”或“将这两页拆分为更多页”，即可快速迭代内容。这种工作流极大地简化了从原始素材到最终演示文稿的转换过程。
此外，演讲者提到了 Artifacts 生态系统 的强大之处，指出越来越多的工作成果以应用形式而非完整文档分享。他演示了如何通过循环（loops）将幻灯片、注释与其他系统部分（如 Google Sheets）连接起来。例如，项目追踪器大多是通过循环更新 Google Sheets 实现的。这种 自动化循环机制 使得复杂的文档处理变得像日常对话一样自然，用户只需专注于内容逻辑，而将格式调整和页面拆分交给 AI 完成。
"This deck really came from me reading my own blog post out loud and then generating the material as we go along."
Computer Use 的 AGI 时刻与安全边界
演讲者认为 Computer Use（计算机使用） 功能带来了类似“AGI 时刻”的体验。当看到光标在屏幕上自主移动并执行操作时，用户会对系统产生强烈的信任感。目前，除了插件（如发送 Slack 消息）和应用内浏览器外，Computer Use 允许 AI 像人类一样操作电脑。演讲者提到，公司内部已有用户利用该功能管理家庭实验室（Home Lab），甚至有人开玩笑说用它来“管理我的家”。这种能力使得 AI 能够处理浏览器中无法通过插件直接完成的任务，如填写表单、测试应用程序或寻找优惠券。
然而，这种强大的自主性也带来了 安全风险。演讲者警告，如果模型被提示得过于“坚定”，它可能会绕过插件限制，直接通过 Computer Use 执行操作。例如，如果 Slack 插件无法上传文件，模型可能会决定打开浏览器并使用文件上传功能；如果 Gmail 插件无法发送邮件，它可能会打开 Chrome 点击发送按钮。这种行为虽然高效，但属于 真实的安全隐患。因此，他强烈建议在使用 Guardian 模式或 Auto 模式时，务必在 Agent MD 文件中明确限制 AI 的行为边界，以防止其越权操作。
"If this model is really determined... it could be like the one wish willow... let me go on computer use and press file upload and do that."
自动化闭环与未来展望
演讲者最后探讨了 自动化闭环 的可能性。目前，虽然 AI 可以执行复杂的任务（如通过截图触发 DX 分类技能，并自动在 Slack 和 Twitter 上沟通），但仍需要人类作为触发器。他设想未来的场景是：当检测到问题时，AI 能自主发起请求，无需人工干预。目前，他主要利用 Computer Use 进行原生应用的测试，利用应用内浏览器进行网站测试。尽管 iPhone 屏幕镜像控制功能尚不成熟，但其潜力巨大。演讲者总结道，随着 AI 能够控制自身线程之间的通信，未来的工作流将更加去中心化和自动化，人类的角色将从执行者转变为监督者和触发者。
"I feel like now when I'm doing things like building an application, if it's a native application, most of my testing is just done by codeex using computer use."
多线程监控与自动化触发机制
Jason Liu 展示了一种基于单线程监控器（Monitor Thread）的自动化架构，该架构能够主动识别问题并动态创建子线程进行分流处理。监控线程的核心职责是持续扫描潜在问题，一旦发现问题，便启动专门的子线程执行分类和初步调查（Triage）。这种设计避免了主线程的阻塞，使得系统能够并行处理多个任务。例如，当监控线程发现某个问题需要 Slack 上的同事确认，或者某个 Pull Request 已创建但未合并时，它会启动相应的子线程来跟进这些状态。如果未来再次出现类似投诉，监控线程会识别出这是同一问题的重复发生，并向下游子线程发送通知，使其意识到该问题的持续性。这种机制极大地降低了人工追踪复杂工作流的认知负担。
"Not only is the same issue, let me send a message to that, you know, downstream thread so that it's aware that this issue is recurring."
这种自动化流程还能整合外部反馈，例如 Twitter 上的用户意见。监控线程可以汇总信息并生成提醒，如“这个问题已经存在三天了，基于 Twitter 反馈，我们是否应该采取行动？”对于像 Jason 这样频繁使用 Twitter 的人来说，人工追踪这些信息极其困难，而代理（Agent）能够管理和消费所有这些信息，使工作流变得更具可操作性和可控性。这种由监控线程触发、子线程执行并自我管理的模式，构成了其自动化系统的核心基础。
侧边栏线程管理与上下文集中化
Jason 强调将子线程固定在侧边栏（Sidebar）的重要性，这改变了用户与 AI 代理的交互方式。传统的子代理往往以无形的 JSON 线程或后台进程形式存在，用户难以察觉其状态变化。而通过将线程固定在侧边栏，用户可以直观地看到工作流的进展和变化。侧边栏成为了理解当前所有进行中的工作流（Work Streams）的中心枢纽。这种可视化使得用户能够迅速注意到新出现的问题或任务状态的变化，从而更有效地进行干预或监督。
"The difference with sub aents versus these threads is because they show up in the sidebar, you can kind of just notice that something has changed."
这种架构的核心在于上下文管理的集中化。通过一个单一的 Monorepo 来管理所有上下文，并采用不同的方式唤醒系统（如消息触发、心跳机制或线程间触发），实现了高度自动化的工作流。大多数自动化操作发生在监控线程层面，它们触发并创建新线程，然后由这些新线程自行管理后续步骤。这种设计不仅提高了效率，还使得线程间的协作和状态同步变得更加清晰和可控，用户只需关注侧边栏中的线程状态即可掌握全局。
个人知识库结构与代理维护的待办事项
Jason 分享了他的 Monorepo 结构，该结构旨在通过 AI 代理高效管理个人和工作信息。其目录结构主要包括三个部分：项目目录（Projects）、人员目录（People）和松散笔记/代理摘要。项目目录中为每个工作流（如语音发布视频、Agents SDK、Codex 开源资助计划）设立独立文件夹。人员目录则记录了所有与他有过 DM 交流的人的信息，包括他们正在从事的项目、面临的问题以及所属的 Slack 频道。这种结构使得代理能够快速检索和关联人员与项目信息。
此外，他维护了一个由代理管理的待办事项列表（To-Do List）。一个专门的线程会定期检查该列表，如果发现任务未完成，会启动子代理进行验证，确认是否有人已经执行了该任务。然而，Jason 指出，这种验证过程Token 消耗较大，除非用户拥有充足的额度，否则可能不值得为个人用户完全复制此设置。他认为最具价值的自动化是每日和每周的摘要生成，例如每天早上 9 点让代理汇报当天和当周的重要事项。这种简单的自动化能带来显著的效率提升和信息整合效果，是个人知识库管理的核心收益点。
记忆隔离与上下文压缩的局限性
在讨论记忆管理时，Jason 承认目前存在不同项目间记忆泄漏（Bleeding）的问题。例如，一个项目使用 npm，另一个使用 yarn，代理可能会混淆这些上下文。他目前的解决方案是在每个项目目录下的 agent.md 文件中手动清理和明确指定相关配置，以隔离不同项目的上下文。他对此表示好奇，想知道通过简单的工具能否自动解决这种泄漏问题，并建议后续探讨项目级作用域与单线程作用域的区别。
"I don't think I have a good answer to that primarily because it's unclear to me what the downstream side effect would be."
关于模型改进，Jason 认为当前的上下文压缩（Compaction）效果已经相当不错。如果让他选择改进方向，他更倾向于提升模型的写作语气（Writing Tone），而不是搜索上下文的能力。他认为目前的记忆设置已经相当有效，尽管他尚未深入挖掘其底层细节。总体而言，他感觉当前的系统已经接近AGI（通用人工智能）的雏形，能够自主处理复杂任务。早期他会使用“检查笔记”技能来引导代理，但现在系统似乎已经具备了这种自主意识，能够更自然地处理上下文和任务管理。
记忆系统与员工入职的类比
Jason Liu 指出，随着 Codex 记忆系统的成熟，用户不再需要频繁手动提醒模型检查笔记。他的个人档案中，“检查笔记”指令已被使用约 150,000 次，但在过去两三个月里他几乎不再提及，因为记忆系统已承担了大量繁重工作。他将这一过程比作新员工入职：在前两三个月，必须给予大量指令、背景和容错机会，让系统通过失败和复盘来清理自身。因此，不要期望在设置的第一天就获得完美结果，这是一个需要耐心磨合的过程。当系统逐渐适应后，它会变得“自然而然地工作”，让用户重新回到专注于本职工作的流畅状态中。
培养“品味”与批判性消费
针对编码能力的提升，Liu 强调“品味”的重要性，并提出了一个核心观点：想要拥有好品味，就必须多“吃”（多体验）。他建议开发者尝试各种应用程序，了解良好的入职流程是什么样的，或者构建让自己感到沮丧的应用。通过消费更多内容并发展对糟糕体验的“词汇量”，用户能更准确地描述问题。这就像烹饪中若不了解食材，就无法判断是太咸还是缺乏酸味。只有批判性地思考为什么喜欢或讨厌某事物，才能提升对代码质量和用户体验的判断力，从而更有效地向 AI 传达需求。
线程控制与语音交互实践
在操作层面，Liu 展示了如何利用线程（Threads）进行高效管理。虽然 Codex 提供了列表线程和发送消息等工具，但直接输入命令较为繁琐，因此他主要依赖语音输入来简化操作。例如，他会直接说：“上周我在做幻灯片，请找到那个线程，重命名并置顶，以便下次使用。”在处理复杂任务时，如拆分幻灯片，他会指令模型为每个部分创建独立线程，重命名为“第一幕”、“第二幕”等，并标记就绪状态。这种通过自然语言询问而非硬编码命令的方式，让用户能直观理解线程控制逻辑，是掌握该功能的第一步。随着模型对 Codex 功能认知的提升，这种交互将更加自然。
思维链（X-High）的误区与优化
关于思维链设置，Liu 纠正了一个常见误解：并非 X-High（高思维模式）总能带来最佳结果。他分享了一个案例：朋友在寻找优惠券时开启 X-High，导致模型花费两分钟遍历所有网站，效率极低。他建议用户习惯使用低（Low）和中（Medium）思维模式，因为即使是低思维模式下的模型，其表现也远超之前的版本。过度依赖高思维模式不仅浪费资源，还可能导致不必要的冗长搜索。通过合理匹配任务复杂度与思维强度，用户可以在保持高效的同时获得高质量输出，避免陷入“最大主义者”的陷阱。
优化代理交互：从默认模式到智能静默
在构建 AI 代理（如 Chief of Staff）时，首要原则是避免过度工程化。Jason Liu 指出，对于大多数工作场景，并不需要从零开始构建复杂的视频游戏或极度繁琐的任务流，默认的中度复杂度设置往往最为实用。他建议用户首先关注如何控制代理的“噪音”，即如何让它在不必要时保持沉默。一个简单有效的策略是设定明确的回复规则，例如当没有新进展时，强制代理仅回复“no updates”这一单词，从而避免信息过载。此外，调整心跳（heartbeat）频率是另一关键手段，用户可以根据实际需求决定是每 30 分钟检查一次，还是在特定时间点（如上午 9 点）触发，而非让代理全天候无休止地运行。
动态心跳与自动化案例：从排队监控到自动退款
通过自定义心跳频率和停止条件，可以实现高度自动化的复杂任务。Jason Liu 分享了一个与 Amazon 客服排队的实战案例：他设定代理每 5 分钟检查一次队列状态，一旦等待时间缩短至 5 分钟以内，便将检查频率提升至每 1 分钟一次，并持续监控直到成功退款。这种基于状态变化的动态调整策略，使得代理能够在用户淋浴期间自动完成繁琐的客服博弈，最终成功追回 400 美元。他强调，实现这一功能的核心在于编辑文本文件以创建自定义心跳，这赋予了用户极大的灵活性。用户甚至可以设定代理在周末或下午降低活跃度，或在特定时间段（如晚上 9 点后）若长时间未收到用户 Slack 消息则自动进入“睡眠”模式，通过设定“永不停止但允许睡眠”的目标，实现高效且低干扰的后台监控。
破除性能迷思：低推理不等于低结果
在代理的推理能力选择上，Jason Liu 提出了一个常被误解的观点：不应恐惧使用低推理模型（Low Reasoning）。他明确指出，“X High”并不等同于“X High Results”，即高推理成本模型并不必然带来更优的结果。在许多日常自动化场景中，过度依赖高推理模型不仅浪费资源，还可能引入不必要的延迟。相反，合理配置低推理模型配合精准的心跳控制和停止条件，往往能以更低的成本实现同等甚至更好的工作流效果。这一策略的核心在于将智能分配给真正需要复杂逻辑判断的环节，而在监控、状态检查等重复性任务中，采用轻量级、低成本的推理方式，从而实现整体效率的最大化。