模块的麻烦，常常从「不用了」开始
AI 构建器把"建一个模块"的门槛拉得很低：一句业务需求，就能得到一个带数据表、管理页面和手机端的业务模块。门槛一低，企业里就会自然长出一批模块——试点的安全检查、临时用的样品登记、被正式系统替换掉的老台账、外包做到一半又停下的派单页。
建出来都不难，难的是不用了以后怎么收场。这件事过去只有两种结局：直接删，或者放着不管。
直接删的问题很直观：删掉的是结构，连同里面几年的记录一起没了。而真实业务里，去年的点检记录、已经结清的老合同、上个项目的施工日志，往往还要备查——删掉容易，找回不可能。
放着不管的代价更隐蔽：工作台越堆越满，新同事第一次登录看到十几个入口，分不清哪个是真在跑的、哪个是去年试的；有人误点进废弃模块录了一条数据，比多一个入口麻烦得多。还有一些模块确实已经彻底结束，只是不能说"这段历史没发生过"。
今天上线的三件事，就是把这一段补齐：模块可停用（数据保留）、可归档（作为独立台账留存，不占工作台），以及恢复时要过的一道结构校验。 想现在验证，路径是模块管理页里某个模块的详情页——次级动作菜单里能看到这几个动作。
先把口径说清：停用和归档都不是删除。 它们改变的是这个模块在日常工作里的位置，不是它数据的存亡。真要抹掉数据是另一类动作，动手前值得再确认一次。## 停用、归档分别对应哪种业务情形
三个动作对应三种不同的业务判断，混着用就会出错。
停用：暂时不用，但数据还要能查。 典型情形是按季节、按项目阶段性启用的模块——汛期用的防汛检查表、年底才密集使用的盘点表、只在新品导入期用的打样登记。停用之后，它不再占用日常工作台的注意力，但数据保留着；什么时候再要用，恢复回来继续。
归档：长期不再使用，但历史不能没有。 模块已经被别的做法取代（比如并入了正式系统），日常彻底结束，但从合规、审计、对账的角度，这段记录必须留着可查。归档把它从工作台里移出来，作为一份独立的台账存在——不打扰日常，需要时能调出来。
恢复：把开关拨回去之前，先核对结构。 这是本次加固的核心，也是最容易被低估的一环。模块停用的是"使用"，不是结构本身：在停用的这段时间里，它的结构与当初那一刻未必还是同一个样子。如果恢复时不做任何核对，直接按当前结构把历史数据放出来，界面和字段一旦对不上，轻则显示错位，重则数据落错字段——而这种错，往往要等几天后有人拿着报表觉得数字不对，才会被发现。
「结构时间戳防线」是什么：一句人话版解释
平台给恢复动作加了一道校验，叫结构（schema）停用时间戳防线。名字拗口，意思很朴素：
模块停用的那一刻，平台记下一个时间戳，以及当时的结构版本。以后要恢复它，平台会拿这份"当时的快照"与当前结构做比对，停用期间发生的结构变化，不会在恢复时未经任何验证就被直接放行。对管理员来说，这意味着恢复不是"点一下就完事"：遇到结构有变的情况，你会看到提示、要走确认流程，而不是被静默通过。
为什么要这么谨慎？因为代价不对称。改一次结构、多走一遍验证，最多花十分钟；把一批历史数据放错字段，可能要花几天去追，还未必追得干净。宁可让恢复多一道门，也不让数据冒这个险。
两句透明说明。 第一，这道防线管的是结构一致性，它判断不了业务口径有没有变——比如字段还在，但含义换了（同一个字段去年记"计划数量"，现在被定义成"实际数量"），平台看不出差别，只能靠人核对。第二，恢复不是版本回退：恢复是把一个已停用的模块重新投入使用，把模块改回上一版的样子是另一条路径，见修改与编辑模块。## 怎么操作：三步
- 进模块管理，打开目标模块的详情页。 模块管理属于平台的管理面动作，影响的是整个团队看到的入口，建议在电脑上操作，不在手机上顺手点。手机端是给业务执行用的，日常在手机上看到的是已发布模块的页面（见移动端使用指南）。
- 在次级动作菜单里选停用或归档。 两者挨在一起，语义不同，选之前先回答一个问题："这个模块以后还要不要日常录入？"要，就停用；彻底不要、只需留档，就归档。操作前把提示逐行读完——它会说明数据是否保留、是否从工作台移除。
- 恢复时按提示走完验证，再确认。 如果平台提示结构存在差异，不要找捷径跳过；按提示逐项确认后再恢复。恢复完成后，用两条旧记录抽查列表页与详情页，确认显示与取值都对得上。
出问题怎么办
- 恢复时提示结构变化：先看提示指向哪些结构项，确认这些变化是否在本意之内；不确定就用最小范围试——先恢复给管理员账号看、抽查无误后再放开权限。
- 停用之后还有人要录数据：说明需求没结束，只是当前模块不合用。正确动作是恢复它、或新建一个精简版，而不是让同事"先记在 Excel 里"，等以后再补录。
- 业务方来问工作台上怎么少了模块：先分清是停用、归档，还是权限没给。归档的模块不在工作台展示，属于预期行为；权限问题查角色配置（见角色与权限配置）。
操作之前，四件值得先做的事
- 命名写清用途与状态预期。 「安全检查（项目部 2026 试点）」比「安全检查2」更能防止误用；名字里带上年份与归属，归档时也不容易犹豫。
- 停用前盘一遍历史查询需求。 两个问题：未来 12 个月有没有人要查里面的记录？谁会来查？如果答案是"审计会来查"，那就是归档而不是删除的理由。
- 把恢复责任人写进模块说明。 每个模块自带的交付说明（见模块交付说明上线）讲的是数据怎么建、页面怎么用；建议顺手补一句"本模块由谁负责、何时停用、怎么恢复"。半年后接手的人，靠这一句能省一轮询问。
- 重要动作留在审计里。 停用、归档、恢复都是管理面动作，平台的操作审计日志会留痕（见AI 监控与审计日志）。做完动作留一条备注，日后追查"这个模块什么时候被谁收起来的"，不用靠记忆。
这次加固没有管的事
它不判断业务价值。 哪些模块该停、该归档，是管理判断，平台只提供动作和记录；它也不替代发布预检。 把模块恢复并调整结构之后，正式投入使用前仍应走一遍预检与移动端同步（见模块的测试与发布）。
一句话总结这次加固：模块从"建出来"到"收起来、再拿出来"，第一次有了完整的管理动作与结构校验。前后对照着看，一个业务模块的完整生命周期大约是这样——建（一句话需求）、改（指令修改与版本回滚）、发（预检与双端同步）、用（PC 与手机）、收（停用与归档）、再启用（带结构校验的恢复）。想先看看这套动作长什么样，可以从AI 构建器的介绍页与演示环境直接上手。