voc-ecommerce-qiwei-jtbd-smart-backlog-2026-07-14.md 30 KB
VOC 电商与企业微信产品清单（JTBD + SMART）
计划基准日：2026-07-14
依据：会议纪要、claude-code-voc-intelligence、claude-code-qiwe-assistant、工作区现有 Listing/VOC 技能资产。
计划口径：M0 为 2026-07-14～07-16 需求定稿；P0 为 07-17～07-31 可售 MVP；P1 为 08-01～08-15 客户试点；P2 为 08-16～08-31 产品化与复制。日期为建议基线，业务方确认后写入每项《任务书》。
一、数量与边界结论
| 方向 | 可独立闭环模块 | 可直接复用的主要资产 | 当前最大缺口 |
|---|---|---|---|
| VOC + 电商 | 16 个 | VOC 经营闭环、竞品图谱、问题池、单品深度诊断、评论痛点/亮点、1,340 个数据接口（社媒 1,018、电商/创作者 285、海外选品 37） | Listing 从建议到图片、预览、人工确认、写回、备份回滚尚未闭环；公开情报接口不等于商家后台写接口；源码 SaaS 尚缺零配置部署与持续监控 |
| 企业微信 | 16 个 | 104 个企微接口、扫码登录与订阅、消息同步/回调、群/客户/标签/朋友圈、官方会议/文档/日程/待办 CLI | 事件监听服务、统一数据模型、目标推进、知识库、Agentic 应答规则、人工接管状态机、CRM 工作流尚未产品化；Fmode 生产路由仍需启用并实测 |
| 合计 | 32 个 | 其中多数已有底层能力，不应从零开发 | 应以“技能单品 + 企业流程方案 + Skills/API/源码底座”三层组合，而不是再做一个大而全传统 SaaS |
证据状态定义：支持＝现有能力和会议需求都明确；部分支持＝方向明确但缺产品闭环或真实样本；待验证＝只有会议假设，需客户数据/权限/业务人员验证后才可立项。
二、VOC + 电商事项清单（16 个模块）
| ID | 阶段 | 独立模块 | JTBD（当……我想……以便……） | 现有基础 / 缺口 | SMART 事项与交付物 | 验收指标与截止时间 | 证据状态 |
|---|---|---|---|---|---|---|---|
| E01 | 基础复用 | 多源 VOC 数据中心 | 当我要判断市场与店内问题时，我想把一方数据和三方数据放到同一证据链中，以便所有优化都有原声依据 | 已有三通道接口清单、趋势采集、证据卡；缺店内客服、售后、订单等一方数据统一模型 | 定义 source/customer/product/order/review/message/evidence 统一字段、来源标签、去重规则和导入模板；接入 1 份店内评论样本、1 份客服样本、2 个外部平台样本 |
07-22 前完成 4 类样本导入；字段完整率 ≥95%，重复记录率 ≤3%，100% 洞察可回溯到来源 ID/时间；任何首轮结论标“待校准” | 部分支持 |
| E02 | P1 | 一方 VOC 问题池 | 当店铺每天积累评论、客服和售后记录时，我想自动识别高频且影响经营的问题，以便先处理最值钱的问题 | 已有 voc-issue-pool、深挖与记忆；缺电商业务字段和闭环状态 |
将评论、客服、售后记录归为“商品/Listing/物流/服务/退款”问题，支持负责人、状态、证据数、预计损失、验证结果和复盘记忆 | 08-08 前用 ≥500 条真实/脱敏记录验收；人工标注集上问题分类 F1 ≥0.80；Top10 每项含 ≥3 条原声；业务人员确认 Top5 命中率 ≥80% | 部分支持 |
| E03 | P0 | VOC 竞品洞察报告 | 当我不知道真正该对标谁时，我想自动找出同品类、同价格带、同场景竞品并看其优缺点，以便决定错位竞争和 Listing 方向 | 已有竞品发现、竞品图谱、评论痛点/亮点、证据报告标准 | 封装“竞品发现→价格/销量/评分/关键词→好差评→我方差距→5 条动作”的一键报告；保留证据卡和不支持/待验证项 | 07-24 前对 1 个客户品类跑通；覆盖 5 个竞品、每竞品 ≥100 条评论或明确样本限制、≥10 张证据卡、5 条可验证动作；业务专家逐条通过率 ≥80% | 支持 |
| E04 | P0 | 竞品持续监控看板 | 当竞品价格、排名、评价和 Listing 每天变化时，我想持续收到变化和原因提示，以便及时调整而非月末才发现 | 已有接口和一次性竞品分析；缺定时任务、历史库、变化检测和告警 | 建立竞品/SKU 配置页、每日采集、价格/评分/评论量/排名/Listing 版本历史、阈值告警和 HTML 看板；先做 5 品牌 20 SKU | 07-31 前连续运行 7 天；每日任务成功率 ≥95%，变化记录可追溯，失败 10 分钟内告警；看板打开 ≤3 秒；业务人员可在 15 分钟内独立新增竞品 | 部分支持 |
| E05 | P2 | 选品与机会扫描 | 当我要扩品或找新品方向时，我想把需求强度、竞争热度、价格带、差评空白和能力匹配放在一起，以便少靠拍脑袋选品 | 已有 Amazon 类目/榜单/ABA/销量和竞品技能；国内平台口径不一致 | 形成 5 维机会评分与证据卡，输出 Top20 候选、Top5 待验证机会和不建议进入清单；不得把平台样本频次表述成总体渗透率 | 08-31 前用 1 个海外品类 + 1 个国内品类回测；Top5 每项有 ≥3 类证据；业务专家盲评可解释性 ≥80%；所有预测明确假设和验证成本 | 部分支持 |
| E06 | P0 | Listing 健康诊断 | 当我拿到一个商品链接/ASIN/SKU 时，我想在几分钟内知道标题、卖点、关键词、图片、A+和 VOC 证据哪里有问题，以便决定先改什么 | 已有单品 6 维诊断和 Listing 5 维评分；散落在 OpenClaw 技能，未统一入可售包 | 把诊断封装为自然语言入口；输出总分、分项分、扣分证据、竞品基准、修改优先级和预计影响；国内/海外规则分开 | 07-24 前用 20 个 Listing 验收；单条 ≤3 分钟；与 2 名运营共同标注的一致率 ≥80%；每条建议引用数据或规则；无证据的提升幅度不得承诺 | 支持 |
| E07 | P0 | Listing 文案优化 | 当诊断完成后，我想得到可直接审核的标题、Bullet、描述/A+和搜索词版本，以便减少运营与设计反复改稿 | 已有好评亮点、差评痛点和关键词建议；缺品牌口吻、平台字符/禁限词校验、版本化输出 | 生成保守/平衡/进攻 3 版文案，逐处标明“修改前/后/依据”；加入字符限制、禁限词、事实声明、品牌词和人工确认门 | 07-27 前用 20 个 Listing 测试；格式规则通过率 100%，事实性高风险表达 0 条直接发布；运营一次采纳率 ≥70%；每版生成 ≤5 分钟 | 部分支持 |
| E08 | P1 | Listing 主图/详情图生成 | 当文案和卖点确定后，我想按平台规范生成主图、边框、场景图和 A+ 分镜，以便快速形成可测试素材 | 已有图片识别，工作区有即梦技能资产；图片生成尚未与 Listing 证据和平台规范串联 | 输出素材 Brief、3 套候选图、尺寸/留白/文字检查、来源素材清单；只生成候选，不自动覆盖线上图 | 08-10 前对 10 个 SKU 生成 ≥30 套候选；生成成功率 ≥90%；平台尺寸/主图规则通过率 100%；设计师可用率 ≥70%；保留原图与提示词版本 | 部分支持 |
| E09 | P0 | Listing 预览、审批与版本回滚 | 当 AI 改完文案和图片时，我想先在 HTML 看修改差异并批准，以便避免错误直接上线且随时能回退 | 会议明确“HTML 只做展示与人机确认”；当前包无审批/版本状态机 | 建立“草稿→待审核→已批准→已发布→已回滚”状态；HTML 展示字段级差异、证据、素材、风险和批准人；保存前后版本 | 07-31 前完成 20 次端到端演练；未批准时写回调用次数必须为 0；100% 版本含操作者/时间/原因；任一版本 5 分钟内可恢复且无字段丢失 | 支持 |
| E10 | P1 | Listing 店铺写回 | 当人工批准新版本后，我想让 AI 调用商家接口更新指定字段，以便不再手工复制并保留完整审计 | 当前 1,340 个接口主要是情报/公开数据；商家授权、写权限、幂等和回滚需另建 | 先选 1 个真实客户平台做 POC，只开放白名单字段；实现 OAuth/授权、读取当前版本、幂等更新、回执、失败补偿和回滚；默认禁止批量自动发布 | 08-15 前在沙箱/测试店完成 20 次更新；成功率 ≥95%，重复提交不重复写入；100% 有人工批准与审计；失败不留下半更新状态 | 待验证 |
| E11 | P1 | 评论洞察与回复助手 | 当店铺每天收到大量好差评时，我想让 AI 分类、给出基于事实的回复并把复杂问题转人工，以便提升响应速度又不乱承诺 | 已有评论采集和痛点分析；缺回复策略、风险门槛、工单和平台写回 | 建立意图/情绪/风险分类、3 档置信度、品牌话术、建议回复、人工工单和处理状态；第一阶段只建议，第二阶段才对低风险评论自动回复 | 08-10 前用 ≥300 条脱敏评论验证；分类 F1 ≥0.85；运营一次采纳率 ≥70%；退款/法律/安全类 100% 转人工；未经批准自动发布为 0 | 部分支持 |
| E12 | P2 | 售后识别与工单跟进 | 当评论或客服记录出现退款、损坏、缺件等问题时，我想自动建单、分派和催办，以便不漏掉高风险售后 | 已有 VOC 问题识别；缺订单关联、工单状态和 SLA | 定义售后类型、订单/SKU/客户关联、SLA、负责人、升级、补偿审批和复盘；与 E11 共用风险分类 | 08-31 前对 100 个案例回放；建单召回率 ≥90%，错误自动补偿为 0；超时工单 5 分钟内告警；每单可回溯原消息和处理记录 | 待验证 |
| E13 | P2 | 节日/活动运营 Agent | 当临近节日或活动时，我想从商品库筛出适配 SKU 并生成批量优化方案，以便快速抓住节点而不盲目改全店 | 会议给出建军节示例；尚无真实转化证据 | 输入节日、目标和商品库，输出候选 SKU、关联依据、Listing/图片修改建议、预览和排期；调用 E06～E10，强制逐批人工批准 | 08-31 前用 1 个节日、20 个 SKU 演练；候选依据完整率 100%；运营确认相关性 ≥80%；未经批准写回为 0；活动后输出版本与指标对比 | 待验证 |
| E14 | P1 | 多店运营指挥台 | 当一个店长要管理多家店时，我想让 AI 汇总异常、生成每日任务并调用各技能执行，以便从管 1～2 家店逐步提升到更多店 | 会议提出“1 个店长能否管 10 店”，这是业务假设；当前只有分析能力 | 先做 3 店试点：每日经营摘要、异常优先级、评论/Listing/售后任务、执行确认和周报；不先做复杂传统后台 | 08-15 前连续试点 14 天；数据同步成功率 ≥95%；人工日常巡店时长下降 ≥30%；漏报高风险事项 ≤5%；达到指标后才验证 10 店目标 | 待验证 |
| E15 | P0 | 竞品/店铺看板源码部署包 | 当合作方要自己给客户部署时，我想用源码和配置向导快速装好看板，以便我们只提供远程技术支持并降低边际成本 | VOC 包已有 workspace/npm 安装、标准结果信封和 smoke；缺租户、数据源向导、调度、看板模板、备份和运维文档 | 交付 Docker/一键安装二选一、.env.example、数据源向导、样例模式、租户隔离、定时任务、健康检查、备份恢复、升级/回滚、部署手册和 smoke |
07-31 前在 1 台全新环境由非开发人员独立部署；首次可见样例看板 ≤60 分钟，真实配置 ≤120 分钟；smoke 100% 通过；包内无 token/客户数据；故障可按手册恢复 | 部分支持 |
| E16 | M0+P0 | 国内店铺 API 与 Skills 包 | 当客户使用京东/淘宝天猫/抖店等国内店铺时，我想用统一技能读写商品、评论和订单，以便上层 Agent 不绑定某个平台 | 现有电商接口适合公开情报采集；商家后台授权和写操作边界未确认 | 07-16 前先做平台矩阵（授权、商品读写、图片、评论、订单、频控、资费、合规）；只选 1 个有真实账号和业务人员的平台做 list/read/update/rollback 连接器 POC |
矩阵覆盖 ≥3 平台且每项有官方/服务方证据；07-31 前 1 个平台读接口成功率 ≥95%、20 次受控写回成功率 ≥90%、幂等/审计/回滚全通过；其余平台不提前承诺 | 部分支持 |
三、企业微信事项清单（16 个模块）
| ID | 阶段 | 独立模块 | JTBD（当……我想……以便……） | 现有基础 / 缺口 | SMART 事项与交付物 | 验收指标与截止时间 | 证据状态 |
|---|---|---|---|---|---|---|---|
| Q01 | 基础复用 | 会议助手 | 当我要组织项目会议时，我想在企微创建、查询、改参会人和取消会议，以便少做重复协调 | 官方 CLI 已支持会议创建/列表/详情/取消/参会人；缺业务模板与稳定实测 | 封装“项目启动会/周会/复盘会”模板，自动带目标、议程、会前材料和参会人；不确定联系人时先查通讯录并确认 | 07-24 前在测试企业完成 10 次创建、查询、改成员、取消；成功率 100%；时间/时区/参与人错误为 0；每次有回执 | 支持 |
| Q02 | P0 | 会议纪要与待办提炼 | 当会议结束后，我想自动得到结论、待办、负责人、截止时间和待确认项，以便口头讨论真正落地 | 工作区有转写能力，企微包有会议/文档/待办；缺会议内容入口和提炼编排 | 支持文本纪要/转写文件输入；输出“结论、决策、Action、负责人、期限、证据原句、未决问题”，人工确认后创建待办并写入文档 | 07-31 前用 10 份真实/脱敏会议样本；关键待办召回率 ≥90%，负责人/期限无依据时必须标待确认；确认前创建待办数为 0；确认后同步成功率 ≥95% | 部分支持 |
| Q03 | P1 | 文档协作助手 | 当我要产出任务书、方案和周报时，我想让 AI 按模板创建/读取/修改企微文档，以便减少格式工作并保留变更可控 | 普通文档创建/读取/全文覆写已支持；表格/智能表格/智能文档未封装，全文覆写有风险 | 先覆盖普通文档；增加任务书、需求变更、周报模板和修改前 diff/备份/确认；其他文档类型单独立项，不伪装支持 | 08-08 前完成 20 次创建/读取/修改；未确认覆写为 0；内容恢复成功率 100%；模板必填字段完整率 ≥95% | 部分支持 |
| Q04 | P1 | 企业知识库 | 当员工遇到制度、产品或客户问题时，我想从有权限的企微文档中得到带引用答案，以便减少重复询问且不泄露内容 | 已有文档读取；缺增量索引、权限继承、检索和引用 | 接入 100 份文档，构建增量索引、文档级权限、版本更新、引用片段和“无证据不回答”；先做 1 个部门 | 08-15 前用 50 题标准集测试；有答案问题 Top3 命中率 ≥90%，引用可打开率 100%，越权命中 0，文档更新后 10 分钟内生效 | 待验证 |
| Q05 | P0 | 大计划与目标拆解 | 当老板提出年度/季度大计划时，我想把它拆成目标、里程碑、衡量指标和负责人，以便团队知道完成的定义 | 官方待办可作为执行出口；缺目标层级、依赖、指标与人工校准 | 建立“计划→目标→里程碑→任务→指标”模型和任务书模板；AI 给出草案，负责人确认后冻结基线，变更走补充任务书 | 07-27 前用 3 个真实计划拆解；每个目标含负责人、期限、指标、依赖和验收证据；业务负责人一次确认通过率 ≥80%；无责任人项不得进入执行 | 部分支持 |
| Q06 | P0 | 待办同步与任务分派 | 当目标或会议产生任务时，我想把确认后的 Action 同步到企微待办并更新状态，以便不用重复录入 | 官方 CLI 已有 todo 通道；缺项目字段映射、幂等和回写 | 支持创建、更新、完成、取消、负责人/截止期映射；同一会议 Action 用稳定 ID 防重复；状态变化回写项目台账 | 07-31 前同步 50 个测试待办；成功率 ≥95%，重复创建率 0，企微与台账状态一致率 ≥95%，失败 5 分钟内可见并可重试 | 部分支持 |
| Q07 | P1 | 目标推进与风险督办 | 当多个目标同时推进时，我想每天只看到逾期、阻塞、无人负责和依赖冲突，以便把精力放到真正的风险上 | 有待办通道；缺事件汇总、风险规则和周报 | 输出每日风险清单、负责人提醒、阻塞升级和周进度；所有风险必须能追溯到任务/会议/变更记录，不用模型主观编造进度 | 08-15 前对 2 个项目连续运行 14 天；真实逾期/阻塞召回率 ≥90%，误报率 ≤10%；人工催办次数下降 ≥30%；每周生成可审计进度报告 | 待验证 |
| Q08 | P0 | 消息监听与标准事件流 | 当私信、群聊和系统事件不断进入时，我想稳定接收、去重和归档，以便客服、CRM 和目标 Agent 共用同一事实流 | 有 client.setCallback、历史消息同步和 25 个消息接口；生产网关路由仍需启用与实测 |
建立 webhook 服务、签名校验、事件标准化、幂等键、重试/死信、历史补偿、媒体占位和账号/会话映射；先只做测试账号 | 07-23 前通过 1,000 条混合事件回放；丢失率 0、重复入库率 ≤0.1%、P95 入库延迟 ≤10 秒；服务重启后可补偿；生产路由未验证前不得称已上线 | 部分支持 |
| Q09 | P0 | 私信智能客服 | 当客户私信咨询时，我想让 Agent 识别意图、查知识和 CRM、生成可审核回复，以便更快响应又保持事实一致 | 企微消息收发和工作区外部 Demo 已有；当前包缺客服编排、知识和评测集 | 实现意图分类、客户上下文、知识引用、回复草稿、置信度、风险标签和下一步动作；MVP 仅建议回复，低风险自动回复另开开关 | 07-31 前用 ≥200 条脱敏会话评测；意图 F1 ≥0.85，事实引用准确率 ≥90%，人工一次采纳率 ≥70%；投诉/退款/法律/敏感信息 100% 转人工 | 部分支持 |
| Q10 | P0 | Agentic 应答策略中心 | 当业务规则经常变化时，我想用自然语言配置应答政策并让 Agent 自主选择工具，以便不为每条规则改代码 | 会议明确不希望规则写死在代码；当前无策略版本、测试和发布机制 | 建立政策文档、优先级、适用场景、允许工具、禁止动作、示例、版本、审批、灰度和回滚；上线前自动跑规则测试集 | 07-31 前配置 ≥30 条规则、100 个测试案例；规则命中准确率 ≥95%，禁止动作触发率 0；任何策略变更均有审批和版本，10 分钟内可回滚 | 部分支持 |
| Q11 | P0 | 人工接管与 AI 恢复 | 当机器人低置信、客户投诉或人工主动介入时，我想无缝转人工并在人工释放后恢复 AI，以便不抢答、不漏答、不重复答 | 会议称 Demo 已打通私信+Agentic+人工接管；当前给定包未见状态机产品化 | 实现 AI 服务中→待接管→人工处理中→人工释放→AI 恢复 状态机、队列、SLA、接管原因、上下文摘要和并发锁 |
07-31 前完成 100 次场景回放；重复回复 0，人工接管后 AI 发言 0，P95 路由 ≤30 秒；释放后上下文恢复成功率 100%；超时自动升级 | 部分支持 |
| Q12 | P1 | 客户 360 CRM | 当销售或客服打开一个客户时，我想看到身份、标签、来源、会话、群、跟进和待办，以便连续服务而非每次从头问 | 已有联系人、外部联系人、标签、会话等接口；缺统一客户模型和隐私治理 | 建立客户主键、去重合并、标签、生命周期、最近互动、负责人、跟进任务和同意/敏感字段；先做 100 客户样本 | 08-15 前同步 100 个脱敏客户；字段完整率 ≥90%，重复客户率 ≤2%，会话/群/待办关联准确率 ≥95%；敏感字段默认脱敏，所有查看/修改有审计 | 部分支持 |
| Q13 | P1 | 客户群 CRM | 当客户分布在多个群时，我想知道群成员、负责人、主题、活跃度和待跟进事项，以便把群作为可管理的客户资产 | 已有群分页、详情、成员变更、公告等 24 个群接口；缺群生命周期和 CRM 关联 | 建立“群→成员→客户→负责人→标签→事件→任务”模型，支持新增/退出同步、群健康摘要和待跟进清单 | 08-15 前接入 20 个测试群；成员同步准确率 ≥95%，变更 10 分钟内可见；每个跟进项可回溯消息；未授权群数据不得入库 | 部分支持 |
| Q14 | P1 | 社群群聊监听 | 当群聊消息量很大时，我想自动识别咨询、购买意向、投诉、风险和无人回应，以便及时介入 | 消息事件与历史同步可复用；缺标注集、信号模型、告警和误报控制 | 定义 5 类信号、关键词+模型双路检测、相同事件合并、负责人通知和处理闭环；先只告警不自动回复 | 08-15 前用 ≥1,000 条脱敏群消息评测；高意向/投诉召回率 ≥85%，误报率 ≤10%；重大投诉 1 分钟内告警；100% 告警可追溯原消息 | 待验证 |
| Q15 | P2 | 自动建群与群运营 | 当满足业务条件的客户需要进入服务群时，我想自动建群、邀请、发公告并安排任务，以便减少手工建群且不触发风控 | 已有建群、邀请、公告、管理员等接口；小牛看房有需求线索；缺触发规则、审批和频控 | 建立客户资格→人工批准→建群→邀请→公告→标签→跟进任务流程；加入频控、失败补偿和重复群检测 | 08-31 前在测试环境跑 20 次；成功率 ≥95%，重复建群 0，未经批准建群 0；失败可恢复；真实账号试点需客户书面确认平台规则 | 部分支持 |
| Q16 | P0 | 企微 Skills/API/数据底座 | 当上层会议、客服和 CRM 模块不断增加时，我想复用统一认证、事件、SQL、审计和工具协议，以便不让每个项目各写一套 | 已有双通道路由、标准结果信封、登录/订阅和 104 接口；缺持久化数据层、租户、事件总线、权限和可观测性 | 建立官方 CLI/Fmode 双通道路由、PostgreSQL 或等价数据模型、租户/账号隔离、审计日志、事件队列、连接器健康检查、权限策略、统一错误码和 sample/live smoke | 07-31 前覆盖 Q01/Q06/Q08/Q09/Q11 的集成测试；关键流程 smoke 100% 通过；无密钥落日志；跨租户访问 0；断网/重启可恢复；接口失败返回可执行提示而非原始堆栈 | 部分支持 |
四、所有模块统一必须完成的交付门槛
| ID | 截止 | 事项 | SMART 验收标准 |
|---|---|---|---|
| G01 | 07-15 | 业务负责人和技术负责人配对 | 每个 P0 模块必须有 1 名真实业务人员持续上手、1 名技术负责人；无业务负责人不得开工 |
| G02 | 07-16 | 客户需求校准会 | 电商拉赵总/实际运营，企微拉刘俊老师/实际实施人；每个 P0 模块记录 3 个真实任务、当前耗时、失败案例、权限与数据来源，并由业务方签字/文字确认 |
| G03 | 07-16 | 竞品与价格调研 | 每个可售 P0 模块至少记录 3 个竞品/替代方案、功能、计费单位、价格范围、部署方式和差评；无公开价格写“询价”，不得编造 |
| G04 | 开发前 | 《任务书》 | 必含 JTBD、范围/非范围、用户流程、接口与数据、依赖、风险、里程碑、工时、验收样本、Demo 脚本和变更机制；评审通过后才计入开发 |
| G05 | 每个里程碑 | 需求变更单 | 新增需求必须写影响范围、增加工时、延期天数和验收变化；未确认的变更不得静默塞入原任务 |
| G06 | P0 完成时 | 15～35 秒销售 Demo | 每个可售模块交 1 条视频：3 秒痛点、15～25 秒核心闭环、5 秒结果/行动；必须使用脱敏或样例数据，可由河南/厦门销售直接转发 |
| G07 | P0 完成时 | HTML 结果页/审批页 | 页面只承担阅读、对比、确认和审计；主要工作由 Skills/API 完成；任何写操作必须显示目标、差异、风险和回滚入口 |
| G08 | P0 完成时 | 安全与可恢复性 | sample 模式无需真实凭据；live 模式缺凭据时友好引导；密钥不写代码/文档/日志；批量写、发消息、建群、发布 Listing 均默认人工确认；有幂等、审计、重试和回滚 |
| G09 | P0 完成后 7 天 | 真实试点 | 每个模块至少由 1 名业务人员完成 5 次真实任务并记录成功率、耗时、人工修改率和异常；达不到表内指标则保持“试点”，不能标“成熟产品” |
| G10 | P1 结束 | 商业化卡片 | 每个可售模块交付名称、一句话价值、目标客户、输入/输出、Demo、部署方式、服务边界、成本、竞品价格和报价建议；Listing 低价单品、SaaS 实施费、企微席位费均先作为假设验证 |
五、建议先卖的组合，而不是 32 项同时开发
| 产品包 | 组合模块 | 首个可卖结果 | 建议验证对象 | 商业假设（均需 G03/G09 验证） |
|---|---|---|---|---|
| A. Listing 优化引流单品 | E03 + E06 + E07 + E09 | 输入链接后得到有证据的评分、3 版文案和可审批 HTML，不做未经批准的线上修改 | 已有 Listing Demo 的学生、河南电商企业 | 单次低价/会员制作为获客；会议提到 9.9 与 299/399，但计费周期和可接受价必须重新确认 |
| B. 竞品看板源码方案 | E01 + E03 + E04 + E15 | 合作方可在 1～2 小时内部署并添加竞品，连续监控 7 天 | 赵总团队、河南电商协会样板企业 | 会议提出实施费约 2～5 万 + 后续 API/技术服务费；以首个部署成本和竞品报价校准 |
| C. 店铺运营 Agent 试点 | E11 + E14 + E16，后续接 E10/E12 | 先对 3 店做评论、异常和任务汇总，验证是否减少店长巡店时间 | 中南经验企业、真实国内平台店铺 | 先证明 3 店效率提升，再验证“1 人管 10 店”；未取得商家写权限前只读不写 |
| D. 企微会议到目标闭环 | Q01 + Q02 + Q05 + Q06 | 会议内容变为经人工确认的目标、任务书和企微待办 | 建恒/江中等已有办公需求客户 | 按组织/项目实施费或月服务费；价值用漏项率、催办次数、按期完成率证明 |
| E. 企微 Agentic 客服 | Q08 + Q09 + Q10 + Q11 + Q16 | 私信进入→AI 建议→低置信/风险转人工→人工释放→AI 恢复 | 小牛看房、已付费张总客户 | 现有企微席位为 ¥200/账号/月；客服/知识/实施应另行核算，不把席位费当全部产品价 |
| F. 企微 CRM 与社群运营 | Q12 + Q13 + Q14 + Q15 | 客户/群统一台账、关键消息告警、经批准自动建群 | 小牛看房及有社群业务的企业 | 先按 20 群试点收实施费，达到信号准确率和运营节省后再扩账号/群量计费 |
六、立项前必须回答的 8 个问题
| ID | 必答问题 | 不回答的风险 |
|---|---|---|
| D01 | 电商首个平台到底是 Amazon、淘宝天猫、京东还是抖店？真实账号和商家写权限谁提供？ | E10/E16 无法形成真实闭环，只能做 Demo |
| D02 | Listing 的成功指标用点击率、转化率、自然排名、修改采纳率还是节省工时？基线数据能否取到？ | 无法证明优化有效，容易只交付“看起来不错”的文案 |
| D03 | 竞品看板首批监控哪些 5 品牌/20 SKU，采集频率、API 成本和告警阈值是多少？ | 成本失控或看板只有数据没有决策价值 |
| D04 | 源码交付是单客户私有部署、合作方多租户部署还是只交 Docker 包？升级和二开边界是什么？ | E15 报价、架构和售后责任会完全不同 |
| D05 | 企微消息监听的合规授权、数据保留期限、敏感字段和可见范围由谁批准？ | 客服/CRM/监听存在隐私与越权风险 |
| D06 | 客服哪些意图允许自动回复，哪些必须人工？谁维护知识和应答政策？ | Q09/Q10 可能乱承诺或长期无人维护 |
| D07 | 人工接管由谁接、多久必须响应、夜间如何处理、何时释放给 AI？ | Q11 技术打通但业务仍然断线 |
| D08 | 每个 P0 模块的业务试用人、开发人、验收人和预计工时是多少？ | 32 项同时开工会稀释人员，无法形成可卖闭环 |
七、执行原则
- 先完成 A/B/D/E 四个组合的可售闭环，再扩 P1/P2；不要 32 项同时开工。
- Listing 是高频低价技能单品，竞品/多店/CRM 是企业流程方案，Skills/API/源码部署是复制底座；三类产品分别定价、分别验收。
- 所有 AI 写操作都采用“建议或草稿→HTML 预览→人工确认→执行→审计→回滚”，不得把“Agentic”理解为无边界自动驾驶。
- 业务方必须每日/每两日反馈真实使用；技术团队负责封装和稳定性，不能替代业务人员决定规则。
- 当前会议材料属于内部需求证据，不等于市场验证；报价、转化提升、1 人管 10 店等均是待验证假设。
八、证据与资产索引
| 证据/资产 | 用于支持本清单的内容 |
|---|---|
C:/Users/刚sir/.codex/attachments/e53a5e01-a006-4562-8dc9-b5cba9009d8a/pasted-text.txt |
两大方向、Listing/看板/API、企微办公/目标/客服/CRM、任务书、Demo、价格和合作模式 |
claude-code/claude-code-voc-intelligence/README.md、docs/capability-map.md、mcp/catalog/voc-social-endpoints.json |
VOC 已有工作流、MCP 工具、数据通道与 1,340 个接口基线 |
openclaw-skills/synthesis/product-deep-analysis/、review-analysis/、competitor-analysis/ |
Listing 诊断、评论痛点/亮点、竞品发现等可复用资产 |
claude-code/claude-code-qiwe-assistant/README.md、mcp/catalog/qiwei-endpoints.json |
企微双通道、104 个接口、登录/订阅、消息/群/客户能力与当前限制 |
claude-code/claude-code-qiwe-assistant/skills/qiwei-official-meeting/、qiwei-official-doc/ |
官方会议与普通文档已有能力边界 |