这不是一篇产品说明书，是一次"人+AI"协作开发的真实手记。
一、先交代底细：我是谁，为什么站在这里写这篇东西
我今年四十出头，职业履历里没有任何一行代码。Excel公式就是我接触过的最复杂的"编程"。在朋友眼里，我大概是那种"电脑崩溃都要找人帮忙反复重装"的数码难民——这种印象不算冤枉。
但我也做了一件他们没想到的事：在10天里，我用 Trae SOLO 独立做出了一款能跑的小程序，从立项到上线，全流程走通。
小程序叫「喵了个鱼」，是个帮朋友决定"聚餐去哪吃"的工具。它有25个页面、35个云函数、6000多行前端代码、2000多行后端代码。功能包括双模式投票、房间管理、约饭定时、拼单、商家发现、匿名投票、忌口过滤……听起来不少，对吧？但今天要聊的不是这些功能本身 ，而是另一个问题：一个完全不会写代码的中年人，凭什么能在10天里把这些东西做出来？
答案是 Trae SOLO。
不过，回答这个问题之前，我想先聊聊为什么这件事值得写。因为现在市面上的 AI 编程工具不少，ChatGPT、Claude、Cursor、CatPawAi、WorkBuddy……每个人都在说"AI让编程变简单"。但"变简单"和"真能做成事"之间，隔着一条不小的河。我的这篇报告，想站在一个真·外行 的视角，讲讲 Trae 是怎么帮我渡过这条河的。
二、为什么我会走到"用AI做小程序"这一步
2.1 这事儿的缘起
起因很日常：每次朋友约饭，"去哪吃"都是一场灾难。
微信群里的典型场景是这样的：
-
A说：火锅吧？
-
B回：太辣了，最近上火。
-
C说：日料？
-
D回：太贵了，随便吃点就行。
-
E一直没说话，到餐厅了才说：我不吃海鲜。
20分钟过去了，没有结论。最后发起人说"就那家吧"，有人附和，有人勉强，有人心里不爽但不说。这顿饭吃得别扭，下次约饭的热情也打了折扣。
我观察这个现象很久了。市面上不是没有工具——问卷星可以投票，微信群可以接龙，大众点评可以找店。但这些工具都有个共同问题：它们是为"收集信息"设计的，不是为"帮人做决定"设计的 。问卷星太正式，像是在做市场调研；微信群接龙太乱，信息散落在聊天记录里；大众点评只能查店，不能帮你协调一群人的口味冲突。
我想做一个东西，让"约饭"这件事变得顺滑。不是更复杂，是更顺滑。
2.2 三条路摆在面前
有了这个念头之后，我面临三个选择：
第一条路：自己学代码，从头写。
我认真考虑过。买了几本书，看了一些视频教程。但很快发现一个根本问题：小程序开发涉及的技术栈太多了——WXML（类似HTML）、WXSS（类似CSS）、JavaScript、云函数、数据库操作、微信API……每一门都需要时间消化。我算了一下，就算每天投入4小时，把基础学完至少也要一两个月。而我需要的是一个能在两周内跑起来的东西。这条路，时间窗口不允许。
第二条路：找外包或者朋友帮忙做。
也想过。但问题是，我的产品想法每天都在变。今天觉得投票页应该上下滑动，明天觉得左右滑动更好；今天想做两种投票模式，后天又冒出第三个模式。如果要和开发者高频沟通这些细节，对方的耐心和我的钱包可能都撑不住。更重要的是，我想亲手把这个想法做出来 ，而不是把需求文档扔给别人，等一个月后拿到一个可能和我设想差很远的东西。
第三条路：用AI辅助开发。
这时候正好看到 Trae SOLO 挑战赛。说实话，我对"AI写代码"这件事本来是半信半疑的。之前用过 豆包啥的问过一些简单的编程问题，它能给出代码片段，但都是零散的、片段式的。你可以让它写一个排序算法，但你很难让它"帮我做一个完整的小程序，要包含用户登录、数据库、投票逻辑、UI界面"。中间的衔接、调试、Bug修复，AI似乎插不上手。
但 Trae 的宣传让我有点动心：它不是聊天机器人，是一个集成在IDE里的AI编程助手 ，能理解整个项目上下文，能帮你写代码、改代码、调Bug，还能看截图给设计建议。我想，要不试试？反正最差的结果就是10天后发现做不出来，也没什么损失。
三、用过才知道：Trae和其他AI工具到底差在哪
在深入讲我怎么用Trae做「喵了个鱼」之前，我想先聊聊工具对比 。因为我这段时间其实不止用了Trae，也试过其他几个方案。对比之后，我才真正理解为什么Trae适合我这种外行人。
3.1 ChatGPT / Claude：知识渊博，但"站着说话不腰疼"
先说大家最熟悉的 ChatGPT 和 Claude。
它们的优点是知识储备惊人 。你问它们任何一个技术问题，它们都能给出教科书式的回答。你想了解微信小程序的生命周期？它们能给你讲20分钟。你想知道云函数怎么连数据库？它们能列出五种方案并比较优劣。
但问题是：它们不干活 。
它们像一位博学的教授，站在讲台上给你讲课。你听完之后觉得"懂了"，但一打开代码编辑器，发现还是不知道怎么下手。你能让ChatGPT写一段登录逻辑的代码，但它不会帮你把这段代码放进正确的文件位置，不会帮你配好项目结构，不会在你运行时报错的时候自动定位问题。
更要命的是上下文断层 。ChatGPT的聊天窗口是有长度限制的。当你跟它聊了20轮，前面关于项目架构的讨论可能被"遗忘"了。你得不断重复"我在做一个微信小程序"“我的技术栈是云开发”“我之前跟你说过这个房间状态机的设计”……这种重复很消耗耐心，也容易出现"AI记错了"的情况。
还有一个问题：ChatGPT给的代码往往是"理想化"的 。它假设你的项目结构是标准的、依赖都已经装好了、配置文件是对的。但现实中，外行人面对的是一个乱七八糟的项目，可能连app.json里少了个逗号都不知道。ChatGPT给的代码贴进去跑不起来，你也不知道是它错了还是你贴错了。
所以我的感受是：ChatGPT和 Claude 是很好的知识库 ，但不是很好的合作伙伴 。它们能回答"怎么做"，但很难陪你一步步"做下去"。
3.2 Cursor：专业程序员的"外脑"，门槛还是高
Cursor 是另一个我很期待的工具。它把AI直接嵌进了代码编辑器，能读你的项目文件，能根据光标位置生成代码，甚至能自动修改多个文件。听起来很强大。
但我实际用下来的感受是：Cursor是为会写代码的人设计的 。
它的强大之处在于：如果你已经知道JavaScript的语法、知道Promise和async/await的区别、知道什么是闭包，那么Cursor能帮你写得更快、更少出错。它像一个经验丰富的搭档，在你写代码的时候随时补刀。
但如果你不知道这些基础概念 ，Cursor的代码补全和自动修改会让你很慌。它突然在一堆文件里改了好几处，你根本看不懂它改了什么、为什么改。它生成的代码里如果有你不认识的语法，你不敢问它"这是什么意思"，因为你连怎么描述这个问题都不知道。
举个例子：我在Cursor里试着让它帮我写一个云函数。它唰唰唰生成了一段代码，里面用了async/await。我看不懂。我问它"这是什么"，它解释了一通，我还是似懂非懂。最后我决定不用这段代码，因为我不知道它会不会在其他地方引发问题。Cursor的"智能"反而成了我的负担——它太快了，我跟不上 。
3.3 GitHub Copilot：自动补全很强，但不会"带路"
Copilot 我用得不多，但感受很明确：它是超级自动补全工具 ，不是项目导师 。
你在写代码的时候，它能在你打了一半的时候猜出后半段，准确率还挺高。这种体验很爽，像是在和一个默契的搭档 Pair Programming。但前提是你已经在写了 。你得先知道要写什么，它才能帮你补完。
对于外行人来说，最大的困难恰恰是"不知道怎么开始"。Copilot 不会告诉你"这个项目应该先建哪些文件"“登录功能应该怎么拆分模块”“数据库集合怎么设计才合理”。它只在你在键盘上敲字的时候帮你加速，不会在你面对空白屏幕发呆的时候给你方向。
3.4 WrokBuddy、CatPawAI、 通义灵码 / 国内其他AI编程助手：还在追赶
我也试过几款国内厂商的AI编程工具。坦白说，它们的功能和体验还处于"能用"的阶段，离"好用"有距离。主要问题集中在：
-
中文理解能力 ：虽然界面是中文的，但对复杂的自然语言需求描述理解不够精准。我用中文描述一个投票逻辑，它生成的代码经常漏掉条件分支。
-
上下文感知 ：项目级别的理解能力较弱，经常"顾头不顾尾"，改了A文件破坏了B文件。
-
调试辅助 ：出错之后给的建议往往停留在"可能是语法错误，请检查"这种层面，不会深入分析。
我体验下来，这些工具更适合作为程序员的"加速轮"，而不是外行人的"学步车"。
3.5 Trae SOLO：一个愿意"蹲下来"跟你说话的AI
最后说 Trae。
用Trae的第一天，我就感觉到它和前面那些工具不一样。这种差异不是某个单一功能的差异，而是整体协作体验的差异 。
第一个不同：Trae 会"带路"。
我不是打开编辑器对着空白屏幕发呆，而是打开Trae的对话框，告诉它：“我想做一个微信小程序，帮助朋友决定聚餐去哪吃，应该有哪些功能？”
它没有给我一堆零散的知识点，而是直接给了我一个完整的骨架 ：
“建议分为四大模块：1.投票决策系统 2.房间管理系统 3.用户系统 4.辅助功能。其中投票系统是核心，可以考虑支持两种模式……”
这就像一个老师傅不会先给你讲"锤子的材质分类"，而是直接说"要打个柜子，你需要先备这四样木料"。它把"知识"包装成了"步骤" ，这对我是救命稻草。
第二个不同：Trae 能记住整个项目。
Trae不是聊天机器人，它是和你的项目文件深度绑定 的。你跟它说的每一句话，它都知道你当前项目的结构、你已经写了哪些文件、你之前做过什么决定。你不需要反复交代背景。
比如我在第三天跟它讨论投票页面的状态管理，到第七天我问"怎么在用户退出后恢复投票状态"，它自动关联到了之前的状态设计，给出了wx.setStorageSync的方案。这种连贯性 在ChatGPT里很难实现，除非你自己做很复杂的提示工程。
第三个不同：Trae 能"看图说话"。
这个功能我在其他工具上没见过。我把UI截图直接发给Trae，问"这个配色有点单调，怎么改？“它不仅给出了具体的色值（#F5F0E8奶油白、#FF6B6B珊瑚红），还解释了"为什么用暖色调更适合聚餐场景”。后来IP形象橘仔的设计，也是靠截图对话一步步迭代出来的。
对于一个不会写代码但有审美直觉 的人来说，这种"视觉对话"能力太重要了。我不需要懂代码，我只需要说"我觉得这里不舒服"，它能听懂并给出技术实现方案。
第四个不同：Trae 会"陪你debug"。
这是我用得最多的功能。开发过程中报错是常态，云函数报个错、前端页面白屏、数据没写进数据库……以前我看到报错信息就头皮发麻，完全不知道从哪里下手。
但Trae的处理方式是：你贴报错信息 → 它分析原因 → 给出修改方案 → 你照着改 → 它验证是否解决。整个过程像有一个耐心的教练站在旁边，不是替你做，而是教你做 。而且因为它能看到你的项目文件，定位问题很准，不会瞎猜。
第五个不同：Trae 能切换"沟通模式"。
这是我觉得Trae最被低估的能力。它不是一个固定性格的AI，你可以根据当前需要，让它扮演不同角色：
-
架构师模式 ：帮我拆分模块、选技术栈、设计状态管理
-
编码助手模式 ：给我写具体函数的代码、补全逻辑、写注释
-
审查模式 ：帮我检查代码有没有Bug、性能好不好、风格统一吗
-
设计顾问模式 ：看截图、给配色、建议布局
这种"多面手"能力，让Trae在项目的不同阶段都能派上用场。不像有些工具，只擅长某一环，其他环节帮不上忙。
四、从0到1的10天：Trae怎么陪我走完这条路
下面这部分，我想按时间线的方式，讲讲这10天里Trae具体帮我做了什么。不是为了罗列功能，而是想呈现一种协作感 ——一个人和AI是怎么一步步把一个想法变成现实的。
Day 1-2：立项和架构——Trae当"老师傅"
我的状态 ：脑子里有一团模糊的想法，但不知道怎么变成技术方案。
Trae的角色 ：架构师 + 技术顾问。
第一天的对话是这样的：
我：“我想做一个微信小程序，帮朋友决定聚餐去哪吃。”
Trae：“好的，建议从以下几个维度梳理：1.用户场景 2.核心功能 3.数据流转 4.技术选型。你想先聊哪个？”
我没有被直接丢进代码里，而是先被引导做结构化思考 。Trae问我的问题包括：
-
“用户是谁？发起人还是参与者？”
-
“投票结果需要匿名吗？”
-
“发起人是否需要最终拍板权？”
-
“除了投票，还有什么场景？比如约饭定时、拼单？”
这些问题我自己其实没想清楚。被Trae一问，我才意识到"啊对，匿名很重要，不然大家不好意思真实投票"。
两天后，我们共同确定了双模式设计：
-
模式A「你们来定」：发起人筛店→成员海报投票→发起人拍板
-
模式B「我来推荐」：发起人提想法→成员匿名填偏好→系统聚合→推荐餐厅
这个设计不是Trae强加给我的，是它先给了我几个选项，我选了最符合直觉的，它再帮我细化。这种"共同决策"的感觉，和"AI给我下指令"完全不同。
Day 3-4：技术选型和项目搭建——Trae当"导航仪"
我的状态 ：知道要做什么，但不知道用什么做。
Trae的角色 ：技术选型顾问。
我问了一个很关键的问题：“该用原生小程序，还是Taro/uni-app？”
Trae没有直接说"用原生"，而是先问我的需求：
-
“你需要跨平台吗？（iOS/Android之外还有别的平台吗？）”
-
“比赛评分看重什么？”
-
“你对学习成本和时间的要求？”
然后它给了对比表：
| 维度 | 原生小程序 | Taro/uni-app |
|---|---|---|
| 云开发支持 | 原生专属，无额外配置 | 需额外适配 |
| 学习成本 | WXML/WXSS/JS从零学 | 需要学框架+转换思维 |
| 开发周期 | 文档完善，社区活跃 | 生态成熟但配置复杂 |
| 比赛加分项 | 代码质量、原生能力展示 | 跨端能力（本项目用不上） |
看完这个表，我自己就能判断了：用原生。这个决定不是我"听AI的话"，而是Trae把信息结构化呈现之后，我自己做的判断 。这种体验很好，我没有被推着走，而是被陪着走。
项目搭建阶段，Trae给了我详细的目录结构建议：
miniprogram/
├── pages/
│ ├── index/ // 首页
│ ├── createRoom/ // 创建房间
│ ├── vote/ // 投票页（核心）
│ ├── roomDetail/ // 房间详情
│ └── …
├── components/ // 公共组件
├── utils/ // 工具函数
├── cloudfunctions/ // 云函数
└── app.js // 全局逻辑
它还解释了每个目录的作用，以及为什么这样拆分"对后期维护更友好"。这些信息对我这种外行人来说，就像装修房子时师傅告诉你"水管走顶不走地"——不是必须知道，但知道了以后会少踩坑。
Day 5-6：投票页面的"地狱难度"——Trae当"拆弹专家"
我的状态 ：遇到了整个项目最复杂的技术挑战，差点想放弃。
Trae的角色 ：深度技术搭档 + 状态管理教练。
投票页面是整个项目的核心，也是技术难度最高的部分。因为它要同时支持两种完全不同的交互模式，状态管理极其复杂。
模式A是"抖音式"的上下滑动海报投票：用户滑一张餐厅海报，喜欢就双击点赞，不喜欢就上滑跳过。需要记录：当前看到第几张、哪些点了喜欢、哪些跳过了、滑动的历史轨迹（方便撤销）、13项忌口的选择。
模式B是"两步式"分类投票：先网格选大类（火锅/日料/烧烤等，最多选3个），再swiper滑动选细类（每个大类下5个细类）。需要记录：选了哪些大类、每个大类下选了哪个细类、当前在第几步。
这两种模式的数据结构完全不同，交互逻辑也完全不同，但它们共用同一个页面。我一开始完全不知道该怎么组织代码。
我跟Trae说：“这个投票页面的状态管理太复杂了，我完全没思路。”
Trae没有直接甩给我一段代码，而是先画了一张图 （用文字描述的层级结构）：
// 第一层：页面级状态
mode: ‘a’ | ‘b’ // 当前是哪种模式
currentStep: ‘category’ // 模式B的第一步还是第二步
// 第二层：模式A私有状态
posters: // 海报数据
currentIndex: 0 // 当前看第几张
likedIndices: // 喜欢的序号
vetoedIndices: // 跳过的序号
// 第三层：模式B私有状态
selectedCategoryIds: // 选中的大类ID
selectedSubCategories: {} // 每个大类对应的细类
// 第四层：通用状态
hardTaboos: // 13项忌口
swipeHistory: // 撤销历史栈
timeInfo: {} // 时间偏好
这张图的价值在于，它让我第一次看清了混乱背后的结构 。原来只要把"共用的"和"各自私有的"分开，再把"页面级的"和"数据级的"分开，复杂就变成了清晰。
然后Trae带我做了三步：
第一步：写状态管理的骨架。
Trae给我写了vote.js的核心结构，约200行。它解释了data对象里每个字段的含义，以及setData的使用规则（这是微信小程序更新UI的机制）。我逐行看，不懂的就问，Trae用比喻解释：“data就像你前台展示的账本，setData就是更新账本后让客人看到最新数字的过程。”
第二步：实现撤销功能。
这是用户体验的关键点。用户滑错了一张，或者点错了喜欢，需要能回退。
Trae引入了"历史栈"的概念：每次用户操作（滑动、点赞），就把当前完整状态拍个快照存进数组。撤销时，从数组末尾弹出一个快照，恢复到那个状态。
recordSwipeHistory(action) {
const snapshot = {
currentIndex: this.data.currentIndex,
likedIndices: […this.data.likedIndices],
vetoedIndices: […this.data.vetoedIndices]
};
this.setData({
swipeHistory: […this.data.swipeHistory, snapshot]
});
}
undoLast() {
const history = this.data.swipeHistory;
if (history.length === 0) return;
const lastState = history[history.length - 1];
this.setData({
currentIndex: lastState.currentIndex,
likedIndices: lastState.likedIndices,
vetoedIndices: lastState.vetoedIndices,
swipeHistory: history.slice(0, -1) // 移除最后一条
});
}
Trae特意提醒了我一个坑："快照要用[…array]做浅拷贝，不能直接用引用。否则你修改当前状态时，历史记录里的旧状态也会被改掉。"这种细节，如果没人提醒，我自己根本发现不了。
第三步：状态持久化。
用户投票到一半，手机来电话了，退出小程序。再进来的时候，应该恢复之前的状态。
Trae给的方案是wx.setStorageSync，把当前房间的状态存到本地。但加了两个保护：
-
过期机制 ：24小时后清除，防止拿过期的状态。
-
房间隔离 ：每个房间的存储key不同，不会串。
const STORAGE_KEY = vote_state_${roomId};
saveState() {
wx.setStorageSync(STORAGE_KEY, {
…this.data,
saveTime: Date.now()
});
}
restoreState() {
const saved = wx.getStorageSync(STORAGE_KEY);
if (!saved) return false;
if (Date.now() - saved.saveTime > 24 * 3600 * 1000) {
wx.removeStorageSync(STORAGE_KEY);
return false;
}
this.setData(saved);
return true;
}
这三步走完，vote.js从0膨胀到了约1500行。这段代码我花了整整两天，和Trae对话了几十轮。但结果是：我不仅得到了能跑的代码，还理解了为什么要这样设计 。这对我后续自己改代码、加功能，至关重要。
Day 7：云函数的"暗礁"——Trae当"排雷手"
我的状态 ：前端基本跑通了，但后端云函数一直提心吊胆。
Trae的角色 ：后端教练 + 数据一致性守护者。
微信小程序用"云开发"做后端，好处是不需要自己搭服务器，坏处是功能相对受限。其中一个很大的坑是：没有真正的事务机制 。
什么是事务？简单说就是：你要同时做两件事（比如"记录用户的投票"和"更新房间的统计"），这两件事要么都成功，要么都失败。不能出现"记录了投票但没更新统计"这种半吊子状态。
传统数据库有事务保护，但微信云开发的云函数没有。这意味着，如果代码写不好，数据很容易错乱。
我第一版代码是这样的：
exports.main = async (event) => {
const { roomId, voteData } = event;
// 第一步：记录投票
await db.collection(‘participants’).add({ data: voteData });
// 第二步：更新房间统计
await db.collection(‘rooms’).doc(roomId).update({
data: { count: _.inc(1) }
});
return { success: true };
};
看起来没问题，对吧？但Trae看了一眼就说：“这里有隐患。如果第一步成功了，第二步失败了（比如网络断了），数据库里就会有一条投票记录，但房间统计没更新。发起人看到’只有5人投票’，实际上已经有6条记录了。”
我问：“那怎么办？”
Trae给的修复方案堪称"穷人大法"——既然没有事务，那就用try-catch+“手动回滚”：
exports.main = async (event) => {
const { roomId, voteData } = event;
let participantId = null;
try {
// 先检查房间是否还在投票中
const room = await db.collection(‘rooms’).doc(roomId).get();
if (!room.data || room.data.status !== ‘voting’) {
return { success: false, error: ‘投票已结束或房间不存在’ };
}
// 检查是否重复投票
const existing = await db.collection(‘participants’)
.where({ roomId, openid }).get();
if (existing.data.length > 0) {
// 已有记录，更新
participantId = existing.data[0]._id;
await db.collection(‘participants’).doc(participantId).update({
data: { vote: voteData, updatedAt: db.serverDate() }
});
} else {
// 新记录
const result = await db.collection(‘participants’).add({
data: { roomId, openid, vote: voteData, createdAt: db.serverDate() }
});
participantId = result._id;
}
return { success: true, participantId };
} catch (err) {
// 如果已经插入了记录但后续报错，尝试清理
if (participantId) {
try {
await db.collection(‘participants’).doc(participantId).remove();
} catch (e) {
console.error(‘清理失败:’, e);
}
}
return { success: false, error: err.message };
}
};
这个方案虽然不完美（极端情况下清理也可能失败），但在云开发的限制内，已经是能做到的最优解。更重要的是，Trae解释了每一步为什么要这样做 ：为什么先查房间状态？为什么要检测重复投票？为什么participantId要在外面声明？
这些解释让我明白了一个原则：写云函数时，要把"最坏情况"都想一遍 。网络断了怎么办？数据重复了怎么办？房间突然被删除了怎么办？想得越多，代码越健壮。
Day 8：UI交互的"魔鬼细节"——Trae当"强迫症治疗师"
我的状态 ：功能基本跑通了，但用户体验很糙。滑动不顺、点击不灵、界面呆板。
Trae的角色 ：UI/UX微调师 + 交互逻辑教练。
这一天的工作很细碎，但Trae帮我解决了很多"看似小、实则关键"的问题。
问题1：swiper滑动延迟。
小程序的swiper组件有个通病：bindchange事件触发有延迟，导致用户滑到下一张了，界面还没更新状态。体验上就是"卡了一下"。
Trae的方案是"预判"：在touchstart的时候记录起点，在change的时候判断方向，提前处理逻辑。
touchStart(e) {
this.startY = e.touches[0].clientY;
},
onCardChange(e) {
const newIndex = e.detail.current;
const oldIndex = this.data.currentIndex;
const direction = newIndex > oldIndex ? ‘next’ : ‘prev’;
// 提前处理状态，不要等到change事件
this.handleSwipe(direction, newIndex);
}
Trae还加了一个细节：在滑动动画期间，暂时屏蔽其他操作，防止用户疯狂滑动导致状态错乱。这种"防手贱"设计，我自己绝对想不到。
问题2：双击和单击的冲突。
投票页面上，单击海报应该放大预览，双击应该点赞。但这两个动作怎么区分？如果用户点得快，系统会误判。
Trae的方案是"300毫秒阈值"：记录每次点击的时间戳，如果两次点击间隔小于300ms，算双击；否则算单击。单击不立即执行，而是等300ms，确认没有第二次点击后再执行。
onTapPoster(e) {
const now = Date.now();
const index = e.currentTarget.dataset.index;
if (this.lastTap && now - this.lastTap < 300) {
// 双击：点赞
this.toggleLike(index);
this.doubleTapped = true;
} else {
// 单击：延迟执行预览
this.doubleTapped = false;
setTimeout(() => {
if (!this.doubleTapped) {
this.previewImage(index);
}
}, 300);
}
this.lastTap = now;
}
这个代码我看了很久才完全理解。Trae用了一个很妙的比喻解释：“就像敲门，你敲一下，屋里人要等一会儿才开门，看看你是不是还要敲第二下。如果等了一下没有第二下，才确认你是单敲。”
问题3：配色和IP形象。
我把初始界面的截图发给Trae，说"感觉不够温馨"。
Trae给出了完整的色彩系统：
–bg-cream: #F5F0E8; /* 奶油白 /
–accent-coral: #FF6B6B; / 珊瑚红 /
–text-primary: #5A4A42; / 深棕 */
并且解释了为什么：“聚餐是温暖的社交场景，冷色调会让人有距离感。奶油白比纯白更柔和，珊瑚红比正红更亲切。”
橘仔（IP形象）的设计也是靠截图对话迭代出来的。我先说"想要一只猫"，Trae给了方向；我说"要橘色的，胖一点"，Trae调整了描述；我说"能不能有’饿晕了’的表情"，Trae给了表情包建议。整个过程像和设计师聊天，而不是对着代码编辑器发呆。
Day 9-10：收尾和打磨——Trae当"质检员"
我的状态 ：主要功能都跑通了，但代码很乱，Bug还有不少。
Trae的角色 ：代码审查员 + Bug猎手 + 优化顾问。
最后两天，我把整个项目的代码贴给Trae，让它做"全面体检"。
Trae的审查报告分几个维度：
1. Bug扫描
它找出了三处我根本没意识到的隐患：
-
一个页面在onUnload时没清除定时器，可能导致内存泄漏。
-
一个云函数里用了Date.now()而不是db.serverDate()，客户端和服务端时间不一致时会出问题。
-
一个列表页面没有上拉加载更多，数据量大了会卡死。
2. 性能建议
-
图片懒加载：海报列表在屏幕外的图片先不加载，滑到附近再加载。
-
数据分页：房间列表一次只拉20条，下拉到底再拉下一页。
-
缓存策略：高德地图API调用结果缓存1小时，避免重复请求。
3. 代码规范
-
命名不统一：有的地方用camelCase，有的地方用snake_case，Trae建议统一为camelCase（微信小程序的惯例）。
-
注释缺失：核心函数没有注释，Trae帮我补了。
-
重复代码：两个页面有相同的权限检查逻辑，Trae建议抽成公共函数。
这些工作很枯燥，但对项目的"健康度"很重要。Trae不会嫌烦，你让它检查一百遍，它还是一样认真。这种"无限耐心"是人类搭档很难提供的。
五、Trae的"隐藏技能"：不只是写代码
上面讲的是开发流程，但Trae还有一些"隐藏技能"，在关键时刻帮了大忙。
5.1 文案调性教练
「喵了个鱼」的文案风格是"猫咪化、口语化"的。这个风格不是我想出来的，是Trae建议的。
我最初用的文案很普通：“喜欢”“跳过”“报名成功”。Trae看了之后说：“你的IP是猫，为什么文案里没有猫的感觉？”
然后它给了一版：
| 原稿 | 优化稿 |
|---|---|
| 喜欢 | 想要喵 |
| 跳过 | 不想喵 |
| 报名成功 | 已喵 |
| 暂无数据 | 橘仔饿晕了，什么都没有 |
| 我来买单 | 喵大佬请客 |
| AA制 | 分摊一下 |
这种"调性统一"的能力，说明Trae不只是在处理代码逻辑，它还能理解产品的气质和情感 。这对于非技术背景的开发者来说，是意外的收获。
5.2 合规顾问
微信小程序对个人主体有很多限制：不能有支付功能、不能有公开社区、不能获取手机号。这些规则散落在微信官方文档的各个角落，自己查很费时。
Trae直接给了我一份"合规检查清单"：
-
不涉及资金交易 -
不涉及UGC公开传播
-
不涉及陌生人社交
-
工具属性优先 -
隐私保护指引完整
-
地理位置收集需单独用户同意
这份清单让我在开发初期就避开了所有雷区，不需要等到提交审核被拒了再返工。
5.3 "假设性问题"引导
Trae有个很妙的习惯：它经常在回答完当前问题后，主动提出你可能没想到的问题 。
比如我让它写了一个投票提交的云函数，它给完代码后说：“另外，你需要考虑如果用户重复提交怎么办？如果房间已经关闭了怎么办？如果网络超时怎么办？”
这些问题我本来没意识到，但被它一提，就觉得"对啊，这确实可能发生"。这种"前瞻性"的引导，让我少踩了很多坑。
5.4 降级方案提供者
有些功能我最初想得很复杂，Trae会主动建议"先做个简单的版本"。
比如"拼单功能"，我最初的设想是：用户在小程序里勾选菜单单品、计算总价、AA分摊。Trae说：“这个功能涉及菜单数据、价格计算、分摊逻辑，复杂度很高。建议先降级为’成员只决定是否参与+选哪家店，小程序不介入支付’。这样既保留了核心体验，又避开了支付合规问题。”
这个建议非常务实。我没有被"做不出来"打击，也没有被"一定要做完美"绑架，而是拿到了一个能跑起来的中间方案 。
六、那些踩过的坑，和Trae也帮不了的事
Trae很强，但不是万能的。有些坑，它也帮不了我。
6.1 坑1：swiper组件的硬限制
微信小程序的swiper组件有一些底层限制，比如：
-
不能无限循环（到头了会弹回）
-
bindchange延迟无法根本消除
-
动态增删卡片时会闪一下
这些问题不是代码逻辑问题，是组件本身的问题。Trae能做的只是"绕过"，而不是"解决"。比如用touch事件预判，用cover-view覆盖避免闪烁。但终究不是完美方案。
这个经历让我明白：AI助手只能在平台能力范围内发挥，平台的硬限制，谁也突破不了 。
6.2 坑2：云函数没有真正的事务
前面提到的数据一致性问题，Trae给的方案是"手动回滚"。但这个方案在极端情况下也会失效——比如回滚的时候网络又断了。这时候数据库里就是脏数据，需要人工介入清理。
Trae很坦诚地告诉我：“在云开发的架构下，这是能做到的最优解。如果业务对一致性要求极高，可能需要考虑自建服务器或使用支持事务的数据库。”
这种"诚实告知边界"的态度，比盲目承诺更能建立信任。
6.3 坑3：AI理解不了的"感觉"
有些设计决策，不是逻辑问题，是"感觉"问题。
比如按钮的颜色，Trae可以给出色值，但它不知道"这个按钮在屏幕上是不是太显眼了"“和周围元素是不是协调”。这些需要开发者自己的审美判断。
再比如交互节奏：滑动动画应该0.3秒还是0.5秒？弹窗提示应该停留2秒还是3秒？这些细微的"手感"，AI只能给参考值，最终还是要靠人一个一个试。
6.4 Trae帮不了的事：你必须理解自己的代码
这是最重要的一条。
Trae能帮你写代码、改代码、解释代码，但它不能替你做代码的主人 。如果你完全不懂代码逻辑，Trae改完之后你不敢用，因为它改了哪里、为什么改、改了之后会不会影响别的地方，你一无所知。
我在开发过程中养成了一个习惯：Trae给的每一段代码，我都要逐行问"这是什么意思"“为什么要这样写”“如果改一下会怎么样”。有时候Trae的解释我一遍听不懂，我就让它换种说法，或者用比喻讲。直到我真的懂了，才把这段代码合并进项目。
这个过程很慢。但正是因为慢，我才能在10天结束时，对自己的项目有基本的掌控感 。哪里出问题了，我能大概知道去哪个文件、哪个函数里找。而不是像一个完全依赖翻译的旅客，一旦翻译不在就寸步难行。
七、写给和我一样的普通人：AI协作的四个心得
如果你也是一个"有想法但不会写代码"的普通人，正在犹豫要不要用AI工具做点什么，以下是我这10天里沉淀下来的四条心得。
心得1：提问的能力，比写代码的能力更重要
和AI协作，本质上是一场"对话"。你的问题问得越清晰，AI的回答就越精准。
我总结了一个提问公式：
场景 + 需求 + 约束 + 预期输出
举例：
-
低效提问：“怎么实现投票功能？”
-
高效提问：“我在做微信小程序投票页（场景），需要支持海报上下滑动和分类两步选择（需求），要求能撤销和本地恢复（约束），请帮我设计状态管理方案（预期输出）。”
这个公式对任何AI工具都适用。Trae之所以在我这里表现好，很大程度上是因为我学会了怎么跟它"好好说话"。
心得2：迭代，再迭代，不要一步到位
不要指望AI一次性给你完美方案。正确的姿势是：
-
第一轮：要骨架（架构、模块拆分）
-
第二轮：要核心逻辑（关键函数、状态设计）
-
第三轮：要错误处理（边界情况、异常分支）
-
第四轮：要优化（性能、代码风格、注释）
每一轮都基于上一轮的成果，逐步细化。Trae在这种迭代中表现很好，因为它能记住之前的上下文，不会"失忆"。
心得3：让AI审查，而不是只让AI写
很多人用AI编程工具只是"让它写代码"，但忽略了另一个更有价值的用法：让它审查你的代码 。
我的做法是在每个功能模块写完之后，把完整代码贴给Trae，问：“请审查这段代码，关注：1.潜在Bug 2.性能问题 3.代码风格 4.是否符合微信小程序最佳实践。”
Trae的审查经常能发现我自己完全没意识到的问题。而且审查的过程，也是我自己学习的过程——看它指出的问题，理解"为什么这是问题"，下次就能自己避免了。
心得4：截图是最低成本的沟通方式
如果你不会用专业术语描述UI问题，截图就是最好的语言 。
我把界面截图发给Trae，说"这里看着不舒服"，它能理解我的意思，并给出具体的调整建议（色值、间距、字体大小）。这种"视觉对话"的方式，极大降低了非技术人员和AI之间的沟通门槛。
八、结语：一个中年人的10天，和一点感受
10天前，我连WXML和WXSS是什么都不知道。10天后，我做出了一个能跑的小程序。
这个变化不是因为我突然变聪明了，而是因为工具变了 。
Trae SOLO 没有替我思考，但它把我的思考翻译成了可执行的代码 。它也没有替我决策，但它把决策需要的信息结构化地摆在了我面前 。它更没有替我承担学习的责任，但它让学习的过程变得有引导、有反馈、有节奏 。
我想特别说一点：作为一个40多岁的中年人，我一开始是有心理障碍的。"学编程"这件事听起来像是年轻人的专利，我这个年纪开始，是不是太晚了？别人会不会觉得我在瞎折腾？
但Trae的存在让我意识到：门槛已经变了 。以前学编程的门槛是"记住语法、理解算法、配置环境"。现在的门槛是"能想清楚自己要什么，并能用自然语言表达出来"。后者对中年人来说，往往是优势——我们有更多生活经验，更清楚"用户真正需要什么"，也更耐得住性子做迭代和打磨。
我不是在鼓吹"AI让所有人都能当程序员"。程序员的职业门槛依然很高，专业的软件工程需要深厚的技术积累。我想说的是，对于"想亲手做一个东西"的普通人来说 ，AI工具已经把"从0到1"的门槛，降到了历史最低。
最后，我想用一句话总结这次经历：
以前我觉得，不会写代码就做不了小程序。现在我发现，只要有清晰的想法和一个愿意陪你一步步走的AI，普通人也能把想法变成现实。
Trae SOLO 就是那个"愿意陪你一步步走"的AI。它不耀眼，不炫技，但它很稳。对于一个需要稳稳走到终点的人来说，这就够了。
联系方式： vx（oygq15510183555）
- 欢迎交流，特别欢迎同样是"零基础起步"的朋友。
感谢 Trae SOLO 在这次开发中的陪伴。
也感谢那个决定"试试看"的自己。
真心希望做个有价值、爱用的小程序
）。
吹吹牛。你也可以的