受访者几乎从自由口述开始所有任务，因为说话比键盘输入更容易带出细节、例外和临时修正。表达中的停顿、重复和改口不会阻碍模型理解，反而可能保留真实的决策过程。这种方式适合需求尚未完全结构化、但操作者掌握大量隐性背景的场景。
为什么重要: 代理输出质量高度依赖上下文完整度；降低输入摩擦，能让更多隐性约束在执行前被明确。
支撑证据
I start all of my tasks basically by just like yapping.
Notion AI 原本可以启动 Vercel 沙箱处理复杂工作，但每次得到的环境较为基础。团队把内部的 Boxy 云端编码虚拟机接入 Notion AI，使代理可以直接运行命令并探索真实代码库。预置环境减少了重复安装、连接和同步工作，也使复杂编码任务更适合异步执行。
为什么重要: 编码代理的能力不仅取决于模型，还取决于它是否拥有正确代码、依赖、工具和运行环境。
支撑证据
what if we just gave Notion AI our like pre-built Boxy VMs?
代理首先研究现有实现，然后创建详细任务，而不是立即修改代码。任务包含代码指针、迁移要求和自验证步骤，并被加入正式里程碑项目。这样可以把模糊意图转化为具备边界和验收标准的执行契约。
为什么重要: 规划阶段越清晰，后续代理越容易自主执行，也越容易判断结果是否真正完成。
支撑证据
it ends up like producing this like pretty detailed task um with all the code, code pointers, requirements, verification steps.
自由口述任务
通过语音输入目标、背景、细节与临时修正，尽可能释放隐性上下文。
连接编码虚拟机研究代码
让 Notion AI 使用预构建的 Boxy 环境运行命令并探索代码库。
生成可执行任务
创建包含代码位置、迁移要求和验证步骤的正式任务。
启动实现与审查
在新会话中链接任务，要求代理满足全部要求并先运行 review swarm。
提交 PR 并监控 CI
代理创建 PR，持续查看检查结果，并自行修复类型错误或测试失败。
记录执行过程
代理把发现的问题和实施过程更新到 Notion，使任务成为动态工作日志。
正在恢复最近的对话...
这场访谈展示了一种以 Notion 为统一工作界面的代理式开发流程：工程师先通过语音自由描述目标、约束和细节，让 Notion AI 连接预配置的云端编码虚拟机，探索真实代码库，并生成包含代码位置、需求与验证方法的可执行任务。随后，他在新会话中要求代理完成任务、运行自建的 review swarm、提交 PR、监控 CI，并自行修复类型错误或测试失败。整个过程可以在云端异步运行，用户关闭页面去开会也不受影响。Notion 同时承担需求来源、任务系统和动态工作日志的角色，持续记录实现发现与问题，从而减少仓库同步、环境连接和应用切换等上下文管理成本。面对大型改动，review swarm 会按前后端等领域切分变更，再分别从正确性和可维护性角度审查，并让 GPT 与 Opus 独立执行，最后由上层代理汇总需要处理的问题并循环修正。最终价值并非所谓“一句话完成开发”，而是把人的精力集中在目标、环境、约束和验收标准上，将实现与验证中的重复劳动交给可观察、可复查的代理流程。
从这套工作流中可推导出的组织与工程模式。
复现该工作方式时可直接采取的下一步。
访谈明确提及的组件、配置与执行结构。