HiveFlow：从反馈到有证据的交付
1.HiveFlow解决什么问题
用户在群里说“导出少了一页”，到问题真正解决，中间还需要调查现象、登记事项、决定是否采纳、明确实施范围、开发与审阅、部署与验收，最后把结果带回。任何一环缺少记录，后来的人就可能不知道谁同意了什么、现在进行到哪里，或者用户到底能不能用。
HiveFlow是一套让人和智能体共同完成这段工作的协作方法。它连接反馈、决定和交付，让每一步都有足够的依据，也让使用者不用在不同工具之间反复转述。
它复用dots、GitHub、Codex和消息桥接，不要求增加新的常驻调度服务。工具名称不授予权限，聊天中的建议也不自动变成开发指令。
本书用一条合成的“导出只包含当前页”案例贯穿主要流程，解释正常路径和异常处理。阅读后应能回答：
- 用户怎样反馈，接收方怎样调查，什么时候需要登记事项。
- 负责人怎样采纳、授权或暂停，已有授权内怎样连续推进。
- 执行者选择PR待审还是完整交付，每种模式怎样结束。
- 合并、部署、验收、正式登记与原群回执分别需要什么依据。
- 原生自动化怎样配置、选单和认领，哪些能力仍需真实验证。
- 网站怎样根据本书整理内容，并保留来源版本和适用范围。
2.与蜂巢、ACDL和网站的关系
蜂巢是这套方法形成和实践的项目背景。ACDL负责需求、设计、实施、评审和版本的工程协作；HiveFlow负责反馈入口、采纳与授权的衔接、任务交付终点及原来源回执。需要了解工程方法时，可以并读ACDL研发流程手册。
HiveFlow的唯一权威执行规范在自动化目录。本手册将规则解释成连续教程和案例；独立flow网站仓库应以本手册为原始材料，整理展示网站的公开内容。
内容依赖为HiveFlow规范→HiveFlow介绍→HiveFlow网站，维护规则由HFL-016定义。规范改变时，先确认正式规则，再同步手册和网站。网站介绍不反过来授权真实操作，也不能替代项目当前记录。具体取材范围、章节映射和来源版本要求见附录C。
独立hive-flow仓库已于2026-10-20按Apache-2.0开源，提供规范参考副本、介绍与离线工具。公开读者不需要访问私有HiveOS即可学习和试用；业务实例的源码访问、执行授权与启用状态仍分别核验。
官网源码flow仓库也已采用Apache-2.0，网站实现与经授权分发的介绍材料按其LICENSE和NOTICE使用，第三方材料保留各自声明。
3.Issue之后：在MacMini上选择怎样启动、做到哪里
蜂巢当前以GitHub Issue作为云端与本机之间的研发交接点。云端Dots（本书沿用名称dots）接收反馈、调查并登记事项；Issue创建并核验后，后续研发由Director的MacMini上的Codex承接。源头的采纳评审仍记录其真实决定，本地执行则按实际手动授权或原生定时配置推进，不由云端dots逐步派发。
本节解释HFL-003定义的本地启动方式及Director介入时点。在MacMini上，有两个独立选择：手动或定时决定怎样启动，PR待审或完整交付决定做到哪里。 它们可以组成四条路径：
| 启动方式 | PR待审 | 完整交付 |
|---|---|---|
| 手动 | Director在本机下达任务；Codex完成开发、检查和PR后停止，Director再介入一次，决定并推进合并、部署 | Director明确完整范围并授权；Codex连续完成必要审阅、修正、合并、约定环境交付、验收和收尾 |
| 原生定时任务 | 本机任务在已批准且实际启用的配置内定时选单，完成PR后停止；Director仍需再介入一次处理合并、部署 | 本机任务在有效配置内选单并按完整终点推进，无需Director逐单再手动发起或例行确认后续步骤 |
PR之后的介入，可以由Director自己操作，也可以在MacMini的可信执行会话中明确授权继续。完整交付中的代码审阅和业务验收仍需真实完成，但不天然要求Director本人逐步点击确认；约定由本人验收或出现超出授权的情况时，另行处理。
这张表描述路径，当前业务自动执行尚未启用。Issue存在不等于可以开工；新采纳模式仍需有效配置、受控决定及认领。Director的介入次数按本地研发阶段单独统计，源头采纳与定时配置准备另计，详见第3章。
4.先看清三件容易混淆的事
采纳表示值得做，实施授权说明可以做到哪里。 已采纳的事项仍可能等待目标、环境或验收范围；已有明确授权时，则在该范围内连续推进，不为例行步骤反复确认。
PR待审与完整交付是两个不同终点。 前者形成供审阅的候选，后者在明确范围内完成必要审阅、合并、部署、验收、正式记录和结果反馈。写完代码不等于完成后者。
业务完成与通知结果分别核验。 部署和验收有自己的证据，消息受理、平台确认、用户收到与已读也有各自依据。通知失败不触发重复开发，结果未知先核实原动作。
5.第一次怎样阅读
快速了解方法，可以先读第1章、第3章、第7章和附录B；准备在群里反馈，先读第4章；需要维护网站，先读本目录及附录C，再按取材范围通读相关章节。
系统阅读时，按下面12章展开：
- 认识HiveFlow：把反馈、决定和交付连起来：理解要解决的问题、适用场景，以及与蜂巢和ACDL的关系。
- 角色与工具：每个参与者负责什么：理解使用者、负责人、dots、Codex和桥接怎样分工。
- 流程总览：一条反馈怎样走到交付：沿一条反馈看调查、登记、决定、研发、验收和通知。
- 群里反馈：怎样提问、调查和登记：学习怎样描述现象、补问、关联来源、登记与答复。
- 采纳与授权：把值得做和可以做分开：分清价值判断和实施许可，写出准确的任务范围。
- 事项状态：评审、进度和正式登记：分清评审、进度、正式登记身份与交付事实。
- 手动研发：选择PR待审或完整交付：比较两种交付终点，理解实际研发与ACDL的衔接。
- 交付与回执：把结果带回原反馈者：理解交付记录、单一通知路径和消息结果。
- 原生自动化：先配置范围，再选择新事项：理解定时任务、选单方式和启用前准备。
- 采纳交接：记录、认领、撤销和恢复：理解受控记录、真实认领、取消与未知结果。
- 调查与恢复：依据、隐私和未知结果：理解版本依据、只读调查、隐私、停止与接续。
- 接入与验证：从离线演练到真实使用：理解接入条件、离线演练、模拟与现场验收的区别。
三篇附录提供查阅、连续案例和网站维护材料：
- 附录A：术语、状态和常见问题：查术语、三类状态和常见问题。
- 附录B：完整案例与对话示例：看同一反馈如何走向不同终点，以及异常怎样处理。
- 附录C：网站取材与内容维护：查网页取材对应关系、版本记录与内容更新方式。
6.按当前问题查阅
| 你现在想知道什么 | 建议先读 |
|---|---|
| HiveFlow到底是什么，为什么需要它 | 第1章、第3章 |
| Issue创建后在哪里做，手动与定时怎样选择 | 第2章、第3章、第9章 |
| Director需要介入几次，PR之后还要做什么 | 第3章、第7章 |
| 我在群里应该怎样提问或报告问题 | 第4章、附录B |
| 谁能决定采纳，采纳后是否会开工 | 第2章、第5章、第9章 |
| GitHub状态、正式编号和实施授权是什么关系 | 第6章、附录A |
| 只想先审阅代码，应选择什么模式 | 第7章 |
| 希望完成部署与验收，应写清哪些范围 | 第5章、第7章、附录B |
| 用户怎样知道已经处理，通知失败怎么办 | 第8章 |
| 怎样准备原生自动化和采纳交接 | 第9章、第10章、第12章 |
| 断连、暂停、撤销或结果未知怎样恢复 | 第10章、第11章 |
| 哪些已经验证，哪些仍然需要现场验证 | 第12章 |
| 网站应该参考哪里，怎样更新而不夸大能力 | 附录C，再按映射读取各章 |
7.当前能力与阅读边界
现行规范定义了手动交付和受控自动路径，已有模板、离线检查以及部分手动交付、单次原来源回执实践。业务自动执行尚未启用。 不能把“已有文档”或“模拟测试通过”解释成采纳后自动完成全链路已经验收。
实际控制记录、原生任务、权限和真实链路要分别核验。带日期的接入事实与未验收范围见HFL-019，怎样阅读这些证据见第12章。本书不会把历史状态直接当作所有环境的当前状态。
上游介绍手册的12章正文和3篇附录保持Review状态。本站按公开范围整理为阅读版；合成案例不代表产品承诺、真实授权或已通过验收，执行依据仍是同版本的HiveFlow规范。
8.从理解转向执行
Agent实际工作仍先读取目标仓库的AGENTS.md，再从HFL-001：规范加载入口选择intake、review或delivery路线，核验真实仓库、完整版本和任务所需规则。工程规范从ACDL规范入口选择，不要求每项任务通读全部材料。
本手册依据同一HiveOS提交中的现行规范展开，章节末尾列出直接依据。规范与介绍同步维护；网站取材时记录包含两者同步修订的完整提交及采用章节，不从旧写作基线推断已经包含新规则。
回到全部手册或文档中心。