👁 477

起因

最近 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 不写代码了，专注做它擅长的——串联验证发布流程。

    延伸阅读：Route Tool：eMMC 信息测速备份插件

    阅读： 477