参赛赛道：全链路开发实战 选题方向：从 0 到 1 的全链路开发
话题：#TRAE双端融合 #全新TRAE实战体验
一、起因：一个拖了很久的"顺手活"****
朋友做社群运营，隔三差五就要搞一次人气投票：发群里、手工统计、再做个 Excel 排名，费时费力还容易算错票。他问我能不能做个微信小程序，需求列得很具体：
· 用户能看项目、投票、查排行榜，每人每天限投一票；
· 项目有开始/结束时间，过期自动结束，没开始的禁止投票；
· 要有一个藏在"我的"页面里的管理员后台，可以建项目、审核参评内容、看数据统计；
· 后端不想租服务器，点名用 HBuilderX 的云函数 + 云数据库。
按我以往的节奏，这种规模（十几个页面加一整套后端接口）少说要磨一个周末。这次我决定全程交给全新 TRAE，看看它能不能把"一句话需求"推到"能在微信开发者工具里跑起来"。
结论先放前面：页面、云函数、数据库设计、部署文档全部产出，中途几次报错也都是把错误信息丢给 TRAE、一起定位修掉的。下面是完整过程，包括踩坑，不做美化。
二、先想清楚再写代码：Plan 模式****
我把整理好的需求文档一次性贴给 TRAE，没有让它直接开写，而是让它先出方案。它读完我现有的空工程（HBuilderX 生成的 uni-app Vue2 模板），给出了完整路线：调整 pages.json 路由与 tabBar → 建 11 个页面骨架 → 设计 6 张数据表和索引 → 开发 17 个云函数 → 开发两端页面 → 联调与部署文档。
计划确认后开始执行，任务清单从"项目配置"一路推进到"部署配置"，每完成一阶段自动勾选。这种"需求 → 计划 → 任务清单 → 逐项落地"的节奏，和我自己干活的方式几乎一样，区别是它不会写着写着就分心。
图 1 贴入完整需求文档后，TRAE 自动拆解任务，全部完成后汇总交付物（17 个云函数、11 个页面、初始化函数、部署文档）
三、数据库与云函数：把"防刷票"交给事务****
3.1 数据模型****
最终落地 6 个集合，其中两个索引是关键设计：users 的 openid 唯一索引；votes（投票流水）上的 openid + projectId + voteDate 联合唯一索引------这是"每人每天每项目一票"在数据库层面的兜底，即使并发请求也插不进第二条。
· users：用户信息，openid 唯一
· voteProjects：投票项目，status + endTime 联合索引便于筛状态
· votes：投票流水，openid+projectId+voteDate 唯一约束
· voteContents：用户提交的参评内容，带审核状态
· admins / settings：管理员账号与可配置的每日投票上限
3.2 投票接口：四重校验 + 事务****
我最关心刷票问题。submitVote 云函数做了四层判断：项目必须"进行中"且在时间窗口内 → 参评内容必须审核通过 → 查系统配置的当日限额 → 查当天是否已投过该项目。全部通过后，用数据库事务同时写流水、内容票数 +1、项目总票数 +1、用户投票次数 +1，任何一步失败整体回滚。
const voteDate = new Date().toISOString().split('T')0;
// 当日是否已投过该项目（业务查询 + 唯一索引双保险）
const existing = await db.collection('votes').where({
openid, projectId, voteDate
}).count();
if (existing.total > 0) return { code: 403, message: '今日已投过票' };
const transaction = await db.startTransaction();
try {
await transaction.collection('votes').add({ openid, projectId, contentId, voteDate, voteTime: now });
await transaction.collection('voteContents').doc(contentId).update({ voteCount: dbCmd.inc(1) });
await transaction.collection('voteProjects').doc(projectId).update({ voteCount: dbCmd.inc(1) });
await transaction.commit();
} catch (e) { await transaction.rollback(); throw e; }
另外写了 updateProjectStatus 云函数，把到点的"未开始"批量置为"进行中"、到期的置为"已结束"，配合定时触发即可实现状态自动流转，不需要人工下架。
四、两端页面：用户投票与后台管理****
用户端 4 个页面：首页卡片式项目列表（全部/进行中/已结束筛选 + 剩余天数）、投票详情页（点参评内容直接投票，并提示今日剩余票数）、排行榜（票数降序，可按状态筛选）、个人中心（投票记录 + 隐藏管理员入口）。
管理端 7 个页面：登录、管理中心（统计卡片）、项目管理（新建/编辑/删除，"进行中"的项目锁定标题和开始时间，只能延长结束时间）、内容审核（待审核/通过/驳回三态）、数据统计（审核进度条 + 近 7 天投票柱状图，纯 CSS 实现，没有引图表库）。所有页面统一用 uniCloud.callFunction 调后端，loading、toast、删除二次确认都带上了。
五、真实踩坑实录：报错原样喂给它就行****
项目不是一次跑通的，编译运行连续踩了三个 uni-app/小程序新手必踩的坑，都是把报错截图/原文丢给 TRAE 一起排掉的。
坑 1：tag has no matching end tag，编译中断。
管理端列表页经过多轮编辑后少了一个 。TRAE 通读整个文件定位到根容器没闭合，补上后编译通过。教训：AI 多轮改同一个模板后，标签配对值得人工再扫一眼。
坑 2：模拟器启动失败，tabBar 图标"未找到"。
编译过了，微信开发者工具却弹一屏红字：static/tabbar/home.png 等 6 个图标路径全部未找到------pages.json 里配了 iconPath，但图标文件根本没放。我让它先用默认方案解决，它直接删掉 iconPath/selectedIconPath、只保留文字，模拟器立刻起来了。
图 2 模拟器报 tabBar 图标缺失，把报错告诉 TRAE 后，它改 pages.json 移除图标配置走默认方案
坑 3：app.json 在项目根目录未找到。
我图省事想用微信开发者工具直接打开工程目录，结果报 app.json 缺失。uni-app 源码里只有 pages.json 和 manifest.json，必须从 HBuilderX 里"运行 → 运行到小程序模拟器 → 微信开发者工具"，由 HBuilderX 编译产出 app.json 等原生文件后再拉起工具。这是纯 Web 思维迁到小程序最容易犯的错。
六、最终跑起来的样子****
把 appid 填进 manifest.json 的 mp-weixin 节点、重新编译后，首页项目卡片、排行榜、我的三个 tab 都能正常切换，云函数调用链路打通。
图 3 编译产物在微信开发者工具中运行：首页投票活动卡片、参赛作品、底部 tab 均正常渲染
交付清单：11 个可交互页面；17 个云函数（鉴权、项目 CRUD、投票事务、内容审核、统计分析）；1 个数据库初始化函数（自动建集合、唯一索引、写入默认管理员与配置）；1 份部署文档（云服务空间、集合权限、初始化、提审流程）。
七、几点真实感受****
· Plan 模式适合"需求明确但工作量大"的活。CRUD + 管理后台这类项目架构决策少、体力活多，AI 收益最大；真正需要人把关的是防刷票规则、编辑权限边界这类业务逻辑。
· 报错信息直接喂给它就行。三个坑排查加起来不到十分钟，它对 uni-app 编译产物、小程序配置约束这类"框架套路"很熟。
· 别跳过验证环节。标签未闭合、静态资源缺失这种低级错误 AI 也会犯，编译一次让工具说话，比逐行肉眼审查高效。
· 下一步：补上微信一键登录（当前 openid 为占位值）、用云存储替换本地图片路径、给状态刷新挂定时触发器。骨架已齐，剩下都是增量迭代。
从一句"帮我做个投票小程序"，到一个能在开发者工具里点开、能切 tab、能调云函数的完整工程------它替我写完了代码，但判断"该做什么、错在哪"的人，还是我。