在AI技術(shù)飛速發(fā)展的今天，編程領域也迎來了重大變革。本文作者通過親身實踐，僅用兩小時就借助Cursor開發(fā)了一款查八字的微信小程序，從需求分析到最終上線，全程記錄并詳細分享了開發(fā)過程中的每一個步驟和心得，希望能幫到大家。

說實話，寫這篇文章的時候，我是有些猶豫的，由一個程序員來寫總歸會讓人覺得有些假。

但又恰恰在某些方面顯得有些真，至少站在客觀現(xiàn)實的角度來分析當下的 AI 編程是否真如傳說中那么牛逼。

當然還有最重要的是，有小伙伴真的需要這一份教程。

為了突出 AI 編程的本質(zhì)，我先是將腦袋里的編程理論抽空，然后把自己當做一個沒有任何編程經(jīng)驗的小白。

最后，用了 2 個小時，完成了一個微信小程序從 0 到 1 的開發(fā)。

這是最終的效果：

雖說是 2 小時，但也是憑借我多年的編程經(jīng)驗，給了 Cursor 一堆的提示，才有的結(jié)果。

所以，接下來，我會帶你沉浸式感受下我這 2 個小時的歷程，全程記錄，做到無死角輸出，讓任何一個無編程經(jīng)驗的小白也能輕松復刻。

并且全程提示詞及糾錯過程都將會展現(xiàn)。講真，開發(fā) 2 小時，寫教程一天，不是瞎說的??。

文章會同步更新到我的AI 開源知識庫，記得收藏！

全文 11353 字，51 張圖，如果喜歡，不妨賞賜個贊????。

這是一個整體的流程，也是模擬的企業(yè)級軟件開發(fā)必要的關鍵步驟：

所以這次，我的期望值是很高的，我希望他能真正充當起工程師，而非實習生。最后。。。還是放到最后說吧。

相比直接讓 AI 寫代碼，我加入了一些前置的需求設計相關工作，目的也是為了讓他能充分了解我們的需求和業(yè)務，避免開發(fā)出來的東西出入過大。

整個思路是這樣的：

有前端，有后端、有小程序、還有 DeepSeek 等大模型的使用，可以說麻雀雖小，基本五臟俱全了。

什么是B端产品经理？和C端产品经理有什么区别？

B端产品经理中的B是Business，商业的意思，B端产品经理首先就要理解这个职位的重要性，要设计出更适合这个项目需求的产品方案，B最终产品经理在日常工作中...

查看详情 >

下面每個步驟我們來做下拆解（呼！）

01 靈感搜集

不瞞你說，一開始還真不知道要開發(fā)什么功能的小程序，太復雜肯定不行，實驗肯定進展不順利，太容易也不行，一個靜態(tài)頁面玩玩沒啥意思。

沒有靈感沒關系，先問下 Grok 3??：

好家伙，還真找到個實用又好玩的功能點，那就是查八字。

根據(jù)陽歷出生日期的日期及出生時辰，自動計算農(nóng)歷日期、天干地支、所屬五行、五行缺啥、所屬生肖等。

這可是個剛需，幾乎人人都需要，而且也利于傳播。

所以我打算搞個完全由 AI 開發(fā)的八字查詢小助手，對標參考小程序：查生辰。

ps：整個靈感的搜集，我僅僅用了 2 分鐘，不得不說 AI 可真能天馬行空。

02 需求分析

有了靈感后，第一步當然是對整個需求進行分析，值不值得做？實現(xiàn)難度如何？市場反饋怎樣？

這一步通常會由產(chǎn)品經(jīng)理或者市場來負責，但作為一個 AI，他可別想偷懶，都得給我干。

先提問 DeepSeek：

我想開發(fā)一個微信小程序，他主要功能是：“根據(jù)陽歷出生日期及出生時辰，自動計算農(nóng)歷日期、天干地支、所屬五行、五行缺啥、所屬生肖等。用戶只需要填入陽歷出生日期及出生時辰即可，系統(tǒng)會自動調(diào)用 DeepSeek 的 API 來推理出需要的信息”。請幫我作為產(chǎn)品經(jīng)理進行一下需求的分析，并給我輸出需求分析報告。

DeepSeek 嘩啦啦的就輸出一堆。

忘記了，我是在 Cursor 中開發(fā)，不想復制來復制去，麻煩，那直接都去 Cursor 操作吧。

首先在 Cursor 中得有個空白的項目吧。

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

完了裝逼一下，稍微修改提示詞為：

我想開發(fā)一款微信小程序，主要功能是：

? 用戶輸入陽歷出生日期和出生時辰，系統(tǒng)自動計算：

? 對應的農(nóng)歷日期

? 天干地支

? 所屬五行

? 五行缺失情況

? 所屬生肖

? 系統(tǒng)調(diào)用 DeepSeek API 進行推理，生成相關信息。

請你作為產(chǎn)品經(jīng)理，對該小程序進行需求分析，并輸出一份**詳細的需求分析報告**，包括但不限于：

1.**產(chǎn)品概述**（介紹產(chǎn)品的核心功能和目標用戶）

2.**用戶需求分析**（目標用戶群體、使用場景、核心需求）

3.**功能需求**（詳細拆解功能點、輸入輸出、API 交互方式等）

4.**關鍵業(yè)務流程**（示例：用戶輸入數(shù)據(jù) -> API 計算 -> 結(jié)果展示）

5.**開發(fā)周期**（建議的開發(fā)計劃、MVP 版本優(yōu)先級）

6.**商業(yè)模式**（是否有付費功能、盈利方式）

幫我將需求分析報告寫在 mrd. md 里面。

直接丟進 Cursor：

噼里啪啦，一頓操作，給我輸出完了，嗯，我看了下說是要 2-3 周開發(fā)完。你在逗我呢？我只能給你 2 小時，給我干。

03 產(chǎn)品 PRD 文檔

有了需求分析，接下來應該是 AI 產(chǎn)品經(jīng)理來輸出需求文檔（也就是 PRD 文檔）了。

這是我給的提示詞是：

接下來根據(jù)需求分析，按照最小 MVP 的版本，幫我寫一份專業(yè)的產(chǎn)品需求（PRD）文檔，我會給你三張參考小程序設計圖，請參考我給你的圖片幫我完成需求文檔。并輸出到 prd. md 中。

把對標的產(chǎn)品圖片直接丟給他。

不到2 分鐘，一份 2000 字的 PRD 文檔就已經(jīng)全部生成，稍微看一眼，然后狠狠的點擊接受。

這個過程如果發(fā)現(xiàn)有和自己設計初衷不符的一定要提前揪出來，不然后面改需求，很坑爹的??

04 產(chǎn)品原型

有了需求文檔，就得畫產(chǎn)品原型了吧，還記得之前有分享過讓 claude 3.7 制作產(chǎn)品原型的提示詞吧。

這不用上了，哈哈哈。

稍微針對性做個更改，下面是提示詞：

你是一位全棧工程師，同時精通產(chǎn)品規(guī)劃和 UI 設計。

請根據(jù)產(chǎn)品 PRD 文檔幫我輸出完整的小程序原型圖，請通過以下方式幫我完成小程序所有原型圖片的設計。

1、按照 PRD 文檔要求以及我給你的圖片參考來設計最小 MVP 版本

2、以產(chǎn)品經(jīng)理的視角結(jié)合 PRD 文檔去設計頁面和交互；

3、作為設計師思考這些原型界面的設計，并以設計師的視角去輸出完整的 UI/UX；

4、使用 html 在一個界面上生成所有的原型界面，文件命名為: prototype. html，可以使用 FontAwesome 等開源圖標庫，讓原型顯得更精美和接近真實

5、我希望這些界面是需要能直接拿去進行開發(fā)的

丟進 Cursor，生成這樣了，一定是哪里有問題，OK，你直接和 Cursor 說吧。

讓他把背景圖換一下。

頁面的中國風亭子去掉，整個頁面以我給你的圖片為背景

有問題，提需求，繼續(xù)讓他生成。

1、整體背景并沒有按照我給的圖片做底圖背景

2、右上角多了一個視頻樣式的圖標，要去掉

3、結(jié)果展示頁中底部那個是廣告展示頁，前期先不放廣告，合理布局。 請重新按照要求生成。

經(jīng)過調(diào)整，以及將墊圖直接放在文件目錄下并命名為：background. jpg

這里因為給了參考的圖片且是截圖的，難免會有些不準，也可以直接讓 AI 不參考。

這是最終的效果：

一番調(diào)整花費了我5 分鐘，總算輸出個還不錯的頁面了。

05 架構(gòu)設計

接下來需要指定開發(fā)規(guī)范、語言等來讓他幫我們輸出架構(gòu)設計文檔。這個提示詞很重要。

這個地方就很考驗提示詞，如果不框定一些東西，AI 生成的連他媽都不認識，哈哈哈。

請依據(jù) prototype. html、prd. md 來進行微信小程序的整體架構(gòu)設計，注意我希望整體前端使用的是 uniapp，后端使用的 java 來開。

1、整體滿足微信小程序的開發(fā)規(guī)范。

2、前端按照原型設計來開發(fā)，后端我希望滿足阿里巴巴開發(fā)編碼規(guī)范，遵守 rest 風格的接口公約，且后端主要提供一個計算的接口，返回前端需要的參數(shù)，

3、后端具體計算的邏輯，我希望是能直接通過調(diào)用 DeepSeek 的 API 來獲得信息，然后轉(zhuǎn)換為對應的接口字段，最終返回給前端。

請幫我輸出架構(gòu)設計文檔到 architecture. md

大概5 分鐘后，一頓輸出，這個架構(gòu)文檔，嗯，我給打個 6 分吧，因為功能真的不難，沒有過多系統(tǒng)間的交互。

不過你看整體有系統(tǒng)架構(gòu)圖，技術(shù)選型：

前端項目結(jié)構(gòu)、頁面組件設計等：

當然還有后端項目結(jié)構(gòu)以及接口設計。

該說不說，還是很詳細了。

06 開發(fā)階段

下面就進入正式開發(fā)階段了，這也是最激動人心的時候，我是真生怕 AI 做的不好，又怕他做的太好，所以忐忑的不行。

給個簡單卻信息十足的提示詞：

@architecture. md 請幫我根據(jù)架構(gòu)設計文檔、需求文檔以及原型圖進行代碼的開發(fā)，請注意，前后端項目結(jié)構(gòu)是分離的，嚴格按照架構(gòu)設計文檔來開發(fā)。

這里一定要選擇 claude 3.7 的 Agent 模式，他才能發(fā)揮出最佳的實力。

他先問你要不要創(chuàng)建目錄文件夾，當然要啊，名字自己改唄：

接下來創(chuàng)建后端項目結(jié)構(gòu)。點擊繼續(xù)就好了。

接下來是創(chuàng)建前端項目結(jié)構(gòu)。同樣點擊繼續(xù)。

只需要不斷點擊 next file 即可。

當然你也可以不用管他，等一會后。

在第 25 次工具調(diào)用后會停下來，你點擊繼續(xù)就好了。

注意：我們默認在 25 次工具調(diào)用后停止代理。你可以繼續(xù)談話了。

后端代碼編寫好后，他會停下來，接下來，你只需要繼續(xù)提示：

請幫我繼續(xù)完善前端代碼，要求與后端能順利的通信

一步步看著他全自動幫我生成好了。

整個過程預計持續(xù)15 分鐘左右，中間還因為網(wǎng)絡問題停了，我只要和老板一樣簽簽字，不對，是點點鼠標就行了，中途大概點了十幾次鼠標吧。（嗯，這一度讓我很享受?。?/p>

07 后端功能驗證

你看，經(jīng)過前面的幾個設計到開發(fā)的步驟，實際耗時只用了半小時左右，但具體代碼有沒有問題？能不能直接使用呢？

我們來驗證下，先是后端驗證，這一過程一度讓我崩潰，因為 AI 寫的考慮也是不夠周到的，不過也能理解吧，畢竟一次性輸出這么多代碼。

為了看下能否啟動，我在 idea 中打開代碼，然后啟動（當然你直接在 Cursor 中也沒關系。）

在 idea 中先打開項目，將依賴拉取一下。

嘔吼，報錯了。

沒關系，回到 Cursor 讓他改。

后來我發(fā)現(xiàn)在 idea 中還是太多問題，直接在 Cursor 中讓他自己改好吧。

自己一頓操作修改終于好了。（中途我一頓確認和點擊，雖然全程沒寫代碼，但我指揮的可不算少了??）

這里有個插曲，我本來想用 DeepSeek 的 API，但余額用完了，而且由于 DeepSeek-r 1 推理模型非流式過慢，剛好我的火山還有余額，所以這里直接換成用豆包 lite 模型，速度會快上很多。

另外關于模型快慢情況以及首 token 相應情況也咨詢了字節(jié)的同學：

我們lite系列的模型速度會快些，pro系列的模型速度與deepseek模型是差不多的哈。

這里給您介紹下通常模型輸出“慢”可能會由哪些原因?qū)е拢?/p>

1. 與輸出方式有關：看使用的是”流式輸出”還是”非流式輸出”由接口中參數(shù) stream 決定， 非流式輸出會等整個的推理過程全部完成才返回，會帶來一種生成很慢的感覺；如果是聊天類應用的話，流式輸出用戶體驗會更好，像豆包一樣一字一句實時輸出。

2. 與模型有關：不同的模型大小有差異，能力也不同，Doubao-pro 相對 Doubao-lite 會慢一些，客戶需要按照實際業(yè)務需求（模型精度、上下文長度等）挑選適合的模型。

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. 與模型輸出內(nèi)容的長度有關：如果用戶的任務需要生成比較長的文本內(nèi)容，則在 Decode 階段耗時也會比較長。

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

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

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

PS：1 個 token 約等于 1.5 個漢字

5. 偶發(fā)情況和后端資源影響

———

基于上面的結(jié)論，模型的完整返回耗時是與模型生成的tokens和輸入的tokens直接相關的，r1模型因為有思維鏈的產(chǎn)出，所以輸出tokens是會比其他模型更多些，非流式情況下完整返回的耗時也會更久些。

最終調(diào)整后，速度快多了。

后端功能驗證花費將近 40 分鐘。

08 接口聯(lián)調(diào)

后端 OK 后，直接在 Cursor 中進行接口聯(lián)調(diào)，也就是前端調(diào)用后端能不能走通整個流程，這一步很關鍵。

聯(lián)調(diào)了一段時間，他說 OK 了。

這里后端有些調(diào)整 Cursor 還不大完美，我直接 idea 中看完后給他調(diào)整。這里會給到 Cursor 一些小的提示，讓他少走彎路，發(fā)現(xiàn)下來，對后臺代碼的整體把控能力還是差了些。

聯(lián)調(diào)的過程大概花費 15 分鐘。

09 小程序調(diào)試

前后端代碼都寫完了，接下來需要用到一個工具：打開微信開發(fā)者工具。

直接搜索就可以下載，使用也非常簡單，都是中文，下載完了后打開工具。

選擇導入項目：

選擇我們的項目 bazi-frontend：

選擇 appid，這里沒有的話需要注冊一個。（注冊頁比較簡單，不過后面會再細說說）

一開始首頁沒有正常渲染，后面我在 Cursor 中給了提示詞讓他快速就改好了。

點擊下驗證功能。

我們選擇一個時間來看看。

計算失敗了：

沒關系，看下報錯原因：

本地調(diào)試，域名校驗這個先關了：

看樣子是成功了：

我們看下有沒有正常請求到后端服務：

可以看到，正常請求，且正常返回數(shù)據(jù)：

不過這個展示樣式有些丑。讓他改下吧。

上傳一張截圖，然后給以下提示詞：

看到返回結(jié)果這個頁面中的結(jié)果有點太靠右邊了，請保持離右邊一定的間距

你可以直接將這個你不滿意的圖上傳給他：

經(jīng)過一番改造，基本完工，這一步驟預計耗時：

10. 手機測試

在開發(fā)工具測試完畢后，需要手機真機測試，這里就有一些坑在了，比如點擊預覽如果不開開發(fā)模式的話，需要進行域名驗證，這個會比較麻煩。

我們先點擊預覽：

會出現(xiàn)二維碼：

但是因為本地的服務沒有發(fā)布到線上，所以就沒法使用服務，要服務上線。

不過功能已經(jīng)通了。

所以需要上線服務。上線的意思就是將自己本地的服務發(fā)布到服務器，當然你也可以本地跑，但是需要將域名暴露出去，且要經(jīng)過 SSL 驗證，

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

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

在小程序后臺——開發(fā)與服務-開發(fā)管理-服務器域名，配置自己的域名。

如果沒有域名，要申請+備案，這是一個很麻煩的過程，所以對小白并不友好，因為有前后端的交互，這一步不能少，如果是純前端代碼就無需這一步。

現(xiàn)在需要將小程序鏈接域名修改為線上的域名，直接讓他改，提示詞：

我現(xiàn)在已經(jīng)將后端服務部署在了我的服務器，域名是XXX，端口號改為了XXX，請幫我前端改下配置，讓他連接線上環(huán)境.要求本地環(huán)境和線上環(huán)境區(qū)分開來

報了一個錯，跨域啦，直接丟給 Cursor

直接幫我解決好：

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

又遇到一個 https 的錯誤，需要有一個 https 的域名，然后指向自己的服務，

這里花了一點時間。

手機再預覽看看效果：

這里特別注意：要想直接預覽，需要配置 https 證書，且在后臺配置域名，這里需要配置子域名，不能配置頂級域名。

這一步還挺花費時間的，預計 20 分鐘，當然如果沒有編程經(jīng)驗，時間就更不好說了??。

一切已經(jīng) OK 了，在手機上也能正常預覽，接下來就只需要發(fā)布上線了，不過這個時候可以用體驗版給大家演示使用。

上面所有步驟加起來耗時大概是這樣的：30+40+15+15+20=120 分鐘=2 小時。大家可以自行感受一下。

現(xiàn)在已經(jīng)可以體驗啦，不過需要開通體驗權(quán)限，你可以點擊文末閱讀原文加入體驗哦。

11. 發(fā)布上線

根據(jù)工信部于 2023 年 8 月發(fā)布的《關于加強移動互聯(lián)網(wǎng)應用程序備案管理工作的通知》，對于未上架的微信小程序，自 2023 年 9 月 1 日起，必須在提交上線審核前完成備案，否則無法通過審核；

這一部分就先不嗶嗶了，發(fā)現(xiàn)已經(jīng) 1 萬 3 千多字了，肝不動了，小命要緊，下次再更。

不過一頓體驗下來，有驚喜也有失望。

驚喜的是，我真的全稱沒寫一行代碼2小時就快速開發(fā)了一個小程序，要知道，換做以前，不敢想象的。

失望的是，目前體驗來看，AI寫出的前端代碼還OK，但后端技術(shù)就不大行了，也可能是后端需要更復雜的邏輯，所以提示詞要更精準一些。

在整個過程中，寫代碼其實花了也就半小時，但更多的時間都是用來解決這貨產(chǎn)生的bug，哈哈哈，所以得出一個結(jié)論。

目前的 AI 編程確實還只是實習生水平。

不過，這已經(jīng)很驚艷了，人人都能開發(fā)應用的時代很快就會到來，這一天，你期待嗎？