@media print{*{color:#000!important;background:#fff!important;border-color:#000!important}}
述职报告 · Web · 高级产品经理 · Z-MAX 具身智能工厂
岗位：高级产品经理 — 场景定义 · 技术选型 · 风险评估 · 协助项目落地
协同对象：与研发工程师(研发工程师)商量技术实现边界 · 与硬件工程师(硬件工程师)对齐真机数据接口 · 与CEO/市场确认场景指标和商务策略
周期：2026年7月-2026年8月
工作概述：将光模块工厂5大精细操作场景从口头需求落地为可量化、可交付、可用于供应商招标的产品定义体系。产出场景工艺规格书(50+物体时空定义)、技术规格书(含BOM成本26-40万/ROI 1.5年回本)、供应商合作方案(三模式·五痛点)、产品大屏原型(8机器人+5场景实时监控)。研发工程师据此明确模型训练目标(抓起8/8·插入7/8)，CEO据此推进商务洽谈，供应商(TARS)据此确认合作意向。
一、工作目标（4项全部达成）
| # | 目标 | 产出 | 落地验证 |
|---|
| 1 | 场景定义：将5大光模块操作场景转化为精确产品规格 | scene-spec.html — Z700自车坐标系·50+物体(X,Y,Z)时空定义·场景1的9步时间线(T+0→T+57.4s) | 研发工程师据此搭建3D仿真(scene-3d.html)·场景1的6s节拍定义指导模型训练目标 |
| 2 | 技术选型与产品形态：确定Z700产品方案 | z700-spec.html — 移动底盘+双臂+四区工具箱·BOM 26-40万·售价40-65万·ROI两班1.5年回本·RK3588芯片选型 | CEO据此对外报价·研发工程师据此确认算力边界(≤20TOPS) |
| 3 | 供应商合作方案：建立对外技术合作框架 | supplier-model.html — 甲方(智蜂)·乙方·三模式(包人/合作/预训练)·五痛点·相机三档可选 | 乙方(TARS)确认"清楚了"·商务谈判推进 |
| 4 | 项目落地监控：产品大屏原型监控全场景运行 | factory-dashboard.html — 8机器人(速度/节拍/负载/温度)+5场景(S1-S5)+实时Orin API | 产线demo演示用·CEO向客户展示用 |
二、核心问题（What/Why/How，按严重性降序）
问题1：场景需求从"说不清"到"可量化"的信息转化鸿沟
What：初期向供应商描述"FW Loading场景"时，对方的反馈是"不知道具体要做什么"——"插拔"两个字无法传达对位精度±0.1mm、力控≤2N、9步动作序列、≤6s节拍的完整要求。CEO也无法向客户展示产品全貌。
Why：根本原因——光模块工厂的工艺知识高度专业化(金线键合193根/板、AuSn共晶焊280°C、透镜AA耦合±1μm)，供应商无工厂背景。产品经理面临的核心挑战不是"缺乏信息"，而是"信息的组织方式"——如何把工厂语言转化为供应商和客户能理解的语言。
How：四层产品文档体系：①最外层(supplier-model.html)：用"五痛点表"建立共情(定位不准/响应慢/成本高/适应慢/协同差)，用"甲方乙方"框架确立数据主权边界；②中间层(scene-spec.html)：定义统一坐标系(自车系原点·+X前+Y左+Z上)，将5大场景50+物体逐一标注时空坐标；③核心层(z700-spec.html)：从场景需求反推产品规格——节拍要求→末端速度计算→整机重量约束；④监控层(factory-dashboard.html)：每个机器人的速度/节拍/负载/温度实时可见。研发工程师据此明确"模型要达到什么指标"，CEO据此推进供应商谈判。
问题2：产品定义中"写死参数"与"可协商"的边界冲突
What：初版供应商合作文档把技术参数写死(state[6]+camera 320×240+action[6]+模型专有名词ACT/W2-VLA)，CEO当场指出"不要把内部研发参数暴露给乙方"。R&D反馈"相机800万像素你写320×240太死了"。
Why：产品经理犯了一个典型错误——将研发内部的技术实现参数(模型input shape)直接写入对外产品文档。乙方不需要知道"模型内部是几维"，只需要知道"兼容什么相机、能控制几个轴、节拍多快"。写死参数 = 锁死供应链选择 = 削弱议价能力。
How：三次迭代：①删掉全部模型专有名词(ACT/W2-VLA/39D/4D)，统一用"模型"或"动作模型/引导模型"；②相机改为"中(320×240)/高(640×480)/超清(1280×960)三档可选·最高800万像素"；③臂从"6轴"改为"6/7轴臂"；④所有硬性数字改为"协商为准"(参考值＜100ms·具体以产线节拍协商)。结果：供应商拿到的是可协商的技术需求书，而非写死的技术参数表。CEO一次通过。
问题3：产品原型与研发实现之间的命名空间断层
What：产品大屏显示的机器人名(Z700-1/Z100L-2)在研发的3D仿真代码中根本不存在(内部用Z4 AOI/R3/M1/W1)。老板问"大屏上的机器人在3D工厂里哪？"，无法回答。
Why：产品原型和研发实现两条线独立迭代——产品经理用"用户友好名"(便于客户理解)，研发用"内部dev名"(便于代码维护)。缺少统一的命名空间和映射表。
How：①逐行阅读研发的factory-3d.html源码(987行)，提取robotDefs实际名称。②产品侧全部机器人重命名为Z4 AOI/R3/M1/W1/Z700-I215/Z700-FW，与研发对齐。③推动建立统一产品命名表(Z700/Z700F/Z100L+AGV A1-A4)，写入z700-spec.html。④要求研发工程师的Orin心跳API增加scene/action字段，使大屏能显示当前作业场景。结果：产品与研发的命名体系统一，3D仿真中的机器人名称与产品大屏一致，老板可以指认"这个R3就是大屏上那个"。
三、最有挑战的KPI指标（产品经理牵头主导）
KPI 1：供应商合作方案的转化率 — 从"听不懂"到"清楚了"
挑战：乙方(上海它石智航/TARS)是专业的具身智能公司，但完全没有光模块产线背景。如何用一份文档让乙方在30分钟内理解5大场景全貌？
方案：supplier-model.html不按"技术架构→模型选型→性能指标"的研发逻辑组织，而是按"工厂痛点→场景需求→三模式合作→技术接口(可协商)"的产品逻辑组织。开篇用五张痛点表建立共情，中段用5大场景卡片列出"组装零件+功能说明+原子动作"(如"光隔离器：微型磁环件·防止反向光反射·左右各一件")，末段给出三模式商业路径(包人/合作/预训练)，推荐"模式二·合作"——甲方数据不外发，乙方提供模型包部署到甲方本地平台。
结果：乙方确认"这篇文档我们看清楚了"。CEO用这份文档向潜在客户做产线工艺介绍。文档同时作为技术协议v3的产品附件。
KPI 2：Z700产品定义的完整性 — 从"具身复合机器人"到"40-65万报价"
挑战：CEO需要一份能直接拿去报价的产品规格书。需要同时回答：长什么样(800×600×700mm工具箱+两端臂)、多重(≤250kg)、用什么芯片(RK3588 6TOPS)、成本多少(26-40万)、卖多少钱(40-65万)、回本多久(两班1.5年)、和谁竞争(五菱移动底盘/节卡臂/欧姆龙AOI)。
方案：①产品形态设计：参考货车箱货理念，单箱集成ABCD四区(料盘/固件/光学/电气)，两端各预留臂安装法兰(1臂或2臂可配置)。②BOM成本对标：逐项列出移动底盘(6-8万·参考五菱工业)、协作臂×2(10-15万·参考节卡Zu7)、AOI模组(2-3万·参考欧姆龙VT-M12)、固件诊断仪(2-3万·参考是德科技示波器)、RK3588主板(0.3-0.5万)。③ROI计算：两班替代2人(年省24-30万)÷售价45-55万=1.5-2.3年回本。④与研发工程师对齐算力边界(≤20TOPS)，确认RK3588(6TOPS NPU)可满足。⑤每项成本来源有行业对标，非凭空编造。
结果：CEO确认40-65万报价区间。乙方的技术协议v3中引用本规格书的BOM和形态定义。
KPI 3：场景工艺规格书的时空精度 — 从文字描述到精确坐标
挑战：光模块产线精度跨越三个数量级——料盘搬运±0.5mm→插拔对位±0.1mm→透镜耦合±1μm。文字描述("对准EVB插槽")无法传达这种精度差异。
方案：scene-spec.html首次定义Z700自车坐标系(原点=车体中心·+X前+Y左+Z上)，5大场景每个物体标注(X,Y,Z)m坐标。场景1拆解为9步时间线(T+0→T+57.4s)，每步标注起点状态、终点状态、速度(m/s)、力控阈值(N)。研发工程师据此搭建3D仿真(scene-3d.html)，9步动作严格按时间线执行。
结果：用户可逐帧对比产品定义与仿真执行。场景1的6s节拍预算成为研发工程师训练模型的硬约束目标。
四、经验总结
- 产品"三件套"驱动对外沟通：场景工艺规格书(给研发)+技术规格书(给市场)+供应商合作方案(给乙方)，三份文档覆盖"做什么→怎么做→谁来做"的产品全链路。一份纯算法文档无法替代这三件套。
- 写死参数 = 削弱产品弹性：对外文档中的技术参数应给出"可选档位"和"上限值"，而非"精确数值"。内部研发参数(模型维度)不应暴露给乙方。从"state[6]+320×240"到"相机三档可选·协商为准"，是产品思维从"展示研发成果"转向"提供合作接口"的关键转变。
- 坐标系是多方对齐的公共语言：产品定义、研发仿真、用户验收三方的沟通成本，在统一坐标系建立后断崖式下降。一旦有了共同的空间参考系，"机器人应该在哪个位置"不再需要5轮文字沟通。
五、自我审视与规划
优势
- 跨域翻译能力：能同时用工厂语言(金手指/EVB子板/AuSn共晶)、产品语言(节拍/精度/成本/ROI)和商务语言(甲方乙方/三模式/协商为准)描述同一件事。CEO用我的文档对外沟通时无需二次翻译。
- 从模糊到精确的产品化能力：能将"搞个插拔场景"的口头需求，转化为"场景1·T+2.9s·模块对准QSFP插座·偏差<0.1mm·力控≤2N"的精确产品定义。
- 快速原型验证：2小时内可将需求转化为可点击的产品原型页面，用于向CEO/客户/供应商演示。
劣势
- 研发深度的局限：不直接参与模型训练和真机调试，产品规格中的性能目标(如抓起8/8·插入7/8)来团队发工程师的研究成果。我对"这个指标是否可达"的判断依赖于与研发工程师的沟通而非第一手实验。
- UI实现停留在原型阶段：产品页面由我直接用HTML/CSS编写，缺少专业UI设计工具的参与。Figma/Sketch等工具链的缺失限制了产品原型的视觉质量。
一年规划
- Q1(3个月)：推动完成5大场景全部3D仿真页面(scene-3d.html?scene=handle/aoi/aging/thermal/ats)。建立统一的API契约版本号机制——研发工程师的Orin心跳格式变更时同步更新版本号。
- Q2(6个月)：基于研发工程师的真机测试数据(抓起8/8·插入7/8真实力控值、节拍实际值)，反推更新产品规格书中的性能指标(从仿真预算值→真机实测值)。建立供应商开发门户:supplier-model.html→JSON API→一键下载场景定义。
- Q3(9个月)：引入Figma设计工具，将产品原型与UI实现解耦。产品文档增加英文版，支持海外供应商对接。
- Q4(12个月)：基于首个量产项目积累的产品数据，输出"光模块具身工厂产品需求白皮书"，形成可复用的行业产品定义方法论。
六、工作环境评价
团队协作：三人分工高度互补——我(产品定义+原型验证+供应商对接)、研发工程师(模型研发+算法验证+工程化交付)、硬件工程师(真机测试+硬件接口+数据采集)。协同模式为"产品提需求→研发评估可行性→产品调整规格→硬件验证"。三方通过飞书群实时同步。
协作中的摩擦：①研发工程师的API格式(如Orin心跳sys字段)偶有变更，产品端需反复适配。②产品原型页面由我直接编写HTML/CSS，文件被git push覆盖时修复成本高。
瓶颈：①真机(Orin)仅硬件工程师可控，产品经理无法直接验证场景定义与真机表现的一致性。②缺少专职UI/UX，产品原型的视觉质量受限于我个人的HTML/CSS能力。
建议：①每周安排2小时真机验证窗口，让产品经理和研发工程师都能看到实际运行效果。②建立API契约版本号——格式变更时同步更新，前端自动适配。③引入Figma或即时设计工具。
述职人：Z-MAX 高级产品经理 · 2026年8月