不会写代码也能用AI做出一个微信小程序并上线：从软件原理到备案发布的全流程实操拆解

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

只想要结论的朋友，先看这段加粗的部分：一个完全不会写代码的人，今天确实可以借助 AI 编程智能体，独立做出一个能在微信里跑起来、并且合规上线的小程序。整条链路我自己完整走了一遍，可以拆成六个大块——理解软件的基本构成、搭好开发环境、用 AI 把功能一个个生成出来、买服务器和域名把服务跑到公网上、过完 ICP 备案与公安备案与小程序备案这三道合规关、最后打包提审发布。你需要付出的不是"啃语法"，而是"把需求想清楚、把步骤拆明白、把每一步落地执行"。整个过程里真正卡人的往往不是技术，而是备案审核的耐心、以及对国内平台合规规则的不熟悉。

下面这篇是完整版的实操拆解。我会以一个记账类小程序作为贯穿全文的例子，把从零到上线每一个环节里"原理是什么、具体怎么操作、容易踩哪些坑"都讲透，并且把国内环境下必须注意的合规要点单独标出来。无论你是想验证一个小想法，还是单纯想体验一次"指挥 AI 干活"的爽感，看完都能照着把第一个属于自己的小程序做出来。内容偏长，干货也比较密集，想看完整拆解，往下翻。

第一章 先把"软件到底由什么组成"搞明白

很多人一上来就想动手敲东西，结果做到一半发现自己根本不知道做的是哪一块。我自己的建议是，先花十分钟把一个联网软件的骨架在脑子里立起来，后面所有操作都会有"我现在在拼哪块拼图"的踏实感。

一个完整的、需要联网的软件系统，通常由四个部分组成：客户端、服务端、数据库、网络。手机上的计算器那种纯本地、不联网的程序不在我们讨论范围内，我们要做的是一个像微信小程序这样、有网络交互的完整系统。

客户端，就是跑在用户设备上的那部分程序。打个比方，你开发了一个小程序，假设有一万个人在用，那就意味着这套客户端代码同时在这一万部手机上各自运行着。服务端则不一样，它跑在服务器上，通常是"服务端程序 + 数据库"，而且只需要部署一份。无论多少用户访问，大家的客户端都通过网络连到这同一份服务端上。

用一家餐厅来理解这套结构

这个比喻我觉得特别好用，第一次接触的人基本一听就懂。

把整个软件想象成一家餐厅。每位顾客进门，会有一名服务员对接，这名服务员就相当于客户端。顾客点完餐，服务员把点餐信息带去厨房——这一步就是客户端把用户的操作数据通过网络发到服务器。厨房收到菜单开始做菜，并把每道菜的状态（在做、做好了、被取消了）记录到菜单上——厨房做菜并记录状态，就是服务端处理逻辑、并把数据存进数据库的过程。最后服务员再把菜端给顾客，对应的就是服务端把处理结果通过网络返回给客户端。

我们偶尔会看到软件提示"服务繁忙，请稍后再试"，套进这个比喻就是：点菜的客人太多，厨房一时处理不过来。客户端和服务端之间的关系，大致就是这样。

下面这张图把四者的关系画出来，看一眼会比文字更直观：

graph LR
    A[客户端<br/>用户手机上的小程序] -->|通过网络发送请求| B[服务端<br/>跑在服务器上的程序]
    B -->|读写数据| C[(数据库<br/>存储所有数据)]
    B -->|返回处理结果| A
    A -.通过域名解析找到.-> B

从这张图里能看出来一件很关键的事：想做一个小程序，本质上要准备好三样东西——一套客户端代码、一套服务端代码（数据库通常集成在服务端这一侧），再加上一条把客户端连到服务端的网络通道。把这三块拼齐，一个能对外提供服务的完整软件就成型了。

各部分的职责，一张表看清

为了让新手彻底分清谁干什么，我把这几个角色整理成一张表：

这里先埋一个后面会反复用到的概念：域名。为什么客户端不直接连服务器的 IP，而非要绕一道域名？原因有两个，一是微信小程序官方根本不支持客户端直连 IP，必须用域名；二是如果客户端里写死了服务器 IP，将来换服务器就得改客户端、再让所有用户更新一遍，根本不现实。用域名的话，换服务器只要改一下域名解析的指向就行，客户端一个字都不用动。所以记住一句话：只要你的程序有服务端，就一定需要一个域名。这部分我会在第十章详细展开。

把这一章的结构吃透，你就已经领先很多"上来就乱点"的人了。莫潇羽在无忆研习社里反复强调一点：动手之前先建立骨架认知，是少走弯路最划算的一笔投入。

第二章 动手前的环境准备：把"地基"打好

骨架清楚了，接下来要把开发用的"地基"铺好。这一步操作不难，但工具有点多，我按"装什么、为什么装"的逻辑给你串一遍，你照着准备就行。

先确认技术语言，再装对应环境

我们做的是微信小程序，它本身基于 JavaScript 运行，而 JavaScript 依赖 Node.js 这个运行环境。服务端我用的是 express 框架，它同样跑在 Node.js 上。所以你会发现，前后端最终都落在同一个底座上——只要装好 Node.js，前后端的运行环境就都齐了。

Node.js 有很多版本，为了方便在不同版本之间切换，我习惯先装一个叫 nvm 的版本管理工具，用它来装和切 Node。装完 nvm 之后，可以在命令行里验证一下，再用它去下载一个 LTS（长期支持）版本的 Node：

# 验证 nvm 是否安装成功
nvm -v

# 查看可安装的 Node 版本列表
nvm list available

# 安装一个长期支持版本（版本号按列表里的实际为准）
nvm install 22.11.0

# 切换到刚装的版本
nvm use 22.11.0

# 验证 Node 与 npm
node -v
npm -v

装好 Node 之后，还有一个非常实用的小配置：把 npm 的下载镜像换成国内源。npm 默认从境外服务器拉包，速度往往很慢，换成国内镜像后下载会顺畅很多：

# 将 npm 镜像切换为国内源，显著提升依赖下载速度
npm config set registry https://registry.npmmirror.com

这一步纯粹是为了在国内网络环境下把依赖装得更快、更稳，属于完全合规的优化，建议每个人都做。配置好之后，就可以用 express 的脚手架快速生成服务端项目骨架了。

选一款国产 AI 编程工具，这是整套流程的核心

整条流水线里，真正"替你写代码"的主角，是一款 AI 编程工具。我自己用的是阿里云推出的 通义灵码（它现在升级为了 Qoder CN 系列，本质是同一个产品线）。选它的理由很实在：底层走的是国产大模型（如通义千问 Qwen3-Coder 等），全链路在国内云上部署，对个人开发者免费、合规，下载装上就能用。

这类工具最关键的能力是编程智能体——你用自然语言把需求说清楚，它会自主完成工程感知、代码检索、文件修改、终端执行一整套动作，端到端把功能给你做出来。除了智能体模式，它还有一个偏"先规划、后执行"的任务模式：先帮你把一个复杂功能拆成详细的设计文档和待办清单，你确认无误后它再按计划精确开发。后面做业务功能时，我基本都是用这种"先出文档、再执行"的方式，全程几乎没有手写过一行代码。

合规小提示：AI 编程工具底层可能调用多种大模型。优先选择在国内合规部署的国产模型与服务即可；若涉及境外模型或境外服务，使用时需遵守国内网络与内容管理相关规定。这一点在企业场景里尤其要留意。

其余几样必备工具，一次性装齐

除了 Node 和 AI 编程工具，还有几样东西要提前装好。我把它们连同用途整理成一张清单，照着装就行：

Git 值得单独说两句，它是后面贯穿始终的工具。它能记录每个文件改了什么、什么时候改的、谁改的，能帮你回退到任意历史版本，还能管理多个分支、把本地代码推到远程仓库。对个人开发者来说，最直接的好处有两个：一是换电脑或多设备开发时能随时拉到最新代码；二是本地代码不怕丢。装 Git 的时候注意把默认编辑器改成自己顺手的（比如 Notepad++），其余一路默认下一步即可。

到这一步，"地基"就铺好了：运行环境有了，AI 帮手有了，调试和版本管理的工具也齐了。莫潇羽@无忆研习社这边的经验是——环境别图省事跳着装，每装一个就在命令行里验证一下版本号，确认它真的生效，比后面报错了再回头排查省心得多。

第三章 不写代码也得懂的数据库常识

数据库这个词听起来很唬人，但它的本质特别简单：就是专门用来存数据的地方。我用前面餐厅点餐的流程，带你用 Excel 的思路想一遍，你立马就懂了。

用 Excel 模拟一遍，秒懂数据库在干什么

假设有这么一段流程：张三进店打开点餐小程序，提示需要登录，他登录了；接着点了三道菜——红烧肉 36 元、炒青菜 18 元、红烧排骨 49 元；厨房做好了红烧肉和炒青菜，这时张三觉得够吃了，把红烧排骨取消了；吃完很满意，又充值了 200 元。

如果用 Excel 来"当数据库"，我们大概会建三张表：一张存用户信息，一张存点餐记录，一张存充值记录。整个流程在数据里就是这样被一步步记下来的：

菜做好了，点餐表里对应那条的状态就从"未开始"变成"已完成"；排骨取消了，状态就改成"已取消"。下次张三再来，系统一查用户表就知道他是老客户，还能调出他点过什么、充过多少钱。这一整套"记录—更新—查询"，就是数据库每天在干的事。

flowchart TD
    A[用户在客户端操作] --> B[服务端接收请求]
    B --> C{需要存还是取?}
    C -->|新增/修改| D[(写入数据库)]
    C -->|查询| E[(从数据库读取)]
    D --> F[返回结果给客户端]
    E --> F

那为什么不直接用 Excel 当数据库？

很多新手会冒出这个念头：既然 Excel 也能存表格，干脆就用它呗。看起来可行，实际上坑很大。我把最直观的三个问题列出来：

第一是并发问题。Excel 不支持两个人同时打开写入，多个用户一起点餐，很容易文件损坏、数据丢失，或者只能排队处理，这在真实软件里完全不能接受。第二是性能问题。Excel 处理上万条数据就会明显变慢，而一个软件系统有几十万、上百万条数据再正常不过，Excel 扛不住这种量级的查询和保存。第三是安全问题。Excel 就是个文件，文件被人复制走，数据等于全泄露。

所以正经做法是用专业的数据库程序，它们天生就是为程序服务的，上面这些问题都不存在。常见的有 MySQL、Oracle、PostgreSQL 这一类，我们一般叫它关系型数据库。后面记账小程序要集成的，就是关系型数据库里的 MySQL。

你不需要去背数据库的语法，AI 会帮你把建表、读写都生成好。但你得知道它存在、知道它大概长什么样、知道为什么不能拿 Excel 凑合——这样当 AI 报"找不到某张表的数据"这类错时，你才看得懂它在说什么。这也是莫潇羽一直主张的：原理可以不精通，但概念必须在脑子里有个位置。

第四章 云服务器、运维工具与数据库部署

服务端代码总得有个地方跑起来，这个"地方"就是云服务器。这一章我们把服务器买好、连上、再把数据库装进去。

入门级云服务器，真的很便宜

现在面向个人的入门级云服务器价格非常友好，两核两G这种配置，一年也就几十块钱的量级。百度云、阿里云、腾讯云、天翼云这些厂商，常年都有面向新用户的入门级活动，选购前多对比几家的新人活动，挑一台入门级的就够开发测试用了。

买的时候有几个点要留意：地域选离自己近一点的，访问延迟低；操作系统尽量选中文版的 Linux 发行版，不确定就先搜一下；自动续费记得关掉，避免不知不觉扣费。买完进控制台，把服务器密码重置成自己记得住的，默认登录用户名一般是 root。到这一步，你就拥有一台属于自己的云服务器了。

连上服务器、把数据库用 Docker 装起来

连服务器要用到两类工具：一个 SSH 客户端用来敲命令，一个文件传输工具用来传文件。连接信息很简单——主机填服务器的公网 IP，用户名 root，密码填你刚重置的那个。

数据库我推荐用 Docker 来装。Docker 是一种容器技术，跑在服务器上，能让你很省心地运行和管理各种应用，装 MySQL 这类服务时一条脚本就能搞定，比手动一步步装要稳得多。大致流程是：把安装脚本传到服务器，给它加上可执行权限，然后执行：

# 给脚本加上可执行权限
chmod +x docker_install.sh
chmod +x mysql_install.sh

# 一键安装 Docker
sh docker_install.sh

# 查看当前运行的容器（验证 Docker 装好了）
docker ps -a

# 一键安装 MySQL（密码等参数在脚本里配置好）
sh mysql_install.sh

装完再执行一次 docker ps -a，能看到 MySQL 容器正常在跑就成功了。注意它默认对外的端口是 3306，这个数字要记住，后面连接数据库要用。

这里插一句运维小知识：上面那个 chmod +x 的意思，就是给文件赋予"可执行"权限。你会发现执行后文件名在终端里变成了绿色，绿色就代表它现在可以被运行了。这种细节 AI 不一定每次都提醒你，自己心里有数会顺很多。

别忘了开放安全组端口

数据库装好后，你在本地用数据库管理工具去连，很可能连不上。原因是云服务器出于安全考虑，默认大部分端口是关着的。解决办法是去控制台找到"安全组"设置，几乎所有云厂商都有这一项，添加一条规则：协议选 TCP，端口填 3306，来源 IP 按提示填（有的厂商要手动填 0.0.0.0/0 表示允许所有来源）。保存后再连，通常就通了。

graph TD
    A[本地数据库管理工具] -->|连接 3306 端口| B[云服务器安全组]
    B -->|放行规则: TCP 3306| C[Docker 容器]
    C --> D[(MySQL 数据库)]

安全提醒：把来源 IP 设成允许所有，开发阶段图方便没问题，但正式对外时建议收紧到你需要的来源范围，并为数据库设置足够强的密码。数据安全这根弦，从一开始就要绷着。

这一章做完，你的"后端基础设施"就齐活了：一台公网能访问的服务器，一个跑在 Docker 里的数据库。后面 AI 生成的服务端代码，就部署到这台机器上。

第五章 用 Git 和远程仓库把代码管好

正式写功能之前，还有一件事得先安排上：代码的版本管理。这件事在个人开发里太容易被忽视，但一旦养成习惯，能帮你躲掉无数次"改崩了又回不去"的崩溃时刻。

注册一个国内的远程代码仓库

本地已经装了 Git，但代码只存在自己电脑上还不够。我们再注册一个国内的远程仓库平台（比如 Gitee），把本地代码推上去。这样做有几个实打实的好处：换电脑能拉到最新代码、本地误删了还能从远程找回、将来要协作也方便。

注册账号后先建一个仓库，仓库名一般用一个有含义的英文单词，比如记账项目就叫 account 之类。这里有个关键点：仓库务必选"私有"，选了开源的话所有人都能看到你的代码。

私有仓库在拉取/推送时会要求验证身份，但用的不是平台的登录密码，而是一个叫"私人令牌"的东西。在平台的设置里生成一个新令牌，把用不到的权限取消勾选，生成后立刻复制保存好（建议先粘到 Notepad++ 里），因为有些平台关闭弹窗后就再也看不到完整令牌了。之后在命令行里克隆代码，输入用户名和这个令牌，就能把私有仓库拉到本地。

用分支管理，让每次尝试都"可回退"

Git 最香的功能之一是分支。你可以把分支理解成"代码的平行宇宙"：在主线之外开一条分支去尝试某个功能或修某个 bug，失败了直接切回原分支，主线代码一点都不会被污染；成功了再合并回去。

我自己的习惯是：每开发一个新功能就新建一个分支，命名带上版本号和功能描述，方便日后追溯。常用命令就这么几条：

# 在当前分支基础上创建并切换到新分支
git checkout -b v1.0.0-1-bottom-nav

# 查看当前所在分支
git branch

# 暂存所有改动
git add .

# 提交本次改动，写清楚改了什么
git commit -m "底部导航栏功能开发"

# 推送到远程仓库
git push

提交信息（commit message）一定要写人话，比如"修复登录 bug""账本管理功能开发"，别图省事写一堆没意义的字符。等你功能多了、回头要找某次改动时，清晰的提交记录就是你的救命稻草。

用 AI 编程工具的好处是，这些 Git 操作大多有图形化界面可以点，但理解背后的逻辑——为什么要分支、提交信息为什么要写清楚——比记住按钮在哪更重要。莫潇羽@无忆研习社这边吃过亏：早期偷懒不开分支、提交信息乱写，后面想回退时一脸懵，后来老老实实按分支管理，整个开发节奏稳了非常多。

第六章 项目初始化：先把客户端和服务端的骨架立起来

环境、服务器、仓库都备好了，现在正式进入项目本身。这一步是把客户端和服务端两套代码的"空架子"先搭出来，后面所有功能都往这两个架子里填。

客户端：用跨端框架，一套代码发多个平台

客户端我选了一个基于 uni-app 生态的跨端框架（uni-app 系列的工程化模板）。它最大的价值是"一套代码、多端发布"：你只写一份代码，就能同时发到微信小程序、支付宝小程序、H5 网页、甚至打包成 App。对个人开发者来说，这意味着省下维护好几套代码的时间和精力。

创建项目时会让你选几样东西，我的选择和理由是这样的：

创建完进入项目目录，用 pnpm 装依赖、再启动一个 H5 调试服务，就能在浏览器里看到客户端跑起来了：

# 进入客户端目录
cd account

# 安装依赖（pnpm 比 npm 更省磁盘、更快）
pnpm install

# 启动 H5 调试
pnpm dev:h5

启动后浏览器打开默认端口（常见是 9000 这类），按 F12 切到手机模式，就能看到移动端的界面效果了。

服务端：交给 AI 智能体来搭

服务端用的是 express。这部分我没有手写，而是直接把需求丢给 AI 智能体，让它来搭骨架。具体做法是：在项目根目录下分别建好客户端、服务端两个文件夹（比如 account-client 和 account-backend），然后在 AI 智能体里新建任务，把当前情况和要求一次性说清楚。

我当时给它的要求大致是这样几条：用国产大模型来完成、集成 MySQL、用 TypeScript、设计一个基础登录功能、处理好登录跳转逻辑、把可变的东西抽成配置文件，最后让它把没想明白的地方列出来好让我补充。AI 会反过来问你几个关键问题，比如短信验证码用第三方还是模拟、token 方案用哪种、验证码有效期怎么设——你顺着回答，它就能生成一份相当详细的设计文档。

sequenceDiagram
    participant 我 as 开发者
    participant AI as AI编程智能体
    participant 项目 as 项目代码
    我->>AI: 描述需求 + 提出要求
    AI->>我: 反问若干关键决策点
    我->>AI: 逐条回答
    AI->>项目: 生成设计文档
    我->>AI: 确认采纳
    AI->>项目: 按文档自动写代码
    我->>项目: 启动验收

这套"先让 AI 出文档、我确认、再让它写代码"的协作方式，是整篇文章最核心的工作模式，请一定记牢。它的好处是把"AI 自由发挥导致跑偏"的风险大大降低了——你在文档环节就能把方向纠正过来，而不是等它写了一大堆代码才发现不对。

第七章 AI 智能体到底怎么帮你写功能：以登录注册为例

这一章我们把"指挥 AI 写一个完整功能"完整演一遍。登录注册是几乎每个软件都要有的功能，拿它当例子最合适。

提示词不用写得复杂，但要把"现状"和"要做什么"说清楚

很多人以为指挥 AI 要写很长很玄的提示词，其实不必。我的经验是：把项目当前现状描述清楚，再把这次要做什么讲明白，剩下的交给 AI。比如做登录注册，我会先告诉它"当前已有前后端骨架代码、还没有任何业务功能"，再说"现在要做一个手机号 + 短信验证码的登录注册"，然后把几个关键决策点定下来。

短信这块要特别说一下，它直接关系到合规。开发阶段当然用模拟短信——验证码不真发，直接打印在服务端控制台里，方便自测。但正式上线必须接正规的第三方短信服务（比如阿里云短信）。我让 AI 把两种方式都实现，并在配置文件里加一个开关来切换：

# 配置文件里用一个标记切换短信服务
SMS_PROVIDER=mock        # 开发阶段：模拟短信，验证码打印到控制台
# SMS_PROVIDER=aliyun    # 生产阶段：走阿里云短信，真实发送

合规要点：正式对用户发短信，必须使用持牌的短信服务商，并提前在其平台申请好签名和模板、通过审核。验证码类短信要写明用途和有效期（例如"验证码 5 分钟内有效，请勿泄露"），这是国内短信合规的硬要求，不能图省事用来路不明的发送渠道。

token、软删除这些概念，顺手了解一下

AI 生成的登录逻辑里会用到 JWT（一个用于校验用户身份的字符串）。它的原理是：登录成功后服务端发一个加密字符串给客户端，之后客户端每次请求都带着它，服务端用自己的密钥校验这串是不是自己签发的。所以这个密钥（secret）一定要用随机、无规律的字符，而且不能泄露——泄露了别人就能伪造登录。生产环境里，我会把模板里给的示例密钥换成随机长字符串，并把 token 有效期设长一点（移动端常设 30 天），免得用户频繁掉线。

还有个词叫软删除：删数据时并不真的从数据库里抹掉，只是打个"已删除"的标记，界面上看着没了，数据其实还在，方便日后追溯。这是个很实用的设计，AI 默认就会帮你这么做。

给 AI 立"规矩"：用规则文件约束它

光靠每次提示词还不够，更省心的做法是给项目配规则文件（rules）。规则就是你对 AI 的长期约束——告诉它项目用什么框架、什么代码风格、有哪些约定，这样就不用每次对话都重复交代一遍。

我一般会建几类规则：服务端规则、客户端规则、一条与语言框架无关的通用规则，再加一条"始终生效"的规则。这些规则本身也可以让 AI 帮你根据现有代码总结生成。我个人特别看重那条始终生效的规则，内容很朴素，但极其好用：

# always 规则（始终生效）
修改代码时务必确认：不要改动无关的代码和逻辑，
严格按照本次要求来修改，不要自作主张扩大改动范围。

这条规则是我用 AI 写代码踩坑踩出来的。早期不加这句，AI 经常顺手把我没让它动的代码也改了，越改越乱。加上之后，它的改动收敛了很多。如果你不想专门建规则文件，至少把这句话每次贴在提示词最后。

报错了怎么办？把错误原样丢回给 AI

新手最怕看到满屏报错。我的处理方式简单到有点反直觉：直接把报错信息复制下来，原样丢回给 AI，让它分析原因并修复。比如登录后首页拿不到用户信息、退出按钮点了没反应，我就把控制台的报错粘给它，再补一句现象描述，它基本都能定位并改好。

flowchart LR
    A[功能跑出报错] --> B[复制报错信息]
    B --> C[原样发给 AI + 描述现象]
    C --> D[AI 分析原因并修复]
    D --> E{重启后还报错?}
    E -->|是| B
    E -->|否| F[功能通过]

这个"报错—回喂—修复"的循环，会贯穿你整个开发过程。重要的不是你自己会不会修，而是你能把现象和错误信息准确地转述给 AI。能把问题说清楚，本身就是一种很值钱的能力。

登录注册做完后记得提交代码、推到远程仓库。从这一刻起，你已经体验到那种"自己只负责想和验收、写代码的脏活累活全交给 AI"的开发方式了。莫潇羽在无忆研习社里常说，这种角色的转变，才是 AI 时代普通人最该抓住的红利。

第八章 按需求文档，把业务功能一个一个做出来

登录注册只是开胃菜。真正能提供给用户用的，是一个个具体的业务功能。这一章讲的是我怎么用一套固定流程，把记账小程序的所有业务模块稳稳地做出来。

先想清楚"最小可行产品"是什么

动手做功能前，我会先让 AI 帮我理一份需求。这里要引入一个特别重要的概念——最小可行产品（MVP），意思是：至少要做出哪些功能，才能把东西交到用户手里用起来。

拿记账软件举例，光有一个"记一笔"是不够用的，至少得有：记账、明细查询、简单的统计。MVP 的价值在于帮你快速验证想法——别一上来就憋大招，先把能闭环的核心功能做出来跑通，后面再一个版本一个版本地迭代。我自己做产品就一直遵循这个原则，做得越轻、上线越快，验证想法的成本就越低。

理清 MVP 后，我让 AI 把功能点整理成一份需求文档，放在项目里。整理出来后我发现一个细节问题：文档里把"业务功能"和"通用要求"混在一起了——账本管理、记账这些是具体功能，而"性能要求"这种其实是约束而非功能。于是我让 AI 重新区分，分成"业务功能需求""通用功能需求""通用开发要求"三块，并把最先要做的底部导航栏放到最上面，整份文档就成了后续开发的清晰蓝图。

一套流程，反复套用在每个模块上

有了需求文档，每个功能我都用同一套流程来做，熟练之后非常顺手：

flowchart TD
    A[在需求文档里定位本次要做的模块] --> B[用规划模式生成详细开发文档]
    B --> C[我浏览确认, 核对功能点是否对]
    C --> D[采纳, 让 AI 自动执行开发]
    D --> E[启动项目验收功能]
    E --> F{有报错或缺陷?}
    F -->|是| G[把报错/需求回喂给 AI 修复]
    G --> E
    F -->|否| H[新建分支提交代码, 推远程]
    H --> A

提示词依然写得很简单——因为详细需求都在文档里了，我只要告诉它"这份文档从上往下开发，现在做到第几个模块，前面的已完成，参照文档做详细设计并实现"就够了。底层那些设计细节、接口、数据库表，AI 会基于文档自己补全。

实际开发中有几个经验值得分享。一是功能做完了界面上可能没入口，比如分类管理做好了，"我的"页面里却看不到进去的按钮，这时再让 AI 把入口加到合适的位置即可，记得强调"只改样式、别改原有功能逻辑"。二是报错很正常，别慌，按上一章说的循环把错误丢回给 AI 就行，有时候报错的根因是开发过程中代码被意外复制了一遍导致重复声明，AI 也能自己排查出来。三是每做完一个模块就新建分支、提交、推远程，养成习惯后回退和追溯都很轻松。

记账小程序的几个核心模块

按这套流程，我把记账小程序的业务模块依次做了出来，它们之间是有依赖顺序的：

这里挑两个点细说。账目记录是核心，包含记账和明细两个页面：记账页能切账本、切收支类型、填金额、选分类、选日期、写备注；明细页按周/月/年维度展示账目，点进去能看详情、能编辑、能删除。我做的时候按"记一笔支出、再记一笔收入、编辑、切换账本、删除"挨个测了一遍，确认闭环没问题才提交。统计分析则依赖账目数据——有了记账记录才好做分析，所以它必须排在记账之后做，首页展示当前账本的本月收入、支出、余额，并支持按分类统计、按时间筛选。

做这些模块时还有一个我自己很在意的细节：新手友好。比如"软删除"这种术语，第一次出现就用一句白话解释清楚；界面设计不合理的地方（比如三个按钮孤零零摆着、头像下方直接显示手机号），我会让 AI 改成更符合常见 App 习惯的卡片+列表样式。这些打磨看似琐碎，但决定了产品给人的第一印象。莫潇羽@无忆研习社这边的体会是：AI 能帮你把功能快速堆出来，但"哪里别扭、哪里要改"得靠你这个产品负责人来把关。

第九章 上线前的"门面"：取名、图标、域名

功能差不多了，接下来要给产品装点门面——名字、图标、域名。别小看这三样，它们直接影响用户对你产品的第一印象，也关系到后面能不能被搜到。

取名：要有"互联网感"，还要适合 SEO

软件名字是产品气质的第一印象。这事没有标准答案，我结合自己的经验总结两个原则供你参考。

第一是要有互联网感：好记、易传播、有"网感"。前两点好理解，"网感"得自己多体会，简单说就是念起来顺、记得住、容易让人联想到你的产品。第二是要适合 SEO（搜索引擎优化），也就是让用户搜索时更容易找到你、排得更靠前。这就要求名字里的关键词别太普通。举个反例：如果叫"生活记账"，用户搜这四个字时，大概率被一堆同名页面淹没，连搜你自己的名字都搜不到。所以一定避开太大众的词。

具体操作上，我会把这两个原则告诉 AI，让它一口气给 20 个候选名，再拿这些名字去搜一搜，看有没有被人用过。比如动物 IP 类的名字往往又好记又有网感，挑一个没被占用的就能用。给软件改名很简单，在代码里搜到应用名称那几处文字，替换掉保存即可。

图标：会用工具，自己也能做出能看的图标

预算充足的话直接付费找设计是最省心的，但太便宜的外包没必要——他们很多也是用 AI 随手出图。想自己做的话，分享一个我常用的路子：先去图标素材网站（比如 iconfinder 这类）按关键词找灵感，找到合适的卡通或线条图标，再用在线设计工具（比如可画/Canva）把它放进图标画布里，导出透明背景的 SVG 格式，替换掉项目里原