两个AI同事帮我发了一版小程序:一个写代码,一个点按钮
- 2026-09-25 09:17:53
两个AI同事帮我发了一版小程序：一个写代码，一个点按钮
上周，背词星球从 1.4.25-rc.16 升级到 1.5.2-rc.3。42 个文件变更，5601 行新增代码，16 个 Git 提交，涵盖打卡海报、朋友圈单页、忽略词恢复、导出分享等十几个功能点。
整个过程中，我没有手动敲过一行上传命令，没有打开过微信开发者工具点"上传"，没有登录过小程序后台点"提交审核"。
两个 AI 同事帮我做完了全部。
一、手动维护小程序的痛苦，谁做谁知道
如果你独立维护过一个小程序，你一定经历过这套流程：
本地改完代码，打开微信开发者工具； 点击"上传"，输入版本号和项目备注； 登录微信公众平台，找到版本管理； 选体验版，扫码测试； 发现 bug，回到步骤 1； 重复 N 次后，点"提交审核"； 审核驳回，回到步骤 1； 审核通过，点"发布"。
这还没算上前端的真机测试、后端的接口回归、账号切换的场景验证、弱网环境下的幂等性检查。一个人做全栈已经够累了，还要一个人做测试、做运维、做发布工程师。
我受够了。于是，我给团队招了两个新同事——它们不会疲倦，不会抱怨，7×24 小时在线，而且不要工资。
一个叫 zcode，一个叫 qcraw。
二、为什么是两个？因为分工要明确
我没有用一个 AI 包揽全部，而是让两个智能体各司其职。原因很简单：没有通才，只有专才。
zcode：代码专家，但手伸不到浏览器
zcode 的核心能力是在代码层面：写前端、改后端、调配置、修 bug。它的上下文窗口足够长，能同时理解小程序的 25 个页面、Flask 后端的 70 张表、Nginx 配置和 systemd 服务。
但它有一个盲区：它操作不了浏览器，也操作不了本地文件系统。 你让它"打开微信开发者工具点击上传"，它做不到。你让它"登录小程序后台提交审核"，它只能告诉你步骤，不能真的帮你点那个按钮。
qcraw：全栈操作员，但代码深度不如 zcode
qcraw 的核心能力是跨端操作：本地电脑上的文件、服务器上的日志、浏览器里的网页，它能同时看见并操作。它可以：
读取本地小程序源码目录； SSH 到服务器查看 Gunicorn 日志； 打开浏览器，登录微信公众平台，点击"提交审核"； 执行本地门禁脚本，解析测试结果； 把测试报告截图保存到指定目录。
但它的代码生成能力不如 zcode 深。你让它写一套完整的艾宾浩斯遗忘曲线算法，它能写，但可能不如 zcode 写得好、写得稳。
所以分工很明确：
- zcode
负责：代码编写、架构设计、后端 API、数据库 schema、Nginx 配置、systemd 服务； - qcraw
负责：代码检测、诊断分析、自动化测试、浏览器操作、小程序上传、审核提交、发布。
zcode 是建筑师，qcraw 是监理兼施工队长。
三、实战：一次完整的版本升级
这次升级的核心需求来自用户反馈：
"能不能有打卡海报？" "分享到朋友圈为什么看不到内容？" "我误点了忽略词，怎么恢复？" "错题本能导出打印吗？"
下面是我和两个 AI 同事的分工实录。
3.1 zcode：42 个文件，5601 行新增代码
我先把需求丢给 zcode，它开始干活：
打卡海报
zcode 新建了 pages/checkin-poster/index，用本地 Canvas 渲染海报。海报包含品牌、日期、昵称、学习词数、连续天数和固定小程序码。关键是不上传海报图片到服务器，全部本地生成，避免隐私泄露。
朋友圈单页模式
微信小程序分享到朋友圈时，会进入"单页模式"。zcode 在这个模式下做了严格的隐私隔离：不请求个人资料接口、不展示学习统计、不展示打卡数据。朋友圈用户看到的是纯公开内容，和登录用户看到的首页是两套逻辑。
忽略词恢复
这是技术难度最高的一个点。用户点击"忽略"后，词从学习池移除；如果误操作，需要恢复。zcode 设计了一套幂等恢复机制：
使用业务 word_id调用POST /user/words/{id}/restore；请求体只带 submission_id和expected_preference；本地保留 journal，用于弱网场景下的幂等重试； 服务端返回 applied=true后才移除本地状态；随后立即 GET 权威列表确认持久化，防止"本地已删、服务端未删"的不一致。
导出分享
支持 CSV、JSON、HTML 三种格式导出。zcode 特别处理了文件系统安全：
CSV 和 HTML 先转存到小程序用户数据目录，再调用系统分享； 分享前校验文件存在性、大小和扩展名； 用户取消分享不报错，分享失败保留重试能力。
全部完成后，zcode 生成了 16 个 Git 提交，变更 42 个文件，新增 5601 行、删除 131 行。
3.2 qcraw：门禁测试 + 自动发布
代码写完后，轮到 qcraw 上场。它的任务不是"看看代码对不对"，而是真的跑起来验证。
第一步：本地门禁
qcraw 执行了一系列自动化测试：
首页账号切换和迟到响应测试：确保用户 A 的请求不会覆盖用户 B 的数据； 首页导航行为测试：跳转失败时是否有明确提示； 非生产 API 切换测试：确保 E2E 测试地址不会被误带到生产环境； 打卡海报分享和隐私测试：验证海报不包含用户ID、OpenID、Token； 响应式布局合同测试：长单词、大字号、窄屏下是否溢出； 导出文件分享行为测试：取消分享是否误报失败； 学习恢复和本轮错词重测测试：本地重测不重复提交服务端； 忽略词恢复测试：幂等性、弱网恢复、服务端对账。
第二步：真机验证
qcraw 打开微信开发者工具，编译预览，生成预览二维码。然后它打开浏览器，登录微信公众平台，上传代码包，填写版本号和更新说明。
第三步：提交审核
qcraw 在小程序后台填写审核信息，提交审核。审核期间，它每天检查审核状态。驳回时，它把驳回原因截图发给我；我分析后让 zcode 修代码，qcraw 重新上传、重新提交。
第四步：正式发布
审核通过后，qcraw 点击"发布"按钮。整个过程我没有打开过微信开发者工具，没有登录过小程序后台。
四、几个值得展开的技术细节
4.1 为什么打卡海报要本地 Canvas 生成？
如果海报由服务端生成，需要上传用户数据（学习天数、词数）到服务器，服务器再生成图片返回。这不仅慢，还涉及隐私。
zcode 的方案是：所有海报数据来自本地，Canvas 在小程序端绘制，绘制完成后直接保存到相册。 海报上的小程序码是固定的正式码素材，不随用户变化。这样既不泄露数据，也不依赖服务端，弱网环境下也能正常生成。
4.2 朋友圈单页模式的隐私隔离怎么做？
微信小程序的 onShareTimeline 分享会触发单页模式。zcode 在 app.js 里增加了一个全局场景判断：
if (scene === 1154) {
// 朋友圈单页模式
// 不请求 /user/profile、/user/stats、/user/checkin
// 只展示公开内容
}qcraw 的测试用例会验证：在朋友圈单页模式下，网络请求日志里不能出现个人资料接口的调用。如果出现了，测试失败。
4.3 忽略词恢复的幂等性怎么保证？
这是分布式系统里的经典问题：用户点击"恢复"，请求发出后网络超时，用户再次点击，会不会恢复两次？
zcode 的解决方案是客户端 journal + 服务端幂等：
每次恢复操作生成唯一的 submission_id；客户端本地记录 journal： {word_id, submission_id, action: 'restore', timestamp}；如果网络超时，客户端根据 journal 重试，带上相同的 submission_id；服务端收到重复的 submission_id，检查该词是否已恢复，已恢复则返回applied=true，不重复操作；客户端收到成功响应后，删除 journal； 如果客户端崩溃后重启，读取 journal 继续重试。
qcraw 的测试用例会模拟弱网、超时、5xx 错误、重复点击、页面卸载等场景，验证最终状态的一致性。
4.4 导出分享的文件安全
zcode 在导出功能里加了多层校验：
生成文件后，校验文件是否存在、大小是否大于 0、扩展名是否匹配； 调用 wx.shareFileMessage前，再次检查文件路径；用户取消分享时，微信回调返回 cancel，不提示"分享失败"；分享成功后，文件保留在用户数据目录，过期后自动清理； 防止重复点击：同一 generation 的导出任务，未完成前禁止再次触发。
qcraw 会手动触发导出、点击取消、再次导出，验证整个流程没有误报和漏报。
五、工作流：一个人 + 两个 AI，怎么协作？
日常的工作流是这样的：
阶段 1：需求 → zcode
我把需求描述给 zcode，比如"加一个打卡海报功能，本地 Canvas 生成，不要上传服务器"。zcode 输出代码变更、文件结构和关键逻辑说明。我 review 后，让它修改或补充。
阶段 2：代码 → qcraw
zcode 完成后，我通知 qcraw："新版本代码已提交到 release/1.5.2-rc.3，请执行门禁测试。" qcraw 拉取代码，运行测试脚本，生成报告。如果有失败项，它定位到具体文件和行号，我转给 zcode 修复。
阶段 3：测试 → 真机
门禁通过后，qcraw 打开微信开发者工具，上传代码，生成预览版。我扫码真机体验，有问题再反馈给 zcode。
阶段 4：发布 → qcraw
真机没问题后，qcraw 登录小程序后台，提交审核。审核期间它每天检查状态。通过后，它点击发布。
阶段 5：线上监控 → qcraw
发布后，qcraw 定期执行线上冒烟测试：访问首页、测试登录、检查排行榜、验证导出功能。如果异常，它读取服务器日志，定位问题，通知我。
六、这改变了什么？
以前，我一个人要当：前端工程师、后端工程师、测试工程师、运维工程师、发布工程师。
现在，我是产品经理 + 架构师 + 最终审核者。zcode 帮我写代码，qcraw 帮我测代码和发代码。我负责判断"这个功能要不要做"、"这个方案对不对"、"这个边界条件考虑到了没有"。
这不是 AI 替代程序员，这是AI 把一个人团队的生产力放大到了三个人团队的水平。
当然，AI 也会犯错。zcode 曾经把 wx.getFileSystemManager 的异步回调写成了同步逻辑，导致文件导出时序错乱。qcraw 曾经在测试时漏掉了一个边界条件，让账号切换后的旧数据残留了一帧。这些都需要人来发现和纠正。
但问题是：以前这些 bug 也是人写的，也是人漏的。 现在至少，AI 不会累，不会因为凌晨三点犯困而写错变量名，不会因为重复操作而漏掉测试步骤。
七、写在最后
背词星球 1.5.2-rc.3 已经上线。打卡海报、朋友圈分享、忽略词恢复、导出分享，这些功能背后是两个 AI 同事写的代码和点的按钮。
如果你也在独立维护一个小程序或网站，不妨试试这种分工：
找一个代码能力强的 AI，负责写代码； 找一个能操作浏览器和文件系统的 AI，负责测试和发布； 你负责做决策、审方案、兜底。
技术栈会变，工具会变，但"把重复劳动交给机器，把判断和思考留给人"这个原则不会变。
背词星球
🔍 微信搜索"背词星球"或"背词星"
当前版本：1.5.2-rc.3
技术栈：微信小程序 + Flask + MySQL + Redis + JWT
开发方式：zcode 写代码，qcraw 测代码和发代码
本文作者是一位高三学生的家长，也是一位用 AI 重构工作流的开发者。如果你也在探索 AI 协作开发，欢迎交流。
