你招到了一位天才工程师。专业第一，精通多门编程语言，全栈开发信手拈来，闭着眼睛都能优化数据库查询。你给他配了市面上最贵的AI编程工具。
六周后，他崩溃了。AI写的代码"烂透了"，产出垃圾，幻觉频发，指令当耳旁风。与此同时，走廊尽头的产品经理——十五年前辅修过计算机科学——却在不断产出令人惊艳的概念验证，功能实打实上线。
问题不在智商或技术。这是一种工程教育几乎不教、资深工程师往往被动习得的能力，而产品经理每天都在刻意练习。
翻译的艺术
产品经理活在"利益相关者想要什么"与"工程师能造什么"的夹缝中。他们的工作是翻译。粗暴概括：PM负责"做什么"和"为什么做"，工程师负责"怎么做"和"何时做完"。
利益相关者说"让它更快"，PM得拆解：是页面加载？事务吞吐？还是价值实现时间？为什么重要？有哪些约束？成功标准是什么？把这些清晰传达，工程师才能估算工期、做对事情。PM要懂用户语言以理解需求，也要懂技术语言以定义成功、验证结果。
这和用AI一模一样。
你给大语言模型写提示词，不是在写代码。你在写需求文档，定义预期产出，交代约束条件、目标、边界场景和质量门槛。你在为一位能力极强、极度字面的执行者做产品管理。
五项核心PM技能直接迁移：
• 需求定义：你到底要什么？不是模糊描述，要精确
• 上下文设定：AI需要了解什么问题背景、现有系统、约束条件？
• 验收标准：怎么算做对？
• 迭代打磨：初稿不是终稿，反馈循环至关重要
• 利益相关者沟通：用对方能理解的方式解释需求
习惯接收规格说明书的工程师，突然要自己写时往往卡壳。产品经理已经写了多年。
老员工的隐性红利
每一轮技术浪潮都遵循可预测的模式：初期红利属于年轻原生代，他们没包袱、敢试错；但当技术成熟、进入企业主流，优势转向能将其与真实业务场景结合的人——这些人通常年纪更大、行业经验更深。
AI编程工具正在跨越这道鸿沟。代码生成能力趋于稳定，差距体现在谁能提出好问题、设定好边界、判断好结果。这不是编码竞赛，是需求工程竞赛。
那位十五年前学过CS的产品经理？他的技术底子够理解可行性，而他的PM训练让他擅长把模糊意图转化为可执行指令。AI成了他的杠杆，而非障碍。
对企业而言，这意味着人才评估体系需要重置。招"AI工程师"时，别只看LeetCode分数和框架熟悉度。看看候选人能不能写一份让实习生也能执行的需求文档，能不能在信息不全时推进决策，能不能把"更快"翻译成可测试的指标。
这些能力过去被归为"软技能"，在AI时代成了硬通货。
热门跟贴