Notion 里随手 @ 一下 Cursor，它自己规划写测试还开了个 PR，我盯着这条链路有点出神
哈喽，我是飞飞。
这两天我看到一条消息，盯着它出了会儿神。Notion 用 Cursor 那个 SDK，几周就把一个编码 agent 嵌进了自己的产品里。现在你在 Notion 的文档里 @ 一下 Cursor，或者在讨论串里提它一句，又或者往数据库里指派一个任务，它接到之后就自己干起来：规划、构建、测试、验证，全程跑完，最后给你开一个 PR 出来。
我天天用 Claude Code 改自己的真实仓库，这条链路的每一步我都熟得不能再熟。可把它们这么一口气串起来、还塞进一个写文档的工具里，我心里咯噔了一下。
先说清楚，这里的 Cursor SDK 不是那个编辑器
容易混的地方先掰开。大家平时说的 Cursor，是那个 AI 编辑器，你打开它写代码、让它补全、跟它对话。这次的主角是 Cursor SDK，跟那个编辑器是两码事。
简单说，SDK 是一套给别的产品用的开发工具。Cursor 把自己那套编码 agent 的能力封装成了一个 TypeScript 库，别人拿去就能把「一个会写代码的 agent」直接嵌进自己的产品、自己的基建、自己的工作流里。官方的说法是，你拿到的是跟 Cursor 生产环境里同一套 harness、同一批模型、同一个 runtime，开箱就是一个全栈编码 agent，不用自己从头搭一整套基建再慢慢养。
所以 Notion 这事的形态是这样的：Notion 没有自己造一个编码 agent，它是借了 Cursor 的能力，包了一层壳，让你在 Notion 的界面里就能调起来。Cursor 自己博客里有个细节我觉得挺关键，Notion 搭的其实是一套 provider 无关的外部 agent 框架，Cursor 只是作为其中一个实现接了进去。换句话说今天能接 Cursor，明天理论上能接别家的同类能力。Notion 那边的一个讨论串，对应的就是一个 Cursor 的 agent 会话，串里发的每一条消息，就触发一次 agent 运行。
这套东西他们说从零到一个完整集成，就花了几周。我盯着「几周」这两个字看了半天。
这事真有用，得先把这一半认下来
我不想一上来就摆出一副老程序员对着新东西念叨危险的样子。这个方向是对的，我得先把它认下来。
写代码这件事，过去有一道天然的门槛：你得会写。哪怕只是改个文案、调个配置、加个小功能，发起这件事的人通常也得懂点技术，至少得知道去哪个仓库、怎么提 PR。这道门槛把很多人挡在外面。产品经理在文档里写了一句「这个按钮的逻辑能不能改一下」，这句话要变成代码，中间隔着好几道手，得有工程师接、排期、动手。
现在 Cursor SDK 这种东西，是把「会写代码的能力」做成了一块可以嵌的积木。Notion 把它嵌进自己的文档流，意味着一个完全不写代码的同事，在他天天用的协作工具里，随手 @ 一下，就能发起一个真实的代码改动。这是实打实在降门槛。能力从工程师专属的 IDE 和终端里走出来，变成任何产品都能调的一个调用，这个趋势我是认的。
而且 Cursor 把链路做到了端到端。它不会给你写半截代码、再撂给你自己接着补，而是规划、构建、测试、验证一条龙跑完，把结果落成一个 PR。我自己天天跟 coding agent 打交道，最烦的就是它写一半撂挑子，让我接手一个半成品。能把「测试」「验证」这两步也包进去自己跑，光这一点就比很多半吊子方案靠谱。
我犹豫的，是那个 PR 该不该合的判断躲不掉
把价值认完，我后背那点凉意才能说清楚。
我天天用 Claude Code 改代码，最有体感的一件事是：写代码真正费劲的，从来不是把字敲出来。前阵子我把一个七千行的 SpringBoot 项目从 Java 迁到 Kotlin，一个任务来回改几十次，agent 手是快，但真正占我时间的是 review。它改完一版，我得逐行看它有没有把空判抹平、有没有把逻辑改岔、有没有顺手把 git 历史写乱。对齐我到底想要什么、给它兜底，这些活全在我这。
现在 Cursor 这套东西，把「产出一个 PR」这一步也自动化了。规划、写、测、验，它替你跑完。可是你注意，它替你跑完的是「产出」，不是「判断」。那个 PR 摆在你面前，能不能合进主分支，这个判断没人替你做。
这就是我出神的地方。agent 从一句模糊的文档 @ 出发，自己规划、自己写、自己测、自己开 PR，中间我一步都没盯着。等我看到它的时候，它已经是一个完成态的 PR 了。我敢不敢直接点那个 merge？
我赖以吃饭的活就是改真实仓库，我太知道一个看起来跑通了测试的 PR，跟一个真能合的 PR，中间隔着多少东西。测试绿了不代表它没在别处改坏点什么。它也可能压根没领会你那句模糊指令背后真正想要的，或者在某个边角偷偷埋了个雷。agent 把「写出来」做到了端到端，但「这玩意能不能要」的那一刀，还是稳稳落回人头上。
越是非技术同事发起的 PR，我越得睁大眼
更让我在意的是入口这件事。
我用 Claude Code 的时候，发起人是我自己，我知道我想要什么，PR 出来我对着我的意图去验，再不济我也读得懂每一行 diff。这是离我最近的入口。
可 Notion 这种集成，把发起入口铺到了非工程同事手上。一个产品同事在文档里 @ 了一下 Cursor，描述还可能是大白话，agent 顺着这句话一路跑到一个 PR。等这个 PR 转到工程师手里要合的时候，问题来了：发起的人未必说得清他到底要什么，跑出来的 agent 也只是尽力理解了那句大白话，而最后按下 merge 的人，对这件事从头到尾的来龙去脉是最模糊的。
发起的人离代码越远，中间链路越自动，那个落在终点的「该不该合」就越重。这不是说这条路不该走，是说这道兜底的闸，得有人清醒地守着。
我顺手想到我自己流水线里一个东西。我之前真装真跑过国产的 MiMo Code，它有个我挺服气的设计：自己写测试，测试把自己的 bug 抓出来，读着报错自诊断，改完再验，一整个闭环能收敛。问题是那是在一个封闭、有干净反馈环境里。代码跑没跑通、测试过没过，机器自己能判。可「这个 PR 符不符合我们这个团队的取舍、要不要合」这种判断，没有一个干净的 test 能替你跑出来，它没法自动收敛，只能落到一个懂上下文的人身上。
门槛塌下来那一刻，我得自己补上一道闸
我对成本一直敏感。每个月给模型的钱不算少，让 agent 干个正经活之前，我都会下意识在心里过一遍秤，掂量值不值得动用最贵的那个模型。说白了，「贵」本身对我就是一道天然的闸，逼我省着用、想清楚再用。
现在 Cursor SDK 这种东西，把编码能力做成了便宜又好嵌的积木，门槛塌下来一大截。我的第一反应是兴奋，能力唾手可得，谁不高兴。第二反应是后背发凉：原本那道由「门槛」和「得懂技术」把守的闸松了，可代码该不该进主分支这件事的份量一点没变。闸松了，份量还在，那道闸只能我自己重新补上。
我手里现在的分法很简单。能让 agent 端到端跑出 PR，这步我乐意放权，让它跑，它跑得越完整我越省事。但合进主分支那一下，尤其是从我看不见的入口冒出来的 PR，我攥得很紧，宁可它停在那等我看一眼，也别帮我自动点了 merge。产出可以全自动，定夺这关，我还想自己过手。
把编码能力做成 SDK 嵌进各种产品，让不写代码的人也能在自己的文档流里发起一个改动，这是好事，我是真觉得是好事。我只是越来越清楚，agent 帮我们多走的每一步里，有些步它走得越远，那个最后拍板的人反而越得清醒。
说回到你们。如果哪天一个产品同事在文档里 @ 出来一个 PR，测试全绿、看着挺像样地落在你面前，你会直接合，还是非得自己从头捋一遍才敢点那个按钮？你心里那道兜底的闸，现在划在哪一步？评论区聊聊。