目标驱动广告自动化 → Multi-agent Operations Platform ｜ 调起产品、技术开发、测试、业务、评估集五个环节的管理工具
linxx 时间节点评论 + LUC-1375 里程碑合并。红色实心点为硬性节点；所有工作流的排期均倒推自这条轴。
Owner 列中「建议」为本稿预填、供会上确认或调整的人选（依据 issue @ 记录与分工惯例），不是既定事实。引用约定：linxx 两条评论记作「linxx 时间节点评论」与「linxx-8.8#N」。
| 编号 | 工作流 | 优先级 | 先行方 | 服务锚点 | Owner |
|---|---|---|---|---|---|
| WS1 | 数据准确性（Amazon 口径）与自动执行门禁 接口核对 · 取数逻辑 · 虎一数据部 · 门禁 | P0 · 最高 | 技术先行→业务确认 | 全局门禁；~8/15 前 | 技术：建议 Wang Dylan 指定专人口径确认：建议 Mario |
| WS2 | 目标计划与运营计划 融合 linxx-8.8#7 主动 operational goal | P0 | 产品先行 | 8/31 GTM | 产品：建议 H Eee |
| WS3 | Workspace Template 模板 = workspace 维护单元 | P0 v2.1 | 产品先行→技术 | 8/12 冻结 → 9/4 | H EeeWang Dylanissue 指定调研 |
| WS4 | Operations Event Center 运营时间的事件触发 · 含 daily follow-up | P0 v2.1 | 技术框架先行∥ 产品业务定义事件 | 8/12 → 9/4 | Elio XuWang DylanH Eeeissue 指定事件约定 |
| WS5 | 团队上下文与云端规划 / 折中规划 | P0 v2.1 | 技术先行出方案 | 8/12 冻结前出结论 | Wang DylanH Eeeissue 指定调研 Viktor |
| WS6 | Slack Agent 集成 海外主打场景 | P0 v2.1 | 技术通路先行∥ 产品场景并行 | 9/4 | H EeeWang Dylanissue 指定 |
| WS7 | 新手引导与首值体验 调研分流 + prompt 建议 + 手册融入 | P0 linxx-8.8#1/#2；#9 为 P1 | 基于现有设计优化 | ~8/15 首批用户 | 建议 H Eee 落地linxx 提供用户输入 |
| WS8 | 统一 Task Overview 交互 | P0 linxx-8.8#4 | 产品/设计优化 | 设计稿 8/18 → 8/31 | 待认领（会上确认） |
| WS9 | Web→App 转化漏斗 云端简版 + 重启 1.0 设计 | P0 linxx-8.8#8 | 产品/增长设计先行 | 方案 8/18 → 8/31 GTM | 建议 linxx 牵头转化侧 |
| 人 | 背负的 P0 / 关键项 | 风险 |
|---|---|---|
| Wang Dylan | WS3、WS4、WS5、WS6（v2.1 四大 P0）+ S1 + WS1 技术（若兜底） | 四条线都要 8/12 冻结、8/28 开发完成，串行不可能，必须做减法或加人 |
| H Eee | WS3、WS4、WS5、WS6 + WS2 产品 + WS7 产品（若认领） | 产品需求初稿全部压在 8/12 前 |
| Elio Xu | WS4 事件约定 | 相对可承接，可考虑分担 WS1 技术或 WS4 框架 |
| Mario | WS1 业务口径确认（建议） | 需确认时间投入 |
| linxx | WS7 用户输入、WS9 转化、S5 访谈（建议） | 需确认时间投入 |
横轴 8/10 → 9/15，按日期精确定位。每个 P0 需求一组：组头 = 需求全名 + 边界（做什么 / 不做什么）+ Owner；组内按阶段分行，行首标 先行 的是今天就能启动、不必等他人的动作；条上标起止日期，◆ 为交付里程碑（什么时候完成什么）。
每张卡片按五个环节拆分动作，并明确先行方、前后条件（依赖）、里程碑与会上收敛点。
| 技术 先行 | ① 接口数据准确性核对（以 Amazon 后台为基准比对）② 取数逻辑成文：广告对象、父子 ASIN、Campaign / Ad Group / Keyword 范围、延迟时间 ③ amazon 账号购买测试 ④ 数据学习：对接虎一数据部（明确对接人与产出物）⑤ 口径与目标、广告指标、时间范围、数据新鲜度四者对齐 ⑥ 门禁：数据过期/缺失/冲突时阻止自动执行并给出可定位原因 ⑦ 每次评估和调整展示数据截止时间 |
|---|---|
| 业务 | 对技术产出的口径文档逐项确认（对应「用户需求业务的确定」），确认后作为唯一口径；虎一数据部协作的业务侧接口人一并明确 |
| 产品 | 定义「数据可信」的产品呈现：数据截止时间展示、阻断提示与原因定位入口 |
| 测试 | 门禁行为用例：阻断 / 放行 / 原因可定位；异常数据注入测试 |
| 评估集 | 接口数据 vs Amazon 后台比对用例集（对象层级 × 指标 × 时间窗全覆盖）；数据新鲜度阈值用例 |
| 产品 先行 | ① 目标生成器（前台上下文收集 + 广告数据收集）② 运营节奏：利润优先 / 销量优先 / 冲排名 / 新品起量 / 稳定老链接 / 清库存 ③ 核心目标追踪（ACoS、销量等：指标、当前值、目标值、周期）④ 子任务（即时任务 / long-session task）⑤ 预算、调价幅度、风险边界、禁止动作 ⑥ 检查频率、调整频率、阶段复查时间 ⑦ 融合 linxx-8.8#7：起步时主动提供 operational goal——老板层面的资源测算（例：小品类排名 100 外 → 2–4 个月进排名 50 需要多少库存/广告预算、能带来什么排名和销量），完成「主动设定」的专业能力 |
|---|---|
| 技术 | 产品需求确认后开发；实现「目标成为策略、调整、执行、复查的唯一依据」 |
| 业务 | 各运营节奏的专业判断输入：目标模板、边界值、行业经验 |
| 测试 | 目标激活 → 计划生成 → 追踪的链路用例 |
| 评估集 | 各运营节奏下「目标→计划」生成质量评估集（专家评审）；operational goal 资源测算合理性评估 |
| 产品 先行 | ① Template 作为正式产品对象的边界：目标、业务对象范围、GUI、Agent Team、Connector、Skills、Pipeline、Event、权限策略 ② 首批三个官方 Template 需求：商品广告日常运营 / 新品上市与阶段追踪 / 运营异常与危机治理 ③ 「描述目标 → 推荐 Template → 补齐创建参数」流程 ④ 版本、差异预览、升级、回退规则 ⑤ 兼顾 S2（多账号同品整合付费点）的权限与对象范围预留 |
|---|---|
| 技术 | 8/12 前给出 Template 数据模型（配合架构冻结）；产品需求确认后开发；现有商品管理 Workspace 迁移为第一个官方 Template |
| 业务 | 三个官方 Template 的运营内容输入（目标模板、节奏、事件绑定） |
| 测试 | Template 实例化正确性；版本升级/回退用例 |
| 评估集 | 「描述目标 → 推荐 Template」命中率评估 |
| 技术 先行 | ① 统一事件模型框架：Workspace/业务对象、发生时间、当前值、基线/阈值、严重度、证据、状态、幂等标识 ② 去重、聚合、冷却、升级、确认、处置、关闭机制 ③ 基于脚本 + 数据先跑通首批事件的采集与触发 |
|---|---|
| 产品 | 流程性设计：事件的设定、监控、执行、反馈、授权五环节产品流程；处置动作分级（只通知 / 创建待办 / 触发分析 / 生成方案 / 安全范围内执行 Pipeline）；本地唤起收敛注意力的交互 |
| 业务 | 首批事件的优先级与阈值定义（候选 10 个见下） |
| 测试 | 定时/自动任务的触发、状态流转用例 |
| 评估集 | 事件触发准确率评估（阈值、去重、冷却、幂等）；误报/漏报率基线 |
| 技术 先行 | ① 调研 Viktor（issue 指定）② 云端文件与 runtime 解决方案 vs 折中方案（本地/云混合）的技术规划文档：范围、成本、风险、路线 ③ 与 Cloud Runtime（issue v2.1-5，P1）协同：队列、租约、幂等、断点恢复、防离线补跑重复写入 |
|---|---|
| 产品 | 老板 / manager 视角的团队共享上下文需求输入 |
| 业务 | 团队协作场景清单（谁看什么、谁批什么） |
| 测试 / 评估集 | 待方案确定后定义（同步一致性、离线补跑防重） |
| 技术 先行 | 基于 Slack 平台的调度能力搭建：bot/app 基础、消息收发、任务调度通道、与 Luckee agent 的连接 |
|---|---|
| 产品 | 明确 Slack 场景需求：哪些流程进 Slack（通知 / 确认 / 对话 / 事件唤起）；与飞书信息同步（issue v2.0.1-7）的分工边界待会上明确——原文口径只确定了「Slack 主打海外」，飞书的目标用户定位需确认，本稿不预设 |
| 业务 | 海外首批用户的 Slack 使用习惯输入（结合首批用户反馈） |
| 测试 | Slack 消息收发、调度链路用例 |
| 评估集 | Slack 场景对话质量评估 |
| 产品 | ① 新手界面调研（#1 P0）：团队规模、角色——优先运营人员为主；按调研区分老板 vs 运营，进入界面后侧重点区分 ② 连接店铺后的 prompt 建议（#2 P0）：根据用户数据和情况生成操作 prompt 建议——降低使用门槛 + 提高粘性 ③ 操作手册融入产品（#9 P1）：加提示 i（如怎么用 workspace）——随后迭代，不卡 8/15 |
|---|---|
| 技术 | 调研分流实现；prompt 建议生成逻辑（依赖 WS1 数据可信） |
| 业务 | 运营 vs 老板两类角色的界面侧重定义；prompt 建议的专业内容审校（建议 linxx 输入用户视角） |
| 测试 | 新手流程端到端用例 |
| 评估集 | 新手激活漏斗指标（连接店铺 → 首个建议 → 首次采纳）；prompt 建议质量评估集 |
| 产品/设计 | 统一 task overview 设计：让用户像在「和一个运营经理 / 智能工具持续对话」，而不是在多个 workspace 和页面间手动切换分别查看更新；保留现有 notification 直接跳回 task 页面的优点 |
|---|---|
| 技术 | 跨 workspace 任务状态聚合 |
| 测试 | 跨 workspace 任务状态一致性用例 |
| 评估集 | 任务可发现性 / 跳转效率的体验评估 |
| 产品 先行 | ① 云端简版设计：只需考虑一个 workspace，端到端体验完整功能 ② 转化路径：需要更多 ASIN → 多 workspace → 引导下载客户端 ③ 评估重启 1.0 设计作为漏斗前端 ④ 「客户端必要性 vs 网页版」的用户沟通话术 |
|---|---|
| 技术 | 云端简版的能力裁剪与部署（与 WS5 云端方案联动） |
| 业务 | 漏斗指标定义：访问 → 注册 → 连接店铺 → 端到端体验 → 下载客户端；结合 S5 AfterShip 研究输出 |
| 测试 | 简版端到端 + 引导下载链路用例 |
| 评估集 | 漏斗各级转化率基线与追踪 |
| 编号 | 事项 | 优先级 | 处理 |
|---|---|---|---|
| S1 | 客户端自主更新（linxx-8.8#3） | P1 | Wang Dylan（linxx 点名）。▶ 建议提前到 ~8/15 前：首批用户上线后没有自更新，每次迭代都要人工引导，影响 8 月快速迭代节奏 |
| S2 | 多账号卖同一产品/链接整合到同一 workspace，作为付费功能（linxx-8.8#5） | P1 | 付费点设计纳入 WS3 Template 的权限与业务对象范围预留；交付时间待排期 |
| S3 | agent 主动 daily follow-up（linxx-8.8#6） | P1 | 并入 WS4 Event Center，作为事件的主动输出形态（首期形态建议见 WS4） |
| S4 | 测用客户是多账号、多角色的方案（linxx-8.8#10） | P2 | 业务出方案，待排期 |
| S5 | 深入学习 AfterShip + 找其 marketing 的人面试或交流（linxx-8.8#11） | P0 | 业务/marketing 负责（建议 linxx）；8/14 前完成约访，8 月内完成交流；输出反哺 WS9 转化漏斗与 GTM 策略 |
带 建议立场 的为本稿预填，会上只做确认或调整，避免开放式讨论。
| 编号 | 决策点 | 关联 |
|---|---|---|
| D1 | v2.0.1 未完成项确认（原截止 8/7 已过）。会前请 WS1/WS2 相关同学先填下方盘点表，会上只确认差异并定新截止，不做现场状态汇报 | WS1 WS2 |
| D2 | 工作流优先级排序确认 建议：WS1 > WS2 > WS3–WS6（8/12 硬点）∥ WS7–WS9（锚 ~8/15、8/31） | 全部 |
| D3 | Owner 确认：WS1 技术执行人（建议 Wang Dylan 指定专人或 Elio Xu 分担）·WS1 业务口径确认人（建议 Mario）·WS2 产品（建议 H Eee）· WS3 产品需求负责人 ·WS7 产品（建议 H Eee + linxx 输入）· WS8 设计 ·WS9（建议 linxx 牵头转化侧）·S5（建议 linxx） | 全部 |
| D4 | WS1 口径确认形式：评审会 or 文档签字；8/14 确认截止是否可行；虎一数据部对接人 | WS1 |
| D5 | a) WS4 首批事件 建议先做 4 个：预算耗尽 / Campaign 暂停 / ACoS偏离 / 授权失效，其余第二批；b) WS2 operational goal 首期覆盖品类场景；c) daily follow-up 首期形态 建议事件驱动汇总而非独立日报 | WS4 WS2 |
| D6 | a) WS3 模板「维护单元」粒度定义（8/12 架构冻结前置条件）+ 首批三个 Template 是否维持；b) WS5 上云 vs 折中 建议 v2.1 只交付规划结论 + 折中落地路径，结论 8/12 前给出 | WS3 WS5 |
| D7 | WS6 Slack 首期场景范围 建议：通知 + 确认 + 简单对话，不做流程编辑；飞书 / Slack 的用户分工边界明确（原文仅确定 Slack 主打海外） | WS6 |
| D8 | a) WS9 是否重启 1.0 设计 建议：仅作漏斗前端，不恢复完整功能面；云端简版范围（一个 workspace 端到端）确认；b) WS8 overview 与现有 notification/task 页信息架构关系 | WS9 WS8 |
| D9 | 评估集统一责任人与建设节奏 建议：随各 WS 开发同步建设，9 月封板前全量跑通 | 全部 |
| D10 | 首批海外用户具体日期确认（linxx 原文为「8月中旬」，本稿按 ~8/15 排期）+ 首批版本内容清单 建议：WS7 最小版 + WS1 门禁 + S1 自更新；若 WS7 无人认领则同步决策是否推迟锚点 | WS7 WS1 S1 |
| D11 | 技术资源分配与四大 P0 并行可行性（见 §贰 负载表）建议减法：WS5 只交付规划、WS6 技术通路 8 月下旬启动；不接受减法则明确加人或串行方案 | WS3–WS6 |
| D12 | 非 P0 项的排期处理确认：issue v2.0.1 的 3–12 项（目标自动追踪、Pipeline 串联、执行核验、Chat、飞书同步、意图记忆、复查闭环、新品 Pipeline、My Skills、Memory）随 WS2 主线推进不单列；v2.1 的 2/3/5/6 项（Multi-agent Team、Pipeline Platform、Cloud Runtime、平台治理）随 8/12 架构统一冻结、开发排在四大 P0 之后。实质性范围排序，需相关提出人会上确认 | 全部 |
| 工作流 | 已完成 | 剩余 | 风险 | 建议新截止 |
|---|---|---|---|---|
| WS1 数据准确性 | （待填） | （待填） | （待填） | （待填） |
| WS2 目标计划 | （待填） | （待填） | （待填） | （待填） |
| 输入来源 | 条目 | 去向 |
|---|---|---|
| issue v2.0.1 P0-1 | 数据准确性与自动执行门禁（amazon 口径 P0；数据学习-虎一数据部；领星 P1） | WS1 |
| issue v2.0.1 P0-2 | 目标激活与运营计划 | WS2 |
| issue v2.1-1 | Workspace Template P0 | WS3 |
| issue v2.1-4 | Operations Event Center P0 | WS4 |
| issue v2.1-7 | 团队上下文管理和同步（是否上云）P0 | WS5 |
| issue v2.1-8 | Slack 的 agent 融入 P0 | WS6 |
| linxx 时间节点评论 | 8月中旬首批海外用户 / 8月底 GTM 成品 / 9月中旬封板 | §壹 时间锚点 + D10 |
| linxx-8.8#1 | 新手界面调研、老板 vs 运营分流 P0 | WS7 |
| linxx-8.8#2 | 连接店铺后 prompt 建议 P0 | WS7 |
| linxx-8.8#3 | 客户端自主更新 P1 @Wang Dylan | S1 |
| linxx-8.8#4 | 统一 task overview P0 | WS8 |
| linxx-8.8#5 | 多账号同品整合 workspace（付费）P1 | S2（预留进 WS3） |
| linxx-8.8#6 | daily follow-up（与 Event 结合）P1 | S3 → WS4 |
| linxx-8.8#7 | 主动 operational goal（老板层面资源测算）P0 | WS2（按 8/10 口径融合） |
| linxx-8.8#8 | 云端简版 + web/app 转化（假设：网页转化效率高于 APP）P0 | WS9 |
| linxx-8.8#9 | 操作手册融入产品 P1 | WS7（随线迭代，不卡 8/15） |
| linxx-8.8#10 | 多账号多角色测用客户 P2 | S4 |
| linxx-8.8#11 | AfterShip 研究 + marketing 访谈 P0 | S5 |
注：非 P0 项的处理已升级为显式决策项 D12，不再只放脚注。