Codex 实战｜不会写代码，也能从 0 做出一个微信小程序

最近越来越多不会写代码的人，开始用 Codex 做自己的小产品。

这次我不讲功能，也不讲一堆“AI 编程到底有多强”。直接拿一个微信小程序走完整流程：

先把页面画清楚，再交给 Codex 写成微信原生小程序，最后放进微信开发者工具里运行、排错和预览。

这款阅读打卡小程序「一页」。它没有复杂后端，也没有支付、社区这些重功能，只有书架、阅读记录和统计几个核心页面。

这个案例真正值得抄的，不是小程序本身，而是这条开发链：想法 → Figma 原型 → Codex 写代码 → 微信开发者工具 → 调试 → 真机预览。

01｜先把页面画出来，再让 Codex 写代码

第一次用 AI 做产品，最容易犯的错就是一句“帮我做个微信小程序”直接开干。更稳的方式，是先把产品长什么样定下来。

可以先让 Codex 根据需求生成三页设计，再输出 SVG，导进 Figma 继续改；文字、按钮、颜色和布局确认后，再进入开发。

Figma 在这里不是为了把流程搞专业，而是为了减少返工。页面都没想清楚，AI 写得越快，后面推倒重来的代码越多。

第一次做小程序，我建议你先只写清四件事：

🎯给谁用；

🎯有哪几个页面；

🎯每页做什么；

🎯页面之间怎么跳；

比如「一页」很简单：书架负责看当前阅读状态，记录页负责填书名、阅读时长和感想，统计页负责看累计数据。设计稿能把这些关系说清楚，就够用了。

02｜设计确认后，再告诉 Codex：我要的是“微信原生小程序”

设计定下来以后，才进入真正开发。这里一个很容易踩的坑是，只给图片，然后说“照着做”。Codex 可能理解成普通网页，也可能自己补一堆你根本没要的功能。

所以开发任务里要把边界说死：

✅️目标是微信原生小程序；
✅️页面按已经确认的设计稿实现；
✅️使用 WXML、WXSS、JavaScript 和 JSON；
✅️第一版不做后端、不做登录、不做支付，数据先存在本地；
✅️没有明确需求的功能不要自己增加。

然后把设计图、页面说明和交互关系一起交给它，让它先复述准备改哪些文件、每个页面怎么实现，再开始写。

完成以后，把项目导入微信开发者工具。能编译只是第一关，真正要检查的是页面有没有跑偏、按钮能不能跳、记录能不能保存、刷新以后数据还在不在。

原案例也是在开发者工具里不断看效果，把问题再交回 Codex 修改，直到模拟器可以正常跑起来。之后再用自己的小程序账号做手机预览、上传和审核。到这里，原帖的主线基本就跑完了。

03｜“零代码”真正省掉的是写代码，不是做判断

很多人看到 AI 能写小程序，会误以为以后做产品只需要一句 Prompt。其实完全相反。

当“写代码”越来越便宜，真正拉开差距的是三件事：你能不能把需求说清楚，能不能发现结果哪里不对，能不能给出明确的验收标准。

不会代码并不可怕，你可以看不懂一大段 WXML，但必须知道：

• 点这个按钮以后应该发生什么；

• 保存一条记录之后在哪里能看到；

• 没有数据的时候页面应该显示什么；

所以我更喜欢把 Codex 当一个执行很快的开发同事，而不是许愿池。你负责决定“做什么”和“什么叫做对”，它负责尽量把中间的代码实现掉。

04｜第一次做，产品一定要砍到足够小

我非常不建议新手第一天就做商城、社区、聊天、会员、支付。AI 会让你产生一种错觉：既然代码不用我写，那多加几个功能也没成本。

但每增加一个功能，实际上都会增加新的页面、数据状态、异常情况和测试路径。最后你不是输在不会写代码，而是根本不知道哪里出了问题。

最适合第一次练手的，是打卡、待办、记账、读书记录、习惯追踪这类小工具。两三个页面，一个核心动作，本地数据就能跑。先完整做出一个“小但能用”的东西，再谈第二版。

05｜我会固定用这三类 Prompt

第一类不是让它写代码，而是先帮我拆需求：

我要做一个微信小程序。先不要写代码。

请把我的想法整理成：

目标用户、核心场景、页面清单、每页功能、页面跳转、第一版明确不做的功能。

如果有任何不清楚的地方，先问我，不要自行补全。”

第二类才是开发：

请根据已经确认的需求和设计稿，实现微信原生小程序。

第一版使用本地存储，不增加登录、支付和后端。

开始前先告诉我准备创建或修改哪些文件；

完成后列出我在微信开发者工具里必须检查的 5 个验收项。

第三类专门用来修 Bug：

✅️我做了什么：____
✅️实际发生了什么：____
✅️我期望看到什么：____
✅️报错信息或截图：____

请先判断最可能的原因，只改与这个问题有关的代码，不要顺手重构其他部分。

修改后告诉我怎么验证已经修好。

这三类 Prompt 比“帮我做个小程序”值钱得多，因为它把需求、执行和排错拆开了。

06｜不会看代码，就用“看得见的结果”验收

普通人没有必要为了用 Codex，先去学半年编程。但至少要会做黑盒验收，也就是不看里面怎么写，只看外面是否符合预期。

我会固定检查四件事：

• 页面有没有明显跑偏、文字有没有溢出；

• 所有按钮和页面跳转能不能走通；

• 新增、修改、删除、刷新以后数据是不是符合预期；

• 什么都不填、重复点击、输入奇怪内容时，会不会直接崩掉;

每发现一个问题，就单独交给 Codex 修。不要一次截图十个 Bug，让它“全部优化一下”。问题越具体，修改越容易控制。

07｜给第一次做小程序的人一条最短路线

如果今天第一次尝试，我会把任务压到 60 分钟左右。

✅️前 10 分钟，只确定一个核心场景和最多三个页面；

✅接着让 Codex 生成页面方案；

✅在 Figma 或其他设计工具里把布局定下来；

然后只实现最核心的一条路径，比如“添加一次阅读记录 → 保存 → 回首页看到结果”。

先别管统计图、动画、登录和云端同步，把项目丢进微信开发者工具，完整点一遍；出现问题就按“操作—现象—期望”反馈给 Codex，核心路径跑通以后，再决定值不值得继续做第二版。

这才是我理解的 Vibe Coding：不是完全不用懂产品，也不是让 AI 一次性把整个应用变出来。

而是把一个模糊想法逐步压成设计稿、页面、交互和验收标准，再让 AI 把其中最费时间的代码工作吃掉。

08｜什么时候该停止让 AI 继续改？

还有一个新手很容易忽略的问题：Codex 改得越快，你越容易陷入“再优化一点”的循环。

按钮换个颜色、卡片再圆一点、统计页再多一张图，半小时很快变成三个小时，但这些修改不一定让产品更有价值。

我会给第一版设置一个很硬的停止条件：

核心路径能完整走通、没有阻断使用的 Bug、数据可以正确保存，就先停。

把它放到真机里自己用几次，最好再给一两个真实用户点一遍。

只有真实使用暴露出来的问题，才值得进入第二版。

升级第二版之前，我只问三个问题：

• 哪个步骤最容易卡住？

• 哪个功能真的有人反复用？

• 有没有一个需求只是我自己觉得很酷？

前两个优先修，最后一个先删掉。AI 把开发速度提上来以后，克制反而比“还能加什么”更重要。以前一个不会代码的人，有想法以后第一反应可能是“我要不要找个程序员”。

现在可以先问另一个问题：这个想法，能不能先花一个小时，自己做出一个能点、能用、能验证的版本？

当第一版的成本被压到这么低，真正稀缺的就不再只是写代码的人，而是能把问题想清楚、把需求说清楚，并且知道什么结果值得继续做下去的人。