模块做出来了，接手的人却不知道从哪下手
用 AI 构建器搭一个业务模块，快的时候一次会话就能出结果：页面有了、字段有了、菜单挂上了。但真正让模块活起来的，往往不是开发那几分钟，而是后面交接的那几十分钟——同事打开页面第一句话通常是「这东西怎么用？哪些字段是我要先填的？」
过去这个问题靠两种办法解决：一是做模块的人口头讲一遍，二是让 AI 在会话里重新解释一遍。两种办法都不留痕，人一走、会话一关，说明就没了。
今天上线的能力解决的就是这件事：每个由构建器生成的业务模块，详情页新增「交付说明」，把「这个模块是什么、怎么用」随模块一起交付。
交付说明是两层文档，不是一份说明书
打开任一模块的详情页，第四个 tab 就是交付说明。它里面放的其实是两份读者不同、更新方式也不同的文档。
第一层：结构骨架。 这是给看得懂系统的人看的清单——这个模块有哪些页面、页面上有哪些字段、字段是什么类型、后端开放了哪些接口。它不写死，而是每次打开时按模块当前状态实时现抽（从模块的实际结构里现场读取生成），所以你看到的永远是此刻的版本，不担心「文档写着 5 个字段、实际已经是 8 个」。
第二层：面向管理员的叙述文档。 这是给业务管理员和交接人看的正文，讲三件事：
- 数据怎么建：先维护哪张基础数据，再有哪张业务单据，谁引用谁；
- 页面怎么用：列表页能筛什么、表单页哪些字段必填、状态是怎么流转的；
- 上线前查什么：发布之前应该确认的几件事，比如权限给了谁、移动端是否需要同步、有哪些必填字段会影响导入。
这一层是 AI 生成的叙述文本，生成后带内容哈希缓存——模块结构一变，哈希对不上，这份文档就自动失效并重写。换句话说，它不会在模块改版之后还留着旧说辞，把新来的人引到一条已经不存在的路上。
两层分开的原因很实际：结构骨架回答「系统里有什么」，叙述文档回答「我该怎么做」。前者适合做交接清单和排查依据，后者适合直接发给要上手用的人。合成一份，两边都不好用。## 它在真实流程里省掉哪几步
换人接手。 做模块的同事离职或转岗，接手人不必翻会话记录，也不必去问「当时是怎么设计的」，进详情页看交付说明即可：先按叙述文档把基础数据维护顺序走一遍，再看结构骨架确认还有哪些字段没用上。
找 AI 改模块之前。 想让构建器给某个模块加字段、加审批，最有效的方式是把现状说清楚。交付说明里的字段清单和页面清单，正好是可以直接引用的描述素材，比「帮我改一下那个报工模块」有效得多。改完之后的写法，可以参考 修改与编辑模块：指令写法、错误账本与版本回滚。
应对内部或外部审核。 审核方常问「这套东西谁维护、字段依据是什么、权限怎么控」。结构骨架里的页面与字段清单，加上叙述文档里的使用说明，构成一份可交付的说明材料，而不是靠人现场解释。
新人培训与口径统一。 同一个模块被三个部门用，用法经常各不相同。把交付说明当成统一说法发出去，比每次口头纠正省事。
它不替代哪些事
写清楚边界同样重要，免得对这份文档期待过高：
- 它描述的是模块「现在长什么样、怎么用」，不是业务验收报告。字段是否覆盖了真实的业务情形、判定规则是否符合行业惯例，仍然要业务人员确认。
- 它是 AI 依据模块结构生成的叙述，不是人工撰写的操作手册终稿。涉及合规、财务口径的模块，建议人工看过再对外发放。
- 它不覆盖平台层面的配置（组织、角色权限、菜单可见性）。这部分请参考 角色与权限配置：从内置角色到自定义授权 与 部门与租户：搭好组织的骨架。
上线前后的动作怎么配合
交付说明是「事后说明」，模块从生成到上线之间还有几个动作要自己做：
- 模块在构建器里生成后，先在沙箱里把主流程走一遍，确认字段和状态流转对得上；
- 需要手机端一起用的模块，确认移动端伴同页已同步，员工在现场才录得进去；
- 发布走预检，把发布前的检查项过一遍，避免带着明显问题挂上菜单；
- 上线后把交付说明的叙述文档发给实际使用的人，作为上手材料。
第 2、3 步的做法在 模块的测试与发布：预检、挂载菜单与移动端同步 里有完整说明；整个构建流程的起点，可以从 AI 构建器操作手册：界面、会话与开发全流程 看起。如果还不确定 AI 构建器能做出什么形态的模块，MES 起点：生产工单与报工数字化 是一个可以直接对照的例子。
怎么自己验证
登录平台，打开任意一个由构建器生成的模块，进入详情页，第四个 tab 就是「交付说明」。建议顺手做一个动作：让 AI 给这个模块加一个字段，再回来看交付说明——结构骨架会跟着变，叙述文档会重写。这一步能直观看出它是跟着模块活的，而不是一份写完就停的文档。
目前这项能力对构建器生成的所有业务模块默认生效，不需要额外开启。使用中遇到说明与实际不符的情况，可以在模块详情页提交反馈，我们按反馈修正生成逻辑。