核心思考：产品经理的核心价值从来不是画原型或码文档，而是在混乱的现场抽象共性、在复杂博弈中划定边界；AI 可以作为极佳的原型沙盒与文案润色工具，但关乎业务生死的分寸感与语义精确度，永远只能由人来裁决。

01. 产研全流程的 8 个关键切片

在猎户星空负责服务机器人相关的产品工作期间，我完整经历了多个版本从需求萌芽到全量上线的周期。

在软硬件结合以及复杂的 B 端企业场景下，做产品的容错率极低。一个未被识别清楚的伪需求，或者一个定义模糊的交互逻辑，不仅会导致研发测试几百人天的人力浪费，甚至可能直接影响线下几十甚至几百台实体机器人的运行表现。

复盘这段高密度的实战经历，我把一个需求从诞生到最终落地的完整生命周期，提炼为 8 个环环相扣的标准化步骤：

  1. 需求分析：深度走访用户与现场，尤其紧盯那些给出负向评价的客户；
  2. 抽象问题：拨开现象迷雾，将诉求精准归属为系统能力层面的具体问题；
  3. 价值评估：从共性、覆盖度和商业回报（ROI）三个维度严格审视是否值得立项；
  4. 边界定义：决定这一轮迭代“做什么”，更要明确“坚决不做什么”；
  5. 流程设计：将复杂的业务诉求解构为环环相扣的确定性状态链路；
  6. 低保真原型验证：利用 AI 快速搭建交互草图，奔赴业务一线快速试错对撞；
  7. PRD 编写与人机协同：采用骨架先行、理工科简述与 AI 查漏润色的协同范式；
  8. 走查与闭环上线：紧扣原初痛点进行提测走查，确保交付质量不走样。

每一个步骤背后，都凝聚着真实的踩坑教训与认知升级。

02. 前半程：从混沌中抽象共性与划定边界

在流程的前半段，产品经理面对的往往是一片嘈杂混乱的信息迷雾。很多时候，客户或者业务一线反馈的只是情绪化的抱怨，比如“这个机器人太笨了，根本没法传图”。

这时，绝不能顺着客户表面提的要求直接改代码，而必须启动问题抽象： 客户说传图慢，是因为网络环境差，还是因为前端批量压缩逻辑有缺陷？之前有没有类似的接口已经支持？这是一个单纯的代码 Bug，还是底层架构设计时就遗漏了批量处理协议？

确立了问题属性后，紧接着必须进行极其冷静的价值评估（ROI 判断）：

  • 共性检验：这只是某一家特定客户的特殊偶发诉求，还是整个行业在机器人运营中的普遍痛点？
  • 能力边界：以我们现有的软硬件架构，能解决其中的两成、五成，还是能彻底闭环？
  • 商业跃迁：解决这个问题，能否帮助客户算得清投资回报率？更重要的是，它能否推动销售格局发生质变——从“每个客户试探性买一两台”，跃升为“核心客户愿意批量采购数十台乃至上百台”？

如果商业账本算不过来，哪怕技术实现再酷炫，也必须果断叫停。

当确认要做之后，真正的考验落在了方案权衡与边界裁决上。 以“批量上传图片到服务器”为例，方案 A 可以是工程上极其复杂的全自动容错流水线，覆盖十几种弱网断点续传；方案 B 可以是技术实现轻量、但要求操作人员增加一次手动确认步骤的折中设计。

选择哪一个？在产品早期，过度追求全自动常常会引入海量的边缘故障。优秀的做法是清晰定义本轮迭代的边界，果断剔除边缘诱惑，用最稳健的路径交付核心价值。

03. 后半程：AI 在产研协同中的真实位置

当流程进入原型与文档阶段，AI 工具的介入彻底改变了我过往的工作流，但也打破了我最初的幻想。

在低保真原型阶段，AI 堪称最高效的脑暴加速器。通过简短的自然语言输入，借助模型可以几秒钟拉出各种界面布局和交互状态草图。我拿着这些半成品原型直接找客户或提需求的同事确认，在极短的时间内不断修正偏离的理解，逼近真实的业务意图。

然而，到了编写 PRD（产品需求文档）阶段，我曾尝试过“甩手掌柜”式的偷懒做法——把原型图和流程一股脑扔给 AI，让它帮我直接输出完整文档。

结果令人大失所望。AI 生成的 PRD 充满了大量正确但空洞的大厂套话，而在核心逻辑处却严重失真。究其原因，通用大模型的思维模式与语义颗粒度，根本无法与具体团队的研发习惯、底层接口命名及系统约束对齐。

跌倒之后，我摸索出了一套被实践证明极其高效的**“人机三段式协同法”**：

  1. AI 搭建骨架：让 AI 基于我提供的背景和流程节点，梳理出结构严整的文档大纲与逻辑目录；
  2. 人类填写核心肉体：抛开繁文缛节，我用非常简练、高度结构化的理工科逻辑语言，亲自把业务规则、前置条件、状态转移与异常分支填入对应位置；
  3. AI 查漏与润色：最后再将初稿交还给 AI，让它作为挑剔的质检员，审视逻辑链条中是否存在未定义的死角，消除语言表达上的歧义，将其润色为开发和测试人员最易理解的规范表述。

到了研发测试阶段，我们在项目协同群中还尝试接入了智能 Agent。当开发在群里对某个临界状态提出疑问时，Agent 可以协助答疑并记录修改意见。但我始终坚持一条铁律：涉及 PRD 的任何变更，人工必须二次过目复核。 因为一旦底层语义理解出现细微偏差，代码实现的走向就会相差十万八千里。

04. 走查与闭环：回到原点检验业务承诺

评审结束后的一个月周期里，我们通常是半个月交付开发，半个月交付测试，周而复始。

但代码写完、提测通过，并不意味着产品经理的职责就此卸下。在正式发布的前两三天，最为关键的一环是产品走查。

在这个阶段，我会完全抛弃所有技术指标和流程图，把自己重新当成一个一无所知的真实客户，坐在机器面前去完整模拟一遍使用过程。

走查的灵魂拷问只有一个：我们花费整整一个月时间、耗费团队心血敲出来的这套新功能，到底有没有接住最初我们在用户现场看到的那滴眼泪、那句叹息？

做产品是一场从混沌现实出发、穿过理性逻辑推演、最终又重返现实世界的奇妙旅程。一个月一个版本，我们不断在推翻与重建中前行。

AI 改变了我们手中的画笔和刻刀，让我们搭建原型的速度快了数倍；但那张决定图纸通往何方的航海罗盘，永远掌握在敬畏现实、懂得倾听人心的产品经理手中。