【AI】我用 WorkBuddy 做了一个微信小程序：拿「Offer 体验站」讲清 AI 开发怎么上手

🫧个人主页：小年糕是糕手

💫个人专栏：《C++》《数据结构》《Blender 修行笔记》《AI》

🎨你不能左右天气，但你可以改变心情；你不能改变过去，但你可以决定未来！

目录

一、先看成品：我到底想解决什么问题？

二、第一版为什么要重来？因为“工具”和“社区”差得很远

还有三个要求，需要在开发中反复守住

三、开发前需要准备什么？先把几个环境分清楚

“前端不用装 npm 包”，不等于“整个项目没有依赖”

四、第一轮开发，先让三页之间真正走得通

每次给 AI 一个可以验收的小任务

五、拆开“给建议”：一个按钮后面到底发生了什么？

1. 打开界面

2. 读取输入并检查

3. 更新本地数据

4. 云函数处理写入

5. 其他用户读取更新

这里还有一个本地开发版的真实缺口

六、最典型的一次返工：页面成功了，数据库为什么没成功？

为什么前端看起来没事？

出问题时，怎样让 AI 帮忙查？

七、页面变暗却点不动：一次看起来像逻辑错误的样式问题

八、能在模拟器里打开，还会遇到哪些上线问题？

1. 工具文件被一起打进小程序包

2. 调用了内容安全接口，却漏了云调用权限

3. 演示数字混进了正式界面

九、功能做完以后，还可能卡在资质和审核上

十、结案和“我的”页，为什么放在主流程之后？

十一、这个项目还没有完善的地方，也应该讲清楚

十二、第一次用 AI 做项目，可以照这个顺序完成一个小版本

第一步：写清一个人要做的一件事

第二步：先做三页和一份演示数据

第三步：接入自己的云环境

第四步：用两个测试账号检查主流程

第五步：故意制造几种失败

第六步：再处理上传、审核和下一轮功能

给 AI 的任务，最好有一个明确的结束条件

十三、写在最后

页面已经弹出“提交成功”，数据库里却找不到刚才写入的数据。

这是我开发「Offer 体验站」时遇到的一个真实问题。

前端没有明显报错，页面也能正常操作。继续排查，才发现云函数写入数据时，把数据库的 _id 字段也塞进了更新内容，导致部分操作一直失败。

在这之前，我还遇到过另一种情况：点击“给建议”，页面变暗了，弹层却怎么也点不动。看起来像功能没实现，最后发现只是两段样式用了相同的类名，遮罩盖到了弹层上面。

这些问题，比“AI 几分钟生成一个首页”更值得写下来。

前面的文章聊过个人开发的工作流程。这一篇，我想拿自己用 WorkBuddy 开发的微信小程序做一次具体复盘：怎样把想法交给 AI，第一版为什么会做偏，怎样接上后端，以及一个看起来能用的页面，距离真正上线还有哪些工作。

如果你也想做一个自己的小程序，可以跟着这篇文章先完成一条小流程，再逐步扩展。

阅读说明

目前线上版本是 0.3.5，已经通过申诉并正式发布；本文同时检查了本地尚未发布的 0.4.0 源码，涉及开发版的问题会单独说明。

完整开发聊天没有保留。下文的提示词根据真实需求和返工经历重新整理，供读者参考，不是当时对话的逐字记录。

配图用于说明界面与操作，不能据此推算真实用户数量或业务规模。补拍的建议弹层、结案页和“我的”页来自本地开发版。

一、先看成品：我到底想解决什么问题？

「Offer 体验站」想做的是一个职业选择社区。

一个人拿到 Offer，真正纠结的内容，往往不止薪资：

• 新工作多给了几千块，但每天要多通勤两个小时，值不值得？
• 现在的岗位没什么成长，不过领导允许自己照顾家人，要不要走？
• 两份工作，一份收入高，一份更稳定，怎么选？
• 面试时说得很好，真正入职以后又是什么样？

这些问题很难靠一个分数回答。

我的想法是，让当事人把自己的处境说出来，再由有相似经历的人补充信息、给一句建议。等做出选择、真正入职之后，还能回来记录后续。

首页因此应该先展示别人正在纠结的事情。

广场界面：读者先看到具体处境，再决定是否参与讨论。

项目还有一个我比较坚持的前提：

不评判职业贵贱。蓝领、骑手、店员和白领，都应该有适合自己处境的表达方式。

所以发布时没有只围绕白领设计表单，而是分成七类职业：

这些分类会影响发布字段和评价维度。

例如，讨论工厂岗位时，“倒班制度”“宿舍食堂”可能很重要；讨论自由职业时，照搬“晋升速度”就不合适了。

发布入口：先选择职业类别，再展示相应字段。

现在的项目还包括树洞、工作瞬间、Offer 对比和入职记录等模块。但如果你第一次做项目，先别照着这个功能数量开工。

这篇文章只抓住一条主线：

看到别人的纠结 → 进入详情 → 写一条建议。

先把这条线做完整，就已经会碰到页面、交互、数据、身份和后端几个关键环节。

二、第一版为什么要重来？因为“工具”和“社区”差得很远

我最初描述需求时，说自己想做一个帮助大家判断 Offer 的产品。

第一版生成出来，方向偏向了工具：

填写几个条件，然后得到一个结论。

它有输入，也有结果，单看页面不能说没有完成任务。但这和我想做的社区差了很远。

我要的是首页上有人发问、有人讨论，后来的人还能看到选择的后续。一个自动计算结果的页面，承载不了这些事情。

这次返工让我意识到，给 AI 的需求里，不能只有“做一个什么产品”，还得写清楚：

用户进来以后，第一眼看见什么，接着做什么，最终留下什么。

下面是根据这次经历整理的一版需求提示词：

我要开发一个微信小程序，项目名叫“Offer 体验站”。

它是职业选择社区。

用户可以匿名描述“这个 Offer 要不要接”或“A、B 两份工作怎么选”，
其他人根据自己的经历提供建议。

首页首先展示用户发布的困惑，不能把首页做成条件输入和评分结果页。

第一阶段只完成三个页面：
1. 广场：展示帖子列表；
2. 详情：展示职业信息、具体困惑和已有建议；
3. 发布：填写一条职业选择困惑。

这一阶段先使用明确标注的演示数据，不接支付，不扩展聊天系统。

业务要求：
– 不要求填写真实公司名称；
– 地点到市级，通勤用分钟表达；
– 祝福和建议分别展示；
– 不同职业使用不同的发布字段；
– 演示数据中的人数、贡献、徽章不能当成真实统计。

先列出页面结构和数据结构，确认后再逐步实现。

这里最有用的部分，是把产品形态和第一阶段范围写明白。

“社区”意味着首页应该有内容流，帖子应该有作者和状态，建议应该属于某条帖子。

“第一阶段只完成三个页面”，则给开发划出一个可以检查的范围。

如果一开始就把广场、投票、树洞、私信、入职曲线、通知全部交给 AI，最后可能得到很多页面，却很难判断哪一条流程已经真正接通。

还有三个要求，需要在开发中反复守住

第一，祝福、建议和对比不能混成一个评论区。

“恭喜你”与“这份工作的夜班安排需要再确认”，承担的是不同作用。混在一起，真正有用的信息容易被刷下去。

第二，职业分类必须影响实际字段。

分类按钮换了颜色，后面的表单却完全一样，这种实现没有解决问题。

第三，不收集真实公司名称，也要检查其他输入入口。

发布页没有“公司名称”字段，不代表自由输入的正文里就不会出现。产品约束需要进入输入提示、检测和后续处置流程。

这些都是具体的验收条件，不能只写在最初的需求里。

三、开发前需要准备什么？先把几个环境分清楚

这个项目采用的是：

微信原生小程序 + 微信云开发。

前端使用 WXML、WXSS 和 JavaScript，没有采用 uni-app、Taro 等跨端框架。

后端使用云数据库和云函数。

对新手来说，可以先这样理解：

这里容易产生一个误会：

AI 生成了项目文件，不等于云端也已经配置好了。

如果你准备从头做一个自己的小程序，可以按下面的顺序准备：

每一步都应该有一个看得见的结果。

例如，完成第五步以后，你应该知道前端连接的是哪个云环境；完成第六步以后，你应该能从云函数日志和数据库里找到一次测试操作的结果。

“前端不用装 npm 包”，不等于“整个项目没有依赖”

这个项目的前端根目录没有 package.json，也没有额外引入第三方 UI 框架。

但云函数使用了官方的 wx-server-sdk；截图自动化脚本也有独立的 Node.js 依赖。

因此，更准确的说法是：

原生小程序前端没有额外的 npm 安装步骤，云函数和开发辅助工具仍有各自的依赖。

另外，项目配置里的 3.5.5 是微信小程序的基础库版本，不是组件库版本。

这些名词看起来琐碎，但如果写错，新手很容易在错误的位置寻找问题。

四、第一轮开发，先让三页之间真正走得通

如果重新带一个新手做这个项目，我会先让他完成以下内容：

这一轮使用演示数据没有问题，前提是明确知道它属于哪一层。

例如：

• 点击卡片，进入的是不是刚才那一条？
• 切换职业后，表单字段有没有变化？
• 缺少必填项时，能不能继续发布？
• 返回广场以后，本地新增的帖子有没有出现？
• 自己和别人的帖子，底部操作是否不同？

这些问题不需要等后端完成后再检查。

每次给 AI 一个可以验收的小任务

比如，实现详情页建议弹层时，可以这样描述：

这一轮只处理详情页的“给建议”功能，不修改其他页面。

预期行为：
1. 查看别人的帖子时，底部显示“给建议”；
2. 点击后打开编辑弹层；
3. 弹层包含身份、判断、可选评分和一句建议；
4. 点击遮罩能关闭弹层；
5. 关闭后，页面恢复正常操作；
6. 查看自己的帖子时，不允许给自己提建议。

先接通弹层交互，暂时不要提交云端数据。

完成后说明：
– 修改了哪些文件；
– 点击后经过哪些方法；
– 我应该按什么步骤验收。

比起一句“把详情页做完善”，这段要求更容易检查。

AI 修改完以后，你也不需要凭整体观感判断。照着六条点一遍，就能知道这一轮有没有完成。

五、拆开“给建议”：一个按钮后面到底发生了什么？

目前的建议编辑层包含身份、判断、评分和文字输入。

本地 0.4.0 开发版：通过实际点击打开弹层，填写的是演示草稿，没有发送。

从用户视角看，操作很短：

打开弹层，写一句话，点击发送。

从代码视角看，它至少要经过几个不同阶段。

1. 打开界面

详情页根据当前帖子是否属于自己，展示不同按钮。

自己的帖子可以进入结案；别人的帖子可以打开建议编辑层。

点击“给建议”后，页面把 showComposer 改为 true，WXML 再根据这个状态显示遮罩和弹层。

这一层做成了，只能说明按钮和界面已经接通。

2. 读取输入并检查

提交方法会读取建议内容，处理前后空格，再检查长度和本地内容规则。

这些检查能改善体验，但客户端可以被绕过。需要由服务端执行的检查，不能只在前端做一次。

3. 更新本地数据

当前项目使用了先更新本地、再同步云端的方式。

提交方法中，有这样一段代码：

store.addAdvice(this.id, {
tag: this.data.tags[this.data.tagIndex],
useful: 0,
scores: scoreText,
text: r
});

这里的几个字段分别来自身份选项、评分结果和建议正文。

store.addAdvice() 会把建议加入本地帖子，保存到本地存储，并在启用云端时放入待同步队列。

4. 云函数处理写入

待同步队列通过云开发封装调用 write 云函数。

云函数再进行服务端内容检查，将建议追加到对应帖子的建议列表，并更新建议数量。

5. 其他用户读取更新

其他用户需要通过后续同步，才能读取云端保存的结果。

因此，一个完整的验收，不能停在当前手机上。

你需要检查：

另一位测试用户重新进入这条帖子后，能不能看到刚才提交的建议。

这里还有一个本地开发版的真实缺口

这次检查源码时，我发现：弹层里已经可以选择“倾向接”“倾向拒”等判断，但当前这条提交代码只把身份、评分和正文传给了 store.addAdvice()。

判断选项还没有接入这条保存链路。

这个问题属于本文检查的本地 0.4.0，不能据此判断线上 0.3.5 的情况。

它说明了一件很具体的事：

控件能够被选中，不代表选中的值已经保存。

以后让 AI 做表单，可以加上这样一条要求：

请逐项核对表单字段：
页面状态里有什么，
提交参数里有什么，
服务端接收了什么，
数据库最终保存了什么。

不要只检查控件能不能点击。

如果不做这一步，一张看起来很完整的截图，会掩盖不少数据问题。

六、最典型的一次返工：页面成功了，数据库为什么没成功？

这个项目里，最容易误导人的问题是“静默失败”。

页面没有崩溃，用户也看到了成功提示，但部分云端写入实际上没有完成。

当时发现的错误写法，可以简化成下面这样：

// 错误写法示意
await db.collection('reactions').doc(id).set({
data: {
_id: id,
kind,
refId,
value
}
});

这里已经通过 .doc(id) 指定了文档，又把 _id 放进待写入内容，触发了：

-501007：不能更新 _id 的值

修订后的写法，把文档标识和业务字段分开：

// 片段示意：省略了数据库初始化及参数处理
await db.collection('reactions').doc(id).set({
data: {
kind,
refId,
value,
at: Date.now()
}
});

官方的 Document.set 示例同样通过 .doc(…) 指定文档，并在 data 中传入业务字段。还需要注意，`set` 用于设置或替换整条记录；只更新部分字段时，应结合 update 的用途判断，不能机械地互换。微信官方文档：Document.set

这个错误影响到的，不只是某一张页面，还包括留痕、互动和处置等写入操作。

为什么前端看起来没事？

因为当前代码中，页面更新和云端成功是两件事。

它会先修改本地数据，再把操作放进同步队列。页面也会很快显示提示。

这种处理可以让操作更流畅，但如果同步失败没有清楚展示出来，用户就容易把“本地已经显示”理解成“服务器已经保存”。

因此，排查时要分别看：

这几项不能互相替代。

尤其不要看到一句“提交成功”，就跳过后面的检查。

出问题时，怎样让 AI 帮忙查？

我更建议把症状和范围一起提供：

现象：
前端显示提交成功，本地也能看到变化，
但云数据库没有出现预期记录。

已知错误：
-501007，不能更新 _id 的值。

请检查所有使用 doc(id).set() 的位置：
1. 是否把 _id 放进了 data；
2. 调用失败后，错误有没有被上层吞掉；
3. 前端成功提示是否依赖云端返回结果。

先列出问题位置和影响范围，再做最小修改。
不要顺手重构整个数据层。

错误码、涉及的方法、前后端观察结果，比“提交有问题，帮我修一下”更有用。

七、页面变暗却点不动：一次看起来像逻辑错误的样式问题

另一个很有代表性的 Bug，发生在“给建议”弹层。

点击按钮后，页面变暗了，但用户无法正常操作弹层。

排查后发现，样式文件里出现了重复的 .mask 定义。后面的规则把遮罩的 z-index 改成了 100，而建议弹层只有 11。

于是：

遮罩：100
弹层：11

遮罩位于弹层上方，把点击挡住了。

这类问题很容易让人查错方向：反复检查点击事件、提交方法，甚至重新生成页面，真正的问题却只是叠放顺序。

当前代码中，建议遮罩与弹层的层级是：

.mask {
position: fixed;
z-index: 10;
}

.sheet {
position: fixed;
z-index: 11;
}

祝福面板则使用单独的 .bless-mask 和 .bless-sheet，避免再与建议面板共用同一个遮罩样式。

这个修复不能只靠看代码确认。

要实际检查：

这次补拍建议截图时，也先通过真实按钮打开弹层，再填写演示草稿。直接把页面状态改成“显示弹层”，只能检查展示效果，无法证明入口按钮正常。

八、能在模拟器里打开，还会遇到哪些上线问题？

开发过程中，有几类问题不会直接体现在页面上，但会影响上传和运行。

1. 工具文件被一起打进小程序包

有一次上传失败，是因为项目里的工具目录没有排除，一个约 196MB 的安装包也被带进了打包范围。

这个时候，继续压缩按钮图标解决不了主要问题。

应该先检查：

最终上传的文件里，为什么会有与小程序运行无关的内容？

项目后来在 project.config.json 的打包配置里，排除了工具、文档和开发日志等目录。

最小配置示意如下：

{
"packOptions": {
"ignore": [
{
"type": "folder",
"value": "_tools"
},
{
"type": "folder",
"value": "docs"
},
{
"type": "folder",
"value": ".workbuddy"
}
]
}
}

packOptions.ignore 的作用是让符合规则的文件或目录跳过打包；规则中的路径以配置的小程序目录为根。配置后仍应检查实际打包结果。微信官方文档：项目配置文件

2. 调用了内容安全接口，却漏了云调用权限

项目还遇到过 msgSecCheck 调用不正常的问题，排查原因之一是云函数目录缺少权限声明。

调用该接口的云函数，需要相应的 config.json：

{
"permissions": {
"openapi": [
"security.msgSecCheck"
]
}
}

微信官方文档明确要求，各云函数声明自己需要调用的接口，上传云函数时会根据配置更新权限。微信官方文档：云调用

这里不能只检查文件有没有写。

部署后还要确认调用结果，并区分：

• 内容检测通过；
• 内容被判定需要拦截或进一步处理；
• 接口调用本身失败。

接口没有正常返回，不能直接理解为“内容没有问题”。

当前开发代码里仍有接口异常时降级放行的处理，这也是后续需要收紧的部分。面向公开内容的产品，更合理的处理是明确失败或进入待审核状态，并记录异常原因。

3. 演示数字混进了正式界面

早期有一处数据把 viewing 写死为 1，于是卡片会显示类似“1 人正在评”的信息，但这个数字并不来自真实行为。

默认用户资料也出现过类似问题：昵称、贡献值、徽章共用一套演示对象。

这些内容在做界面时很方便，到了正式版本里，却会被用户当成真实信息。

因此，正式使用前需要逐项清理：

• 没有真实统计来源的人数；
• 写死的贡献、采纳次数；
• 自动附送的演示徽章；
• 开发时为了填满页面而准备的示例内容。

项目后来把新用户统计归零，并按设备标识生成本地初始昵称。

不过，设备标识只适合承担本地初始化等用途，不能替代账号认证。服务端仍需通过微信身份识别操作者，再判断谁有权修改数据。

九、功能做完以后，还可能卡在资质和审核上

这个项目的发布经历，也值得提前告诉准备做小程序的人。

0.3.1 曾通过审核并发布。后来的 0.3.5 一度被驳回，当时给出的原因涉及个人主体与“社交—笔记”类目。

之后进行了申诉，目前 0.3.5 已申诉成功并正式发布。

这是一段具体项目经历，不能推导成“个人主体都可以发布同类功能”，也不能保证其他项目采用同样做法会得到相同结果。

对新手更有用的提醒是：

类目和主体条件应该在开发前了解。

不要等所有页面写好，才第一次确认自己的账号能不能提供这类服务。

可以先把产品的实际行为整理出来：

• 用户是否公开发布内容；
• 是否有评论、投票或其他互动；
• 内容由谁审核和处理；
• 是否涉及收费；
• 计划提供的服务与所选类目是否一致。

这些问题会影响产品怎么设计，也会影响后续提交什么说明。

AI 能帮助整理功能和材料，但不能替平台决定审核结果。

十、结案和“我的”页，为什么放在主流程之后？

在职业选择社区里，收到建议并不是故事的终点。

一个人最后接了哪份工作，为什么这样选，入职后又有什么变化，都能帮助后来处境相似的人。

因此，项目增加了结案入口。

本地开发版的结案表单，尚未提交。当前没有可供补拍的本人已结案记录，因此没有生成虚构复盘卡。

“我的”页则用于集中查看自己发布和参与的内容。

本地开发版的“我的”页。界面中的连接状态和计数，不能替代对具体写入结果的检查。

这些功能都值得做，但没有必要抢在最前面。

如果“别人看不到我发布的帖子”还没解决，继续增加结案卡、徽章和曲线，只会让项目变得更难排查。

比较合适的顺序是：

先能发布，再能被别人看到；先能收到建议，再记录最后的选择。

每扩展一步，都建立在上一条流程已经接通的基础上。

十一、这个项目还没有完善的地方，也应该讲清楚

目前本地项目包含 16 个页面、5 个底部 Tab，以及 login、`sync`、`write`、`moderate`、`notify`、`purge` 六个云函数。

按本次检查范围，JS、WXSS 和 WXML 合计约 1.6 万行。

不过，这些数量无法说明项目是否可靠。

这次检查已经能看到几项需要继续完善的工作：

第一，补齐表单字段的保存链路。

例如前面提到的判断选项，不能只停在页面状态里。

第二，把本地成功和云端成功分开表达。

当前待同步队列会重试网络类失败，但达到重试次数后会移除操作；服务端明确拒绝时也会移除待同步项。本地展示还需要与这些结果对应起来。

更清楚的状态应该是“正在提交”“已保存”“未通过检查”或“提交失败”，并给用户提供可以理解的处理方式。

第三，完善异常和审核状态。

服务端检查失败、接口调用失败和网络失败，需要分别处理。

这次截图也没有执行发送建议或确认结案，所以它验证的是入口、页面和草稿展示，不能冒充一次完整的线上写入验收。

我希望这篇复盘呈现的是一个确实在开发、发布和继续修改的项目，而不是把页面截图包装成所有功能都已经验证完成。

十二、第一次用 AI 做项目，可以照这个顺序完成一个小版本

如果你现在准备打开 WorkBuddy，不必一开始就复刻「Offer 体验站」的全部功能。

先完成下面六步。

第一步：写清一个人要做的一件事

比如：

用户发布一个职业选择困惑，另一个用户可以看到，并给出一条建议。

这句话要能对应到实际操作。

“打造一个有温度的职业平台”可以成为愿景，但不足以直接指导开发。

第二步：先做三页和一份演示数据

完成广场、详情、发布。

这一轮只检查页面和导航，不把演示数据显示成功当成后端已经完成。

第三步：接入自己的云环境

配置环境，部署云函数，确认调用日志。

先让一条测试记录进入数据库，再扩大写入范围。

第四步：用两个测试账号检查主流程

账号 A 发布，账号 B 查看并给建议，再由 A 读取结果。

使用两个不同的测试账号，才能检查跨用户共享和权限边界。仅仅换一台设备，不一定代表换了用户。

这一步建议使用测试环境和明确的测试内容。

第五步：故意制造几种失败

至少试一次：

• 网络不可用；
• 必填内容为空；
• 内容检查拒绝；
• 查看或操作不属于自己的记录；
• 重新进入页面后读取结果。

你需要知道失败时用户看见什么，数据停在哪里，以及能不能重试。

第六步：再处理上传、审核和下一轮功能

检查打包范围、配置、主体与类目，再准备体验和提交。

每完成一个可用节点，就做一次版本提交或备份。下一轮即使被 AI 改坏，也能回到已知可用的状态。

给 AI 的任务，最好有一个明确的结束条件

我现在更建议采用下面这个结构：

目标：
这次只完成什么功能。

现场：
当前看到什么现象，有什么日志或错误码。

范围：
允许检查和修改哪些页面、方法、配置。

验收：
我要经过哪些操作，看到什么结果，才算完成。

边界：
哪些文件不能动，哪些操作不能真实提交。

比如，不要只说：

帮我把社区完善一下。

可以改成：

修复详情页建议弹层无法操作的问题。先检查点击事件和遮罩层级，只修改相关页面。完成后验证打开、输入、关闭和再次打开，不发送建议，不修改数据库。

任务越具体，AI 越容易沿着已有项目继续工作，你也越容易发现它有没有改偏。

如果它拿不到开发者工具或云函数日志，就把错误码、相关日志和预期结果提供给它。继续生成代码，不能替代缺失的现场信息。

做完「Offer 体验站」，我对 AI 开发最深的体会，来自那些不起眼的检查：按钮点下去有没有反应，选中的字段有没有传出去，云端有没有保存，另一个人能不能读到。

如果你今天也准备开始一个项目，先给自己定一个小目标：

让一位测试用户提交的内容，在另一位测试用户重新进入页面后，仍然能正确显示。

把这一步做扎实，再去增加投票、曲线、徽章和更多页面。你会更清楚自己已经完成了什么，也更容易知道下一次该让 AI 帮你做什么。

十三、写在最后

回头看「Offer 体验站」的开发，最初的想法其实很简单：一个人拿不定主意的时候，能找到有相似经历的人，听一句具体的建议。后面增加的职业分类、Offer 对比、结案和入职记录，都是围绕这件事慢慢展开的。

WorkBuddy 帮我把不少想法变成了页面和代码，也让我更早遇到了那些只有动手才会碰到的问题。第一版把社区做成了判断工具，需要重新说明产品方向；页面提示成功，数据却没有入库，需要顺着调用链查日志；弹层点不动，需要回到样式里检查遮罩。这些问题最终都落到了一个个可以定位、可以修改的细节上。

经过这次开发，我觉得新手最值得练习的，是把模糊的要求说清楚，把眼前的异常描述准确，再亲手检查修改后的结果。你不需要一开始就读懂整个项目，但应该逐渐知道：这个按钮调用了什么方法，这份数据保存在哪里，出了问题该去哪里找线索。每弄明白一处，下一次和 AI 协作时，就能少一些猜测。

这也是我愿意把返工过程写出来的原因。只展示成品，很容易让人以为开发是一条顺畅的直线。实际做起来，需求会变，代码会出错，已经完成的功能也可能需要重新调整。遇到这些情况，可以先缩小问题范围，保住已经能用的部分，再一步步往前推进。

「Offer 体验站」还有需要继续完善的地方。这篇文章记录的是它已经走过的一段路，也希望给准备动手的人一个具体参照。如果你也有一个想做很久的小项目，可以先挑出其中最有用的一件事，借助 AI 把它实现，再请一个真实的人试着用完。

当对方能顺利完成操作，并告诉你哪里方便、哪里别扭时，下一步该做什么，往往就清楚了。

在这篇博客我想说，其实这个小程序就是一个中午我在图书馆突发奇想，然后花了3h就完成的一个半成品吧，现在还不是很成熟，但是我想说的是，现在开发的门槛确实被降低了很多，大家要是有自己的想法肯定要去动手比较好，看再多的教程、学再多的知识，只要不动手，那就没有意义，app的开发我觉得和这个小程序其实也是有相似的地方的，游戏的开发则会更加难一点，他涉及到了美术资源、动画等等，有机会我也会写博客，给大家带来一个教程，教大家如何快速上手