零代码独立开发：纯 AI 生成的微信小程序正式上线

近两周我一直在打磨一款自己独立开发的微信小程序，前几篇文章也提到过。它在微信平台上线已经一段时间了，但因为还存在一些交互上的瑕疵，我没急着单独写文章。又用了一段时间后，体验问题陆陆续续修掉了，主要功能也走顺了，正好可以完整聊聊这次开发的全过程。

先把最关键的一点放在前面：这款小程序的代码 100% 由 AI 生成，我自己没有写过一行代码。

模型与思考预算：Claude Opus 4.7 + Max

全程使用的是 Claude Opus 4.7，思考程度（thinking）拉到了 max。

让我比较意外的是，整个开发过程里，没有出现过一次因为 AI 改动导致小程序直接报错、起不来的情况。换成自己手写的时候，经常因为漏一个括号、多一个 HTML 标签让整个项目卡住，AI 写的时候，这种低级故障几乎绝迹。

UI：Claude Design 出初版，AI 自动延续设计规范

UI 的初版完全交给了 Claude Design。它每周的额度刚好够搭一套初版骨架、跑出一份设计规范，之后的页面 AI 会自己照着延续。

实际效果远超预期：在后续做需求的时候，Claude 几乎严格遵守了已有规范，整体 UI 在颜色、圆角、间距、字号上保持得相当一致，不会出现页面之间风格割裂的问题。

项目记忆：用 skills 维护“AI 的认知”

我专门用 skills 写了一份项目记忆文件，把已经实现的功能完整记录成 markdown。然后在约束文件里要求：每次新增或修改需求，都必须同步更新这个 skill。

目的是让 AI 始终明白项目里有什么。这里有一条经验值得划重点：

这份 skill 在能完整描述项目的前提下，越短越好。内容越多，每次对话消耗的 token 就越多，长期成本不容忽视。

需求拆分：worktree 并行让 AI 同时干 6 件事

有了项目记忆文件，可以让 AI 反过来帮你想需求清单，自己只负责挑选合适的需求去执行。

最初的节奏大概是 5 小时让 AI 完成 6 个需求，全部用 git worktree 并行推进。这样做有两个好处：

• 多个 AI 不会同时改到同一个文件，避免冲突
• 完成后让 AI 自己 rebase 到主分支，git 历史依然干净

后端：Golang + PostgreSQL

后端我让 AI 用 Golang 搭建。这个选择主要看中三点：天然的高并发、占用资源少、运行稳定性高，对独立开发者尤其友好，一台轻量服务器就能撑住相当规模的请求。

数据库选了 PostgreSQL。部署环节也全部交给 AI：让它直接通过 SSH 连进服务器，从环境准备到服务起停一条龙搞定。

需要提醒一句：小程序要接入自建后端，域名必须先完成 ICP 备案，否则微信不会放行任何网络请求。这是一个绕不开的硬门槛。

上线之后才是真正的开始

把功能、UI、后端都打通之后，会撞上一件挺尴尬的事，我自己都说不全小程序里到底有哪些功能。

这时候的解法是切换身份：放下开发者视角，当一个普通用户去用自己的产品。在这个过程中，体验不好的地方会自己浮现，自己缺什么功能也会变得清晰。再把这些反馈丢回去给 AI 实现就好。

UX 打磨：让 AI 自己去微信开发者工具里“试用”

走到这一步还会遇到一类问题：功能齐了，界面有了，UI 也统一了，但就是哪里别扭，这就是典型的 UX 问题。

我的做法是借助 computer use，让 AI 直接操作微信开发者工具，自己体验小程序、自己发现交互问题，再自己修。一周下来，交互改了相当多版本，到现在我觉得已经能放心交给真实用户体验了。

扫码即可直接试用：

下一站：一款“为浏览网页而生”的背单词工具

最后聊聊接下来在做的事。

因为我目前把“学好英语”当成第一优先级，所以正在开发一款学习英语的产品。这次不再局限于小程序，而是覆盖浏览器插件、网页端、小程序三端。

为什么市面上已经有那么多背单词 App，我还要再做一款？因为我用下来发现，大多数产品都把重心压在了 App 端，浏览器插件和网页端几乎被忽视，而这两个场景恰恰是我每天接触英文最高频的地方。

我目前设计的核心闭环是：

1. 浏览网页时遇到不认识的单词
2. 浏览器扩展接入 AI，根据当前语境给出翻译
3. 觉得有价值的单词一键收藏
4. 网页端 / 小程序自动同步这些单词，集中复习

主要功能侧重于把“日常浏览中沉淀生词”这件事做顺，这是我自己的刚需，也是我用过的背单词软件普遍不支持的能力。所以与其等谁来做，不如自己做一套出来。