今天我手动拉闸，把 Codex 的目标模式先停了。
不是系统不继续做了，而是我越来越觉得：再让它按照目标模式跑一个月，也不一定能跑到我真正想要的样子。系统永远有能扩充、能优化的功能，AI 也并不知道我们现场真正要走什么流程，更不知道什么样的操作顺序和 UI 才是员工顺手的。
对于现在的图书项目来说，基础链路没有大的漏洞，人工把整个流程跑下来能稳定使用，就已经到了可以准备内测的条件。再无止境地让它自己优化，最近速度又慢，性价比确实不高。
大纲速览
图书ERP人工实测，先从清单一条条往下跑
我让 Codex 把所有需要人工核验的目录清单列出来。接下来不是坐在这里看它自己跑，而是我亲自把这些流程都走一遍：哪里该补功能，哪里该少点一次，哪里后台和小程序接不上，就一条条改。
等所有人工核验流程都跑通，再集中修一轮整体 Bug，才是我现在理解的内测上线。
今天，先跑通了两条最核心的流程：书籍录入和图书上架。
ISBN扫码连续录书：一部手机就能当扫码枪
录书这一段，是从微信小程序进去。小程序本身就有 ISBN 扫码和拍照能力，所以任何一部手机都能直接当扫码枪用。扫到 ISBN，拍完实拍图，资料就能进入 ERP 系统的库存里。
我这次还把小程序改成了连续录入。先选好货架的位置代码，后面就能盯着这一层货架，一本接一本地录。对真正收书、录书的人来说，这比每录一本就重新选一次位置，要省掉很多重复动作。
不过，流程能通只是第一步。今天和朋友聊完以后，我又发现小程序还有继续改的空间。真正拿着手机干活时，前后顺序、页面跳转、信息怎么留在当前操作里，都会直接影响效率。看起来不大的一个细节，放进连续录书的场景里，就会变成很明显的卡顿。
图书上架定价，不能只看 ISBN 给出的建议零售价
一本书录完上架以后，根据 ISBN 能拿到建议零售价。我们现在的想法，是把建议零售价、实际售出成本和运费一起带进来，再由 AI 给出一套二手书的建议价格。
但这套机制不能生搬硬套。很多老书以前的标价只有几块钱，甚至几毛钱，只按建议零售价推，结果肯定不严谨。所以这里还得设置一个最低阈值来托底，不能让一套看起来很聪明的规则，把真正的定价带偏。
这也是人工实测的意义。前面的小程序自动测试已经做过，我在前面的小程序自动测试里也记过。当时主要看功能能不能跑；现在要看的，是人拿着真实的书、真实地录、真实地上架，这套流程到底够不够快、够不够顺。
后台记录、员工权限和库存数据，都得跟着一起验
录书不是资料进后台就算完。后台要能看见库存记录，资料状态、价格状态和待上架的商品要能跟得上；谁录入、谁处理、哪一步没有完成，也得能查得到。
员工账号也一样。录书、接单、发货这些动作，后面不会全部由一个人做。权限给多了不放心，给少了又会让员工卡住，只有真的按角色把页面点一遍，才知道哪里需要收，哪里又该放开。
所以我现在不只是看一张页面好不好看，而是看一个人从登录开始，到录书、上架、接单、发货，能不能把自己的那段事情走完。只要还需要别人反复解释，或者得绕一个页面才能完成，就说明这条链路还要继续修。
接下来录50到100本实体书，再把闲鱼账号一起拉进来
另外，我已经带了两位伙伴，分别开始测试批量图书录入上架，以及闲鱼电商自动化上架流程。
今明两天的目标很直接：录入 50 到 100 本可用实体书，再用 3 到 5 个闲鱼账号把全流程跑一遍。重点看数据隔离有没有问题，批量操作时哪里还会拖慢效率，哪里值得继续改。
第一阶段，用 AI 把东西做出来。第二阶段，用 AI 去测 Bug、看链路有没有断。现在正在跑的第三阶段，才是把它放进真实项目里，看看它到底能不能替人省时间。
系统不是做出来就结束，真正能在现场跑起来，才算过了这一关。
最开始为什么要做图书项目，以及图书 ERP、自动化上架和长期做这件事之间的关系，我之前写在最开始做图书项目的记录里。现在回头看，前面把系统搭出来只是一个开始，真正的答案，还是得靠这几天一趟一趟地实测出来。