Dots
理解问题、调查事实，登记Issue并保留源头采纳决定。
具体模型以账号和平台支持为准。蜂巢的第二个副产物 / HIVEFLOW
让协作，
自己向前流转。
云端理解反馈，Issue交接到MacMini。
人决定目标与范围，Codex承接研发，
把有证据的结果带回。
规范持续演进 · 当前自动开发未启用
一条反馈，怎样接到下一步HIVEFLOW / 01
01云端dots理解反馈、调查、登记
↓02GitHub Issue准确事项与事实的交接点
↓03MacMini上的Codex在有效授权内研发与交付
↶ PR待审后由你再决定合并、部署
完整交付在明确范围内连续推进。
完整交付在明确范围内连续推进。
流程示意 · 定时业务执行尚未启用
复用现成能力
让不同工具，
各自承接清楚的责任。
从反馈、决定到实施和结果通知，
每一段都有明确的对象与依据。
GitHub Issues
连接准确事项、目标、候选和交付证据；登记与实施分别核验。
Issue存在不等于获得开发许可。Codex
在Director的MacMini承接手动任务或原生定时任务，按所选终点交付。
两种启动方式，都有两种交付终点。企业微信与桥接
在管理员接入并授权的工作群沟通，通过固定来源把允许的结果带回。
wecom-slack-bridge ↗工具保存、核对和传递事实，Director负责目标与授权。平台名称和消息路由本身都不授予权限。
从蜂巢实践中生长
同一个起点，
三个相互配合的部分。
产品提供工作空间，
工程方法组织研发，
HiveFlow连接反馈与交付。
起点 / PLATFORM
蜂巢 ↗
Agent在哪里工作？员工数字分身的平台，连接对话、文件、工具与工作环境。
第一个副产物 / METHODACDL ↗
研发怎样有据可循？组织需求、设计、实施、评审与版本，按实际风险选择需要的工作。
第二个副产物 / FLOW
HiveFlow ↳
反馈怎样接到交付？把源头反馈、采纳与授权、本地研发和原来源回执连成可接续的过程。
以Issue交接
反馈在云端整理，
研发在MacMini继续。
Issue之后的本地研发，
由实际任务与有效授权推进，
不等待云端逐步转述指令。
先理解，再登记
已有权限内调查，符合条件才登记。核验真实Issue与原来源，先向反馈者说明登记结果，再按源头流程核验采纳决定。
核验事实，承接研发
手动任务在可信执行会话核验，定时任务依据预先批准的有效配置。复用已完成的候选与检查，不为同一事项重新开发。
01 / 采纳
值得做
采纳记录价值判断，不能单独产生代码修改、合并或部署权限。
02 / 授权
可以做到哪里
一次说清目标、范围与终点，已经明确的同范围步骤连续推进。
03 / 证据
实际完成什么
修改、检查、合并、部署、验收与通知分别核验，不用一个状态代替全部结果。
两种启动 × 两种终点
怎样开始，
与你希望做到哪里分开选。
手动和定时都能选择PR待审或完整交付。
定时生成的PR仍然等你决定后续；
完整交付减少范围内的重复确认。
手动启动 / PR待审
先交给你看，再决定后续
你在MacMini的可信Codex会话发起任务。完成开发、检查与PR后停止，等待你决定并推进合并、部署。
本地介入：启动1次，PR后再1次。
手动启动 / 完整交付
一次授权，推进到约定交付
你明确目标、范围、环境与验收。Codex在有效授权内连续完成必要审阅、修正、合并、部署、验收和收尾。
本地介入：完整授权1次，正常路径接收结果。
定时启动 / PR待审
本机定时准备候选
先批准并实际启用有界配置，本机任务才可定时选单。每单完成PR后，仍需你再介入一次处理合并、部署。
本地介入：无需逐单发起，PR后介入1次。
定时启动 / 完整交付
有效配置内，连续完成交付
本机任务核验配置、事项与已有工作，满足选单及所需认领条件后，连续完成规定审阅、合并、部署与验收。
本地介入：无需逐单发起或例行确认。
这里统计MacMini研发阶段。
源头采纳与定时配置授权另计。约定由你亲自验收，或遇到新的重要取舍、超出授权的问题时，按实际情况再介入。当前业务自动执行尚未启用，定时路径展示的是有效配置下的工作方式。
查看Director介入次数与条件 →给工作群里的每个人
像平常一样，
把事情说清楚。
在管理员接入并授权的工作群，
选择并@实际助手，说明现象与期望。
“@助手”是示意，名称以本群机器人为准。
@助手 我想把本月的记录导出来，应该从哪里操作？
@助手 选了整个月再导出，文件仍只有第一页。预期是全部结果。
@助手 每周都要手工整理记录，希望能按日期一次导出。
- 说明场景与现象
- 调查或补问关键事实
- 符合条件时登记
- 负责人评估决定
登记不等于采纳、排期或开工。补充信息时自然点明事项，不依赖永久记忆或原生引用自动续接。
阅读完整使用指南 ↗已有
规范、手动实践与离线检查
有手动交付及单次原来源回执的实践。文档、合成演练与真实联调各自记录，不能互相代替。
未启用
业务自动开发
原生定时模板和受控采纳方案已有定义；真实启用、认领、取消和恢复仍需对应范围的现场验证。
分别核验
业务完成与通知结果
合并不等于部署，部署不等于验收，平台确认不等于用户已读。未知先查原结果，不盲目重放。
12章正文 + 3篇附录
从一个问题，
读懂整条协作过程。
按介绍手册连续阅读，
或直接查当前关心的部分。
每篇都保留对应来源。
01
认识HiveFlow
理解HiveFlow解决的问题，以及它与蜂巢和ACDL的关系。
↗02角色与工具
云端dots、Director、MacMini上的Codex与消息桥接分别做什么。
↗03流程总览
从群反馈到Issue，再到本地研发；查看四种组合与介入次数。
↗04群里反馈
怎样提问、描述现象、补充信息和理解登记结果。
↗05采纳与授权
把值得做与可以做分开，一次说清有效任务范围。
↗06事项状态
评审、处理进度、正式登记与交付事实各自表达。
↗07两种交付
选择停在PR待审，或在授权内完成约定交付。
↗08交付与回执
交付记录怎样对应原反馈者，通知未知时怎样处理。
↗09原生自动化
在本机准备有界定时配置，核对选单与启用条件。
↗10采纳交接
受控决定怎样生产、认领、取消和恢复。
↗11调查与恢复
核对版本、只读调查、保护隐私并接续未知结果。
↗12接入与验证
分清文档、合成演练和现场证据，不夸大已经具备的能力。
↗13术语与常见问题
查术语、状态和经常混淆的问题。
↗14完整案例
沿一条合成导出问题，看两种交付终点和异常处置。
↗15网站取材与维护
规范怎样进入介绍，再成为网站的原始材料。
↗内容从哪里来
规范 → 介绍 → 网站
HiveOS规范保存执行规则，介绍手册解释方法与案例，本站据此整理公开内容。新规则先回到规范确认，再向下同步。
独立项目hive-flow已按Apache-2.0开源，提供规范参考版、介绍与离线工具。官网源码flow同样采用Apache-2.0，两仓各自保留LICENSE与NOTICE。HiveOS主仓库仍为私有，公开不授予真实业务访问或执行权限。
来源：HiveOS 51926b24 · 内容核对：2026-10-20 · 上游介绍手册状态：Review
从反馈，到有证据的交付