用AI从零开发微信小程序的理想很丰满，现实却很骨感。一个‘随手当市长’的失败案例，揭示了AI编程在环境配置、平台规则和系统验证等环节的致命短板。本文深度拆解三类典型错误与七步工程化解法，告诉你为何AI能写代码却扛不起项目成败。

一、前言

2026 年春，我用 AI 工具从零做了一款微信小程序——”随手当市长”（又名”随手造景”）。想法很简单，用户拍下路边的风景，AI 把它改造成理想画面。还煞有其事地写了句slogan：”拍下路边，AI 改造，世界本该更美好”。

最后，卒。

结合本次经历和教AI开发的公开资料，网上资料要么教配置却过于前置，要么给出“修复用户session过期后refresh token仍有效但刷新失败”之类0代码基础的人看不懂的话，要么太通用反而无从下手。

本文仅聚焦于0代码基础用AI开发的失败经历与简要的工程化措施，而不是创业全流程指南，不涉及需求、市场、商业和运营。这些与AI关系不大，难以工程化，也超出本次实践与个人能力范围。且本文并未解决AI改完代码后自动测试不理想的问题，除了换AI工具外，本人至今找不到有效措施。

二、失败类型

本章节概括失败的类型，不展开描述，不希望陷在细节里。如果描述粒度精确到具体的问题，太过繁琐，且问题和解决方式涉及代码，我看不懂，无法为文章质量负责。大家可能会遇到类似或不同的问题，但基本可以分成三层：

1. 代码错误，代码就是错的，AI通常比较容易修。例如：中文变量名、catchtap=“”、wx：for传数字等。
2. 系统错误，单个代码没问题、整体系统有问题，AI开始容易迷路。例如：上传修好删除坏了、修改A影响B、回归测试不足等。
3. 环境错误，代码没问题、系统没问题、环境/配置/规则有问题，AI甚至都不知道有问题。例如：BOM、Promise运行时差异、隐私授权、云函数配置、textarea原生组件等。

2.1 方向性的错

2.1.1 核心前提不验证就开工

我最开始问 AI 的问题是：”我能用你无代码开发微信小程序吗？”这句话暗藏着一个期待“你帮我搞定一切，我不用操心”。AI的回答我也很满意，AI说：

完全可以帮你开发微信小程序，而且你不需要自己写代码。你只需要：

1.告诉我你想做什么 — 用自然语言描述你的小程序需求

2.我来负责所有代码 — 页面设计、逻辑实现、云开发配置等全包

这个承诺成了整个项目错误的起点。

小程序的核心功能只有1个：用户上传照片，AI 改造它。

我加入了小程序开发计划，可免费使用一定token额度的混元生图。我将API文档链接给它，AI 说混元 API 可以。其实我能看懂API文档，并且大概浏览过，隐约看到只支持文生图，但我的想法是“AI，让我看看你的极限”。最后开发完才发现只支持文生图。

更关键的是，我到最后才发现。微信个人主体发布的小程序，只能做普通图片编辑类功能。AI 相关的功能，要求企业主体才能发布。也就是说，即使 API 支持图生图、代码全部跑通，我也发布不了。此项严重失误与AI无关，纯粹是我只看了个人主体的服务类目包含“图片处理”，想当然的认为AI图片处理也属于“图片处理”。

2.1.2 一直在准备，从来没碰核心

开发之前，看到一篇文章，AI时代的产品迭代可能不需要遵循MVP，先让AI给出包含所有功能的产品残品再一点点优化。理由是AI写代码的速度很快，没必要先做MVP，直接做成品。

为尽可能完善，我的产品文档写了 5 个版本，等级体系从 5 档扩到 20 级再砍回 10 级，全过程纸上谈兵。一开始让AI开发全部功能，后来发现全部功能调试起来太麻烦，改完这边的问题那边又有了。终于受不了，砍掉枝叶，只做核心功能，假如全职做的话，核心功能大约也就一两天。

果然，AI时代的开发仍要先做MVP。

2.2 方法上的错

2.2.1 AI听不懂我说的话

有时自然语言和AI理解不一致。比如我将废弃地的图片改造为生态公园，我口语说“废弃地”是标签，AI认为“改造前”是标签，可以先统一语言。如果懂代码，最好直接给AI说挪动哪个元素到什么位置。如果不懂，可以问AI需要挪动哪个元素。

案例：我让AI将改造前后的名称挪到下面，这种小要求AI也改了好几次。

记得心态平稳，认清AI改不好是常态。

2.2.2 反复修改

比如按钮点不动。问 AI，它说可能是 A。改完不行。说可能是 B。还不行。再说试试 C。一个按钮搞了十几轮，此外，还有BOM 问题、旧接口被停用、格式等各种问题。

更麻烦的是，一个问题改不好，还引发了其他问题。比如修好上传，删除坏了。修好删除，上传又坏了。调好拍照页，结果页白屏。

还有同一个问题反复出现，这次改好，下次还犯。比如MEMORY.md 里写了”源码不能出现 wx.cloud”，但仍然生成了，AI工具连MEMORY.md都能忽略。

对于完全不会代码的人来说，按钮点不动、数据库连接失败、接口返回格式错误几乎没有区别，因为最终表现都是不工作。于是只能告诉 AI“还是不行”，而 AI 最怕的反馈就是“还是不行”，因为信息接近于零，它只能继续猜。

看起来 AI 在修 Bug，实际上 AI 更类似搜索答案“可能是A→不是→可能是B→不是→可能是C”，本质是穷举搜索。如果搜索空间很小，很快找到；如果搜索空间很大，AI可能永远找不到。

2.2.3 代码没问题也不行

这一类最绝望，因为出问题的时候从代码上看一切正常。 比如云函数超时，package.json里写了timeout，但实际不生效，必须在云开发控制台手动设置且至少 60 秒。微信要求后台声明用途，代码写的再好，不在微信公众平台上配置也没用。

代码写对了不等于能用，还有文件格式、工具链、平台限制、运行时环境等等一堆东西等着你。

2.3 小节

很多AI编程宣传视频给人的感觉是“想法→AI→成品”。但真实流程更像“需求→AI写代码→编译器→构建工具→平台规则→权限系统→云服务→用户设备→产品上线”。如果出bug，问题至少分为代码问题、系统问题、环境问题、平台规则问题、配置问题。AI的大量时间其实都浪费在用修代码的方法，去解决根本不是代码导致的问题。

AI时代的一个人≈传统开发的产品经理+架构师+开发工程师+测试工程师。但目前AI就算可以比较好地代替开发工程师，仍然不太能稳定代替测试、风险控制、系统验证，没有人负责持续质疑和验证。

而且从头到尾，我的真实心态不是”我要创业做小程序”，更接近”我想试试AI到底能做成什么样”。

这是两种完全不同的模式。玩乐模式：你接受 AI 的乐观判断，不验证、不查资料、不去想后果——做不成就算了，反正就是试试。开发模式：你做之前先确认最关键的那个前提能不能成立，确认了再往前走。直到项目挂掉才意识到自己从来没切进开发模式。

AI 的问题是无法确认自己是否正确，人的问题是无法判断 AI 是否正确，所以不是不会解决问题，而是反复修改。AI 能写代码，但不对方向和结果负责，你必需知道 AI 替你做了哪些关键判断，以及为什么是这些判断。

三、简易工程化措施

需求、定位、市场、是否需要MVP等方向性的错误，大部分与AI无关，只能由人反复确定并负责，本文不涉及这些的解决措施。不过AI写代码本身的解决方案可以回归调试系统的思维方式，即观测 → 描述 → 猜想 → 验证 → 修改 → 沉淀 → 重置。

总有人说提示词已死，但至少现在还没死。或许提示词将来会死，但如何用对方能听懂的话沟通、如何工程化约束AI仍然有效。所以本章节给出了一些提示词以供参考，可视实际情况使用或批判性吸收到自己的skills、规则等。

3.1 观测

提高可观测性，让AI在前端或日志加上报错提示，截图或复制给AI完整的提示。

3.2 描述

让AI听懂你的意图。

如果不知道元素名称，可以先问”xx页面中涉及哪些元素？标注名称“。

在沟通前，强制AI复述你的描述，确保理解一致，比如可以说“复述一遍我的需求，说明需要怎么改？等我确认。强调：禁止修改代码”。

描述包含操作、现象和期望，比如“我的操作是1、xxx；2、xxx；3、xxx。出现bug xxx。报错为xxx。期望xxx”。

提供上下文，比如“我在开发者工具打开/在网页打开/上传了云函数/使用了xx接口/最近修改了xx”。

3.3 猜想

枚举可能原因，避免直接跳入“怎么修”，比如给AI说有哪些可能原因？按概率排序。可参考如下提示词：

有bug xxx，禁止修改代码，按以下步骤诊断：

1.这个问题属于哪一类？（代码逻辑 / 页面状态 / 权限授权 / 微信平台限制 / 云环境配置 / 开发工具 / 其他问题）

2.列出所有可能的原因，按概率排序

3.4 验证

用事实驱动判断，且每一步验证都旨在缩小怀疑范围。问AI“什么证据支持这个判断？检查结果分别意味着什么？下一步检查能排除什么？”。禁止说“你觉得呢”或“下一步改什么”。人和AI相互帮助，验证修改结果。

可以在3.3小节的基础上增加以下提示词，一块使用：

1.告诉我先检查什么、为什么先检查它、怎么检查

2.告诉我检查结果分别意味着什么

3.5 修改

最小影响修改问题。

1.针对某个问题，强制让AI分析上下游影响，比如问AI哪些功能依赖它？它依赖哪些功能？如何保证仅修改此功能？可以参考如下提示词：

假如问题是xx（诊断出的问题），请按照以下约束先完成第1、2步的分析，再修复代码：

1.影响范围分析

分析根因、依赖关系、被依赖关系、如果改动可能影响的范围、最小修改方案

2.最小化修改策略

请只修改必要的那几行代码，不要重构、不要调整无关代码。

如果建议的修改涉及多个文件，请逐一说明每个文件的改动点和必要性。

3.代码与环境约束

参考错误文档xx.md，避免已经发生的错误。

4.验证要求

给出本次修改的验收标准：具体操作步骤 + 预期现象。

2.让AI单独开发测试页面，只放核心逻辑。我的小程序足足有150个独立的Python 调试脚本，涵盖测试bottom值、调试点击事件、检查详情下载按钮、截图_配色C、分析标签栏等。

3.6 沉淀

将每次踩过的坑记录下来，形成可被AI读取的文档，避免重复犯错。不要记录今天修了什么，而是记录以后禁止什么及必须干什么。建立编码规范，例如：禁止中文变量名、禁止空字符串绑定、必须处理异步错误等。建立环境问题库，例如BOM头、wx.cloud字面量、textarea遮挡、隐私授权三步等。

可以添加到MEMORY.md或单独建立BUG.md等文档。视AI工具本身的能力，按理说可以自动读取；若不能，手动强制要求调用文件。

可以参考以下提示词：

请根据本次调试经验，更新项目规范文档xx.md。只记录“以后禁止什么”和“必须做什么”，不记录具体bug经过。每一条规则应该是AI可执行的。

一些其他的约束条件，可视实际情况删改以下提示词： 请根据我们本次调试过程中遇到的问题和解决方案，进行知识沉淀,更新xx.md。

【重要原则】

1.不记录具体bug经过，只记录“以后必须遵守什么”和“以后禁止什么”。

2.每一条规则应该是AI可执行的，例如：“禁止使用中文变量名”而非“注意变量命名”。

3.区分“编码规范”和“环境/平台陷阱”，编码规范记录代码本身的问题，环境/平台陷阱记录除代码以外的系统问题、环境问题、平台规则问题、配置问题和其他问题。

3.7 重置

能改改，改不了换人。

即使你遵循上述6步流程，仍可能遇到工具本身的问题。例如，AI开始胡言乱语了；上一轮能读报错截图，下一轮说不支持查看图片；AI工具支持自动测试，但时灵时不灵。

为此，建议：

1.开启新对话，并把之前所有的报错和代码作为一个整体丢给新AI，先分析它为什么失败，有哪些可能原因，按概率排序。

给旧对话或旧AI的提示词可以参考：

禁止修改代码。我要用其他AI接力开发，根据当前对话内容，更新xx问题对应的失败记录，输出故障交接文档为”xxx.md”。 文档必须包含以下章节：

1.问题描述（原始现象、操作步骤、期望结果）

2.环境信息（如微信开发者工具版本、基础库、真机/模拟器；如果对话中未提供，标注“待补充”）

3.已尝试的方案（按时间顺序列出：每次修改了什么、结果如何、失败现象、排除了什么可能性）

4.当前状态（最后一次尝试后的代码状态、控制台输出）

给新对话或新AI的提示词可以参考：

xxx文件是源代码，xx文件是项目记忆，xx文件是xx。重要强调：xx文件是之前的失败调试记录，它是第三方提交的故障报告，不是事实。你的任务不是继续执行它的方案，而是审查它。请总结已试过的不行方案，然后给出新的诊断方向：

1.这个问题属于哪一类？（代码逻辑 / 页面状态 / 权限授权 / 微信平台限制 / 云环境配置 / 开发工具 / 其他问题）

2.列出所有可能的原因，按概率排序

3.告诉我先检查什么、怎么检查

4.告诉我检查结果分别意味着什么

2.建立工具备用机制，当某个工具反复出现异常行为，切换到另一个工具（有次我从workbuddy切到trae，一次就修复bug了。不过这是当前AI工具的普遍现状，可能从trae切到workbuddy也能一次性修复。这里不做工具推荐），不要在同一工具上死磕。

3.在个人消费水平内选择相对稳定的工具，并关注其更新日志。吃点好的吧。

3.8 小节

1.“3.4 验证”章节，我写的是让AI告诉用户如何验证，一是强制约束AI完善思考，二是指导用户看报错，对于没有编码基础的人，控制台那么多信息，都不知道看什么。按理说AI工具本身有自动化测试，可以承担验证的工作。但从事实来看，不尽人意。

2.就算AI给出了猜想或方案，0代码基础的人也看懂。所以无论是猜想，还是验证、修改，都是约束AI的，类似让迷雾中的人三思而后行。如果您有代码基础，没必要完全按照这个思路，尽可能先自行分析或判断。

3.按我实际使用的体验，以上提示词确实可以节省返工时间，但需要人主动“教”AI，显得有些累，而且有些问题可以一次性修复。所以，建议第一次按自己的习惯和AI沟通，比如说“出现了xx问题，现象为xx，应该xx，报错如下xx”，修复失败再使用以上提示词。

4.真正有价值的不是提示词本身，而是背后的工程原则，提示词可能会过时，但工程原则不会。用 AI 做产品，不需要学编程，而是需要学需求拆解、产品设计、AI协作、测试验证。分清楚什么交给 AI，什么自己把关。代码本身的事（样式、布局、普通代码实现）交给 AI，其他的事（可行性、接口能力、平台规则、成本、权限）建议自己二次确认。在做之前问自己一个问题：如果 AI 搞错了这件事，我会不会白干好几周？会，就自己查。不会，就交给 AI。

5.记住一个原则：用 AI 必疑，疑 AI 方用。不要把思考外包给AI。

四、后记

最初的想法很简单，随便玩玩，不成也罢，有了想法直接开发，没经过认真的调研。虽然开发时间整体加起来约一周，但每天做一点，零零散散也用了一个多月。失败虽然意料之中，难免遗憾。其实AI照片改造的最佳形态并非独立小程序，而是手机系统级相册的内置功能，或是由大模型将用户语音转化为相机参数直接拍照。既然创业未半而中道崩殂，且作留白。

本文希望能为“一人公司”降降温，很多鼓吹一人公司的人，本质上是在售卖 Token 以收取 AI 时代的地租，或者是兜售焦虑的卖课商。对于“一人公司”而言，AI写代码是最简单的，代码之外的市场、获客、营销等传统的工作反而是重点。

秉承互联网的开源精神，也为纪念这次失败实践，我将本项目的原型截图开源（因内含敏感信息，且至今仍有bug，无法为 AI 生成的质量背书，源码不予公开）。若能对您的产品有所启发，就感谢热心网友吧。

附录一：原型截图

https://mp.weixin.qq.com/s/lLkS53XbprHG7dXFH0zhxQ

附录二：具体错误归类

重要声明：我没有任何编程基础。下表由 AI 根据开发记录整理，请自行判断准确性。

API / 服务配置

1. 混元 API Version 参数问题 混元 API 的 Version 参数不能用当前最新日期。 → 解法：必须固定设为 2023-09-01。

2. 区域参数缺失问题 没传区域参数导致接口调不通。 → 解法：请求头必须加 X-TC-Region: ap-guangzhou，混元仅支持广州区域。

3. 图片 Base64 前缀问题 上传图片时带了 data:image/jpeg;base64, 前缀，API 解码失败。 → 解法：ContentImage 字段必须传纯 Base64 字符串，去掉前缀。

4. 结果图片字段取错问题 查询结果后拿不到图片数据。 → 解法：结果图片在 ResultImage 数组中，取第 0 项 ResultImage[0] 即可。

5. 分辨率参数格式问题 分别传 Width 和 Height 不生效。 → 解法：改用字符串格式 Resolution: ‘768:1024’。

6. JobStatusCode 类型误判问题 把 JobStatusCode 当数字判断状态，导致全部误判。 → 解法：它是字符串类型——’1′ 等待中、’2′ 运行中、’4′ 失败、’5′ 完成。

7. 云函数超时设置问题 在 package.json 里配置了超时时间，实际不生效。 → 解法：必须在云开发控制台手动设置超时时间，建议 60 秒以上。

8. 服务未开通就调接口问题 云服务账户未开通就开始调接口，返回”未开通”错误。 → 解法：先到云平台控制台开通对应服务，再写代码调用。

微信 API / 权限

9. 选图接口已废弃问题 旧接口 wx.chooseImage 从基础库 2.21.0 起已废弃。 → 解法：换成新接口 wx.chooseMedia，注意返回值字段不同（res.tempFiles[0].tempFilePath）。

10. 隐私用途未声明问题 未在微信后台声明隐私用途，选图直接 fail，错误码 112。 → 解法：进入微信后台 → 设置 → 服务内容声明 → 用户隐私保护指引，声明”选中的照片或视频信息”。

11. 未处理隐私授权弹窗问题 代码中没有处理隐私授权弹窗，新用户 100% 失败。 → 解法：配置文件加 __usePrivacyCheck__: true；入口文件注册 wx.onNeedPrivacyAuthorization。

12. 隐私弹窗被拒后重试问题 隐私弹窗被拒后 10 秒内再次调用，直接报错不弹窗。 → 解法：考虑引导用户手动开启授权，或延长重试间隔。

13. 个人主体无法做 AI 功能问题 微信个人主体只能发布图片处理类小程序，AI 图生图要求企业主体。 → 解法：开发前先确认微信服务类目是否支持你的核心功能，必要时注册企业主体。

14. 认证费用未考虑问题 个人小程序认证需 30 元/年，不是免费的。 → 解法：开发前确认认证费用，计入项目成本。

15. 小程序名称敏感问题 名称含”市长”字样，只有政府机构才能使用。 → 解法：开发前查阅微信小程序命名规范，确认名称是否可用。

代码生成 / 编译器限制

16. 文件 BOM 问题 PowerShell 的 Set-Content -Encoding UTF8 存的文件自带 BOM（0xEF 0xBB 0xBF），WXSS 编译器不兼容。 → 解法：用 Python 的 open(path, ‘w’, encoding=’utf-8′) 写入源码文件。

17. wx.cloud 字面量扫描问题 源码中出现 wx.cloud.database() 字面量，编译直接崩溃。 → 解法：改用间接引用 wx[‘cl’ + ‘oud’].database()。

18. Promise 导致页面注册失败问题 .then / .catch 链式调用导致 Page 注册静默失败，按钮无反应且 Console 零日志。 → 解法：所有异步操作全部改为纯回调 success / fail 写法。

19. 中文标识符编译报错问题 AI 生成的中文变量名或函数名（如 var 用户数据 = {}）导致编译报错。 → 解法：变量名和函数名全部使用英文。

20. catchtap 为空字符串问题 catchtap=”” 是非法写法。 → 解法：绑定真实函数名，或者直接删除该属性。

21. wx：for 传了数字问题 wx:for 绑定了一个数字而非数组。 → 解法：wx:for 必须遍历数组，需要先把数字转成数组。

22. CSS inset 简写不兼容问题 CSS 中用 inset: 0 简写，小程序不支持。 → 解法：四个方向分别写：top:0; right:0; bottom:0; left:0。

23. textarea 原生组件遮挡问题 textarea 是原生组件，z-index 对它无效，会遮挡底部按钮导致点击穿透。 → 解法：底部按钮容器用 position: absolute 脱离原生组件层级。