ch15-15 每章验收标准

返回本章

先定交付标准

每章验收标准要像工程 checklist 一样可执行，而不是像编辑口号。读者翻完一章后，应该能用源码、命令、截图、事件或测试证明自己真的掌握了这一章，而不是只觉得“看懂了”。

源码入口

• book/ch13/README.md：本章验收和交付证据来源。
• book/ch14/README.md：本章验收和交付证据来源。
• book/ch15/README.md：本章验收和交付证据来源。
• book/ch15/code/s01-move-test-template/README.md：本章验收和交付证据来源。

从章节到验收证据

章节验收包括五类证据：概念能复述，源码能定位，代码能运行，失败能解释，风险能披露。只满足前三项还不够，因为 DeepBook 应用最常见的问题往往出现在失败路径和数据延迟上。

每章验收标准应同时检查概念、源码定位、运行步骤和风险说明。对 ch13 要能跑通 Indexer/Server 路径，对 ch14 要能演示一个应用闭环，对 ch15 要能证明测试、安全和部署证据完整。

章节作者在交稿前至少要问一次：这一章有没有仍然像“介绍文档”的小节？有没有只给链接、不解释字段的源码引用？有没有用“未来会支持”替代当前网络状态？这些问题不解决，就不能算出版社级别。

交付判断

• 每个测试或部署结论都要能回到具体命令、fixture、日志、指标或审计材料。
• 同时覆盖成功路径、失败路径、边界值、权限错误和数据延迟。
• 升级、迁移和部署步骤要写明回滚点、兼容窗口、健康检查和负责人。
• 涉及资金安全时，把链上约束、SDK 构造、Indexer 读模型和前端提示分层验证。
• 对短小节额外检查：是否有真实场景、源码依据和读者可执行任务。

动手检查

• 这一章最关键的三条源码路径是什么？
• 这一章的代码示例在哪里运行，预期输出是什么？
• 这一章最容易误导读者的产品边界或网络状态是什么？