这半年，公司一直在推进 Cursor 自动化编程，Token 由公司统一报销。表面上看，这是一种“工具升级”；但如果往深一点看，它其实是在推动一种新的研发协作方式。

公司希望通过 AI 编程提效，把原本重复、机械、低价值的工作交给 AI，释放研发人力，让大家把更多时间投入到真正重要的事情上，比如方案设计、业务建模、技术决策和复杂问题处理。

过去半年里，我也一直在高频使用 Cursor，对它的能力边界、适用方式和实际价值有了比较直观的认识。与此同时，我也在持续关注 AI 编程领域的一些新方向。最近比较让我感兴趣的，是 Claude Code 生态里一个叫 Ralph 的自动编排工具。

它给我的最大启发不是“它有多强”，而是它背后的思路：

AI 不一定只能是一个被动响应的聊天助手，它也可以被组织成一个持续推进任务的工作流。

这件事让我开始认真思考一个问题：

既然我们已经在用 Cursor，为什么还要把它限制在 GUI 对话框里？它有没有可能进一步变成一个可编排、可循环执行、可持续推进任务的系统？

我的答案是：有，而且很值得尝试。

为什么我开始研究“编排”

日常用 Cursor 的时候，我越来越明显地感受到一件事：

它已经很好用了，但更多时候仍然是“半自动”。

比如，一个稍微复杂一点的需求，往往还是这样的流程：

1. 人先整理需求
2. 手动把任务喂给 AI
3. AI 完成后，人再检查结果
4. 再把下一个任务继续喂给 AI
5. 中间还要不断补上下文、纠偏和约束行为

这种方式当然已经比纯手工开发快很多，但它本质上还是“人在驱动 AI”，而不是“AI 在流程里持续工作”。

如果只是单次问答式编码，这没有问题。
但如果想让 AI 真正参与更完整的研发流程，比如从需求拆解、到任务执行、再到结果验收，那么只靠 GUI 交互就会显得很吃力。

于是我开始想，能不能把这套过程做成一种脚本化、自动推进的编排机制。

也就是让 AI 不再只是“写一段代码”，而是能在一个明确的流程里承担不同角色，围绕任务持续协作，直到整件事完成。

我的设计：三个角色，形成一个最小闭环

基于这个想法，我给整个流程设计了三个核心角色：

• planner
• implementer
• verifier

这个拆分并不复杂，但非常贴近真实研发流程。

planner：负责拆解任务

planner 的职责不是写代码，而是读需求、拆任务、标边界、给出执行顺序。

它更像一个会看 PRD 的项目经理或技术负责人。
当拿到一个需求时，它先把问题拆成更小、更清晰、更可执行的任务单元，再交给后面的角色处理。

这一步非常关键，因为如果任务拆不清，后面的执行就会越来越混乱。

implementer：负责具体实现

implementer 是真正干活的角色，负责把任务做出来。

考虑到真实研发里前后端分工差异比较大，我没有只保留一个 implementer，而是继续细分成了两个方向：

• 前端 implementer
• 后端 implementer

这样做的好处很明显：
每个子智能体只关注自己所在的技术域，减少无关上下文干扰，也更符合团队实际协作方式。

verifier：负责验收和校验

verifier 可以理解为质量保障角色。

它不是简单看一句“完成了没有”，而是要判断：

• 实现是否符合需求
• 前后端联调是否一致
• 是否遗漏关键点
• 是否存在明显风险
• 是否真的可以被标记为完成

如果说 planner 负责“把事情讲清楚”，implementer 负责“把事情做出来”，那么 verifier 负责的就是“确认这件事到底做没做好”。

整个流程其实很简单

这套编排流程，用一句话概括就是：

先拆任务，再执行任务，再验收任务，通过后继续推进下一个任务，直到全部完成。

也就是：

需求拆解 -> 执行实现 -> 验收校验 -> 标记完成 -> 继续循环

从流程设计上看，它其实是在模拟一个简化版的软件研发闭环，只是把原本由人承担的一部分角色，交给了 AI 来完成。

这也是我觉得它有价值的地方。
因为我们不是在追求“AI 帮我多写几行代码”，而是在尝试让 AI 进入一个更接近真实交付过程的工作模式。

为什么 Cursor SDK 是关键

如果只停留在 Cursor 的图形界面里，这件事很难真正成立。

原因很简单：
GUI 更适合“人和 AI 的交互”，但不适合“程序去驱动 AI 连续执行流程”。

而我真正想做的，不是一个只能人工触发的辅助流程，而是一个能自动循环推进的编排系统。

这时候，Cursor SDK 的意义就出来了。

它让 Cursor 不再只是 IDE 里的一个聊天窗口，而是变成了一个可以被脚本调用的能力模块。
一旦有了 SDK，我们就可以做很多原本 GUI 难以完成的事情，比如：

• 用脚本自动向不同角色分发任务
• 自动传递上下文和提示模板
• 自动接收执行结果
• 自动标记任务状态
• 自动继续推进下一个未完成任务
• 对整个执行过程做日志留存和结果追踪

换句话说，Cursor SDK 把“人工驱动 AI”这件事，变成了“程序驱动 AI”。

而这两者之间，差的并不是一点点效率，而是系统能力的级别差异。

提示词模板，不是配角，而是基础设施

在这次实践里，我越来越强烈地感受到一件事：

Prompt 模板绝对不是随便写几句提示那么简单，它其实是整个编排系统的基础设施。

因为一旦进入自动化流程，AI 就不能再像平时聊天那样，依赖人随时补充说明。
这时候，它必须靠模板来明确自己的身份、职责、边界和输出规范。

所以我也按角色分别设计了三套模板：

• Planner Prompt Template
• Implementer Prompt Template
• Verifier Prompt Template

这些模板的核心目标，不只是告诉 AI “要做什么”，更重要的是告诉它：

• 你是谁
• 你的职责范围是什么
• 哪些事情不能做
• 输出结果要遵循什么格式
• 你和上下游角色如何衔接

比如，implementer 就不能“顺手改配置”“顺手重构无关代码”“超范围实现需求”；
verifier 也不能只是给一句模糊评价，而应该给出明确的验收结论、风险项和未验证项。

这部分看起来像细节，但其实决定了整个系统能不能稳定跑起来。

我做了一个 Demo，结果是可行的

基于这套思路，我让 AI 先读了 Ralph 的代码和设计方式，再结合 Cursor 的特点，生成了一版适合当前场景的 TypeScript 编排脚本。

随后我做了一个测试 Demo，验证结果比我预期的更好一些：

这套思路是能跑通的。

至少从最基本的流程上看，已经能够做到：

• 根据需求拆解任务
• 按角色调用子智能体执行
• 对任务状态做流转管理
• 对执行结果进行留存
• 在任务完成后继续推进后续任务
• 在出现问题时回看过程并重新执行

这意味着，它已经不只是一个概念验证，而是一个具备继续工程化演进潜力的原型。

真正的难点，不是“能不能跑”，而是“能不能稳定跑”

虽然 Demo 已经验证了可行性，但实际用下来我也越来越清楚：
真正难的，不是调用 AI，也不是把流程串起来。

真正的难点在于：

如何让这套系统稳定、可控、可追踪地运行。

目前暴露得最明显的问题，还是在提示词规范和角色边界上。

比如：

• implementer 有时会改动本不该动的配置
• 实现任务时可能顺手处理了需求之外的内容
• verifier 的验收结论有时还不够稳定
• 不同角色之间的输出格式如果不统一，自动衔接就会变脆

这些问题本质上说明了一件事：

自动化编排的核心挑战不是“接上 AI”，而是“约束 AI”。

谁来做什么，做到什么程度，什么不能做，失败后怎么重试，输出格式怎么统一，状态怎么流转，日志怎么留存，这些工程化细节才是真正决定成败的地方。

重视“留痕”

除了流程本身，我这次还特别重视一件事：任务执行过程的留痕。

每个任务执行后，我都会保留对应的标记和文档。
这样做的原因很现实，因为一旦系统开始连续跑任务，就必须考虑后续的问题排查和过程追踪。

这些留痕可以带来几个非常直接的好处：

• 出问题时能快速回溯是哪一步出了偏差
• 某个任务失败后，可以单独重新执行
• 可以复盘 AI 在执行过程中常见的错误模式
• 有助于不断优化模板、角色边界和编排策略
• 让整个过程从“黑盒执行”变成“可观察、可审计、可复盘”

我觉得这点非常重要。
因为如果一个自动化系统只能产出结果，却无法解释过程，那它在真实研发环境里很难被长期信任。

可以把执行完成后整理成对应的报告.

这件事最让我兴奋的，不是写脚本，而是看到了一种新可能

这轮实验做下来，我越来越觉得：

Cursor 不应该只被当成一个 GUI 里的 AI 编程助手。

如果只停留在“打开 IDE，输入一句话，让它帮我改几行代码”这个层面，它当然已经很有价值；
但它真正更大的想象空间，可能在于：

• 接入 SDK
• 引入角色分工
• 做任务拆解
• 建立循环执行机制
• 加上状态与日志管理
• 最终形成一个可以持续推进研发任务的自动化编排系统

这件事并不一定要一开始就做得特别复杂。
完全可以先从一个最小可行版本开始，只解决三个核心问题：

• 任务能不能拆清楚
• 流程能不能自动循环
• 结果能不能被可靠追踪

只要这三个问题成立，后面的稳定性、约束力和工程化能力，都是可以逐步增强的。

最后

这次尝试，对我来说并不是简单“复刻一个 Ralph”。

更准确地说，它是一次基于 Cursor 能力边界、团队使用习惯以及实际研发需求的重新组合和再设计。

我想验证的，不是 AI 能不能多写一点代码，
而是：

我们能不能把 AI 从一个被动响应的工具，逐步变成一个围绕任务持续协作的系统能力。

如果这条路走通，带来的改变可能不只是“编码更快了”，而是研发流程本身会发生变化。

而这，可能才是 AI 编程在团队落地后更值得期待的地方。