TikHub 行为数据架构评审 · 会议介绍
Platform e2ea1b8a / TikHub_API 80132ea8；核对工作区代码，未验证生产部署。Crawler Gateway、Billing Gateway 尚未独立读仓，跨仓接口须负责人确认。
开发拆解与验收提案；22 项任务均待实施，不代表业务代码已修改或生产权限已生效。

1. 我们要做什么（40 秒）
这套系统先解决 TikHub API 接入新 Platform 后的三个问题：用户卡在哪一步、哪些账户需要内部运营跟进、哪些异常值得人工调查。它只供 TikHub 内部授权员工使用。卖家不能看行为明细、聚合、画像和导出，包括卖家自己的行为数据。公开演示全部是合成样本，生产采集和权限还没有落地。

2. 为什么先做权限（50 秒）
我们不从一张漂亮看板开始接真实数据。第一批四个任务先复用员工会话、团队权限和 MFA，再补分析数据范围、受控查询、导出撤权和拒绝测试。隐藏菜单没有安全作用，后台接口必须逐次判断当前员工身份和授权。OpenPanel 放在私网，只由 TikHub 服务端查询。普通用户、组织 Key、卖家会话或卖家 App Key 都不能获得读取权。

3. 抓包防不防得住（60 秒）
我们不能阻止用户查看和修改自己设备发出的请求，也不能把永久秘密藏在 JavaScript 里。我们的目标是：即使抓包、改包和重放，也不能越权、改余额、制造充值、骗取活动资格或直接触发处罚。浏览器只报告低信任体验信号；身份由服务端绑定，资金和业务结果来自拥有事实的服务。服务间再用 TLS、工作负载身份、签名、时间窗和 nonce 防篡改重放，用稳定事件 ID 防重复统计。加密保护机密性，签名保护来源与完整性，两者都不自动证明业务内容真实。

4. 用一个真实 TikHub 场景讲清楚（60 秒）
以 /api/v1/douyin/web/fetch_one_video_by_share_url 为例。用户打开文档、复制 Key，这些是可缺失、可伪造的前端线索。真正调用接口后，API 记录执行结果，Platform 提供可信操作人、付款账户和最终结算。这个接口对已删除或受限作品也可能返回 HTTP 200 并正常计费，所以请求完成、取得可用作品、首次激活、实际扣费必须分开统计。浏览器把点击改成已充值，不会进入资金事件入口；把组织改成别人，也不能改变服务端绑定的归属。

5. 怎样证明能落地（60 秒）
按依赖执行 22 个任务：内部访问边界；职责、指标与身份；一个 API 的服务端闭环；质量、出口与删除；最后故障、负载和异机恢复。每项都有代码模块、责任角色和可复现验收。验收不仅看成功请求，还要停 OpenPanel、撤销员工、重复消息、制造篡改、恢复旧备份。分析故障不能影响资金；删除过的数据不能在重放后回来。现有签名和日志可借鉴，但防重放、可靠分析队列和新的压测链都需要补建。

6. 这次会议需要决定什么（40 秒）
请确认第一批 T01 至 T04 的负责人，同时让 Platform、API、Crawler Gateway 和 Billing Gateway 负责人确认契约。产品确定可用结果和首次激活的口径，运维与业务共同批准容量、性能增量、保留期、成本及 RPO/RTO 目标。九项 P0 目前都未关闭；只有测试证据和责任人验收齐全，才开放内部受控真实数据试点。运营自动触达和风险处置另有启用门槛，不随看板上线自动开启。

会议入口：https://tikhub-behavior-blueprint.pages.dev/#meeting
任务拆解：https://tikhub-behavior-blueprint.pages.dev/#delivery
场景演示：https://tikhub-behavior-blueprint.pages.dev/#trust

参考依据：
OWASP：前端逻辑不能承担安全信任边界：https://cheatsheetseries.owasp.org/cheatsheets/Web_Frontend_Security_Cheat_Sheet.html
OWASP：REST 接口的认证、授权和输入校验：https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
RFC 9421：HTTP 消息签名与重放防护：https://www.rfc-editor.org/rfc/rfc9421.html