Răsfoiți Sursa

更新qiwei技能包

gangvy 2 luni în urmă
părinte
comite
0f9f0ab6d4

+ 3 - 0
.gitignore

@@ -44,3 +44,6 @@ milin-clashverge-wireguard-udp443.yaml
 
 # Backup files
 *.bak-*
+
+# Generated runtime outputs
+output/

+ 5 - 5
claude-code/claude-code-qiwe-assistant/mcp/src/core/credentials.js

@@ -128,15 +128,11 @@ function readQiweiAuthToken(input = {}) {
     fileEnv.FMODE_API_KEY,
     fileEnv.FMODE_API_TOKEN,
     fileEnv.NEWAPI_TOKEN,
-    fileEnv.VOC_TOKEN,
-    fileEnv.VOC_SOCIAL_TOKEN,
     process.env.QIWEI_AUTH_TOKEN,
     process.env.QIWE_AUTH_TOKEN,
     process.env.FMODE_API_KEY,
     process.env.FMODE_API_TOKEN,
     process.env.NEWAPI_TOKEN,
-    process.env.VOC_TOKEN,
-    process.env.VOC_SOCIAL_TOKEN,
     fmodeConfig.newapiToken,
     fmodeConfig.newApiToken,
     fmodeConfig.fmodeApiKey,
@@ -144,7 +140,11 @@ function readQiweiAuthToken(input = {}) {
     claudeEnv.FMODE_API_KEY,
     claudeEnv.NEWAPI_TOKEN,
     pickFmodeAnthropicToken(process.env),
-    pickFmodeAnthropicToken(claudeEnv)
+    pickFmodeAnthropicToken(claudeEnv),
+    fileEnv.VOC_TOKEN,
+    fileEnv.VOC_SOCIAL_TOKEN,
+    process.env.VOC_TOKEN,
+    process.env.VOC_SOCIAL_TOKEN
   ]);
   return normalizeToken(token);
 }

+ 12 - 4
claude-code/claude-code-qiwe-assistant/mcp/src/core/login-flow-server.js

@@ -161,7 +161,7 @@ function poll() {
       checkErrors++;
       const st = await api('/flow/state');
       if (st.data.online) { clearInterval(pollTimer); renderSuccess(st.data.detail || {}); return; }
-      if (st.data.subscribed === false) { clearInterval(pollTimer); renderSubscribe(st.data.subscribeDetail || '订阅已到期'); return; }
+      if (st.data.subscribed === false && !st.data.stateError) { clearInterval(pollTimer); renderSubscribe(st.data.subscribeDetail || '订阅已到期'); return; }
       // 二维码过期或上游瞬时异常:未提交验证码时自动重新生成二维码
       if (!codeSubmitted && checkErrors >= 2) { clearInterval(pollTimer); startLogin(); return; }
       if (codeSubmitted && checkErrors >= 10) {
@@ -224,12 +224,18 @@ function renderSuccess(detail) {
     '<div class="hint">账号:' + (detail.nickname || detail.userId || '未知') + (detail.corpName ? '(' + detail.corpName + ')' : '') + '<br>现在可以回到对话中使用企微接口能力(qiwei_api_call、消息、会议等)。</div></div>';
 }
 
-(async () => {
+async function boot() {
   const r = await api('/flow/state');
   if (r.data.online) { renderSuccess(r.data.detail || {}); return; }
   if (r.data.subscribed) { startLogin(); return; }
+  if (r.data.stateError) {
+    panel.innerHTML = '<div class="center"></div>';
+    showMsg('err', '网络异常,暂时无法获取订阅状态(不会重复扣费)。<br><button class="main" onclick="boot()">重试</button>');
+    return;
+  }
   renderSubscribe(r.data.subscribeDetail || '');
-})();
+}
+boot();
 </script>
 </body>
 </html>`;
@@ -270,11 +276,13 @@ function createFlowHandler(ctx) {
         let subscribeDetail = '';
         let online = false;
         let detail = null;
+        let stateError = false;
         try {
           const sub = await callFmodeWecomGateway({ gatewayPath: '/subscribe/status', httpMethod: 'GET', token: ctx.token, apiBase: ctx.apiBase });
           subscribed = Boolean(sub.data && sub.data.subscribed);
           if (!subscribed) subscribeDetail = '尚未开通包月订阅';
         } catch (error) {
+          stateError = true;
           subscribeDetail = String((error && error.message) || '订阅状态查询失败');
         }
         if (subscribed) {
@@ -286,7 +294,7 @@ function createFlowHandler(ctx) {
             online = false;
           }
         }
-        json(res, 200, { subscribed, subscribeDetail, online, detail });
+        json(res, 200, { subscribed, subscribeDetail, online, detail, stateError });
         return;
       }
       if (url.pathname === '/flow/subscribe' && req.method === 'POST') {

+ 15 - 0
claude-code/claude-code-qiwe-assistant/scripts/start-login-flow-4200.js

@@ -0,0 +1,15 @@
+const { readQiweiAuthToken, ensureQiweiUid, readQiweiApiBase } = require('../mcp/src/core/credentials');
+const { startLoginFlowServer } = require('../mcp/src/core/login-flow-server');
+
+const token = readQiweiAuthToken({});
+const uid = ensureQiweiUid({});
+const apiBase = readQiweiApiBase({});
+
+startLoginFlowServer({ token, apiBase, uid, port: Number(process.env.QIWEI_FLOW_PORT) || 4200 })
+  .then(({ url, alreadyRunning }) => {
+    console.log(JSON.stringify({ url, alreadyRunning, uid, apiBase, tokenConfigured: Boolean(token) }));
+  })
+  .catch((error) => {
+    console.error('failed to start login flow server:', error && error.message);
+    process.exit(1);
+  });

+ 169 - 0
docs/specs/voc-ecommerce-product-direction-competitor-research-2026-07-14.md

@@ -0,0 +1,169 @@
+# VOC 到电商:产品方向与竞品能力调研
+
+> 调研日期:2026-07-14  
+> 本文只回答三个问题:市场上有哪些产品能力、VOC 到电商还能形成哪些独立方向、我们每个方向应该做到哪一层。  
+> 本文不是开发任务书,不拆接口、页面、工时和验收用例。方向评审通过后,才进入需求与任务拆解。
+
+## 一、先给结论
+
+基于现有能力、会议原始方向和国内外竞品调研,VOC 到电商目前可以列出 **15 个可独立讨论的产品方向**:
+
+- 原会议已明确 4 个方向:竞品监控与分析、Listing 优化、已有 SaaS 标品、国内店铺 API/Skills。
+- 市场调研补充 11 个方向:评论 VOC、选品机会、关键词流量、价格促销、数字货架、内容创意、达人生态、活动运营、店铺客服售后、多店运营、标准报告交付。
+- 其中不建议 15 个方向同时开发。建议先评审 6 个核心方向,其他作为扩展候选。
+
+建议的第一层产品组合:
+
+| 产品层 | 方向 | 说明 |
+|---|---|---|
+| 低门槛技能单品 | Listing 优化、评论 VOC、标准竞品报告 | 输入简单、结果快、可用于获客和演示 |
+| 持续订阅产品 | 竞品监控、关键词流量、价格促销、数字货架 | 需要持续采集和告警,适合月费/年费 |
+| 已有标准产品 | 现有 SaaS 源码标品 | 不重新定义为新项目,重点是配置、部署、交付和销售 |
+| 企业流程方案 | 多店运营、客服售后、活动运营 | 要接一方数据和真实业务流程,适合实施费 + 服务费 |
+| 复制底座 | 国内店铺 API/Skills | 对接平台授权,把查询和写操作封装成统一技能 |
+
+## 二、能力深度口径
+
+| 等级 | 做到的程度 | 用户得到什么 |
+|---|---|---|
+| L1 数据与看板 | 展示发生了什么 | 指标、趋势、排行、对比 |
+| L2 诊断与解释 | 解释为什么变化 | 异常原因、竞品动作、证据链 |
+| L3 方案与预览 | 给出下一步怎么做 | 修改建议、候选方案、HTML 预览、人工确认 |
+| L4 受控执行 | 经人工批准后调用平台执行 | 更新 Listing、回复评论、创建任务、保留审计和回滚 |
+| L5 自动驾驶 | 系统在规则内自主决策并执行 | 仅适合低风险、规则稳定场景,不作为现阶段默认目标 |
+
+我们的差异化不应只是“再做一个看板”,而应是:
+
+```text
+跨平台 VOC 与经营数据 → 发现变化 → 解释原因 → 生成可审核方案 → 人工确认 → Skills/API 执行
+```
+
+## 三、15 个产品方向
+
+### A. 原会议已经明确的 4 个方向
+
+| ID | 产品方向 | 这个产品卖什么 | 市场上已做到什么 | 我们建议做到的程度 | 当前判断 |
+|---|---|---|---|---|---|
+| V01 | 竞品监控与分析系统 | 自动发现竞品,持续监控价格、销量、排名、评价、关键词、Listing 和市场份额变化 | Helium 10、SellerSprite、SmartScout、DataHawk 已覆盖竞品发现、监控、关键词和市场表现;企业级产品还能解释 KPI 变化 | 目标 L3:不仅显示变化,还要说明证据、可能原因和建议动作;首版不直接修改店铺 | 核心方向,优先评审 |
+| V02 | Listing 优化单点产品 | 输入链接/ASIN/SKU,完成诊断、关键词与 VOC 分析、文案和图片方案 | Jungle Scout、Helium 10、SellerSprite、SmartScout 均有 Listing 评分、关键词和 AI 文案;部分支持实时优化分数 | 首版做到 L3:评分、竞品/VOC 依据、三版文案、图片 Brief 和预览;接入店铺 API 后再到 L4 | 核心方向,最适合做低价单品 |
+| V03 | 已有 SaaS 源码标品 | 将现有竞品/店铺看板作为标准软件或源码交付给客户及合作方 | DataHawk、CommerceIQ 等证明企业愿意为统一看板、告警、多账号和报告付费 | 不作为新研发方向重新发明;先盘清现有 SaaS 已有功能、缺口、安装、配置、升级和售后边界 | 已有产品,优先做产品盘点与销售包装 |
+| V04 | 国内店铺 API 接入与 Skills | 对接淘宝天猫、京东、抖店等自有店铺授权,将商品、Listing、评论、订单等能力封装为统一技能 | 抖音电商罗盘、生意参谋、京东商智提供平台内数据;ERP 产品深入刊登、订单、库存和客服 | 目标 L4 底座:先完成一个平台的授权、统一读写动作、人工确认、审计和回滚;不先做全平台 ERP | 核心底座,必须先确认真实账号和开放权限 |
+
+### B. 调研后建议补充的 11 个方向
+
+| ID | 产品方向 | 这个产品卖什么 | 竞品证明的市场需求 | 我们建议做到的程度 | 当前判断 |
+|---|---|---|---|---|---|
+| V05 | 评论 VOC 与产品改进洞察 | 从自家和竞品评论中提取痛点、亮点、场景、人群、产品缺陷和卖点机会 | SellerSprite 有 Review Analysis;魔镜洞察有“电商聆听”,把评论用于痛点、新品卖点、人群和场景研究 | 目标 L3:原声证据、问题优先级、竞品差异、Listing/产品/售后三类建议 | 与现有 VOC 能力最匹配,优先评审 |
+| V06 | 选品与新品机会系统 | 找到增长类目、蓝海属性、价格带和未满足需求,输出候选商品方向 | Helium 10、Jungle Scout、SellerSprite、魔镜增长雷达、抖音罗盘均覆盖产品研究或趋势机会 | 目标 L2:发现并解释机会,明确证据和风险;不能把平台估算值说成确定销量 | 重要扩展,数据成本较高 |
+| V07 | 关键词与流量情报 | 反查竞品流量词、关键词排名、搜索趋势、转化词和共同词 | Helium 10 Cerebro/Magnet/Keyword Tracker、SellerSprite 反查 ASIN/流量对比、SmartScout Keyword Detective 均为核心功能 | 目标 L2~L3:关键词差距、流量来源、排名变化、应放入 Listing 的词和内容方向 | 可独立售卖,也可作为 V01/V02 的核心模块 |
+| V08 | 价格与促销情报 | 监控竞品价格、优惠券、促销节奏和异常价格,识别价格带机会 | Keepa 专注价格历史和追踪;魔镜价控支持批量高频监测、价格日报和异常告警;Pacvue 分析价格和竞品促销 | 目标 L2:历史曲线、促销事件、异常告警和价格带解释;不直接自动改价 | 容易形成订阅产品,可并入 V01 |
+| V09 | 数字货架与品牌可见度 | 看品牌在搜索、类目、库存、内容、评分、Buy Box 等位置是否健康 | CommerceIQ 覆盖 Share of Search、库存、内容分、评分评论和每日 scorecard;DataHawk 覆盖 SEO、库存和绩效 | 目标 L2~L3:品牌/竞品对比、问题归因、修复建议;适合多店和品牌客户 | 企业版方向,晚于 V01/V02 |
+| V10 | 竞品内容、素材与直播情报 | 监控竞品短视频、直播、主图、广告素材、话题和内容表现 | 飞瓜覆盖抖音/快手/B站趋势、自品/竞品、广告和直播运营;Pacvue 覆盖跨零售媒体与竞争情报 | 目标 L2~L3:发现高表现素材结构、用户反应和可借鉴方向,不能只做素材搬运 | 国内内容电商价值高,可与 VOC 联动 |
+| V11 | 达人/联盟生态洞察 | 发现竞品合作达人、受众匹配、内容绩效和达人层级结构 | 飞瓜覆盖达人分析和分销管理;现有 VOC 电商通道已有星图、蒲公英等创作者接口 | 目标 L2:竞品达人布局、受众匹配和内容机会;不直接代替客户做投放采买决策 | 有数据基础,适合作为内容情报模块 |
+| V12 | 节日与活动运营 Agent | 根据节日、市场变化和商品库挑选 SKU,生成 Listing、图片和活动方案 | 抖音罗盘已把趋势、人群、商品和内容用于经营策略;Pacvue/CommerceIQ 正在向“发现—解释—行动”发展 | 目标 L3,后续可到 L4:先生成候选和预览,确认后再调用店铺技能 | 差异化方向,需要真实商品库验证 |
+| V13 | 店铺评论、客服与售后 Agent | 分类评论和咨询、生成回复、识别退款/投诉并转工单或人工 | 店小秘覆盖客服管理;抖音罗盘把服务体验纳入经营诊断;市场产品普遍从分析向工作流延伸 | 目标 L3,低风险场景再到 L4:建议回复、风险分级、人工接管和工单 | 有明确业务价值,但依赖 V04 和客户规则 |
+| V14 | 多店运营 Copilot | 汇总多店异常、生成每日任务、调用已有技能处理 Listing、评论和售后 | DataHawk 支持多账号看板和报告;抖音罗盘策略版覆盖全局多店和行业竞争;ERP 覆盖跨店流程 | 目标 L2~L3:每日异常与任务指挥,不先复制订单、仓库、财务等 ERP | 企业流程方向,需先验证真实节省工时 |
+| V15 | 标准竞品/VOC 报告工厂 | 以一次性报告或持续月报交付品类、竞品、VOC、机会和行动方案 | 魔镜同时提供 SaaS 报表和行业报告;DataHawk 强调自动报告;大量客户先买报告再买系统 | 目标 L3:证据可追溯、结论可校准、行动可直接进入 Listing/内容/产品决策 | 最快变现方向,可作为其他产品的销售入口 |
+
+## 四、市场竞品能力对标
+
+| 竞品 | 定位 | 官方页面显示的核心能力 | 能力深度 | 对我们的启示 |
+|---|---|---|---|---|
+| [Helium 10](https://www.helium10.com/tools/) | Amazon 卖家全套工具 | 产品研究、竞品产品分析、关键词反查与跟踪、Listing Analyzer/Builder、评论、利润、库存、Listing 变化告警、Market Tracker、广告 | 从研究到经营的完整套件;Market Tracker 360 还有市场份额、ASIN 基准和两年历史数据 | V01/V02/V07 的功能基准;不要只交付静态报告 |
+| [Helium 10 Market Tracker 360](https://www.helium10.com/tools/product-research/market-tracker-360/) | 高阶竞品与市场监控 | 市场份额、ASIN 表现基准、关键词/ASIN 动态更新、历史市场数据 | 独立高价增值模块;官方公开价显示 add-on 从 650 美元/月起 | 深度竞品监控可单独定价,不必免费塞入大 SaaS |
+| [Jungle Scout Listing Builder](https://www.junglescout.com/features/listing-builder/) | Amazon 选品与增长工具中的 Listing 模块 | AI 生成标题、描述和卖点;关键词库;实时 Listing Optimization Score,评分覆盖标题、描述、关键词、图片等 | 已做到“生成 + 实时评分”,企业计划还提供数字货架、市场份额和竞争洞察 | V02 至少要达到“有依据的评分 + 生成 + 实时反馈” |
+| [SellerSprite 卖家精灵](https://www.sellersprite.com/) | 面向中国跨境卖家的 Amazon 数据工具 | 选品、市场分析、关键词挖掘、反查 ASIN、流量对比、关键词转化、Listing 优化、评论分析、产品/关键词/新品监控 | 覆盖研究、优化和监控,中文用户习惯成熟 | 是 V01/V02/V05/V07 最直接的中文竞品 |
+| [SmartScout](https://www.smartscout.com/) | Amazon 品牌、卖家和市场关系情报 | 品牌/卖家/产品/子类目数据库、Ad Spy、Keyword Detective、Traffic Graph、AI Listing Architect、历史卖家收入份额 | 强在“关系图谱 + 市场结构 + 广告/流量发现”;官网公开月费约 29/97/187 美元三档 | V01 可加入品牌—卖家—商品—关键词关系,而非只列竞品表格 |
+| [Keepa](https://keepa.com/) | Amazon 价格与历史数据工具 | 价格历史、跟踪、产品查找和 API | 功能窄但时间序列深,用户为可靠历史和告警付费 | V08 应做深做稳,可作为 V01 的独立收费模块 |
+| [DataHawk](https://datahawk.co/overview/) | Amazon/Walmart/Shopify 企业分析平台 | 销售、广告、SEO、库存、竞品、利润、自动报告、多账号/白标、角色权限、AI 告警与原因诊断 | 从统一数据到“发现变化并告诉你怎么修复” | V03/V09/V14 的企业产品基准;我们的优势应是 Skills 执行与源码交付 |
+| [CommerceIQ Digital Shelf](https://www.commerceiq.ai/digital-shelf-analytics) | 大品牌数字货架与 Agentic 电商 | 1,500+ 零售商、Share of Search、库存率、内容分、评分评论、每日 scorecard、PIM 同步与内容修复、Ask/Explain/Act | 已从看板进化到问原因、给动作、推送修复 | 证明 L3/L4 是市场方向;但我们不应从大企业 PIM 和全零售商覆盖起步 |
+| [Pacvue](https://pacvue.com/) | 零售媒体、数字货架与商业运营平台 | 广告、数字货架、收入恢复、市场/竞品情报、SOV、价格促销、库存和 Agentic 能力 | 广告与经营一体化,覆盖 100+ 零售商 | 广告优化和供应链不是当前切入口;可借鉴其“情报与行动联动” |
+| [魔镜洞察](https://www.mktindex.com/home/) | 国内消费市场与消费者洞察 | 国内外电商销售、评论、社媒;自定义类目/属性;增长雷达;电商聆听;社交聆听;价控;SaaS 报表和行业报告 | 把市场、VOC、竞品、新品机会和报告做成产品矩阵 | 与我们的 VOC 基因最接近;V05/V06/V08/V15 均有市场验证 |
+| [抖音电商罗盘](https://compass.jinritemai.com/) | 抖音电商官方经营数据产品 | 店铺经营、内容运营、货架运营、服务体验、市场洞察、多店数据、行业竞争、商品/内容/人群策略和达人选品 | 官方一方数据完整,可诊断和给策略 | V04 必须接官方/授权数据;V10/V12/V14 可从其经营场景中选切口 |
+| [飞瓜数据](https://www.feigua.cn/) | 短视频、直播与内容电商数据 | 抖音/快手/B站趋势、自品/竞品、达人、舆情、广告素材、直播回看与运营 | 内容、达人、广告、直播形成产品矩阵 | V10/V11 应独立于传统 Amazon Listing 工具看待 |
+| [店小秘](https://www.dianxiaomi.com/) | 70+ 平台跨境电商 ERP | 产品采集/搬家、刊登、客服、订单、采购、物流、仓储、财务、图片和多平台管理 | 深入交易与履约全流程 | 它是边界参照:我们应连接 ERP,而不是短期复制订单、仓库和财务系统 |
+
+## 五、按市场能力看,我们要做到什么程度
+
+| 市场能力 | 市面上的成熟基准 | 我们的最低可售标准 | 推荐目标 | 不建议现在做的部分 |
+|---|---|---|---|---|
+| 竞品发现 | 可按品类、价格、销量、关键词找到竞品 | 能解释为什么这些是竞品 | 自动发现 + 用户确认 + 竞品关系图 | 覆盖所有平台和所有类目 |
+| 竞品监控 | 日/周监控价格、销量、排名、评论和 Listing | 有历史、有变化、有告警 | 变化 → 原因 → 证据 → 建议动作,做到 L3 | 自动跟随竞品改价或改 Listing |
+| Listing 优化 | AI 文案、关键词库、优化分数、实时反馈 | 评分和文案不能脱离竞品/VOC 依据 | 文案 + 图片 Brief + 差异预览,做到 L3;后续 L4 | 首版直接无人审核发布 |
+| 评论 VOC | 评论聚类、痛点、亮点和 Review Analysis | 展示原声、频次和样本限制 | 连接产品、Listing、售后三类决策 | 只输出抽象情绪词云 |
+| 关键词流量 | 反查 ASIN、关键词排名、共同词和转化词 | 能识别词差距和流量来源 | 连接 Listing 和内容选题,做到 L3 | 直接承诺自然排名提升 |
+| 价格促销 | 历史曲线、促销事件、异常告警 | 数据连续、告警可靠 | 给出价格带和促销节奏解释,做到 L2 | 自动价格战 |
+| 数字货架 | 搜索份额、库存、内容、评分、Buy Box | 先覆盖少数平台和核心指标 | 面向品牌/多店客户做到 L2~L3 | 一开始对标 1,500+ 零售商 |
+| 内容与达人 | 竞品内容、直播、达人和投放情报 | 能解释高表现内容与目标人群 | 与 VOC 原声、商品卖点和内容方案连接 | 自动替客户决定达人采买 |
+| 国内店铺执行 | 官方授权、商品/订单/评论等读写 | 先跑通一个平台、统一技能、审计回滚 | 按客户需求逐平台扩展到 L4 | 一次性承诺淘宝、京东、抖店全部可写 |
+| 多店运营 | 多账号看板、异常和经营任务 | 先证明 3 店能节省管理时间 | Agent 指挥现有技能,做到 L3 | 复制 ERP 的库存、采购、财务全流程 |
+
+## 六、建议的方向优先级
+
+### 第一组:现在最值得进入方向评审
+
+1. V01 竞品监控与分析系统。
+2. V02 Listing 优化单点产品。
+3. V03 已有 SaaS 标品盘点与销售包装。
+4. V04 国内店铺 API/Skills,先选一个平台验证。
+5. V05 评论 VOC 与产品改进洞察。
+6. V15 标准竞品/VOC 报告工厂。
+
+这六个方向与现有资产最接近,也能形成“报告引流 → 技能单品 → 持续订阅 → 企业实施 → 源码交付”的产品阶梯。
+
+### 第二组:作为第一组的扩展方向
+
+- V06 选品与新品机会。
+- V07 关键词与流量情报。
+- V08 价格与促销情报。
+- V09 数字货架与品牌可见度。
+- V10 竞品内容、素材与直播情报。
+- V11 达人/联盟生态洞察。
+- V12 节日与活动运营 Agent。
+- V13 店铺评论、客服与售后 Agent。
+- V14 多店运营 Copilot。
+
+### 当前不建议作为独立主产品
+
+| 方向 | 原因 | 建议处理 |
+|---|---|---|
+| 广告自动投放与出价优化 | Helium 10、Pacvue 等已有成熟数据、归因和平台连接;风险和资金责任高 | 先做广告/素材情报,不做自动出价 |
+| 订单、采购、库存、物流、财务 ERP | 店小秘等已深耕多年,集成复杂且偏离 VOC 优势 | 通过 API 连接现有 ERP,只做智能分析和任务编排 |
+| 无审核的全自动店铺运营 | 店铺写操作涉及价格、承诺、平台处罚和客户损失 | 默认停在 L3;低风险场景经客户规则验证后再开放 L4 |
+
+## 七、下一步应该先确认什么
+
+在进入任何开发待办前,建议只开一次“方向评审会”,逐项确认:
+
+1. 15 个方向哪些保留、合并、删除。
+2. 现有 SaaS 实际已经覆盖哪些方向,避免重复定义。
+3. 第一批客户愿意为哪一个结果付费:报告、Listing、监控、店铺接口还是多店运营。
+4. 首个电商平台和真实测试账号由谁提供。
+5. 每个保留方向对应的业务专家是谁,能否持续提供真实反馈。
+
+方向评审完成后,再为被选中的 3~6 个方向写任务书;此前的细化待办只能作为候选池,不能直接视为已立项需求。
+
+## 八、官方资料来源
+
+以下页面均在 2026-07-14 联网核查:
+
+- [Helium 10 Tools](https://www.helium10.com/tools/)
+- [Helium 10 Listing Builder](https://www.helium10.com/tools/listing-optimization/listing-builder/)
+- [Helium 10 Market Tracker 360](https://www.helium10.com/tools/product-research/market-tracker-360/)
+- [Helium 10 Pricing](https://www.helium10.com/pricing/)
+- [Jungle Scout Listing Builder](https://www.junglescout.com/features/listing-builder/)
+- [Jungle Scout Pricing / Capability Comparison](https://www.junglescout.com/pricing/)
+- [SellerSprite 卖家精灵](https://www.sellersprite.com/)
+- [SmartScout](https://www.smartscout.com/)
+- [Keepa](https://keepa.com/)
+- [DataHawk](https://datahawk.co/overview/)
+- [CommerceIQ Digital Shelf Analytics](https://www.commerceiq.ai/digital-shelf-analytics)
+- [Pacvue](https://pacvue.com/)
+- [魔镜洞察](https://www.mktindex.com/home/)
+- [抖音电商罗盘](https://compass.jinritemai.com/)
+- [飞瓜数据](https://www.feigua.cn/)
+- [店小秘](https://www.dianxiaomi.com/)
+- [生意参谋登录入口](https://sycm.taobao.com/)
+- [京东商智登录入口](https://sz.jd.com/)
+
+说明:生意参谋与京东商智的公开入口主要为登录页,具体功能仍需用真实商家账号在产品内二次核查,本文不根据非官方文章补写其详细能力。

+ 195 - 0
docs/specs/voc-ecommerce-qiwei-execution-checklist-2026-07-14.md

@@ -0,0 +1,195 @@
+# VOC 电商与企业微信执行待办清单
+
+> 当前状态:**候选任务池,暂不作为正式立项清单。** 请先完成《VOC 到电商:产品方向与竞品能力调研》的方向评审,再从被选中的方向中提取任务。  
+> 用法:一行就是一条可认领待办。认领后填写负责人、工时和实际完成日期。  
+> 阶段:M0=需求确认;P0=可售 MVP;P1=客户试点;P2=复制与扩展。  
+> 状态:`☐` 未开始,`◐` 进行中,`☑` 已验收,`⊘` 暂缓。
+
+## 需求分类总览
+
+| 大方向 | 原始需求分类 | 对应待办 |
+|---|---|---|
+| 1. VOC 技能 + 电商竞品分析、洞察 | VOC 数据、竞品发现、洞察报告、选品机会 | E01~E07、E11 |
+| 1. VOC 技能 + 电商竞品分析、洞察 | Listing 优化 | E12~E21 |
+| 1. VOC 技能 + 电商竞品分析、洞察 | SaaS 提供源码,用户自动配置完成竞品看板 | E08~E10、E35~E39 |
+| 1. VOC 技能 + 电商竞品分析、洞察 | 国内店铺的 API 接入和 Skills | E22~E25、E40~E41 |
+| 1. VOC 技能 + 电商竞品分析、洞察 | VOC 到店铺的具体应用:评论、售后、活动、多店运营 | E26~E34 |
+| 2. 企业微信 | 日常办公:会议、文档、知识库 | Q01~Q11 |
+| 2. 企业微信 | 目标管理:大计划、目标拆解、会议待办、推进工作 | Q12~Q18 |
+| 2. 企业微信 | 智能客服:私信聊天、Agentic 机器人、人工接管 | Q19~Q32 |
+| 2. 企业微信 | CRM:私信客户、客户群、社群群聊 | Q33~Q43 |
+| 2. 企业微信 | 底层 Skills + API | Q44~Q51 |
+
+## 一、所有项目共同待办
+
+| 状态 | ID | 阶段 | 待办事项 | 具体需要干什么 | 做成什么样算完成 |
+|---|---|---|---|---|---|
+| ☐ | C01 | M0 | 确定业务负责人 | 每个 P0 模块指定 1 名真实业务使用人,负责提供案例、试用和反馈 | 名单中有业务负责人、技术负责人、验收人;没有业务负责人的模块不开工 |
+| ☐ | C02 | M0 | 收集真实业务任务 | 每个 P0 模块收集 3 个日常真实任务、当前做法、耗时和失败案例 | 每个模块至少有 3 个案例,并由业务人员确认“确实每天或每周会做” |
+| ☐ | C03 | M0 | 完成竞品与价格调研 | 每个可售模块调研至少 3 个竞品或人工替代方案,记录功能、价格、计费方式和差评 | 表中信息有来源;无公开价格写“需要询价”,不编造价格 |
+| ☐ | C04 | 开发前 | 编写任务书 | 写清范围、非范围、输入、输出、流程、接口、数据、风险、工时和验收样本 | 业务、技术、验收三方确认后才进入开发 |
+| ☐ | C05 | 全程 | 管理需求变更 | 新需求单独记录增加内容、工时、延期和验收变化 | 所有新增工作都能找到变更单,不静默塞进原任务 |
+| ☐ | C06 | 交付时 | 制作销售 Demo | 每个可售模块制作 15~35 秒视频,展示痛点、核心过程和结果 | 河南、厦门销售人员无需讲解即可直接转发;视频使用样例或脱敏数据 |
+| ☐ | C07 | 交付时 | 制作 HTML 结果页 | 用 HTML 展示分析结果、修改差异、证据、风险和确认按钮 | 页面打开正常;用户一眼能看懂结果;页面不承载复杂业务操作 |
+| ☐ | C08 | 交付时 | 增加人工确认 | Listing 发布、发消息、建群、自动回复等写操作执行前必须让人确认 | 未确认时写操作次数为 0;确认记录包含操作者、时间和目标对象 |
+| ☐ | C09 | 交付时 | 增加审计与回滚 | 记录每次修改前后内容、操作者、时间、原因和执行结果 | 任一修改都能追溯;支持恢复上一版本;失败不留下半完成状态 |
+| ☐ | C10 | 交付时 | 提供 sample/live 两种模式 | sample 不需要真实账号,live 使用真实授权和小规模默认值 | 无账号也能跑 Demo;缺凭据时给清晰操作提示,不暴露原始接口错误 |
+| ☐ | C11 | 交付时 | 完成 smoke 验收 | 覆盖安装、工具发现、样例运行、缺凭据、核心输出字段和异常恢复 | smoke 全部通过;代码、文档、日志和安装包中没有真实密钥或客户数据 |
+| ☐ | C12 | 试点时 | 完成真实业务试用 | 让真实业务人员用模块完成至少 5 次任务,记录成功率、耗时、人工修改和异常 | 达到本清单指标才能标“可交付”;未达标统一标“试点版” |
+| ☐ | C13 | P1 | 制作商业化卡片 | 写清产品名称、客户、输入输出、Demo、部署方式、服务边界、成本和报价 | 销售拿到卡片能说明卖什么、怎么演示、怎么收费、哪些能力不承诺 |
+
+## 二、方向 1:VOC 技能 + 电商竞品分析、洞察
+
+### 1.1 VOC 数据、竞品分析与洞察
+
+| 状态 | ID | 阶段 | 待办事项 | 具体需要干什么 | 做成什么样算完成 |
+|---|---|---|---|---|---|
+| ☐ | E01 | P0 | 定义多源 VOC 数据结构 | 统一客户、商品、订单、评论、客服消息、售后和外部内容的字段与来源标签 | 四类样本可导入;字段完整率 ≥95%;每条数据都有来源和时间 |
+| ☐ | E02 | P0 | 接入一方业务数据 | 接入店铺评论、客服记录、售后记录和订单导出中的至少两类 | 每类至少导入 1 份真实脱敏样本;重复记录率 ≤3% |
+| ☐ | E03 | P0 | 接入三方市场数据 | 复用现有社媒、电商和海外接口采集竞品、评论、价格和排名 | 至少跑通 2 个外部平台;采集失败有明确状态和重试提示 |
+| ☐ | E04 | P0 | 建立证据追溯 | 给每条洞察保留原文、来源链接或来源 ID、时间和分析依据 | 100% 重点结论可以点回原始证据;无证据结论标“待验证” |
+| ☐ | E05 | P1 | 建立店铺 VOC 问题池 | 把评论、客服和售后归入商品、Listing、物流、服务、退款等问题 | 用 ≥500 条记录验收;分类 F1 ≥0.80;Top10 每项至少有 3 条原声 |
+| ☐ | E06 | P0 | 自动发现直接竞品 | 根据品类、价格带、消费场景、评分和销量筛选竞品 | 对 1 个品类找出 5 个可解释竞品,每个竞品都写明入选原因 |
+| ☐ | E07 | P0 | 生成竞品洞察报告 | 汇总价格、销量、评分、关键词、好差评和我方差距 | 1 次运行产出 5 个竞品、≥10 张证据卡和 5 条可执行动作 |
+| ☐ | E11 | P2 | 建立选品机会评分 | 按需求强度、竞争热度、价格带、差评空白和能力匹配给候选商品评分 | 输出 Top20 候选、Top5 待验证机会和不建议进入清单;每项有证据 |
+
+### 1.2 Listing 优化
+
+| 状态 | ID | 阶段 | 待办事项 | 具体需要干什么 | 做成什么样算完成 |
+|---|---|---|---|---|---|
+| ☐ | E12 | P0 | 封装 Listing 诊断入口 | 用户只需输入链接、ASIN 或 SKU,系统自动读取并开始诊断 | 国内外规则分开;无需用户选择底层接口或填写复杂参数 |
+| ☐ | E13 | P0 | 完成 Listing 五维评分 | 对标题、卖点、关键词、图片和 A+ 内容分别评分并列出扣分项 | 20 个 Listing 单条诊断 ≤3 分钟;与运营标注一致率 ≥80% |
+| ☐ | E14 | P0 | 增加竞品与 VOC 依据 | 每条 Listing 建议都关联竞品表现、关键词或用户评论 | 100% 重点建议有数据或规则依据;不凭空承诺转化提升 |
+| ☐ | E15 | P0 | 生成三版 Listing 文案 | 生成保守、平衡、进攻三版标题、Bullet、描述/A+和搜索词 | 20 个 Listing 每个有 3 个完整版本;运营一次采纳率 ≥70% |
+| ☐ | E16 | P0 | 校验平台规则与禁限词 | 检查字符数、禁限词、品牌词、事实声明和高风险表达 | 格式规则通过率 100%;高风险表达不得直接进入待发布版本 |
+| ☐ | E17 | P1 | 生成图片素材 Brief | 根据 VOC 卖点和 Listing 文案输出主图、场景图、边框和 A+ 分镜要求 | 每个 SKU 都有尺寸、文案、场景、素材和禁止项说明 |
+| ☐ | E18 | P1 | 生成候选主图与详情图 | 接入图片生成技能,为每个 SKU 生成 3 套候选素材 | 10 个 SKU 生成 ≥30 套素材;生成成功率 ≥90%;设计师可用率 ≥70% |
+| ☐ | E19 | P0 | 制作 Listing 修改预览 | 用 HTML 对比修改前后的标题、卖点、图片、依据和风险 | 用户能逐项查看差异;未批准内容不能进入发布流程 |
+| ☐ | E20 | P0 | 建立 Listing 审批状态 | 支持草稿、待审核、已批准、已发布和已回滚五个状态 | 20 次流程演练状态无跳跃;每次审批记录人员、时间和意见 |
+| ☐ | E21 | P0 | 保存 Listing 历史版本 | 发布前自动备份当前版本,保存所有修改版本和素材 | 任一版本可在 5 分钟内恢复;恢复后字段和素材不丢失 |
+### 1.3 SaaS 提供源码,用户自动配置完成竞品看板
+
+| 状态 | ID | 阶段 | 待办事项 | 具体需要干什么 | 做成什么样算完成 |
+|---|---|---|---|---|---|
+| ☐ | E08 | P0 | 配置竞品监控对象 | 制作品牌、SKU、指标、频率和告警阈值的配置入口 | 业务人员能在 15 分钟内独立新增 1 个竞品;首批支持 5 品牌 20 SKU |
+| ☐ | E09 | P0 | 实现竞品每日监控 | 定时采集价格、评分、评论量、排名和 Listing 变化并保存历史 | 连续运行 7 天;任务成功率 ≥95%;变化记录可追溯 |
+| ☐ | E10 | P0 | 实现竞品变化告警 | 对价格突变、评分下降、评论激增和 Listing 修改发送告警 | 采集失败或命中阈值后 10 分钟内产生告警;同一事件不重复轰炸 |
+| ☐ | E35 | P0 | 制作源码部署包 | 提供 Docker 或一键安装、环境模板、依赖检查和启动命令 | 在全新环境安装后 60 分钟内看到样例看板 |
+| ☐ | E36 | P0 | 制作数据源配置向导 | 让合作方选择平台、填写授权并添加品牌/SKU | 非开发人员可在 120 分钟内完成真实数据源配置 |
+| ☐ | E37 | P0 | 增加租户与数据隔离 | 不同合作方、客户和店铺的数据与凭据相互隔离 | 跨租户读取测试全部失败;无客户数据或密钥进入安装包 |
+| ☐ | E38 | P0 | 增加健康检查与告警 | 检查接口、数据库、定时任务、余额/权限和数据新鲜度 | 任一关键组件异常后 10 分钟内可见;提示包含可执行恢复步骤 |
+| ☐ | E39 | P0 | 增加备份、升级和回滚 | 提供数据库备份、版本升级、失败回滚和运维手册 | 非开发人员按手册完成一次备份恢复和一次版本回滚 |
+
+### 1.4 国内店铺的 API 接入和 Skills
+
+| 状态 | ID | 阶段 | 待办事项 | 具体需要干什么 | 做成什么样算完成 |
+|---|---|---|---|---|---|
+| ☐ | E22 | M0 | 调研商家后台写接口 | 对 Amazon、淘宝天猫、京东、抖店至少 3 个平台调研授权、商品读写、图片、评论、订单、频控和费用 | 平台矩阵信息有官方或服务方证据;明确哪些能读、哪些能写 |
+| ☐ | E23 | P1 | 跑通一个平台授权 | 选择 1 个有真实测试账号的平台完成授权、续期和权限检查 | 授权流程跑通;凭据不写日志;过期后有清晰恢复方式 |
+| ☐ | E24 | P1 | 实现 Listing 受控写回 | 只写白名单字段,支持读取旧值、幂等更新、回执和失败补偿 | 沙箱或测试店完成 20 次更新;成功率 ≥95%;重复提交不重复写入 |
+| ☐ | E25 | P1 | 实现 Listing 回滚 | 写回失败或用户撤销时恢复发布前版本 | 20 次写回演练均可恢复;失败不留下部分字段为新、部分字段为旧的状态 |
+| ☐ | E40 | P0 | 定义统一店铺 Skills | 将不同平台统一为商品查询、Listing 读取、更新、回滚、评论、订单等动作 | 上层 Agent 使用统一动作名称,不直接依赖平台原始接口 |
+| ☐ | E41 | P0 | 完成国内平台连接器 POC | 从淘宝天猫、京东或抖店中选 1 个平台实现核心读写动作 | 读接口成功率 ≥95%;20 次受控写回成功率 ≥90%;有幂等、审计和回滚 |
+
+### 1.5 VOC 到电商的其他具体应用:评论、售后、活动与多店运营
+
+| 状态 | ID | 阶段 | 待办事项 | 具体需要干什么 | 做成什么样算完成 |
+|---|---|---|---|---|---|
+| ☐ | E26 | P1 | 分类店铺评论 | 识别评论的情绪、意图、问题类型和风险等级 | 用 ≥300 条评论测试;分类 F1 ≥0.85 |
+| ☐ | E27 | P1 | 生成评论回复草稿 | 根据商品事实、品牌话术和客户问题生成可审核回复 | 运营一次采纳率 ≥70%;回复能引用正确商品与政策信息 |
+| ☐ | E28 | P1 | 建立评论转人工规则 | 退款、法律、安全、严重投诉和低置信度评论必须转人工 | 评测集中高风险案例 100% 转人工;未经批准自动发布为 0 |
+| ☐ | E29 | P2 | 建立售后工单 | 从评论或客服记录识别退款、损坏、缺件等问题并创建工单 | 100 个案例中建单召回率 ≥90%;每单能回溯原消息和订单/SKU |
+| ☐ | E30 | P2 | 实现售后分派与催办 | 给工单设置负责人、SLA、升级、补偿审批和完成状态 | 超时后 5 分钟内告警;错误补偿自动执行次数为 0 |
+| ☐ | E31 | P2 | 生成节日商品候选 | 输入节日和商品库,筛选适合活动的 SKU 并说明原因 | 用 1 个节日和 20 个 SKU 演练;业务确认相关性 ≥80% |
+| ☐ | E32 | P2 | 生成节日批量优化方案 | 为候选 SKU 生成 Listing、图片和排期建议,进入人工审批 | 每个修改有预览和依据;未经批准写回为 0 |
+| ☐ | E33 | P1 | 生成多店每日经营摘要 | 汇总各店价格、评论、Listing、售后和异常,按优先级生成当天任务 | 3 店数据同步成功率 ≥95%;高风险事项有明确负责人 |
+| ☐ | E34 | P1 | 验证多店管理效率 | 让 1 名店长连续 14 天使用多店摘要和任务清单 | 日常巡店时长下降 ≥30%;高风险事项漏报率 ≤5% |
+
+## 三、方向 2:企业微信——自动化办公、监听与客服
+
+### 2.1 日常办公:会议、文档、知识库
+
+| 状态 | ID | 阶段 | 待办事项 | 具体需要干什么 | 做成什么样算完成 |
+|---|---|---|---|---|---|
+| ☐ | Q01 | P0 | 制作会议模板 | 提供项目启动会、周会和复盘会模板,包含目标、议程、材料和参会人 | 三类模板均可直接创建会议;必填信息缺失时不执行 |
+| ☐ | Q02 | P0 | 验证官方会议能力 | 跑通创建、查询、修改参会人和取消会议 | 测试企业完成 10 次操作;时间、时区和参会人错误为 0 |
+| ☐ | Q03 | P0 | 接收会议内容 | 支持会议文本、转写文件或录音转写结果进入纪要流程 | 三种入口至少跑通两种;内容与来源会议正确关联 |
+| ☐ | Q04 | P0 | 提取会议结论与待办 | 从会议内容提取决策、Action、负责人、期限、原句和未决问题 | 10 份会议样本中关键待办召回率 ≥90%;无依据字段标“待确认” |
+| ☐ | Q05 | P0 | 人工确认会议待办 | 在创建文档和企微待办前,让负责人确认或修改提取结果 | 未确认时创建待办数为 0;确认记录可追溯 |
+| ☐ | Q06 | P0 | 写入会议纪要与待办 | 把确认结果写入企微文档并创建企微待办 | 确认后同步成功率 ≥95%;失败可重试且不重复创建 |
+| ☐ | Q07 | P1 | 制作文档模板 | 提供任务书、需求变更、会议纪要和项目周报模板 | 四类文档都能由自然语言创建;必填字段完整率 ≥95% |
+| ☐ | Q08 | P1 | 增加文档修改预览 | 修改企微文档前展示新旧差异并备份原文 | 未确认覆写次数为 0;原内容恢复成功率 100% |
+| ☐ | Q09 | P1 | 建立知识库索引 | 读取一个部门的企微文档,建立增量索引和版本更新 | 首批接入 100 份文档;文档更新后 10 分钟内生效 |
+| ☐ | Q10 | P1 | 增加知识库权限 | 继承文档可见范围,查询时过滤无权限内容 | 越权命中次数为 0;权限变化后索引同步更新 |
+| ☐ | Q11 | P1 | 实现带引用问答 | 回答制度、产品和业务问题时返回引用文档和原文片段 | 50 题标准集 Top3 命中率 ≥90%;引用可打开率 100% |
+
+### 2.2 目标管理:大计划、目标拆解、会议待办与工作推进
+
+| 状态 | ID | 阶段 | 待办事项 | 具体需要干什么 | 做成什么样算完成 |
+|---|---|---|---|---|---|
+| ☐ | Q12 | P0 | 定义目标层级 | 建立计划、目标、里程碑、任务、指标和依赖的数据结构 | 每个目标都能关联负责人、期限、指标、依赖和验收证据 |
+| ☐ | Q13 | P0 | 自动拆解大计划 | 输入年度或季度计划,生成目标、里程碑和任务草案 | 用 3 个真实计划测试;业务负责人一次确认通过率 ≥80% |
+| ☐ | Q14 | P0 | 冻结目标基线 | 负责人确认后保存目标、指标、期限和任务基线 | 无负责人、无指标或无期限的任务不能进入执行状态 |
+| ☐ | Q15 | P0 | 同步企微待办 | 支持待办创建、更新、完成、取消以及负责人和截止时间映射 | 50 个测试待办同步成功率 ≥95%;重复创建率 0 |
+| ☐ | Q16 | P0 | 回写任务状态 | 将企微待办状态回写项目台账,并支持失败重试 | 企微与台账状态一致率 ≥95%;失败 5 分钟内可见 |
+| ☐ | Q17 | P1 | 识别项目风险 | 每天识别逾期、阻塞、无人负责和依赖冲突 | 对 2 个项目运行 14 天;真实风险召回率 ≥90%,误报率 ≤10% |
+| ☐ | Q18 | P1 | 生成进度日报和周报 | 汇总已完成、待办、风险、变更和下周动作 | 每项进度能追溯任务、会议或变更记录;不允许模型编造进度 |
+
+### 2.3 智能客服:私信聊天、Agentic 机器人与人工接管
+
+| 状态 | ID | 阶段 | 待办事项 | 具体需要干什么 | 做成什么样算完成 |
+|---|---|---|---|---|---|
+| ☐ | Q19 | P0 | 启用企微生产路由 | 确认 Fmode 企微生产接口路由、订阅、席位和登录链路可用 | 测试账号完成登录、状态查询和 1 次业务接口调用;未验证前不称已上线 |
+| ☐ | Q20 | P0 | 建立消息 webhook | 接收私信、群聊和系统回调,校验签名并转换为统一事件 | 1,000 条混合事件回放丢失率 0;P95 入库延迟 ≤10 秒 |
+| ☐ | Q21 | P0 | 增加消息去重与重试 | 给事件加幂等键、重试、死信队列和处理状态 | 重复入库率 ≤0.1%;失败事件可以重新处理 |
+| ☐ | Q22 | P0 | 增加历史消息补偿 | 服务断开或重启后,用历史同步接口补齐缺失消息 | 重启演练后消息完整;补偿过程不产生重复记录 |
+| ☐ | Q23 | P0 | 建立客服意图分类 | 识别咨询、购买、售后、投诉、退款和其他意图 | 用 ≥200 条脱敏会话测试;意图分类 F1 ≥0.85 |
+| ☐ | Q24 | P0 | 读取客户上下文 | 回复前读取客户资料、历史会话、所属群、待办和知识库 | 评测中客户和会话关联准确率 ≥95%;无权限信息不进入上下文 |
+| ☐ | Q25 | P0 | 生成客服回复草稿 | 根据知识、CRM 和应答政策生成回复、置信度和下一步动作 | 事实引用准确率 ≥90%;人工一次采纳率 ≥70% |
+| ☐ | Q26 | P0 | 设置客服风险门槛 | 投诉、退款、法律、敏感信息和低置信度必须转人工 | 评测集中高风险案例 100% 转人工;未经批准自动发送为 0 |
+| ☐ | Q27 | P0 | 建立 Agentic 应答政策 | 用自然语言配置适用场景、允许工具、禁止动作、优先级和示例 | 首批配置 ≥30 条政策;业务人员不改代码即可调整政策 |
+| ☐ | Q28 | P0 | 建立政策测试与发布 | 每次政策变更自动运行案例集,支持审批、灰度、版本和回滚 | 100 个案例命中准确率 ≥95%;禁止动作触发率 0;10 分钟内可回滚 |
+| ☐ | Q29 | P0 | 实现人工接管状态机 | 支持 AI 服务中、待接管、人工处理中、人工释放和 AI 恢复 | 100 次回放中状态流转正确;人工接管后 AI 发言次数为 0 |
+| ☐ | Q30 | P0 | 建立接管队列与 SLA | 记录接管原因、负责人、等待时间、超时升级和处理结果 | P95 路由时间 ≤30 秒;超时自动升级;同一会话不重复分派 |
+| ☐ | Q31 | P0 | 生成接管上下文摘要 | 转人工时提供客户、问题、已查知识、已执行动作和建议下一步 | 人工无需翻完整聊天即可继续处理;摘要关键信息完整率 ≥90% |
+| ☐ | Q32 | P0 | 恢复 AI 服务 | 人工释放后让 AI 读取处理结果并恢复服务 | 100 次演练恢复成功率 100%;不重复询问人工已解决的问题 |
+
+### 2.4 CRM 客户管理:私信客户、客户群与社群群聊
+
+| 状态 | ID | 阶段 | 待办事项 | 具体需要干什么 | 做成什么样算完成 |
+|---|---|---|---|---|---|
+| ☐ | Q33 | P1 | 定义客户 360 模型 | 统一客户身份、标签、来源、会话、群、负责人、跟进和生命周期 | 100 个客户样本字段完整率 ≥90%;每个客户有稳定主键 |
+| ☐ | Q34 | P1 | 合并重复客户 | 按企微 ID、手机号等规则识别和合并重复记录 | 100 个样本重复客户率 ≤2%;合并有记录并可撤销 |
+| ☐ | Q35 | P1 | 增加客户隐私与审计 | 敏感字段脱敏,限制查看范围,记录查看和修改操作 | 未授权访问为 0;所有客户资料修改都有审计记录 |
+| ☐ | Q36 | P1 | 定义客户群模型 | 建立群、成员、客户、负责人、标签、事件和任务的关联 | 首批 20 个群均能关联成员和负责人 |
+| ☐ | Q37 | P1 | 同步群和成员变化 | 同步建群、入群、退群、成员变化和群公告 | 成员同步准确率 ≥95%;变化 10 分钟内可见 |
+| ☐ | Q38 | P1 | 生成群健康摘要 | 汇总活跃度、关键问题、无人回应和待跟进事项 | 每个跟进项都能回溯到原消息;无原文不产生任务 |
+| ☐ | Q39 | P1 | 定义群聊关键信号 | 定义咨询、购买意向、投诉、风险和无人回应五类信号 | 每类有清晰规则、正反例和处理负责人 |
+| ☐ | Q40 | P1 | 检测群聊关键信号 | 使用关键词和模型双路检测,合并重复事件 | 用 ≥1,000 条消息测试;高意向/投诉召回率 ≥85%,误报率 ≤10% |
+| ☐ | Q41 | P1 | 发送社群告警 | 将重大投诉、高意向和长时间无人回应通知负责人 | 重大投诉 1 分钟内告警;100% 告警可追溯原消息 |
+| ☐ | Q42 | P2 | 建立自动建群流程 | 按客户资格生成建群申请,人工批准后建群、邀请、发公告和建待办 | 测试环境跑 20 次;成功率 ≥95%;未经批准建群次数为 0 |
+| ☐ | Q43 | P2 | 增加建群风控 | 设置频率限制、重复群检测、失败补偿和平台规则检查 | 重复建群次数为 0;失败可恢复;真实账号试点前取得客户确认 |
+
+### 2.5 底层 Skills + API 支持
+
+| 状态 | ID | 阶段 | 待办事项 | 具体需要干什么 | 做成什么样算完成 |
+|---|---|---|---|---|---|
+| ☐ | Q44 | P0 | 固化双通道路由 | 会议、文档、日程、待办走官方 CLI;客户、群、朋友圈、个人账号走 Fmode 接口 | 每种用户意图都能路由到正确通道;两套凭据不混用 |
+| ☐ | Q45 | P0 | 建立企微业务数据库 | 建立账号、客户、群、会话、消息、任务、策略、接管和审计数据表 | Q06、Q20、Q29、Q33 的数据可正常写入和查询 |
+| ☐ | Q46 | P0 | 增加租户与账号隔离 | 按企业、项目、企微账号隔离数据和权限 | 跨租户访问测试全部失败;查询必须带租户上下文 |
+| ☐ | Q47 | P0 | 建立统一事件队列 | 消息、任务、客户、群和接管事件使用统一格式和状态 | 事件可重试、可追踪、可回放;消费者失败不丢事件 |
+| ☐ | Q48 | P0 | 建立统一审计日志 | 记录读写对象、操作者、时间、动作、输入摘要和结果 | 发消息、建群、改任务、改策略等关键动作 100% 有审计 |
+| ☐ | Q49 | P0 | 增加连接器健康检查 | 检查官方 CLI、Fmode 网关、登录、订阅、数据库和事件队列 | 任一组件异常 10 分钟内告警;提示包含恢复方法 |
+| ☐ | Q50 | P0 | 统一工具输出和错误提示 | 所有 MCP 工具返回正文、摘要、数据、文件、下一步、警告和错误 | 用户不会看到 token、原始 403、堆栈或上游响应体;提示可直接执行 |
+| ☐ | Q51 | P0 | 完成企微集成 smoke | 覆盖会议、待办、消息监听、客服、人工接管和数据库恢复 | 关键流程 smoke 100% 通过;断网和重启演练后可以恢复 |
+
+## 四、建议的第一批开工范围
+
+| 顺序 | 产品组合 | 本批必须完成的待办 |
+|---:|---|---|
+| 1 | Listing 优化引流单品 | E06~E07、E12~E21 |
+| 2 | 竞品看板源码方案 | E01~E04、E06~E10、E35~E39 |
+| 3 | 企微会议到目标闭环 | Q01~Q06、Q12~Q16 |
+| 4 | 企微 Agentic 客服 | Q19~Q32、Q44~Q51 |
+
+> 第一批之外的 P1/P2 待办先不并行开发;先让上述四个组合各形成一个能演示、能试用、能验收的闭环。

+ 114 - 0
docs/specs/voc-ecommerce-qiwei-jtbd-smart-backlog-2026-07-14.md

@@ -0,0 +1,114 @@
+# 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 项同时开工会稀释人员,无法形成可卖闭环 |
+
+## 七、执行原则
+
+1. 先完成 A/B/D/E 四个组合的可售闭环,再扩 P1/P2;不要 32 项同时开工。
+2. Listing 是高频低价技能单品,竞品/多店/CRM 是企业流程方案,Skills/API/源码部署是复制底座;三类产品分别定价、分别验收。
+3. 所有 AI 写操作都采用“建议或草稿→HTML 预览→人工确认→执行→审计→回滚”,不得把“Agentic”理解为无边界自动驾驶。
+4. 业务方必须每日/每两日反馈真实使用;技术团队负责封装和稳定性,不能替代业务人员决定规则。
+5. 当前会议材料属于内部需求证据,不等于市场验证;报价、转化提升、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/` | 官方会议与普通文档已有能力边界 |