过去 6 个月里找上我们的每一位 CTO，说的都是同样三个字：“我们试过 Cursor

过去 6 个月里找上我们的每一位 CTO，说的都是同样三个字：“我们试过 Cursor。” 他们给工程团队买了许可证，在 Slack 上发了公告，可能还做了个 15 分钟的演示。 然后就等着生产力提上去。 三周后，真正用起来的人只剩下寥寥几个工程师。其余的人都回到了老样子，照旧写他们的代码。 董事会还是要在第 3 季度前拿出一份 AI 战略。 每次都是同一个套路。没人界定过哪些该让 AI 碰、哪些保持人工。没人衡量过开发速度到底有没有变化。没有资深工程师为这次推行负责。工具就这么冒出来了，还被指望能直接好用。 50 个人拿到了一件工具。零个人拿到了一套工作流。 Cursor 不是你的 AI 战略。Copilot 也不是。Claude Code 也不是。 一位熟练使用 Cursor、且有一套清晰操作体系的高级工程师，交付速度能快 2-3 倍。 一位只用 Cursor、没有任何防护机制的新手工程师，交付的 bug 数量是前者的 2-3 倍。 同样的工具，截然相反的结果。 差别在于它周围的脚手架：约定、分区、度量。 动手之前，你得先有一个基线。 团队现在交付速度有多快？ 有多少比例的代码是 AI 生成的？ 每次提交的成本是多少？ 如果事前没法度量，事后就没法向董事会证明任何东西。 那你就需要划分区域。 80% 的任务完全适合交给 AI：样板代码、CRUD、测试。 20% 需要副驾模式，由工程师主导。 0% 保持手动：认证、支付、架构。 工程师在写提示词之前就定好分区。 不是之后。 然后你需要按周做测量。 速度会变，做法也会变。 不看观点，只看数字。 “我们试过 Cursor”不算失败。这恰恰是那些最终把 AI 落地做对的团队最常见的起点。工具只占这项工作的 5%。 围绕它的操作系统才是另外那 95%。大多数公司买了个许可证，就管这叫战略。而那些交付速度快了 2-3 倍的团队，是先把这个体系搭起来的。