一个尴尬的时刻

演示系统时，客户问："员工档案在哪维护？"——数据库里有表，代码里有模型，但后台没有页面。

这种情况在快速推进的项目里非常常见。原因不是懒，而是完成的定义不一致：开发认为"表建好、接口能调"就算完成，客户认为"我在后台点得进去、点得对"才算完成。

差距就在中间那几层：页面、权限、种子数据、文档、冒烟测试。

我们的完成定义：六件套

一个功能只有六件事全部具备，才在清单上打勾：

第 5 项最容易被漏：页面写完了，但没往菜单表插记录、没给角色分配权限，结果只有开发者自己用直连 URL 能打开。

第 6 项也不是形式主义：三个月后回来看，能读懂"这个字段为什么这么设计"的唯一依据就是当时的记录。

三类表，三种处理

不是每张表都需要页面。我们把表分成三类：

• 业务操作表：必须有页面（员工档案、字典、登录日志）；
• 系统内部表：明确标注"仅内部使用、无页面"，例如迁移台账、任务执行日志（后者有查询页，但只读）；
• 预留表：如果暂时没有功能，就删掉或明确标注为"未启用"，不留悬空。

关键是分类要写进文档。表清单里每一行都标注归属，新同事读文档就知道哪些是活的。

清零"有表无功能"的做法

我们做了一次专项排查：把全部表按前缀分组，逐张确认"有没有页面入口"。结果分成三堆：

1. 有页面：正常；
2. 有表有接口、无页面：这一堆最多，典型是字典、员工档案、登录日志；
3. 有表无接口无页面：空壳，按上一节的标准决定删除或补功能。

第二轮把第 2 堆全部补上页面与权限种子，逐项跑冒烟（打开页面、增删改查、无权限账号访问被拒）。专项做完后，客服从"帮我查一下后台哪有这个"变成"我自己找到了"。

为什么值得花这两天

交付一套 B 端系统，客户的评价标准非常朴素：能不能自己用。

• 有页面：能自己维护，交付成本下降；
• 没页面：每次改一条数据都要找你，交付变成长期驻场。

所以"有表无功能"不是技术债，是商业债。补它的投入远小于它带来的持续消耗。