做产品这几年，被工程师挑战是家常便饭。"这个实现不了"、"你这个设计逻辑不对"、"这个技术上行不通"。
以前我的第一反应是：我是不是技术学得不够？如果我懂代码，是不是就不会被这样挑战了？
但后来我发现，这个反应本身就是个误区。
先把"技术挑战"拆成两种
被工程师质疑需求，其实有两种完全不同的情况，不能混为一谈。
第一种：可行性挑战。"这个需求实现不了。"
这个时候，工程师可能是对的，也可能只是当前周期做不了，也可能是他理解错了你的需求。不管哪种情况，你需要的不是比他更懂代码，而是能追问："哪里实现不了？限制来自哪一层？是模型能力的边界，还是数据不够，还是时间成本问题？"
这种问题不需要你懂实现细节，但需要你对系统有基本的心智模型，知道应该往哪个方向问。
第二种：方案挑战。"你这样设计是错的。"
这里有个容易踩的坑：如果 PM 太深入实现细节，很容易跟工程师在技术方案上产生争论——"应该用 LangGraph 还是自定义 pipeline？"、"这里应该用 streaming 还是等全部生成再返回？"
但这个争论本来就不属于产品的主场。你应该回答的是"为什么产品要这样设计"，工程师应该回答的是"怎么实现"。如果 PM 开始在技术方案层面争论，大概率是越界了。
可行性挑战：正确的接法
下次工程师说"这个实现不了"，试试这几个问题：
"帮我理解一下，限制具体在哪一层？是模型能力的天花板、框架的约束、数据问题，还是时间和成本？"
"如果这一期做不了，有没有可以先验证产品假设的简化版本？"
"这个限制是永久性的，还是说换一种方案或者等模型迭代之后可以解决？"
这几个问题问出来有两个效果：一是你把对话拉回到了产品目标层面，不是在争技术方案；二是工程师会感受到你在认真理解约束，而不是蛮不讲理地坚持需求。
这比你说"我看过 LangGraph 源码"更有说服力。
建立技术可信度，靠的不是学更多代码
很多 PM 有一个误解：觉得自己技术学得越深，在工程师面前就越有底气。
这个逻辑不完全对。工程师对 PM 的尊重，很大程度上来自"这个 PM 能把需求说清楚、能定义清楚验收标准、能做合理的取舍"——不是来自"这个 PM 也会写代码"。
更准确地说，如果一个 PM 开始在技术实现上跟工程师抢话语权，工程师反而会不舒服，因为这是在越界。
PM 的技术可信度来自几件具体的事：
能说清楚产品目标是什么、不是什么。 "这个模块的核心目标是让用户在 30 秒内拿到摘要，准确率 90% 以上，可以有标注不确定的降级，但不能出现完全编造的内容。"这句话说出来，工程师就知道你在想什么，也知道什么地方可以有弹性。
能在边界问题上做出判断。 当工程师问"这里要不要加人工确认"，你能说清楚"这个场景的错误成本高，加确认；那个场景的处理量大，不加确认但要加标注"——这种判断能力，才是 PM 的核心价值。
能提前想到失败场景。 AI 产品里，工程师最烦的不是需求改变，是"上线了发现没考虑到某个边界情况然后甩锅"。如果你在写 PRD 的时候就已经写清楚了各种失败路径和降级策略，工程师会觉得这个 PM 靠谱，自然减少挑战。
你真正需要的，是在对话里把主场拿回来
总结一下，面对技术挑战，PM 最重要的能力不是技术深度，而是能把对话拉回产品目标这个主场。
工程师说"这个实现不了"，你的回应是把问题定位到"哪层受限"和"怎么降级验证"。
工程师说"你这样设计是错的"，你的回应是把问题拉回"产品目标是什么、为什么需要这个设计"。
只要你能清楚地回答"我们要解决什么问题、成功的标准是什么、不可接受的失败是什么"，你在产品决策上就有足够的底气，不需要靠比工程师更懂代码来建立权威。
「AI 时代产品经理转型」系列第四篇。下一篇聊另一个经典困惑：Agent 框架那么多，到底应该学哪个？