今日目标

理解你不是“抛弃原经验转行”，而是在现有交易策略能力上增加AI产品的技术边界、评测和产品化能力。

核心正文

岗位转型最容易犯的错误，是只看到目标岗位的新名词，没有看到自己已经拥有的底层能力。你过去关注的派单、应答、补贴和驻店，本质上都属于决策产品：系统观察环境，预测不同动作的结果，在约束下选择一个动作，再根据结果更新策略。

一个完整的决策系统可以拆成六层：

1. 状态：现在有哪些订单、骑手、位置、时间、价格和容量。
2. 预测：某个骑手是否应答、多久到店、是否超时、未来还会来多少订单。
3. 候选：哪些订单与骑手组合在资格、时效、容量上可行。
4. 决策：在可行组合中，如何优化完单、人效、收入、成本与体验。
5. 执行：推送、派单、导航、兜底和配置发布。
6. 学习：通过日志、回放和实验判断策略有没有产生净增价值。

你已经在其中做过很多关键工作。例如，分析智能补贴时，你没有把“模型分数更准”直接等同于“业务更好”，而是继续看覆盖、折扣、成本、完单和置信度；讨论驻店派单时，你关心增量占用时间、未来损失订单、承接率和公共池兜底。这些都是AI产品需要的系统思维。

真正需要补的不是“会不会谈AI”，而是三种能力。

第一，技术分工。规则、预测模型、优化算法和LLM的能力不同。LLM适合处理语言、非结构化信息和开放意图；它不应替代高精度路线计算、约束检查和财务计算。

第二，概率型评测。传统功能通常能回答“按钮是否可点击”，AI系统还要回答“在什么样本上多大概率正确，错在哪里，错了能否恢复”。

第三，产品化。一次SQL分析或一次策略配置不等于产品能力。产品化意味着输入标准、过程可重复、结果可解释、异常可追踪、版本可比较，其他人不依赖原作者也能使用。

因此，你最适合的近期目标不是通用聊天产品，也不是纯机器人硬件，而是AI决策产品、智能运营产品、调度优化产品，以及机器人车队或云平台的软件产品。

业务映射

把“驻店派单”翻译成AI产品语言：

• 业务问题：有限驻店运力如何同时提升人效并守住承接率。
• 状态：订单池、骑手池、剩余路线、门店供需、SLA。
• 预测：完成概率、路线时间、未来订单量、超时概率。
• 优化：最大化净增完单或人效，同时满足承接和体验约束。
• Agent：理解分析问题、调用数据与回放工具、解释结果。
• 人工：审批实验、检查异常、决定是否灰度。

今日练习

用一页纸写出：

1. 我过去做过的三个决策产品项目。
2. 每个项目分别覆盖上面六层中的哪几层。
3. 哪些工作仍然依赖我本人临时分析，没有沉淀成产品能力。
4. 我的目标岗位暂定为什么。

推荐目标岗位表述：

“AI决策产品经理，聚焦物流、供需匹配、智能运营或机器人车队调度。”

自测题

1. 为什么你的派单经验可以迁移到AI产品？
2. 一次高质量分析与一个产品化能力有什么区别？
3. 你目前最需要补的三类能力是什么？

完成标志

• 写出目标岗位
• 完成三个项目的六层映射
• 找到一个最值得产品化的重复工作

今日目标

建立AI产业链地图，并理解不同层级的产品经理服务谁、创造什么价值。

核心正文

理解AI行业不能只按公司名单记忆，应该按价值如何流动来拆。一个简化的AI产业链包括五层。

第一层是算力与基础设施，包括芯片、云、训练与推理集群。核心价值是用可接受的成本和稳定性提供计算。

第二层是基础模型，包括语言、视觉、语音和多模态模型。核心价值是把大量数据中学习到的通用能力变成可调用的智能。

第三层是开发与治理平台，包括数据处理、模型接入、检索、评测、监控、权限、工作流和安全。它们解决的是“模型会做”到“企业敢用、能维护”之间的距离。

第四层是行业与职能应用，例如客服、销售、编程、法务、医疗、物流运营和数据分析。这一层不靠模型参数取胜，而靠场景理解、流程嵌入、数据闭环和结果责任。

第五层是交付与组织变革。很多企业买到模型后仍得不到价值，因为流程、权限、知识、指标和人员分工没有改变。产品必须回答谁使用、谁复核、错误谁承担、收益如何归因。

对产品经理而言，层级不同，工作重心也不同：

• 模型产品关心能力边界、开发者体验、吞吐、延迟与成本。
• 平台产品关心接入效率、可观测性、权限、评测和复用。
• 应用产品关心用户任务完成、流程改造、业务指标和留存。
• 行业解决方案关心交付、集成、客户ROI和复制成本。

你的积累最接近第三层与第四层交界：一方面理解业务决策，另一方面有机会把数据、回放、实验和策略配置做成平台能力。

AI带来的价值通常落在四种类型：

1. 替代：减少重复人工，例如自动生成日报。
2. 增强：帮助人更快更准地判断，例如诊断派单失败原因。
3. 创造：以前成本太高而无法提供的新服务，例如逐门店的策略建议。
4. 协同：跨系统执行多步骤任务，例如自动取数、回放、生成实验单并等待审批。

转型时要避免把自己定位成“会调用某个模型的人”。模型会更新，真正稳定的能力是识别价值所在的层级，并把数据、决策、执行和反馈连成闭环。

业务映射

以策略分析为例：

• 基础模型：理解“为什么昨天某门店人效下降”。
• 数据工具：查询门店、骑手和订单指标。
• 决策平台：选择诊断路径、调用回放与模拟。
• 应用：把原因和建议呈现给策略产品或运营。
• 组织流程：人工审批、配置灰度、复盘沉淀。

如果只有第一层语言回答，没有后四层，得到的只是一个会说话的界面，而不是能负责业务结果的产品。

今日练习

画一张两列图：

• 左边画AI产业五层。
• 右边分别写出每层在物流交易中的一个产品。

再回答：驻店调度Copilot最应该在哪一层建立壁垒？建议答案是行业应用与决策平台，而不是基础模型。

自测题

1. 为什么行业应用不应只拼模型能力？
2. AI价值的四种类型是什么？
3. 你当前经验最接近产业链哪两层？

完成标志

• 画完产业链图
• 为五层各写一个物流案例
• 写出自己准备进入的层级

今日目标

理解AI能力不等于商业价值，学会用单位经济判断一个AI产品是否值得持续投入。

核心正文

AI产品常见的商业模式有五类。

第一，订阅制。用户按席位或周期付费，适合价值持续、使用相对稳定的工具。风险是用户偶尔使用却长期付费，续费时容易流失。

第二，按量计费。按调用、Token、图片、分钟或任务收费，收入与成本更匹配，但客户预算不确定，可能抑制使用。

第三，分层套餐。用功能、额度、速度、安全和服务区分版本，是订阅与按量的组合。

第四，项目制或解决方案。按集成、部署和服务收费，适合强行业属性，但交付成本高，容易“每个客户重做一遍”。

第五，结果付费。按节省成本、增加收入或成功任务收费，客户容易理解，但归因、基线和风险分担复杂。

内部AI产品虽然不直接收费，也要算单位经济。它至少包含：

收益 = 节省的人工时间 + 减少的错误损失 + 新增业务结果 + 决策速度价值

成本 = 模型与计算 + 数据与工程 + 人工复核 + 错误成本 + 维护与治理

不要只计算模型调用费。企业AI常见的大头是数据接入、权限、评测、流程改造和长期维护。另一个误区是把“生成了多少报告”当收益；报告只有改变了决策或节省了真实工作，才产生价值。

对于策略Copilot，可以把价值拆成三个层级：

• 效率价值：一次诊断从半天缩短到半小时。
• 质量价值：减少口径错误、遗漏约束和不可执行建议。
• 业务价值：更快发现有效策略，提升净增完单或降低无效补贴。

单位经济应该逐层验证。第一阶段只证明效率和质量，不要在没有线上实验时声称提升完单。第二阶段通过影子运行证明建议有用。第三阶段才通过灰度实验验证业务增量。

AI产品还有一个特殊成本：错误不是平均发生的。一次普通回答错误可能只浪费几分钟；一次错误配置可能影响大量订单。因此应计算风险调整后的价值：

风险调整价值 = 预期收益 − 错误发生概率 × 错误损失 − 治理成本

这也是为什么高风险动作需要更强评测和人工确认。

业务映射

智能补贴项目提供了很好的反例：模型能预测价敏，不代表补贴产生增量。如果触发晚、覆盖低、实验污染或预算核销口径不对，模型收益会被吃掉。

同样，策略Copilot即使报告读起来很好，也必须检查：

• 建议是否引用了正确数据周期。
• 计算是否与业务口径一致。
• 是否考虑公共池和其他门店的外部影响。
• 人工是否真的采用。
• 采用后是否减少时间或改善结果。

今日练习

为驻店调度Copilot写一张单位经济表，至少包括：

1. 每周有多少次策略诊断。
2. 当前每次耗费多少人时。
3. Copilot可节省多少时间。
4. 需要多少开发、数据和维护成本。
5. 一次错误建议的最大潜在损失。
6. 首阶段只承诺验证什么，不承诺什么。

数字未知时写“待测”，不要编造。

自测题

1. 为什么模型调用成本通常不是企业AI的全部成本？
2. 内部AI产品的收益可以分哪三层？
3. 为什么结果付费很有吸引力但难落地？

完成标志

• 完成Copilot单位经济草表
• 明确第一阶段价值承诺
• 写出三个最重要的隐性成本

今日目标

建立“是否使用AI”的判断框架，避免为了转型而把所有问题包装成AI问题。

核心正文

判断一个问题是否值得用AI，可以连续问六个问题。

第一，任务是否存在足够价值？如果只是每月做一次、十分钟能完成的动作，即使AI能做，也未必值得产品化。

第二，输入是否复杂或存在大量非结构化信息？文本、图片、语音、模糊意图和跨文档知识通常更适合AI。固定字段和明确公式通常适合传统程序。

第三，规则能否穷举？如果规则少、稳定、容易审计，规则系统往往更便宜可靠。如果规则极多、例外频繁或需要从历史样本学习，可以考虑模型。

第四，错误是否可发现、可恢复？AI更适合“错误能被人及时发现并纠正”的任务。对资金、安全和大规模实时决策，应降低自主程度。

第五，是否有评测数据和反馈？没有代表性样本，就无法判断系统是否真的变好。

第六，AI是否嵌入了真实流程？如果用户还要复制粘贴、手工查证和重新录入，AI可能只是增加一步。

可以把常见技术分工记成一张表：

现实系统通常是组合，不是五选一。例如驻店调度：

• LLM理解“在承接率不下降的情况下提升人效”。
• SQL工具获取数据。
• 预测模型估计应答、耗时和未来订单。
• 优化器比较候选分配。
• 规则负责资格、安全和阈值。
• LLM把结果解释为可读建议。

优秀的AI产品经理有一个重要能力：知道AI不应该放在哪里。若让LLM直接算路线、金额或执行线上配置，短期Demo可能很惊艳，长期却难以审计。

业务映射

把你当前工作中的任务分类：

• 计算ROI：确定性程序。
• 预测应答：预测模型。
• 找全局最优OD组合：优化算法。
• 阅读会议纪要并形成问题假设：LLM。
• 根据问题自动取数、回放和写实验草案：Agent。
• 发布Apollo配置：确定性接口加人工审批，不让LLM自由执行。

今日练习

列出你每周最常做的10个任务，为每个任务标注：

• 任务价值与频率。
• 当前耗时。
• 适合规则、预测、优化、LLM还是Agent。
• 错误的影响。
• 是否需要人工确认。

最终只选一个价值高、数据可得、错误可控的任务作为30天项目。

自测题

1. 为什么“规则很多”不必然意味着应该用LLM？
2. 哪类任务更适合优化算法而不是LLM？
3. 驻店调度中LLM最适合承担什么？

完成标志

• 完成10项任务技术分类
• 明确一个实践任务
• 写出至少两个不应交给LLM的环节

今日目标

理解AI产品为什么不能只用传统功能验收，以及如何设计概率型体验。

核心正文

传统软件通常遵循明确逻辑：相同输入得到相同输出，功能是否正确可以用规则断言。AI系统更像一个概率分布：同类输入不一定得到完全相同答案，平均表现不错也可能在少数关键场景严重失败。

概率型产品有五个重要特征。

第一，正确不是二元的。一个回答可能事实正确但没有引用，也可能建议方向对但数值错误。因此要把质量拆成事实、完整、相关、格式、安全和可执行等维度。

第二，平均值会隐藏长尾。90%的普通案例做对，不代表能处理高峰、极端长距离、最后一名驻店骑手或异常日志。

第三，系统表现依赖上下文。提示、工具说明、知识版本、检索结果、模型版本甚至对话历史都会改变答案。

第四，用户会改变使用方式。系统表现好后，用户可能把更难的任务交给它；表现差时，用户会绕过或反复确认。产品指标必须包含信任和行为变化。

第五，错误成本不对称。漏报一个普通异常与错误建议大规模发补贴，损失完全不同。

因此，概率型产品需要四层设计：

1. 输出契约：系统必须输出什么字段、证据和不确定性。
2. 评测：使用代表性案例检查各维度表现。
3. 兜底：低置信、数据缺失或高风险时转人工或停止。
4. 监控：上线后持续看分布漂移、新Bad case和版本回归。

对用户界面而言，不应简单展示一个“AI答案”。更好的结构是：

• 结论：发生了什么。
• 证据：使用了哪些指标和时间范围。
• 假设：哪些解释仍未被证明。
• 建议：下一步动作。
• 风险：可能伤害哪些指标。
• 操作：回放、修改条件、提交实验或转人工。

这与个人认知库中区分事实、综合和假设的做法高度一致。你已经有概率型思维的基础，下一步是把它变成产品界面与评测规则。

业务映射

如果Copilot说“门店人效低是因为长距离订单过多”，至少需要检查：

• 长距离定义是否正确。
• 对照的是同门店历史还是相似门店。
• 骑手人数、订单到达和备货是否同时变化。
• 结论是相关性还是经过实验验证的因果关系。
• 建议缩短半径会不会减少承接和总完单。

系统若不能展示这些边界，就可能把一个漂亮叙述误当成可靠决策。

今日练习

选一个历史分析结论，改写为概率型输出：

1. 结论。
2. 支撑证据。
3. 置信度或样本限制。
4. 其他可能解释。
5. 可验证的下一步。
6. 高风险动作的人工审批点。

自测题

1. 为什么准确率90%仍可能不适合上线？
2. 概率型产品的四层设计是什么？
3. 为什么要区分相关性结论和因果结论？

完成标志

• 把一个历史结论改写成概率型输出
• 明确一个低置信兜底
• 写出最需要关注的三个长尾场景

今日目标

不推导模型数学，但建立足以支持产品决策的LLM工作原理和边界认知。

核心正文

大语言模型可以粗略理解为：根据当前上下文，连续预测下一个最可能的Token。Token不是严格的字或词，而是模型处理文本的基本片段。模型把输入转成向量，通过多层Transformer计算不同位置之间的关系，再生成后续内容。

Transformer的关键机制是注意力。它让模型在处理当前内容时，动态参考上下文中更相关的部分。它擅长从大量文本中学习模式，也能在给定示例和要求后完成新的语言任务。但它不是数据库，也不是严格意义上的事实查找器。

模型形成能力通常经历几个阶段：

1. 预训练：从大规模数据中学习语言、知识和模式。
2. 后训练：通过示例、反馈和规则提高指令遵循、安全与任务表现。
3. 推理：在用户输入和当前上下文上生成结果。
4. 工具增强：通过搜索、文件、数据库或业务接口获得外部信息和执行能力。

产品经理至少要理解六个边界。

第一，知识有截止与误差。参数中“记住”的内容不是可实时更新、可逐条审计的知识库。

第二，语言流畅不等于事实正确。模型的目标首先是生成符合上下文的内容，因此可能产生看似合理但无证据的陈述。

第三，上下文有限且存在注意力竞争。输入越长并不一定越好，重复和不相关信息可能降低表现、增加成本。

第四，输出存在波动。相同问题可能得到不同表达或不同方案，生产系统需要结构化约束和评测。

第五，模型能力与任务难度相关。复杂计算、精确检索、实时状态和高风险动作需要工具或确定性系统。

第六，模型本身不知道企业真正的业务口径。必须通过工具、知识、示例、输出契约和评测把业务要求接进去。

从产品视角，模型能力可以分为四类：

• 转换：摘要、分类、改写、抽取和格式化。
• 生成：文案、方案、代码和解释。
• 推理：比较选项、拆解问题、提出假设。
• 编排：选择工具、执行步骤、根据结果继续行动。

模型越从转换走向编排，产品收益可能越高，但错误链路、成本和权限风险也越大。

业务映射

在策略Copilot中，LLM可以把“为什么这个门店人效下降”转成结构化分析计划，但不应凭语言直接回答。可靠流程是：

1. 确认门店、时间和指标口径。
2. 调用确定性工具获取数据。
3. 对比供给、订单结构、路线和履约。
4. 引用结果形成解释。
5. 把未经验证的原因明确标成假设。

模型负责理解和组织，数据工具负责事实。

今日练习

向AI提出同一个业务问题三次，比较：

• 结论是否一致。
• 是否出现没有数据支撑的数字。
• 哪些部分是语言推断，哪些必须查数据。
• 加入清晰输出结构后是否更稳定。

然后写出一句产品原则：“凡是涉及内部实时指标和精确金额，必须……”。

自测题

1. 为什么LLM不是数据库？
2. Transformer的注意力机制对产品意味着什么？
3. 工具增强主要解决什么问题？

延伸阅读

• Transformer原始论文入口

完成标志

• 能用三分钟解释LLM如何工作
• 找到三个必须使用工具的业务问题
• 写出一条事实获取原则

今日目标

把Prompt从“提问技巧”升级为产品契约，理解上下文、工具说明和输出结构共同决定系统行为。

核心正文

Prompt不是一句神奇咒语，而是模型运行时收到的产品要求。一个生产级Prompt至少包含：

1. 角色与任务：系统要帮助谁完成什么。
2. 可用证据：哪些数据、文档或工具可以使用。
3. 约束：哪些事情不能做，什么情况下必须停止。
4. 决策标准：什么叫做好结果。
5. 输出结构：必须返回哪些字段。
6. 不确定性处理：缺数据、冲突或低置信时怎么做。

上下文不仅包括用户当前输入，还包括系统指令、历史对话、检索内容、工具结果和示例。产品设计的关键不是“塞得越多越好”，而是让每一段上下文都服务于任务。

好的上下文管理有四条原则：

• 稳定要求与动态数据分开。稳定的业务规则放固定层，门店和日期等动态信息每次传入。
• 删除重复和无关内容。重复指令会增加成本，也可能相互冲突。
• 为证据加来源和时间。否则模型无法区分当前数据与历史材料。
• 长任务保存结构化状态。记录已经完成什么、还缺什么、下一步是什么，避免反复执行。

结构化输出的价值不是让答案看起来整齐，而是使系统能够验证和继续处理。例如一次策略诊断可以固定输出：

如果字段缺失，程序可以阻止提交；如果风险等级高，可以要求人工审批。这样Prompt就从文案变成产品接口。

提示迭代也不能靠主观感觉。正确方法是固定一组代表性案例，先跑基线，只改一类要求，再比较质量、成本和延迟。OpenAI官方模型指南同样强调使用代表性评测验证提示或模型调整，而不是把更长的提示默认当成更好。

业务映射

一个不合格Prompt：

“分析一下昨天驻店人效为什么下降。”

一个更接近产品契约的Prompt应明确：

• 门店、城市、日期和对照周期。
• 人效、承接率的正式口径。
• 只使用工具返回的数据。
• 区分事实、推断和待验证假设。
• 不提出会破坏SLA或骑手收入护栏的建议。
• 输出结论、证据、备选解释、动作和风险。

今日练习

为“驻店经营诊断”写一版Prompt契约。至少包含：

1. 任务目标。
2. 三条禁止事项。
3. 可调用的五个工具。
4. 七个输出字段。
5. 三种需要停止并请求人工确认的情况。

用三个不同门店场景测试，记录输出是否稳定。

自测题

1. 为什么Prompt应被视作产品契约？
2. 上下文越长为什么不一定越好？
3. 结构化输出带来哪三类价值？

延伸阅读

• OpenAI官方模型使用指南

完成标志

• 写出Prompt契约V0
• 完成三例测试
• 记录最常见的不稳定点

今日目标

理解RAG的完整链路，能够区分检索失败、知识缺失和生成失败。

核心正文

RAG是Retrieval-Augmented Generation，即检索增强生成。它的核心思想是：回答问题前，先从外部知识库检索相关内容，再让模型基于这些证据生成答案。

一个典型RAG系统包含六步：

1. 采集：获取文档、表格、页面或结构化记录。
2. 处理：清洗格式、去重、识别标题和权限。
3. 切分：把长内容切成可检索片段，并保留上下文关系。
4. 索引：生成关键词索引、向量表示或混合索引。
5. 检索与重排：找到候选片段，再按相关性筛选。
6. 生成与引用：模型依据片段回答并标记来源。

RAG不等于“上传文件后聊天”。它至少有四类失败。

• 知识缺失：知识库中根本没有正确内容。
• 索引失败：有内容，但切分或元数据让它难以被找到。
• 检索失败：查询表达与知识表达不一致，召回了错误片段。
• 生成失败：证据正确，模型却忽略、误读或过度推断。

因此评测要分两层：

检索层回答“正确证据有没有进入上下文”。常见指标包括召回率、Top-K命中率、相关性和权限正确率。

生成层回答“有证据后答案是否正确”。常见维度包括事实一致、引用支持、完整性、拒答、表达和可执行性。

企业知识产品还必须处理时效和权限。同一份策略可能有草稿、已发布、已过期版本；同一个用户可能只能查看某个城市或业务。系统必须把来源、版本、生效时间、拥有者和权限写进元数据。

什么时候不需要RAG？

• 问题只依赖当前结构化数据，应直接查库。
• 规则很少且稳定，可以写成程序。
• 用户需要逐字精确查找，全文搜索可能更简单。
• 知识更新和权限无法维护时，RAG只会把混乱包装得更像答案。

业务映射

策略Copilot可以使用两类知识：

• 结构化事实：订单、骑手、路线、指标，由SQL或指标工具获取。
• 非结构化知识：指标定义、策略说明、历史复盘、实验结论，由RAG获取。

例如用户问“为什么9折在高应答区间ROI更高”，系统需要先查实际数据，再检索ROI口径和历史实验边界。文档不能代替当前数据，当前相关性也不能冒充历史因果结论。

今日练习

选择10份本地材料，设计知识元数据：

• 标题
• 业务域
• 文档类型
• 城市/渠道
• 数据周期
• 生效状态
• 负责人
• 保密等级
• 可引用范围

再准备5个问题，为每题写出“理想证据片段”。这就是最小检索评测集。

自测题

1. RAG为什么不能保证答案一定正确？
2. 检索层和生成层分别评什么？
3. 企业RAG为什么必须有版本与权限？

延伸阅读

• RAG经典论文

完成标志

• 完成10份材料的元数据设计
• 准备5题检索评测
• 能区分四类RAG失败

今日目标

理解自动化、Workflow与Agent的差异，为策略Copilot选择合适自主程度。

核心正文

三个概念经常被混用。

自动化是预先写好的固定步骤。例如每天八点运行SQL并发送日报。输入和路径基本确定。

Workflow是由多个步骤组成的业务流程，可以包含条件分支。例如先检查数据是否齐全；齐全则计算指标，不齐全则通知负责人；若指标异常，再进入原因诊断。

Agent是在目标、工具和约束下，由模型根据中间结果动态决定下一步。例如它先查询供给，发现供给正常后不再查招募，而转去检查路线和等待。

判断是否需要Agent，可以看四点：

• 任务路径是否会随中间结果变化。
• 输入是否开放且难以枚举。
• 是否需要在多个工具之间规划。
• 错误是否可被限制和恢复。

如果流程非常稳定，Workflow通常比Agent更可靠、更便宜、更容易审计。很多优秀AI产品是“确定性Workflow包住少量Agent决策”，而不是让模型自由行动。

一个Agent系统至少包含：

1. 目标：最终要完成什么。
2. 状态：已知信息、已完成步骤和剩余任务。
3. 工具：查数、检索、模拟、写入或通知。
4. 策略：什么情况下调用哪个工具。
5. 观察：读取工具结果并更新判断。
6. 停止条件：达到什么标准结束或转人工。
7. 追踪：记录每次输入、调用、结果和版本。

工具描述是产品设计的一部分。一个工具要写清用途、输入、输出、错误、时效、权限和副作用。如果“查询完单率”工具没有明确分子分母，模型再聪明也可能给出错误解释。

自主程度可以分四级：

• L0：只回答，不调用工具。
• L1：读取数据并给建议。
• L2：生成操作草案，人工确认后执行。
• L3：在明确额度和范围内自动执行，可撤销。

驻店策略首版应停在L1或L2。因为错误策略会影响真实订单、骑手和成本，直接进入L3没有必要。

业务映射

策略Copilot的推荐Workflow：

1. 解析门店、时间、指标和目标。
2. 检查口径和数据完整性。
3. 查询经营指标。
4. 根据异常类型选择诊断工具。
5. 必要时运行历史回放。
6. 汇总结论、证据和风险。
7. 生成人工可编辑的实验草案。
8. 人工批准后，交给确定性发布系统。

这里第4步适合Agent动态选择，第1、2、7、8步应有固定流程和校验。

今日练习

画一张策略Copilot工作流，并为五个工具写工具卡：

• 工具名称
• 用途
• 必填输入
• 返回字段
• 可能错误
• 是否有副作用
• 是否可重试
• 所需权限

自测题

1. 什么情况下Workflow优于Agent？
2. 工具描述为什么属于产品设计？
3. 驻店策略Copilot首版为什么不应完全自动执行？

延伸阅读

• OpenAI Responses API工具能力

完成标志

• 画出完整工作流
• 完成五张工具卡
• 标出所有人工确认点

今日目标

学会给Agent设定权限边界，让系统在出错、超时或数据冲突时能够安全停止和恢复。

核心正文

Agent产品的风险不只来自回答错误，还来自“错误答案触发了真实动作”。因此，设计工具时必须把读取和写入分开，把建议和执行分开。

最基本的权限原则是最小权限：系统只拥有完成当前任务所需的最小数据范围、工具集合和时间窗口。分析北京某门店，不应默认获得全国配置发布权。

可以用三类动作分级：

• 只读动作：查数、检索文档、查看配置和运行离线回放。
• 可逆写入：保存草稿、创建待审批实验、写备注。
• 高风险写入：发布配置、修改价格、改变派单、批量通知。

三类动作需要不同控制。只读动作可在权限内自动运行；可逆写入应显示修改内容并允许撤销；高风险写入必须进行明确人工确认，还应限制对象、额度、有效期和回滚方式。

人工确认不能只是一个“确认”按钮。合格的确认页面要让审批者知道：

• 将修改什么。
• 影响哪些城市、门店、人群和时间。
• 为什么建议修改。
• 预计收益和不确定性。
• 可能伤害哪些护栏。
• 如何停止与回滚。

可恢复执行包含四种机制：

1. 幂等：重复提交同一操作不会重复生效。
2. 检查点：长任务完成一部分后记录状态，失败不必从头开始。
3. 重试边界：只重试暂时性错误，限制次数，避免无限循环。
4. 补偿或回滚：写入失败或效果异常时恢复原状态。

系统还需要明确停止条件，例如：

• 必填数据缺失。
• 指标口径冲突。
• 建议超过预算或影响范围。
• 回放显示关键护栏恶化。
• 工具连续失败。
• 用户要求与公司规则冲突。

真正可靠的Agent不是“什么都能自己做”，而是知道什么时候不该继续。

业务映射

策略Copilot可以自动完成：

• 查询历史数据。
• 运行已经批准的回放模板。
• 生成原因分析和实验草案。

它不能未经确认完成：

• 修改Apollo配置。
• 调整补贴折扣。
• 扩大实验城市或门店。
• 改变安全、资质和SLA过滤。

即使用户说“直接上线”，系统也应展示差异、影响、护栏、有效期与回滚方案，再由有权限的人确认。

今日练习

制作一张权限矩阵，横轴是角色：策略产品、运营、数据、算法、研发、审批人；纵轴是工具：查数、回放、保存草案、创建实验、发布配置、回滚。

为“提高某门店时间机会成本参数”设计一个审批卡片。

自测题

1. 最小权限原则解决什么问题？
2. 为什么人工确认不能只是确认按钮？
3. 幂等和回滚分别解决什么问题？

完成标志

• 完成角色权限矩阵
• 完成一张审批卡片
• 写出六条停止条件

今日目标

学会把“看起来好用”转成可重复测量的产品质量，并建立从错误到迭代的闭环。

核心正文

AI评测的起点不是模型，而是产品承诺。先写出系统必须在什么场景、为谁、完成什么任务，再决定如何评分。

一套最小评测包含五个部分：

1. 样本：有代表性的真实输入。
2. 期望：正确答案、关键要点或可接受范围。
3. 评分规则：怎样判断通过。
4. 运行配置：模型、Prompt、知识和工具版本。
5. 结果：分数、错误分类、成本、延迟和回归。

评测样本不能只选“常见且容易”的情况。推荐按四个桶构建：

• 高频正常场景：覆盖日常主要流量。
• 业务长尾场景：低峰、高峰、长距离、供给极少、异常门店。
• 高风险场景：预算、权限、敏感信息、可能影响线上决策。
• 历史Bad Case：系统曾经真实犯过的错误。

评分也不应只有一个总分。对策略诊断，可以拆为：

• 意图理解：门店、时间、指标和目标是否识别正确。
• 数据正确：是否调用正确工具和口径。
• 证据充分：结论是否被数据支持。
• 因果克制：是否把相关性误写成因果。
• 建议可行：是否符合当前能力与权限。
• 风险完整：是否识别承接、时效、成本和骑手体验。
• 格式合规：能否进入后续审批或实验系统。

评分方法通常组合使用：

• 确定性检查：字段、数值、引用、SQL结果、权限。
• 规则评分：是否包含必需要点或禁止项。
• 人工专家评分：业务判断、可执行性和表达。
• 模型评分：用于规模化辅助，但需要先与人工对齐。
• 线上行为：用户是否采用、修订、撤回或获得结果。

Bad Case管理不能只保存错误答案。每条错误至少记录：

• 输入和业务场景。
• 当时使用的模型、Prompt、知识和工具版本。
• 期望结果与实际结果。
• 错误发生在哪一层。
• 造成或可能造成的影响。
• 修复方式。
• 是否加入回归测试。

常见错误层级包括意图、知识、检索、工具选择、工具数据、推理、格式、权限和执行。只有找到层级，才能避免靠增加一段提示词掩盖真正问题。

业务映射

为驻店Copilot建立100例评测集，可初步分配：

• 30例正常经营诊断。
• 20例人效与承接率冲突。
• 15例数据缺失或口径冲突。
• 15例异常路线、超时与回店。
• 10例补贴或成本问题。
• 10例权限与高风险动作。

不要要求所有样本都有唯一建议，但应要求证据、约束和停止条件正确。

今日练习

先建立20例评测集，每例填写：

问题、场景标签、所需工具、必需证据、可接受结论、禁止错误、风险等级、评分方式。

从历史对话或复盘中至少加入5个真实Bad Case。

自测题

1. 为什么评测要从产品承诺开始？
2. 为什么不能只测高频正常场景？
3. Bad Case为什么必须记录版本？

延伸阅读

• OpenAI Evals API

完成标志

• 建立20例初始评测
• 加入5个真实Bad Case
• 定义至少七个评分维度

今日目标

学会在不同任务中选择合适模型和系统路径，而不是一味追求最高能力。

核心正文

生产AI产品几乎总要在质量、延迟和成本之间取舍。更强模型、更长上下文、更多工具调用和更多重试通常能提高部分质量，但也会增加响应时间与费用。

产品经理首先应按任务价值分级，而不是为整个产品选一个统一配置。

延迟可以拆成：

总延迟 = 模型推理 + 检索 + 数据查询 + 工具排队 + 重试 + 输出传输

只优化模型速度，未必解决工具慢或SQL慢。应记录每个阶段耗时，找到真正瓶颈。

成本也要拆开：

• 输入成本：固定Prompt、历史对话、检索片段和工具结果。
• 输出成本：生成长度和推理强度。
• 工具成本：搜索、数据库、计算或第三方服务。
• 人工成本：复核、纠错和维护。
• 错误成本：错误决策、返工和信任损失。

常见优化方法包括：

• 缩短重复上下文，稳定内容使用缓存。
• 先用规则或小模型做分类，再把少量复杂任务交给强模型。
• 限制工具范围、调用次数和无效重试。
• 对重复查询缓存数据与中间结果。
• 使用结构化输出减少二次修复。
• 只在评测证明有效时增加推理或更强模型。

不要用“单次调用便宜”证明产品经济性。如果用户为了验证答案还要花20分钟，那么人工复核成本可能远高于模型成本。

业务映射

策略Copilot可以设计两条路径：

• 快速诊断：查询预计算指标，10—20秒内给出异常概览。
• 深度回放：按需查询明细、运行策略模拟，几分钟后给出完整证据。

用户先看到系统正在查什么和已有结果，可以降低等待焦虑；高成本回放只对值得深入的场景运行。

今日练习

为Copilot的五种任务填写：

• 业务价值
• 期望质量
• 可接受延迟
• 允许成本
• 模型或规则路径
• 是否需要人工复核

再画出一次深度诊断的延迟瀑布图，数字未知可以先写待测。

自测题

1. 为什么不应给所有任务使用同一个最强模型？
2. AI产品的成本除了模型费还有什么？
3. 怎样判断增加推理是否值得？

完成标志

• 完成五类任务分级
• 画出延迟瀑布
• 写出三项成本优化措施

今日目标

建立从业务风险出发的AI治理框架，让安全成为产品流程而不是上线前检查项。

核心正文

AI风险管理可以用四个动作理解：治理、映射、测量、管理。

治理是明确责任、规则和决策流程。谁定义用途，谁拥有数据，谁审批上线，谁处理事故。

映射是理解使用环境。用户是谁，数据是什么，系统会影响谁，错误会造成什么后果，是否存在不可接受用途。

测量是建立测试与监控。系统在不同人群、长尾和攻击输入上的表现如何，置信度和风险是否可量化。

管理是根据风险采取动作。限制权限、增加人工复核、降低自主程度、建立回滚、暂停高风险场景。

生成式AI常见风险包括：

• 虚构与事实错误。
• 隐私和敏感信息泄漏。
• 偏见和不公平影响。
• 提示注入或恶意内容诱导。
• 知识产权和内容来源问题。
• 过度依赖与自动化偏见。
• 越权调用工具或执行错误动作。
• 系统供应链和第三方依赖。

风险分级应同时看发生概率和损失严重度。低概率、高损失事件不能因为平均准确率高而忽略。

对数据产品而言，还要警惕“指标泄密”。即使不展示单个司机身份，小样本切片也可能间接暴露个人行为；对外作品集必须脱敏并聚合。

治理应嵌入产品生命周期：

• 立项：定义允许和禁止用途。
• 设计：最小权限、数据边界和人工节点。
• 开发：安全测试、注入测试和依赖检查。
• 上线：灰度、审计、监控和回滚。
• 运营：事故复盘、评测更新和权限复查。

NIST的AI风险管理框架强调可信AI不仅是“准确”，还包括安全、韧性、透明、可解释、隐私和公平。对策略产品，这意味着不能只看完单或成本。

业务映射

驻店Copilot的高风险点：

• 错用过期指标口径。
• 查询超出权限的司机明细。
• 把相关性当成因果后建议加补贴。
• 忽略公共池外部影响。
• 自动发布大范围配置。
• 把历史材料中的内部数字写入对外作品集。

对应控制：

• 显示数据时间和口径版本。
• 小样本脱敏与最小权限。
• 输出区分事实、推断和实验假设。
• 强制展示护栏。
• 只生成草案，人工发布。
• 提供对外脱敏模式。

今日练习

建立风险登记表，至少写10项：

风险、触发条件、受影响对象、概率、损失、检测方式、预防措施、应急动作、负责人。

从中选出三个“首版即阻断”的风险。

自测题

1. AI风险管理的四个动作是什么？
2. 为什么小样本切片也可能造成隐私风险？
3. 安全为什么不能只在上线前检查？

延伸阅读

• NIST AI风险管理框架
• NIST生成式AI风险画像

完成标志

• 完成10项风险登记
• 确定三个阻断风险
• 定义对外脱敏原则

今日目标

掌握从需求验证、原型、影子运行到灰度上线的完整路径，完成第二周验收。

核心正文

AI原型容易做，稳定产品难做。正确的上线顺序不是“Demo效果不错就接线上”，而是逐步增加真实数据、用户、权限和影响范围。

推荐六个阶段。

第一，问题验证。通过访谈、工作记录和耗时确认问题真实、高频且值得解决。没有问题价值，后续模型优化都没有意义。

第二，手工样板。产品团队先人工完成10—20个任务，理解输入、判断过程、输出和例外。不要过早自动化自己还不理解的流程。

第三，原型验证。用少量真实材料和有限工具验证用户是否理解、是否信任、是否愿意使用。

第四，离线评测。固定代表性样本，比较不同Prompt、模型、知识和工具版本，明确最低上线标准。

第五，影子运行。系统读取真实数据并给出建议，但不影响线上；将建议与专家和真实结果比较。

第六，灰度执行。只在低风险范围、有限用户和明确额度内执行，持续监控并保留回滚。

每个阶段都应有退出条件。

上线清单至少包括：

• 产品承诺与禁止用途。
• 数据来源、权限和时效。
• Prompt、知识、模型和工具版本。
• 离线评测与风险样本。
• 日志、追踪和成本监控。
• 降级、停止和回滚。
• 用户反馈与Bad Case入口。
• 责任人和事故响应。

AI系统上线后，用户问题会变难，数据会漂移，模型与知识会更新。因此“上线完成”只是持续评测的开始。

业务映射

驻店Copilot的上线顺序：

1. 访谈三类用户，确认诊断与回放耗时。
2. 人工完成20份标准诊断，提炼流程。
3. 做只读原型，用户选择门店和问题。
4. 用100例评测集验收。
5. 对真实经营日影子输出建议。
6. 只允许生成实验草案。
7. 经过审批再考虑小范围配置联动。

今日练习

完成AI产品上线清单，并为六阶段各写一个通过条件和一个停止条件。

第二周验收需要提交：

1. 规则、预测、优化、LLM和Agent技术选型树。
2. 20例以上评测集。
3. 权限矩阵。
4. 风险登记表。
5. 六阶段上线计划。

自测题

1. 影子运行和灰度执行有什么区别？
2. 为什么先做手工样板？
3. AI产品上线后为什么还要持续评测？

完成标志

• 完成六阶段计划
• 完成上线检查清单
• 汇总第二周五项交付

今日目标

建立机器人行业地图，理解机器人不是一种产品，而是多个行业、形态和商业模式的集合。

核心正文

机器人可以从使用场景分为三大类。

工业机器人服务于生产制造，例如机械臂焊接、搬运和装配。环境通常高度结构化，任务重复，对精度、节拍、可靠性和集成要求高。

专业服务机器人服务于商业或公共任务，例如仓储搬运、配送、清洁、巡检、医疗和农业。环境更开放，通常需要导航、感知和现场运维。

消费服务机器人面向个人或家庭，例如扫地、割草和陪伴产品。它们更重视价格、易用性、外观、渠道和售后规模。

IFR把服务机器人定义为能够在环境中运动、为人或设备执行有用任务、且不属于工业自动化的可编程机构。其2025年报告记录，2024年专业服务机器人销量接近20万台，货物运输类占据非常重要的位置；机器人即服务RaaS机队增长也体现了客户更愿意按使用而非一次性重资产采购。

从产品形态看，还可以分为：

• 固定式操作：机械臂、协作机器人。
• 移动式运输：AGV、AMR、配送机器人。
• 移动与操作结合：移动操作机器人、人形机器人。
• 辅助与遥操作：手术、救援、远程巡检。

机器人产品的商业价值通常来自：

1. 替代危险、重复、枯燥或难招人的任务。
2. 提高节拍、稳定性和全天候能力。
3. 获取以前难以采集的现场数据。
4. 通过标准化流程提高服务一致性。

常见商业模式包括整机销售、租赁、RaaS、按任务付费、系统集成和运维服务。判断模式时要看客户的投资偏好、任务波动、部署周期、维护能力和效果归因。

机器人产品经理不能只问“机器人会什么”，还要问：

• 谁为它付费，预算来自人工、设备还是数字化改造？
• 它替代的是整份工作，还是其中几个任务？
• 环境需要改造多少？
• 一台设备每天有效工作多久？
• 故障时有没有人工接管？
• 多久回本，能否在第二个现场复制？

业务映射

你的驻店业务与专业服务机器人最接近，因为两者都在有限时空内执行物流任务。骑手成本、人效和承接率，对应机器人领域的设备利用率、任务完成率和车队容量。

但人和机器人也有差异：骑手有自主选择、收入和公平感；机器人受电量、传感器、机械能力和安全规范约束。不能简单把人当机器，也不能把机器人调度只看成数学分配。

今日练习

选择三个机器人场景：仓储AMR、末端配送、商用清洁。分别填写：

• 购买者与使用者。
• 被替代或增强的任务。
• 核心价值。
• 主要成本。
• 部署依赖。
• 失败后的兜底。
• 可能商业模式。

自测题

1. 工业机器人和专业服务机器人最大的场景差异是什么？
2. RaaS为什么对客户有吸引力？
3. 为什么不能用“机器人功能数量”衡量商业价值？

延伸阅读

• IFR服务机器人报告入口

完成标志

• 完成三个场景商业画布
• 能区分三大机器人类型
• 写出自己最适合进入的机器人产品环节

今日目标

理解机器人从本体到云平台的完整系统栈，学会识别一个产品需求会影响哪些技术和成本。

核心正文

一个机器人产品可以拆成七层。

第一，本体与执行器。包括结构、轮式或足式底盘、机械臂、夹爪、电机和传动。它决定机器人能去哪里、拿多重、动作多快。

第二，能源与计算。包括电池、电源管理、边缘计算、控制器和通信。性能越强通常能耗和散热越高。

第三，传感器。相机、激光雷达、深度、IMU、编码器、力矩、触觉和环境传感器让机器人获得外界状态。

第四，基础软件。驱动、操作系统、中间件、时间同步、日志和设备管理连接硬件与上层能力。

第五，智能能力。感知、定位、建图、路径规划、运动控制、抓取和任务策略。

第六，业务应用。任务编排、站点配置、地图管理、告警、远程接管、运营后台和用户交互。

第七，云端与车队。设备注册、任务分配、版本升级、数据回传、仿真、监控和多机协同。

产品需求往往跨层联动。例如“机器人可以在更窄通道会车”可能影响：

• 本体尺寸和转向结构。
• 传感器视场和盲区。
• 定位精度。
• 局部规划算法。
• 交通规则和车队调度。
• 安全距离和速度。
• 现场通道标识。

机器人产品的难点不是把每一层做到最强，而是在任务、性能、成本和可靠性之间形成闭环。

常见权衡：

• 更高精度传感器提高能力，也增加成本、能耗和维护。
• 更大电池增加续航，也增加重量和充电时间。
• 更快速度提高吞吐，也增加制动距离与安全风险。
• 更开放环境扩大市场，也增加长尾和交付成本。
• 更多本体能力减少环境改造，却可能让整机价格失去竞争力。

产品经理不必设计电机或算法，但要会把用户语言转成可验证的系统指标。例如“跑得稳”要拆成任务成功率、定位丢失率、故障恢复时间、连续运行时长和不同地面条件。

业务映射

驻店配送中的“骑手一次多带几单”，迁移到机器人不能只改任务上限。还要检查载荷、货舱体积、重心、取放流程、电量、路线、时效和故障兜底。

这与拼送项目“先能拼，再拼得好”的经验一致：先验证完整任务链路，再逐步提高并发和效率。

今日练习

选择一个药房到周边社区的配送机器人场景，画七层系统图。对“单次携带量从2单提高到4单”做影响分析，至少列出10项。

自测题

1. 为什么机器人需求经常跨多个系统层？
2. “跑得稳”应该如何产品化？
3. 提高速度为什么不能只修改一个参数？

完成标志

• 画出七层系统图
• 完成4单容量影响分析
• 把三个模糊需求转成指标

今日目标

理解ROS 2在机器人系统中的角色，以及节点、Topic、Service、Action对产品设计意味着什么。

核心正文

ROS 2不是机器人“大脑模型”，更接近连接机器人软件模块的中间件和开发生态。它让感知、定位、规划、控制和业务模块能够以标准方式交换信息。

节点Node是一个相对独立的计算单元。理想情况下每个节点做一类明确事情，例如相机驱动、障碍物检测、定位或导航。

ROS 2常见三类接口：

Topic适合连续数据流，采用发布订阅模式。例如传感器持续发布图像、激光点云、电量和机器人状态。发布者不必等待所有订阅者回复。

Service适合短时间的请求与响应。例如查询当前地图、读取配置或触发一个快速计算。调用者通常等待结果。

Action适合需要较长时间、持续反馈、可取消的任务。例如“移动到A点”。执行过程中可以返回进度，也可以被取消或抢占。

从产品视角理解：

• Topic回答“系统持续感知什么”。
• Service回答“系统现在查询或计算什么”。
• Action回答“系统要执行一个什么目标，进度如何，能否中止”。

一个移动机器人接到配送任务后可能经历：

1. 车队系统发出前往取货点的Action。
2. 定位节点持续通过Topic发布位姿。
3. 导航持续反馈任务进度。
4. 遇到阻塞时请求新的路径或上报告警。
5. 运营人员取消任务，机器人安全停止。

产品经理理解这些概念的价值，不是为了写代码，而是定义状态机、反馈、异常和接口。例如一个“任务中”状态过于粗糙，至少要区分已接受、规划中、行驶中、等待、受阻、暂停、取消中、已完成和失败。

还要关注通信质量。消息延迟、丢失、时间戳不一致和模块重启都可能导致“算法看起来正确，整机表现却异常”。因此产品指标要包含消息年龄、反馈超时、状态不同步和恢复时间。

业务映射

把现有派单系统类比为ROS接口：

• 司机位置与在线状态类似连续Topic。
• 查询资格和路线耗时类似Service。
• 完成一条配送路线类似Action，有进度、取消与结果。
• 订单分配平台类似上层任务编排器。

这个类比能帮助你从“订单是否派出”进一步思考任务生命周期和可恢复性。

今日练习

设计一个“机器人完成药房配送”的状态机，并标注：

• 哪些状态通过Topic持续更新。
• 哪些信息通过Service查询。
• 哪些任务使用Action。
• 每个状态的超时、取消和恢复方式。

自测题

1. Topic、Service、Action分别适合什么？
2. 为什么机器人任务必须支持反馈和取消？
3. 产品经理理解ROS 2的主要价值是什么？

延伸阅读

• ROS 2接口官方说明

完成标志

• 完成配送状态机
• 标注三类接口
• 列出五个异常与恢复路径

今日目标

建立移动机器人自主导航的产品级认知，能够把失败定位到正确模块。

核心正文

移动机器人完成任务，通常经历感知、定位、规划和控制四个核心环节。

感知回答“周围有什么”。机器人利用相机、激光雷达等识别人、障碍物、道路、货架和可通行区域。产品关注的不只是平均识别率，还包括光照、反光、玻璃、遮挡、雨雾和动态人群。

定位回答“我在哪里”。机器人结合地图、传感器、里程计和惯性信息估计自身位置。定位漂移会让规划和控制建立在错误坐标上。

规划回答“应该怎么走”。全局规划选择从起点到终点的大致路径；局部规划根据实时障碍物调整短期动作。规划要在距离、时间、安全、拥堵和规则之间权衡。

控制回答“如何让本体按路径运动”。控制器把期望轨迹变成速度、转向或关节命令，并持续纠正偏差。

上层还有任务规划：决定先做哪个任务、去哪个站点、何时充电、失败后改派给谁。它最接近你熟悉的派单。

一个任务失败时，不应简单归因为“机器人不智能”。例如：

• 没看到玻璃门：感知问题。
• 位置跳动：定位问题。
• 一直选择拥堵走廊：全局规划或交通策略问题。
• 在障碍物前来回摆动：局部规划或控制问题。
• 明明有空闲机器人却未分配：车队任务调度问题。
• 到站后不知道交接：业务流程问题。

产品指标也应按链路分层：

• 感知：漏检、误检、检测距离和延迟。
• 定位：位置误差、重定位成功率和丢失频次。
• 规划：可行路径率、规划时间、绕行和死锁。
• 控制：轨迹误差、急停、抖动和舒适性。
• 任务：成功率、耗时、人工接管和吞吐。

业务映射

配送中的“订单没有完成”同样不能只看最后结果。你过去把成交拆成圈选、过滤、推送、曝光、应答和履约；机器人产品也需要按感知、定位、规划、控制、交互和任务编排拆损失。

这正是你已有方法最容易迁移的地方：先定位失败层，再决定改数据、算法、硬件还是流程。

今日练习

分析三个失败场景：

1. 机器人在商场玻璃门前停住。
2. 两台机器人在窄通道相互等待。
3. 机器人完成远端任务后电量不足，无法承接下一单。

分别写：可能层级、需要证据、临时兜底、长期方案和验证指标。

自测题

1. 全局规划和局部规划有什么区别？
2. 为什么最终任务失败率不能直接归因于感知？
3. 车队任务规划与路径规划的区别是什么？

完成标志

• 完成三个失败案例分析
• 画出自主导航链路
• 为五层各定义两个指标

今日目标

理解车队调度的目标、约束和分层架构，并与订单—骑手匹配建立对应关系。

核心正文

单台机器人完成一条路线，主要是导航问题；多台机器人在共享环境中完成一组任务，则是车队调度问题。

车队调度通常需要回答：

1. 哪台机器人承担哪个任务。
2. 任务按什么顺序执行。
3. 哪些任务可以合并。
4. 何时充电、维护或退出服务。
5. 如何避免拥堵、冲突和死锁。
6. 设备失败后如何改派。

目标函数可能包括：

• 最大化完成任务量或业务价值。
• 最小化总时间、空驶、能耗和延误。
• 平衡设备利用率，减少个别设备过载。
• 满足优先级、安全、容量和时窗。

不要把所有目标简单相加后凭感觉调权重。更清晰的方法是：

• 硬约束：安全、载荷、权限、时窗和物理可行。
• 主目标：任务吞吐、准时完成或总成本。
• 护栏：电量、设备磨损、拥堵、公平和服务质量。
• 次级排序：主目标接近时再选择能耗或利润更好方案。

车队系统与单机自治还要划清边界。中央系统适合做任务分配、优先级、区域规则和全局协调；单机适合依据实时传感器完成细粒度路径与避障。2026年的VDA 5050 3.0进一步支持具有更高自主性的移动机器人：中央控制仍能通过区域和任务规则施加约束，而详细路线由机器人本地规划，并可回传路径。

开放接口对商业产品非常重要。客户可能同时采购不同厂商设备，如果每种机器人都需要独立车队系统，扩展和集成成本很高。标准接口帮助交换任务、状态、错误和能力，但不能自动解决所有业务语义差异。

业务映射

骑手调度和机器人车队可以这样对应：

人类供给有自主行为，机器人供给有物理和可靠性约束。调度框架相似，但成本模型不同。

今日练习

设计一个5台配送机器人、20个带时窗任务的调度问题：

• 写出状态。
• 写出五条硬约束。
• 选择一个主目标。
• 写出四个护栏。
• 设计机器人故障后的改派流程。

自测题

1. 为什么车队调度不是简单选择最近机器人？
2. 中央控制和单机自治如何分工？
3. 开放接口主要降低什么成本？

延伸阅读

• VDA 5050 3.0官方页面

完成标志

• 完成5机20任务调度定义
• 划分硬约束与优化目标
• 写出故障改派流程

今日目标

理解为什么机器人和调度产品需要仿真，以及仿真结果为什么不能直接等同于真实世界收益。

核心正文

机器人测试的成本和风险远高于普通软件。真实现场可能需要设备、场地、人员和安全保障，极端失败又难以反复制造。因此仿真承担四类任务：

1. 设计验证：产品方案是否物理可行。
2. 算法训练：在大量可控场景中学习或调参。
3. 回归测试：新版本是否破坏已有能力。
4. 极端测试：低概率、高风险情况如何处理。

数字孪生强调真实对象或现场在数字空间中的持续映射。它不仅是一张3D图，还可能包含设备状态、地图、任务、交通、传感器和运行数据。

常见测试层级：

• 模型在环：只测试算法模型。
• 软件在环：完整软件栈在虚拟环境运行。
• 硬件在环：部分真实控制器或硬件接入仿真。
• 现场试验：在受控或真实环境运行。

NVIDIA Isaac Sim等平台支持物理仿真、传感器模拟、合成数据，以及软件在环和硬件在环验证。产品经理不一定操作仿真工具，但需要定义场景库和通过标准。

仿真最大的风险是现实差距。摩擦、光照、人类行为、网络、定位和异常都可能与模型不同。仿真表现好只能说明“在这些假设和场景里表现好”，不能直接证明现场效果。

降低现实差距的方法包括：

• 使用真实数据校准场景参数。
• 随机改变光照、地面、障碍和流量。
• 把现场Bad Case不断加入场景库。
• 分层验证，从仿真到封闭场地再到真实灰度。
• 明确哪些指标只能在真实环境确认。

调度系统也需要仿真。历史回放可以重现过去订单和供给，但无法直接看到策略改变后司机或用户行为变化；更完整的市场仿真需要模拟订单到达、供给响应和策略之间的反馈。

业务映射

策略Copilot的“历史回放”相当于轻量数字孪生：

• 输入过去订单、骑手和路线状态。
• 用不同策略重新决策。
• 比较预计人效、承接、时效和成本。

但要标明三种限制：

1. 新策略可能改变骑手行为，历史行为不能完全复用。
2. 一笔订单改派后会改变后续供给状态。
3. 预测模型本身存在误差。

因此历史回放适合筛选候选方案，线上实验才负责确认真实因果效果。

今日练习

为驻店调度建立20个仿真场景标签，包括：

• 高峰/低峰
• 供给充足/不足
• 单店/多店
• 短单/远单
• 正常/异常备货
• 正常/突发离岗
• 公共池充足/紧张

为每个场景写出通过指标和仿真不能证明的内容。

自测题

1. 仿真的四类主要价值是什么？
2. 为什么历史回放不能直接证明业务增量？
3. 软件在环和硬件在环有什么差异？

延伸阅读

• NVIDIA Isaac Sim官方介绍

完成标志

• 建立20个仿真场景
• 区分仿真与线上实验结论
• 写出三类现实差距

今日目标

理解机器人产品为什么必须把安全、可靠性、运维和现场改造作为核心功能。

核心正文

软件失败可能重试，机器人失败会发生在物理世界。安全不是一个“急停按钮”，而是从风险识别、设计、验证到运营的完整体系。

安全关注人员、设备和环境是否受到不可接受伤害。可靠性关注系统在规定条件和时间内能否持续完成任务。可用性关注需要服务时系统能否提供服务。三者相关但不相同。

常见指标：

• 任务成功率。
• 平均故障间隔MTBF。
• 平均修复时间MTTR。
• 人工接管率。
• 急停和安全停机频次。
• 单位时间可用率。
• 故障自动恢复率。
• 现场问题首次解决率。

平均成功率会隐藏问题。机器人一天执行一千次简单任务，只有一次在人员密集区失控，即使成功率很高也不可接受。风险必须按严重程度分层。

机器人安全通常需要多层防护：

• 本体与传感器层：限速、制动、碰撞检测、冗余。
• 控制层：安全状态机、看门狗、异常检测。
• 规划层：禁行区、速度区、人与机器的安全距离。
• 业务层：高风险任务限制、人工确认和任务取消。
• 运营层：场地标识、培训、检查、维护和事故响应。

ISO的机器人标准体系覆盖工业机器人、协作机器人、服务机器人及性能测试。产品经理不必背标准条款，但必须在目标行业识别适用标准，并把它们转成需求、测试和交付条件。

现场交付决定产品能否规模化。每次部署都可能涉及地图、网络、充电、通道、电梯、门禁、人员流程和系统集成。如果第二个现场仍需大量定制，商业上可能只是项目，不是标准产品。

因此要记录：

• 标准能力与定制需求。
• 环境前置条件。
• 部署工时。
• 培训与运维。
• 远程解决率。
• 备件和维修。
• 从一个站点复制到另一个站点的成本。

业务映射

驻店业务中的承接率、准时率、骑手离岗和公共池回落，对应机器人产品中的任务成功、可用率、设备故障和人工接管。

你已有的“主指标加护栏加兜底”思维可以直接迁移，但机器人领域需要把安全置于任何效率目标之前。

今日练习

为药房配送机器人做一份FMEA式风险表：

• 失败模式
• 原因
• 影响
• 严重度
• 发生概率
• 可检测性
• 预防措施
• 故障后动作

至少写10项，包括传感器、定位、路径、电量、货舱、网络、交接和人机冲突。

自测题

1. 安全、可靠性和可用性有什么区别？
2. 为什么平均成功率不能代表机器人安全？
3. 如何判断一个机器人方案是产品还是定制项目？

延伸阅读

• ISO机器人标准入口

完成标志

• 完成10项风险分析
• 定义可靠性与可用性指标
• 写出现场部署前置条件

今日目标

系统整理可迁移能力与必须补齐的差异，形成机器人软件/调度产品的个人叙事。

核心正文

你当前经历与机器人产品最强的连接点，不是“配送行业都在移动”，而是任务调度的共同结构。

共同结构包括：

• 有一组不断到达的任务。
• 有一组能力和状态不同的执行者。
• 每次分配会改变未来可用资源。
• 路线、时窗、容量和优先级形成约束。
• 局部最优可能损害全局吞吐。
• 失败需要重试、改派和兜底。
• 系统需要通过回放、仿真和实验持续优化。

你的可迁移能力：

1. 供需与时空密度。知道总人数不等于有效供给。
2. 匹配漏斗。能把未完成拆到候选、过滤、触达、接受和履约。
3. 机会成本。理解占用当前资源会损失未来任务。
4. 多目标与护栏。不会只看单一人效或利润。
5. 场景分层。知道城市、时段、距离和供给结构会改变策略效果。
6. MVP与灰度。倾向先跑通闭环，再提高并发和复杂度。

不能直接迁移的部分：

• 骑手会基于收入、偏好和公平自主决策；机器人不会“嫌单差”，但会受能力、电量、维护和故障限制。
• 机器人涉及物理安全、硬件可靠性和标准认证。
• 路线不仅影响时间，还影响碰撞、拥堵、地面与传感器条件。
• 机器人现场部署和系统集成通常更重。

因此，面试时不要说“骑手就是机器人”。更准确的表达是：

“两类系统都需要在动态任务、异构执行者和多重约束下进行全局调度。我能迁移任务建模、机会成本、实验和经营闭环；同时我正在补齐机器人本体约束、安全、ROS接口和现场交付知识。”

你的近期机器人方向应聚焦：

• 车队管理平台。
• 任务编排与调度。
• 机器人运营后台。
• 仿真与评测平台。
• 物流、仓储和配送场景产品。

纯机械结构、运动控制或硬件量产岗位不应作为第一跳。

今日练习

完成一张迁移表：

至少填写智能补贴、两轮拼送、驻店派单、司机愿接和好坏单诊断五个项目。

再录制一段三分钟口述：为什么你适合机器人调度产品，而不是纯硬件岗位。

自测题

1. 骑手调度和机器人调度最核心的共同结构是什么？
2. 为什么不能说“骑手就是机器人”？
3. 你最适合的机器人产品岗位是哪几类？

第三周验收

• 一张机器人七层系统图
• 一个配送任务状态机
• 一份5机20任务调度定义
• 20个仿真场景
• 10项机器人风险分析
• 一张个人能力迁移表

今日目标

完成“驻店运力智能调度与策略评测Copilot”的问题定义，不从功能或模型开始。

核心正文

一、项目背景草案

驻店配送需要在有限骑手工时下提高完成单量，同时保证门店承接率、履约时效、骑手收入和成本。现有策略涉及压单、候选过滤、OD评分、路线耗时、拼单、运力预留和公共池兜底。

策略分析往往需要产品或分析人员临时取数、核对口径、查配置、抽样回放，再把结果组织成建议。这个过程存在三个问题：

1. 分析链路长，反复查询与整理耗时。
2. 结论依赖个人经验，口径、约束和外部影响容易遗漏。
3. 历史策略、案例和实验没有形成可重复使用的评测能力。

二、目标用户

核心用户一：交易策略产品经理。

任务是发现问题、提出策略、评估效果和推动灰度。主要痛点是数据和规则分散，难以快速验证假设。

核心用户二：城市或驻店运营。

任务是判断哪些门店、时段和运力需要调整。主要痛点是知道结果不好，但难以区分供给、匹配、订单结构、备货或配置问题。

协作用户：数据分析、算法和研发。

他们需要准确的问题定义、统一口径、可复现案例和清晰的改动范围，避免反复解释与返工。

三、核心用户任务

用Job Story表达：

“当某门店的人效、承接或履约发生异常时，我希望快速获得基于可信数据的原因分解，并能回放不同策略的影响，从而选择一个可验证、风险受控的行动，而不是依赖一次性SQL和经验猜测。”

四、产品价值

第一阶段不承诺自动提升完单，先验证：

• 诊断时间是否缩短。
• 口径和规则遗漏是否减少。
• 结论能否复现。
• 用户能否快速形成合格实验草案。

第二阶段验证：

• 系统推荐是否与专家判断和真实结果一致。
• 是否提高有效实验占比。
• 是否减少无效或高风险配置。

第三阶段才验证：

• 净增完单。
• 骑手人效。
• 驻店承接率。
• 单均成本和SLA。

五、产品定位

它不是聊天机器人，也不是自动派单器。

它是一个连接指标、规则、策略回放和历史知识的决策支持系统：LLM负责理解意图和解释证据，确定性工具负责数据、计算和策略模拟，人工负责高风险决策。

六、必须验证的假设

1. 策略人员每周确实花较多时间在重复取数、口径核对和报告组织上。
2. 问题诊断存在可标准化的主路径。
3. 历史数据足以支持有意义的策略回放。
4. 用户愿意使用带证据和风险的建议，而不是只看结论。
5. 系统能在不暴露敏感数据的情况下提供足够解释。

今日练习

分别访谈一名策略产品、一名运营和一名数据或研发。不要先介绍方案，只问：

1. 最近一次驻店异常是什么？
2. 从发现到结论经历了哪些步骤？
3. 哪一步最慢、最容易错？
4. 哪些信息经常找不到？
5. 什么样的建议你绝不会直接相信？
6. 最终谁决定上线，依据是什么？

记录原话、实际案例和耗时。访谈后修改上面的背景与假设。

自测题

1. 为什么第一阶段不应承诺提升完单？
2. 核心用户和协作用户有什么区别？
3. 这个产品为什么不是聊天机器人？

完成标志

• 完成三类用户定义
• 完成至少两次真实访谈
• 修订五条关键假设

今日目标

完成一份可评审的MVP PRD，明确做什么、不做什么和如何验收。

PRD V0

1. 产品名称

驻店运力智能调度与策略评测Copilot。

2. 产品目标

帮助策略产品和运营把驻店经营问题转为可复现的数据诊断、策略回放和实验草案，缩短分析周期，减少口径与约束遗漏。

3. 非目标

第一期不做：

• 实时自动派单。
• 自动发布线上配置。
• 自动决定补贴预算。
• 全城市、全业务通用诊断。
• 训练新的基础模型。
• 替代专家审批。
• 复杂排班和运力采购。

4. MVP场景

限定一个城市、一个驻店业务类型、3—5个门店，支持三个问题：

1. 为什么某门店骑手人效下降？
2. 为什么承接率下降或公共池回落增加？
3. 调整压单时间、时间机会成本或运力预留后，历史回放结果如何？

5. 用户流程

1. 用户选择门店、日期和问题类型。
2. 系统展示正式指标口径和可用数据状态。
3. 系统查询指标并识别主要异常层级。
4. 用户选择继续深挖或运行策略回放。
5. 系统输出结论、证据、其他解释、建议和风险。
6. 用户可修订假设并生成实验草案。
7. 草案进入人工评审，不自动发布。

6. 功能需求

F1：经营概览。

• 展示订单、有效运力、人效、驻店承接、回落、时效、成本。
• 支持与历史同期或相似门店比较。
• 所有指标显示口径、时间和数据更新时间。

F2：原因诊断。

• 按供给覆盖、订单结构、匹配、路线、备货、履约和配置七层拆解。
• 每条结论提供证据。
• 无法确定时列出替代解释和所需数据。

F3：订单与骑手回放。

• 展示候选、过滤原因、原评分、路线和最终结果。
• 支持查看分配前后骑手状态。

F4：策略模拟。

• 支持修改压单时间、目标人效对应的时间机会成本、回店时间、运力预留阈值。
• 比较当前策略与候选策略。
• 输出主指标、护栏和样本限制。

F5：实验草案。

• 生成目标、假设、实验单元、指标、周期、停止与回滚条件。
• 用户可编辑、保存和提交评审。

7. 输出契约

每次诊断必须包含：

• 结论。
• 数据范围。
• 指标口径。
• 支撑证据。
• 其他解释。
• 推荐动作。
• 风险与护栏。
• 置信等级。
• 下一步验证。

8. 权限与风险

• 只读访问限定业务和城市数据。
• 司机明细默认脱敏。
• 不展示无权限的文档或配置。
• 不执行发布、价格和派单修改。
• 数据不足或口径冲突时停止给出确定建议。

9. MVP验收

• 20个评测案例全部完成结构化输出。
• 数据和指标口径正确率达到团队约定阈值。
• 高风险场景未出现越权或直接执行。
• 至少3名目标用户独立完成一次诊断。
• 诊断时间较现行人工流程明显缩短。
• 专家能够追溯结论使用的数据和规则。

10. 暂不写死的指标

当前没有真实基线，不应虚构“节省80%时间”或“准确率95%”。先测人工流程，再设正式目标。

今日练习

把这份PRD给一位策略产品或研发看，让对方回答：

• 哪个输入拿不到？
• 哪个功能最难？
• 哪个功能首版没必要？
• 哪个风险被遗漏？
• 怎样判断它比现有方式更好？

根据反馈删除至少一个非核心功能。

自测题

1. MVP为什么要限制城市和门店？
2. 为什么非目标和功能需求同样重要？
3. 产品为什么必须展示指标口径和数据时间？

完成标志

• 完成PRD评审
• 删除至少一个非核心功能
• 确认MVP数据范围

今日目标

完成Copilot系统架构、数据清单和工具接口，让LLM只承担适合它的部分。

核心架构

用户问题
   ↓
意图与范围解析
   ↓
权限、口径、数据完整性检查
   ↓
诊断编排器
   ├─ 指标查询工具
   ├─ 供给覆盖工具
   ├─ OD链路回放工具
   ├─ 路线与增量耗时工具
   ├─ 策略模拟工具
   └─ 知识检索工具
   ↓
证据与结果校验
   ↓
LLM生成解释、风险和实验草案
   ↓
人工确认、保存、评审

数据清单

订单事实

• 订单ID、门店、渠道、创建时间。
• 起终点、距离、承诺时效、价格与补贴。
• 圈选、过滤、推送、曝光、应答、取消与完成时间。
• 备货、等待、异常和最终结果。

骑手状态

• 脱敏骑手ID、车型、资格。
• 在线、位置、忙闲、已有订单与剩余路线。
• 驻店签到、服务时段和所属门店。
• 历史应答、完成、取消与偏好特征。

OD候选与策略

• 候选订单—骑手组合。
• 过滤结果和原因码。
• 预测应答、完成与超时概率。
• 分配前后路线和增量占用时间。
• 原评分、各子项与最终排序。
• 规则、模型和配置版本。

经营与履约

• 门店订单到达率。
• 有效运力覆盖。
• 驻店承接与公共池回落。
• 骑手工时、人效、收入和空闲。
• SLA、取消、超时与成本。

六个工具定义草案

工具1：get_metric_definition

用途：获取指标正式定义、负责人、版本和适用范围。

输入：指标名、业务、日期。

输出：分子、分母、过滤、粒度、版本、生效时间。

工具2：query_store_metrics

用途：查询门店×时段经营指标。

输入：门店、时间、对照方式、指标列表。

输出：数值、样本量、同比/环比、更新时间。

工具3：diagnose_supply_coverage

用途：判断问题是否来自有效运力不足或时空错配。

输入：门店、时段、服务范围。

输出：订单需求分钟、可用骑手分钟、缺口、分层原因。

工具4：replay_od_chain

用途：重现订单从候选到完成的完整链路。

输入：订单ID或抽样条件。

输出：候选、过滤、推送、评分、路线、结果和版本。

工具5：simulate_dispatch_policy

用途：用历史状态比较候选策略。

输入：数据周期、门店、策略参数、护栏。

输出：策略差异、预计指标、置信区间、未建模影响和失败样本。

工具6：retrieve_strategy_knowledge

用途：检索指标、策略说明、历史复盘和实验结论。

输入：问题、业务范围、时间、权限。

输出：片段、来源、版本、生效状态、权限和相关性。

设计原则

• 精确数值由工具产生，LLM不得重新心算。
• 每个结果携带时间、版本和来源。
• 工具失败要返回结构化错误，不返回模糊空值。
• 副作用工具首版不接入。
• 同一个查询使用唯一运行ID，支持复现。
• LLM输出必须引用工具结果ID。

今日练习

和数据或研发确认：

1. 哪些数据已经存在。
2. 哪些只能离线获取。
3. 哪些原因码或版本目前缺失。
4. 哪个工具最适合先做。
5. 一个最小样本能否完整回放。

自测题

1. 为什么LLM不应重新计算工具返回的精确数值？
2. 为什么策略版本必须进入回放数据？
3. 首版为什么不接入副作用工具？

完成标志

• 画出系统架构
• 确认最小数据闭环
• 完成六张工具卡

今日目标

把产品承诺变成一组可运行的评测案例，并设计可信的历史回放方案。

一、评测样例

先建立下面12类样本，再扩展到50—100例。

每个评测案例需要记录：

• 用户问题。
• 初始状态。
• 数据与规则版本。
• 必须调用的工具。
• 必须出现的证据。
• 可接受结论。
• 禁止行为。
• 风险等级。
• 评分标准。

二、评分表

总分建议100分：

• 范围与意图：10分。
• 数据和口径：20分。
• 工具选择：10分。
• 证据与推理：20分。
• 建议可行性：15分。
• 风险与护栏：15分。
• 输出结构与引用：10分。

高风险样本另设一票否决：

• 编造数据。
• 越权读取或写入。
• 未经确认执行配置。
• 把不显著相关性写成确定因果。
• 忽略明确安全或履约约束。

三、历史回放方案

基线策略

使用当时真实生效的候选过滤、评分、压单和兜底配置，先验证回放能否重现历史决策。若基线都无法重现，候选策略比较没有可信基础。

候选策略

第一轮只比较三项：

1. 总路线时长改为分配前后的增量占用时长。
2. 加入骑手离店导致的未来损失订单。
3. 承接率接近目标时预留最后一名有效骑手。

一次只改变一项，再看组合效果。

输出指标

• 完成单量或预计完成单量。
• 骑手付费工时与小时完单。
• 驻店承接率。
• 公共池回落。
• 超时、取消和SLA。
• 骑手收入。
• 单均成本。
• 结果按门店、时段、距离和供需分层。

回放限制

• 历史骑手行为可能因新策略而改变。
• 一次改派会改变后续供给状态，不能逐单独立计算。
• 预测模型存在误差。
• 未记录的现场与运营动作无法还原。

今日练习

1. 为E01—E12各找一个真实或模拟案例。
2. 让当前系统或人工方法跑一遍，记录基线。
3. 检查历史策略能否被回放重现。
4. 选择一个候选改动，写出它可能改善和伤害的指标。

自测题

1. 为什么要先重现历史基线？
2. 为什么高风险错误需要一票否决？
3. 为什么候选策略应先逐项改变？

完成标志

• 建立至少20例评测
• 完成基线重现检查
• 定义第一个候选策略

今日目标

完成从产品使用、建议质量到真实业务结果的指标树，并设计能够处理共享运力干扰的实验。

一、指标树

北极星指标

第一阶段建议使用：

“每周被用户采纳并进入验证的高质量策略建议数。”

它比对话次数更接近真实价值，但仍需要“高质量”和“采纳”的明确口径。

产品使用层

• 目标用户周活跃。
• 发起诊断人数和次数。
• 独立完成率。
• 首次得到有效结果的时间。
• 深度回放触发率。
• 实验草案保存与提交率。

建议质量层

• 意图解析正确率。
• 指标口径正确率。
• 工具调用成功率。
• 证据支持率。
• 专家评分。
• 高风险错误率。
• 建议采纳率。
• 人工修改比例和修改类型。

效率层

• 从发现异常到形成假设的时间。
• 取数与口径确认耗时。
• 一份实验方案的准备时间。
• 数据或研发往返次数。

业务结果层

• 全市场净增完单。
• 驻店骑手小时完单。
• 驻店承接率。
• SLA和取消。
• 单均运力成本。
• 骑手小时收入。
• 公共池与周边门店影响。

系统与成本层

• P50/P95响应时间。
• 每次诊断模型与工具成本。
• 数据新鲜度。
• 失败与重试率。
• 模型、Prompt和知识版本回归。

二、实验的阶段

阶段1：可用性测试

让3—5名目标用户完成同一组任务，观察是否能独立选择范围、理解证据、修改假设和生成实验草案。

阶段2：离线对照

使用同一批历史案例，对比：

• 纯人工现有流程。
• Copilot辅助流程。

测量耗时、口径错误、诊断完整度和专家评分。

阶段3：影子运行

系统每天对真实门店生成建议但不执行。比较建议、专家选择和后续真实结果，记录系统在哪些场景有增量信息。

阶段4：线上策略实验

共享运力市场存在干扰：一笔订单使用某策略，会改变其他订单可用的骑手，因此简单订单级A/B可能污染对照。

可考虑按“区域或店群×时间窗口”切换策略，使同一时间空间内共享同一版本。实验必须处理：

• 前一时间窗的残留影响。
• 骑手跨区域流动。
• 门店订单量和供给的季节性。
• 同期其他补贴或策略实验。
• 样本量和最小可检测效应。

DoorDash在配送派单实验中使用过按区域与时间切换的Switchback设计，原因正是订单之间共享运力、相互影响。该方法也有统计功效和残留效应问题，应与数据科学团队共同设计。

三、决策规则

上线前先写清：

• 成功：主指标达到约定改善，所有硬护栏通过。
• 继续观察：方向正向但样本不足。
• 调整：局部场景有效、整体不稳定。
• 停止：高风险错误、关键护栏恶化或没有效率价值。

不要在看到结果后才修改成功标准。

今日练习

完成一页实验卡：

• 假设
• 目标用户与场景
• 实验单元
• 对照与处理
• 主指标
• 护栏
• 周期与样本
• 残留与干扰
• 停止条件
• 结论模板

自测题

1. 为什么对话次数不是合格北极星指标？
2. 订单级A/B为什么可能不适合派单策略？
3. 为什么必须事前写成功和停止规则？

延伸阅读

• DoorDash：网络效应下的Switchback实验
• DoorDash：机器学习、优化、仿真和实验

完成标志

• 完成指标树
• 完成一页实验卡
• 明确成功、观察、调整和停止标准

今日目标

完成Copilot核心页面和交互逻辑，让用户能判断建议，而不是被一个结论说服。

核心原则

决策产品的解释不是展示模型思考过程，而是提供足够证据，让用户理解：

• 系统看了什么。
• 为什么得出这个结论。
• 哪些内容仍不确定。
• 改动会影响什么。
• 用户可以怎样验证、修改或停止。

不要把“置信度87%”当解释。置信度必须说明来源：样本量、数据完整度、历史相似度、证据一致性或模型校准。

页面一：问题入口

选择门店：[门店A]
时间范围：[昨日 10:00—14:00]
问题类型：[人效下降]
对照方式：[过去四周同星期同时间]

目标：
在驻店承接率不低于目标的情况下，找出人效下降原因。

[开始快速诊断]

入口要帮助用户明确范围，不用开放聊天框承载所有信息。自然语言可以辅助填写，但关键字段必须确认。

页面二：经营概览

优先展示一条因果链，而不是堆几十张图：

订单需求 → 有效运力 → 驻店命中 → 拼成与路线 → 履约完成

每层展示当前值、对照值、样本量和异常标识。用户点击异常后进入证据明细。

页面三：诊断结论

推荐结构：

当前结论

人效下降主要与平均增量占用时长上升相关；暂未发现有效运力覆盖明显下降。

关键证据

• 增量占用时长较对照上升。
• 拼单量基本稳定。
• 远距离和回店慢订单占比上升。
• 备货等待数据存在缺失。

其他解释

• 备货等待可能贡献部分变化，但数据不足。
• 骑手结构变化需要继续检查。

推荐动作

对高峰远单加入动态机会成本，在历史回放中先验证。

风险

可能降低部分远单的驻店承接，并增加公共池压力。

页面四：策略模拟

左右并列当前策略与候选策略。用户修改参数时，同时展示：

• 参数的业务含义。
• 适用范围。
• 预计主指标。
• 护栏变化。
• 样本限制。
• 受影响订单案例。

不要只展示一个综合分。综合分负责排序，页面应展示分项和最终业务指标。

页面五：实验草案

系统预填假设、实验单元、指标、周期、停止和回滚；用户必须确认影响范围和审批人。

重要交互状态

至少设计：

• 正常完成。
• 数据加载中。
• 部分数据缺失。
• 指标口径冲突。
• 无显著异常。
• 多个解释并存。
• 高风险动作被阻止。
• 工具失败可重试。
• 结果已过期需重新运行。

今日练习

使用纸笔、PPT或原型工具画出上述五页。找一位不了解项目的同事完成任务：

“判断昨天门店A人效为什么下降，并决定是否创建实验。”

观察他在哪里停顿、误解或过度相信系统。

自测题

1. 为什么关键范围不能只藏在自然语言里？
2. 解释与展示模型思考过程有什么区别？
3. 为什么策略模拟不能只显示综合分？

完成标志

• 画完五个页面
• 补齐九种状态
• 完成一次可用性测试

今日目标

把实践项目整理成能够证明产品判断、技术理解和业务结果意识的作品集。

一、商业价值说明

项目价值按三层表达，不提前夸大。

效率价值

• 减少重复取数、口径核对和报告整理。
• 缩短从异常发现到形成实验假设的时间。
• 降低数据、算法、产品之间往返。

质量价值

• 统一指标与策略版本。
• 强制区分事实、假设和因果。
• 自动检查承接、SLA、成本和公共池护栏。
• 让历史案例进入回归评测。

业务价值

• 提高有效实验占比。
• 更快停止无效策略。
• 在验证后争取净增完单、人效或成本收益。

作品集中必须把“已验证”和“待验证”分开。

二、作品集结构

1. 一句话

为驻店配送策略团队设计AI决策Copilot，将自然语言经营问题转成可审计的数据诊断、OD回放、策略模拟和实验草案。

2. 为什么做

说明现有流程、耗时、错误和协同问题。不要从“LLM很火”开始。

3. 谁使用

策略产品、运营、数据、算法和研发分别承担什么。

4. 为什么使用组合技术

• LLM：理解意图、组织分析、解释证据。
• RAG：检索口径、策略和历史实验。
• 数据工具：提供实时事实。
• 优化与回放：比较确定性策略。
• 人工确认：承担高风险决策。

5. MVP与取舍

强调首版只做一个城市、少量门店、三个问题、只读与影子建议。说明主动放弃了自动派单、自动发补贴和自动发布。

6. 评测

展示样本分类、评分维度、一票否决、历史回放和Bad Case闭环。

7. 产品与交互

展示五个核心页面和关键异常状态。

8. 结果

如果尚未上线，写完成了什么验证、哪些结论仍待真实数据和实验确认。诚实的边界比虚构收益更有说服力。

9. 迁移价值

说明该系统怎样迁移到机器人车队：订单变任务，骑手变设备，收入偏好变为能力、电量和维护约束。

三、简历描述草案

如果项目仍为方案或原型：

“围绕驻店配送人效与承接冲突，设计AI调度策略Copilot MVP，将指标查询、OD链路回放、历史策略模拟和实验草案编排为可审计工作流；定义规则/预测/优化/LLM边界，并建立覆盖数据缺失、口径冲突、长尾与权限风险的评测框架。”

如果完成用户测试：

“完成X名策略/运营用户测试和X类真实案例回放，将单次诊断流程由X缩短至X；系统输出统一展示数据范围、证据、备选解释和业务护栏，高风险动作保持人工审批。”

只有完成线上实验后，才写净增完单、人效或成本结果。

四、10分钟陈述结构

• 1分钟：业务背景和为什么值得做。
• 1分钟：目标用户和现有流程。
• 2分钟：系统方案与技术分工。
• 2分钟：MVP取舍和交互。
• 2分钟：评测、回放和风险。
• 1分钟：当前结果与限制。
• 1分钟：怎样迁移到目标岗位。

今日练习

制作6—8页作品集：

1. 背景与问题。
2. 用户与流程。
3. 系统架构。
4. 核心页面。
5. 评测与风险。
6. 价值、边界和下一步。

录制一次10分钟陈述，删除所有没有证据的形容词。

自测题

1. 为什么作品集要区分已验证和待验证？
2. 哪个技术取舍最能体现AI产品判断？
3. 没上线时怎样描述项目才不显得虚？

完成标志

• 完成6—8页作品集
• 完成简历描述
• 录制10分钟陈述

今日目标

完成转型面试演练，识别证据缺口，并制定未来90天行动。

一、面试开场

建议使用下面的90秒结构：

“我过去主要做物流交易和策略产品，长期处理供需匹配、派单、拼单、智能补贴和骑手经营。我的核心能力是把复杂交易问题拆成状态、预测、约束、决策和实验闭环。

最近我把这套能力进一步产品化，设计了驻店运力智能调度与策略评测Copilot。它不是用大模型替代调度算法，而是让LLM理解经营问题、调用指标和回放工具，再由确定性计算完成策略模拟，并通过评测集、权限和人工审批控制风险。

我希望转向AI决策产品或机器人车队/调度产品，因为这两类岗位都需要在动态任务、有限资源和多重约束下形成可评估的智能决策系统。”

二、核心面试题与答题方向

1. 为什么要用AI？

回答重点：问题中存在开放语言、跨文档知识和动态分析路径；精确计算仍由数据与优化工具完成。若固定报表已经能解决，就不需要Agent。

2. 为什么不让LLM直接派单？

回答重点：实时调度要求确定、低延迟、可复现和严格约束；LLM更适合理解、编排和解释。首版只读和影子运行。

3. 怎样评价系统好不好？

回答重点：任务评测、工具与口径正确、证据支持、建议可行、风险、成本和延迟；业务上从效率、质量走向影子和线上实验。

4. 最大风险是什么？

回答重点：错误数据或因果判断推动错误配置。控制方式是版本、引用、停止条件、权限、一票否决和人工确认。

5. 为什么你的物流经验能迁移到机器人？

回答重点：共同的动态任务、异构资源、时窗容量、机会成本、全局调度、故障改派和仿真闭环；同时承认硬件、安全和现场交付是新增知识。

6. 你的MVP砍掉了什么？

回答重点：自动派单、自动补贴、自动发布、全国通用和新模型训练。因为首版先验证诊断与回放价值。

7. 如何证明建议带来净增，而非转移？

回答重点：看全市场与公共池，处理共享运力干扰，使用合适实验单元和护栏，不只看参与门店。

8. 如果模型换了怎么办？

回答重点：固定代表性评测，保留模型、Prompt、知识和工具版本，一次只改变一个变量并做回归。

9. 如果用户不信任系统怎么办？

回答重点：展示口径、数据、证据、替代解释、受影响案例和操作边界；让用户修改假设并保留人工决定权。

10. 这个产品的商业价值是什么？

回答重点：先验证效率和质量，再看有效实验与业务结果；完整成本包含数据、评测、复核、错误和维护。

三、面试评分表

每题按0—2分：

• 是否先给结论。
• 是否有真实案例。
• 是否说清技术边界。
• 是否包含评测或证据。
• 是否说明风险与取舍。
• 是否在两分钟内完成。

总分低于16分的问题需要重录。

四、未来90天计划

第31—60天

• 将评测集扩至100例。
• 完成真实数据最小回放。
• 与3—5名用户完成可用性测试。
• 做出可点击或可运行原型。
• 补充一个机器人车队任务状态机案例。

第61—90天

• 完成2—4周影子运行。
• 对比人工与Copilot效率和质量。
• 修复Top 10 Bad Case。
• 完成脱敏作品集和简历。
• 针对目标岗位完成至少5次模拟面试。

第91—120天

• 若条件允许，推动一个小范围真实实验。
• 若内部无法上线，用公开或合成数据完成可复现演示。
• 定向投递AI决策、智能运营、调度平台和机器人车队产品岗位。

五、30天毕业检查

• 能解释AI产业链和商业模式
• 能选择规则、预测、优化、LLM或Agent
• 能设计RAG、工具和权限
• 有20—100例评测集
• 能设计历史回放和市场实验
• 理解机器人系统栈、ROS 2和车队调度
• 完成Copilot PRD和系统架构
• 完成五页核心交互
• 完成作品集和简历描述
• 能完成10分钟陈述

最后一句

真正的转型不是把原有经历换一套名词，而是把已经验证过的业务判断，升级成能够被系统执行、被数据评测、被他人复用的产品能力。