把AI任务之间的交接写成一份可执行发布单

复杂网站工作很少在一个连续任务里完成。内容整理可能发生在知识库任务中，页面开发在官网任务中，账号验证和搜索平台提交又在另一个操作阶段。交接如果只有一句“请把这些发布出去”，下游AI就不得不重新猜测范围、版本和已经确认的决定。

最近一周，我们多次把已经完成的内容工作正式交给网站建设任务。实践表明，AI之间有效的交接不是摘要，而是一份可以直接执行和验收的发布单。

交接先回答什么拥有最终权威

上游可能同时拥有正文、发布配置、图片、作者档案和对话中的补充决定。发布单要明确：哪几个材料区块是本次完整权威输入，哪份文件决定正文，哪份配置决定TDK与Schema，后来的补充要求覆盖哪一项旧安排。

“以这5个Markdown文件为唯一正文源”就是一种清晰边界。它告诉下游可以调整网页格式，但不能从旧稿重新组合文章。图片补充则只覆盖封面安排，不自动改变标题、URL和作者。

如果材料之间存在真正冲突，应说明哪个版本优先；无法判断时，相关页面暂停，其他无冲突页面可以继续。这比让下游为了完成任务而自行选择更可靠。

必须执行和明确禁止同样重要

发布要求通常容易记录，禁止事项却最容易在交接中丢失。例如：不建设某个专题页、不增加`isPartOf`、第16和17篇已经取消、不得编造数据和作者经历、不创建第二个作者页。

这些负向约束不是备注，而是验收条件。只记录“发布第18至20篇”，却不说明16和17已经取消，下游可能为了让编号连续而建立占位页面；只说“优化Schema”，却不说复用作者实体，可能生成第二个`@id`。

发布单最好把事项分成四类：必须执行、不得执行、可以依据现有架构合理判断、缺失时必须暂停。这样AI拥有执行空间，但不会把执行空间误解为扩大任务范围。

用精确映射代替模糊顺序

批量发布需要明确“哪一项对应哪一项”。每篇文章应有最终标题、建议URL、作者、原始时间、本版时间、封面编号、来源、内链和Schema要求。图片规则不能只写“依次使用”，还要给出本轮具体映射和下一次从哪里继续。

日期尤其需要逐项说明。`dateCreated`使用历史时间、`datePublished`使用真实官网首次上线时间、`dateModified`使用本版确认日期，这些规则如果只写“保留时间”，不同任务会得到不同理解。

精确映射也能让下游自动生成测试。它可以验证文章数量、URL、作者`@id`、封面资源和Sitemap记录是否逐一对应，而不是只检查页面总数增加了多少。

把失败处理提前写进交接

可执行发布单不仅描述成功路径。它还要说明：URL冲突时暂停哪一页；构建失败时是否停止覆盖线上版本；搜索平台提交失败时是否保留已上线页面；知识库回填失败时怎样报告。

在同一批次中，局部冲突不一定需要停止全部工作。如果规则允许“其余无冲突页面继续”，下游就可以安全推进；如果涉及全站构建或Sitemap错误，则应该整体停止。提前写清楚，可以避免AI在压力下选择最乐观的解释。

最终报告也是交接的一部分

完成后需要返回最终URL、HTTP状态、Canonical、Schema、Sitemap、封面映射、移动端检查、搜索平台提交结果和未执行事项。报告中的每一项都应对应发布单的验收要求。

这让任务可以继续向下游流动：内容团队知道哪些状态需要回填，运营人员知道哪些页面已经上线，下一次发布知道封面序列从哪里继续。没有完成报告的交接，只是把工作推走；有证据闭环的交接，才真正减少了上下文损耗。

AI协作的效率不只来自并行处理，也来自少一次重新解释。把权威输入、负向约束、精确映射和失败规则写成结构化发布单，不同任务才能在不编造、不越权的前提下连续完成一件复杂工作。

请把下面的上游工作整理成一份可以直接交给下游AI执行的发布单。

上游已确认材料：［填写］
本次目标：［填写］
允许处理的页面：［填写］
已取消或明确禁止的内容：［填写］
URL、作者、日期、封面和内链规则：［填写］
发布与回填要求：［填写］

发布单必须包含：
1. 本次范围与明确不在范围内的事项
2. 每个权威材料区块及其用途
3. 必须执行、不得执行、可合理判断的边界
4. 页面、URL、作者、日期、图片和Schema映射表
5. 冲突、缺失和检查失败时的处理方式
6. 构建、发布、线上核验与最终报告清单

不要省略负向约束，不要把建议写成已经确认的决定，也不要在交接中加入上游没有批准的新任务。