图书ERP的录书流程，前面已经把单本跑通了。手机扫 ISBN、拍实拍图、资料进库存，这一套在人工实测里已经能走下来。
下一轮我不准备再坐在电脑前盯着一个演示页面，而是直接拿 50 到 100 本实体书来连续录。因为一本到十本，和一口气录几十本书，完全不是同一回事。前者能证明功能存在，后者才能看出这个流程能不能真的交给人做。
这次测试不是为了凑一个数量，而是想把录书这件事里最容易被忽略的地方全部挑出来。
从录一本到连续录一层货架，测试重点已经变了
前一轮的重点，是先确认小程序能不能把 ISBN、图片和图书资料带回图书ERP。这个节点已经记录在前一轮图书ERP人工实测记录里。
现在往前走，关键就变成了连续操作。收书的人不会每录一本就停下来重新选位置、重新找入口。货架位置选定以后，最好能围绕这一个位置不断扫书、拍图、提交，直到这一层录完。
所以这次批量测试，先看的不是“扫一扫有没有反应”，而是连续录到第十本、第三十本以后，页面会不会乱，位置会不会丢，图片会不会漏，提交以后人要不要反复回头补资料。
ISBN、货架位置和实拍图，要在一本书里一起完成
二手书录入不是只有一个 ISBN。扫描只是把书的基础资料带进来，后面还要确认这本书放在哪个货架，实拍图有没有补齐，资料是不是已经进入后台。
尤其是图片这一块，做演示时很容易被忽略，真正上架时却不能少。封面、书脊、正文这些信息如果不在录书的时候一次完成，后面再回头找书、补拍、补传，效率会比现场多花很多。
批量录书最怕的不是慢一点，而是录完一堆半成品。 书已经扫进去了，图片没齐；位置写了，后台没回来；库存里有记录，但后面上架的人不知道能不能接着处理。这样的量跑得越大，后面返工越多。
批量录入后，后台库存记录必须马上接得住
录书的小程序和后台库存，不应该是两套各自好看的页面。小程序提交以后，后台需要能看到这本书的录入记录、资料状态、价格状态和后续要不要上架。
所以这 50 到 100 本书录进去以后，我会顺着后台再看一遍：有没有重复记录，有没有资料缺失，库存状态是不是正确，人工操作中出现的问题能不能被查回来。只要某个环节只能靠人凭记忆找，就说明它还没有达到批量操作的要求。
这次不先给效率下结论，先把卡点抓出来
现在还没有必要提前说一小时能录多少本，也不急着给这套流程打分。先把书录进去，把连续操作跑起来，再看时间真正花在哪儿。
有些问题可能在第一本书时根本看不出来，例如货架代码要不要反复选择、图片上传是不是会拖慢、网络变化后数据会不会丢、资料不完整时怎么补。只有连续录一批，问题才会自己露出来。
这一轮结束后，我更想看到的是一份真实的记录：哪些步骤已经不用人管，哪些步骤还得优化，哪些要求其实一开始就定错了。系统要服务的不是演示，而是每天真的有人拿着书站在货架前操作。
图书ERP后面还要接上上架、发货和电商账号，但录书这个入口如果不顺，后面每一段都会被拖慢。关于为什么要做图书项目，以及自动化上架和ERP的关系，我之前写在图书项目最开始的规划里。先把第一段录稳，后面的链路才有意义。