从一个现实问题开始
问题与产品构想
绍兴一位兼职做家教的朋友，向 Yi Zhou 描述了将有托管需求的家庭推荐给服务机构的机会。他由此开始探索如何用小型软件组织需求、转介和协作。此起因来自本人陈述，不代表平台已产生收入。
机构服务
家长或学生表达家教、课后托管需求，参与的服务方协调自身服务，并在需要时联系老师。
当前范围。 已实现自有家长需求和机构申请。机构获取线索、分配与协同确认仍在计划中；尚未建立独立学生角色。
大学生兼职服务
面向大学生和研究生的独立服务板块，其中的机会并不自动由机构分配。
当前范围。 已有家教资料与示例需求浏览，尚未形成完整的独立兼职市场。
这是同一小程序中的两块独立业务。家长、家教与机构是不同角色，并不意味着所有大学生兼职机会都由机构分配。
Yi Zhou 的个人贡献
据 Yi Zhou 陈述，他确定产品方向，发现最初只有家教端的实现遗漏了家长与机构的需求，并要求增加这些角色。他在微信开发者工具中实际操作小程序、反馈错误，并在测试时发现了不合理的佣金状态推进流程。
如何与 AI 协作
Yi Zhou 与 ChatGPT 整理并细化需求。Codex 完成了大量 JavaScript、WXML、WXSS、云端逻辑和测试代码。Yi Zhou 陈述自己负责实际操作、检查行为和提出修改。这是 AI 辅助的产品开发，不代表所有代码均由他手写。
一次具体的挑战
拥有佣金记录，不等于有权审批付款
发现的问题
据 Yi Zhou 陈述，早期测试中，家教通过反复确认，能把自己的佣金从待确认推进至待结算和已支付，即使金额仍为空。实际没有发生付款。现有历史中未找到最初存在漏洞的处理函数。
采取的措施
已核对的当前服务端在查找目标佣金前，就以 FORBIDDEN 拒绝家教推进财务状态。新候选记录从待核验开始，金额与结算日期未知。家教界面保持只读；独立的平台审批与实际付款尚未实现。
这说明了什么
按钮操作成功或测试通过都不够，产品还必须明确谁有权改变每一种业务状态。
以上是根据现有证据整理的技术经验，个人反思仍以 Yi Zhou 本人的表达为准。
系统如何组织
原生微信客户端通过共享的云开发身份入口访问系统。服务端检查账户、角色、数据归属和成员关系后决定权限。在界面中切换角色，并不会自动获得对应的服务端权限。
家长需求生命周期
- 草稿
- 已提交
- 可修改
- 已取消 · 只读
佣金权限边界
- 报告报名
- 候选记录 · 未核验
- 家教端 · 只读
- 家教端
- 管理自己的资料和转介，佣金记录保持只读。
- 家长端
- 管理自己的资料与需求，支持草稿、提交、修改与取消。
- 机构端
- 查看自己的申请与审核状态，访问受账户和成员权限约束。
影响产品的关键选择
- 在同一小程序中保留多个角色，共用身份基础。
- 区分记录归属与审批财务状态的权限。
- 明确标记未知金额与历史测试状态，不将其当作确认收入。
证据与验证
源码核对、本地界面观察、历史报告和本人陈述分别说明不同层面的事实。以下标签明确它们各自的边界。
当前防护实现
佣金处理函数在访问目标记录前拒绝财务推进操作。源码中包含家长数据归属、机构成员关系与普通角色权限边界检查。
已有回归断言
测试源码覆盖直接财务调用、伪造输入、跨账户读取和未来财务动作。本次核对阅读了这些测试，没有重新运行。
历史真机验收
项目记录包含本人报告的部署与真机检查。这些报告与当前源码核对、新提供的手机截图分别记录。
明确当前边界
当前成熟度与限制
- 原型与体验版证据不代表已完成公开商业发布。
- 不声明已验证的收入、活跃用户、真实付款、钱包或提现功能。
- 机构线索、分配、家长独立确认及平台财务审批仍未完成。
- 历史记录中仍有推迟的旧账户检查和未修复的测试佣金，不代表所有迁移场景均通过。
- 手机录屏展示部分界面行为，不能独立证明部署的服务端版本或完整权限覆盖。