我不会写代码, 却把一个复杂小程序做到了上线
- 2026-09-24 08:43:35
做"省停停"以前，我对用 AI 开发小程序的想象很简单：
我把需求说清楚，AI 把代码写出来，我再把代码上传。
真正做完以后，我才发现，自己做的并不是"向一个 AI 要代码"。
更像是在管理一支临时组成的团队：有人负责产品，有人负责前端，有人负责后端和数据，有人审查代码，还有人陪我部署。
而我，是那个必须把所有结果接起来、在真实环境里验证，并最终决定能不能上线的人。
我不是程序员，也没有小程序技术开发背景。我有一些产品和项目协作经验，但这并不会自动让我看懂代码、云函数和部署环境。
这篇不是成功故事的浓缩版。
我更想把从一个想法走到正式上线的路径拆开，让你看到：AI 究竟做了什么，我又有哪些事情无法交给 AI。
起点不是"我要做一个小程序"，而是一个具体的麻烦
我在上海开车时经常遇到一个问题：
到商场、医院、学校或办事地点以前，我知道目的地在哪里，却不知道附近哪个停车场更合适。
地图能显示停车场，但真正影响决定的信息常常不完整：
▪ 离目的地到底有多远；▪ 收费规则是什么；▪ 入口在哪里、好不好找；▪ 是地面、地下还是路边停车；▪ 有没有实拍图；▪ 其他车主踩过什么坑。
所以，我最初的需求并不是"做一个停车平台"。
而是：
用户输入目的地后，能比较附近停车场，更快决定停哪里。
这句话后来成了整个产品的中心。
它也让我第一次意识到：一个项目能不能做出来，和 AI 会不会写代码不是同一件事。你首先要知道，自己到底在替谁解决什么问题。
 |  |  |
用户选择目的地后，地图显示周边停车场、距离、类型和实拍信息。
第一阶段：AI 先帮我删东西，而不是写代码
最开始，我的设想远比现在复杂。
除了搜索和比较停车场，我还考虑过预约、在线支付、实时车位、优惠交易等功能。它们听起来都合理，也很像一个"完整平台"应该拥有的能力。
但当我让 AI 分别从产品、数据、合规和开发角度审查时，问题很快出现了：
▪ 实时车位从哪里来，能否稳定获得？▪ 在线支付涉及什么主体和资质？▪ 用户之间交易优惠券，出现纠纷怎么办？▪ 预约成功以后，停车场是否真的承认？▪ 数据更新由谁负责，错误信息如何纠正？
这些问题不是多写几段代码就能解决的。
最后，第一版砍掉了在线支付、停车预约、实时余位和用户之间的优惠交易，保留了最核心、也最有可能真实运行的链路：
搜目的地 → 看附近停车场 → 比较信息 → 查看详情和攻略 → 用户补充或纠错 → 后台审核后再展示。
这一阶段，AI 最有价值的工作不是"生成"，而是帮我暴露假设、计算代价、发现边界。
但最后决定什么做、什么不做的人，仍然是我。
因为 AI 不知道我愿意承担多少成本，也不会替我承担错误方向带来的后果。
第二阶段：我没有找到一个全能 AI，而是给 AI 分了角色
需求收敛以后，我曾经以为可以把整份需求交给同一个对话，让它从头做到尾。
很快我就发现，这样做的问题很多：
对话越来越长，前面的决定容易被忘记；产品讨论、代码修改、故障排查混在一起；同一个 AI 刚提出方案，下一刻又自己证明方案没问题。
于是，我开始让 AI 承担不同角色。
◆ 产品顾问
负责追问用户是谁、场景是什么、第一版为什么要做这些功能，以及哪些需求应该推迟。
◆ 项目统筹
负责把需求拆成任务，明确先后顺序、依赖关系、完成标准和版本变更。
◆ 前端与交互顾问
负责用户看到的页面、按钮、状态、提示和操作路径。
◆ 后端与数据顾问
负责数据怎样保存、不同页面怎样取到同一份信息、用户提交以后如何进入审核流程。
◆ 代码审查员
不参与自证，专门从安全、错误处理、数据一致性和修改范围上找问题。
◆ 部署顾问
不一次丢给我几十个步骤，而是每次只带我完成一个动作：去哪里、点什么、正常应该看到什么、我需要把什么结果反馈回来。
这些角色并不一定要由六个不同品牌的 AI 承担。
你可以用同一个 AI 开不同对话，也可以组合不同工具。重要的不是"使用哪一个 AI"，而是不要把所有工作混成一句"帮我把小程序做完"。
角色的本质，是给 AI 限定目标、上下文和验收方式。
第三阶段：页面做出来了，我才看见真正的工程
最初，我关注的是用户能看到的页面。
但为了让一个页面真的工作，背后还要有很多东西互相连接：
▪ 小程序前端负责接收用户操作；▪ 后端负责处理搜索、收藏、投稿和审核；▪ 数据库保存停车场、价格、图片、攻略和用户记录；▪ 运营后台让人处理纠错、投稿和内容风险；▪ 地图接口提供地点搜索和定位能力；▪ 云端环境承载真实运行的服务；▪ 日志记录系统实际发生了什么。
最初只是"附近哪里能停车"的想法，后来对应了 22,819 个停车场的基础数据，以及多条用户提交、后台审核、前台展示的数据链路。
停车场详情不只是一个页面：价格、实拍图、来源、纠错和审核状态，都需要背后的数据与流程支撑。
这也是很多非技术用户最容易误判的地方：
看见一个像真的页面，就以为产品已经完成了 80%。
实际上，页面可能只是展示了几条写死的示例数据。按钮可以点击，却没有把信息保存到数据库；开发工具里显示成功，手机上却没有任何变化。
一个复杂小程序的进度，不能按"做了多少个页面"计算。
应该按"打通了多少条真实链路"计算。
例如用户纠正停车价格，这条链路至少要经过：
用户填写 → 提交成功 → 数据入库 → 后台出现待审核记录 → 运营人员审核 → 正确内容发布 → 用户端重新读取 → 错误时可以撤下或恢复。
只完成其中一半，都不能叫真正完成。
第四阶段：AI 交付代码以后，工作才进入现实
AI 可以生成代码、解释报错，也可以告诉我应该怎样部署。
但它无法替我完成许多现实动作：
▪ 注册并管理微信小程序账号；▪ 创建真实的云环境；▪ 配置接口、域名和环境变量；▪ 保管密钥并控制权限；▪ 导入真实数据；▪ 上传开发版和体验版；▪ 在自己的手机上授权定位、上传图片、提交内容；▪ 查看数据库、运营后台和日志是否出现对应记录；▪ 阅读平台审核意见并修改；▪ 最终点击发布。
这些步骤听起来不像"创造产品"，却决定了产品能不能离开电脑，真正被别人使用。
我在部署时最有效的一条提示，不是技术最强的提示，而是下面这条：
提示词 · 部署顾问
你现在是我的部署顾问。我没有技术开发背景。请不要一次给我完整教程，每次只告诉我一个可执行步骤，并明确：在哪个软件或页面操作、点击或输入什么、正常应该看到什么、失败时需要截取什么信息。等我反馈真实结果以后，再给下一步。不要假设我已经完成任何操作。
它把"给我知识"变成了"陪我完成"。
对不会部署的人来说，这两者差别很大。
第五阶段：真正的上线，不是 AI 说"完成了"
项目中，我遇到过很多次"看起来完成"：
▪ AI 修改了代码，但改的是历史备份目录；▪ 用户端提示提交失败，后台其实收到了记录；▪ 内容已经审核通过，却只生成了草稿，前台仍然看不见；▪ 后台撤下了错误图片，详情页却还在继续展示；▪ 开发工具运行正常，真机或正式环境却不是同一个结果。
这些经历让我形成了一个很朴素的标准：
是否完成，不由写代码的人宣布，而由真实环境里的证据决定。
所以每次关键功能完成后，我都需要同时检查：
1. 用户端发生了什么；2. 数据库实际保存了什么；3. 运营后台能否看到并处理；4. 日志里有没有异常；5. 当前手机运行的是哪个版本；6. 出错以后能不能撤回或恢复。
上线以后，用户提交的内容不会自动变可靠。审核、发布、撤下和追踪同样是产品的一部分。
最终上线的，不只是几张页面，而是一套可以被真实用户操作、可以被运营人员管理、出现错误后还能处理的系统。
AI 做了什么，我又必须做什么
如果把整个过程压缩成一份分工清单，大概是这样。
AI 适合承担的工作
▪ 帮我追问和整理需求；▪ 从不同角度挑战产品假设；▪ 把目标拆成页面、数据和任务；▪ 生成前端、后端和管理后台代码；▪ 设计数据结构和接口；▪ 分析报错、日志和异常现象；▪ 检查代码、安全和遗漏；▪ 把复杂操作翻译成逐步指引；▪ 根据真实反馈继续修改。
我不能外包给 AI 的工作
▪ 选择要解决的真实问题；▪ 提供不能靠猜测获得的业务事实；▪ 决定取舍、预算和风险边界；▪ 确认 AI 操作的是正确项目和正确版本；▪ 完成账号、权限、部署和平台操作；▪ 用真实设备和真实数据验收；▪ 判断结果是否符合用户需求；▪ 对隐私、内容、费用和发布结果负责。
这不是说非技术主理人什么都要亲自做。
当项目涉及复杂支付、高敏感数据、医疗、金融、实时安全控制或大规模交易时，仍然应该找专业开发、法律、安全或行业人员参与。
真正重要的是：你知道哪一部分可以交给 AI，哪一部分必须由一个真实的人负责。
换成别的小程序，这套路径还能用吗？
可以，因为可以迁移的不是停车页面，而是完成一条真实业务链路的方法。
如果你做预约小程序，核心链路可能是：
用户选择时间 → 系统检查名额 → 提交预约 → 管理员确认 → 用户收到结果 → 取消后释放名额。
如果你做会员资料小程序，核心链路可能是：
用户提交资料 → 系统保存 → 管理员审核 → 权限生效 → 用户修改 → 变更留下记录。
如果你做内容或社区小程序，核心链路可能是：
用户投稿 → 内容检测 → 人工审核 → 正式发布 → 被举报或发现错误 → 撤下并停止展示。
领域不同，但你都需要回答五个问题：
1. 谁在什么场景下完成什么任务？2. 数据从哪里来，又保存到哪里？3. 谁有权查看、修改和审核？4. 怎样证明整条链路真的完成？5. 出错后怎样纠正、撤回或恢复？
能够回答这五个问题，你才真正开始从"让 AI 做页面"转向"用 AI 推进一个产品"。
如果你今天就想开始，先不要让 AI 写代码
你可以先把下面这段话交给你正在使用的 AI。
提示词 · 开工前的第一轮对话
我没有技术开发背景，想做一个【小程序类型】。它要帮助【目标用户】在【具体场景】下完成【最核心任务】。
现在先不要写代码，也不要默认我的想法可行。请作为产品顾问和项目审查员，依次帮我完成：
1. 用一句话复述真实用户问题；2. 列出必须由我补充、不能由你猜测的事实；3. 找出数据来源、平台规则、主体资质、费用和运营上的关键风险；4. 把第一版收敛为一条最小但完整的用户链路；5. 明确第一版做什么、不做什么；6. 列出 AI 可以承担的角色，以及每个角色需要交付什么；7. 为每一阶段写出可被真实验证的完成标准。
如果信息不足，请先逐个提问。未经我确认，不要进入页面设计和代码生成。
使用这段提示时，不要只看 AI 给出的方案是否"专业"。
你还要检查：它有没有把未知事实当成已知？有没有绕开最难的数据和运营问题？有没有把"页面能显示"当成"业务已完成"？
我真正学会的，不是写代码
从想法到上线，我没有变成一名程序员。
我学会的是另一种能力：
▪ 把一个模糊想法变成可判断的问题；▪ 把复杂目标拆成不同角色和阶段；▪ 要求 AI 提供证据，而不是接受结论；▪ 在自己不熟悉的领域里，一步一步缩小不确定性；▪ 对最终结果负责。
AI 确实降低了一个人做产品的门槛。
但它降低的是获取专业能力的门槛，不是取消判断、执行和责任。
非技术用户真正需要学习的，不是怎样像程序员一样写代码，而是怎样成为一个能组织 AI、连接真实世界并验收结果的主理人。
下一篇，我想继续拆开 Vibe Coding 里最容易让人误判的一件事：
为什么你和 AI 聊得很顺、页面也越来越好看，项目却可能一直没有真正向上线靠近？
这也是"会聊天"和"会做产品"之间最大的区别。
VIBE CODING 实战复盘系列
关注我，追更这个系列
下一篇：为什么聊得很顺、页面越来越好，项目却没有真正向上线靠近？
— END —
如果觉得有启发，欢迎点个「在看」或转发给同样在做小程序的朋友
