应用开发，功能设计要从需求出发
——记录一次开发前的框架规划
在一个风和日丽的下午，我如往常一样睡觉摆烂，突然！一个神秘人闯入我的梦境，给了我一个任务，需要我做一个关于违规内容检测的项目。还没等我开口，神秘人来也匆匆去也匆匆，只留下一个项目名称……
正常人不会把这个荒诞的梦境当一回事，但是我不正常。
我开始着手分析这个项目：
服务对象是谁？
什么群体会有这个需求？
需求量大不大？
系统最终会被放在什么环境里运行？
正在我一筹莫展之际，天空突然飘来了五个字——
“先做校园网～”
受到神明指引的我，瞬间豁然开朗。
校园网是一个非常典型、也非常“矛盾”的网络环境：
一方面，它承载着教学、科研、管理等严肃业务；
另一方面，它的用户群体复杂，网站数量庞大，历史包袱极重。
如果能在这个场景下，把“违规内容检测”这件事做清楚、做稳定，那么放到更复杂的互联网环境里，只会更游刃有余。
于是，项目的第一个锚点被钉死了：
这是一个面向多学校、以校园网为扫描对象的违规内容检测系统。
一、先不写代码，先想“人”
在真正动手之前，我强迫自己做了一件“反直觉”的事情——
不写代码，不画架构图，只想“谁在用”。
如果这个系统真的被用起来，那么它里面至少会出现几类人：
-
有人负责整个系统的运维与合规
-
有人代表某一所学校
-
有人只负责点按钮、跑任务
-
还有人只关心：
“你们系统是不是乱扫？有没有越权？有没有审计？”
于是，一个非常清晰的结论出现了：
这是一个天然的多租户系统，而且权限一定不能乱。
也正是从这里开始，RBAC（基于角色的权限控制）不再是“加分项”，而是“生死线”。
二、需求倒推功能，而不是功能堆需求
我给自己立了一个规矩：
任何一个功能，都必须能在需求里找到它的“来源”。
为什么要注册、登录、授权？
因为这是一个面向学校的系统，不是给个人随便用的工具。
所以我很早就否定了“开放注册”这种方案，而是选择了：
- 注册码注册
- 租户级别激活
- 登录即视为授权确认
这不是技术问题，是合规问题。
为什么要区分这么多角色？
不是我想复杂，而是现实本来就复杂。
如果把“学校”当成一个整体，会非常危险：
- 谁能创建扫描任务？
- 谁能删除扫描结果？
- 谁能看到历史记录？
- 谁来背锅？
所以最终，我把角色拆得非常明确：
- 系统管理员：只存在于平台层
- 学校管理员：对学校负责
- 操作员：只能“干活”
- 审计员：只看、不动
这样做的目的只有一个：
任何越权行为，在设计阶段就被堵死。
三、扫描不是点一下按钮那么简单
当功能走到“扫描任务”这一步时，我意识到一个问题：
扫描本身，就是一个高风险操作。
尤其是在校园网这种环境里：
- 扫太快，可能影响业务
- 扫太广，可能越权
- 扫内网，还涉及账号、代理、登录态
所以我给“扫描任务”加了很多的限制：
- 二次确认
- 资产范围快照
- 任务状态机
- 可取消、可暂停
- 全流程审计
表面看起来复杂，实际上是在给系统兜底。
四、任务调度的本质，是隔离与可控
当我开始设计任务调度时，我给自己提了一个问题：
如果 A 学校的任务把 Worker 跑死了，会不会影响 B 学校？
如果答案是“会”，那这个系统就不配上线。
于是我明确了几条原则：
- 任务必须入队
- Worker 必须无状态
- 进度高频走 Redis，DB 只做关键节点
- 取消是“请求式”的，不是“强杀”
这也是为什么任务状态、进度、心跳要拆开存储。
不是为了“优雅”，是为了活着。
五、从目录结构开始，约束未来的混乱
在真正敲第一行代码之前，我先写下了整个项目的目录结构。
不是为了好看，而是为了回答一个问题：
半年后我回来看，这个项目还能不能看懂？
前端按业务拆、后端按职责拆、Worker 专心干活。
每一层都知道自己能做什么，不能做什么。
当目录结构一旦定下来，其实很多错误已经被提前避免了。
写在最后
到这里，代码还没写一行，但项目已经“活”了一半。
回头看这次规划，我越来越确信一件事：
好的系统，不是写出来的，是想清楚之后“被允许”写出来的。
如果你正在做一个偏工程、偏合规、偏长期维护的项目，
那请一定记住这一句话：
功能设计，一定要从需求出发，而不是从技术出发。
而真正的编码工作，反而成了整个过程里，最轻松的一步。