一、背景与问题
12 个部门的日常协作全靠微信群和共享文档：任务靠刷屏、公告不知道谁没看、抢票靠接龙截图。
校学生会 12 个部门的日常协作跑在微信群和共享文档上：任务布置靠刷屏、公告触达没有回执（谁没看到永远不知道）、活动抢票靠接龙截图、材料收集靠人肉催。工具层面的真正约束有三个——零预算（没有服务器经费）、成员每年大换血（培训成本必须趋近于零）、移动端优先（几乎所有使用发生在手机上）。
我要做的是一个打开就知道"今天该干什么"的单一入口：任务有状态、公告有已读、抢票不超卖、权限不靠人情。这不是一个高并发产品，但它是真实组织每天要用的生产工具——"能用"和"敢用"之间隔着一整套工程纪律。
二、我的角色
一个人做完全程：跑各部门调研、定 13 个模块、设计权限、写前后端、部署并持续迭代。
独立产品人与开发者，own 全部环节：各部门工作流调研、13 个模块的信息架构、四级角色权限模型、React 19 + Supabase 的前后端实现、GitHub Pages 部署与 CI，以及上线后的持续迭代（v1 → v4.6.1）。
三、过程与关键取舍
四次取舍里最关键的一次是「给自己开刀」：上线后做全面审视，发现 15 张表没有行级安全，随后分两轮补。
取舍 1：Supabase 全托管，把预算约束变成架构决策。 零预算 + 无运维人力，自建后端从第一天就不成立。选 Supabase 换来 Auth/数据库/Realtime/Storage 全托管，代价是安全责任前移到客户端——这一点后来被审视报告证明是全项目最大的风险敞口。
取舍 2：上线后给自己开刀——双视角全面审视。 v3.0.2 我做了一轮产品经理视角 + 工程师视角 + 同类平台调研的全面审视，暴露的问题比预想严重：16 张表里 15 张没有行级安全（RLS）、前端 JS 里硬编码管理密钥、论坛 N+1 查询（50 帖 = 50 次 HTTP）、月报逾期数硬编码为 0。审视产出 17 篇改进文档，P0 级（抢票并发超卖，用 PostgreSQL FOR UPDATE 行锁解决）在改进轮收口，其余按优先级进入后续版本。这件事改变了我的交付观：内部工具没有外部用户来帮你发现问题，审视机制就是它的"用户反馈"。
取舍 3：移动端溢出做进 CI 门禁，不靠人眼。 移动端横向溢出修过三轮——第一轮修"配置类"（Table/Modal/断点），用 375px 视口门禁取基线后发现残留的是"内容类"（用户生成内容无断词）和"行级"（内联样式）。v4.6.1 把 5 个溢出页全部收口，并把"375px 无页面级横向滚动"做成随 CI 跑的机器门禁。门禁的意义和体积预算一样：让"会不会坏"从感觉问题变成构建问题。
取舍 4：Realtime 与通知的节奏。 通知触发最初写成 await，主流程要等通知写入才能返回——改为 fire-and-forget，非关键操作不阻塞关键路径。Supabase Realtime 的 channel 名全局唯一，两处订阅同一 channel 直接白屏崩溃，这类"框架契约"坑最终沉淀成项目侧的经验清单（Phase 1-5 共 19 条）。
四、结果与量化
13 个模块上线、服务 12 个部门；四个大版本走过来，留下 100 多篇过程文档。
- 13 个功能模块上线运行：任务管理（看板拖拽 + 乐观更新）、部门公告（已读回执 + 未读名单）、活动抢票、四级权限体系、Realtime 通知、Ctrl+K 全局搜索、PWA 安装到桌面等，服务 12 个部门的日常协作。
- v1 → v4.6.1 四个大版本：从功能堆叠到审视修复（v3.0.2 → 改进两轮）→ UI 精化（v3.6）→ 移动端门禁（v4.6.1），每个版本有独立迭代总结与实施计划。
- 质量门禁：CI 全绿自动部署；375px 溢出门禁随构建运行。
- 项目全部过程文档（100+ 篇：审视报告、改进文档、迭代总结、经验清单）随仓库开源：github.com/YHLLXY/student-union-platform。
- 诚实交代：这是组织内部工具，用户规模是部门口径，没有外部用户增长数据；审视暴露的安全与性能项按 P0 → P1 → P2 分轮修复，P0（并发安全）在改进轮收口，RLS 全表覆盖等项进入后续迭代——修什么、什么时候修，优先级判断本身就是这个项目的一部分。
五、复盘与反思
最险的一条：如果这个工具管着钱或敏感数据，行级安全和密钥必须在上线前做完——这次只是运气好。
成立的：审视文化——敢在没人要求的情况下给自己开刀，17 篇改进文档让"问题"变成"任务"；门禁化——把重复出现的问题（溢出、超卖）做成机器门禁而不是靠记性。
过度设计或不足的：先上线后审视的顺序在内部工具场景成立，但如果换成有真实资金或敏感数据的场景，RLS 和密钥管理必须在上线前完成——这次是运气好没有出事；权限模型最初只有角色没有审计日志，事后补成本远高于一开始就设计进去。
下次会验证的：通知到达率（Realtime 在弱网下的表现）与邀请码防滥用（成员换届时批量失效）值得做专项实验；13 个模块里使用率最低的模块是否应该砍掉，需要一届成员的真实使用数据来回答。