千川素材中心设计理念

01版本定位

这份文档不是“千川工作台功能介绍”。

如果只从功能看，它会被拆成素材录入、任务卡、授权查询、计划匹配、追投筛选、巡查规则、飞书回写、小火龙执行、卡审申诉、发布证据等模块。

但从业务设计看，它其实在解决一个更大的问题：

如何把达人素材投放中大量依赖人脑、群消息、表格和后台来回切换的工作，升级成一套可量化、可解释、可审计、可迭代的投放素材经营系统。

因此，这份文档要回答的不是“页面上有什么按钮”，而是：

• 为什么不能继续只靠微信群、飞书表和投手个人经验。
• 为什么千川素材中心不能做成一个简单的“自动加素材工具”。
• 为什么 ROI、消耗、预算、授权、卡审、计划状态、素材身份必须被统一建模。
• 为什么真实写入必须分层验证、显式确认、写后回读。
• 为什么运营反馈不能停留在群里，而要变成规则和状态机的一部分。

这个版本适合用于业务评审、产品对齐、技术方案共识和后续页面/文档化呈现。

02先给业务一个最准确的定义

我们要做的不是一个“千川自动化脚本”。

也不是一个“投放素材表格”。

更不是一个“帮投手点后台按钮”的工具。

我们要做的是一个：

千川素材中心。

它的本质是：

把达人素材投放中的素材、任务、计划、账户、ROI、预算、授权、审核、追投、执行和回写，从“人工分散处理”，升级成“统一任务卡承接、系统量化筛选、人机协作确认、受控执行落地、结果回读复盘、规则持续进化”的完整业务闭环。

更业务化地说，它帮助团队回答这几个问题：

• 这条素材是不是值得进入投放任务池？
• 它是老达人新素材，还是新达人新计划？
• 它应该走老计划加素材，还是新建计划？
• 它当前授权是否满足？缺的是抖音号授权、全域授权，还是商品可投条件？
• 它在今天、本月、近 7 天、近 30 天的消耗和 ROI 怎么样？
• 它是样本充足的好素材，还是小消耗虚高？
• 它应该追投、加预算、继续观察、止损，还是转随心推补量？
• 它是否卡审？卡审是素材级失败，还是计划状态可投但素材仍未通过？
• 它以前有没有被追投过、申诉过、回写过、人工处理过？
• 系统这次推荐它，是依据什么规则、什么数据、什么快照时间？
• 如果投手推翻系统判断，原因是什么，下一轮规则应该怎么变？

所以，这个中心真正要沉淀的不是“素材链接”，而是：

团队对素材投放的判断能力、执行能力、验证能力和迭代能力。

03这个中心的核心价值：把每日投放劳动变成组织资产

现在千川素材投放里最核心的问题，不是没有素材，也不是没有投手，而是：

素材、计划、数据和判断太分散，很多劳动每天重复发生，但没有变成组织资产。

过去投手每天要做的动作大概是：

打开群消息或飞书表
-> 找素材和达人信息
-> 进千川户
-> 搜计划 ID 或计划名
-> 看素材/计划消耗和 ROI
-> 判断是否追投、加预算、关停或转随心推
-> 手工填写预算、时长和执行时间
-> 手工执行
-> 再回填结果或在群里反馈

这条链路不是一次性的，而是每天反复发生。

这个中心的价值，不只是省几步操作。

它真正改变的是：过去投手的很多判断只存在于人脑和聊天记录里，系统化之后会变成任务卡、规则、阈值、状态机、动作账本、审计和复盘记录。

这样一来：

• 新人接手时，不只看群聊天，而是看任务卡和规则。
• 负责人看问题时，不只听“我处理了”，而是看状态账和回读证据。
• 工程定位问题时，不靠截图猜，而是看动作账本和 final_status。
• 规则调整时，不靠感觉，而是看误报、漏扫、样本门槛和反馈原因。

最终，每天投放运维的重复劳动会变成可复用的组织资产。

04我们设计的不是“替代投手”，而是“放大投手判断”

千川素材中心绝对不是要让投手退出投放。

相反，它要做的是：

把投手从“找信息、查数据、复制字段、反复点后台”的低价值劳动里解放出来，让投手更多参与真正有价值的判断。

机器应该做什么

机器适合做重复性强、标准明确、需要大量记忆和计算的事情：

• 批量读取任务卡、飞书表、历史任务池和千川快照。
• 识别素材链接、视频 ID、素材 ID、内容 ID、商品 ID、达人 ID、计划 ID。
• 查询抖音号授权、全域授权、商品可投、计划状态、素材审核状态。
• 按 today、本月、近 7 天、近 30 天、自定义周期计算消耗、GMV、ROI、订单、完播率。
• 判断 ROI 是否超过目标，消耗和订单是否达到样本门槛。
• 判断是否重复追投、是否冷却期内、是否已人工处理。
• 生成可追投、观察、止损、样本不足、缺授权、缺计划、卡审等标签。
• 生成追投任务篮、执行草稿、申诉草稿、飞书回写 dry-run。
• 记录执行动作、外部响应、回读结果、失败原因和审计证据。
• 汇总扫描账、状态账、排除账，帮助团队对账。

人应该做什么

人做目标判断、边界判断、策略判断和最终责任判断：

• 判断当前阶段更看重消耗放量、ROI 稳定、素材供给，还是风险控制。
• 决定某类素材是追投、观察、止损，还是转随心推。
• 判断中等置信度素材到底要不要进入任务篮。
• 判断高风险动作是否值得真实执行。
• 确认预算、时长、执行时间、目标 ROI 等关键参数。
• 审核系统提出的规则调整建议。
• 结构化填写人工覆盖原因，纠正系统误判。
• 决定哪些能力可以从只读升级到单卡真实执行、小批量执行或规则触发执行。

过去，投手要看很多素材和计划，靠脑子记哪些能追、哪些不能追。

未来，系统先把任务压缩成几个队列：

• 今日可追投素材。
• 今日止损观察素材。
• 样本不足但值得观察素材。
• 授权或字段缺失素材。
• 卡审或申诉复检素材。
• 已处理但待回读动作。
• 规则与人工判断冲突的边界样本。

人的工作从“从头找完所有信息”，变成“审最关键的判断点”。

这不是降低人的价值，而是把人的价值放在更高的位置。

05整个千川素材中心的业务闭环

千川素材中心可以理解为一条完整链路：

素材进入任务卡
-> 素材身份识别
-> 授权/账户/计划匹配
-> 投放数据自动取数
-> ROI/消耗/预算/审核状态量化
-> 规则扫描与候选分级
-> 追投/止损/申诉/随心推动作建议
-> 投手确认或受控执行
-> 写后回读与审计留痕
-> 规则、阈值和素材策略更新

这条链路里，有些节点是执行层，有些节点是策略层。

执行层包括

• 素材录入。
• 飞书 Sheet 同步。
• 千川 API 取数。
• 执行草稿生成。
• 老计划加素材。
• 新建计划。
• 预算调整。
• 申诉提交。
• 飞书回写。
• 小火龙随心推交接。

这些可以逐步自动化。

策略层包括

• 如何判断一条素材是否进入任务池。
• 如何判断它是否具备投放条件。
• 如何判断 ROI 是真实有效还是样本太小。
• 如何判断它该追投、观察、止损还是转随心推。
• 如何判断卡审结果是否足以关闭旧处理单。
• 如何判断一次执行是否已经真的成功。
• 如何把误报、漏扫、跳过原因反哺规则。

真正需要设计的，是这些决定质量的策略节点。

所以这个中心的核心，不是“让自动化跑起来”，而是：

让自动化跑在正确的业务判断和验证机制之上。

06第一层素材进件与任务卡

1. 这个环节做什么

素材进件是整个中心的入口。

素材可能来自：

• 微信群或飞书群里发来的达人素材链接。
• 飞书表格里维护的长线追投计划。
• 历史 API 反查出来的候选素材。
• 已经在千川投放过的素材。
• 人工调控素材表。
• 当日关闭但有消耗、需要转随心推重建的计划。

过去这些素材进入团队视野时，经常只是聊天记录、表格行、后台截图或计划名。

在中心里，它们首先要被标准化为一个业务对象：

素材任务卡。

2. 为什么这么设计

如果没有任务卡，各部门就会围绕不同的事实协作：

• 媒介看群消息。
• 投手看千川后台。
• 负责人看飞书表。
• 工程看日志。
• 运营看截图。

这些事实很难对齐。

任务卡的价值，是把“这条素材为什么要投、怎么投、投到哪里、当前卡在哪、最后结果如何”全部挂到同一个对象上。

3. 人在这里做什么

媒介和商务负责补齐人类最容易知道、系统最难凭空知道的字段：

• 达人昵称。
• 抖音号。
• 商品。
• 商品链接。
• 合作码。
• 特殊备注。
• 授权线索。

投手不再从群消息里重新整理基础字段，而是在任务卡上继续处理计划匹配和执行。

4. 这个环节的产出

这个环节最终产出：

• 一张素材任务卡。
• 一个明确的来源。
• 一组缺字段提示。
• 一个当前负责人。
• 一个下一步动作。
• 一个可继续进入授权、计划匹配和投后数据刷新流程的业务对象。

任务卡不是表格行，而是千川素材中心的最小协作单元。

07第二层素材身份识别

1. 这个环节做什么

素材身份识别解决的是“这到底是哪条素材”的问题。

它要识别：

• 素材链接。
• 视频 ID。
• 素材 ID。
• 内容 ID。
• 达人昵称。
• 抖音号。
• 达人 ID。
• 商品 ID。
• 商品链接。
• 计划 ID。
• 计划名称。
• 千川账户。
• 广告主 ID。

2. 为什么这么设计

千川投放里很多错误，不是规则判断错，而是身份识别错。

比如：

• 同一个达人改名后，被当成新达人。
• 同一个商品有多个链接，被当成不同商品。
• 同计划名跨账户出现，被误套老计划。
• 只有计划名没有计划 ID，导致搜索结果误采纳。
• 只有视频链接没有素材 ID，导致执行后无法做强回读。

所以中心必须先建立“素材、达人、商品、计划、账户”的统一身份体系。

3. 系统怎么判断

系统遵循几个原则：

• plan_id 优先，plan_name 只能辅助，不能跨账户套老计划。
• material_id/video_id 优先，计划级统计只能作为兜底，并且必须显性标注。
• 同账户内查找候选计划，禁止自动采用跨账户候选。
• 本地派生表可以提高体验，但不能成为唯一事实源；官方原始响应里的关键业务字段必须作为兜底。
• 如果派生字段缺失，系统要说明缺什么、从哪里能补，而不是静默跳过。

4. 这个环节的产出

它产出的是：

• 一个可追踪的素材身份。
• 一组与达人、商品、计划、账户的映射。
• 一个是否疑似重复或同源变体的判断。
• 一个后续可用于取数、执行、回读和复盘的主键体系。

身份识别是整个中心的地基。地基错了，上层 ROI、追投、卡审、回写都会错。

08第三层授权、账户与计划匹配

1. 这个环节做什么

这个环节解决的是：

这条素材有没有资格被投，应该投到哪个账户，走老计划还是新建计划。

系统要判断：

• 抖音号授权是否满足。
• 全域投放授权是否满足。
• 商品是否在该账户可投。
• 计划是否属于该账户。
• 老计划是否可用。
• 没有可用老计划时，是否进入新建计划草稿。

2. 为什么这么设计

授权不能用一个字段简单判断“已授权”。

实际业务里，至少有三类状态要拆开：

如果把这些状态合成一个“授权生效”，就会导致误判。

3. 人在这里做什么

系统负责查证据，投手负责确认方案。

投手看到的不是一堆接口返回，而是：

• 推荐老计划加素材。
• 推荐新建计划。
• 退回补信息。
• 授权缺失。
• 账户不匹配。
• 商品不匹配。
• 计划状态异常。

投手根据证据选择下一步，而不是手工进户搜索。

4. 这个环节的产出

它最终产出：

• 授权状态。
• 可用老计划候选。
• 新建计划草稿条件。
• 计划匹配证据。
• 风险提示。
• 下一步执行动作。

这个环节不要求系统 100% 替投手拍板，但必须把证据摆清楚。

09第四层投放数据理解

1. 这个环节做什么

投放数据理解解决的是：

这条素材当前表现到底怎么样，数据口径是否足以支撑动作。

系统要自动刷新和计算：

• 今日消耗。
• 本月消耗。
• 近 7 天消耗。
• 近 30 天消耗。
• GMV。
• ROI。
• 订单数。
• 点击率。
• 转化率。
• 3 秒、5 秒、10 秒完播率。
• 平均播放时长。
• 预算使用比例。
• 最近统计时间。

2. 为什么这么设计

过去飞书表里的累计消耗、累计 GMV、累计 ROI 是有用的，但不能支撑所有判断。

投手需要的是不同周期下的判断：

• ROI 好时，看本月优质素材，找能继续放量的对象。
• ROI 不好时，看当天数据，找能救场的素材或该止损的素材。
• 长线追投时，要看素材从创建日至当前的累计表现。
• 规则巡查时，要看当日消耗、整体 ROI 和分时 ROI。

因此，任务卡主数据和每日效果快照必须拆开。

任务卡回答“它是谁”，效果快照回答“它在某个周期表现如何”。

3. 系统怎么判断

系统按周期聚合效果快照，而不是直接依赖任务卡上的累计字段。

窗口包括：

• 今天。
• 昨天。
• 本周。
• 本月。
• 近 7 天。
• 近 30 天。
• 自定义周期。

统计口径遵循：

• 优先素材级统计。
• 没有素材 ID 时，使用计划级兜底，并标注“计划级兜底”。
• ROI 优先用千川同口径字段。
• 若只有消耗和 GMV，按 GMV / 消耗计算，并标注计算口径。
• 统计起点优先素材创建日期，其次计划创建日期。
• 缺少关键字段时，进入待补字段，而不是凭空取窗口。

4. 这个环节的产出

它产出一份素材投放表现画像：

• 当前表现。
• 周期表现。
• 样本是否足够。
• 是否超过目标 ROI。
• 是否触发止损。
• 是否预算不足。
• 是否存在口径兜底。
• 是否需要人工确认。

数据理解不是报表，而是后续追投、止损、巡查和预算动作的判断依据。

10第五层量化决策模型

1. 这个环节做什么

量化决策模型把投手经验转换成规则变量。

它不问“我感觉这条不错吗”，而是问：

• 周期消耗是否达到样本门槛？
• 订单数是否足够？
• ROI 是否高于目标？
• 当前预算是否接近用尽？
• 是否连续分时异常？
• 是否处于冷却窗口？
• 是否已经追投过？
• 是否卡审或授权异常？
• 是否属于当前商品规则组？

2. 为什么这么设计

千川素材判断中最大的误区之一，是只看 ROI。

ROI 高不一定能追。

如果消耗太小、订单太少，可能只是样本不足。

消耗高也不一定该追。

如果 ROI 低于目标，可能应该止损。

计划状态正常也不一定素材能投。

如果素材审核未通过，就不能把计划可投当素材成功。

所以，中心必须把判断拆成多变量组合，而不是单指标拍板。

3. 决策变量

4. 这个环节的产出

它产出的不是一个简单分数，而是一组可解释判断：

• 推荐追投。
• 推荐观察。
• 推荐止损。
• 样本不足。
• 授权不足。
• 计划异常。
• 卡审处理。
• 规则排除。
• 需要人工确认。

每个判断都必须有原因，而不是只有结论。

11第六层候选扫描

1. 这个环节做什么

候选扫描负责从大量计划和素材里，找出“值得业务看一眼”的少数。

它扫描的不是单一列表，而是多个来源：

• 中台线上任务卡。
• 历史 API 反查候选。
• 飞书调控素材表。
• 飞书投放总表。
• 长线追投任务表。
• 当日关闭但有消耗的计划。
• 卡审或申诉复检对象。

2. 为什么这么设计

人工每天从全量里找候选，是最耗注意力的工作之一。

但候选扫描如果只给一个总数，也会制造混乱。

比如系统说“命中 21”，页面显示“当前 7”，投手手里有“12 个”，如果没有解释已建、已忽略、待处理、规则排除、疑似漏项，大家只能在群里反复截图对账。

所以候选扫描不只是“扫”，还要“解释”。

3. 系统怎么判断

候选扫描必须同时输出：

• 本次按什么规则扫描。
• 数据快照时间是什么。
• 扫到多少条。
• 可操作多少条。
• 已生成草稿多少条。
• 已完成多少条。
• 已忽略多少条。
• 失败多少条。
• 被排除的主要原因是什么。
• 每个排除原因能否展开样本。

尤其是 skipped reason，不能只有聚合数字。

它必须能展开到样本，区分：

• 规则正确排除。
• 系统证据链缺口。
• 官方快照存在但本地未入池。
• 官方快照不存在。

4. 人在这里做什么

投手不再靠截图和记忆对账。

当投手手里有一份名单时，可以粘贴计划名或达人名，系统输出：

• 已在候选池，当前状态是什么。
• 被规则排除，排除原因是什么。
• 官方快照存在但本地未入池，疑似系统漏项。
• 官方快照不存在，可能不在当前扫描范围或数据未刷新。

人的工作从“帮系统找漏项”，变成“验证业务名单和系统扫描的差异”。

5. 这个环节的产出

它产出：

• 候选池。
• 扫描账。
• 状态账。
• 排除账。
• 疑似漏项清单。
• 规则排除样本。
• 业务名单对账结果。

候选扫描的目标不是多，而是准、可解释、可对账。

12第七层追投筛选与任务篮

1. 这个环节做什么

追投筛选回答的是：

哪些素材值得继续加码，哪些素材应该观察，哪些素材应该止损。

系统通过时间周期、消耗、ROI、样本门槛、账户、商品、达人、任务状态、计划状态、授权状态、发布时间等条件筛选候选。

2. 为什么这么设计

追投不是全量自动执行。

系统负责筛选和解释，投手负责选择。

这一点非常关键。

如果系统把所有命中规则的素材都追投，就会误伤：

• 样本不足但 ROI 虚高的素材。
• 授权不完整的素材。
• 已经追投过、还在冷却期的素材。
• 商品不在当前策略范围的素材。
• 已经人工处理过但系统没记住的素材。
• 高风险但仍有价值、需要人判断的素材。

3. 系统怎么判断

追投筛选分几个典型策略：

4. 人在这里做什么

投手看到的不是一堆原始数据，而是筛选结果和推荐原因：

• 本月 ROI 高于目标，且样本充足。
• 今日消耗达门槛，但 ROI 低于目标。
• ROI 高但消耗太低，样本不足。
• 计划可投但授权异常。
• 已在近 N 小时追投过，冷却期内。
• 商品不在当前规则组。

投手从结果中勾选进入“追投任务篮”。

任务篮里可以：

• 标记准备追投。
• 生成追投执行草稿。
• 标记人工已追投。
• 退回观察。
• 标记不追，并记录原因。

5. 这个环节的产出

它产出：

• 追投候选列表。
• 推荐标签。
• 推荐原因。
• 追投任务篮。
• 人工选择记录。
• 不追原因。
• 执行草稿。

追投筛选的价值，是把“投手从全量里找机会”变成“投手在系统压缩好的候选里做判断”。

13第八层长线追投任务表

1. 这个环节做什么

长线追投任务表承接的是长期反复追投或调控的对象。

它不是每天人工查数据的表，也不是系统凭空自动发现所有任务的替代品。

它是：

长期要追投的对象池。

当前口径是：

运营/投手先把长期要追投的计划或素材录入飞书表
-> 中台同步表格
-> 中台通过千川 API 自动统计消耗和 ROI
-> 投手补预算、时长、执行时间
-> 中台生成追投建议或进入执行队列

2. 为什么这么设计

系统不能凭空知道哪些计划属于业务想长期追投的对象。

完全自动发现会涉及误伤：

• 把不该追投的计划纳入。
• 把已关闭的计划纳入。
• 把低质素材纳入。
• 把无授权素材纳入。
• 把非目标商品纳入。

所以 P0/P1 阶段，业务先录入长期对象，系统负责后续查数、判断和生成建议。

后续 P2/P3 才考虑：

系统按规则自动发现长线候选
-> 自动加入待确认池
-> 投手批量确认
-> 进入长线追投任务表或执行队列

3. 系统怎么判断

长线追投表的核心字段包括：

• 千川账户。
• 计划 ID。
• 计划名称。
• 素材消耗。
• 素材 ROI。
• 追投预算。
• 时长。
• 任务执行时间。

建议补充：

• 小组。
• 商品。
• 素材 ID / 视频 ID。
• 素材创建时间。
• 任务状态。
• 执行结果。
• 最近统计时间。

统计数据按钮负责：

• 读取选中行或全表有效行。
• 校验账户、计划、素材字段。
• 调千川 API 查计划与素材数据。
• 计算素材创建日至当前的消耗和 ROI。
• 写入中台任务库。
• 可选回写飞书表格。

执行表格按钮负责：

• 读取待执行行。
• 校验追投预算、时长、执行时间。
• 做执行前预检。
• 未到执行时间时进入定时队列。
• 需要立即执行时生成草稿或受控执行。
• 回写状态和结果。

4. 人在这里做什么

运营或投手负责录入“长期要追投的对象”。

投手负责补预算、时长、执行时间，并确认是否进入执行队列。

负责人负责看长期任务的预算风险、执行结果和异常。

5. 这个环节的产出

它产出：

• 长线追投任务库。
• 每日刷新结果。
• 可追投、预算不足、需关停、需观察、字段缺失等标签。
• 执行草稿。
• 到点任务队列。
• 回写结果。

长线追投表的意义，不是让人继续维护一张表，而是把表变成中台任务池的入口。

14第九层巡查规则与商品分组阈值

1. 这个环节做什么

巡查规则负责把“什么时候提醒、什么时候观察、什么时候触发异常”配置化。

它回答：

• 哪些账户参与巡查？
• 是否推飞书提醒？
• 冷却时间是多少？
• 当日消耗达到多少才触发？
• 整体 ROI 低到什么程度提醒？
• 分时消耗和分时 ROI 怎样触发？
• 老品和新品是否使用不同阈值？
• 哪些商品归老品组，哪些归新品组？

2. 为什么这么设计

如果巡查规则写死在代码里，业务只能找工程改阈值。

但千川业务规则会变化：

• 不同商品目标 ROI 不同。
• 新品和老品容忍度不同。
• 某个阶段更看重放量，另一个阶段更看重 ROI。
• 全部户开启后提醒量会暴涨，需要调冷却时间和合并提醒。

因此，巡查规则要从固定代码升级为业务可维护的配置。

3. 系统怎么设计

页面包含几块：

商品选择不能让运营手写商品 ID。

它应该以商品卡片展示：

• 商品图。
• 商品名。
• 商品 ID。
• 店铺。
• 任务数。
• 账户数。
• 计划数。
• 素材数。

同一个商品只能属于一个分组，避免同时命中老品和新品规则。

4. 人在这里做什么

运营或负责人维护规则。

系统给提醒量预估和触发样例，帮助业务判断规则是否太松或太严。

工程不直接决定 ROI 门槛，但要保证规则可维护、可解释、可回滚。

5. 这个环节的产出

它产出：

• 当前组巡查规则。
• 商品分组。
• 提醒量预估。
• 触发样例。
• 冷却状态。
• 合并提醒摘要。

这个环节只影响提醒和巡检摘要，不触发千川、小火龙或飞书真实写动作。

15第十层卡审、申诉与复检

1. 这个环节做什么

卡审和申诉处理的是素材审核异常。

它要回答：

• 哪些素材审核未通过？
• 哪些处理单应该保留？
• 哪些旧处理单应关闭？
• 是否需要申诉？
• 申诉是否已经提交？
• 申诉结果是否回读？
• 是素材通过，还是只是计划可投？

2. 为什么这么设计

卡审链路里最容易出现“假成功”。

比如计划状态显示 DELIVERY_OK 或 ENABLE，只能说明计划可投，不能说明素材审核通过，更不能说明申诉成功。

所以卡审必须三源分离：

3. 系统怎么判断

卡审状态机遵循：

candidate
-> active_reject
-> probe_failed
-> passed
-> closed

禁止流转：

• plan_delivery_ok -> material_pass。
• submit_success -> appeal_success。

也就是说：

• 计划在投不等于素材通过。
• 申诉提交成功不等于申诉通过。

4. 人在这里做什么

系统负责巡检、生成处理单、回读素材详情和申诉结果。

投手或运营负责确认高风险和不确定样本：

• 是否继续申诉。
• 是否人工关闭旧卡点。
• 是否转人工处理。
• 是否补充素材 ID 或内容 ID。

5. 这个环节的产出

它产出：

• 卡审处理单。
• 申诉草稿。
• 复检结果。
• 素材级通过/拒绝证据。
• 计划级状态证据。
• 旧卡点关闭依据。
• 待人工确认样本。

卡审的核心不是“自动申诉”，而是“不要把错误状态解释成成功”。

16第十一层执行动作草稿与执行队列

1. 这个环节做什么

执行队列承接所有真实或半真实动作：

• 老计划加素材。
• 新建计划。
• 增加预算。
• 关闭或启停计划。
• 追投素材。
• 飞书指标回写。
• 官方申诉提交或复检。
• 小火龙 managed 类型执行或交接。
• 标记人工提交。

2. 为什么这么设计

如果前端按钮直接调用外部写接口，风险会非常大。

因为投放动作往往涉及：

• 真实预算。
• 真实广告状态。
• 真实账户。
• 真实商品。
• 真实外部平台。

所以，所有动作必须先进入执行队列，经过预检、确认、审计和回读。

3. 系统怎么判断

执行前必须校验：

• 千川账户是否映射到唯一广告主。
• 计划是否属于该账户。
• 动作类型是否开放。
• 预算和时长是否在规则范围内。
• 真实写开关是否开启。
• 请求是否带 confirm_write。
• 广告主是否在白名单或验证舱内。
• 去重窗口内是否已经执行过。
• 素材、视频、商品、授权是否完整。

如果不满足，进入草稿或预检失败，而不是下发。

4. 人在这里做什么

投手确认执行参数。

负责人决定是否开闸或扩大范围。

工程保证执行器稳定、接口契约正确、审计完整。

QA 验证状态机和回读。

5. 这个环节的产出

它产出：

• 执行动作。
• 执行草稿。
• 预检结果。
• 风险说明。
• 请求摘要。
• 外部响应摘要。
• 回读摘要。
• final_status。

执行队列的价值，是把“前端点击”变成“可审计、可复盘、可回滚的动作”。

17第十二层受控真实写入

1. 这个环节做什么

受控真实写入解决的是：

哪些动作可以真正写到千川、飞书或小火龙，在哪些条件下可以写。

真实写动作包括：

• 千川加素材。
• 千川新建计划。
• 千川增加预算。
• 千川关闭或启停计划。
• 千川申诉提交。
• 飞书指标持久回写。
• 小火龙随心推提交。

2. 为什么这么设计

这些动作不是本地保存，不是页面状态变化，而是会改变外部系统真实状态。

它们可能影响：

• 广告预算。
• 投放计划。
• 素材审核。
• 商品投放。
• 团队协作表。
• 业务结果。

所以不能因为“代码能跑”就自动开放。

3. 真实写入必须满足

所有真实写动作必须同时满足：

服务端写开关开启
+ 动作在允许范围内
+ 广告主在白名单或验证舱内
+ 请求显式确认真实写
+ preflight 通过
+ 产生审计日志
+ 必要时通知飞书
+ 写后回读

4. 人在这里做什么

投手确认单卡动作。

负责人确认小批量或规则触发执行。

Release Manager 控制发布和回滚。

业务 Owner 确认业务 canary 是否成立。

运营不负责发现接口、状态机、回读问题；运营只确认业务后台或页面上的业务状态是否符合预期。

5. 这个环节的产出

它产出：

• 真实写请求。
• preflight 证据。
• confirm_write 证据。
• 白名单或验证舱证据。
• 审计记录。
• 写后回读。
• 是否可进一步放量的判断。

受控真实写入的原则是：

慢一步可以接受，错一笔不可接受。

18第十三层飞书回写与组织协作

1. 这个环节做什么

飞书回写负责把中台结果同步到团队协作空间。

它包括：

• 指标表发现。
• 可回写字段识别。
• 完播率字段回写。
• 素材消耗和 ROI 回写。
• 状态和结果回写。
• 飞书提醒摘要。
• 发布证据摘要。

2. 为什么这么设计

飞书在业务里很重要，但它不是唯一事实源。

飞书适合：

• 录入。
• 协作。
• 对账。
• 人工查看。
• 结果同步。

但执行事实源应该在中台任务库和动作账本里。

否则一旦表格被人工改动、字段口径变化、公式变化，就很难判断真实状态。

3. 系统怎么做

飞书读取优先通过开放平台 API，不依赖浏览器登录态。

回写遵循：

• 先字段发现。
• 再 dry-run。
• 展示将写哪张表、哪一行、哪些字段。
• 单行灰度通过后再扩大。
• 持久写回开关默认关闭。
• 回写后做只读回读，确认目标表行和字段一致。

4. 人在这里做什么

业务同学通过飞书录入或查看。

投手确认任务和结果。

负责人看汇总和异常。

工程不把飞书 token、webhook、secret 暴露到前端或知识库。

5. 这个环节的产出

它产出：

• 飞书读取结果。
• 回写 dry-run。
• 单行灰度结果。
• 批量回写结果。
• 发布证据摘要。
• blocked claims。

飞书回写的意义，不只是同步数据，而是让系统每一步都进入组织视野。

19第十四层小火龙与随心推补量

1. 这个环节做什么

小火龙和随心推承接的是千川暂停、关闭或需要补量后的后续动作。

它可以处理：

• 随心推重建候选。
• 全域自动追投或复投规则草稿。
• 亏损关停规则草稿或 managed 执行。
• 商品、素材、ROI、预算、时长、任务名称、执行时间等参数。

2. 为什么这么设计

小火龙截图和页面路径是业务理解材料，不等于默认执行方案。

系统接入优先级是：

1. 正式合作接口或开放 API。
2. 受控 API 或内部适配器。
3. 登录态浏览器自动化兜底。

浏览器自动化只能作为兜底，并且必须白名单流程、截图留档、人工确认。

3. 系统怎么判断

小火龙链路必须拆开：

• 已提交。
• 投放记录出现。
• 最终生效。
• 最终失败。
• 待回读。
• 多次未匹配转人工。

不能把“已提交”直接说成“最终投放成功”。

4. 人在这里做什么

投手确认是否转随心推。

负责人确认真实提交范围。

工程保证接口或 managed 执行可控。

业务只验证后台业务状态是否符合预期，不承担基础集成 QA。

5. 这个环节的产出

它产出：

• 随心推重建候选。
• 执行参数。
• 小火龙 action。
• 待回读队列。
• 回读结果。
• 人工确认样本。

小火龙不是“自动乱跑的执行器”，而是被规则、合约和闸门约束的生产工。

20第十五层数据回流与效果复盘

1. 这个环节做什么

数据回流负责把执行后的效果重新送回中心。

它要分析：

• 追投是否有效。
• 加预算是否有效。
• 关停是否及时。
• 申诉是否成功。
• 飞书回写是否准确。
• 小火龙是否真正生效。
• 系统推荐是否被验证。
• 投手人工覆盖是否合理。

2. 为什么这么设计

如果数据回来后不学习，系统永远只是执行工具。

千川素材中心必须把每一次成功和失败都变成下一轮规则的输入。

3. 系统怎么分析

系统分析：

• 推荐追投后 1 小时、2 小时、次日效果。
• 未追投原因分布。
• 连续分时 ROI 异常。
• 高 ROI 可复用素材。
• 高消耗低 ROI 止损素材。
• 误报和漏扫样本。
• skipped reason 分布。
• 人工覆盖原因。

4. 人在这里做什么

投手反馈：

• 误报。
• 过早。
• 字段缺失。
• 阈值过松。
• 阈值过严。
• 人工已处理。
• 当前不适合。

负责人审核是否调整规则。

工程保证反馈结构化进入规则和测试。

5. 这个环节的产出

它产出：

• 复盘报告。
• 规则调整建议。
• 阈值校准建议。
• 产品分组调整。
• 新的测试样本。
• 旧错误防复发用例。

数据回流的目标，是让系统每跑一次，下一次更准一点。

21三张账机制：扫描账、状态账、排除账

候选扫描类自动化不能只发总数。

至少要同时给三张账：

这三张账解决的是一个很实际的问题：

系统看到的、页面展示的、投手手里的，经常不是同一个数字。

如果不拆账，所有人都会围绕数字争论。

拆账后，问题就能被定位：

• 扫描命中很多，但可操作少，是状态问题。
• 被排除很多，是规则问题。
• 官方快照有但本地没入池，是系统漏项。
• 投手名单不存在于官方快照，可能是范围或数据刷新问题。

每个 skipped reason 必须能展开样本。

否则“系统没扫到”无法区分是规则正确排除，还是系统证据链缺口。

三张账不是报表，而是生产自动化的可信基础。

22状态机与动作账本：不再把“已提交”当“已成功”

千川素材中心最重要的可靠性原则之一是：

已提交不等于业务成功。

接口返回 OK，只说明请求被接收。

真正的业务成功，必须由权威回读证明。

典型误区

统一动作账本

每个外部动作至少要记录：

• operation_id。
• action_id。
• entity_id。
• action_type。
• status / final_status。
• request_summary。
• external_response_summary。
• readback_summary。
• audit_ref。
• verification_level。

终态示例

前端只展示后端权威 read model，不自行推断成功或失败。

这能避免“页面看起来成功，但业务事实不成立”的假成功。

23验证舱与发布证据闸：自动化必须先证明自己

千川素材中心的自动化，必须先声明验证层级，再进入业务群反馈。

验证阶梯如下：

缺 L4 时，不能把业务群反馈当验证舱。

业务只能验证业务事实，不能承担基础集成 QA。

发布证据闸

发群前，系统应生成发布证据摘要：

• 千川写闸门状态。
• 验证舱配置。
• 小火龙待回读。
• 审计尾部。
• 当前验证等级。
• 哪些话不能说满。
• 业务同事需要验证的问题。

示例：

业务验证问题要被压缩为：

请只确认这条样本在业务后台/页面上的业务状态是否符合预期；接口可用性、写入安全和回读证据由工程侧负责。

这句话背后的分工非常重要：

运营验证业务事实。

工程证明系统正确。

QA 验证状态机和证据。

Release Manager 控制发布和回滚。

24整套中心背后的核心设计理念

整套千川素材中心背后有几条核心理念。

1. 一套事实

所有素材、任务、计划、账户、执行和结果最终回到一套任务卡和动作账本。

飞书是协作入口，千川是平台事实源，小火龙是受控执行通道，但中台数据库和审计账本是组织内部的执行事实源。

2. 量化优先

追投、止损、观察、提醒、回写都必须有可量化依据。

ROI、消耗、GMV、订单数、样本门槛、预算比例、周期窗口、审核状态、授权状态，都是判断变量。

3. 可解释优先

系统不能只给结论。

每个候选都要说明：

• 为什么进。
• 为什么没进。
• 当前在哪个状态。
• 下一个动作是什么。
• 是否安全可执行。

4. 受控执行

真实写动作不是页面按钮，而是受控生产动作。

它必须经过：

• 预检。
• 白名单。
• confirm_write。
• 审计。
• 回读。
• 验证等级。

5. 回读为准

提交成功不是业务成功。

只有权威回读匹配，才能进入 confirmed_success。

6. 反馈进化

误报、漏扫、跳过原因、人工覆盖、执行失败，都要回流成规则和测试。

系统不是上线后固定不变，而是每一轮运行后变得更准确。

25AI/系统助理机制：不是一个大脑，而是一组业务助理

千川素材中心不是让一个“大 AI”决定所有事情。

它更适合被设计成一组业务助理：

1. 进件识别助理

它解决的问题：

群消息、飞书行、素材链接里有很多非结构化信息。

它做什么：

• 识别达人、抖音号、商品、素材链接、视频 ID。
• 拆多条素材。
• 标记缺字段。
• 判断是否疑似重复。

人怎么参与：

• 补充系统无法确定的字段。
• 确认同源变体或重复。

2. 授权与计划匹配助理

它解决的问题：

投手不应逐户查计划和授权。

它做什么：

• 查授权状态。
• 查同账户计划候选。
• 给推荐理由和风险。
• 生成授权或新建计划草稿。

人怎么参与：

• 确认采用老计划、新建计划，还是退回补信息。

3. 数据刷新助理

它解决的问题：

每天人工查消耗和 ROI 太低效。

它做什么：

• 拉取千川数据。
• 更新日快照。
• 按周期聚合。
• 标注统计口径和兜底口径。

人怎么参与：

• 处理缺字段和异常口径。

4. 候选扫描助理

它解决的问题：

全量素材太多，投手不能每天从头找。

它做什么：

• 按规则扫描。
• 生成可追投、观察、止损、样本不足等队列。
• 输出三张账。
• 支持业务名单对账。

人怎么参与：

• 核对边界样本。
• 反馈误报和漏扫。

5. 追投策略助理

它解决的问题：

哪些素材该追，哪些该止损，需要系统压缩判断面。

它做什么：

• 按周期、ROI、消耗、订单数、预算比例生成建议。
• 生成追投任务篮。
• 输出建议预算和时长。

人怎么参与：

• 选择任务篮。
• 修改建议参数。
• 填写不追原因。

6. 卡审与申诉助理

它解决的问题：

素材审核、计划状态、申诉结果容易混淆。

它做什么：

• 三源裁决。
• 生成申诉草稿。
• 到期复检。
• 关闭旧卡点或转人工。

人怎么参与：

• 确认高风险样本和申诉动作。

7. 执行与回读助理

它解决的问题：

真实写动作必须有证据链。

它做什么：

• 做 preflight。
• 写动作账本。
• 执行后回读。
• 生成 final_status。

人怎么参与：

• 确认真实写。
• 处理 post_verify_failed 和 manual_review_required。

8. 复盘学习助理

它解决的问题：

数据回来后如果不学习，系统永远只是工具。

它做什么：

• 分析推荐是否验证成功。
• 分析规则误报和漏扫。
• 分析阈值是否过松或过严。
• 生成规则调整建议。

人怎么参与：

• 审核建议。
• 决定是否灰度。
• 决定是否回滚。

26人机协作机制：让人从执行者变成策略管理者

1. 高置信低风险自动处理

适合：

• 只读取数。
• 生成建议。
• 生成草稿。
• 更新本地状态。
• 生成提醒摘要。

系统自动完成：

• 数据刷新。
• 候选扫描。
• 标签生成。
• 三张账汇总。
• 草稿生成。
• 回读状态更新。

人只做抽检。

2. 中置信人工复核

适合：

• 样本门槛边界素材。
• ROI 高但消耗低。
• 授权状态不完整。
• 计划候选不唯一。
• 规则和人工经验冲突。
• 商品归组不确定。

人做什么：

• 看证据。
• 确认或否定。
• 选择追投、观察或止损。
• 填写结构化原因。

3. 高风险强制确认

适合：

• 增加预算。
• 关闭或启停计划。
• 新建计划。
• 小火龙真实提交。
• 飞书批量真实回写。
• 批量真实执行。

人做什么：

• 确认影响范围。
• 确认预算和时长。
• 确认白名单或验证舱。
• 确认 confirm_write。
• 确认回滚路径。

4. 人工覆盖必须结构化

投手可以推翻系统判断，但不能只写一句“我觉得”。

必须选择原因：

• 当前不追。
• 已人工处理。
• 规则误报。
• 规则漏扫。
• 样本不足。
• 授权异常。
• 商品不匹配。
• 外部已完成。
• 需要负责人确认。

人工覆盖不是绕过系统，而是让系统学习人的判断。

27规则配置中心：让投放经验可维护、可解释、可回滚

千川素材中心的规则，不能藏在代码里。

规则应该成为业务资产。

规则配置中心至少包括：

• 巡查规则。
• 商品分组规则。
• ROI 阈值。
• 消耗门槛。
• 分时 ROI 规则。
• 样本门槛。
• 追投预算规则。
• 关停规则。
• 冷却时间。
• 重复执行窗口。
• 飞书提醒开关。
• 真实写动作白名单。
• 验证等级策略。

为什么规则要可维护

因为业务阶段会变：

• 某阶段看重放量。
• 某阶段看重 ROI。
• 新品容忍低 ROI。
• 老品要求更稳定。
• 单户试跑和全组巡查提醒量完全不同。

如果规则写死，业务每次调整都要找工程。

如果规则可维护，业务可以通过预估和灰度调整策略。

为什么规则要可解释

每次提醒、追投、止损、排除，都要能说明命中了哪条规则。

否则运营无法信任系统，工程也无法定位误报。

为什么规则要可回滚

规则调整可能带来提醒量暴涨、误报增多或漏扫。

所以规则要版本化、可灰度、可回滚。

规则中心不是“配置页”，而是投放经验的操作系统。

28指标模型中心：让 ROI、消耗、预算和样本门槛可进化

指标模型中心解决的是：

用哪些指标判断素材价值，以及这些指标如何随业务阶段进化。

指标分层

样本门槛为什么重要

ROI 是核心，但不能孤立看。

低消耗高 ROI 可能是假象。

所以中心必须引入样本门槛：

• 最低消耗。
• 最低订单数。
• 时间周期。
• 是否达到客单价比例。

只有样本足够，ROI 才能成为追投依据。

指标模型如何进化

指标模型不是一次确定。

它通过反馈持续进化：

• 误报多，说明阈值过松。
• 漏扫多，说明规则过严或字段缺口。
• 样本不足却被推荐，说明样本门槛要上调。
• 某类商品持续误判，说明需要独立商品组。
• 外部写后回读失败，说明状态机或接口合约要补。

指标模型中心的最终目标，是让团队越来越清楚：

什么样的数据，真的值得动作。

29组织协作方式会发生什么变化

千川素材中心改变的不只是系统，而是组织协作方式。

媒介 / 商务 / 达人对接

过去主要在群里交接素材。

未来主要负责：

• 提供达人、抖音号、商品、素材链接。
• 补缺字段。
• 确认合作码和授权线索。
• 处理系统退回的待补信息。

他们不再反复被投手追问基础字段，而是在任务卡上把字段补全。

投手

过去主要做：

• 查计划。
• 查数。
• 搜素材。
• 手工追投。
• 手工回写。

未来主要做：

• 复核候选。
• 选择追投任务篮。
• 确认预算、时长、执行时间。
• 处理高风险动作。
• 结构化反馈误报和漏扫。
• 参与规则迭代。

投手从“后台操作员”，变成“投放策略判断者”。

负责人

负责人看到的不再是零散群反馈，而是：

• 今日新增素材。
• 待补字段。
• 待授权。
• 待匹配。
• 待执行。
• 卡审异常。
• ROI 异常。
• 追投候选。
• 预算风险。
• 执行结果。
• 规则误报和漏扫。
• 自动化覆盖率。

负责人不需要逐条点后台，而是管理规则、风险和优先级。

工程 / 总控

工程不直接决定业务规则。

工程要保证：

• API 可靠。
• Token 不泄露。
• 前端不接触密钥。
• 写动作有闸门。
• 状态机正确。
• 动作账本完整。
• 发布证据充分。
• 回滚路径明确。

QA / Release

QA 不靠运营截图替代测试。

Release Manager 不发布未过质量门的变更。

业务群不再承担第一轮 QA。

30各角色在中心里的职责

每个角色的边界越清楚，系统越能稳定运行。

31日常工作方式会变成什么样

每天早上

系统自动完成：

• 同步长线追投表。
• 刷新任务池。
• 拉取千川数据。
• 更新消耗、GMV、ROI、订单和完播率。
• 执行巡查规则。
• 生成可追投、观察、止损、字段缺失、卡审等队列。
• 生成三张账。
• 汇总飞书提醒。

投手打开中心，会看到：

• 今日需要动作的任务。
• 可追投候选。
• 止损观察候选。
• 授权或字段缺失任务。
• 卡审或申诉复检任务。
• 待回读动作。
• 规则冲突样本。

投手不用从头捞数据，而是处理系统压缩好的判断队列。

白天

投手主要处理：

• 中置信度候选复核。
• 高风险动作确认。
• 追投任务篮选择。
• 预算和时长确认。
• 卡审和申诉样本确认。
• 人工覆盖原因填写。

系统根据投手确认，进入草稿、执行队列、回写和回读。

执行后

系统自动做：

• 写动作账本。
• 回读外部状态。
• 更新 final_status。
• 写飞书或生成回写 dry-run。
• 汇总执行结果。
• 标记待人工确认样本。

每周复盘

负责人和团队看：

• 哪些规则误报最多。
• 哪些候选被漏扫。
• 哪些商品阈值需要独立。
• 哪些素材追投后有效。
• 哪些动作停在待回读。
• 哪些能力可以从 L0/L1 升级。
• 哪些真实写仍缺验证舱或 canary。

这时，复盘不再是“大家聊感觉”，而是围绕账本、指标和规则做调整。

32这个中心最终会实现什么效果

1. 对投手

• 少进后台重复查数。
• 少从群里翻字段。
• 少手工回写。
• 更快找到可追投素材。
• 更清楚知道为什么推荐或排除。
• 更容易处理卡审、授权、计划匹配等异常。

2. 对负责人

• 看清每日任务和风险。
• 看清规则是否有效。
• 看清自动化覆盖率。
• 看清真实写是否安全。
• 看清哪些规则需要调整。
• 看清业务群反馈是否有证据支撑。

3. 对工程和 QA

• 状态机清楚。
• 动作有账。
• 回读有证据。
• 发布有闸门。
• 失败可定位。
• 旧错可防复发。

4. 对组织

• 素材投放经验不再只存在于个人脑子里。
• 运营反馈不再只停留在群消息里。
• 每轮执行都能沉淀成规则、测试和复盘。
• 自动化不再靠业务群试错，而是靠验证阶梯逐级放量。

最终效果不是“少几个人”，而是：

同样的人，可以处理更大的素材规模、更复杂的账户结构和更高频的投放迭代。

33评审时最应该让业务达成共识的几个点

1. 这是素材中心，不是单点脚本

如果只当成加素材脚本，就会忽视任务卡、状态机、回读和规则沉淀。

2. 任务卡是统一事实对象

群消息、飞书、千川、小火龙、工程日志都要回到任务卡和动作账本。

3. ROI 判断必须带样本门槛

不能只看 ROI 高低，必须同时看消耗、订单数、周期和商品规则组。

4. 追投不是全量自动执行

系统筛选推荐，投手选择任务篮。真实写必须开闸。

5. 计划可投不等于素材审核通过

卡审链路必须三源分离。

6. 已提交不等于业务成功

只有权威回读匹配，才能说 confirmed_success。

7. 业务群不是验证舱

业务只能验证业务事实，不能替系统做基础集成 QA。

8. 规则调整必须可解释、可回滚

每次阈值和规则变化，都要有预估、灰度和复盘。

9. 小火龙不是默认点击路径

优先正式接口或受控 API，浏览器自动化只是兜底。

10. 已实现不等于已开放

接口接通、dry-run 通过、草稿生成，只说明基础可用；真实批量执行要按验证等级推进。

34建议的业务落地路径

阶段一：统一任务卡和只读数据

目标：

• 所有新素材进入任务卡。
• 任务卡字段可补全。
• 任务池可查询。
• 千川数据可只读刷新。
• 日快照可按周期聚合。

验收：

• 投手能从任务卡进入计划匹配和追投筛选。
• 系统能说明缺字段、缺授权、缺计划。
• 数据只读刷新稳定。

阶段二：追投筛选和三张账

目标：

• 可按周期、消耗、ROI、样本门槛筛选。
• 生成追投任务篮。
• 输出扫描账、状态账、排除账。
• 支持业务名单对账。

验收：

• 投手可以从候选池选任务，而不是全量查后台。
• 每个 skipped reason 可展开样本。
• 疑似漏项可定位。

阶段三：执行草稿和受控单卡真实执行

目标：

• 老计划加素材、新建计划、预算调整、申诉等动作进入执行队列。
• 默认草稿或 dry-run。
• 单卡真实执行需要 confirm_write、白名单、预检和审计。

验收：

• L0/L1 本地和状态机测试通过。
• L2 生产只读证据可用。
• 单卡 L4/L5 canary 有回读证据后再扩大。

阶段四：规则中心和反馈闭环

目标：

• 巡查规则可配置。
• 商品分组可维护。
• 误报、漏扫、跳过原因和人工覆盖可结构化回流。
• 规则可预估、可灰度、可回滚。

验收：

• 规则调整后提醒量可预估。
• 误报/漏扫有下降或可解释。
• 新规则不直接扩大真实写范围。

阶段五：动作账本和可靠性升级

目标：

• action_runs / action_events 统一。
• final_status 枚举稳定。
• 前端读后端 read model。
• 覆盖率证明、round model、release evidence 完整。

验收：

• 旧错均有回归测试。
• 提交成功和业务成功彻底分开。
• P2 自动执行天花板保持 L2，L3+ 继续单独授权。

阶段六：小批量放量和日常自动运转

目标：

• 在验证舱和业务 canary 通过后，逐步开放小批量真实执行。
• 对高置信低风险动作自动化。
• 对高风险动作保留人工确认。

验收：

• 连续样本通过。
• 监控、回滚、审计、待回读队列稳定。
• 业务 Owner 确认真实业务样本。

35最终一句话

千川素材中心不是把投手的工作自动点完。

它真正要做的是：

把达人素材投放从“人工查数、经验判断、分散执行、群里对账”，升级成“统一任务卡、量化筛选、人机确认、受控执行、权威回读、规则迭代”的组织级素材经营系统。

它改变的不是一个页面，而是一套工作模式。

过去，团队每天重新找素材、查计划、看 ROI、处理异常。

未来，系统每天自动形成候选、解释原因、保护写入、回读结果、沉淀规则。

人不再是流程里的体力执行者，而是策略、边界和最终责任的管理者。