很长一段时间里，人们对AI编程的想象都停留在那个固定的姿势：一个程序员坐在屏幕前，对着侧边栏的对话框敲下一行自然语言，然后盯着机器一行行往外吐代码。这种交互方式固然直观，对单兵作战也确有奇效；可要是公司的代码库日益膨胀，或者团队试图把那些枯燥的修bug工作自动化，这套高度依赖人工点击的流程也就成了真正的卡点。于是不少人开始手搓脚本，试图把大模型的API和本地的Git命令硬绑在一起，结果多半是在处理上下文、工作区状态和工具链调用时碰了一鼻子的灰。我总怀疑，那个仿佛无所不能的聊天框，不过是技术演进过程中的一块过渡踏板罢了。

Cursor背后的团队大概也看穿了这一点，他们近期推出了TypeScript SDK，并同步放出了一个名为Cursor Cookbook的代码仓库。市面上收集提示词的废纸篓项目固然不少；而这套仓库提供的是将代码智能体从本地编辑器里拽出来、转化为可调用系统构件的底层图纸。借着这套SDK，开发者只需要几行代码就能在自己的应用或脚本里召唤出`composer-2`或其他前沿模型。智能体既可以在本地的工作目录里跑，也可以直接丢进Cursor托管的云端沙盒虚拟机里运行。在这个Cookbook仓库里，他们交出了几个相当具体的演示：一个能从终端直接唤醒智能体的极简命令行工具，一个用于追踪和管理云端智能体状态的看板，以及一个用来快速生成项目脚手架的Web应用。

这些例子的分量，在于它们把那些大多数团队根本不想从头编写的脏活给标准化了。当一家公司试图把AI程序员塞进CI/CD流水线时，大模型的推理能力固然是一道门槛；但在实操层面，真正把人难住的，往往是周边的脚手架究竟该怎么搭。你要怎么让模型安全地连接到线上的PostgreSQL数据库？怎么把Model Context Protocol（MCP）服务器无缝整合进工作流？Cookbook给出的解法很直接：在云端执行时，你可以配置智能体克隆指定的代码库、切出分支、修复问题，并顺手把`autoCreatePR`的开关打开。它会在后台把执行状态持续推流回你的系统，开发者大可以离开电脑，等事情做完再凭着任务ID去提取结果。于是，AI摆脱了那个只能一问一答的客服角色，开始真刀真枪地在后台执行完整的工程任务。

流水线上的效率固然能借此跃升；而更深层的变动，在于软件开发的组织形式正在发生转移。以前人们总爱把AI叫做副驾驶，暗示方向盘还死死攥在人类程序员手里。但Cookbook里展示的这些能力，分明是把智能体当成了可以批量部署的无头劳动力。不管是自动审查合并请求、直接把Issue转化成代码提交，还是在代码构建失败时自动去修补错误，智能体都有了自己独立的工作区和生命周期管理。当然，这种全自动的愿景目前也并非毫无瑕疵，就连他们自己的文档里也老老实实列出了一堆局限，比如内联的MCP服务器状态还无法跨任务持久化，或者本地智能体没法直接下载生成的文件。可这些终究只是工程实现上的小磕绊。

当编写代码的机器自己变成了一串可以被调用的代码，甚至堂而皇之地接管了自动化测试和部署的节点，程序员的日常也就随之变了味道。过去那种在键盘上逐行推敲的乐趣势必会遭到进一步的压缩；取而代之的，是成天忙于配置权限、审批那些由机器自动生成的代码。代码编辑器正在慢慢变成一个纯粹的调度中心。

https://github.com/cursor/cookbook