发送端说自己按约定写了，接收端也说自己按约定读了。如果两边恰好犯了同一个错误，一次自发自收也可能看起来正常。
所以汇合需要独立对照：自己的发送器交给参考接收器；参考发送器交给自己的接收器；最后再把自己的两端接在一起。
两位建设者各自复述：长度指字节还是字符，字节序是什么，正文用什么编码，不完整数据怎样保留，错误格式怎样报告，回执确认的是哪个阶段。
若两份复述不同，先处理约定，不急着为各自代码辩护。它们可能都在忠实实现不同的理解。
在教材目录运行：
py -3 -B practice/check.py学生起点故意未实现。完成两函数后，预期四项检查通过：与参考接收器互通、从每个截断位置正确等待、粘连消息分离、坏帧与未完成尾部不冒充成功。
参考实现的入口是：
py -3 -B practice/check.py --reference它只检查参考解，不代表学生任务已经完成。也不要修改验收脚本来让错误实现变绿。
停止原服务或换一个端口，运行：
py -3 -B lab.py --codec student --port 8037启动冒烟会用一条中文与表情消息交叉核对。通过后，网页里的实际发送、接收和工作台都会使用这份学生实现。冒烟不能替代完整测试，但能拦住最直接的不兼容。
在新房间走一遍：发一封带编号的消息 → 对端解析 → 对端发 received → 原发送者得到匹配回执。记录每一步在哪里有证据，不借后台复盘倒推“发送时已经知道”。
可以让 AI 实现一个函数、生成边界输入或解释失败。人要核对协议、运行测试，并让解释落到实际字节和分支上。
运行角色实验时，导出自己角色的信息包，把它交给 AI 作为本角色分析搭档。返回的动作建议先预览，再执行；新来信会使旧建议需要重新检查。
如果你同时阅读双方信息包并转交 AI，就应标为演绎观察。要让 AI 真正独立扮演另一端，需要独立操作者或受限工具接入；本版不自动调用外部模型，也不能把全知中转者算成原模型中的局部角色。
无模型账号时可以由两位学习者分工，或在已标明规则的脚本搭档模式中练习。脚本不是语言模型，能够识别的提议模板与行动规则会公开说明。
回到双方各自的窗口，写下行动或等待的依据，以及仍未知的部分，然后固定选择。若两人都等待，可能避免了单方行动，却没有推进本次任务；若一方行动，复盘会如实显示单方行动，不由中央程序替它撤销。
导出局部记录，再看全局复盘。对照“当时可知”和“事后实际发生”，指出一处不能由成功提示推出的结论。下一步到 V1 的边界，为系统选择下一项建设。