一、功能概覽和本文核心

本次開發，不是1天干擼，而是在下班后或早起搞的，總體加和計算了一下，大概1天的時間（12個小時），平常下班都是9點的衰仔，好在還有雙休，謝天謝地。

1.1 一圖介紹小程序功能

快速應用工具

1.1 本文核心

• 大概介紹一下，小程序功能，以及設計小程序的出發點
• 介紹一下整體開發過程，體驗一下claude初步評估一下研發水平
• 總結一部分心得，再用claude寫小程序時，發現的一些問題和設計思路
• 介紹一下開發中，在沒有付費開通云服務時，小程序圖片/音頻/數據怎么存儲

二、功能介紹和設計出發點

2.1 小程序功能

首頁工具

• 單位轉換：主要用來臨時換算單位
• 生成二維碼：把一些文本/密碼/鏈接等生成二維碼，方便快速傳播，或者解碼二維碼獲取文本
• 全屏時鐘：可以用來計時，大屏效果好，適合專注工作計時，點擊可以隱藏年月
• 計時器：支持倒計時/計時器，而且支持同時多個存在，適合批量計時
• 應援彈幕：設置字體顏色，大小和速度，演唱會上舉起手機（哥哥/姐姐，你太美，此刻我已等待2年半）
• 證件照：1寸/2寸/小2寸，可以自己拖拽裁切
• 表情制作：單純的圖片拼接文字，沒什么復雜內容（后面搞一組現成的詞語表）
• 稱呼計算器：回家過年必備好吧，爸爸的爸爸叫什么？叫爸爸爸爸？
• 房貸計算器：算一算，就不想戀愛/結婚啦，可以說是戀愛/結婚冷靜神器。
• BMI計算器：看看自己真實的斤兩，PS和美圖只能騙騙自己。
• 復雜計算器：比系統自帶的計算器，提供了更多的計算器內容。

導航工具

• 這個主要是為了適配公眾號，因為有些東西不能在公眾號去寫，而且公眾號發了就不太好修改了，沒法做實時補充內容。
• 另外這個和github的通用導航庫是互相映射的，github是公開開源內容， 如果有興趣/或有喜歡的推薦網址，提交代碼 https://github.com/justalong/navjson

休閑娛樂

• 劃劃水玩玩小游戲。
• 敲敲木魚，平復一下上班的負面情緒，遠離垃圾人和事。

2.2 設計出發點

• 一直想做工具小程序，但是時間上真的沒有那么多，所以存在小程序項目 hellow world 基礎，但沒建設任何內容
• claude或Deepseek等眾多AI產品的爆發，以及能力的飛升，想測測AI能力，但是缺少真實項目練習，缺少項目規劃
• AI的發展，以及個人對AI在編程上影響非常感興趣，在把上面兩點一結合，本次的初步嘗試就誕生了，而且總體大大超出我的預期。

三、介紹claude整體開發過程

3.1 概況介紹

先整體看一下開發內容，其實寫了很多需求描述，為什么寫這么多，多數由下面幾點導致的（大的方向：長度限制和功能錯誤和UI不達標）

• 功能點復雜，輸出長度超出了最大限制
• 輸出的功能有BUG，多次對話修改，達到長度限制
• 多次改動后，代碼輸出混亂（因為修改bug問題，它有時候只給出部分修改內容，會出現函數丟失）
• 使用不正確的API，導致功能異常
• UI個界面布局過于丑陋，大小和顏色適配不合理
• 功能不符合預期，輸出簡陋/數據不足/方法設計不合理

3.2 功能介紹

Claude 四種模式主要區別語言風格、內容深度和適用場景：

1. Normal（標準模式）

   • 風格：自然口語化
   • 長度：中等內容，保留一些必要細節
   • 特點：日常對話等通用場景

2. Concise（簡明模式）

   • 風格：精簡概括總結，電報式表達
   • 長度：平均比標準模式短40-50%
   • 特點：適合簡短，重點獲取，移動端查看
   • 典型回答：“1.xxx;2.xxx;3.xxx”

3. Explanatory（解析模式）

   • 風格：教學模式，邏輯清晰
   • 長度：比標準模式長30-100%
   • 特點：適合復雜概念/深度理解
   • 典型回答：“1.詳細介紹xxx技術點，算法，公式，處理機制都會詳細介紹”

4. Formal（正式模式）

   • 風格：商務模式，嚴謹規范
   • 長度：與標準模式相當
   • 特點：適合專業場景/正式文件
   • 典型回答：“尊敬的[姓名/職務]：謹定于[日期] [時間]在[地點]舉行關于[主題]的會”

場景選擇：

• 日常咨詢 → Normal；快速備忘 → Concise；學術研究 → Explanatory；商務溝通 → Formal；內容創作 → Normal/Formal；技術文檔 → Explanatory/Formal

使用技巧：

• 指令疊加模式（如"用Formal模式解釋XXX"）實現更精細的內容控制，可根據需要靈活切換。

3.3 開發方式

• 主要是通過通過不斷對話來實現需求，調試bug問題。
• 通過轉換語句/詞語的內容，來更好的保持邏輯性和讓AI能夠理解你的表述內容。
• 合理的拆分功能模塊，避免輸出超限，將功能解耦在人工組合產出新的完整功能。

3.4 問題處理

• 結合編輯器，適當的進行功能運行，通過編輯器查看錯誤。
• 將錯誤變量/函數/對象等，反饋給AI，讓其修復問題。
• 添加適當的console輸出，針對事件適當補充console。
  

四、心得和設計思路

這塊內容，個人感覺還是有點意思的，用AI開發，需要一些經驗積累，從最開始簡單幾句話編程到后面通過詳細表述需求，來達到實現自身預期的目標，這是一個必然的過程。

隨著功能開發，你會發覺語言的表達方式，詞語的運用對結果都有一定影響，在沒拿到想要的結果時，很難確定哪些表達它可以理解的更準確。

4.1 先看個樣板變化（從首次提問到后面提問內容的轉變）

4.1.1 首次提問

先看我第一個提問“微信小程序二維碼生產（還寫錯了字）和二維碼解析實現”，很符合絕大多數人的處理方式。

想用一句話給我產出一個符合我預期的需求（這在業務開發中，如果PM提出一句話，研發肯定會心里罵娘，立刻拿起40米大刀，好在AI心平氣和）

結果可想而知，肯定是沒符合我的要求，輸出的內容也完全不符合我的預期，我期望是一個完整的功能，而不是一個方法。

// 1. Basic QR code generation
wx.createQRCode({content: 'Your content here',width: 200, // Size in pxsuccess: function(res) {// res.path contains the path to the generated QR code imageconst qrCodePath = res.path;// You can use this path to display the QR code},fail: function(error) {console.error('QR code generation failed:', error);}
});// 2. Alternative: Use canvas to draw QR code
// First, add a canvas element in your WXML file
// <canvas canvas-id="qrcode" style="width: 200px; height: 200px;"></canvas>// Then in your JS file
import QRCode from 'path/to/qrcode-library'; // Import a QR code libraryPage({generateQRCode: function() {const ctx = wx.createCanvasContext('qrcode');const qrcode = new QRCode({content: 'Your content here',width: 200,height: 200});qrcode.draw(ctx);ctx.draw();}
});

4.1.2 后面提問

1. 只寫page頁面相關，不用app.js全局變量；
2. 支持最新小程序api；
3. 采用rpx布局方式；
4. 主體背景黑色，小程序頭部同意采用黑色背景白色字體；
5. 不要使用button和text標簽；
6. 主要字體采用28rpx; 大號字體使用32rpx;超大號字體使用36rpx；
7. 禁止在wxml里使用函數方法做數組字符串操作；
8. 禁止在wxml里使用includes方法；
9. 創建BMI計算器，區分男女；
   

從兩次描述，其實你就能發現，表述差距和細節約束一下增加很多，從 “PM人” => “RD人”的角度，肯定是后面的表述，更符合人的理解。

而且需求表述的越詳細，“研發”理解的越容易，理解的越“準確”，到最后的產出就越符合預期，修改“溝通”的次數就越少。

4.2 設計思路

回看上面的功能截圖，細看會發現，開始的前三個，功能背景顏色和字體都不是很統一，字體大小沒約束，背景顏色也黑白都有，但是后三個則更像一個產品的功能風格。

這也是不斷約束提示詞，才有的更加統一的效果預期。

4.2.1 統一UI

• 用必要且詳細的表述你對UI視覺的預期
• 明確約束一套字體大小規范（大中小）
• 明確約束核心內容背景色和字體設計規范（主體背景色值，字體顏色色值，區域背景色值，按鈕背景色值，頭部標題背景色值，文字色值，都可以提供多段色值）
• 明確約束布局尺寸方案（rpx還是px）
• 明確約束是否使用通欄頭部

4.2.2 統一頁面結構體

• 讓其制定一套項目目錄結構，將結構輸出，并將其作為你的項目設計核心
• 單純的使用claude是沒有辦法完美實現持久化記憶能力的（應該可以通過Agent或者工作流平臺可以）所以這個目錄結構可以自己截圖保存，后續做功能設計時，合理的讓其理解該結構，并適當拆分功能（這個使用準確性不太好，但可以用用看）
• 我這里統一采用了pages維度設計，也就是一個功能一個pages下的目錄，特點是它給我輸出四個文件內容，我自己拷貝過去。（只寫page頁面相關，不用app.js全局變量）

4.2.3 統一API使用

• 統一API的使用規范，這里主要的表現的是，使用全新的API，避免使用一些老舊的API導致非預期的效果
• 支持最新小程序api；使用Canvas最新的API；（我建議適當的羅列出相關API） 這里能避免一些媒體選擇API使用舊版。
• wx.getSystemInfo；wx.getSystemInfoSync；這兩個就可能需要單獨羅列；

4.2.4 統一WXML數據規范

• 這里主要是約束WXML規范，避免一些不合理的使用導致頁面渲染異常
• 如果沒有約束，在WXML里可能存在includes，findIndex以及其他數組操作方法，這些方法都會帶來異常
• 禁止在wxml里使用函數方法做數組字符串操作；禁止在wxml里使用includes方法；

4.2.5 統一WXML標簽規范

• 這里主要是約束一些標簽使用，AI可能更愿意嘗試語義化的表達，更具有邏輯性，但是往往帶來一些問題
• 經常使用text標簽，導致布局異常
• 經常使用button標簽，導致事件和UI布局異常

4.3 心得經驗

除了上面的一些大的方向的約束，在開發過程中還有一些小的點也會帶來問題，這里我主要總結我當前遇到過的一些問題。

4.3.1 經驗和問題總結

• 如果不明確說明以page維度輸出，經常會使用全局變量，并且生成app.js和app.json相關配置
• 本地存儲storage，AI更喜歡使用移步方法進行set/get，但是有時候，或者多數時候，使用同步的set/get更符合我們預期
• 默認輸出，會隨機使用px單位或rpx單位，建議統一約束
• 輸出的wxml的樣式和變量，綁定內容過長，AI會進行換行操作，但是換行會導致異常，可以自己修改或者約束wxml屬性不換行
• 動畫一般會采用小程序的api實現(wx.createAnimation)，如果不是很需要或者使用不多，可以約束其動畫實現效果。
• 音頻內容不能使用本地，但是AI生成是沒法處理這種問題的，需要自己去更換一下。
• AI更多的是負責生成功能的實現方案，不會在意你的限制條件，需要特別明確出來（比如我希望給gif添加字幕，用來制作表情包，它給我了云服務的實現方案，但是我沒有買）必須明確只用前端方案。
• 過多的條件約束，偶爾會出現能力實現丟失，雖然最后它總結時說實現哪些功能，但是代碼層面會沒有。這種時候可以追加補充功能提示詞就行，它會自己完善。
• 過長代碼輸出，會觸發終止，需要輸入continue來完成后續的持續輸出
  

4.3.2 貼近真實項目的實戰效果

項目主題是，開發一個高中教師排課的課表功能，這個需求的出發的點就是老婆那邊使用課表比較費勁，每學期的課表都是保存個圖片，修改后也不方便調換。另外就是她們排課也比較復雜，沒有什么快捷方式，一般都是excel逐步去處理。

這個項目的目標就是用小程序實現一個初步的排課表功能，可以實現在手機上完成排課，并且可以共享課表，讓每個老師都能看到這個課表，并且可以通過課表過濾，只看自己的課程和自己的自習時間。

這項目其實本身復雜度并不是很高，只不過為了達到一個標準的且符合用戶習慣的使用效果，需要處理很多邊界和交互能力。

• 添加課程時，可以對這個課程（老師）進行備注，打標簽
• 比如孕期老師，可能不適合安排上午最后一節課，這種條件都通過標簽實現
• 需要支持設置課程時間和課間時間，這個直接影響每次添加課程的開始和結束時間默認值
• 添加課程時，下一次添加要以上一次結束時間+課間間隔作為時間選擇器的開始時間
• 時間選擇器的結束時間，默認是開始時間 + 課程時間
• 需要自動校驗時間重疊問題，如果課程時間有重疊，要禁止添加，給出提示
• 每天的時間選擇器設置時間是互相隔離的，比如周一的添加和周二的添加，時間選擇器的開始和結束時間互不影響
• 支持數據本地存儲，方便快速啟動渲染
• 每次添加的數據是按照周一到周日隔離，互不影響

• 在不做人為修改的情況下，這個能力基本上每次都不符合預期，而且幾乎總是有錯誤。
• 但隨著提示詞的改變，也是有逐步轉好，表現得越來越接近預期。
• 第一個大的變化：從最開始的沒有合理的UI布局超出屏幕，且只有一個添加按鈕，數據無法準確添加，存在邊界case導致添加異常，到后來變成，有不錯的UI界面，每天下面有個添加按鈕，且數據能夠準確添加，盡管還有時間問題，但是如果使用的人能夠自己檢查時間，那本次功能其實也基本算可用。 這期間AI不能準確理解時間隔離，但是能更好的理解每天有一個添加功能按鈕 也凸顯出提示詞，甚至說語言呈現的結構體，對AI是有非常大影響的。
• 個人認為面對AI編程，語言的邏輯性和語言表達出來的結構性，將是AI輔助型研發的主要差距點，因此AI編程的藝術，更像是語言表達的藝術。

4.3.3 粗淺的結論

• 從本次結果和消耗的時間來看，AI對工作效率有相當大提升，但取代研發說法還是為時尚早，但是研發模式的變革已經悄然來臨了，只是本次的一些小小的功能測試，也能體現出AI的恐怖能力。
• 個人的觀點認為，當前程序研發和AI工具發展情況，可以嘗試類比農民和農具（反正也是碼農），當前處在工具的快速發展，百花齊放的階段。農具的使用大幅提升效率和批量產出能力，自然會降級基礎勞動力的需求，但是對于熟練使用工具的人需求同樣會增加。另外效率溢出，產能過剩，研發時間降低，自會催生更多產品，甚至逐步產生獨立的個人產品，也許會變成公眾號的愿景“在小的個體也會有自己獨立的品牌”

五、小程序數據存儲

5.1 圖片資源

目前小程序圖片主要分成2部分

• 一部分在本地，圖片壓縮體積，盡量保持足夠小，這類主要是存放一些ICON
• 一部分存儲在cloudflare平臺，這真是“大善人”，沒啥可說的，免費提供對象存儲，而且提供https能力
• 當然你還可以使用一些免費的圖床平臺，比如“路過圖床”，可以去搜搜有很多，此圖床不提供https能力，這對小程序來說可不咋友好

5.2 音頻資源

• 因為小程序不支持本地音頻，所以只能用云端數據，那當然也放到了 cloudflare 上了。

5.3 數據資源

• 比如一些靜態JSON數據，不需要動態改變的內容，理想狀態是放到CDN上，但是幾乎所有的免費都有時間限制，所以我給他設計成了npm包形式，通過unpkg實現，我可以把靜態json打包，然后可以通過unpkg直接請求JSON內容。然后在本地存儲一份，每日更新一次。
• 如果你不知道unpkg是什么，可以搜“cnpm 視頻事件”，一位老哥把視頻搞上去了，我記得當時也是一段熱搜。