AI 开发微信小程序，先做清楚一场活动的报名
最后更新:
从两个名额的教学样例出发，把提交、拒绝、查询和管理员核对连起来。已有本地逻辑检查，微信环境和服务端仍需单独验收。
先写业务终点：组织者能拿到准确名单
假设你为一场虚构的社区手作活动制作报名工具，只有两个名额。参与者输入姓名、提交并看到结果，组织者最终要拿到没有重复占位的名单。这个任务的终点不是出现一个“报名成功”弹窗，而是参与者看到的结果、剩余名额和组织者的记录互相一致。
本页以 2026-09-11 生成并保存的代码及随后检查记录为依据，证据复核日期为 2026-09-12。已有样例只在一个 Page 对象里保存姓名数组和余量；没有管理员页面、登录、跨设备数据或发布记录。下面把实际完成的单页逻辑与待实现的业务闭环分开，读者可以逐步验证，不必把所有能力混在第一版里。
把姓名、身份、报名记录和容量分开定义
样例用姓名判断重复，便于观察数组变化，但真实活动可能有同名参与者，也可能允许一人报名多个场次。实际身份应由经过验证的登录关系确定，不能由前端随意传一个 userId 就代表本人。活动和场次也要有稳定编号，显示名称可以改变，报名归属不能随之改变。
先与组织者约定取消是否释放名额、报名何时截止、谁能导出资料，再让 AI 写接口。每个字段都对应一个业务判断；不为了“以后可能有用”收集额外个人信息。下表是面向下一阶段的教学数据设计，不是现有样例已建立的数据库。
| 对象 | 教学字段 | 需要保持的关系 |
|---|---|---|
| 活动场次 | eventId、capacity、deadline | 容量是场次属性，截止时间由服务端判断 |
| 参与者 | authenticatedUserId、displayName | 姓名用于展示，身份用于判断报名归属 |
| 报名记录 | registrationId、eventId、status | 同一有效报名不得重复占用容量 |
| 提交尝试 | requestId、payloadHash | 相同请求重放返回同一业务结果 |
| 管理员操作 | actorId、action、occurredAt | 导出和取消留下可复核的操作记录 |
读懂已生成的核心代码，再让 AI 继续修改
原始项目含 app.json、app.js，以及首页的 JS、JSON、WXML、WXSS 文件。下面摘录实际生成的提交方法；它依赖 Page 中 name、remaining、registered 三个数据项，初始 remaining 为 2。执行顺序是去除两端空白、检查空值、判断重复、检查容量，最后一次更新名单和余量。
这段代码的优点是每次拒绝都能检查状态有没有变化；局限也很直接：它没有把数据写到任何持久层，重新创建页面就会恢复初始数据。让 AI 解释这一点比让它再美化按钮更重要。不要把 registered 数组直接改成“本地缓存”就宣称完成多人报名，那仍不是所有设备共同认可的记录。
submit() {
const name = this.data.name.trim();
if (!name) return this.setData({message: "请输入姓名"});
if (this.data.registered.includes(name)) {
return this.setData({message: "该姓名已报名"});
}
if (this.data.remaining <= 0) {
return this.setData({message: "报名已满"});
}
this.setData({
name: "",
remaining: this.data.remaining - 1,
registered: this.data.registered.concat(name),
message: "报名成功"
});
}本地检查到底证明了什么
取证脚本用本地 JavaScript 环境接收 Page 配置，并用对象合并模拟 setData，依次提交空输入、小甲、小甲、小乙、小丙。检查的是 remaining 和 registered.length，而不是匹配成功提示语。这能说明这组输入在单一页面内按预期改变状态；不能证明 WXML 事件绑定、微信运行环境、持久化或服务端并发。
复查时保留输入顺序。若每次测试都重新初始化两个人名，就测不到最后一个名额耗尽后的行为。也要理解“重复姓名被拒绝”是样例规则，不是生产身份设计的验收结论；同名但不同人的处理需在真实身份方案下另测。
| 顺序 | 输入 | 剩余名额 | 名单条数 | 已有证据 |
|---|---|---|---|---|
| 1 | 空输入 | 2 | 0 | 本地模拟通过 |
| 2 | 小甲 | 1 | 1 | 本地模拟通过 |
| 3 | 再次小甲 | 1 | 1 | 本地模拟通过 |
| 4 | 小乙 | 0 | 2 | 本地模拟通过 |
| 5 | 小丙 | 0 | 2 | 本地模拟通过 |
在微信开发者工具补上环境验收
下一步由具备项目权限的人，在微信开发者工具中新建或导入对应目录，核对 app.json 的页面路径与文件位置，编译后从输入框触发同一组操作。先观察页面是否显示初始容量，再输入带前后空格的姓名，检查按钮触发、提示刷新与列表更新；最后离开页面并重新进入，记录数据是否重置。这个重置现象应作为当前实现的已知限制保留。
微信小程序开发者工具官方入口与Page 官方参考是环境复核入口。2026-09-12 本次检索未能读取这两页正文，因此这里不转述当前版本、账号资格或审核要求。本文尚无开发者工具执行和真机记录；实际编译错误应连同工具版本、基础库版本、文件路径交给 AI 定位，而不是描述成“微信不兼容”。
多人争抢最后一个名额，必须交给服务端
两台手机可能同时看到剩余一个名额，所以前端按钮置灰只能改善交互，不能决定谁报名成功。教学架构可以让服务端在同一事务内检查场次、识别已有报名、占用名额并写入记录，提交后返回报名编号。取消操作也要按当前状态执行一次，避免反复释放容量。
如果采用 PostgreSQL，可研究行锁与事务内的检查顺序；官方文档说明 SELECT FOR UPDATE 会约束其他事务对同一行的修改，锁在事务结束时释放。这个机制是设计材料，不是本页已经跑过的实现，参见 PostgreSQL 行级锁说明，核对日期 2026-09-12。真正验收要让两个独立连接同时申请最后名额，确认恰好一条有效报名，重放请求不增行，并检查失败事务没有残留占位。
给开发 Agent 一张分阶段任务单
AI 在这里负责辅助理解代码、补接口与测试，报名者不必每次点击都调用模型。先读取现有项目约定，让 Agent 输出涉及文件和验收命令，再授权修改。模型接入可参考 Cline 配置，模型与协议从模型目录和接口文档核对。工具能返回代码，不表示它能访问你的微信环境。
下方提示词用于下一阶段教学实施。完成后分别索要本地命令结果、开发者工具记录、服务端两连接并发结果；某一项缺失就保持待验证。测试只使用虚构身份，不把真实报名名单交给模型分析。
任务：将容量为 2 的单页报名样例推进到可核对的报名闭环。
先读取项目结构，说明当前数据保存位置和缺失环节。
身份由服务端认证结果确定，展示姓名不能充当身份。
正常报名返回稳定报名编号；重放同一请求不得新增记录。
管理员只能查看获授权场次；取消状态仅转换一次。
先给出数据约束与接口错误码，再实现一条报名到名单查询流程。
分别验证：本地输入逻辑、微信页面事件、两个连接争抢最后名额。
没有执行的环境明确写未执行，不把模拟结果替代真机结果。交付按责任划分，而不是按页面数量报价
常见问题
这个小程序已经在微信里跑通了吗？
没有。已有代码、语法检查和本地 Page 模拟，空输入、重复姓名与单页容量检查通过；没有微信开发者工具、真机和服务端并发成功记录。
为什么报名姓名不能直接当唯一身份？
现实中存在同名与代填。先确定业务允许谁报名，再由认证身份与活动关系约束有效报名，姓名只用于必要展示。
把名单存到手机里就能多人使用吗？
不能据此保证统一容量。每台设备的本地数据不是共享事实，多人报名需要统一服务端记录和并发控制。
开发时用了 AI，产品运行也必须调用 API 吗？
不必。报名、容量校验和名单查询可以由确定性程序执行；AI 参与编程与解释代码，不等于每次报名都产生模型调用。
接这种小程序订单应验收什么？
按真实运行环境验收报名、重复提交、满额、取消、越权查询与管理员核对，同时交付版本、维护范围和数据恢复办法。