在AI技术飞速发展的今天，编程领域也迎来了重大变革。本文作者通过亲身实践，仅用两小时就借助Cursor开发了一款查八字的微信小程序，从需求分析到最终上线，全程记录并详细分享了开发过程中的每一个步骤和心得，希望能帮到大家。

说实话，写这篇文章的时候，我是有些犹豫的，由一个程序员来写总归会让人觉得有些假。

但又恰恰在某些方面显得有些真，至少站在客观现实的角度来分析当下的 AI 编程是否真如传说中那么牛逼。

当然还有最重要的是，有小伙伴真的需要这一份教程。

为了突出 AI 编程的本质，我先是将脑袋里的编程理论抽空，然后把自己当做一个没有任何编程经验的小白。

最后，用了 2 个小时，完成了一个微信小程序从 0 到 1 的开发。

这是最终的效果：

虽说是 2 小时，但也是凭借我多年的编程经验，给了 Cursor 一堆的提示，才有的结果。

所以，接下来，我会带你沉浸式感受下我这 2 个小时的历程，全程记录，做到无死角输出，让任何一个无编程经验的小白也能轻松复刻。

并且全程提示词及纠错过程都将会展现。讲真，开发 2 小时，写教程一天，不是瞎说的。

文章会同步更新到我的AI 开源知识库，记得收藏！

全文 11353 字，51 张图，如果喜欢，不妨赏赐个赞。

这是一个整体的流程，也是模拟的企业级软件开发必要的关键步骤：

所以这次，我的期望值是很高的，我希望他能真正充当起工程师，而非实习生。最后。。。还是放到最后说吧。

相比直接让 AI 写代码，我加入了一些前置的需求设计相关工作，目的也是为了让他能充分了解我们的需求和业务，避免开发出来的东西出入过大。

整个思路是这样的：

有前端，有后端、有小程序、还有 DeepSeek 等大模型的使用，可以说麻雀虽小，基本五脏俱全了。

B端究竟需要什么样的产品经理？

B端产品经理都是以提升供应侧的工作效率为目的，所以B端需求主要是以业务问题为导向。 这个是B端产品比较重要的一点，B端产品是服务于一个主体 ...

查看详情 >

下面每个步骤我们来做下拆解（呼！）

01 灵感搜集

不瞒你说，一开始还真不知道要开发什么功能的小程序，太复杂肯定不行，实验肯定进展不顺利，太容易也不行，一个静态页面玩玩没啥意思。

没有灵感没关系，先问下 Grok 3：

好家伙，还真找到个实用又好玩的功能点，那就是查八字。

根据阳历出生日期的日期及出生时辰，自动计算农历日期、天干地支、所属五行、五行缺啥、所属生肖等。

这可是个刚需，几乎人人都需要，而且也利于传播。

所以我打算搞个完全由 AI 开发的八字查询小助手，对标参考小程序：查生辰。

ps：整个灵感的搜集，我仅仅用了 2 分钟，不得不说 AI 可真能天马行空。

02 需求分析

有了灵感后，第一步当然是对整个需求进行分析，值不值得做？实现难度如何？市场反馈怎样？

这一步通常会由产品经理或者市场来负责，但作为一个 AI，他可别想偷懒，都得给我干。

先提问 DeepSeek：

我想开发一个微信小程序，他主要功能是：“根据阳历出生日期及出生时辰，自动计算农历日期、天干地支、所属五行、五行缺啥、所属生肖等。用户只需要填入阳历出生日期及出生时辰即可，系统会自动调用 DeepSeek 的 API 来推理出需要的信息”。请帮我作为产品经理进行一下需求的分析，并给我输出需求分析报告。

DeepSeek 哗啦啦的就输出一堆。

忘记了，我是在 Cursor 中开发，不想复制来复制去，麻烦，那直接都去 Cursor 操作吧。

首先在 Cursor 中得有个空白的项目吧。

好，在 Cursor 中新建一个一个项目。就叫 wechat-mini 吧。

完了装逼一下，稍微修改提示词为：

我想开发一款微信小程序，主要功能是：

• 用户输入阳历出生日期和出生时辰，系统自动计算：

• 对应的农历日期

• 天干地支

• 所属五行

• 五行缺失情况

• 所属生肖

• 系统调用 DeepSeek API 进行推理，生成相关信息。

请你作为产品经理，对该小程序进行需求分析，并输出一份**详细的需求分析报告**，包括但不限于：

1.**产品概述**（介绍产品的核心功能和目标用户）

2.**用户需求分析**（目标用户群体、使用场景、核心需求）

3.**功能需求**（详细拆解功能点、输入输出、API 交互方式等）

4.**关键业务流程**（示例：用户输入数据 -> API 计算 -> 结果展示）

5.**开发周期**（建议的开发计划、MVP 版本优先级）

6.**商业模式**（是否有付费功能、盈利方式）

帮我将需求分析报告写在 mrd. md 里面。

直接丢进 Cursor：

噼里啪啦，一顿操作，给我输出完了，嗯，我看了下说是要 2-3 周开发完。你在逗我呢？我只能给你 2 小时，给我干。

03 产品 PRD 文档

有了需求分析，接下来应该是 AI 产品经理来输出需求文档（也就是 PRD 文档）了。

这是我给的提示词是：

接下来根据需求分析，按照最小 MVP 的版本，帮我写一份专业的产品需求（PRD）文档，我会给你三张参考小程序设计图，请参考我给你的图片帮我完成需求文档。并输出到 prd. md 中。

把对标的产品图片直接丢给他。

不到2 分钟，一份 2000 字的 PRD 文档就已经全部生成，稍微看一眼，然后狠狠的点击接受。

这个过程如果发现有和自己设计初衷不符的一定要提前揪出来，不然后面改需求，很坑爹的

04 产品原型

有了需求文档，就得画产品原型了吧，还记得之前有分享过让 claude 3.7 制作产品原型的提示词吧。

这不用上了，哈哈哈。

稍微针对性做个更改，下面是提示词：

你是一位全栈工程师，同时精通产品规划和 UI 设计。

请根据产品 PRD 文档帮我输出完整的小程序原型图，请通过以下方式帮我完成小程序所有原型图片的设计。

1、按照 PRD 文档要求以及我给你的图片参考来设计最小 MVP 版本

2、以产品经理的视角结合 PRD 文档去设计页面和交互；

3、作为设计师思考这些原型界面的设计，并以设计师的视角去输出完整的 UI/UX；

4、使用 html 在一个界面上生成所有的原型界面，文件命名为: prototype. html，可以使用 FontAwesome 等开源图标库，让原型显得更精美和接近真实

5、我希望这些界面是需要能直接拿去进行开发的

丢进 Cursor，生成这样了，一定是哪里有问题，OK，你直接和 Cursor 说吧。

让他把背景图换一下。

页面的中国风亭子去掉，整个页面以我给你的图片为背景

有问题，提需求，继续让他生成。

1、整体背景并没有按照我给的图片做底图背景

2、右上角多了一个视频样式的图标，要去掉

3、结果展示页中底部那个是广告展示页，前期先不放广告，合理布局。 请重新按照要求生成。

经过调整，以及将垫图直接放在文件目录下并命名为：background. jpg

这里因为给了参考的图片且是截图的，难免会有些不准，也可以直接让 AI 不参考。

这是最终的效果：

一番调整花费了我5 分钟，总算输出个还不错的页面了。

05 架构设计

接下来需要指定开发规范、语言等来让他帮我们输出架构设计文档。这个提示词很重要。

这个地方就很考验提示词，如果不框定一些东西，AI 生成的连他妈都不认识，哈哈哈。

请依据 prototype. html、prd. md 来进行微信小程序的整体架构设计，注意我希望整体前端使用的是 uniapp，后端使用的 java 来开。

1、整体满足微信小程序的开发规范。

2、前端按照原型设计来开发，后端我希望满足阿里巴巴开发编码规范，遵守 rest 风格的接口公约，且后端主要提供一个计算的接口，返回前端需要的参数，

3、后端具体计算的逻辑，我希望是能直接通过调用 DeepSeek 的 API 来获得信息，然后转换为对应的接口字段，最终返回给前端。

请帮我输出架构设计文档到 architecture. md

大概5 分钟后，一顿输出，这个架构文档，嗯，我给打个 6 分吧，因为功能真的不难，没有过多系统间的交互。

不过你看整体有系统架构图，技术选型：

前端项目结构、页面组件设计等：

当然还有后端项目结构以及接口设计。

该说不说，还是很详细了。

06 开发阶段

下面就进入正式开发阶段了，这也是最激动人心的时候，我是真生怕 AI 做的不好，又怕他做的太好，所以忐忑的不行。

给个简单却信息十足的提示词：

@architecture. md 请帮我根据架构设计文档、需求文档以及原型图进行代码的开发，请注意，前后端项目结构是分离的，严格按照架构设计文档来开发。

这里一定要选择 claude 3.7 的 Agent 模式，他才能发挥出最佳的实力。

他先问你要不要创建目录文件夹，当然要啊，名字自己改呗：

接下来创建后端项目结构。点击继续就好了。

接下来是创建前端项目结构。同样点击继续。

只需要不断点击 next file 即可。

当然你也可以不用管他，等一会后。

在第 25 次工具调用后会停下来，你点击继续就好了。

注意：我们默认在 25 次工具调用后停止代理。你可以继续谈话了。

后端代码编写好后，他会停下来，接下来，你只需要继续提示：

请帮我继续完善前端代码，要求与后端能顺利的通信

一步步看着他全自动帮我生成好了。

整个过程预计持续15 分钟左右，中间还因为网络问题停了，我只要和老板一样签签字，不对，是点点鼠标就行了，中途大概点了十几次鼠标吧。（嗯，这一度让我很享受！）

07 后端功能验证

你看，经过前面的几个设计到开发的步骤，实际耗时只用了半小时左右，但具体代码有没有问题？能不能直接使用呢？

我们来验证下，先是后端验证，这一过程一度让我崩溃，因为 AI 写的考虑也是不够周到的，不过也能理解吧，毕竟一次性输出这么多代码。

为了看下能否启动，我在 idea 中打开代码，然后启动（当然你直接在 Cursor 中也没关系。）

在 idea 中先打开项目，将依赖拉取一下。

呕吼，报错了。

没关系，回到 Cursor 让他改。

后来我发现在 idea 中还是太多问题，直接在 Cursor 中让他自己改好吧。

自己一顿操作修改终于好了。（中途我一顿确认和点击，虽然全程没写代码，但我指挥的可不算少了）

这里有个插曲，我本来想用 DeepSeek 的 API，但余额用完了，而且由于 DeepSeek-r 1 推理模型非流式过慢，刚好我的火山还有余额，所以这里直接换成用豆包 lite 模型，速度会快上很多。

另外关于模型快慢情况以及首 token 相应情况也咨询了字节的同学：

我们lite系列的模型速度会快些，pro系列的模型速度与deepseek模型是差不多的哈。

这里给您介绍下通常模型输出“慢”可能会由哪些原因导致：

1. 与输出方式有关：看使用的是”流式输出”还是”非流式输出”由接口中参数 stream 决定， 非流式输出会等整个的推理过程全部完成才返回，会带来一种生成很慢的感觉；如果是聊天类应用的话，流式输出用户体验会更好，像豆包一样一字一句实时输出。

2. 与模型有关：不同的模型大小有差异，能力也不同，Doubao-pro 相对 Doubao-lite 会慢一些，客户需要按照实际业务需求（模型精度、上下文长度等）挑选适合的模型。

3. 与用户输入的 prompt 长度有关：如果用户输入的 prompt 本身就上千甚至上万 tokens ，对应生成首 token 阶段（prefill phase 或 context phase）耗时也会长一些。

TTFT (Time To First Token) 均值速度可参考：

lite 32k 模型每 1k token 的输入 ，耗时 300±100ms，并且是线性增长的，比如 1k token 300ms，5k token 就是5*300ms = 1500 ms；

pro 32k 模型每 1k token 的输入，耗时 600±100ms ，也是线性的增长的，比如 1k token 600ms，5k token 就是5*600ms = 3000 ms；

4. 与模型输出内容的长度有关：如果用户的任务需要生成比较长的文本内容，则在 Decode 阶段耗时也会比较长。

TPOT (Time Per Output Token) 均值速度可参考：

doubao lite系列 输出在 20-50 ms / token

doubao pro系列 输出在 50ms-100ms / token

PS：1 个 token 约等于 1.5 个汉字

5. 偶发情况和后端资源影响

———

基于上面的结论，模型的完整返回耗时是与模型生成的tokens和输入的tokens直接相关的，r1模型因为有思维链的产出，所以输出tokens是会比其他模型更多些，非流式情况下完整返回的耗时也会更久些。

最终调整后，速度快多了。

后端功能验证花费将近 40 分钟。

08 接口联调

后端 OK 后，直接在 Cursor 中进行接口联调，也就是前端调用后端能不能走通整个流程，这一步很关键。

联调了一段时间，他说 OK 了。

这里后端有些调整 Cursor 还不大完美，我直接 idea 中看完后给他调整。这里会给到 Cursor 一些小的提示，让他少走弯路，发现下来，对后台代码的整体把控能力还是差了些。

联调的过程大概花费 15 分钟。

09 小程序调试

前后端代码都写完了，接下来需要用到一个工具：打开微信开发者工具。

直接搜索就可以下载，使用也非常简单，都是中文，下载完了后打开工具。

选择导入项目：

选择我们的项目 bazi-frontend：

选择 appid，这里没有的话需要注册一个。（注册页比较简单，不过后面会再细说说）

一开始首页没有正常渲染，后面我在 Cursor 中给了提示词让他快速就改好了。

点击下验证功能。

我们选择一个时间来看看。

计算失败了：

没关系，看下报错原因：

本地调试，域名校验这个先关了：

看样子是成功了：

我们看下有没有正常请求到后端服务：

可以看到，正常请求，且正常返回数据：

不过这个展示样式有些丑。让他改下吧。

上传一张截图，然后给以下提示词：

看到返回结果这个页面中的结果有点太靠右边了，请保持离右边一定的间距

你可以直接将这个你不满意的图上传给他：

经过一番改造，基本完工，这一步骤预计耗时：

10. 手机测试

在开发工具测试完毕后，需要手机真机测试，这里就有一些坑在了，比如点击预览如果不开开发模式的话，需要进行域名验证，这个会比较麻烦。

我们先点击预览：

会出现二维码：

但是因为本地的服务没有发布到线上，所以就没法使用服务，要服务上线。

不过功能已经通了。

所以需要上线服务。上线的意思就是将自己本地的服务发布到服务器，当然你也可以本地跑，但是需要将域名暴露出去，且要经过 SSL 验证，

不管他，我先在服务器中跑吧：

需要配置微信小程序的可信域名：

在小程序后台——开发与服务-开发管理-服务器域名，配置自己的域名。

如果没有域名，要申请+备案，这是一个很麻烦的过程，所以对小白并不友好，因为有前后端的交互，这一步不能少，如果是纯前端代码就无需这一步。

现在需要将小程序链接域名修改为线上的域名，直接让他改，提示词：

我现在已经将后端服务部署在了我的服务器，域名是XXX，端口号改为了XXX，请帮我前端改下配置，让他连接线上环境.要求本地环境和线上环境区分开来

报了一个错，跨域啦，直接丢给 Cursor

直接帮我解决好：

重新打包，重新部署后端服务看看。

又遇到一个 https 的错误，需要有一个 https 的域名，然后指向自己的服务，

这里花了一点时间。

手机再预览看看效果：

这里特别注意：要想直接预览，需要配置 https 证书，且在后台配置域名，这里需要配置子域名，不能配置顶级域名。

这一步还挺花费时间的，预计 20 分钟，当然如果没有编程经验，时间就更不好说了。

一切已经 OK 了，在手机上也能正常预览，接下来就只需要发布上线了，不过这个时候可以用体验版给大家演示使用。

上面所有步骤加起来耗时大概是这样的：30+40+15+15+20=120 分钟=2 小时。大家可以自行感受一下。

现在已经可以体验啦，不过需要开通体验权限，你可以点击文末阅读原文加入体验哦。

11. 发布上线

根据工信部于 2023 年 8 月发布的《关于加强移动互联网应用程序备案管理工作的通知》，对于未上架的微信小程序，自 2023 年 9 月 1 日起，必须在提交上线审核前完成备案，否则无法通过审核；

这一部分就先不哔哔了，发现已经 1 万 3 千多字了，肝不动了，小命要紧，下次再更。

不过一顿体验下来，有惊喜也有失望。

惊喜的是，我真的全称没写一行代码2小时就快速开发了一个小程序，要知道，换做以前，不敢想象的。

失望的是，目前体验来看，AI写出的前端代码还OK，但后端技术就不大行了，也可能是后端需要更复杂的逻辑，所以提示词要更精准一些。

在整个过程中，写代码其实花了也就半小时，但更多的时间都是用来解决这货产生的bug，哈哈哈，所以得出一个结论。

目前的 AI 编程确实还只是实习生水平。

不过，这已经很惊艳了，人人都能开发应用的时代很快就会到来，这一天，你期待吗？