产品经理该懂多少技术
“产品经理要不要懂技术”是一个问错了的问题。懂技术不是一个开关：会写代码不等于能做产品判断，不写代码也不意味着只能描述页面。
更有用的问题是：为了对产品结果负责，产品经理必须独立作出哪些决定；为了不替工程编造答案，又必须理解哪些机制和边界。
对 AI 产品来说，这条线比过去更重要。模型、知识、工具、状态和评测共同决定结果，任何一层都可能把产品承诺变成一句空话。
技术理解的目标是作决定
产品经理不需要凭空指定向量数据库、队列或模型参数，但应该能回答：这个问题为什么需要 AI，哪一部分适合确定性规则，哪一部分需要语言模型，知识从哪里来，工具能改变什么现实状态，失败后用户去哪。
如果一项技术知识不能改变范围、优先级、风险、成本或验收，它通常不是当前最该学习的内容。反过来，只要某个机制会改变用户承诺，产品就不能以“这是技术细节”为由完全跳过。
技术深度的衡量标准，不是术语数量，而是能否把机制翻译成产品决定。
至少看懂六个责任层
第一层是任务：系统本轮要完成什么，什么情况必须拒绝或暂停。
第二层是数据与知识：事实来自哪里，哪份最后算数，版本、权限和删除如何治理。
第三层是模型与生成：输出为什么有不确定性，上下文和 Prompt 能解决什么、不能解决什么。
第四层是工具与外部动作：调用会产生哪些副作用，重复、超时和部分成功怎样处理。
第五层是状态与运行：长任务如何等待、取消、恢复，模型重启后凭什么继续。
第六层是评测与治理：怎样定位 Bad Case，哪些指标支持发布，哪些风险必须硬阻断。
产品经理不必实现每一层，却要知道每一层对用户结果承担什么责任，以及缺失时会出现哪类失败。
能问出机制问题，比会复述架构名更重要
面对一个技术方案，我通常更关心这些问题：
- 正确结果依赖哪些前提，哪个前提现在只是猜测？
- 多份数据冲突时，系统按什么决定，谁是 Owner？
- 工具超时后，我们知道它没做，还是只知道没回？
- 用户取消时，哪些动作可以停止，哪些已经不可撤销？
- 模型、知识或规则升级后，用什么回归证明没有伤到旧能力？
- 成本变高来自模型调用，还是重复检索、人工复核和失败重跑？
这些问题不会替工程选实现，却能暴露方案是否真的覆盖了产品承诺。
共同对象比跨角色猜测更有效
产品和工程协作，不应该依赖一方学会另一方所有工作。更有效的是共同维护几类可读回对象：任务合同、输入输出结构、关键状态、测试集、运行 Trace 和版本包。
任务合同让范围一致；结构定义让接口可验收；状态让异常有去向；测试集把“效果好”变成可判样本；Trace 帮助找到第一次偏离；版本包让一次结果能被复现。
产品提供业务语义、用户边界和决定标准，工程提供实现约束、失败机制和可观测证据。共同对象把两边的判断连在一起，也减少“产品写方案、工程猜需求”的来回。
不要把会写代码误当成技术判断
代码能力当然有价值。它能帮助产品快速验证、理解约束，也能降低和工程沟通的成本。但一个原型跑通，不代表权限、并发、恢复、监控和长期成本已经成立。
同样，一个人熟悉最新模型和框架，也不代表他能判断用户是否需要、数据是否允许使用、失败是否可承担。工具熟练度解决制作问题，产品技术判断解决责任问题。
最危险的状态不是不懂，而是用一段可运行代码或一张架构图掩盖尚未决定的业务边界。
一条更实际的学习路径
与其按技术名词从底到顶学习，不如沿一次真实任务向下追。
先画用户从触发到结果的流程，标出关键对象和状态；再追每个事实来自哪里、每个工具改变什么；随后为缺输入、超时、重复和取消设计恢复；最后建立评测、监控和回退。
每学一个机制，都把它转成一项产品产物：状态图、真源表、失败矩阵、工具合同或验收样本。这样技术知识会进入决策，而不是停在笔记里。
边界是：懂到能负责，停在需要证据的地方
产品经理应该懂到能识别未知、提出正确问题、写清产品规则、理解工程取舍，并用证据验收结果；不应该在缺乏技术真源时替工程承诺架构、性能和实现细节。
这不是降低技术要求，而是把要求放回正确位置。AI 产品需要的不是一个会背完整技术栈的产品经理，而是一个能把用户、业务、模型和系统约束连成同一条决策链的人。