我是文科出身，代码只会写一点 Python 基础，模型原理也只懂个大概。而算法同学整天泡在代码、模型和数据里。这样的两个人，要怎么“好好说话”？我该怎么把需求清晰地递过去？
刚入职那段时间，沟通上我踩了不少坑：需求说得含糊、边界情况没想全、不会把“产品语言”翻译成“技术语言”……被算法同学问到答不上来的场面，也不是没有过。下面这五条建议，算是踩坑之后的总结。
建议一：把“我想要什么”换成“用户需要什么”
第一次提需求，我说的是：“加个 AI 自动摘要吧，用户看完长文章太累了。”
算法同学回了一句：“你怎么定义‘太累了’？”
我当场愣住了。
后来我才想通：产品经理嘴里的“用户需要”，在算法同学耳朵里是“你到底要我做什么”。在技术协作里，“用户需要”太虚了，没有人能对着它写代码。
所以我开始学着先把“用户需要什么”拆成具体、可衡量的行为描述，再翻译成技术语言：
❌ “用户看完长文章太累了，加一个自动摘要吧。”
✅ “用户在阅读2000字以上的文章时，停留时长显著下降。我们希望能提供一个摘要功能，把文章压缩到200字以内，让用户先快速了解内容再决定是否细读。”
把原因、要解决的问题、输出的边界都讲清楚，算法同学才能判断“这事能不能做、怎么做、优先级排多高”。
建议二：把边界情况想清楚，再去沟通
这一条是我被怼得最多的地方。
有一次我提了个需求：“当用户问的问题超出知识库范围时，模型应该回复‘我不知道’。”
算法同学问：“如果用户问的是‘你今天吃饭了吗’，这个算不算超出知识库范围？如果算，回复‘我不知道’合适吗？”
我：“……我回去想想。”
那次之后我学会了一点：去找算法同学之前，先把自己能想到的边界情况列一遍。
比如提“超出知识库怎么处理”这个需求，我会提前列好：
-
用户问的问题完全不在知识库范围内 → 回复“这个我暂时还回答不了”
-
用户的问题在知识库边缘（部分相关） → 用已有信息生成回答，并注明“根据现有资料……”
-
用户的问题包含多个子问题，部分超出 → 回答能回答的部分，超出部分做说明
边界想得越细，沟通效率越高。算法同学不是不愿意帮你想边界，而是更希望你先想完第一轮，他们来补第二轮。
建议三：学会说“人话”，也学会听“黑话”
这里说的“人话”，是相对算法同学的行话而言的。
刚入职时我常说：“这个功能要更智能一点。”说完自己都觉得空。
后来我改成：“这个功能要能根据用户的历史对话推荐相关内容。”——这就成了一个可以被讨论、被拆解的需求。
反过来，你也要听得懂算法同学的“黑话”：
-
“这个需求涉及模型重训” → 时间成本高，不是几小时能改完的
-
“需要高质量标注数据” → 你先去找数据/让人标数据，或者现有的数据质量不够
-
“推理成本有点高” → 做是能做，但每次调用要花钱，你要想好用户会不会愿意为它买单
-
“输出质量不稳定” → 模型有时候行有时候不行，你得考虑兜底方案
-
“目前没有成熟方案” → 这是一个研究问题，不是工程问题，别压排期
这些“黑话”我花了一两个月才慢慢摸清。先学会听，再学着说，你和算法同学的沟通效率会翻倍。
建议四：用“项目语言”对齐，而不是“技术语言”争论
这是一次很关键的认知转变。
刚入职时我有个误区：以为要和算法同学聊得来，就得懂他们的技术细节。于是我去啃模型架构、学怎么看 loss 曲线——后来发现，这不是产品经理该干的活。
产品经理的核心任务，是把复杂的技术问题翻译成项目推进语言。
比如算法同学说：“这个方案准确率只有85%。”你不需要跟他争论“85%够不够”，而是问：“如果提高到90%，大概需要多长时间？成本增加多少？如果我们先上线85%的版本，后续再迭代，这个方案可行吗？”
这三个问题一抛出来，对话就从“技术细节之争”被拉回到“项目决策对齐”，这才是产品经理真正该做的：不是替算法同学做技术判断，而是帮整个团队做项目决策。
建议五：对AI技术保持敬畏，但不必怯懦
文科生做 AI 产品经理，很容易滑向两个极端：
极端一：什么都不懂，不敢说话。开会的时候算法同学说什么就是什么，不敢质疑、不敢追问。结果上线之后发现功能跟预期不一样。
极端二：觉得自己是“老板”，什么都要按自己的来。完全不管技术可行性，拍脑袋定需求，最后开发推不动。
我的体会是，中间状态最舒服：
对技术保持敬畏：承认自己不懂细节，算法同学的建议要认真听
但不怯懦：不懂就问，“这个我不太懂，能解释一下为什么吗？”——这句话不丢人
同时坚守产品底线：“从产品视角来看，这个方案用户在操作上会有困惑，我们能不能调整一下？”
个人经验是：算法同学反而更喜欢“不懂就问、不装懂”的产品经理。跟这种人沟通省心——他知道你哪里不懂，会主动解释；你提的需求，他也会更愿意信任。
顺便说一句，尊重不是怕，是不随意挑战算法同学的专业判断；不怯懦也不是硬刚，是敢于用产品语言捍卫决策依据。
评论0