规范驱动开发：Notion的AI工程工作流程丨How I AI
输入“/”快速插入内容
规范驱动开发：Notion的AI工程工作流程丨How I AI
规范驱动开发：Notion的AI工程工作流程丨How I AI
用户4242用户42426月9日修改
原创 Capihom Capihom 晚点再听LaterCast2026年6月8日 22:00 北京
我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听
"我只是打开 Whisper，把这个功能该怎么工作一口气说出来。"
"我把那段语音交给 Codex，说：写个 spec。"
"再过 10 分钟，它回了我一个 PR 链接和一个预览地址。"
这一期的嘉宾是 Notion 工程师 Ryan Nystrom，Notion 收购团队协作产品 Campsite 后，他在 2024 年底加入，后来成了 Notion AI 和 Custom Agents 的核心建设者之一，现在一边带 6 到 7 人团队，一边继续自己写代码。这期对话很适合工程师、产品负责人和工程经理细看。Ryan 没去重复“大模型会改变一切”那类判断，他直接摊开一条已经在 Notion 团队跑起来的工程工作流：会议 prep 交给 agent，需求先沉淀成 spec，再让 Codex 进仓库提 PR、自测、回传截图，人把精力放回判断、验证和取舍。对很多还停在“让 AI 帮我补几行代码”的团队来说，这套流程已经更接近下一阶段的日常。
先别写代码，先把功能说清楚
Ryan 开场那段最抓人。他说自己最近常放进 prompt 里的句子是： “我真的不知道这里在干什么，你得像给 5 岁小孩讲一样解释给我听。” 他在用最坦白的方式给新工作流找入口。做一个功能时，他没有先开 IDE，没有先铺类名和目录，也没有先写几段试探性的代码。他先打开 Whisper，对着空白 markdown 把这个功能该怎么工作一路说出来，再把那段语音丢给 Codex，让它先写 spec。
"我只是打开 Whisper，把这个功能该怎么工作一口气说出来。"
下一步也很直接。他再把 Codex 指向那份 spec 文件，说一句“Build it”，然后让它开工。Ryan 已经做软件工程二十多年，他很清楚旧工作流的摩擦点在哪里：文档写完还要等评审，评审完还要再写代码，很多讨论卡在理论层面。如今那份 spec 不再只是会议材料，它成了 agent 的施工说明书。Ryan 的判断很明确：文档还会继续写，只是文档第一次真正开始驱动实现，工程师也第一次能把“先说清楚”变成一条可以复用的流水线。
为什么 AI 时代先要救 CI
Ryan 在 Notion 带一个 6 到 7 人的小团队，项目叫 Afterburner，目标非常硬：把公司的 CI 时间压到当前的四分之一。他坦白自己并不是基础设施专家，也不是 CI 专家，但他知道慢 CI 在 AI 编程时代会把整个组织拖住。以前构建慢，最多是工程师多等几轮；现在背景 agent、Codex、Claude Code 会并行跑任务， 一次等待会卡住整个验证回路，速度问题会直接变成 AI 采用问题。
"我不是 CI 专家，但我大概知道自己想要什么。"
这也是 Ryan 反复提到 DevX 的原因。团队里的人已经习惯用 agent 加速开发，如果 CI、预览环境、测试基建还停在旧节奏，AI 只会把瓶颈放大。一次测试队列堵塞，后面跟着的 PR、截图验证和回滚判断都会一起卡住。Claire Vo 在后半段点得很透：大团队如果还没有自己的 VM 策略和背景 agent 策略，现在就该补这堂课。Ryan 展示的 Afterburner 表面上在做 CI 优化，底层其实在做一件更大的事：给 AI 编程准备一条能承受高频提交、高频验证、高频回滚的跑道。
让站会 prep 从手工整理变成自动汇总
Ryan 展示的第一个具体场景，是每天开会前的 standup 预读。Notion 会先自动生成会议模板，随后一个 Notion AI custom agent 在后台接手：它读取过去 24 小时的 Slack 对话、刚关闭的任务、刚合并的 PR、昨天的会议记录，再通过 Honeycomb MCP 拉最新指标，最后按 Ryan 预先写好的格式生成一份 preread，直接发回 Slack。Ryan 还专门限制了它的权限，只让它查看项目数据库，不去改动全公司都在用的任务表。
"它会查看过去 24 小时的 Slack、关闭掉的任务、合并掉的 PR，还有昨天的会议记录。"
这份 preread 里有什么？有最新 CI 时长，有进度、有决策、有 bug、有风险、有反馈，也有待讨论的问题。Ryan 连输出格式都事先写清楚了，要求它简短、有条理，最好还带一点轻松语气。Ryan 说，他现在经常可以一直工作到开会前最后一分钟，完全不用再花一大段时间手工抄写状态。会议也随之变样了：团队不再按人轮流念“我今天做了什么”，而是围着一份已经聚好上下文的材料，直接讨论问题、决定取舍、确认下一步。高频会议没有消失，低质量汇报先被淘汰了。
20 分钟省下的，不只是 20 分钟
Claire 有一句总结很准：很多人会把自动化想成“每天节省 5 小时”的宏大叙事，Ryan 真正获得的，往往只是每天 20 分钟。但那 20 分钟原本最伤人的部分，不是时长，是反复切上下文。工程经理先看 Slack，再翻 GitHub，再抄任务，再改成适合会议的口气，脑子被迫在三四种界面之间来回折返。AI 没有替 Ryan 做战略判断，却把这段最耗神的搬运活接走了。
"你的 AI、你的 agent，不会因为你在开会前 5 分钟让它做这件事而抱怨。"
Ryan 还提到一个很少被认真讨论的点：这种自动 prep 其实也是一种 burnout 保护。会议前的大量整理工作通常没有成就感，却最容易让人提前疲惫。现在 agent 先把信息拉平，他进入会议时已经拿到结构化材料，团队的精力可以放在决策、问题和风险上。AI 在这里没有制造神话，它只是把“人肉拼接状态”这件事收掉，让高频会议终于像会议，而不是一场集体抄作业。
在 Notion 评论区里 @Codex，就能换来一个 PR
第二个场景更像很多工程团队马上会抄的玩法。Ryan 他们内部做了一个系统，项目名叫 Boxy，本质是一组装好了 Codex 和 Claude Code 的小型虚拟机。工程师不必先在本地拉环境，再手动跑一堆命令，而是在 Notion 任务评论里直接 @Codex，把需求、截图和边界条件写进去，Boxy 就去后台开工。Ryan 举的例子很轻：朋友给他发短信，说想给 Notion 的 tab block 增加“copy link to tab”。他打开任务页，写了四句描述，贴了一张截图，又顺手补了几个 URL 落地时的边角情况。
"再过 10 分钟，它回了我一个 PR 链接和一个预览地址。"
Ryan 还专门翻了时间戳：10:40 到 10:51 开始实现，再过 10 分钟，PR 链接和 preview URL 就回来了。更让他惊喜的，是 agent 不只提了代码，还在 PR 里附上自己的测试说明和 UI 验证截图。对工程组织来说，这比“生成几百行代码”更有价值，因为它把一条完整的闭环露出来了：需求入口在 Notion，执行环境在后台 VM，交付形态是 PR，验证证据跟着代码一起出现。工程师没离开自己的主工作流，却已经把外包对象从人换成了 agent。
新世界代码评审，先说“我看不懂”
Ryan 讲代码评审那一段很有意思。PR 里有一处类型相关的改动，他看不懂，就直接留言：“我不知道这里在干什么，这不太对。”换到旧世界，这种话发给同事很容易变成情绪和防御；发给 agent，却成了最有效的 debug 方式。对方没有介意，而是回了一段解释，顺手把类型问题也修了。Ryan 甚至说，自己最近常故意把 prompt 写得很直白，因为只有先承认“不懂”，才会逼 agent 把隐含步骤摊开。
"我真的不知道这里在干什么。你得像给 5 岁小孩讲一样给我解释。"
Claire 顺手调侃，说 Codex 没有 Claude Code 那种“嘿朋友我替你搞定了”的温柔语气，Ryan 反倒很喜欢。因为在他看来，代码评审最稀缺的是把事情快速讲清楚。agent 愿意接收“我不懂，解释一下”的反馈，工程师就能更频繁地暴露自己的盲点。那种过去容易被面子、资历和沟通成本挡住的问题，现在更像是普通的迭代动作。AI 没有取消 code review，它把 code review 从社交阻力里拽了出来。
spec 进仓库后，文档第一次成了可执行资产
Ryan 展示的第三条主线，就是这期标题里的 spec-driven development。那份 spec 已经超出简短需求说明的范围，它是写进仓库、带着代码指针、行为说明和验证计划的工程文档。文档底部甚至明确写了 verification：测试怎么过、CLI 怎么跑、Notion AI 自己该怎么被拉起、要向它发哪些查询、最后应该看见什么结果。Ryan 说，第一次完整跑下来花了几个小时，他回来做了 code review，自己又玩了一遍，感觉是对的，就放行了。
"spec 就是事实来源。"
更重要的是，这份 spec 进了版本控制。Ryan 可以回看 spec 怎么演化，也能把它当作这部分 Notion AI 功能的 change log。代码当然也有历史，但纯代码很难让市场、运营、其他团队快速理解“这项能力现在到底怎么工作”。写进 repo 的 plain English 文档就不一样了：agent 能读，工程师能查，别的团队也能拿去转成对外说明。Ryan 还提到，他们专门做了 CLI，让 agent 能在 ask mode 和普通模式之间切换，并把交互转录拉出来复盘。很多公司以前也写设计文档，Ryan 的判断是，过去它们停在会议等待区里；现在它们第一次真的变成了工程资产。
工程师还得继续写代码，但重心已经变了
Ryan 最后给出的判断，可能是整期里最值得抄进团队共识文档的一句：工程师会越来越像系统思考者和架构师。人当然还要继续写代码，Ryan 自己就是“我管理人，也继续写代码”的状态，但人的重心会从大量手工 plumbing 挪到另外几个更难外包的部分：场景边界有没有想清楚，spec 有没有把行为写实，验证回路是否足够硬，agent 在不确定时有没有工具自证。 如果验证还是模糊的，第一件该补的是让 agent 能自己跑起来的工具，把自测链路先搭出来，再回头打磨 prompt。
"我把我们的工作看成是在变成系统思考者和架构师。"
Ryan 还顺手拆掉了一个常见误解：spec-first 并没有给团队平白增加一层新负担。那些技术设计文档、规格说明和实现讨论，以前本来就在写，只是写完之后要排会、等 review、再去实现。现在人的注意力被推到了更值钱的位置，文档也从理论材料变成了执行入口。Claire 在结尾的复盘很简洁：别再手工准备会议；从你最常工作的地方直接 @ 背景 agent；把 spec 放进 repo，改功能时先改 spec，再让 agent 回头改代码。Ryan 说她总结得很准确。对很多工程团队来说，这已经不只是一个 demo，而是一条可以开始迁移的工作流。
写在最后
Ryan 这期最有价值的地方，在于他没有把 AI 编程说成神秘魔法，而是把工程组织里最具体的几段路重排了一遍：prep 自动化、PR 后台化、spec 可执行化、验证前置化。工具还会继续变，团队角色也会继续变，但有一件事越来越清楚了：谁能把需求说清楚、把验证写清楚、把工作流接顺，谁就更容易在下一轮 AI 工程里跑得更快。如果你今天就在带团队，可以先挑一段最重复的流程试一次，像 standup 预读、任务评论触发 PR、或者把一份老设计文档改写成可执行 spec。先打通一小段，再把整条链路慢慢换掉，阻力会小很多，团队也更容易跟上。
内容来源："Spec-driven development: the AI engineering workflow at Notion"丨How I AI（嘉宾：Ryan Nystrom）