2026 年，最早把「vibe coding」这个词带火的 Andrej Karpathy，站上台宣布它已经过时。他用来替代它的新说法叫 agentic engineering（智能体工程），并把它拆成一串动作：写设计规格、监督计划、审查 diff、写测试、搭评估循环、管理权限、守住质量。
把这串清单里的工程师术语去掉，再读一遍。决定该做什么；检查结果是否符合意图；定义「足够好」的标准，并拒绝低于它的东西上线。这根本不是什么新学科。正如 Jeff Gothelf 所说：做判断的那个版本，才是这份工作本身——它从来都是。 AI 只是把我们过去用来藏住它的地方，全拆掉了。
这是当下做产品的人最该记住的一个转变。而它指向的方向，多数人第一反应是「反常识」。
留下来的能力，不是写代码
过去十年，「学会编程」是所有有产品想法的人听到的标准建议。2026 年，这个建议悄悄反转了。当 AI 智能体能把一个说清楚的问题变成可运行的软件，写文档不再是工作本身——意图、清晰、判断，才是工作。 这一年真正重要的人，业界已经有了称呼，而且不是「提示词工程师」。Product School 的判断很直接：在 2026 年，真正算数的产品经理，是 AI 产品经理。
具体怎么干，也佐证了这一点。关于「AI 原生产品经理到底做什么」，业界的共识收敛成了三个动作：
- 描述：把你想要的东西说清楚到，一个有能力的智能体能照着动手。
- 拆解：把问题切成小到可以逐一验证的块。
- 判断：评估产出是否符合意图——并决定在那不符合的 15% 里，该怎么办。
这三件事，没有一件是写代码。三件，都是产品管理。
为什么不懂代码反而是优势
接下来这段听起来不对，但它没错。会写代码的人，脑子后台永远跑着一个估算：这玩意儿实现起来有多麻烦。 当你是动手的那个人，这个估算很有用；可当你是决定什么东西该存在的那个人，它就成了包袱——想法还没出口，就先被实现成本修剪、定型，而不是被用户价值。
如果你不会写代码，就没有这层条件反射。你手里只剩下开局最重要的那两个问题：用户到底需要什么？这个体验对不对？然后你的活儿，就是把它说清楚。而「把想法说清楚」，是产品经理最古老的看家本事。
这不是在为「不学」辩护。这是在说：瓶颈挪位置了。稀缺的不再是你在编辑器里敲字的速度，而是你所要求的那个东西，本身有多清晰。
「言出法随」是一套方法，不是凭感觉
但有个前提：vibe coding 拿到那份讣告，是有原因的。当你提示得很随意，每一次运行都会漂移——设计师们已经注意到，AI 原型填上了过去线框图占的位置，可同一个提示词每跑一次，结果都微妙地不一样，这种语义漂移会迅速放大。意图含糊地进去，产品就不一致地出来。
所以答案不是「把提示词憋得更用力」，而是带着纪律去做。这套纪律，我们叫它 DO AI PM，落到几条承诺上：
- 高保真优先。 跳过线框图，直接做能跑的真东西——真实内容、真实状态（加载 / 空 / 错误 / 成功）、真实交互——然后靠实际运行来验证它。一个能跑的原型，永远赢过一个被描述的原型，包括在做决定的那个会议室里。
- 五个阶段，小步走。 发现 → 定义 → 设计 → 开发 → 验证。在「定义」阶段，让 AI 先反问你，再写规格；在「开发」阶段，一次只改一件事。
- 一张安全网。 原型里不放真实密钥和生产数据；不可逆的按钮——发布、删除、付款——由人来按；不碰生产环境；拿不准，就问。
最后这串，正是「我撞运气蒙对了一个提示词」和「下周一我还能再做一次」之间的区别。
成果即证据
只会自我解释的方法，一文不值。所以这里的每一句，背后都是用同一套方法、用 Claude Code 做出来的真实产品：SoloMD（Markdown 编辑器）、Unterm（AI 能操作的终端）、unfetch（人和 AI 都能用的下载器）、StoryAlter（学你文风的 AI 写作助手）、Unflick（人和 AI 都能用的播放器）。你正在看的这个网站——八种语言、这个博客、那几页演示稿——也是用同样的方式「说」出来的，没有一行代码是手写的。
方法解释作品，作品证明方法。
Karpathy 没说错，vibe coding 结束了。可取代它的，不是一种更难的工程——而是「把决定做好、把意图说清」的纪律。这件事有名字，而现在，正是干这份活儿的好时候。
想真切体会一下「言出法随」是什么感觉，从 doaipm 方法论中心 开始。
本文首发于 doaipm 博客：doaipm.com/zh/blog/vib…
