零代码做一个真实小程序,难的从来不是让 AI 写代码

上一篇我写《AI 会做软件了，菜谱小程序还值得做吗？》，最后得出的结论是：

AI 降低的是制作门槛，不是做好产品的门槛。

这次我想把后半句展开。

我做的「随心配菜谱」已经不是一个停在电脑里的 Demo。它有微信小程序、云端后端、数据库和运营后台，也真的有人打开、录菜谱、记冰箱、选想做的菜和记录一餐。

截至 2026 年 8 月 8 日，后台统计到 494 名外部用户；近 7 日新增 212，核心活跃 117。这个体量不大，留存和真实价值也还需要继续验证。但它至少越过了一条很重要的线：别人真的可以打开它、使用它，而不是只看一段演示视频。

更反常识的是：这个项目里，我一行代码没写，平时也几乎不逐行看代码。

但我必须先说清楚，我是技术出身。这不是一个「完全不懂软件的人，念一句咒语就做出产品」的故事。我的实验是：当我不再亲自编码，也不把阅读代码当成主要工作后，能不能靠 AI 把真实软件长期做下去？

答案是能。

但前提不是找到一句神奇提示词，而是给 AI 建一套交付系统。

一、一点不懂，直接从零干，很容易变成许愿

刚开始用 AI 做东西的时候，确实很爽。

一句话出去，一个页面出来；再补一句，又多一个功能。成就系统、家庭群组、海报生成、「AI 帮我搭配」……只要我能想到，AI 很快就能做出来。

有一阵子，我瞄了一眼系统，已经被扩成二十多张表、三百多个字段。功能看上去越来越完整，我却越来越说不清：这些数据为什么存在，它们之间是什么关系，改一个地方会不会把另一个地方弄坏。

我后来给这种状态起了个名字：许愿。

你对 AI 说「我要一个很厉害的菜谱小程序」，AI 当然可以把愿望铺成页面、按钮和数据结构。但愿望不是需求，生成出来也不等于做对了。

一个很典型的例子，是曾经那个叫「AI 帮我搭配」的按钮。名字听起来很智能，底层其实只是五十多行固定规则。它不是完全没用，但这个名字承诺了它兑现不了的东西。

最后我把它砍了。

成就系统、家庭群组和一些看起来完整、实际没有核心消费者的功能，也陆续被删掉。

这一轮之后，我才真正理解：AI 最危险的地方，不是它做不出来，而是它什么都能做一点。它跑得越快，人越容易把「正在生成」误认为「正在前进」。

二、我不看代码，但我不是什么都不做

不亲自写代码之后，我的工作没有消失，只是换了位置。

我主要负责四件事。

1. 把真实麻烦说出来

不是说「给我做一个推荐系统」，而是说：

我下班回家打开小程序时，想先从自己会做的菜里看四个候选；如果冰箱里缺东西，要直接告诉我还差什么，不要让我重新搜一遍菜谱。

一个好需求至少包含场景、动作、当前问题和可观察结果。技术方案可以让 AI 想，但「什么才算解决了我的问题」必须由人定义。

2. 决定什么不做

现在项目任务箱里有 169 条真实任务：113 条完成，22 条储备，21 条被放弃。

我很看重那 21 条被放弃的任务。

AI 能把一个想法论证得很完整，也能很快做出第一版。但产品不是功能总和。人的价值往往不是批准 AI 做什么，而是在兴奋过去以后说：这个不是现在的核心，先别做。

3. 判断体验是否成立

按钮放在哪里顺不顺手，流程是不是拧巴，文案像不像人话，第一次打开的人能不能理解——这些问题不能由「代码通过测试」替代。

我会让 AI 打开微信开发者工具，进入指定页面，点击、输入、滚动、截图，再回读页面状态。最后我自己看真实页面，决定它到底好不好用。

4. 承担最后的风险

部署生产服务、修改线上数据、开通付费资源、提交审核、公开发布，这些都不是「AI 觉得可以」就可以。

AI 可以准备，可以执行到确认前，可以给出回滚方案，但最后的授权仍然在人手里。

所以，零代码并不等于零责任。你只是从写代码的人，变成了问题定义者、产品决策者、验收人和风险责任人。

三、真正让我敢放手的，是四层项目记忆

很多人第一次用 AI 写软件，会遇到一个共同问题：今天聊得很好，过几天它像失忆了一样，把已经定过的东西重新做一遍。

这不是多写几句提示词就能彻底解决的。聊天上下文会结束，模型会换，Agent 会重启，甚至同一个任务也可能跨好几天。

我后来给项目补了四层可以被重新读取的记忆。

第一层：任务箱

所有碎碎念先进入任务箱。AI 先查有没有重复任务，再判断它是 bug、功能、设计还是文档问题，然后给优先级。

大功能还要先回答四个问题：证据是什么？为什么现在做？有没有更小的方案？做错了怎么退？

任务不是只有「做」和「没做」。它还可以储备、待拍板、待验收或者明确放弃。

第二层：项目地图

项目地图告诉每一个新来的 AI：现在是什么阶段，代码在哪里，哪些文档是事实源，改推荐、数据库、部署或小程序页面时分别先读什么。

它不保存所有细节，只负责把 AI 带到正确的地方。

第三层：领域契约

用户故事、API、数据模型、部署、测试和 UI 各有自己的权威文档。

这层解决的不是「AI 记不住代码」，而是「AI 不知道为什么必须这样做」。比如旧版小程序已经有线上用户，服务端字段就不能说改就改；云服务为了控制成本固定为零到一个实例，也不能因为某次部署方便就偷偷扩容。

第四层：可重复的 Skill

Skill 不是一句万能提示词，而是一份窄而明确的操作手册。

测试小程序、部署云服务、做数据变更、上传体验版、生成宣传图、搜小红书相关帖子、发送任务结果邮件，都有各自的流程、验证方式和禁止事项。

模型可以换，聊天可以结束，但流程还在。

这四层合起来，AI 才不再是临时来帮忙的聊天对象，而像一支每次上岗前都会重新读制度、接任务和交证据的流动团队。

四、AI 说「做完了」，我只问四句话

不会看代码，最容易焦虑的问题是：我怎么知道它真的做对了？

我的办法不是逼自己去审每一行代码，而是追问可观察证据。

我固定问四句话：

改了什么？跑了什么？真实页面看到了什么？还有什么没验证？

这四句看起来很普通，实际把「完成」拆成了四种不同证据。

「改了什么」防止 AI 用一堆正确废话掩盖没有落地；「跑了什么」要求它真的执行测试和构建；「真实页面看到什么」防止只在代码层自证；「还有什么没验证」则逼它承认边界，而不是为了结束任务宣布全都正常。

我还会要求每个 bug 尽量先变成一个能失败的回归测试。修好之后，这个测试留在项目里，下一次别的改动又碰坏它，门禁会先报警。

自动测试也不是终点。

微信小程序运行在自己的容器和云环境里。Node 测试全绿，不代表真实的 callContainer、登录、图片上传和页面交互都没问题。所以最后还要进微信开发者工具，必要时再上真机。

我不需要读懂每一行实现，但我必须看懂证据链。

五、从一句需求到真实上线，AI 到底干了什么

现在这套流程大概是这样：

我随口提一个真实问题→ AI 放进任务箱，查重并挑战→ 读取项目地图和领域契约→ 给出方案和可观察验收点→ 我决定做、改、储备还是放弃→ AI 设计 UI、修改小程序和后端→ 补回归测试并运行项目门禁→ 打开真实小程序页面操作和截图→ 需要时部署云服务、执行数据变更→ 上传体验版并回读平台状态→ 生成运营素材和执行结果邮件→ 我做最后验收

这里真正难的，不是其中某一步有多高级，而是跨层保持一致。

一个页面增加字段，后端 API、数据库旧数据、小程序旧版本、测试和文档都可能受影响。AI 很会在一个局部写出漂亮答案，但真实产品要求它同时照顾这些看不见的关系。

所以我给它的要求一直是：不要只改一个点，代码、测试、部署口径和文档要一起收口。

六、0 基础的人，真正需要准备什么

不需要先学会一门编程语言，但也不是打开 AI 对话框就能开始。

至少要准备这些东西：

• 一台能安装 Node.js、Git 和微信开发者工具的电脑；
• 微信小程序账号、AppID、管理员和体验者身份；
• 腾讯云或 CloudBase 账号、云环境和可接受的费用预算；
• Git 托管账号，用来保存和回退版本；
• AI Agent、模型订阅或 API 额度；
• 用于运营的小红书、公众号或邮件账号；
• 隐私政策、用户协议，以及与你收集的数据相匹配的合规材料。

扫码登录、实名认证、接受付费、提供密钥、决定数据权限、提交正式审核和对外发布，这些必须由人完成。

对于真正零基础的人，我建议第一周不要挑战「完整产品」，只走一个最小纵切：

1. 选一个非常窄的问题；
2. 只做一个页面；
3. 只接一个 API；
4. 只保存一种数据；
5. 在真实小程序里完成一次操作；
6. 故意制造一次失败，确认错误可见、数据不会乱；
7. 把完成标准和踩坑写回项目文档。

比如不要从「做一个菜谱平台」开始，而从「打开小程序，展示四道我自己录过的菜」开始。

第一周的目标不是功能多，而是第一次让「需求—实现—测试—真实页面—失败处理」闭环。

七、它确实很烧 token，模型也有门槛

这套玩法很烧 token。

最烧的不是第一次生成页面，而是长期读项目、调用工具、处理失败、跑测试，以及在小程序、后端、数据、部署和文档之间保持一致。

以我在 2026 年 8 月、这套项目和工具环境里的主观体感，大约需要智谱 5.2、K3、GPT-5.5/5.6、Claude Opus 4.6 这一档的综合能力，才能比较顺畅地长时间跑。DeepSeek V4 Flash 正式版在部分任务上勉强可用。其他模型也会很快追上，这不是一张永久排行榜。

更便宜的模型并非没用。写文案、做小修改、生成样例、跑定向检查，都可以交给它们。跨前后端、数据和部署的任务，再换更强的模型。

真正能省 token 的也不是少问一句，而是减少返工：任务更窄、契约更清楚、测试更自动、失败更早暴露。

八、我想公开这套方法，但不会直接把生产仓库裸开

我认真考虑过把这套围绕小程序开发的方案开源。

菜谱小程序本身被人看到、被 AI 很快追上，我觉得没关系。这个盘子足够大，功能也不是最难复制的部分。

真正需要时间积累的，是一个维护者是否愿意长期修问题、处理数据、控制成本、解释边界，并在每一次发布后继续负责。

公开过程，也是在公开自己的工作方式：别人可以看到我不是生成一个页面就走了，而是在认认真真做产品。

但当前生产仓库不能直接一键公开。里面有真实云环境、机器路径、运营过程、用户数据边界、第三方图片和菜谱版权，也缺少正式开源前必须完成的许可证与历史记录审计。

更稳妥的顺序是：

1. 先公开文章和失败复盘；
2. 再开放脱敏的任务箱、项目地图和验收模板；
3. 做一个只连假数据、默认不碰生产环境的最小 starter；
4. 最后再决定生产仓库是否值得完成完整的安全、隐私和版权审计。

功能会被快速追上，信任不会一夜建立。

这可能才是我愿意把它写出来的真正原因。

如果我先整理一份可以直接复制的模板，你更想先拿到「任务收件箱」，还是「不看代码的完整验收工作流」？