01.认识HiveFlow：把反馈、决定和交付连起来

1.从一句反馈开始

一位同事在工作群里说：“导出的文件只有第一页，能不能看看？”

这句话同时留下了几个问题：是操作方式不对，还是软件缺陷？已经有人处理过吗？值得改时由谁决定？代码改完以后，最初反馈的人怎样知道结果？如果开发工具中途断线，又怎样避免把同一个修改做两遍？

HiveFlow围绕这些问题组织协作。使用者说出真实场景，协调方调查并整理事项，负责人决定是否采纳和做到哪里，开发工具在授权内实施，再把有证据的结果带回原反馈者。

它关注的是一件事从提出到结束是否连贯：问题有没有被理解，决定是否明确，实施有没有越界，结果是否经过检查，尚未完成的部分有没有被准确留下。

HiveFlow是源自蜂巢实践的一套人和智能体协作规范。它把反馈入口、负责人决定、研发工具、事项记录和结果通知连接起来，探索在明确授权边界内，让已有流程可以逐步自动承接。

这套方法先用于蜂巢自身。它使用现成的模型、GitHub、Codex和消息平台，说明这些能力怎样配合，以及遇到失败、重复或未知结果时怎样处理。

读者可以从三个层次认识它：

介绍材料帮助读者理解，规范指导实际任务，接入记录说明已经观察到的事实。把这三层放在一起阅读，才能避免把一个设计目标误认为已经上线的能力。

一次反馈通常会经过聊天、工单、开发会话和发布环境。只靠人反复转述，容易丢失原来的目标，也容易出现“代码已经合并，但没人知道用户的问题是否解决”的情况。

HiveFlow尝试减少以下重复劳动：

减少转述不等于省略重要判断。产品取舍、权限扩大和高风险变化仍由有权负责的人决定；已经明确的同范围步骤则连续推进，不再逐个重复询问。

蜂巢是实际被研发和使用的产品。ACDL是蜂巢形成的工程协作方法，负责需求、设计、实施、反馈、独立评审和版本。HiveFlow关心反馈怎样进入这套工程过程，以及决定和交付结果怎样跨工具衔接。

例如，用户报告导出缺陷，HiveFlow先安排调查、登记和采纳问询；需要修改时，实施者遵守ACDL与仓库规则完成代码、验证和必要评审；满足约定终点后，再由HiveFlow处理事项收尾与原来源回执。

小维护仍按项目实际风险选择路径。本书使用完整案例是为了讲清衔接关系，不要求每次咨询、文案调整或链接修复都建立Issue、REQ或一轮正式实施记录。

现行规则采用负责人直接发起的手动研发路径。负责人可以选择做到PR待审，也可以在目标、环境和风险明确后，授权连续完成交付。

更进一步的方向是：负责人预先批准一份有范围、期限、数量和停止条件的配置，再由配置启用后新增的真实采纳决定选出事项。工具仍须核验事项、认领和已发生结果，才能开始实施。

两者共享一个要求：执行权来自可核验的有效授权。群里提出反馈、Issue显示已采纳、模板已经保存，都不能单独启动开发。

本书编写时，现行规范仍明确业务自动开发尚未启用。原生任务模板、离线辅助和既有实践的详细状态，要结合第12章与有日期的接入记录理解；阅读流程图不会使这些能力自动启用。

适合从范围明确、结果可观察的协作开始，例如产品咨询、证据充分的缺陷反馈，以及负责人已经明确目标的小范围研发任务。

判断是否适合时，可以问：反馈来源能否核验？事项能否准确定位？目标和验收能否说清？工具是否具有对应能力和权限？发生未知结果时能否查到原任务？这些问题有清楚答案后，再逐步减少人工转述。

对于目标仍在争论、需要新权限、涉及不可替代数据或缺少恢复条件的工作，先完成相应调查和决定。HiveFlow保留这些判断，不把“自动”作为跳过它们的理由。

群用户可以先读第4章，负责人先读第5章与第7章，维护者先读第2章、第11章和第12章。第14章把同一个例子完整走一遍；第15章说明网站怎样从各章取材。

准备实际执行任务时，从主仓库根规则和HFL加载入口进入，按任务读取对应章节。手册中的合成案例用来说明方法，不是对真实事项的授权、排期或完成声明。