← 返回周目标

直播电商场景落地方案 设计

日期：2026-10-09；10-10 按 1010 会和 ndclaw 已确认事项回修。对象：本周目标二（周目标原文未入库，三项周目标见 10/16 结项待办「周目标」一条；任务跟踪在 multica AIC-2703），梳理直播电商场景的任务流程、所需 Agent 能力和接入方式，明确与团团的协作机制和开发范围，作为 10/16 交付的依据。它是结项目标 ①「想法 → 目标与计划，匹配 AI 能力与资源推动落地」的演示情景。技术底座见姊妹篇 团团与外部 Agent 协作技术方案。

性质三分：白晨已定／本文提案／待白晨定，每条规则都标明。合作方材料是飞书文档「AI直播团队工程设计V2.0」（下称「直播团队设计」，https://my.feishu.cn/docx/O1K5dRx6aoGvJHxpA6ycBdEnndf）。它还没有存入 knowledge/sources/，见第 8 节。

1. 目标与范围外

目标

  1. 回答吴梦赢 10/8 提的问题：电商拆成多少个 Agent、怎么调用，这周或下周要定（10/8 周目标会解读第一节第 5 条）。本文答案：9 个 ndclaw 专家，加上团团里的 1 个直播电商场景包。
  2. 10/16 演示（本文提案）：一位新手主播从立项开始，经过定位、主题、选品、排品、脚本五个环节，每个环节都由 ndclaw 专家真实完成，交付自动带入下一环节，最后拿到一份可用的直播脚本。
  3. 对合作方：列清楚提示词要改哪些地方（第 6 节）。合作方「愿意配合修改」，「先由协调 Agent 派单」的机制「不必照搬」（白晨 10/8 语）。

范围外

2. 演示故事（本文提案）

小林第一次做直播，想在小红书卖「小而美家居」小物件，手上有一批香薰和杯具的货源，计划下周六晚播 60 分钟。

步 发生什么 谁在干活
1 小林对团团说想法。团团按直播电商场景包问清赛道、经验、开播时间与时长、货源和约束，生成项目摘要；小林点「开工」 团团
2 画布上出现直播筹备的任务图，每个任务标出建议的专家 团团
3 「主播定位」派给定位专家。小林在任务工作间里一步步选择，专家交付定位卡（一句话定位、人设、用户画像、审美风格） 定位专家 ＋ 小林
4 团团预审后，小林验收；定位卡自动带进「主题策划」的任务书 团团 → 主题专家
5 主题 → 选品 → 排品 → 脚本，依次接力。选品走「已有货源、跳过样品测试」这条路径 各专家 ＋ 小林
6 拿到整场流程脚本加商品讲解手卡，团团汇报进度、列出下一步（物料、播前检查）和需要小林做的线下准备 团团

3. 角色映射

3.1 主管 → 团团的「直播电商场景包」（白晨 10/8 初步想法，1010 会确认方向；具体做法为本文提案）

白晨 10/8 的初步想法（当时说明「不作为正式的讨论」）是：直播团队的 leader（主管）做成平台拆解任务的 skill，子 Agent 全部放到 ndclaw 上。1010 会白晨再次确认：对方的 Agent 全是提示词，封装成 skill 挂到团团上，团团就有拆分能力；陈高武补充不能整体照搬、要打散成各个 Agent 和 skill，团团需要时再指派，白晨同意（1010 会解读页 第二节第 3 条）。本文照这个方向做，但团团承担的比原主管多：

原主管的职责 在团团里变成 团团额外负责
判断用户处在哪个阶段（新手从定位开始，有定位的从主题开始……） 场景包的「立项维度」和「起始环节规则」 目标与成功标准、预算、授权清单
采集基础信息（直播时间、时长、价格和数量偏好、库存约束、发布平台） 立项维度（问到够开工就开工，其余标「待补」，用到时再问） 项目事实
派单时附带赛道标准名和结构化信息 任务书（按任务模板从项目事实里取字段） 匹配执行方
识别员工的收尾话术，切换到下一环节 交付块 → 预审 → 验收 → 写入项目事实 预审、验收
交接表（每个环节要传给下一个环节的字段） 任务模板之间的依赖关系 变更传播（10 月底）
用户中途入场时补齐缺失的上游字段 立项时把已有成果录成项目事实，跳过对应任务 —
员工上报上游数据矛盾时，回到源头修正 上报块 → 团团处理 改动记录

3.2 九个员工 → 九个 ndclaw 专家（本文提案）

专家（skill 标识） 职责 任务书里的上游字段 交付 交互特征 10/16
主播定位设计师（anchor-position-designer） 定位、人设、用户画像、账号设置 赛道（用户自述） 定位卡：赛道标准名、一句话定位、人设类型、用户画像、审美风格、账号设置 多轮，13 步逐项选择 ✅ P0
主题策划师（live-theme-planner） 本场直播主题 赛道、一句话定位、人设、用户画像、直播时间 主题方案：名称、目标受众、切入点、人设匹配、选品方向 多轮，要用户确认 ✅ P0
直播选品官（live-goods-selection） 选品方案、样品测试、商家确认、最终选品表 赛道、主题、目标人群、核心价值主张、人设适配点、价格和数量偏好 最终选品表：品类、角色、价格、核心信息 多轮；有线下环节（测样、和商家沟通） ✅ P0（走「已有货源」路径）
直播排品专家（live-goods-schedule-arrange） 讲解顺序与时间分配 赛道、主题、选品表、直播时长 排品时序表 基本一次完成 ✅ P0
直播脚本设计师（live_script_generator） 整场流程脚本、商品讲解手卡 赛道、主题、人设、用户画像、选品表、排品表、时长 流程脚本 ＋ 讲解手卡（原设计可下载 Word／Excel） 分批输出；要产出文件 ✅ P0（10/16 先出文本）
直播物料制作师（live_preheat_planner） 封面图、种草图、预告视频方案 赛道、主题、日期时间、人设、审美、用户画像、选品表、发布平台 物料方案和发布引导 要出图 P1（只出文字方案）
直播前调试专家（live_before_check） 场地、设备、话术合规、价格库存检查 赛道、人设、主题、选品表、排品表、脚本 开播前检查确认 多轮；有线下环节 P1
直播复盘师（live_data_reviewer） 数据诊断、归因、利润核算 赛道、全部上游成果、直播数据 复盘报告 要用户上传截图 P1（用示例数据）
直播售后助手（live_aftersale_helper） 售后纠纷，出买家和商家双方的话术 赛道、售后事件 处理方案 随时可用，不在主链上 P1

为什么 P0 选前五个：它们是主链上连续的五环，全部是文本交付，一次演示就能走完；选品的线下环节可以走「已有货源」路径绕开。后四个分别卡在出图、线下、真实数据或「随时」这几个因素上，放进 10/16 只会增加风险，不增加主链说服力。

模型写法不一致：每个 skill 头部写的是 deepseek-v3，团队配置表里多数成员写 Kimi-k2.6、个别写 doubao-seed-2.0-Pro。ndclaw 支持按请求指定模型（metadata.model，同一上下文内一直沿用；可用模型用 /a2a/models 查，见 ndclaw 对接报告 1.3 第 6 项），所以按专家选模型做得到，用哪个以合作方定的为准（第 8 节）。

4. 任务流程与场景包内容（本文提案）

主流程：

立项（团团）→ 主播定位 → 主题策划 → 选品（含测样、商家确认）→ 排品 → 脚本 → 物料 → 播前检查 → 开播（用户本人）→ 复盘
                                                                      售后：随时

新手从定位开始；已有定位的直接从主题开始，以此类推（照搬原主管的「判断用户阶段」规则）。

场景包 scenarios/直播电商/ 的内容：

部分 内容
立项维度（必问四项以外） 赛道（标准名：小而美家居、美妆个护、女装穿搭）；直播经验与起始环节；开播日期和时长（默认 60 分钟）；货源和库存；价格与商品数量偏好；必须包含或排除的品类；发布平台（默认小红书）
指标 筹备期：各环节按时交付并通过验收。开播后：成交额、转化率、毛利（来自用户回报）
任务模板 第 3.2 节的九项，每项写清所需能力标签、上游字段、交付字段、验收标准、是否有线下环节
关卡 播前检查之前，脚本必须通过合规自检（违禁词、功效宣称，知识库里已有）；商品、价格、库存、话术、链接要前后一致
调整规则 用户跳过某个环节时，把缺的上游字段补齐；上游有矛盾时，回到源头重做；同一商品连续出现售后问题，提议下架或换供应商

5. 协作机制（本文提案）

  1. 用户和专家直接对话。原设计本来就是「员工和用户直接沟通」，所以每个专家任务都在任务工作间里进行，团团旁听。白晨 1010 会定：也要支持只要结果，由团团凭项目事实代答专家的问题，做成可选（姊妹篇 3.7，10/16 做最小版）。P0 五环里定位、主题都要用户逐项选择，10/16 演示以交互模式为主。
  2. 团团在关键节点接手：开工派单、收到交付块（预审）、收到上报块、执行停滞（催办）、环节之间交接。
  3. 线下环节：选品的样品测试、和商家沟通，以及播前布置场地，专家用「等待线下」块挂起。团团记进待办并提醒用户；用户回来回报结果后，专家继续。
  4. 售后和复盘随时可用：用户可以随时打开对应专家的工作间；团团把售后情况记进项目，发现规律（比如同一商品反复出问题）时提出调整。

6. 直播合作方要改的地方（本文提案）

# 改什么 为什么
1 不再依赖「主管」，改成从任务书里读输入；去掉「@主管」和「主管自动传入」之类的说法 主管由团团接管
2 收尾话术改为输出交付块（格式见姊妹篇 3.5 节），每个专家的交付字段按第 3.2 节的表定 平台才能可靠地判断完成，并把交付带到下游
3 缺少上游字段、发现上游有矛盾，或判断这件事做不了时，输出上报块并写明原因，不再重复问用户已经回答过的问题 由团团从项目事实里补齐；做不了的由团团给用户换人或调整的选项（姊妹篇 3.6）
4 需要用户线下操作时，输出等待线下块 让任务状态和提醒可以管理
5 文件产出（脚本的 Word／Excel、物料图）：10/16 先用文本表格。ndclaw 上专家产出的文件会自动上传、以会过期的链接写在回复里，平台收到后转存（姊妹篇 3.4 节），以后可以直接交文件 ndclaw 的 A2A 只收发文本，文件都以链接传递
6 统一模型写法；知识库按专家拆开挂载 原设计两处写法不一致；每个专家只带自己用得上的知识库，省 token

兜底：如果合作方来不及改，平台先用各员工的固定收尾话术识别完成（姊妹篇 3.5 节）。第 1 条在任务书里加一段适配说明就能临时绕过。

7. 开发范围与分工（本文提案，负责人待定的部分标「待定」）

工作项 内容 建议负责方
场景包 把主管的逻辑改写成直播电商场景包（SKILL.md ＋ pack.yaml），团团加载 林炜
执行方对接 执行方登记、ndclaw A2A 适配器、执行记录、交付块解析、任务书拼装（姊妹篇第 2、3 节） 林炜（待定）
任务工作间 UI 工作间对话、执行状态、预审和验收入口 陈高武（周目标三）
合作方改造 第 6 节的六项 直播合作方（范敬萍；10/8 周目标会转写作「范金平」，林炜 10/10 确认是同一人）
专家上架 在 ndclaw 界面创建 9 个专家（至少 P0 的 5 个）并发布到市场；选品、售后连上知识库超长，做成技能包挂到专家上 我方或范敬萍，谁先有空谁做（ndclaw 报告 1.4 待办 2、3）
ndclaw 侧 在 AIAE 生产环境打开 A2A，给我方 BTS 应用开通接口权限；演示期的预热池先联调、再按需申请 AgentHub 方（ndclaw 报告 1.4 待办 1 与待定）

时间安排（本文提案）：

日期 任务
10/12 打通 ndclaw 环境和鉴权，导入 P0 的 5 个专家
10/12～10/13 执行方对接后端
10/13～10/14 场景包、任务工作间前后端联调
10/15 全链彩排
10/16 交付

8. 风险与待确认

风险与应对：

风险 应对
ndclaw 侧的 A2A 开通与 BTS 授权在 10/14 前没办下来（用户体系已确认是同一套） 备选方案：九个 skill 都是纯提示词，可以先在平台进程里用团团的 Capability 机制直接运行，演示同一条主链。这样损失的是「外部 Agent 协作」这层说服力，但能保住演示（待白晨定）
冷启动导致演示时卡顿 演示前预热；界面上用「专家准备中」状态承接等待
合作方来不及改提示词 第 6 节的兜底做法
合规（违禁词、功效宣称） 脚本合规自检列为关卡；合作方的知识库里已有相关内容

待白晨定：

  1. P0 是否就是这五个环节；
  2. 是否接受「进程内运行」作为备选方案；
  3. 物料环节 10/16 是否只出文字方案。

待合作方确认：

  1. 第 6 节六项改造能否在 10/12 前完成；
  2. 以哪个模型为准。

合作方一侧的人是范敬萍（第 7 节）。

ndclaw 侧：见 ndclaw 对接背景与待确认项 第一节。已确认（1.3）：用户体系同一套；实例每天自动开通 4000 个、无需审核（林炜 10/10 确认）；先在正式环境联调；专家先不隔离、直接上架到市场。待办（1.4）：开通 A2A 与授权、创建并上架专家、选品和售后做成技能包。预热池先联调、再按需申请。

资料入库：直播团队设计是外部方交来的材料，按知识库规则要存入 knowledge/sources/商务与外部/ 并登记（AIC-2693 的待办之一）。

9. 依据