用 Trae 全 AI 编程，从零到一开发一款微信小程序：极速图像工具箱的诞生

当 AI 不再只是补全代码的助手，而是成为整个项目的"首席开发者"，开发范式正在被重写。本文记录我使用 Trae 编辑器，以"全 AI 编程"模式开发一款微信小程序「极速图像工具箱」的完整实践。

一、为什么选择 Trae 做全 AI 开发

传统 IDE 时代，开发者是"驾驶员"，AI 只是副驾。但在 Trae 中，角色发生了反转——AI 成为执行者，开发者更像"产品经理 + 架构师"，负责描述意图、审查方案、验收结果。

Trae 的几个核心能力让"全 AI 开发"成为可能：

语义化代码检索：AI 能基于意图定位代码，而非依赖关键字匹配。例如我说"找到所有底部广告占位逻辑"，它能精准定位到 20+ 个页面的相关代码块。
多文件并行编辑：当需要把同一套广告占位模式应用到 20 个页面时，AI 能批量识别模式并逐个修改，保留每个文件的上下文。
上下文感知的工程化操作：AI 能读懂整个项目结构，理解模块划分（module1~module4），自动识别哪些页面需要同步修改。
可验证的工程实践：AI 会主动调用 Advisor 进行方案审查，避免"拍脑袋"式修改。

二、项目背景：极速图像工具箱

这是一款工具类小程序，基于 uni-app + Vue2 构建，目标平台为微信小程序。项目结构如下：
pictureToolbox/
├── pages/
│ ├── index/ # 主入口
│ ├── module1/ # 时间日期工具
│ │ ├── converter/ # 单位换算
│ │ ├── countdown/ # 倒计时
│ │ ├── date-calc/ # 日期计算
│ │ ├── lunar/ # 农历查询
│ │ └── salary-calc/ # 薪资计算
│ ├── module2/ # 图像处理工具
│ │ ├── compress/ # 图片压缩
│ │ ├── convert/ # 格式转换
│ │ ├── enhance/ # 图片增强
│ │ ├── grid/ # 九宫格切图
│ │ ├── id-photo/ # 证件照
│ │ ├── ocr/ # 文字识别
│ │ ├── image-merge/ # 图片合并
│ │ └── qrcode/ # 二维码生成
│ ├── module3/ # 文本处理工具
│ │ ├── case-convert/ # 大小写转换
│ │ ├── json-format/ # JSON 格式化
│ │ ├── password/ # 密码生成
│ │ ├── text-clean/ # 文本清洗
│ │ └── text-stats/ # 字数统计
│ └── module4/ # 生活查询工具
│ ├── express/ # 快递查询
│ ├── garbage/ # 垃圾分类
│ ├── health/ # 健康计算
│ └── info/ # 实用信息
└── manifest.json

4 大模块、20+ 功能页面、集成微信广告变现（激励视频 / 插屏 / Banner）——这是一个具有真实商业价值的小程序，而非玩具 demo。

三、全 AI 开发的工作流

3.1 需求描述即开发指令

在 Trae 中，我不再写代码，而是写"需求文档"。例如底部广告占位需求，我只描述意图：

"所有添加了底部广告位的页面，都要让功能能正常显示出来，不要遮挡住业务功能的使用和显示，底部都要加一个和广告占位的元素，底部广告关闭后就把站位元素去掉。"

Trae 的 AI 会自动完成：

扫描所有页面，识别哪些页面有底部广告位
设计统一的解决方案（ad-placeholder 元素 + v-if="!bottomAdClosed" + adCloseBottom 方法）
逐个文件应用修改，保持代码风格一致
主动维护 TodoList 跟踪 20+ 文件的修改进度

3.2 工程化模式抽取

当 AI 发现同一模式需要在 20 个页面重复应用时，它不会简单地复制粘贴，而是抽取出一个标准化模式：

<!-- 模板层：占位 + 广告容器联动 -->
<view class="ad-placeholder" v-if="!bottomAdClosed"></view>
<view class="footer" v-if="!bottomAdClosed">
    <ad-custom unit-id="xxx" bindclose="adCloseBottom"></ad-custom>
</view>

// 逻辑层：状态驱动
data() {
    return { bottomAdClosed: false }
},
methods: {
    adCloseBottom() { this.bottomAdClosed = true; }
}

/* 样式层：占位与广告等高 */
.ad-placeholder { height: 140rpx; }

这种"模板→逻辑→样式"的三层模式，AI 会在每个页面精确套用，同时处理每个页面的特殊性（比如有的页面原本有 padding-bottom，需要移除以避免双重占位）。

四、技术深水区：激励视频广告的踩坑与 AI 修复

真正考验 AI 工程能力的，是处理微信小程序原生 API 的边界 case。激励视频广告的集成过程，是一个绝佳的"AI 调试"样本。

4.1 第一层问题：show() 一次后失效

现象：用户第一次观看广告正常，第二次点击播放就再也无法弹出。

AI 诊断过程：

我向 Trae 描述："激励广告 bug，点击播放第一次后就无法再弹出来了"。

AI 立即定位到 watchAd 方法，发现原来的写法是：

this.videoAd.show().catch(() => {
    this.videoAd.load().then(() => this.videoAd.show());
});

问题在于：第二次 show() 失败时进入 catch，调用 load() 后再 show()，但最内层的 show 没有 catch，错误被 Promise 链吞掉，用户看不到任何反馈。

AI 的修复方案：改为"先 load 再 show"的链式调用，统一在末尾 catch：

this.videoAd.load()
    .then(() => this.videoAd.show())
    .catch(err => {
        uni.showToast({ title: '广告加载失败', icon: 'none' });
    });

同时 AI 主动补充了两个需求：

播放前增加确认弹窗 uni.showModal，避免误触
冷却时间从 15 秒改为 5 秒，5 秒内点击给出 toast 提示

这些"超出指令"的优化，体现了 AI 对产品体验的理解。

4.2 第二层问题：跨页面调用报错

现象：在页面 A 看完广告，跳转到页面 B，调用 show() 报错：
you can only invoke show() on the page where rewardedVideoAd is created

AI 的第一轮尝试：通过 getApp().globalData 共享实例引用，在新页面 initVideoAd 时先 destroy 旧实例。

结果触发了新的报错：
removeTextView:fail 33334 not found

这是微信 SDK 内部警告，但 AI 当时认为这是致命错误，第二轮又把 destroy 全删了——结果跨页面报错重新出现。

关键转折点：AI 主动调用 Advisor 审查

在用户表达"越改越错"的不满后，AI 触发了 AdvisorTool（策略审查机制），Advisor 给出关键判断：

"原来的 'you can only invoke show()' 错误很可能不是 load/show 模式导致的，而是你自己的 globalData/destroy 改动引入的。当前代码可能已经接近正确，你需要先读取完整文件状态，而不是继续盲目修改。"

AI 随后完整读取了文件，并主动调用 WebSearch 查阅微信官方文档，找到了关键一句：

"该方法返回的是一个单例，该实例仅对当前页面有效，不允许跨页面使用。"

4.3 最终方案：onUnload 生命周期清理

AI 综合官方文档和社区实践，给出了最终方案——在 onUnload 中完整清理实例：

onUnload() {
    // #ifdef MP-WEIXIN
    if (this.videoAd) {
        try {
            // 1. 先解绑事件监听器，防止内存泄漏
            this.videoAd.offClose && this.videoAd.offClose();
            this.videoAd.offError && this.videoAd.offError();
            this.videoAd.offLoad && this.videoAd.offLoad();
        } catch(e) {}
        // 2. destroy 释放单例绑定（removeTextView 警告无害）
        try { this.videoAd.destroy(); } catch(e) {}
        // 3. 清空引用，配合 initVideoAd 的防重复初始化
        this.videoAd = null;
    }
    // #endif
}

这个方案体现了 AI 工程化的三个关键判断：

destroy() 是必须的——它是释放单例绑定的唯一方式，removeTextView 警告是 SDK 内部清理原生视图的副作用，不影响功能
try/catch 双重隔离——offClose 等方法和 destroy() 在不同基础库版本行为不同，分别隔离确保一个失败不影响另一个
配合 initVideoAd 的防重入——if (this.videoAd) return; 防止页面生命周期内重复绑定监听器

4.4 AI 调试的方法论价值

这次踩坑过程最大的价值，不是最终代码，而是AI 暴露出的调试方法论：

阶段	AI 行为	教训
第一轮	直接改 load/show 链	✅ 正确方向
第二轮	加 globalData + destroy	❌ 过度工程化，引入新问题
第三轮	删除所有 destroy	❌ 矫枉过正，丢失关键修复
第四轮	Advisor 审查 + 查官方文档 + 完整读文件	✅ 回归工程化思维

AI 不是神，它会犯错。但 Trae 的 Advisor 机制让 AI 具备了"自我反思"的能力——当用户表达不满时，AI 不会继续蛮干，而是停下来重新审视全局。

五、AI 编程的工程化能力

5.1 TodoList 驱动的批量工程

处理 20+ 个文件的批量修改时，AI 主动维护 TodoList：
□ Update module1 pages (6) with bottom ad placeholder
□ Update module2 manually-added pages (2) with bottom ad placeholder
□ Update module2 rewarded-video pages (6) with bottom ad placeholder
□ Update module3 pages (5) with bottom ad placeholder
□ Update module4 pages (4) with bottom ad placeholder
□ Update index pages (5) with bottom ad placeholder

每个任务完成后立即勾选，遇到错误会暂停并评估影响范围。这种"任务编排"能力，是传统 IDE 完全不具备的。

5.2 并行工具调用

Trae 支持 AI 在单次响应中并行调用多个工具。例如同时读取 6 个文件的相关代码段，同时搜索多个关键字。这大幅缩短了"理解上下文"的耗时。

5.3 条件编译的精准处理

uni-app 的 #ifdef MP-WEIXIN 条件编译是 AI 容易踩坑的地方——它需要理解"这段代码只在微信小程序执行"。Trae 的 AI 能正确识别这些指令块，在修改微信特有逻辑时自动包裹条件编译，不污染其他平台的代码。

六、全 AI 开发的边界与反思

实践下来，全 AI 开发小程序是可行的，但有明确边界：

AI 擅长的领域

重复性工程：同一模式应用到 N 个文件（如广告占位）
API 集成：调用微信原生 API、处理 Promise 链
样式调整：CSS 定位、响应式布局
Bug 定位：基于错误信息 + 代码上下文 + 官方文档三方对照
工程化重构：抽取公共模式、统一代码风格

AI 需要人类介入的领域

产品决策：广告位的商业策略（5 秒还是 15 秒冷却？是否强制观看？）
架构权衡：是否需要把广告逻辑抽成 mixin 或组件
边界 case 的取舍：removeTextView 警告是否可接受，需要人类基于产品上下文判断
UI/UX 细节：广告占位高度是 140rpx 还是 220rpx，需要人类视觉验收

最佳协作模式

我的实践总结出一种"意图驱动 + 方案审查 + 结果验收"的协作模式：

开发者描述意图：用自然语言说清"要做什么"和"约束条件"
AI 提出方案：Trae 的 AI 会先分析、调用 Advisor 审查、再执行
开发者验收结果：检查 AI 修改的代码、运行测试、决定是否接受

这个循环里，AI 承担了 80% 的执行工作，人类聚焦在 20% 的决策工作上——这才是"全 AI 开发"的真正含义：不是 AI 独立完成所有事，而是 AI 把开发者从"写代码"解放出来，专注于"想清楚要做什么"。

七、结语：工具类小程序的 AI 开发范式

极速图像工具箱的开发实践证明：一个包含 4 大模块、20+ 功能页面、集成广告变现的微信小程序，完全可以通过 Trae 以"全 AI 编程"模式交付。

这个范式对工具类小程序尤其有效，因为：

工具类页面结构相似，AI 能高效复用模式
业务逻辑相对独立，AI 不需要理解复杂领域知识
微信 API 文档完善，AI 能通过 WebSearch 获取最新规范

Trae 的价值不在于"让不会写代码的人写代码"，而在于让会写代码的人从机械劳动中解放，把精力投入到真正需要人类智慧的产品决策上。

下一个十年，开发者的核心竞争力不再是"记住多少 API"，而是"能否清晰描述意图、能否审查 AI 的方案、能否在 AI 犯错时及时纠偏"。Trae 这样的 AI IDE，正在重塑这个能力的定义。

本文基于「极速图像工具箱」小程序的真实开发实践整理。项目技术栈：uni-app + Vue2 + 微信小程序原生广告组件。

当然，真正的全流程肯定比描述的更多，但是足以见得ai的强大，该项目总共时长估计也就五六个小时，虽然里面的功能比较简单，都是前端方面的，但是如果是在没有ai的情况下，肯定是这个时间的数倍不止。
好了，给大家看看最终实现成果！大家可以扫码看看。

gh_9a1341a30d1e_258
（极速图像工具箱）

posted @ 2026-08-16 18:09 健伟博客阅读(34) 评论(0) 收藏举报

刷新页面返回顶部

健伟博客

每一行代码。就是每一条生命，生命诚可贵，代码价更高