图书系统人工测试已经快一周了。前几天我把供书商、代理商、管理员和员工的流程逐个跑了一遍，前面的图书ERP人工实测记录里已经写过这一轮的实际问题。
今天总对话终于撑不住了。一个小小的任务，正常一两分钟就能做完，这一次却做了整整30多分钟。
任务本身不大，真正拖慢我的，是反复出现的上下文压缩。
Codex语音助理上线后，我把上午留给规划
最近我的工作状态也有了调整。现在我给自己的分配是：上午8点到11点，到城市书局里面，带上笔记本，只做规划性工作、发清单和远程 Codex 开发方面的任务。
中午吃完饭以后健身，然后进行重度开发和一些需要语音对话的工作。
城市书局里的氛围很特别。很多考公、考研的，早上5点多就能到，一直学到晚上十一二点才回家。在这种氛围下，感觉抬头超过1分钟都是不齿的。2到3个小时的规划性工作，可以安静地做完。
今天 Codex 也进行了一个比较大的更新，增加了语音助理。以前这是 ChatGPT 对话里的功能，手机上我偶尔会用一用。现在直接装到 Codex 里面了，而且可以静默运行。
也就是说，我在电脑上做别的事情，或者在 Codex 里面跑着某一个开发对话，它都可以一直待在右下角，实时接收我的语音消息，中英文都可以。
它在 Codex 里面的好处是，它也是一个真实的任务对话。比如让它帮我看看现在屏幕里的某个东西，帮我截个图，或者快捷地打开一个网页，只需要一句话就可以。
“帮我打开谷歌浏览器”“我百度一下 XXXX”“帮我登录我 B 站”“帮我把朋友发给我的这个网页采集下来。”以前买过海盗船的 Elgato，也长期用过 YouTuos 的快捷搜索和 AI 聚合回答，都不如现在一句话来得方便。
我相信，就这一个小小的更新，将带来极大的效率推进。
Codex上下文为什么会反复压缩
我去看了一下细节执行流程，前后进行了大约6到7次上下文压缩，而且很多压缩其实没必要。
比如明明任务已经完成了，不直接汇报，而是因为上下文背景不够用，又重新压缩。压缩完以后，再执行一遍，再汇报。
这种情况最早我在 Codex 里面碰到过，后面很少再发生。除非上下文特别多，而且没有进行本地的文档和进度部署。
总之，任何对话单次能提交的文本长度都是有限的。尤其是中大型项目，不能只靠一个对话一直往下堆。
图书ERP人工测试，进度不能只留在对话里
我们要尽量学会流程化、规范化地开发，尤其是让它自己在本地的 Markdown 文档里面，记录每一个板块现在的情况。
就像我们开发一套课程，要写课程大纲，还要用思维导图把每一节课要讲的知识点全部罗列出来。任何时候、任何地点，只要打开这个思维导图，就知道现在还有哪些地方没写，哪些地方要优化，现在是第一版还是第二版。
跟 AI 对话其实也是这样，尤其是一些中大型项目。我们不是专业的程序员，但在 AI 开发的时候，这些方法还是需要去了解和运用。
不过这种愣头青的持续对话也并非不可用。当出现这种频繁压缩上下文的情况时，可以立刻中断当前对话任务，让当前对话把现在的进程总结到本地 Markdown 文档里面，再给出一段新的提示词。
然后在同一个项目下新建新的对话，把接手提示词发给它，它就会顺理成章地继续去做。之前我把图书 ERP 放到另一台 Mac 上重构时，也是在反复找一套能让项目持续交接的方式，具体过程写在另一台 Mac 重构图书 ERP 的记录里。
这次遇到的不是系统做不出来，而是提醒我：对话再长，也要给下一次接手留一条清楚的路。
图书ERP内测前，人工测试还要继续跑
问题不大，这套系统我预计三天之内就可以进行内测。我真人对每一个环节进行实际测试之后，接下来就是内部去实战角色流程。再往后一个阶段，可能会发起众筹，对内部股东开放使用。
之前的日记里面，我其实也提到过，优化是一个持续而漫长的过程，或者说，它本来就是一个常态化的工作。
因为平台的规则一直在变，所以做出来的系统也要一直适应新的规则、新的玩法模式和用户需求。
现在先把这几天的人工测试继续跑完。等内测真正开始以后，很多现在看不见的问题，才会慢慢冒出来。