7年踩坑后顿悟：AI时代唯一死不了的能力，和产品经理抢饭碗

2019年做一个功能需要7步，2026年只需要1句提示词。但当所有人都能20分钟出代码，什么能力反而更值钱了？

HackerRank一位干了7年的工程师最近摊牌：他靠"产品工程思维"拿下晋升，代码能力在团队里排不上号。这不是谦虚——在GPT-4o已经量产的今天，会写代码的遍地都是，知道该写什么的成了稀缺品。

从1.9M次测试里挖出的真相

他经手的Test Creation Experience覆盖190万场技术测评。表面看是个UI工具，帮招聘方快速组卷。但数据暴露了一个反常识现象：用户卡住的点根本不是"界面难用"。

recruiters（招聘专员）真正的问题是——他们根本不知道好的技术题长什么样。

团队最初的方向是优化表单验证、简化操作流程。这些改动做完，留存纹丝不动。直到有人提出一个奇怪的问题：如果用户连"好题目"的定义都模糊，界面再流畅有什么用？

后来上线的不是新按钮，而是一道推荐引擎。输入岗位名称，系统自动匹配历史验证过的高区分度题目。这个功能让创建测试的完成率跳涨，而它的核心代码复杂度，远低于被砍掉的那批"体验优化"。

这位工程师后来读到Gergely Orosz的《The Product-Minded Software Engineer》，感觉像被人扒了工作日记。文章列的每一条特质——主动提产品想法、端到端功能 ownership（所有权）、用用户问题当北极星——全是他日常干的事。

他把这篇文章甩给经理当晋升答辩材料。结果证明，当AI抹平了技术实现门槛，"懂业务"比"懂技术栈"更能区分工程师的层级。

2019年的" friction（摩擦）"其实是保护伞

七年前想上线一个功能，流程长得让人窒息：写技术方案、排期开发、测试上线、收集反馈、迭代优化。动辄数周的周期里，团队被迫反复问自己：这事值得吗？

这个 friction 是个粗糙的过滤机制。它筛掉了大量拍脑袋的需求，也让工程师有时间观察用户到底在骂什么。

2026年的 Claude 可以在20分钟内把一段描述变成可运行代码。摩擦消失了，判断力的训练场也跟着消失。一位工程师的原话：「现在任何人都能构建任何东西。能活下来的不是提示词写得更好的，是知道什么值得构建的。」

他见过太多" brilliant（聪明绝顶）"的工程师，能把数据库查询从200毫秒优化到2毫秒，却从没问过这200毫秒是不是用户真正在意的痛点。AI加速的是执行层，但执行层加速十倍，方向错了只会让你更快撞墙。

产品工程 vs 软件工程：一个类比

传统软件工程像是在问：这把椅子怎么造得更结实、更便宜、更快出厂？

产品工程是在问：用户坐这把椅子是要吃饭、办公，还是临时歇脚？如果TA其实需要站着干活，你造出全世界最好的椅子也是库存。

HackerRank那套测试系统里，最值钱的代码从来不是性能优化。是那个藏在推荐引擎背后的判断——识别出用户说"界面难用"时，真正想表达的是"我不知道好题目长什么样"。

这种能力没法被AI替代，因为它依赖对具体场景的深度浸泡。你需要见过足够多的用户访谈、足够多的失败功能、足够多的"我以为TA想要X，结果TA其实要Y"。

2025年11月即将出版的《The Product-Minded Engineer》又把这个观点加固了一遍。作者Drew Hoskins的核心结论和Gergely Orosz三年前写的一致：最有影响力的工程师，是对产品本身有执念的人，不是对代码有执念的人。

一个正在发生的分化

AI工具的普及正在制造两条职业路径。

一条是"加速型"——用Cursor、Claude、Copilot把产出量翻十倍。这条路的尽头是内卷：当所有人都能十倍速交付，十倍速就变成了新的基准线，溢价归零。

另一条是"判断型"——在十倍速的世界里，守住"什么值得做"的决策权。这条路越走越宽，因为方向判断的复杂度没有随工具进步而降低，反而因为选项爆炸变得更难。

那位HackerRank工程师的观察很直白：现在工程师Shipping的速度史无前例，却越来越多人困惑"为什么我的功能没落地"。他们能构建任何东西，回答不了的是：我应该构建什么？

这个gap（缺口）就是产品工程的定义空间。

他最后提了一个细节。团队曾经花三个月开发一套高级报表系统，功能完备、性能优异，上线后使用率不到5%。复盘时发现，目标用户每周只看一次数据，而且只需要三个数字。那个被砍掉的三个月，如果用来问清楚"你打开报表后下一步做什么"，结局会完全不同。

AI把"三个月"压缩成了"三天"。但问对问题的能力，压缩不了。

当提示词工程师的岗位描述开始泛滥，你觉得招聘方真正想买的，是更快的代码生成，还是更准的需求翻译？