# Media Ops > 跨平台媒体发布执行总控：按外部触发器扫描内容目标；供给不足时调用 media-loop 委托 media-core 生成和验收资产，再调用 X、小红书或抖音子技能完成平台化改编与发布，统一执行账号、事实、版权、安全、去重、结果核验和平台真实限流门禁。Use when Codex needs to directly publish a configured content target, execute an approved editorial workflow, recover an empty ready queue, or coordinate content production through publishing. For vague operating problems or permanent strategy changes, media-loop is the default entrypoint. Do not manage credentials or perform simple verbatim cross-posting. - Skill: `askairo/media-ops` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add askairo/media-ops` - Raw SKILL.md: https://api.skillmd.com/api/skills/askairo/media-ops/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: askairo (https://skillmd.com/u/askairo) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/askairo/media-ops --- # Media Ops 把账号目标、平台机制和内容主体转化为可执行的素材发现与发布任务，并协调平台子技能完成核验、筛选、改编和发布。外部自动化任务的 RRULE 是运行频率的唯一权威；配置不得再用目标计划时间、最小间隔、每日上限或媒体获取次数把一次已触发的运行挡掉。运营反馈由独立的 `media-loop` 负责；`media-ops` 只消费其经过证据支持的策略覆盖，不在发布流程中自行猜测效果原因。 `media-ops` 是发布执行层总控，不是运营策略层总控。直接发布请求、已明确的目标级执行任务和由 `media-loop` 路由来的配置落地任务进入本技能；“为什么效果差”“应该改哪个配置”这类未分类问题先交给 `media-loop` 诊断。`media-ops` 只能在用户明确授权长期生效时修改常驻执行配置，其他反馈只作为本轮或下一轮的临时覆盖。 涉及可复用内容资产时，先读取 [media-core](../media-core/SKILL.md) 的内容资产、证据卡、生命周期和分发目标规范；`media-ops` 负责调度和发布，不把平台账号配置写回内容资产的共同真相。 ## Resolve configuration 执行前读取 [configuration.md](references/configuration.md)，按其中的配置位置、模型、合并顺序和校验规则解析运行上下文；运行阶段、检查点和恢复规则遵守 `media-loop` 的 [runtime-contract.md](../media-loop/references/runtime-contract.md)。 若配置提供 `docsRoot`，将其作为外部运营文档根目录；按 `///` 读取和写入队列、发布历史、运行记录和复盘。外部文档是人类可读记录，本地状态是机器执行缓存；两者不一致时停止推进并记录待核对状态。 若平台 operation 提供 `editorialFrameworkRef`，先读取 `media-core` 内容层主题框架，再交给平台子技能做适配；若提供 `coverSpecRef`，只在需要生成或核验该平台账号视觉资产时读取。主题框架和平台视觉规范职责分离，不能把平台规则回写到内容层。 先做调度权威检查：内容优先模式下，每个内容 pipeline 只能由一个来源生产任务写入候选；统一扫描器和现有平台定时器都可以触发，但必须进入同一个 `media-ops` 决策入口，并共享 `contentId + targetId` 运行锁。平台定时器保留原有发布能力，资源为空时应调用 `media-loop → media-core` 有界补货，再回到对应平台子技能发布。发现触发器绕过全局决策、同一 pipeline 存在两个生产者、未持锁写入或内容层游标与平台队列互相宣称拥有顺序权时，返回 `scheduler_authority_mismatch`，不打开发布页、不上传、不点击发布。 配置采用“账号共性 → 平台 operation → 执行 strategy”的层级。`media-ops` 只负责解析和校验这套结构；平台推荐机制、发现关键词、候选信号和内容形态由对应子技能根据运行上下文决定。 1. 选择一个逻辑账号；一个逻辑账号只能代表一个品牌/运营主体。若存在多个账号且用户未指定，不要混合运行，先询问选择；不同定位、受众或内容支柱的账号即使属于同一用户，也必须分别运行。 2. 解析该账号启用的平台身份、平台风格、数据源组和执行策略。 3. 解析 `platformAccounts..browserProfileRef` 和平台 operation 的执行传输；浏览器平台必须先路由到绑定的 Chrome Profile，再核对平台公开身份。API 平台不需要 Chrome Profile。 4. 允许用户在本次请求中覆盖配置；仅覆盖本次运行，不自动回写配置文件。 - 本轮不再创建“频率豁免” lease；每次外部触发都是独立的尝试。仍不得把触发本身解释为关闭健康、事实、版权、去重、媒体可用性、平台真实限流或成功核验门禁。 5. 若缺少的信息只影响表现形式，采用保守默认值并列明；若缺少账号定位、来源、目标平台或浏览器 Profile 路由会改变执行对象，停止并返回具体缺失字段。 6. 不读取或保存密码、Cookie、访问令牌等凭证。Profile 配置只保存本机可见的环境标识和切换方式，不保存认证材料。 7. 形成运行上下文：账号定位、平台、运营目标、内容主体、受众、来源边界、平台目标、发布策略和浏览器 Profile 路由。上下文不完整且会改变选材结论时停止，不用通用热点替代。 8. 若存在有效的 `media-loop` 反馈，读取最近一次健康状态、策略版本、实验状态和未决门禁。账号被标记、限流或发布状态不明确时，先执行反馈中的暂停/降频要求；不得用新一轮内容覆盖账号健康风险。 ### Route the browser Profile - 浏览器平台的执行对象由 `platformAccountRef → browserProfileRef → platform handle` 唯一确定；同一平台的不同账号不得共用一个 Profile 路由。 - Chrome 浏览器操作只能使用配置的 `chrome-mcp`（Chrome MCP/browser-client）或 `playwright-mcp`（Playwright MCP Bridge）。`chrome-mcp` 先从 `openTabs` 定位目标 `profileName` 的已登录 Tab 并 `claimTab`；`playwright-mcp` 则要求用户先在目标 Profile 中启用 Bridge 并授权已登录 Tab。不得猜测或切换 Profile，也不得使用桌面点击、Computer Use、CDP、鼠标坐标点击或其他浏览器控制接口。 - 接管后重新打开平台入口，读取当前登录 handle、账号名和平台身份。任何一项与配置不一致、页面仍在旧账号或目标 Tab 不可确认时，立即停止，不创建草稿、不上传媒体、不发布。 - 两种通道均要求目标 Profile 的已登录 Tab 可确认；`chrome-mcp` 无可 `claimTab` 的 Tab 或 `playwright-mcp` 无 Bridge 授权 Tab 时，返回 `profile_route_missing`，不得创建未核验会话或在两种通道间静默回退。 - `switchMethod: chrome-mcp` 表示 Chrome MCP 识别并接管既有 Tab；`switchMethod: playwright-mcp` 表示用户授权既有 Tab 后由 Playwright MCP Bridge 接管；`current-session` 只表示沿用当前已确认的单账号 Tab，不能用于同平台多账号无人值守路由。 - 在提供 Unified Computer Use/`cua_repl` 的新版运行时中，`chrome-mcp` 对应 `cua.getState()` 返回的 `family: chrome`、`type: extension` 浏览器及其 `cua.getTab(...)` Tab API。使用该 Chrome extension Tab 的可访问页面读取、输入、上传和导航仍属于 Chrome MCP 通道，不是 Computer Use 回退；不得改用 `cua.getApp("Google Chrome")`、桌面坐标或原生窗口点击。旧版独立工具名不存在本身不能判定 `profile_route_missing`。 ### Resolve the execution transport - `operation.transport` 标识平台适配器；`interactiveSkill` / `scheduledSkill` 标识交给哪个平台子技能；`interactiveTransport` / `scheduledTransport` 标识该次运行实际使用的执行通道。 - `scheduledTransport` 对所有需要写入外部平台的定时任务都是必填。浏览器平台只允许显式的 `chrome-mcp` 或 `playwright-mcp`；API 平台必须选择已接入的 `official-api`。平台子技能可以进一步限制可用值。 - `chrome-mcp` 或 `playwright-mcp` 表示 Profile 路由、页面读取、输入、上传、编辑、发布控件、结果核验和 Tab 清理全部由同一已声明通道完成；不得在两者之间静默转换，也不得转换为 Computer Use、controlled-browser-session、CDP、鼠标坐标点击或其他 Chrome 控制接口。`official-api` 不打开 Chrome，必须由对应 API 子技能完成身份和结果核验。 - `switchMethod: chrome-mcp` 或 `playwright-mcp` 与 `interactiveTransport` / `scheduledTransport` 必须分别写入运行快照，但都不得指向其他浏览器执行器。 - 运行时预检先发现当前可用工具：若有 Unified Computer Use，则读取 browser inventory，选择 `family=chrome` 且 `type=extension` 的实例，再按目标站点 URL 取得既有 Tab；只有没有 Chrome extension browser/目标 Tab，或页面实读账号与配置不一致时，才返回 `profile_route_missing` / `account_mismatch`。不得仅检查旧工具名称后提前失败。 - Chrome extension inventory 不暴露 `profileName` 时，只有一个 extension browser、其中存在目标站点 Tab、配置 Profile 已验证且页面实读 handle 匹配，才能记录本轮 browserId / extensionInstanceId 并继续；多个 extension browser 无法映射到配置 Profile 时停止，不猜测。 - 缺少、拼写错误或当前平台不支持的传输不得静默回退；返回 `scheduled_transport_missing` 或 `scheduled_transport_unsupported`，不打开发布页、不上传、不点击发布。 - 运行记录必须写入 `activeTransport`、`interactiveTransport` / `scheduledTransport` 和 `browserProfileRef`，便于区分配置门禁、浏览器连接问题和平台发布问题。 ### Content-driven dispatch and Profile batching 当任务由内容分发触发时，先读取 `media-core` 内容资产和未完成的 `distributionTargets`，再解析每个目标的 `platformAccountRef`、平台策略和 `browserProfileRef`。定时器的执行对象是内容目标，不是某个平台技能本身；外部触发时间决定本轮是否尝试，不再等待目标的计划时间。 - 统一分发定时器和平台定时器都可以触发同一决策入口；触发器当前 RRULE 决定运行频率。`plannedAt` / `preferredWindow` 仅保留为排序、审计和内容计划信息，不是发布阻断条件。 - 在进入浏览器前，确认内容资产已经通过 `media-core` 的 ready admission check；扫描器不得把 `verified` 资产提升为 `ready`，也不得为缺少到期字段的目标临时补写发布时间。 - 对每个目标检查 ready 状态、账号身份、事实、版权、媒体、去重、运行锁、平台真实限流/挑战、失败中的不确定状态和 `media-loop` 健康门禁。不得再检查 `minIntervalMinutes`、`maxPublishedPerDay`、目标时间窗口或媒体获取次数。`maxPublishedPerRun` 仅是单次触发的批量保护，不是时间或频率门禁。 - 同一平台不同账号和同一账号不同平台仍分别记账；全局扫描器的 `maxTargetsPerRun` 只是单次触发的资源保护。平台返回的真实 rate limit、账号标签、挑战和安全暂停仍必须尊重，不能由配置关闭。 - 同一内容的多个目标可以覆盖不同平台、账号和格式；平台策略中的旧时间字段不再作为目标级阻断条件。 - 解析完目标后，先按 `scheduledTransport`，再按 `browserProfileRef` 分组，并在同一传输和 Profile 内尽量连续处理不同平台目标，减少路由切换；分组只改变执行顺序，不改变目标边界。 - 即使多个目标使用同一个 Profile，每个目标进入平台后仍必须重新核对公开账号身份。不能因为 Profile 已确认，就跳过 `platformAccountRef → platform handle` 校验。 - 一个 Profile 可以承载用户已确认登录的不同平台账号；同一平台的不同账号不得默认共用 Profile，除非平台支持可靠的账号切换且配置明确授权。账号不匹配、Profile 不明或切换后页面仍是旧账号时，立即停止该目标，不影响其他目标按独立状态处理。 - 每个目标独立写入 `publishState`、帖子 URL、指标和失败原因。不能把“同一内容部分平台成功”汇总成一次全局成功，也不能把一个平台失败扩散为所有目标失败。 - 同一账号的多个未完成目标按 `media-core.dispatchScheduler.targetSelection` 处理：选择最早 `plannedAt` 的未完成且 eligible 目标；同一时间再按 `targetCreatedAt`、`sourceObservedAt`、`targetId` 排序。不得因为新资源刚在另一个平台成功，就改选最新资源；已在小红书完成的目标不影响同一内容在抖音上的独立未完成目标。目标级不 ready/适配失败可以保留并检查下一条 eligible 目标，账号级健康阻断则暂停该账号队列。 ## Preflight and resume 进入来源访问、媒体上传或平台写操作前，先建立一次运行检查点，确认账号、目标、传输、来源证据、媒体状态、幂等键和运行锁。若同一 `contentId + targetId` 已有未完成运行： - 已明确发布成功、审核中或已写回：直接结束，不重复发布； - 已有草稿或上传产物：从最近的明确阶段继续，不重新发现、下载或创建资产； - 发布结果不明确：只读核验，不点击发布； - 仅有可恢复的连接/页面错误：只恢复受影响阶段，达到预算后转为具体 `blocked` 或 `unknown`。 每个跳过、失败和待确认结果都必须写出 `reasonCode`、`nextAction` 和 `resumeCondition`。不要用“本轮没有内容”掩盖配置错误、适配积压、账号暂停、数据不足或运行时故障。 ### Historical result reconciliation does not fulfill the current run 平台时间线可能已经显示某个本地 `pending` 目标在更早的运行中成功发布，而本地队列、游标或台账尚未回写。此时只读核验并修复本地状态属于历史结果对账，不是本轮新发布： - 先用标题/正文/媒体或时长、账号和平台发布时间把历史作品与 `contentId + targetId` 明确关联，再写回 `published` / `published_pending_review` 和顺序游标；不得重复上传或点击发布。 - 记录 `historical_result_reconciled`、作品实际发布时间和 `newPublishSideEffectsThisRun: 0`。历史作品发生在本轮 `runStartedAt` 之前时，不消耗本轮 `maxPublishedPerRun`，也不能被写成“本轮已发布”。 - 对账完成后必须在同一轮重新扫描当前账号的未完成目标。如果本轮是用户明确要求发布一次，或当前触发器的目标是推进一次平台发布，而仍没有本轮关联的新提交，则继续执行空队列恢复：先交给 `media-loop` 判断，再由 `media-core` 恢复适配或生产，最后重新扫描并最多新发布 1 条。 - 用户说“今天发布”时，以账号配置时区比较平台 `publishedAt` 的自然日；前一自然日的历史作品只能完成对账，不能满足今天的发布请求。不得用固定每日上限或最小间隔替代这一判断。 - 只有账号健康暂停、结果不确定、来源/版权/媒体硬门禁、无合格候选、幂等冲突或有界恢复停止条件命中时才结束；结束记录必须区分“历史对账成功”和“本轮新发布未完成”。 ## Shared runtime contract 运行结果分类、检查点、未知副作用和恢复语义统一遵守 [media-loop runtime contract](../media-loop/references/runtime-contract.md)。本技能只补充发布执行阶段规则，不另建同义结果类型。 ## Run the workflow 如果调用上下文已经提供 `contentRef` 或 `distributionTargetRef`，先读取 `media-core` 内容资产和目标状态，不重新做与该内容无关的平台热点发现；只在证据、目标窗口或平台适配信息缺失时补充发现。只有没有现成内容资产时，才从候选发现开始，并在核验通过后建立内容资产和分发目标。 ### 1. Build the discovery brief - 先解析目标账号与平台的运营上下文，再调用对应平台子技能生成 `discoveryBrief`；不得先用统一的“热门内容”搜索覆盖所有平台。 - `discoveryBrief` 至少包含：内容主体、平台推荐目标、首要行为信号、候选来源、搜索主题/关键词、排除项、版权边界、时间窗口和候选排序依据。 - 平台子技能可以把“是否值得找”定义为平台专属问题：例如 X 关注讨论、引用、主页访问和关注转化；抖音音乐账号关注音频适配、前三秒记忆点、画面可编辑性、完播潜力和版权；小红书关注搜索意图、收藏价值和卡片信息密度。 - `media-ops` 负责校验 `discoveryBrief` 是否符合账号配置、来源与安全门禁，不改写平台目标，也不把所有任务降级为追逐总阅读量。 ### 2. Collect source candidates - 按账号引用的数据源组采集；显式提供的素材作为本次运行附加来源。 - 按 `discoveryBrief` 指定的顺序采集；若目标平台为 X，检查账号首页/近期时间线中的高价值候选，再扩展到官方名单、原始作者、主题搜索和趋势发现；其他平台按各自子技能的来源策略执行。 - 优先使用配置的可信名单、官方公告、原始研究和作者原文；仅在策略允许时扩展到主题搜索或趋势发现。 - 对热点、平台规则、产品信息和其他时效性事实进行实时检索，不依赖记忆；平台专属规则交给对应子技能。 - 为每项候选记录标题、发布者、发布日期、URL、来源类型、核心主张和与账号定位的关系。 - 对视频、播客或访谈，优先取得带时间戳的原始转写；无法直接核对时降低置信度。 - 遵守站点访问规则、平台 API 条款和版权边界，不绕过访问控制。 热点发现的最小记录应包含：检索时间窗口、排序依据（浏览量、互动量、增长或平台明确的趋势信号）、原帖链接和可见指标。记录绝对指标与归一化指标（如互动/阅读、收藏/阅读、回复/阅读），不要把搜索结果页的顺序或总阅读量直接等同于“热度最高”；优先选择官方账号或原始作者的帖子，并用独立来源交叉核对核心事件。 - X 推荐策略的长期参考见目标平台子技能的增长参考；候选评估应覆盖账号相关性、陌生人理解成本、用户价值、可信度、新鲜度、原创增量、平台适配度，以及可能触发的回复、转发、引用、点击、主页访问、停留和关注行为。不得声称掌握线上固定权重。 ### 3. Normalize and deduplicate - 按同一事件、研究或原始声明聚类，不把转载和评论误认为独立证据。 - 找出最早或最权威的原始来源，将二手材料仅作为背景、反应或补充视角。 - 区分事实、推断、观点和传闻；在后续草稿中保持这种边界。 ### 4. Verify and score 读取 [source-quality.md](references/source-quality.md)，执行其中的来源层级、核验门禁和 100 分评分。 - 关键事实必须能回溯到来源中的具体段落、数据、页面或时间戳。 - 高影响或存在争议的主张需要两个相互独立的可靠来源；多个转述同一原文的页面只算一个来源。 - 不能核实的内容不得写成事实。将其排除，或明确标记为待核验线索。 - 记录淘汰理由，避免为了凑数量降低标准。 - 使用执行策略配置的候选数量、最低分和入选数量；不可配置项不得放松事实与安全门禁。 - 保留通用核验分与平台专属分；通用分判断可信度、版权和安全，平台专属分由对应子技能判断是否值得在该平台生产。 ### 5. Select an editorial angle - 选择与账号定位和内容支柱最相关、对受众最有实际价值、且能提供原创解释的候选。 - 同等条件下优先来源更强、收藏/分享和主页访问潜力更高、能形成稳定栏目承诺的候选；高阅读量但定位弱或原创增量不足的内容降级。 - 明确内容增量：背景解释、概念拆解、实践建议、不同观点比较或基于证据的个人判断。 - 不将翻译、改写标题或拼接摘要冒充原创价值。 - 把素材可支持的结论与作者自己的推断分开表述。 - 优先选择能让陌生用户在首句理解“发生了什么、为什么重要、我能得到什么”的角度；每帖只解决一个问题。 - 为每个平台版本设计平台匹配的互动入口和关注/收藏/完播理由：入口应是具体问题、取舍、可验证判断或平台专属行动；理由应体现账号持续提供的栏目、视角或方法，而不是泛泛求关注。 ### 6. Delegate platform selection and adaptation 按目标平台读取对应子技能，只生成目标平台对应的版本： - X / Twitter：读取 [x](../../platform/x/SKILL.md) - 小红书：读取 [xiaohongshu](../../platform/xiaohongshu/SKILL.md) - 抖音：读取 [douyin](../../platform/douyin/SKILL.md) 总控层先传递运行上下文让平台子技能生成发现策略，再传递已核验候选和证据卡；平台子技能负责平台专属筛选、结构、媒体、平台规则和平台发布交互。不得把“平台适配”缩减为对同一候选做机械改写。 - 围绕同一运营目标重写发现路径、候选标准、结构、节奏、信息密度和行动引导，不机械复制同一候选或同一正文。 - X 的 `scheduled_run` 按目标策略调用 `x`；有效 `unattended` 配置授权其直接完成一次发现、改编和发布，不得再次要求人工确认。`x-api` 不是 `x` 的前置依赖，只有用户或配置明确选择 API 适配器时才调用。不得因 API 未启用而把有效的 `x` 无人值守运行拦截。 - 先应用账号级定位，再应用目标平台引用的风格配置；平台级风格优先于账号通用风格。 - 保留来源链接、作者归属和必要引用在证据卡、审计记录和状态文件中；公开文案是否放链接由平台子技能决定。抖音默认不把外部来源链接、下载链接或“原视频：平台名”写入标题、正文、话题或置顶评论；直接引文只使用支持论点所需的最短片段。 - 不捏造数据、引语、体验、人物反应或画面。无法确认的素材位置使用明确占位符。 - 若精确字数、视频时长、链接或商业内容规则会影响交付，先查阅平台当前官方规则。 - 封面、配图、字幕、配音或镜头仅提供可执行方案；除非用户明确要求，不自动生成媒体资产。 - 若用户要求“翻译后转发/引用”，优先使用平台的引用/转发能力保留原作者归属和原帖媒体；只在用户明确要求且素材版权、来源和上传方式都可核实时重新上传。翻译不等于原创增量，必须补充事实边界或简短解释。 ### 7. Apply the publishing gate 先区分“创建/更新常驻调度”和“执行一次已经被调用的任务”。默认使用人工确认模式并停止在草稿和发布准备阶段；只有用户明确要求建立定时任务时，才创建或更新常驻调度。配置中的 `schedule` 仅为兼容旧文档的描述，不触发创建调度，也不阻断已触发运行。 每次运行先标记执行上下文： - `interactive_run`：用户当前直接发起的一次运营请求。 - `scheduled_run`：已有调度器、自动化任务或外部调用器触发的一次运行。 - `schedule_setup`：创建或更新常驻调度的管理操作。 自动化任务的调用提示必须同时写明：这是 `scheduled_run`、要读取指定账号的当前 media-ops 配置、当配置组合为有效 `unattended` 时无需逐条人工确认，以及仍需执行哪些内容和安全硬门禁。仅写“执行 x”不足以覆盖总控门禁，不能据此恢复旧的全局人工审核默认值。 `scheduled_run` 不得再次要求人工确认。对 `interactive_run`，如果用户明确要求按当前无人值守配置执行一次，也按该配置执行；只有 `schedule_setup` 仍需要用户明确要求。不要把“需要用户明确创建常驻调度”误用为“每次运行前需要人工确认”。 不要读取、填写或保存密码、Cookie、令牌和验证码。可以复用用户已建立的受控登录会话。 只接受以下发布模式： - `publishingMode: reviewed`：要求 `humanApprovalRequired: true` 且 `autoPublish: false`。用户明确授权具体账号和完整内容后，可以完成单次发布。 - `publishingMode: unattended`：要求 `humanApprovalRequired: false`、`autoPublish: true`、`selectLimit: 1`、`maxPublishedPerRun: 1` 与有效 `scheduledTransport`；不要求 `schedule`、最小间隔或每日上限。配置校验通过后，`scheduled_run` 以及用户明确要求按该配置执行的 `interactive_run` 可以直接进入发现、改编和发布，不再增加业务层逐条确认；仍必须遵守所选执行通道的运行时安全策略。 门禁结果必须按实际原因返回，不得笼统返回“未满足人工确认门禁”： - 无人值守配置有效但没有合格候选：返回“本轮跳过：没有候选达到 minScore/内容门禁”，并说明具体门禁。 - 无人值守配置字段组合无效：返回“本轮跳过：无人值守配置无效”，列出字段路径和期望值。 - `reviewed` 模式尚未获得具体内容授权：返回“本轮暂停：人工审核模式需要确认”，不得开始最终发布动作。 - 登录账号、来源、版权、事实或重复检查失败：返回对应的具体失败原因；不得伪装成人工确认失败。 无人值守运行必须执行以下硬门禁： - 实际登录账号必须与配置中的平台 handle 一致；不一致时停止。 - 没有候选达到 `minScore` 时跳过，不为满足频率降低阈值。 - 关键事实、来源链接、版权归属或商业披露存在缺口时跳过。 - 高影响、争议性或无法区分事实与传闻的内容不自动发布。 - 发布前检查近期账号时间线，避免重复事件、近似正文和重复链接。 - 发布后记录可见绝对指标和归一化指标，按内容支柱、格式、作者来源和互动入口复盘；用单变量实验调整首句、引用/原创、媒体、讨论问题和发布时间，不把单条爆文当作稳定规律。 - 每次运行最多发布 1 条；发布成功信号不明确时不重试。 - 对顺序下载任务，运行前读取并校验游标/已发布清单；来源 URL、视频 ID、规范化标题和作者+作品组合都必须参与去重。只在发布结果明确且状态写入成功后推进游标并清理本次临时文件；任何不确定状态都保留候选和媒体，不盲目重试。 - 外部下载必须通过页面可见的下载/备用地址控件完成；下载失败时按平台子技能规定刷新、重解析并交替恢复，不能单次失败即放弃，也不能把页面上的签名直链、媒体预览页或旧下载目录文件当作已下载素材。平台子技能必须完成音视频轨和可播放性验收后才能上传。 - 若配置了外部运营文档，成功、跳过、失败和待确认结果都要写入对应的运行记录；成功发布还要同步更新队列和已发布清单。来源链接可写入内部文档，但仍不得违反平台子技能的公开文案规则。 人工确认模式发布前要求核对： - 事实与引用可回溯； - 标题和钩子没有超出证据； - 观点符合账号定位； - 版权、隐私、商业披露和平台风险可接受； - 每个平台版本确实针对该平台重写； - 链接、标签、画面和口播占位符已补全。 人工确认模式下，在动作发生前说明目标平台、账号和将要发布的完整内容。只有用户对这些具体信息作出明确授权后，才点击最终发布或发送控件；不得把早期的宽泛授权解释为对后续不同内容的持续授权。无人值守模式不走这条逐条确认门禁，但仍必须执行前述事实、版权、账号、重复、限额和成功核验门禁。 使用已登录浏览器发布时，按以下低自由度顺序执行： 1. 解析并锁定目标 `platformAccountRef`、`browserProfileRef` 和 `scheduledTransport`；确认执行器与配置通道一致，完成 Profile 路由后，核对当前登录身份与配置中的平台 handle 一致，再打开目标原帖或发布入口。 2. 创建草稿后重新读取页面状态，确认正文、引用对象、媒体、受众和发布按钮均正确；交互控件优先用精确可访问名称定位，并先核对数量与可用状态。若编辑器追加文本而非替换，必须全选后重填并复读最终内容；抖音公开字段默认不得出现外部链接。 3. 最终发布控件只点击一次。等待平台明确的成功提示、帖子 URL 或账号时间线新内容；出现超时或错误时不得盲目重试。 4. 发布成功后保留已发布页面或结果页供用户复核；若没有可直接取得的帖子 URL，至少报告成功提示和目标账号。 平台专属发布前必须再次确认目标平台、账号身份、媒体/引用对象和最终控件；不得因为“配图”要求而重复上传同一官方媒体。 ### 8. Clean up browser workspaces 任务收尾必须按“结果确认 → 外部系统回写 → 浏览器清理”的顺序执行： - 先确认发布成功、审核中、明确跳过或明确失败的最终状态，再写入 `docsRoot` 下的运行记录、队列/已发布清单和本地机器状态；回写失败时不得关闭仍需要核对或恢复的页面。 - 运行开始时记录本次创建的浏览器 Tab；成功回写后关闭本次运行创建的来源页、搜索页、下载页、编辑器页和结果页等临时页面，避免历史任务不断累积。 - 不关闭用户在任务开始前已经打开的页面，不关闭未完成草稿、上传/下载中页面、验证码/登录交接页或用户明确要求保留的交付页面。结果不明确时保留必要的结果页并标记为 `handoff`，不要靠关页掩盖不确定状态。 - 使用浏览器连接支持的 Tab 清理/finalize 能力时，将清理作为本轮最后一次浏览器操作；清理完成后不再继续点击、读取或导航。若只支持电脑操作，按同一保留规则关闭明确属于本次运行的临时窗口或 Tab。 - 在运行记录中写入清理结果：已关闭的运行 Tab 数量、保留的交接/交付页面及未能关闭的原因。不得为了“清空浏览器”而批量关闭无法确认归属的现有页面。 抖音的 `operation.allowDownload` 默认值为 `false`。`media-ops` 将该值传给 `douyin`；平台子技能负责在最终发布前重新读取“允许下载”控件并确认其处于关闭/不允许下载状态。控件状态不明或仍允许下载时，必须停止，不得因无人值守配置而发布。 ### 9. Hand off feedback 发布、跳过、失败和不确定结果完成记录后，调用 `media-loop` 进行账号健康与运营效果复盘。传递平台、账号、内容支柱、格式、来源、发布时间、可见指标、发布状态和本轮策略版本；不得把凭证或隐私数据传给反馈技能。 `media-loop` 返回的 `strategyOverrides` 只作为下一轮运行的临时覆盖，除非用户明确要求修改常驻配置。`media-ops` 不自行修改策略、不把单条内容表现当作稳定规律，也不因反馈建议绕过事实、版权、安全、去重、限额和发布成功核验。 `publish_unconfirmed` 永远按不确定状态处理：不得因为 `retry-on-failure` 或定时器下一次触发而自动重发。只有平台明确显示提交失败，且策略明确允许重试时，才可以重试；成功页、审核中或结果冲突都先写回并暂停该 `contentId + targetId`。 ### 9.1 Recover an empty ready queue 空队列恢复前先读取 `media-loop` 的库存指纹和生产检查点。只有当前仍有 eligible 可恢复适配目标、上次结果为 `adaptation_backlog_present`、指纹未变化且没有适配写回时，才执行轻量 no-op；存在可恢复适配时先恢复适配，不重新发现来源。争议、审核中、未知、已完成、账号暂停和 disabled 目标不计入 eligible 积压；排除后 ready 为零时必须进入 `ready_supply_starved` 供给决策。 `no-ready-unfinished-due-distribution-targets` 是一次扫描结果，不一定是整轮终点。刚完成 `historical_result_reconciled` 且当前触发仍未获得本轮新提交时，也必须进入本节；不得把历史对账当作本轮发布额度。对配置允许内容生产的执行上下文，按以下低自由度流程处理： 1. 把账号、平台、策略窗口、队列库存、候选阻塞、最近发布/审核状态和最近反馈交给 `media-loop`。 2. 若 loop 返回 `adaptationRequest`，先调用 `media-core` 按最早未完成资产恢复适配，再分别调用对应平台子技能；适配积压存在时不得请求新的来源生产。 3. 若 loop 返回账号暂停、结果不确定、已有足量 ready 库存或无生产请求，记录具体原因并结束；不得重试审核中目标。 4. 仅当 loop 明确返回 `productionRequest` 时，调用 `media-core` 对指定 pipeline 生产并验收。来源发现、下载、版权、去重、资源路径和游标全部属于 core 及其外部协议；ops 不自行补造候选。媒体生产不再受固定“每轮最多几次”限制，由本次外部触发、队列状态、幂等键和 stopConditions 决定是否继续推进。 5. core 返回 `asset_ready` 或适配完成后，在同一轮重新扫描 ready admission 和平台门禁；符合条件才交给平台子技能。生产出的目标不受旧计划时间阻断，保留其计划字段用于审计和排序。 6. core 返回 `production_blocked`、`adaptation_backlog_present` 或 `no_qualified_candidate` 时写入内容层和平台运行记录，停止；同一 `requestId + pipelineRef` 本轮不得再次调用。若返回 `adaptation_backlog_unchanged`，先校验当前 eligible 适配积压数量必须大于 `0`；成立时按成功的轻量 no-op 记录，禁止重新访问来源、调用 Chrome、发起生产或发布，等待队列指纹变化或适配写回。若 eligible 数量为 `0`，该结果无效，必须重分类为 `ready_supply_starved` 并继续一次有界供给恢复。 每次外部触发可以持续推进仍有明确缺口的适配或媒体供给，不再受固定获取次数门禁；但每个请求必须遵守 `contentId + targetId`、`requestId + pipelineRef` 幂等键，遇到成功、无合格候选、来源/版权/媒体失败、锁冲突、账号健康暂停或不确定发布状态即停止。单次触发仍默认最多发布 1 条，防止一次异常重入排空队列；这不是时间或频率门禁。不得形成 `ops → loop → core → ops` 的无界递归。 ### 10. Apply an authorized optimization 当用户明确要求基于 `media-loop` 报告实施优化时，由 `media-ops` 负责拆分变更，不把所有调整写入同一层： - 账号定位、发布频率、阈值和平台 operation：写入 `/local-config/media-ops/config.yaml`； - 平台通用的文案、候选、媒体验收和发布规则：写入对应平台子技能或其 references； - 实际自动化触发频率和提示词：检查并更新对应的本机自动化定义； - `media-loop` 只保留诊断、实验假设、结果和下一次复盘条件，不直接替代执行器改写平台内容。 实施前必须核对变更对象与账号边界，实施后验证配置、自动化定义和运行目录一致。实际触发频率以外部自动化任务当前的 RRULE 为准；技能和内容配置不得写死扫描周期，也不得因为文档窗口与 RRULE 不同就自行创建定时器。只有用户明确要求调整频率时，才同时修改策略配置与实际定时器；只改其中一处会造成“配置看似已变、实际仍按旧频率运行”。每次优化只改变报告支持的主要变量，并记录旧值、新值、生效时间、预期指标和回滚条件。 ## Deliver the editorial package 按以下顺序输出，省略与任务无关的部分： 1. **运行上下文**：账号、定位、平台身份、风格、数据源组、策略、时间窗口和本次覆盖项。 2. **候选池**：候选主题、原始来源、核验状态、总分、建议和淘汰理由。 3. **证据卡**：入选主题的关键事实、来源链接、引用位置、事实/推断边界和风险。 4. **平台草稿**：每个平台独立成节，包含成稿与必要的媒体制作说明。 5. **编辑说明**：内容增量、平台化差异、仍待确认事项。 6. **发布检查单**：逐项列出需要用户确认或补充的内容。 7. **发布结果**：仅在执行发布时提供平台、账号、成功信号和帖子链接；失败或不确定时说明停留状态。 在来源不足时，交付“待核验候选清单”和下一步取证建议，不生成貌似完整的发布稿。