起因
最近 route-tool 插件收到几个小反馈，我随手丢了几条数据给 Hermes Agent，没想到它一口气把改代码、打包、验证、发布全干了。
丢的数据就这些：
- eMMC 版本显示 5.01 但编程器测出来是 5.1
- "MTK 的 u-boot-env 分区不需要备份和写入，去掉它"
- 几个新 MID：海力士 0x90、长江存储 0x9B、康芯威 0x2F
- "实际上现在路由用到的 eMMC 基本都是 5.1 的"
- "更新的品牌数据不要推 GitHub，做个人用"
就这么几句话，零散信息。但 Hermes 把每一条都落地了。
它怎么干的
版本判定：我说了句 "路由器基本都是 5.1"，它就去读 ext_csd byte308（CMDQ 支持位），判定逻辑改成 byte192=5.01 + CMDQ=1 → 显示 5.1，同时保留原始值和判定依据说明。
分区移除：我说 "去掉 u-boot-env"，它找到 4 处引用一次性全删——allowed_part、分区列表、label 映射、note 映射。
MID 品牌：我给了三个数字和名字，它写进品牌映射表。
不推 GitHub：我说 "个人数据不推公开仓库"，它就推 GitHub 前临时移除个人 MID、推完再加回本地、打两套 IPK（公开版 38 家、个人版 41 家）。
每改一处，自动打包 IPK → SCP 传路由器 → opkg 安装 → 实机验证输出，30 秒一轮。
人和 AI 各干什么
说白了：我给的是方向性的碎片信息——一个判断、几个数字、一条业务规则。不是详细方案，不是设计文档，更不是伪代码。
AI 干的是把这些碎片拼成完整改动：
- 知道"去掉 u-boot-env"意味着去主后端找所有引用
- 知道"不推 GitHub"意味着代码仓库和个人 IPK 要分开管理
- 知道每次改动后要打包验证才能确认没出问题
这些执行层面的连贯性，人做起来又慢又容易漏步骤。AI 不漏，而且快。
但是方案判断必须人来
AI 可以帮你改代码、跑验证，但有些事它做不了：
比如 eMMC 版本判定，我凭的是编程器实测数据——5.1 颗粒 byte308 都是 1。这个观察不是 AI 从协议文档推导出来的，是我拿着编程器一颗颗读出来的。协议确实定义了 byte192 = EXT_CSD_REV，但它没告诉你很多 5.1 颗粒会报 5.01。实测比协议更接地气。
再比如 "个人 MID 不推 GitHub" 这条业务规则，AI 不可能自己想到——它不知道哪些数据有知识产权考量，哪些只是个人库补充。
下一步
今天还有一个认知：代码改动本身也应该拆给 Codex 或 Claude Code 做。分工改成：
- 我：随手丢数据和判断
- Codex/Claude Code：改代码
- Hermes：打包验证、推 GitHub/Halo
这样 Hermes 不写代码了，专注做它擅长的——串联验证发布流程。
by 数码罗记 · godsun.pro