挑战来啦！4天内用AI编码，竟然能从零打造一个超强小程序！

从零到一：我用 AI 开发行李打包助手的实践经历

你有没有想过，AI 能不能真正帮我们开发一个实用的小程序呢？这篇文章就是我这次实验的分享。我利用了 Qoder 代码助手，加上我自己的想法，在短短 4 天内，从头开始搭建并成功上线了一个「行李打包助手」的小程序。接下来的内容里，我会聊聊：

• 我是如何把需求逐步“翻译”给 AI 的
• AI 在项目中的表现如何，哪些地方还是需要人来把关
• 在开发过程中遇到的一些典型问题，比如数据结构、权限、图片上传等
• 这款小程序的功能介绍和使用方法

---

一、先说结果：我这四天做了些什么？

我开发的是一个行李打包助手的小程序，主要功能有：

• 我的物品：可以维护常用的物品，比如「牙刷」「充电器」「奶瓶」「帐篷」等等
• 打包方案（Plan）：
• 私有方案：我自己常用的打包模板
• 公共方案：系统推荐的一些方案，比如「商务出差」「亲子游」「露营」「海边度假」等
• 打包任务（Mission）：
• 可以从方案生成任务，轻松复制方案里的物品，形成这次出行的打包清单
• 支持记录每次打包的进度和完成度

在技术方面，我用的是一个典型的 Taro + React + TypeScript + VantUI + 腾讯云函数 + 云数据库 的组合：

• 前端：Taro 4.x + React 18 + TypeScript
• UI：@antmjs/vantui（Taro 版 Vant）
• 后端：腾讯云云函数（material / plan / mission / userinfo）
• 数据库：云开发数据库，主要字段有 openId、isPublic、isDeleted、createdAt、updatedAt

整个过程中，我的重点是：全程依靠 Qoder 进行协同编程，而我更多的是在扮演产品经理、架构师和代码审核的角色。

---

二、我为什么想做这个实验？

其实有三个主要原因：

1. 测试 AI 在实际项目中的能力上限 你知道，AI 能写简单的 demo 组件很容易，但真正到了：

• 多页面路由
• 云函数
• 权限与数据隔离
• 线上问题调试

这时候就能明显看到 AI 是否能成为我的得力助手。

2. 探索「人 + AI」的协作模式 包括：

• 如何给 AI 描述需求
• 什么时候该让 AI 查代码，什么时候自己查
• 如何确保 AI 一直沿用当前项目的技术栈和代码风格

---

三、项目技术栈与基础搭建（第1天）

1. 技术栈的选择

一开始，我就和 Qoder 确定了技术栈和一些约束条件，要求它不要随便引入不存在的库：

• 使用 Taro 4.1.8 + React + TypeScript
• UI 库统一用 @antmjs/vantui
• 数据存储统一用 腾讯云开发数据库
• 业务模块化拆分页面：
• /pages/material/* 物品模块
• /pages/plan/* 方案模块
• /pages/mission/* 任务模块
• /pages/home/* 首页
• /pages/profile/* 个人中心 / 设置

在这个过程中，AI 主要做了以下几件事：

• 根据路由约定生成初始页面文件：home.tsx / list.tsx / detail.tsx / add.tsx
• 帮我搭建基础布局：顶部标题、列表样式、空状态、按钮等
• 统一使用 VantUI 的组件，比如 Button、Tabs、Empty、Search、SwipeCell 等

2. 数据模型设计

我先口头描述了需求，然后请 Qoder 帮我整理成数据结构，接着一起打磨：

• 物品（Material）
• name: 物品名称
• image: 图片 fileID
• defaultQuantity: 默认数量
• unit: 单位（个 / 件 / 套）
• description: 描述信息
• openId: 所属用户
• isDeleted: 软删标记
• createdAt / updatedAt

• 方案（Plan）
• _id
• name / icon / description / category / tags
• materials: { materialId, name, quantity, unit }[]
• itemCount / usageCount
• isPublic: 是否公共方案
• openId: 所属用户（公共方案这里可以为空或统一用系统账号）
• isDeleted / createdAt / updatedAt

• 任务（Mission）
• _id
• title / planId / planName
• items: { materialId, name, quantity, unit, checked }[]
• progress / totalItems / completedItems
• status: active / completed / archived
• openId / isDeleted / createdAt / updatedAt

在这一块，AI 的帮助主要体现在：

• 将我零散的需求整理成清晰的字段列表
• 统一了 createdAt / updatedAt 等时间字段的定义
• 同时实现了云数据库和云函数，前后端保持在同一起跑线

云函数的部分也交给 AI 来处理，写得相当标准：

---

四、核心功能开发（第2天）：物品 / 方案 / 任务

1. 物品管理页（Material）

功能包括：

• 物品列表：支持搜索和分页（后续可以扩展）
• 添加 / 编辑物品：包含名称、图片、默认数量、单位、描述
• 删除物品（软删）

其中有个比较有趣的坑：图片上传

最开始的实现是这样的：

• 在 Uploader 组件的 onAfterRead 里又调用了一次 Taro.chooseImage
• 结果就是：
• 第一次点击上传 → 选择图片
• 上传回调里又弹出一次选择 → 再选一次
• 结果需要选两次图片才能上传成功

我把问题描述给 Qoder，经过它的代码分析，帮我改成了：

• 直接用 onAfterRead 给的 file.url / file.path
• 在这里调用 Taro.cloud.uploadFile 进行上传
• 成功后：
• setImageList([{ url: tempFilePath, isImage: true }])
• updateField(“image”, uploadResult.fileID)

修好之后，上传流程简化为一次点击和一轮选择，体验也变得顺畅了。

2. 方案列表与详情（Plan）

这里有两个关键点：

（1）我的方案 vs 公共方案

产品需求是：

• 方案列表页增加 Tab：
• 「我的方案」
• 「推荐方案（公共）」
• 公共方案是我预先准备的一批 JSON 数据，导入到腾讯云数据库中
• 首页的「推荐打包方案」展示的是公共方案（isPublic = true），而不是我自己创建的方案

一开始云函数的写法比较粗糙，只是简单根据 openId 过滤，导致：

• 无论如何传递 isPublic，查出来的始终是「我自己的方案」，公共方案完全无法获取。

于是我和 Qoder 一起调试云函数 serverless/plan/index.js：

• 在 listPlans 方法中增加了对 isPublic 的判断：
• isPublic === true → 只查询 where.isPublic = true，不再加 openId 条件
• isPublic === false → where.openId = openId 且 where.isPublic = _.neq(true)

如何让你的方案更易管理？

• 如果 isPublic 是空的，系统默认会查找当前用户的所有方案，这样就兼顾了老用户的习惯。

在前端的使用方式上：

• 首页的推荐方案在调用云函数时，务必要传递 isPublic: true。
• 在方案列表页面加载时，会同时获取 isPublic: false 的个人方案和 isPublic: true 的公共方案，然后通过 Tab 来进行前端筛选。

（2）公共方案只能收藏，无法直接编辑

• 如果方案详情页的 isPublic 为 true：
• 编辑入口会被隐藏，取而代之的是一个「收藏方案」按钮。
• 点击「收藏」时，会弹出一个确认框，提示用户这将把方案复制到自己的方案库。
• 在云函数中，会使用 action: “add” 来新建一条记录，复制所有字段，但不会继承原来的 _id。
• 成功收藏后，系统会自动跳转到新方案的详情页，此时它就变成了私有方案，用户可以自由编辑。

这部分主要是我描述需求，Qoder 提出实现方案，我再根据用户体验微调文案和交互设计。

3. 从方案生成任务（Mission）

• 在方案详情页中添加一个「生成任务」的按钮。
• 点击后会弹出确认框，询问用户是否要使用方案「xxx」创建新任务。
• 确认后会跳转到 /pages/mission/add?planId=xxx，在任务创建页面加载方案中的物品，并生成任务项目列表，默认情况下全都未勾选。

---

五、首页体验优化（第3天）：推荐方案与进行中任务

1. 首页推荐方案区

首页的「推荐打包方案」模块最终呈现如下：

• 顶部标题：推荐打包方案 + 右侧有「查看全部 →」的链接。
• 中间是分类标签：全部 / 商务 / 家庭 / 旅行 / 户外。
• 下方是卡片网格，展示公共方案的图标、名称、物品数量以及使用次数。

这个部分经历了几次迭代：

1. 最初使用的是模拟数据，前端手动写死了几条方案。
2. 随后我把真实的公共方案数据导入云数据库（用 JSONL 一条条导入）。
3. 接着将首页改为调用云函数 plan.list，传递 isPublic: true，使用真实数据进行渲染。
4. 最后把底部的「查看更多方案」按钮改成标题右上角的「查看全部 →」，这样交互也更加统一（保持与「进行中的任务」一致）。

2. 进行中任务的自动刷新

最开始的实现方式是：

• 在首页使用 useEffect 在组件挂载时调用 fetchActiveMissions()。
• 当我在「我的任务」里创建了一个新任务后返回首页，发现 列表没有刷新。

于是我让 Qoder 查看首页的代码，他指出需要使用 Taro 的 useDidShow：

• useEffect 只在组件首次挂载时执行。
• 小程序从 A 页面返回到 B 页面时，B 并不会重新挂载，只会触发 onShow。

因此，我们在首页增加了：

useDidShow(() => {
  fetchActiveMissions();
});

这样无论是：

• 在「我的任务」中创建新任务后返回，
• 还是从任务详情返回首页，

「进行中的任务」都会自动刷新。

---

六、发布与上线（第4天）：查漏补缺与真机测试

最后一天我主要做了以下事情：

1. 真机调试

• 检查所有页面在真机上的表现：滚动、点击区域、字体大小。
• 重点关注的包括：
• 公共方案详情页是否为只读状态。
• 收藏后是否真的复制一份到我的方案里。
• 从方案生成任务后，任务列表和首页是否都能同步显示。

2. 排查小 bug

• 物品上传需选两次图片的问题 → 已修复，改用 Uploader 的 onAfterRead 自带文件。
• 公共方案未显示的问题 → 云函数过滤条件修正 isPublic。
• 从首页点击「查看更多推荐方案」跳转到方案列表后，要默认定位到「推荐方案」Tab → 在路由里加参数 ?tab=public，方案列表读取 URL 参数设置初始 Tab。

3. 提交审核与发布

• 整理小程序的基本信息（名称、描述、分类、图标）。
• 截取几张关键页面截图：首页、物品管理、方案详情、任务打包界面。
• 进行小程序备案（如果是拿现有的小程序发布，可以跳过备案直接上线，之后再更新备案）。
• 提交审核，等待上线。

---

七、AI 在这个项目中的角色

简单总结一下这四天的工作中，我和 Qoder 的分工：

AI 表现出色的部分：

1. 重复性页面和组件的生成

• 新建列表、详情、表单页：一旦风格确定，后续基本上都是「复制 + 微调」。
• 统一使用 VantUI 的组件，保持 UI 一致性。

2. 云函数参数和返回结构的梳理

• 将 plan.list / plan.get / plan.add / plan.update / plan.delete 的入参和出参统一成一个模式。
• 通过 action 字段来区分操作，确保前后端的理解一致。

3. 逻辑问题的排查

• 公共方案查不到的情况：发现代码里 where.openId = openId 写死了，帮我拆分成 isPublic === true / false / null 三种情况。
• 页面不刷新的问题：提醒我「这里需要用 useDidShow，而不是只用 useEffect」。

4. 代码风格和一致性

• 在多个文件中帮助我统一命名、TypeScript 类型定义和 Toast 文案的风格。

AI 目前还无法做好的部分（需要人来把关）：

1. 产品侧的权衡

• 例如，公共方案是否能直接修改？如何提示用户复制？
• 首页是否展示「收藏」功能？我最后决定：只在详情页保留收藏入口。

2. 数据设计中的边界

• 如何区分「用户私有方案」和「公共推荐方案」；是否允许用户将自己的方案公开等等，这些需要自己仔细思考。

3. 真机体验和细节打磨

• 列表的滚动手感、按钮点击区域、文案是否清晰，这些仍需亲自体验和检查。

---

八、如果你也想尝试「全程用 AI 写一个小程序」，我的一些小建议

1. 先给 AI 阐明「世界观」

• 技术栈：Taro + React + TypeScript + VantUI + 云函数。
• 文件结构：pages / serverless / data。
• 数据模型：Material / Plan / Mission 的字段和关系。

2. 从「修改」入手，而不是一开始就让它「全帮你写」

• 先让它了解现有文件，再给出修改建议。
• 例如：「请在 plan/list.tsx 中加一个 Tab，用于区分我的方案和公共方案。」

3. 用「场景 + 预期行为」来提出需求，而不是单纯说「实现一个功能」

• 「从首页点击『从方案生成』，应该跳转到方案列表页；从『推荐打包方案』点击『查看全部』，应该默认定位到『推荐方案』Tab。」

4. 将 AI 当作全职的搭档，而不是外包

• 你的职责包括：
• 需求决策。
• 最后的代码审核。
• 真机体验和发布。
• AI 的职责包括：
• 写代码。
• 查找逻辑问题。
• 帮助记住项目的上下文。

---

九、最后，欢迎体验这款小程序

如果你常常：

• 出差前紧张兮兮地怕丢东西。
• 带娃出门总是感觉「这个也要带、那个也要带」。
• 周末想去露营，却每次都在群里问「有什么必带清单？」。

那可以试试这款小程序：

• 创建属于自己的「出差方案 / 亲子方案 / 露营方案」。
• 下次出发前，从方案一键生成任务，按照清单逐一打勾就行了。
• 公共推荐方案中还有几套常见场景，可以直接使用。
• 别忘了先维护好自己的常用物品哦。

小程序入口（扫码或者搜索 “快备丨AI智能出行打包清单”）：

---

Qoder 下载链接：https://qoder.com/