独立站每日经营与竞对雷达

1. 一个总入口、确定性执行与待审核队列

自然语言 Skill 只负责说明入口、路由和完成标准。定时、任务锁、重试、哈希、数据校验、历史基线和文件落盘，应由确定性的 Runner 执行。不同平台的访问逻辑放在各自连接器里，所有真实外部写入都不属于每日采集任务。

QoderWork CN schedule / command
  -> dtc-daily-ops-router
  -> deterministic daily runner
  -> tenant + seat policy / credit guard
  -> SellerSprite + owned + competitor connectors
  -> SignalEvent + AuditEvent evidence ledgers
  -> ProductCandidate auto-selection
  -> MultimodalOutreachPack per creator
  -> DingTalk selection brief / Feishu outreach queue
  -> credit ledger + delivery receipt + read-back

这个系统的产品价值不是“多抓一些数据”，而是每天形成一份证据可追溯、数据缺口也清楚可见的经营判断记录。

2. 八个职责清楚的模块

3. 每日运行必须经过的八个关卡

4. 竞品公开信号与自有经营数据是两类不同数据

数据契约明确区分 owned_authorized、competitor_official_public、public_observation 与 inferred。任何数字跨表使用时，都必须保留它原来的来源和定义。

经营事实规则：自有订单、退款和库存以 Shopify 交易记录为主账。GA4 与各广告平台保留各自的归因口径和数据成熟度，平台归因转化不能相加后当作店铺真实订单。

5. 五类业务契约、一份权限策略与两本治理账

observed evidence
  -> explicit interpretation
  -> proposed action
  -> pending_human_review
  -> approved operator execution
  -> read-back verification

6. 自动化选品与基于证据的达人多模态建联

当前运营链路由 QoderWork CN 负责编排，卖家精灵提供已授权范围内的商品、关键词与评论证据，钉钉 CLI 承接选品结果的内部交付，飞书 CLI 管理达人批量建联任务。“自动化选品”指每日运行不再依赖运营逐个浏览商品、凭感觉挑选；管理员负责制定规则与硬门槛，Runner 按同一套标准自动产生选品结论。

QoderWork CN
  -> SellerSprite evidence snapshot
  -> ProductCandidate hard gates + ranking
  -> AUTO_SELECTED / REJECTED_HARD_GATE / NEEDS_FRESH_DATA
  -> DingTalk CLI selection brief

Creator evidence + Product Truth Card
  -> MultimodalOutreachPack
  -> Feishu CLI batch work queue
  -> approved external channel
  -> delivery / reply / follow-up read-back

自动化边界：每日选品运行内部不再人工挑 SKU，但采购、寄样、供应商外联、Listing 发布和广告花费仍是独立审批动作。达人研究与多模态合作包可以批量生成；对外建联必须基于已批准名单、合法联系依据、渠道规则、频率限制和排除机制。QoderWork CN、卖家精灵、钉钉与飞书 CLI 的具体访问方式和权限范围，需要在每次实施时真实核验。

ChatGPT 来单与 GEO 闭环：已验证的 ChatGPT 会话与订单，作为查询覆盖和选品的需求证据；Product Truth 再让 PDP、结构化数据、Feed 与达人多模态合作包保持一致。订单归因状态、抓取权限、Feed 新鲜度、实验与转化质量的详细方法，见 ChatGPT 电商 GEO 方法论。

7. 企业团队需要权限控制面，而不是共用店铺凭证

企业版权限不能只看“账号是否已经登录”，而要同时限定企业、操作席位、店铺、数据源、可执行动作、credits 额度与有效期。一个席位最终能做什么，取决于角色、店铺分配、连接器权限、审批规则、额度和有效期的最小交集，不能继承浏览器中碰巧存在的更大权限。

Tenant Admin connects store
  -> server-side credential reference
  -> seat receives scoped AccessGrant
  -> tenant + store + role + action + credit check
  -> approval when required
  -> AuditEvent + CreditLedgerEntry
  -> read-back verification or explicit revoke state

企业版状态边界：以上是实施时必须达到的控制标准，不代表席位强制管控、完整审计、紫鸟等受管浏览器安全、额度分配或自动离职撤权已经上线；本系统也不能为第三方浏览器的安全性作保证。审计只能覆盖本系统观察到或发起的动作，绕开本系统的直接平台操作仍需依赖对应平台日志；credits 上限只约束本系统额度，不等于限制广告花费或第三方费用；只有所有连接系统都回读确认后，撤权才算完成。

8. 每日简报应在五分钟内读完

1. 自有站红灯：需要优先处理的页面、结账、库存、埋点或连接器问题。
2. 外部重点变化：与当前业务最相关的竞品网站、社媒、媒体和公开广告动作。
3. 自有表现背景：店铺真实交易结果，以及标明归因口径与成熟度的平台数据。
4. 评论与搜索缺口：把最新高频用户表达对应到自己的搜索词、PDP 或 Listing 优化假设，但不自动改写线上内容。
5. 最多三个动作：今天该修什么、测试什么或继续观察什么，并写清负责人、依据与验收指标。
6. 团队管控异常：角色或席位变更、即将到期的授权、越权尝试、重要操作、credits 相对配额的使用情况，以及尚未完成的撤权。
7. 数据边界：今天哪些来源受限、过期、不支持或尚未配置。

如果本次成功采集为零，日报只能输出访问受限告警；不得把历史信号重新包装成今天的新竞品结论。

9. 先只读采集，真实执行必须经过审批

• 可以自动完成：合规读取、快照、哈希、规范化、变化比较、计算、本地报告，以及发送到预先批准目的地的告警，但不得超出当前席位所属企业、店铺和数据源范围。
• 必须人工批准：修改网站、价格、库存、内容、广告预算、竞价、受众、活动状态，以及对外联系或发布；操作者、审批人和回验结果都要进入审计日志。
• 不共享凭证：子席位不能查看、导出或复用其他席位的密码、令牌、Cookie 或浏览器会话；拿到浏览器环境不等于获得店铺权限。
• 不隐形消耗 credits：付费任务必须计入已批准的席位、店铺或项目配额；达到上限后停止付费步骤或请求管理员批准，不得静默加购。
• 不盲发、不伪造身份：达人批量建联必须去重、限频、遵守停止联系名单，并在发送前保留审核。多模态定制可以按达人公开受众语境改写真实 SKU 叙事，但不得克隆达人脸部或声音、伪称既往合作，也不得虚构使用经历。
• 不绕过访问控制：不绕登录墙、验证码、私密账号、robots 规则或平台限流。
• 不编造竞品成绩：投放时长、点赞量或素材重复使用，不能证明花费、销量、转化、盈利或“爆款”。
• 当前状态：本页是已经整理完成的系统设计规范，不声称其中每个 API 连接器、定时任务或交付集成都已经部署。

主要平台依据

• YouTube Data API — Channels
• Meta — Instagram Business Discovery
• Meta Ad Library
• TikTok Commercial Content API
• Google Ads Transparency Center
• Shopify Admin GraphQL — Orders
• GA4 — Reporting data expectations
• Google Search Console — Performance data