获课：shanxueit.com/11580/

研发总说"做不了"，产品总说"这很简单"，中间差着一门翻译课

我在一家做AI产品的公司待了三年，观察到最消耗团队能量的，不是技术难题，不是需求变更，是研发和产品之间那段永远填不平的认知鸿沟。产品说"这个功能用大模型应该很简单吧"，研发翻了个白眼说"你根本不懂技术难度"。研发说"这个需求技术上行不通"，产品转头就跟老板说"研发能力不行"。

两边都是聪明人，但说的根本不是同一种语言。

这种撕裂在我经历了好几个项目之后才慢慢找到解法——不是让产品学会写代码，也不是让研发学会写PRD，是让两边对"大模型能做什么、不能做什么、做到什么程度算好"有一个共同的基础认知框架。 这个框架不需要很深，但需要一致。而这份一致，靠的是"技术通识"。

第一条认知：产品说的"智能"和研发理解的"智能"不是同一个东西。

产品看到ChatGPT侃侃而谈的样子，觉得"大模型什么都能干"。研发看到的是Token概率预测、上下文窗口限制、幻觉率、推理成本。产品想象的是一个全能的虚拟员工，研发面对的是一个"有时候很聪明、有时候蠢得离谱"的概率模型。

弥合的第一步，是让产品理解大模型的"能力边界图"。 哪些任务大模型天生擅长（文本生成、信息提炼、多轮对话），哪些任务它天生不擅长（精确计算、复杂推理、实时决策），哪些任务它勉强能做但需要大量工程手段兜底（结构化输出、知识问答）。这张图不需要讲技术原理，只需要讲"能"和"不能"的边界。产品理解了边界之后，提需求的时候就不会再说"这个应该很简单"，而是会问"这个需求在能力边界内还是边界外、边界外的话需要多少工程代价才能补上"。

第二条认知：研发说的"做不到"很多时候是"成本不允许"，不是"技术上不可能"。

大模型时代很少有"完全做不到"的事——你舍得花钱、花算力、花时间，大部分需求都能硬堆出来。研发说"做不到"，翻译过来往往是"按照现有的资源、时间、成本约束，做不到你期望的那个程度"。

弥合的第二步，是让研发学会用产品的语言表达成本。 不要说"这个技术难度太高做不了"，要说"要做到你期望的准确率，需要增加两类训练数据、多跑两轮评测、预计工期比你现在给的时间多三周"。把"做不到"翻译成"做到需要什么代价"，产品就能在自己的优先级列表里做判断。不是每个需求都值得付出那个代价，但这个判断必须建立在"代价清晰"的基础上，而不是"研发说NO就NO"的模糊地带。

第三条认知：什么是"好"，两边定义完全不一样。

研发眼里的"好"是推理速度快、显存占用低、精度指标好看。产品眼里的"好"是用户用了说"这个功能真灵光"。这两个"好"之间有时候是正相关的，更多时候需要取舍——为了精度牺牲速度，用户嫌慢；为了速度牺牲精度，用户嫌笨。

弥合的第三步，是建立统一的效果评估框架。 不只用技术指标（准确率、召回率、推理延迟），也不只用用户反馈（满意度、留存率），而是把两者绑在一起看。每次迭代之后同步更新"技术指标变化"和"用户体验变化"两张表，让两边的人在同一份数据上讨论"这次迭代是好了还是坏了"。数据不撒谎，但数据要放在桌面上让所有人都看到。

第四条认知：需求变更是常态，但变更的原因需要被看见。

产品迭代过程中需求经常变，研发最烦的就是"做了一半突然改方向"。但产品改需求往往有他的理由——市场反馈变了、竞品出了新功能、老板临时有了新想法。这些理由研发看不到，看到的只是"又要改代码"。

弥合的第四步，是把"需求变更的上下文"透明化。 每次变更需求的时候，产品不只是丢一个新PRD出来，而是同步附上"为什么变"的一两句话说明。不是长篇大论的论证，是"上周灰度测试发现用户在这个环节困惑率偏高，所以调整了交互路径"。研发看到了理由，就不再把变更当成"产品又在瞎折腾"，而是当成"解决了一个真实问题"来配合。

第五条认知：大模型项目的"不确定性"是所有认知鸿沟的放大镜。

传统软件项目里，研发说"这个功能三天搞定"，三天基本上能搞定。大模型项目里，研发说"这个功能三天搞定"，三天后可能效果一塌糊涂，需要再调一周Prompt和参数。这种不确定性让产品觉得研发在"拖"、在"不靠谱"，让研发觉得产品不理解"这不是传统开发"。

弥合的第五步，是把"探索型任务"和"执行型任务"明确区分开。 前者打"探索"标签，工期是预估值、效果是预判值，需要边做边调整；后者打"执行"标签，按传统项目管理的节奏走。两个标签用不同的颜色标记在项目进度表上，产品看到"探索"标签就知道这里的进度条可能会动，研发看到"执行"标签就知道这里必须精确交付。把不确定性的源头摆到明面上，比藏着掖着等爆发要强得多。

最后，回到"技术通识"这个主题。 我参加的那期大模型技术通识课，核心内容不是什么高深的理论，就是一张能力边界图、一套效果评估框架、一个"探索VS执行"的项目分类方法。这些东西技术深度极浅，但它在研发和产品之间搭了一座桥。桥通了，大家才能站在桥中间互相看见对方的岸。

研发和产品的认知鸿沟，不是靠"一方妥协于另一方"来弥合的，是靠"双方共同站在一个更高的地方看同一张地图"来弥合的。通识课的价值，不是让产品变成研发，也不是让研发变成产品，是让两个角色都学会对方的语言、理解对方的约束、在同一个坐标系里讨论问题。坐标系对上了，沟通就顺了。沟通顺了，项目就稳了。