作者寄语：最近深度打磨 AI Native 开发工作流后，我发现大部分人用 Cursor 或 Claude 时，都存在两个极端：

要么像带实习生一样，每走一步就要喂一句提示词，累得要死；
要么彻底放飞 AI，结果它一口气改了 50 多个文件，直接把项目改崩。

核心问题在于：我们没有给 AI 建立「研发全生命周期的状态机」。

今天分享的这套 【自主推进式 Agent 提示词骨架】，是把大厂敏捷开发、TDD 特征测试、和主程序员评审制完美融合后的终极产物。

把这段提示词丢进 Cursor或 Claude Code，你就可以真正退居二线，只在核心决策点当「架构师」拍板决策。

这套骨架为什么能降维打击？

普通 Prompt 是在教 AI 怎么写代码，而这套骨架是在教 AI 怎么当一个合格的资深开发。它有四大核心突破：

• 🚦 完美的状态机停顿机制：AI 不会一口气干完所有事。在现状确认、需求拆解、方案设计、前端改造等关键节点会主动停下来，等你拍板。
• 👁️ 第零步「反降智」防御：强制要求先确认产品现状，避免重复造轮子。
• 🧱 隐式 WIP Limit（单次产出限制）：后端改造按批次执行，跑通测试后再继续，防止长上下文崩溃。
• 📸 前端视觉留存仪式：改前端前必须先截图，极大降低样式错乱风险。

终极自推进 Agent 提示词骨架（可直接复制使用）

使用方法：新建功能时，把下面整段内容复制到 Cursor 或 Claude 中，替换 [把 leader 的一句话需求填这里]，然后执行即可。

我刚拿到一个新需求：[把 leader 的一句话需求填这里]

完整跑通改造流程，全程自主推进，遇到关键决策点停下来等我，不要每一步都问我。请按以下顺序执行：

第零步：现状确认 (必做，不能跳)
- 提醒我打开浏览器、按需求路径点一下产品看现状
- 等我确认 "功能不存在" 才能进下一步
- 如果功能已存在，停下来让我重新评估改造方向 (新增 vs 重构 vs 优化)

第一步：拆需求
- 读 docs/ + CLAUDE.md + 现有代码
- 按六维写需求文档草稿到 docs/requirements/<feature>.md
- 列出所有 "待产品决策" 的边界场景和 "不在这次范围里" 的候选
- 停下来等我反馈业务目标修正、边界场景决策、范围决策

我反馈完后：
- 整理为正式 PRD 文档定稿

第二步：拆方案
- 摸链路 (含前端) + 列改造点 + 画流程图 + 说影响 + 说步骤
- 整合成 solution.md，第 7 节 "待审核的关键决策点" 单独抽出来
- 停下来等我审核 solution.md 第 7 节 + 反馈调整

我反馈完后：
- 更新 solution.md 把决策落定

第三步：后端改造
- 锁现有行为 Characterization Test 先跑
- 按 P01-P03、P04-P05、P06 三批小步执行，每批跑通后才下一批
- 任何 Characterization Test 失败立刻 stop
- 补单元测试覆盖关键边界
- 跑 mvn test 全套，告诉我总测试数 + 失败数

第四步：前端改造 (先停下来让我截图改造前)
- 告诉我前端入口位置 (菜单路径)，等我截图改造前
- 改完前端，跑构建确认无报错
- 等我浏览器验证

第五步：文档自动更新
- api-list.md / data-model.md / requirements/<feature>.md / CLAUDE.md 全部同步更新

自主原则：
- 每步跑完自己 review 输出质量，不合格自己重跑
- 失败自己 debug 自己修 (除非连续 3 次同一错误)。每次 debug 修复前，必须先通过 git diff 检查自己是否越界修改了非本 Slice 相关的代码。
- 测试断言凭实际不凭应该
- 不要重构现有方法，只调用
- 关键决策点停下来等我，不要替我拍板

跑完输出 summary.md，列每个产出文件 + 我应该重点 review 的地方。

真实落地效果

我在复杂 Java 后端项目中跑通这套骨架后，最直观的感受是：

1. git diff 极其干净：由于「禁止重构现有方法」和「debug 前检查 git diff」的硬约束，AI 改动精准如外科手术，几乎没有多余改动。
2. 真正成为架构师：你不再当打字员和校对员，只需要在关键节点给出方向性决策，例如：“E04 null 视同空串，E07 允许查 diff，下期再加缓存，继续执行。”

这种全局掌控感，才是 AI 时代高级工程师真正的核心竞争力。

最后：

你在用 Cursor 做敏捷开发时，有哪些特别好用的「人机协作卡点」技巧？

欢迎在评论区分享你的 Prompt 骨架或实战经验，一起把 AI 生产力继续拉高！