贯穿案例｜活动报名与审核系统

这本指南一直用同一个虚构项目举例。你在这里可以查到：前面说好的到底是哪几条，后面突然多出来的要求是不是练习。

这些都是为了讲清步骤编的例子，不能拿去当成你的甲方已经同意的要求。

起点：甲方只有一句初步描述

「能看活动、提交报名，后台能发布和审核。手机上能用，人数满了就不能报。」

听着挺清楚，真正做起来才会发现：怎么登录？什么时候占名额？能不能取消？后台谁能看哪些名单？什么时候交，要花多少钱？这些都还没说。

第 3 章先把问题找出来，不急着写代码。

第04章开始采用的已确认示例规则

我们把甲方确认过的话一条条编号，方便以后指出来。比如你说「第 2 条改了」，就知道要找审核占名额那件事。

编号	说好的规则	还要注意
第 1 条	提交报名后是“待审核”，不占名额	截止后不收新报名；名额满了但还没截止，仍然可以提交
第 2 条	只有审核通过，才占一个名额	就算只剩一个名额，同时审也不能超过
第 3 条	截止之前，待审核的和已通过的都能取消	已经通过的取消掉，名额要还回来
第 4 条	同一个人对同一个活动，只能有一条有效报名（“待审核”和“已通过”都算有效）	取消以后、截止之前可以再报；被拒绝以后能不能再报，还没确认
第 5 条	后台账号只能动自己被授权的活动	不能只在页面上藏按钮，后台也要拒绝

第 4 章之后，页面、开发和检查都按这几条示例走。文中的「30 个名额」只是为了方便算例子，不代表所有活动都固定 30 个。

还有些事没有在这张表里说完。比如晚上 8 点截止，正好 8 点算不算晚？按哪个地方的时间？被拒绝后能不能再报？遇到相关功能，仍要先问清楚。

示例中的范围

这一版做查看活动、提交、审核、取消、查结果，以及必要的账号限制。候补、签到、积分和邮件提醒先不做，后面提到时通常是在讨论要不要增加。

原型就是正式开发前，用来说明页面和操作的草稿。比如点一下能跳到下一页，但用的都是假记录，不代表已经真的保存。

真正开发时，可以先做「看活动、提交、保存、再查看」这一小段。涉及账号、截止和重复报名的检查，要一起做，不能等最后再补，不然前面就可能存进不该有的记录。

后文的变更不自动覆盖这里

第 4 章假设甲方提出「取消后不还名额」，是在练习如何处理新要求，并没有真的改掉这里的第 3 条。「后台代为新增报名」也只是练习题。

读到新说法，先看它是已经说好的、还在考虑的，还是临时假设。实际项目里也一样：AI 随口建议一个功能，不代表它已经成了必须做的事。

自己做项目时怎样使用？

可以学这页的记录方法，不要抄这里的业务答案。保存你自己甲方的原话，把说好的内容编上号，不知道的明确写不知道。

一条规则改了，相关页面、方案、代码和检查步骤都要跟着看。验收条件，就是「做到什么样算合格」，比如截止后提交不能新增记录。规则改了却还按旧条件检查，双方就会各说各的。