你的一天，可能像这样
上午客户 A 说「这里改一下」，下午项目 B 报了个线上 bug，晚上你想推进 C，结果打开仓库看了十分钟，才想起上周为什么把那个模块拆成两半。
三个项目同时推进的人，输的从来不是打字速度。输在这几处：
- 需求在微信里：改了什么、谁确认的、什么时候要，翻聊天记录比写代码还久。
- 「改好了」没有标准：你自己也不知道算不算改好，客户更不知道。
- 上下文靠脑子存：一周后再回来，等于重新入职一次。
- 不敢接第四个：不是没时间，是没余量应对「忘了」。
这四条都不是「AI 帮我写快一点」能解决的。它们要的是流程，不是更快的补全。
让 Agent 干活不难。难的是它干完之后，你还知道它干了什么、凭什么算干完了。 —— 我们把「验收命令」写进任务卡的原因
这套东西不是为卖给你设计的
它是我们自己在用的开发方式。十天里 100 张任务卡、94 份结果、131 条验收命令，跑在三个仓库上——我们既是作者，也是第一个用户。日志在这儿，可以逐条核对。
把「记得住」和「验得清」交给系统
下面这张表就是我们每天的实际分工。左边是可以机械化的，右边是你不能交出去的部分。
| 环节 | 机器做什么 | 你做什么 |
|---|---|---|
| 需求入队 | 把客户的一句话变成一张任务卡：改哪个目录、跑什么验收命令、依赖哪张卡、最多重试几次 | 判断这张卡的边界对不对——拆错卡，后面全错 |
| 执行 | Agent 领卡、在独立分支与工作目录里改、写测试、提交结构化结果（改了哪些文件、退出码多少） | 不需要在场。它跑它的，你做别的 |
| 验收 | 跑卡上声明的验收命令；失败就带着输出退回，连续失败到上限转 blocked，不再空转 | 合并前看一眼 diff 与结论——这是你唯一必须做的事 |
| 上下文 | 把架构决策、踩坑、客户偏好写进记忆服务；下次开新会话先 recall，再动手 | 决定什么进长期记忆，什么只是临时草稿 |
| 多机并行 | 笔记本跑前端、旧台式跑测试、云主机做夜间批处理；一台挂了任务被回收重派 | 决定今晚排哪几张卡 |
| 交付 | 给出可复跑的验收清单：谁验的、验了什么、结果如何 | 和客户确认「这样算完成」，把口头承诺变成可核对的清单 |
最右边那一列都很短，但没有一条能被替代。这套方案提高的是吞吐，不是判断力——如果你不会拆卡，它只会让你更快地做错。
这些数字不是估算，是日志
来源：hive/tasks/ 与 hive/results/，2026-10-23 至 11-01。
十天，九十四份结果
100 张任务卡里 98 张已关闭，94 份结构化结果：93 张 done，1 张失败（机器上没配某仓库的本地路径，失败原因原样记在结果里）。
每份结果都带分支、基点、改动文件清单、验收命令与退出码。这意味着三个月后你还能回答「这个改动当时验了什么」——这是 chat 记录永远给不了的东西。
131 条验收命令，全部通过
其中 93 条是 pytest，23 条是自写校验脚本，其余是构建与语法检查。不是形式化 smoke test：卡上写什么就真跑什么，跑不过不许提交。
被杀 32 次，0 失败
20 分钟浸泡测试：3 个 worker 抢 240 张卡，期间随机 kill -9。结果 240 张全部完成、失败 0、缺结果 0；租约回收重试 7 次，已分派未领取重派 13 次，没有出现一张卡两份结果。
这才是「多机并行」能不能用于生产的分界线：不是跑得快，是坏了能自己收场。
代价也写着
每张卡都要写得出验收命令；卡太细会淹没在协调开销里；Git 仓库是单点。这三条我们写在案例里，没藏在脚注。
接第四个项目的底气从哪来
不是因为你变快了，是因为「切换」这件事不再吃你的脑子。
现在
一周后
四条不承诺
软件这一行，夸口的代价是线上事故。所以我们先把话说死。
诚实清单
- 不承诺工期。卡跑得快不代表需求清楚；需求不清楚时，机器只会更快地做出错的东西。
- 不替代代码评审。合并前必须有人看 diff。这个人是你，不是工具。
- 不保证一次就过。我们的日志里有失败卡和未修的 bug，案例里写着。
- 不做多租户 SaaS。这套东西是按「几台自己的机器」设计的，客户数据要隔离就分仓、分机器、分租户。
接活的人最关心的四件事
AI 写的代码，敢上线吗？
取决于你有没有验收。我们把「能上线」定义得很土：有测试、有验收命令、有人看过 diff。三条缺一条就不算完成，「跑起来了」不算。你要是接受「看起来能跑」就合并，那用什么工具都会出事。
客户的数据和代码放哪？
放你自己的机器和你的 Git 仓库里，模型请求走你自己填的 Key。我们不中转、不存储。一个客户一个仓库、一个租户，记忆也按租户隔离——这比任何「我们承诺不泄露」的条款都实在。
我怎么知道它真的干完了？
看结果文件：领卡时间、耗时、改了哪些文件、验收命令与退出码、是否越出你声明的可改路径。任何一项不对，这张卡就不该合并。不用信它的自述，看它的证据。
我不是科班出身，学得会吗？
这套东西对你的要求是「会拆活、会写判据」，不是「会写代码」。反过来说：如果你拆不清一张卡的边界，工具也帮不了你——它只会把你的模糊放大成返工。
从一张卡开始
不要一次上三台机器。先在你自己的电脑上，让一张卡跑完「派发 → 执行 → 验收 → 结果」。
git clone https://github.com/skywalk163/hive.git # 国内慢就换镜像：https://gitcode.com/skywalk163/hive.git cd hive && python3 hive.py --dir . init python3 hive.py --dir . task new --title "给设置页加一个导出按钮" \ --repo my-app --paths src/ --verify "npm run build && npm test" python3 hive.py --dir . dispatch python3 hive.py --dir . work --agent my-laptop
跑通之后再加两件事：装记忆让它记住这个项目的决策；把第二台机器拉进来当夜间班次。顺序别倒——先能验收，再谈并行。
你可能还需要
- Python 3.10+（hive 核心只用标准库）。
- 一个能 push 的 Git 远程仓（GitHub / 自建 Gitea 都行）。
- Go 1.25+（如果要装记忆服务）。