先把业务闭环定义清楚，再决定哪些步骤交给 AI
摘要
跨境团队真正需要的不是另一个能写 Listing 的聊天框，而是一个能保持 SKU 事实、理解渠道差异、连接销售与利润、在高风险动作前停下来审批，并在动作发生后重新读取平台结果的经营系统。系统必须知道“页面做好”和“商品可售”、“指令提交”和“平台已修改”、“预计提升”和“真实验证”是不同状态。
1. 三条业务旅程，共用一个控制塔
客户不会购买“十八个 Skill”。客户从一个具体起点出发，希望到达一个可以验收的经营结果。Skill 只是完成某个边界清楚任务的执行单元；控制塔负责把这些任务串成业务闭环。
JOURNEY 01 · SUPPLY TO BRAND
从供应链资源到可交易品牌
起点：有工厂、货盘或产品想法，但不懂跨境运营。
验收结果：1–3 个精确 SKU 完成事实、样品、单位经济、包装、渠道、支付与履约验证，至少一个渠道通过真实交易。
JOURNEY 02 · AMAZON DAILY OPS
Amazon 每日经营诊断
起点：运营每天分开看销量、广告、关键词、Listing、库存和利润。
验收结果：五分钟内得到可信经营结论、对象级原因候选、最多五项动作，以及执行后的验证结果。
JOURNEY 03 · ZERO TO FIRST ORDER
从零选品到首单履约
起点：没有产品，希望通过 CJ、DSers 或 AliExpress 做一件代发。
验收结果：精确变体、三地运费、样品、Product Truth、Shopify 草稿、非零实付订单、供应商接单、物流回传与签收均有证据。
SHARED MODULE · OPERATING CONTROL TOWER
全渠道经营控制塔
职责：统一管理数据覆盖、经营事实、异常、诊断、动作候选、审批、执行回读、验证结果、企业席位和 credits。它不是第四类客户，也不是万能大屏。
产品判断：先把 Amazon 每日经营诊断作为第一个可用切片，因为它的数据对象、诊断规则和动作边界最清楚；同时搭出控制塔的通用证据、审批与回读骨架。之后再接入品牌启动和一件代发旅程，避免一开始建设一个没有真实闭环的“大而全自动化平台”。
2. 所有模块必须说同一种业务语言
跨境自动化失败往往不是模型不够聪明，而是不同工具对“商品、上线、执行、成功”的定义不一致。系统用下面这条共用链路约束所有模块。
- 01 · PRODUCT TRUTH商品事实卡
- 02 · OFFER可售方案
- 03 · ECONOMICS单位经济卡
- 04 · SIGNAL经营信号
- 05 · DIAGNOSIS经营诊断
- 06 · ACTION动作候选
- 07 · READBACK执行回读
- 08 · MEMORY经营记忆
PRODUCT TRUTH CARD先锁定精确 SKU，再允许生成
记录来源、视觉事实、功能边界、允许与禁止声明、未知项和素材权利。社媒参考和相似商品不能覆盖它。
SELLABLE OFFER选品针对可售组合，不针对图片
同一个商品在不同变体、仓库、目的国、物流线路、渠道和价格下，是不同的可售方案。
ACTION CANDIDATE建议必须变成可审批对象
每项动作写清对象、旧值、新值、证据、负责人、风险、有效期、复核窗口与回滚条件。
VERIFICATION RESULT预计结果不能写成已取得结果
只有按预先约定口径重新读取平台数据后，才能标记保留、迭代、回滚或数据不足。
两个状态轴不能混在一起
| 状态轴 | 状态 | 回答的问题 |
|---|---|---|
| 商业就绪 | PLANNED → DRAFTED → STAGED → PUBLISHED → TRANSACTION_VERIFIED → FULFILLMENT_VERIFIED | 商品现在能否被看到、购买、收款和履约？ |
| 经营动作 | DESIGN → DIAGNOSED → DRAFT ACTION → APPROVED → READ-BACK → VERIFIED OUTCOME | 一个经营判断是否已经执行并验证？ |
硬边界：Shopify 有商品草稿不等于前台可售；支付 App 显示连接不等于真实收款；API 返回成功不等于平台对象已经正确改变；有流量和加购不等于已经完成订单；一笔订单付款不等于供应商已接单和顾客已签收。
3. 模块一：从供应链资源到可交易品牌
这一模块服务“有货但没有跨境品牌能力”的团队。系统不以生成一个漂亮网站为终点，而以一个最小品牌试销单元通过事实、合规、经济、渠道、支付和履约验证为终点。
- 01 · 启动约束确认公司主体、品牌、目标市场、预算、账号归属与现有供应链；输出 Launch Charter 和权限缺口。
- 02 · 供应链事实把精确商品链接、规格、材质、MOQ、报价、交期、包装、证书和仓库整理成 Supplier Dossier 与 Product Truth Card；缺项保持未知。
- 03 · 选品与单位经济结合需求、竞品、VOC、平台费、物流、退货和 CAC 上限，对“可售方案”评分；任何合规、履约或负经济硬失败都不能靠总分补回。
- 04 · 品牌、包装与声明形成 Brand Profile、视觉规则、Claims Matrix、包装标签核对和最终印刷审批；AI 不能替代法规确认或真实打样。
- 05 · 渠道上市包分别生成 Amazon、Shopify、TikTok Shop 的 Listing 草稿、变体、价格、图片需求、视频脚本、库存映射和政策检查；三个渠道不共用一份泛文案。
- 06 · 多模态营销包基于商品事实，路由 Instagram、短视频、博客、LinkedIn、X、Facebook、达人合作包与 GEO 内容；Product Truth 约束所有渠道版本。
- 07 · 交易与履约闸门分别验收域名、库存、运费、支付、税务、结账、供应商付款、订单同步、tracking、退货和通知；每一项都是独立状态。
- 08 · 受控上线与 30 天运营先上线 1–3 个 SKU，完成真实非零订单和履约，再进入广告、达人与扩量；每天回收经营信号和问题。
AI CAN PREPARE可自动完成
合规读取、证据整理、去重、评分、经济情景计算、Listing/内容草稿、Shopify Draft、页面检查、差异报告和审批队列。
HUMAN MUST AUTHORIZE必须人工确认
最终 SKU、供应商、商标、样品、功效声明、包装印刷、发布、价格库存、域名、支付、采购、广告预算、达人外发与结果性声明。
4. 模块二：Amazon 每日经营诊断
第一版产品不再做一个 KPI 墙，而是做一个“经营判断层”：先说明数据能不能支持判断，再解释销售与利润变化来自哪里，最后只生成少量可审批动作。
最小数据合同
| 数据面 | 最小粒度 | 关键边界 |
|---|---|---|
| Business Reports | marketplace × child ASIN × day | Unit Session % 不能替换成广告 CVR。 |
| Amazon Ads | campaign × ad group × target/search term × day | SP、SB、SD 与归因窗口分开。 |
| 关键词与排名 | ASIN × query × day | 第三方排名是观测证据，不是账户经营事实。 |
| 利润与库存 | SKU/FNSKU × day | 没有成本只谈收入效率；不能用父 ASIN 掩盖变体断货。 |
| Offer / Listing | child ASIN × snapshot time | 必须保留价格、Coupon、Buy Box 与 Listing 版本时间。 |
三个核心界面不是三张孤立图
SCREEN 01 · DAILY VERDICT今日经营总览
先给一句可执行判断，再展开销售—利润桥、风险贡献和昨日动作验证。
- 显示最新可用数据日、缺失源、归因成熟度与质量等级。
- 问题必须落到 ASIN、Campaign、Target 或 Search Term。
- 今日动作最多五项。
SCREEN 02 · CAUSAL WORKBENCHAmazon 问题详情
把信号、原因候选、支持证据、反向证据、排除项和缺失证据放在同一工作台。
- 显示因果链，但不把同时发生写成已证明因果。
- 置信度和证据完整度分开。
- 必须保留“需要人工判断”的问题。
SCREEN 03 · APPROVAL & READBACK动作审批中心
审批人看到修改前后差异、权限范围、预算影响、回滚条件与平台回读，不接受一句“建议优化”。
- 读取、执行和审批是不同权限。
- 先保存执行前快照，再分阶段写入。
- 回读成功后才进入业务验证。
跨指标诊断必须先查反证
| 观察组合 | 优先判断 | 必须检查 | 安全动作 |
|---|---|---|---|
| Sessions ↓ / Unit Session % stable | 流量问题 | 自然排名、广告曝光、预算、Buy Box、库存 | 定位掉量对象，不直接改 Listing |
| Sessions stable / CVR ↓ | Offer、页面或流量结构 | 价格、Coupon、评分、Listing 版本、Broad 占比 | 生成字段级差异草稿 |
| Spend ↑ / Orders flat | CPC、搜索词相关性或承接 | Placement、Target、Search Term、Ad CVR | 对象级出价/否词草稿，不全账户停投 |
| Sales ↑ / Contribution profit ↓ | 增长被成本吞噬 | 广告、折扣、费用、退款、COGS 完整性 | 先输出利润桥，阻止盲目放量 |
第一版自动化边界：可自动导入、归一化、重算、异常检测、诊断草稿、通知和候选文件；不得自动改 Bid、Budget、Negative、Campaign State、Listing、Price、Coupon 或库存。任何写入都必须经过对象级差异审批、最小权限执行和状态回读。
5. 模块三：从零选品到首单履约
这一模块不是“一键建站”，而是一个证据驱动的开店状态机。只有上一阶段硬闸门通过，AI 才能进入下一阶段。
EVIDENCE_MISSING→READY_FOR_SAMPLE→READY_FOR_DRAFT→READY_FOR_REAL_ORDER→FIRST_ORDER_DELIVERED→SCALE_ELIGIBLE
- 01 · 机会发现聚合搜索、社媒、竞品站、广告库和评论痛点，形成 Opportunity Card；社媒热度只能证明需求方向，不能证明销量。
- 02 · 精确变体寻源保存 CJ/AE Product ID、变体、供应商、原图、成本、重量、仓库和目的国；只保存标题或相似图不合格。
- 03 · 硬淘汰与评分不可配送、无法核实费用、侵权/高合规风险、只能依赖未经证实功效、基础经济为负，任一项直接停止；通过后再按需求、履约、利润、内容与差异化评分。
- 04 · 三地物流与单位经济按具体变体核对三个目标 ZIP 的运费、处理时间、运输时间、退款/补发预留与 CAC 上限，分别计算 Base 和压力情景。
- 05 · 样品与商品事实核对实物组件、材质、颜色、包装、安全、用法、可写和不可写声明；没有样品，不用 AI 场景图替代真实商品证据。
- 06 · 店铺与内容草稿生成 Shopify Draft、PDP、政策、FAQ、Blog/GEO、Instagram、TikTok、YouTube、LinkedIn、X、Facebook 与邮件草稿；仍标记为 Draft。
- 07 · 连接器独立验收CJ、DSers、AliExpress API、Shopify、PayPal、域名和物流分别验收；安装 App 或导入商品不代表授权、库存、支付、采购和 tracking 已经贯通。
- 08 · 单 SKU 受控上线开放一个真实商品与结账，完成非零实付、供应商付款与接单、tracking、通知、签收和退款路径；完成前不进入规模投放。
内容进入时机：机会发现阶段可以研究 Instagram、TikTok 与 YouTube 的创意结构；Product Truth 完成后可以写博客、GEO 与页面草稿；样品通过后才制作产品证明型内容；域名、支付、物流和政策通过后才开启购买导向；真实首单签收并回填成本后，才进入小额广告测试。
6. 模块四：全渠道经营控制塔
控制塔不把 Amazon、Shopify 和 TikTok Shop 强行变成同一种店铺。它只统一三类共用对象：证据、经营判断和动作治理；渠道指标仍按自己的口径保存。
01 · DATA COVERAGE数据覆盖与可信度
记录来源、对象、时间、时区、币种、归因窗口、成熟度、缺失字段和访问失败。访问失败是覆盖问题，不是“没有变化”。
02 · DAILY VERDICT五分钟经营简报
先给全局判断，再按店铺、渠道、SKU、Campaign 和问题贡献下钻；最多保留五项今天可行动事项。
03 · ACTION GOVERNANCE审批、执行与回滚
读取、起草、执行和审批分权；价格、库存、发布、预算、广告状态、外联、退款和采购必须在明确权限内发生。
04 · OPERATING MEMORY账户级经营记忆
持续保存“证据—诊断—动作—审批—回读—结果”，让系统知道某个账户什么动作在什么条件下有效，而不是只保留聊天记录。
企业团队安全不是附加功能
- 管理员拥有连接店铺、广告、社媒、ERP 与受管浏览器连接由企业管理员创建和撤销；子席位拿到限定授权，不拿可复用凭证。
- 紫鸟只是访问容器紫鸟或其他指纹浏览器不能成为权限系统。系统不导出 Cookie、不跨企业复用环境，也不因已登录就自动获得店铺权限。
- 飞书与钉钉是运营控制面它们承接队列、审批、负责人、达人名单和结果回写；不能把群机器人或 CLI 当作外部平台的业务授权。
- credits 单独治理企业额度按席位、店铺或项目分配，付费任务先预占、结束后核销；不透支、不静默重试、不自动充值。credits 不等于广告预算。
7. Skill 只在需要它的节点被调用
下面是现有能力如何进入产品，而不是把 Skill 名称直接当成产品菜单。每个 Skill 都保留自己的输入合同、输出合同与停止条件。
输入 Business Reports、Ads、关键词排名、Listing 变更、库存、价格和成本；输出数据质量、经营结论、跨模块诊断、Top 5 动作和验证计划。
JOURNEY 02 + TOWER按诊断需要路由资料采集、Review/VOC、关键词库、Listing 草稿、广告冷启动和单报表分析；它们不代替每日决策层。
JOURNEY 01 / 02从 Product Truth Card 与 DTC Desire Angle 出发，生成来源记录、创意执行包、品牌片视觉包、五格故事版与脚本；没有商品事实或视觉 QA 时不声称完成最终内容。
JOURNEY 01 / 03负责 SKU 级品牌片的商品锚点、连续性、模型路由、脚本、关键帧与交付验证；不替代批量 SKU 调度或真实平台发布。
JOURNEY 01 / 03把公开或授权样本整理成趋势信号、内容切入点和待验证创意假设；热度、点赞和投放时长不能证明销量或利润。
JOURNEY 01 / 03 + TOWER连接自有站健康、竞品、评论、公开广告、自动选品、达人队列、企业席位、紫鸟风险与 credits；当前是设计规范，不声称已接管账户。
JOURNEY 01 / 03 + TOWER完成人群匹配、达人评分、个性化多模态合作包、去重、频率与审批队列；默认不群发，不克隆达人身份，不伪造合作关系。
JOURNEY 01 / 03 + TOWER把已验证的 ChatGPT 会话与订单信号连接到商品事实、抓取/Feed、可回答页面、实验和转化质量；不保证引用、排名或推荐。
JOURNEY 01 / 03 + TOWER路由原则：经营控制塔先判断“问题是什么、证据够不够、需要哪一类专用能力”；专用 Skill 只做边界内任务；结果重新进入证据账本和审批队列。不能让一个大模型同时猜问题、改页面、改广告、发布内容并把返回成功当成业务完成。
8. 实施顺序：先建可信判断，再逐步开放执行
| 阶段 | 交付内容 | 验收条件 | 不做什么 |
|---|---|---|---|
| 0 · 业务与数据合同 | 统一实体、指标、状态、证据等级和动作合同。 | 同一数据能稳定重算；NA 不变成 0。 | 不接正式账户写入。 |
| 1 · Amazon MVP | 固定 CSV/XLSX 导入、基线、10–15 条规则、三个核心界面、每日动作与 7 日验证。 | 管理者三分钟理解最大风险；每条结论可追溯。 | 不自动停广告、改 Listing 或价格。 |
| 2 · 审批与回读 | 字段级差异、审批有效期、最小权限执行、幂等键、平台状态回读与回滚。 | 批准内容与平台实际状态逐项一致。 | 不把接口成功码当业务结果。 |
| 3 · 品牌与一件代发旅程 | Product Truth、Offer、经济、样品、渠道、支付与履约状态机。 | 至少一个 SKU 完成真实非零交易与履约回读。 | 不把草稿目录当可售店铺。 |
| 4 · 企业控制面 | 租户、席位、店铺授权、审计日志、credits、离职撤权与跨渠道日简报。 | 越权默认拒绝；每次重要动作可定位到人和对象。 | 不共享凭证，不跨租户复用浏览器环境。 |
产品成功指标
TIME TO DECISION理解问题的时间
管理者能否在三分钟内找到最大风险；运营能否在五分钟内进入正确对象。
TRACEABILITY结论可追溯率
每条结论是否都有来源、对象、时间、指标口径、反证和缺失证据。
READBACK MATCH执行回读一致率
批准的字段、对象和范围，是否与平台实际状态逐项一致。
VERIFICATION COMPLETION动作验证完成率
动作是否在归因成熟后形成保留、迭代、回滚或数据不足结论，而不是永远停在“已执行”。
9. 哪些能力已经有证据，哪些仍是待建设
RUNNABLE / VERIFIED PARTS已有能力
Amazon Listing 与广告专用 Skill、Product Truth、评论/VOC、关键词、Listing 草稿、广告草案、报表分析、SKU 级故事版/品牌片、网页与视频本地验证，以及独立站/GEO/达人方法。
DESIGN SPECIFICATIONS已完成设计但尚未统一运行
Amazon 每日诊断、DTC 每日经营路由、自动选品、全渠道控制塔、企业席位、credits、紫鸟安全边界、飞书/钉钉队列和一件代发状态机。
MISSING PRODUCTION LAYER当前最大缺口
官方/ERP 数据适配器、统一实体映射、每日快照、利润驱动分解、Action Ledger、正式写入适配器、read-after-write、席位强制与完整审计覆盖。
CLAIMS NOT MADE本页不声称
不声称无人值守启动品牌、不声称自动发布或真实广告增量、不声称生成内容已经自动通过商品一致性 QA、不声称 ChatGPT 来单由 GEO 导致，也不声称当前已经完成企业级账号接管。
相关公开实现与方法
下一步实现范围：用 Amazon 离线报表做第一版可操作原型，完成“今日经营总览—问题详情—动作审批—执行回读—验证结果”闭环。只有这条链路被真实运营使用并产生可追溯结果后，才扩展正式 API 和另外两条商家旅程。
把 Skill 变成可验收的经营系统
实施从 Amazon 每日经营诊断和共用控制塔开始：先统一数据与状态，再做诊断、审批和回读，不从全自动写入开始。