企业官网建设流程全解析

• 人工智能
• AI 技能
• 提示工程

在 agency-agents-zh 的 NEXUS 多智能体流水线中，智能体之间的每一次工作转交都必须携带完整上下文，否则接收方只能"冷启动"式地猜测，这正是多智能体协作失败的头号原因。本文以 handoff-templates.md 为主体，完整拆解 NEXUS 定义的七种标准化交接模板——标准交接、QA 通过/不通过、升级报告、阶段门禁、Sprint 交接与事故交接——并结合 nexus-strategy.md 的交接协议、开发-测试循环与质量门禁机制，讲清每种模板在什么场景使用、每个字段为什么存在、以及如何让交接文档真正"可执行"。读完本文，你将能够为任意多智能体工作流建立一套不丢上下文、可审计、可重试、可升级的交接规范。

交接为什么是 NEXUS 成败的关键

NEXUS（Network of EXperts, Unified in Strategy，专家网络统一策略）把 Agency 中各自为战的 AI 专家组织成一条协调的流水线。单个智能体能力再强，缺乏协调也会产出相互矛盾的架构决策、跨部门重复劳动、交接边界的质量断层，以及最致命的——没有共享上下文和组织记忆。

NEXUS 策略文档 把"上下文连续性"列为六大核心原则之一：每次交接都带完整上下文，没有智能体冷启动。换句话说，任何一个智能体接手工作时，都不应该靠猜测来还原"之前发生了什么"——这份上下文必须由交接文档显式携带。

这正是 handoff-templates.md 存在的意义：它定义了 NEXUS 流水线中所有智能体之间交接的标准化模板。文档开篇就点明了要害："交接规范做好了，就不会丢上下文——这是多智能体协作失败的头号原因。"

与交接模板配套的另一份即用文档是 agent-activation-prompts.md，它提供激活智能体的提示词模板；而交接模板解决的是智能体被激活之后、把工作交给下一个人时的格式问题。两者配合，才构成完整的"激活 → 工作 → 交接"闭环。

模板一：标准交接模板——任何智能体之间的工作转交

标准交接模板是整套体系的底座，用于任何两个智能体之间的工作转交。无论交接发生在同一阶段内部（比如前端开发者把实现交给证据收集者），还是跨阶段传递（比如第 2 阶段把骨架应用交给第 3 阶段），都必须按此格式填写。

# NEXUS 交接文档 ## 元数据 | 字段 | 值 | |------|-----| | **发送方** | [智能体名称]（[部门]） | | **接收方** | [智能体名称]（[部门]） | | **阶段** | 第 [N] 阶段 — [阶段名称] | | **任务引用** | [Sprint 排序师待办列表中的任务 ID] | | **优先级** | [紧急 / 高 / 中 / 低] | | **时间戳** | [YYYY-MM-DDTHH:MM:SSZ] | ## 上下文 **项目**：[项目名称] **当前状态**：[到目前为止做了什么——要具体] **相关文件**： - [文件/路径/1] — [内容说明] - [文件/路径/2] — [内容说明] **依赖**：[这项工作依赖什么已完成的部分] **约束**：[技术、时间线或资源约束] ## 交付要求 **需要什么**：[具体的、可衡量的交付物描述] **验收标准**： - [ ] [标准 1 — 可衡量] - [ ] [标准 2 — 可衡量] - [ ] [标准 3 — 可衡量] **参考材料**：[需求、设计、之前工作的链接] ## 质量预期 **必须通过**：[该交付物的具体质量标准] **需要的证据**：[完成证明长什么样] **下一个接收方**：[谁接收产出，需要什么格式]

逐块拆解这个模板的设计意图：

• 元数据区回答"谁给谁、在哪个阶段、对应哪个任务"。任务引用字段必须指向 Sprint 排序师 待办列表中的任务 ID，保证交接文档与任务追踪体系一一对应；时间戳采用 ISO 8601 格式（YYYY-MM-DDTHH:MM:SSZ），便于审计时间线。
• 上下文区回答"现在做到哪一步了"。其中相关文件必须列明文件路径与内容说明，依赖指明这项工作依赖哪些已完成的部分，约束记录技术、时间线或资源限制。这是"上下文连续性"原则的直接落地——接收方拿到这份文档，不需要再去翻聊天记录。
• 交付要求区回答"接收方要产出什么"。验收标准必须写成可衡量的条目（而不是"做好 UI"这种模糊表述），因为后续 QA 环节（见模板二、三）要逐条勾选这些标准。
• 质量预期区回答"怎么算合格"。需要的证据定义了"完成证明长什么样"，与 NEXUS"证据高于口说"原则一致——口说无凭，证据为证。

值得注意的是，NEXUS 策略文档第 11 节"交接协议" 给出了标准交接模板的精简版（元数据 / 上下文 / 交付要求 / 质量预期四个小节），而本模板是其完整版。两者的字段一一对应，精简版适合流水线内部的轻量交接，完整版适合需要记录验收标准与证据要求的正式交接。

模板二：QA 反馈循环——判定"通过"

当证据收集者或其他 QA 智能体通过一个任务时，使用本模板。它是开发-测试循环中"通过 → 进入下一个任务"分支的交接载体。

# NEXUS QA 判定：通过 ## 任务 | 字段 | 值 | |------|-----| | **任务 ID** | [ID] | | **任务描述** | [描述] | | **开发智能体** | [智能体名称] | | **QA 智能体** | [智能体名称] | | **第几次** | 第 [N] 次，共 3 次 | | **时间戳** | [YYYY-MM-DDTHH:MM:SSZ] | ## 判定：通过 ## 证据 **截图**： - 桌面端（1920x1080）：[文件名/路径] - 平板（768x1024）：[文件名/路径] - 手机（375x667）：[文件名/路径] **功能验证**： - [x] [验收标准 1] — 已验证 - [x] [验收标准 2] — 已验证 - [x] [验收标准 3] — 已验证 **品牌一致性**：已验证 — 颜色、字体、间距符合设计系统 **无障碍**：已验证 — 键盘导航、对比度、语义化 HTML **性能**：[实测加载时间] — 在可接受范围内 ## 备注 [任何观察、后续可改进的小建议、或值得表扬的地方] ## 下一步行动 → 智能体编排者：标记任务完成，进入待办列表中的下一个任务

这个模板把 NEXUS 的质量哲学落到了格式层面：

• 证据必须具体到文件。截图固定要求三档尺寸：桌面端 1920x1080、平板 768x1024、手机 375x667——这与 证据收集者 的截图 QA 标准、第 4 阶段加固手册 中"完整截图套件"的要求完全对齐。证据收集者智能体的人格设定里明确写着"没有截图的 UI Bug 不提交"、"证据必须在提交时收集，不能事后补"。
• 验收标准逐条勾选，每条后面标注"已验证"。功能验证、品牌一致性、无障碍、性能四个维度缺一不可，恰好覆盖 NEXUS 第 3 阶段质量门禁 中"所有任务通过 QA、品牌一致性 95%+、无严重 bug"等检查项。
• 下一步行动写明由智能体编排者标记完成并进入下一个任务，即 QA 通过后控制权明确交还给流水线控制器。

模板三：QA 反馈循环——判定"不通过"

当证据收集者或其他 QA 智能体打回一个任务时，使用本模板。与"通过"模板相对，它是开发-测试循环中"不通过 → 重试"分支的交接载体。第 3 阶段手册 明确规定：每个任务最多重试 3 次，超过就升级，所以模板中的"第几次"字段直接对应重试计数。

# NEXUS QA 判定：不通过 ## 任务 | 字段 | 值 | |------|-----| | **任务 ID** | [ID] | | **任务描述** | [描述] | | **开发智能体** | [智能体名称] | | **QA 智能体** | [智能体名称] | | **第几次** | 第 [N] 次，共 3 次 | | **时间戳** | [YYYY-MM-DDTHH:MM:SSZ] | ## 判定：不通过 ## 发现的问题 ### 问题 1：[分类] — [严重度：紧急/高/中/低] **描述**：[问题的准确描述] **预期**：[按验收标准应该是什么样] **实际**：[实际是什么样] **证据**：[截图文件名或测试输出] **修复指引**：[具体的、可执行的修复说明] **需要改的文件**：[准确的文件路径] ### 问题 2：[分类] — [严重度] **描述**：[...] **预期**：[...] **实际**：[...] **证据**：[...] **修复指引**：[...] **需要改的文件**：[...] [所有发现的问题都列出来] ## 验收标准状态 - [x] [标准 1] — 通过 - [ ] [标准 2] — 不通过（见问题 1） - [ ] [标准 3] — 不通过（见问题 2） ## 重试说明 **给开发智能体**： 1. 只修上面列出的问题 2. 不要加新功能或做其他改动 3. 所有问题修完后重新提交 QA 4. 当前是第 [N] 次，最多 3 次 **如果第 3 次还不通过**：任务将升级给智能体编排者

这个模板的设计有几个值得学习的要点：

• 问题条目七要素：描述 / 预期 / 实际 / 证据 / 修复指引 / 需要改的文件，加上严重度分类。这与 NEXUS 策略文档 11.2 节"QA 反馈循环协议" 的结构一致，也呼应证据收集者"一份好的 Bug 报告，开发看完就能开始修，不需要再问你一个问题"的职业准则。
• 验收标准状态表把"通过"与"不通过"的标准分开列示，并反向引用问题编号，让开发者一眼看清哪些标准已满足、哪些因哪个问题而失败。
• 重试说明的纪律性："只修上面列出的问题，不要加新功能"——这是防止范围蔓延的关键约束，与第 3 阶段手册中"开发者只修被指出的问题 → 重新提交 QA"的编排者决策逻辑一一对应。
• 升级兜底："如果第 3 次还不通过，任务将升级给智能体编排者"——对应 NEXUS 策略文档第 11.3 节升级协议 与第 3 阶段手册的升级机制。

模板四：升级报告——任务超过 3 次重试时的向上路由

当一个任务超过 3 次重试时，使用本模板。它是"快速失败，快速修复"原则的最终落点——3 次不通过说明不是简单的实现问题，需要更高层级的决策介入。

# NEXUS 升级报告 ## 任务 | 字段 | 值 | |------|-----| | **任务 ID** | [ID] | | **任务描述** | [描述] | | **开发智能体** | [智能体名称] | | **QA 智能体** | [智能体名称] | | **重试已用完** | 3/3 | | **升级给** | [智能体编排者 / 工作室制片人] | | **时间戳** | [YYYY-MM-DDTHH:MM:SSZ] | ## 失败历史 ### 第 1 次 - **发现的问题**：[摘要] - **做了什么修复**：[开发者改了什么] - **结果**：不通过 — [为什么还是没过] ### 第 2 次 - **发现的问题**：[摘要] - **做了什么修复**：[开发者改了什么] - **结果**：不通过 — [为什么还是没过] ### 第 3 次 - **发现的问题**：[摘要] - **做了什么修复**：[开发者改了什么] - **结果**：不通过 — [为什么还是没过] ## 根因分析 **为什么任务一直过不了**：[对底层问题的分析] **系统性问题**：[这是偶发还是有规律？] **复杂度评估**：[任务本身的范围定义是否合理？] ## 建议处理方式 - [ ] **重新分配**给别的开发智能体（[建议的智能体]） - [ ] **拆分**成更小的子任务（[建议的拆分方案]） - [ ] **换思路**——架构/设计需要调整 - [ ] **接受**当前状态，记录已知限制 - [ ] **推迟**到后面的 Sprint ## 影响评估 **阻塞**：[什么其他任务被这个堵住了] **时间线影响**：[对整体排期的影响] **质量影响**：[如果接受当前状态，有什么质量上的妥协] ## 需要决策 **决策者**：[智能体编排者 / 工作室制片人] **截止时间**：[什么时候需要做决定才不会进一步延误]

升级报告的设计逻辑分三层：

• 失败历史要求完整记录三次重试的"问题 → 修复 → 结果"，这不是为了追责，而是让升级决策者看清问题到底有没有收敛。这与 第 3 阶段手册 中编排者在第 2 次重试时"考虑这个开发智能体是不是合适的人选"的反思逻辑呼应。
• 根因分析区分"偶发问题"与"系统性问题"——如果同一个任务反复不过，可能是任务本身范围定义不合理，也可能是分配错了智能体。这对应 NEXUS 策略文档 11.3 节 中"什么系统性问题阻碍了解决"的追问。
• 建议处理方式给出五个互斥选项（重新分配 / 拆分 / 换思路 / 接受 / 推迟），与 第 3 阶段手册 编排者决策逻辑中的升级选项（a-e）完全一致。需要决策字段还给决策者设定了截止时间，避免升级任务悬而不决。

模板五：阶段门禁交接——跨阶段转换的"过门"手续

在 NEXUS 阶段转换时使用。NEXUS 流水线有 7 个阶段（发现 → 策略 → 基础搭建 → 构建 → 加固 → 上线 → 运营），每个阶段之间都有质量门禁，门禁不通过，阶段不能推进。本模板就是门禁通过后，把阶段成果"打包"递给下一阶段的交接文档。

# NEXUS 阶段门禁交接 ## 转换 | 字段 | 值 | |------|-----| | **来源阶段** | 第 [N] 阶段 — [名称] | | **目标阶段** | 第 [N+1] 阶段 — [名称] | | **门禁守门人** | [智能体名称] | | **门禁结果** | [通过 / 不通过] | | **时间戳** | [YYYY-MM-DDTHH:MM:SSZ] | ## 门禁标准结果 | # | 标准 | 阈值 | 结果 | 证据 | |---|------|------|------|------| | 1 | [标准] | [阈值] | 通过 / 不通过 | [证据引用] | | 2 | [标准] | [阈值] | 通过 / 不通过 | [证据引用] | | 3 | [标准] | [阈值] | 通过 / 不通过 | [证据引用] | ## 带入下一阶段的文档 1. [文档名称] — [下一阶段用途] 2. [文档名称] — [下一阶段用途] 3. [文档名称] — [下一阶段用途] ## 下一阶段的关键约束 - [本阶段发现的约束 1] - [本阶段发现的约束 2] ## 下一阶段智能体激活 | 智能体 | 角色 | 优先级 | |--------|------|--------| | [智能体 1] | [下一阶段的角色] | [立即 / 第 2 天 / 按需] | | [智能体 2] | [下一阶段的角色] | [立即 / 第 2 天 / 按需] | ## 带入的风险 | 风险 | 严重度 | 缓解措施 | 负责人 | |------|--------|---------|--------| | [风险] | [P0-P3] | [缓解方案] | [智能体] |

阶段门禁交接模板把 NEXUS 策略文档第 12 节"质量门禁" 的机制具象化：

• 门禁标准结果表的"标准 + 阈值 + 结果 + 证据"四列结构，直接对应策略文档中每个阶段门禁的标准/阈值/证据定义。例如第 0 阶段门禁要求"市场机会已验证（TAM 超过最低可行阈值，证据为趋势研究员报告 + 来源）"、第 3 阶段门禁要求"性能基线达标（P95 < 200ms，证据为性能基准师报告）"。
• 带入下一阶段的文档列出要传递给下阶段的交付物及其用途，例如第 3 阶段手册明确定义了"第 3 阶段 → 第 4 阶段交接包"：给现实检验者的 QA 证据与回归结果、给法务合规员的数据处理实现、给性能基准师的压力测试地址与性能预算。
• 下一阶段智能体激活表的优先级字段（立即 / 第 2 天 / 按需）帮助接收阶段排定激活顺序。
• 带入的风险表与 NEXUS 策略文档第 13 节风险管理 的风险登记表格式一致，P0-P3 的严重度分级对应响应矩阵（P0 立即响应、P1 4 小时内、P2 24 小时内、P3 1 周内）。

模板六：Sprint 交接——Sprint 边界的"复盘 + 移交"

在 Sprint 边界使用。它同时完成两件事：对刚结束的 Sprint 做总结复盘，为下一个 Sprint 准备输入。Sprint 排序师的 RICE 评分、团队速度等概念在这个模板中被显式引用。

# NEXUS Sprint 交接 ## Sprint 总结 | 字段 | 值 | |------|-----| | **Sprint** | [编号] | | **持续时间** | [开始日期] → [结束日期] | | **Sprint 目标** | [目标描述] | | **速度** | [计划] / [实际] 故事点 | ## 完成状态 | 任务 ID | 描述 | 状态 | QA 次数 | 备注 | |---------|------|------|---------|------| | [ID] | [描述] | 完成 | [N] | [备注] | | [ID] | [描述] | 完成 | [N] | [备注] | | [ID] | [描述] | 顺延 | [N] | [原因] | ## 质量指标 - **首次通过率**：[X]% - **平均重试次数**：[N] - **完成任务数**：[X/Y] - **交付故事点**：[N] ## 顺延到下一个 Sprint | 任务 ID | 描述 | 原因 | 优先级 | |---------|------|------|--------| | [ID] | [描述] | [为什么没完成] | [RICE 分数] | ## 回顾洞察 **做得好的**：[主要成功点] **可以改进的**：[主要改进点] **行动项**：[下个 Sprint 的具体改变] ## 下一个 Sprint 预览 **Sprint 目标**：[拟定目标] **重点任务**：[最高优先级的事项] **依赖**：[跨团队的依赖]

Sprint 交接模板与前几个模板互补：

• 质量指标（首次通过率、平均重试次数）直接对表 NEXUS 策略文档第 14 节成功指标：任务首次 QA 通过率目标 70%+、每任务平均重试次数目标 < 1.5。这些指标是衡量"交接与 QA 循环是否健康"的关键依据。
• 顺延任务的优先级用 RICE 分数（Reach x Impact x Confidence / Effort），这是 Sprint 排序师 的排序语言，保证顺延任务能在下一个 Sprint 的待办列表中被公平重排。
• 回顾洞察对应 第 3 阶段手册 中的"Sprint 复盘"环节（由工作流优化师主持：哪些做得好？哪些可以改进？下个 Sprint 改什么？），而下一个 Sprint 预览为 Sprint 排序师 的下一轮规划提供了输入。

模板七：事故交接——事故响应期间的接力棒

在事故响应期间使用。NEXUS 策略文档将事故响应定义为"生产事故处理"的专项场景（见 runbooks/scenario-incident-response.md），事故交接模板就是让多位响应人无缝接力、不丢失现场状态的关键。

# NEXUS 事故交接 ## 事故 | 字段 | 值 | |------|-----| | **严重度** | [P0 / P1 / P2 / P3] | | **发现者** | [智能体或系统] | | **发现时间** | [时间戳] | | **负责人** | [智能体名称] | | **状态** | [排查中 / 止血中 / 已解决 / 事后复盘] | ## 描述 **发生了什么**：[对事故的清楚描述] **影响范围**：[谁/什么受影响，影响多严重] **时间线**： - [HH:MM] — [事件] - [HH:MM] — [事件] - [HH:MM] — [事件] ## 当前状态 **受影响的系统**：[列表] **有没有临时方案**：[有/没有——有的话描述一下] **预计修复时间**：[估计] ## 已采取的措施 1. [做了什么，结果是什么] 2. [做了什么，结果是什么] ## 交接上下文 **给下一位响应人**： - [试过什么了] - [还没试什么] - [怀疑的根因] - [要查的相关日志/指标] ## 利益相关方通知 **最近一次更新**：[时间戳] **下次更新时间**：[时间戳] **通知渠道**：[更新发布在哪]

事故交接模板与 NEXUS 策略文档风险响应矩阵 强关联：P0 事故要求立即响应、由工作室制片人决策并停下其他工作；P1 事故 4 小时内由项目牧羊人负责。模板的"交接上下文"一节是它的灵魂——"试过什么了 / 还没试什么 / 怀疑的根因 / 要查的相关日志"四要素，确保接手的响应人不会重复别人已经做过的排查，这正是事故场景下最昂贵的浪费。

使用指南：什么场景用哪个模板

handoff-templates.md 末尾给出了完整的场景对照表，这里原样保留并补充场景说明：

七种模板覆盖了 NEXUS 流水线的所有"边界时刻"：

• 任务级边界：任务在开发智能体与 QA 智能体之间流转时，用 #1、#2、#3；
• 失败边界：重试次数耗尽时，用 #4 升级；
• 阶段级边界：质量门禁通过、阶段转换时，用 #5；
• 时间级边界：Sprint 结束时，用 #6；
• 异常边界：系统事故发生时，用 #7。

交接模板在 NEXUS 流水线中的运行位置

理解了七种模板后，再把它们放回 NEXUS 策略文档 的整体架构中看，就能看清它们如何支撑流水线运转：

1. 开发-测试循环（第 3 阶段核心机制）是模板 #2/#3 的主战场。智能体编排者按 RICE 排序逐任务推进：分配任务（#1 标准交接）→ 开发者实现 → 证据收集者测试 → 通过（#2）进入下一个任务，或不通过（#3）把 QA 反馈发回开发者重试，重试达 3 次触发 #4 升级。
2. 质量门禁是模板 #5 的触发点。NEXUS 有 6 道门禁（发现门禁、架构门禁、基础门禁、功能门禁、生产门禁、上线门禁），每道门禁有指定的守门人（如现实检验者是生产门禁的唯一权威）。门禁通过后，守门人出具 #5 阶段门禁交接，把标准/阈值/证据、风险与下一阶段的激活计划打包传递。
3. Sprint 节奏是模板 #6 的周期点。每个 Sprint 边界（规划、每日执行、回顾、复盘）之间用 #6 交接，让 Sprint 排序师拿到完整的质量指标与顺延清单，为下一轮规划做准备。
4. 事故响应是模板 #7 的紧急场景，配合 scenario-incident-response.md 使用。

整个体系的关键是：交接不是"发消息"，而是"交文档"。证据高于口说，上下文靠文档延续，质量靠标准衡量，失败靠升级兜底——七种模板把这些原则全部格式化了。

实践要点：让交接文档真正"可执行"

结合 证据收集者、现实检验者 等 QA 智能体的人格设定，填写交接模板时有几个直接影响流水线效率的要点：

1. 上下文要具体，不要写"进展顺利"。当前状态字段应写明"已完成 X、正在进行 Y、Z 尚未开始"，并附上具体文件路径。证据收集者的信条是"没有截图的 UI Bug 不提交、没有日志的服务端问题不提交"——同样，没有文件路径的交接上下文等于没有上下文。
2. 验收标准必须可衡量。标准交接模板和 QA 判定模板中的验收标准要能逐条勾选。第 3 阶段门禁要求"100% 任务通过 QA"，如果验收标准本身模糊，QA 判定就成了口头承诺，违背"证据高于口说"原则。
3. QA 不通过的反馈要"能直接开工"。问题条目必须包含预期 vs 实际、证据引用、修复指引、需要改的文件路径四件套。证据收集者的成功指标是"Bug 报告被开发退回率 < 5%（因信息不足退回）"，这条标准同样适用于 QA 判定模板的填写质量。
4. 升级报告要有完整失败历史。三次重试的"问题 → 修复 → 结果"缺一不可，否则决策者无法判断任务是否真的在收敛，也就无法在"重新分配 / 拆分 / 换思路 / 接受 / 推迟"五个选项中做出有理有据的选择。
5. 门禁交接必须带证据引用。门禁标准结果表中每一行的"证据"列都要指向具体的报告或文件（如"性能基准师报告"、"证据收集者截图包"），而不是写"已验证"三个字。

结语：把交接变成流水线的"肌肉记忆"

NEXUS 交接模板的七种格式，本质上是把多智能体协作中最容易失守的三个环节——上下文传递、质量反馈、失败升级——全部标准化。标准交接（#1）保证没有冷启动，QA 通过/不通过（#2/#3）保证证据与反馈可执行，升级报告（#4）保证失败有决策出口，阶段门禁（#5）保证阶段推进有据可依，Sprint 交接（#6）保证周期复盘有数据，事故交接（#7）保证紧急时刻不丢现场。

这套模板可以直接与 agent-activation-prompts.md 中的激活提示词配合使用——激活提示词定义"智能体做什么"，交接模板定义"做完后怎么交给下一个人"。从 QUICKSTART.md 的 NEXUS-Full / NEXUS-Sprint / NEXUS-Micro 三种模式，到 nexus-strategy.md 的七阶段流水线，交接模板贯穿始终。把交接规范做好，多智能体协作最昂贵的那一类失败——上下文丢失——就能被系统性根治。

• 人工智能
• AI 技能
• 提示工程