做一个微信小程序：从需求、原型、开发到上线，一篇讲清 Vibe Coding
最近总有人问我：“你一直说 AI 能帮普通人做产品，但我不会写完整的软件，也没有团队，到底能做什么？”
以前我会回答：不用等到什么都会再开始。
说多了以后，我自己都觉得有点像鸡汤。
所以这次不聊抽象的“AI 让人人成为开发者”，直接看一个我真正做下来的项目。
我会 Python，也懂一些算法，但此前没有完整开发过微信小程序，更没有独立走完需求、原型、工程开发、调试、测试到发布这一整套流程。后来主要借助 ChatGPT 和 Codex，再配合微信开发者工具、CodeBuddy 和自动化测试工具，把一个生活里的小需求一路推进成了「拼豆图纸生成君」。
它不是那种“上传一张图片，十分钟得到完美结果”的演示页面。真做下去以后，会碰到真实色卡、图像结构、图纸编辑、材料统计、逐色制作、导出、权限、性能和真机兼容。
也正因为麻烦，它反而很适合拿来讲清楚一件事：
Vibe Coding 真正改变的，不只是写代码的速度，而是一个人把想法推进成产品的方式。
01从一个生活问题开始，而不是从“我要做个 App”开始
这个项目的起点很小。
女朋友喜欢做拼豆，平时会在网上找图纸。我跟着看了一段时间以后发现，很多图纸“看起来能用”，真正照着做却挺费劲：
屏幕上颜色很丰富，实际买材料时却发现用了大量接近色； 图里的颜色和现实品牌色卡不是一回事； 没有坐标和定位线，做到中间很容易数错； 没有材料数量，几千个格子还得自己统计； 生成出来以后没有方便的编辑、检查和制作流程。
一张 48×48 的图纸就有 2304 个格子。这里面如果有几百格被错误地合并、遗漏或者表达得不清楚，结果很容易从“能做”变成“只能看看”。
一开始我也把它理解成一个图片像素化问题：缩小图片，再给每个格子找一个最接近的颜色。
真正往下做才发现，至少有三个问题纠缠在一起。
颜色：屏幕上的 RGB / HEX，不等于用户真的可以买到的拼豆色号。 结构：眼睛里的一颗高光和背景里的一颗噪点，看起来都可能只是“一颗豆”，但它们的重要性完全不一样。 施工：最终目标不是一张好看的预览图，而是人真的能从第一颗做到最后一颗。
所以产品目标后来被重新定义成：
在有限的真实色卡里，重建一张人可以照着完成的拼豆施工图。
这个定义一变，产品范围也跟着变。
裁切、色卡、编辑、检查、材料统计、逐色制作和导出，不再是“有空再加”的功能，而是完成任务所需要的链路。
02原型不是为了做漂亮，而是为了早点暴露问题
问题定义清楚后，我没有先花很长时间把所有页面画成最终稿。
更实用的做法是让 ChatGPT 先把页面结构、用户流程和视觉方向快速做出来，再拿着一个具体东西反复挑问题。
第一版最短流程大致是：
选择图片
↓
裁切构图
↓
选择拼豆品牌和色卡
↓
设置图纸尺寸
↓
生成图纸
↓
编辑和检查
↓
查看材料
↓
导出施工图
到了原型阶段，讨论也会从“这个页面好不好看”变成更具体的问题：
首页能不能一眼看懂是干什么的？ 用户选完图片以后，下一步够不够明确？ 编辑页的画布有没有被工具栏挤得太小？ 浅色被高亮以后，反而看不清怎么办？ 图标缩到真实手机尺寸以后还能不能认？
逐色制作页面就是个很典型的例子。
当时的逻辑是“当前颜色高亮，其他颜色变暗”。但白色、米色、浅黄色本身就很接近背景，高亮以后反而更难看清。
把实际截图给 ChatGPT 后，我们就可以只讨论这一件事：是降低其他颜色的饱和度，还是给目标格加描边，或者给浅色单独做对比补偿。
最后采用的是描边和局部对比度调整。
这类过程让我越来越确定：AI 原型最大的价值，不是“一次设计完成”，而是把一次试错的成本降得很低。
03主体开发工具一直是 ChatGPT 和 Agent
这里顺便把工具关系说清楚。
微信开发者工具是小程序真正运行、调试、真机预览、上传和发布的地方。CodeBuddy 我也会用，主要适合看局部代码、改一个默认值、调一个明确的小交互。
但整个项目的主体开发中枢，一直是 ChatGPT 和 Codex。
ChatGPT 贯穿需求分析、技术调研、方案设计、页面结构、代码实现、代码审查、Bug 根因分析和测试设计；复杂长任务再交给 Agent 连续推进：先读现有代码，定位根因，明确改动边界，修改以后做专项测试和回归。
这和“AI 编辑器里一句话生成整个项目”其实不是同一套玩法。
工具放回整条链里，分工会更清楚：
04真正进入开发后，问题很快就不只是“写代码”
图片转拼豆图纸的核心算法，就是一个很典型的例子。
最简单的办法，是每个格子取平均色，再从色卡里找一个最接近的颜色。
这种方法很容易写，但效果也很容易出问题：重要的小细节会被吞掉，背景里没有价值的碎色又可能被保留下来。
颜色接近，只能说明“它们有可能合并”。
到底该不该合并，还得看这个位置是什么：
大面积平坦区域，可以更积极地整理近似色； 硬边缘两侧，要尽量保留分离； 稳定渐变不能粗暴切断； 一格宽的连续细线和关键高光，需要提高保护权重； 背景里的随机近似色，更适合进入清理候选。
这里会涉及色彩空间、感知色差、候选色筛选、连通区域分析和空间优化。
但真正困难的地方，不是“ChatGPT 能不能告诉我这些名词”，而是要让这些判断进入代码、测试样本和诊断指标。
这也是我对 Vibe Coding 一个很深的体会：
AI 能很快给你一个实现，但工程质量来自一轮轮“结果不对—定位原因—修改—回归”的闭环。
05我后来最常做的，不是让 AI “继续”，而是让它先证明自己改对了
项目做复杂以后，我越来越少直接说：
“继续优化。”
更多会写成：
先检查现有代码，不要先修改。
请说明：
1. 当前真实调用链是什么；
2. 问题最可能出现在哪一层；
3. 准备改哪些文件；
4. 哪些原有行为不能破坏。
修改后：
- 跑专项测试；
- 跑前序回归；
- 检查有没有引入新问题。
修 Bug 也是一样。
比如一个经典的异步问题：
操作步骤：
1. 选择一张图片；
2. 设置 64×64 网格；
3. 点击生成；
4. 生成过程中重新修改尺寸；
5. 等待两个任务都返回。
当前现象：
旧任务结果覆盖了新任务。
正确结果：
页面只接受最后一次生成请求的结果。
请先检查任务身份、版本号和异步回调，
定位根因后再修改。
这种描述比“这里坏了，帮我修”有效得多。
真正需要训练的，也不是背多少 JavaScript API，而是：
能不能把需求说清楚； 能不能判断结果对不对； 能不能把“不对”变成可复现的问题； 能不能给每次修改定义验收线。
06从“能运行”到“真能交付”，中间全是工程细节
这个项目里最磨人的问题，很多并不是算法本身。
比如生成逻辑放进微信 Worker 后，普通 Node.js 的模块加载方式不能直接照搬，依赖需要重新打包。Worker 和页面之间传数据时，一些 TypedArray、Map 或类实例也不能原样扔回页面。
异步任务也会制造麻烦。用户重新修改参数并生成，旧任务可能比新任务更晚返回。如果没有任务身份和版本控制，页面就可能被旧结果覆盖。
Canvas 更典型。
有一版编辑器在开发者工具里看着完全正常，真机一滚动，视觉位置和触摸坐标就发生了偏移。用户明明点这一格，实际修改的是另一格。
这种问题，光看静态代码很难发现。
此外还有一个需要特别注意的问题，就是鸿蒙 OS 真机测试，虽然小程序对鸿蒙做了一定的适配，但还是有部分功能需要你专项优化。
发布前还得继续检查：
相册权限被拒绝后，重新授权能不能恢复； 自定义导航栏会不会挡住弹窗； 不同手机安全区会不会压住底部按钮； 大图导出会不会顶到内存； 页面返回、重进后状态还对不对； 真机触摸、拖动和长图渲染有没有差异。
这就是为什么“AI 会写代码”和“产品可以交付”之间，还有一大段路。
07最后做出来的，不是一键出图，而是一条完整的制作流程
做到后面，我对这个产品的判断也发生了变化。
它真正有价值的地方，不是“生成一张图”。
而是用户能不能从一张原图开始，一路把拼豆做出来。
所以现在的完整流程包括：
裁切和调整构图
↓
选择图纸尺寸与真实色卡
↓
生成
↓
编辑和检查
↓
统计材料
↓
逐色制作
↓
导出施工图
生成后可以继续使用画笔、橡皮、吸管和填充工具调整，也支持撤销、重做。检查页会帮助发现部分孤立色、稀有色和结构问题，修复建议则先让用户看到结果，再决定是否应用。
材料统计会按真实色号汇总数量；逐色制作会让当前颜色突出，帮助用户一种颜色一种颜色往下做。
施工图导出还要包含坐标、格内色号和颜色图例。网格本身也不是随便画：普通格线要淡，每五格需要更明显的定位线，外边框也要更突出，不然大图根本不好数。
这里也要区分一件事：原型图能说明“产品打算做什么”，但不能因为页面已经画出来，就写成所有功能都已经正式交付。
08测试和性能优化，最后也成了开发的一部分
项目做久以后，一个明显变化是：我不再愿意每次改完都靠自己重新点几十遍。
于是开始用 miniprogram-automator 把一些关键流程做成自动操作，让选图、生成、编辑、导出这些步骤可以重复回归。
我当时还留了一组固定回归样本：900×2048 像素的源图被转换成 94×216 网格，使用 MARD 221 色卡、最大 64 色；在那组测试环境里，新版本运行时间从约 5.7 秒降到约 1.6 秒，平均感知色差下降约 40%。
我更愿意把这类数字理解成“这一次修改有没有进步”的证据，而不是拿来做普遍性能承诺。换设备、换图片、换色卡，结果都可能不同。
发布前还会专门做一轮性能和交付检查：
做得越久，我还开始把已经踩过的坑整理成下一次 AI 可以直接复用的 Skill 和方法：
以前解决一个问题，最多留一份笔记。
现在还可以进一步把它变成下一次 Agent 的工作方法：哪些 Worker 限制必须先检查，Canvas 哪些问题必须真机验收，发布前必须跑哪些流程。
这大概也是我做完这个项目以后，对 Vibe Coding 最大的改观。
它不是“不会写代码也能一键上线”。
更像是：
原本一个人很难承担的需求分析、原型、开发、排错、测试和迭代，被 AI 压缩成了一条可以不断往前推进的协作链。
人还是得负责最后几件事：用户真正要完成什么、什么结果算好、哪些问题不能糊弄过去，以及什么时候真的可以交给别人用。
AI 把“做出来”的门槛降了很多。
但产品最后能不能站得住，还是要靠这些判断一项项压实。
最后，欢迎打开体验小程序，如果你也想做一个属于自己的小程序，欢迎留言或私信交流～