 |
| 這是自己做的第一個比較完整的Web軟體，碰壁也最多 |
當然啦，有興趣的朋友可以照表操課。不過因為我開發這兩個軟體其實有投入一點點的月費，要靠全免費軟體對程式小白而言，可能會很痛苦，所以歡迎想要用軟體的朋友留言留下聯絡資料（e-mail），幫忙小額抖內一下，我會回覆你e-mail通知如何抖內後給予金鑰，目前的軟體可以開放給你用囉。
一、 奠定根基：軟體應用規劃與藍圖（開發前）
旅行萬用帳本的桌面模式，當然也有手機用的模式
1. 頁面連結與佈局規劃
第一步就是要先規劃軟體在什麼地方用，怎麼用的問題。所以可以先畫出樹狀圖，仔細思考頁面如何去連結，例如開啟App後，首頁有什麼佈局，點哪個按鍵以後會進入什麼頁面，一個支線一個支線想清楚，再下去請AI協助佈局，整個App撰寫的開局會非常清楚。
2. 功能清單與開發流程表
先想好軟體的所有功能，和AI進行討論，然後把開發功能規劃寫成一張表（用AI寫），然後再寫開發流程表。善用對話選項，磨清楚整個功能，因為AI可以檢查你思考的漏洞，最後的開發流程才會順利。
3. 善用工具深化計畫
Cursor可以用Plan來進行問答功能，人機雙方釐清問題後，Cursor可以幫你做更詳細而且精準的計劃。
4. token 開支與語言橋接策略
若你用cursor的免費或付費版進行開發，甚至是其他的代理軟體，每一分錢建議都要花在刀口上。所以為了要節省token的關係，可以利用免費的AI作為橋接，幫你將中文的prompt翻譯成英文，這樣就可以不用讓AI進行語意猜測，因為AI的母語就是英文，可以少了很多來回溝通的token量。當然如果你的英文也很強，這部分就直接用英文做就好。然後請AI在做好軟體以後的報告，或者是和你的溝通，他可以直接輸出中文，因為這樣幾乎不會浪費太多token。
二、 頂層設計：UI 佈局與國際化架構（開發中・第一階段）
1. 建立 UI（User Interface）佈局
想完軟體規劃後，就可以跟AI討論每一頁的UI佈局，自己畫草圖後請AI協助化成更漂亮的介面圖，會比從文字跟AI討論，請AI直接生成來得快且準，除非你自己很會下Prompt（提示）。而這時候可以不用讓你的UI佈局有功能，或者是讓UI很美觀，先讓UI被建立以後才重要。
2. 佈局先行的優勢與抽離多語系
當然UI的建立，是需要倚仗前一步的軟體規劃樹狀圖，你不能想一步做一步，否則回頭再修很花時間，若用Cursor的Agent模式代寫的話也更花錢。而且一次先建立好UI，不去加功能的話，是有好處的，那就是程式碼不會很複雜，後面讓AI整理起來也更快。
例如我建立旅行帳本的App，一開始把介面先想好，連多語系的模式也先弄，那麼AI很容易就可以把語言檔做成json檔案獨立出來，讓後面要連動或者加文本，甚至多增加語系也會很方便。
三、 核心實作：人機混合架構與工具互補（開發中・第二階段）
帳本邏輯相似，後來也搬用在日常記帳模式
1. Hybrid（人機混合）程式語言核心原則
真正開始寫程式時，可以先請cursor做一些核心原則。而有一個核心原則也可以節省token，這就是Hybrid的程式語言。可以把程式撰寫時的語言，請AI自行規劃，如果是人類常常會修改（不管功能或介面），或者是之後可能會有比較多bug的地方，請AI用人類也可以修改的方式做。但如果是程式底部完全人類不會碰到的程式碼，那就可以直接用只有AI懂的程式行來寫，讓程式可以更精簡。好處是AI讀取AI專負責的語言快速，節省token，程式碼也可以更乾淨（雖然人類看不懂）。而人類也可讀的程式碼則可以由人類來自行修改，或者讓AI找的時候也比較容易對應程式碼表徵語意。如果要做這種Hybrid的程式語言書寫，一定要記得在一開始的時候就做程式的檔案結構表，而且只要大型更新時也一定要更新一下。
2. 建立功能
接下來這階段就是實作的重心了，開始替每個功能鍵加上正確的功能，這是不懂程式者用代理AI最燒錢的地方，有時候Prompt沒下清楚，就得重複修改，浪費很多AI的tokens。所以你可以先和claude之類討論清楚，再下正確的prompt給代理軟體，盡量讓代理軟體一次搞定，不要一修再修，浪費token，當然也浪費錢。
3. 雙模型協作策略
這時候可以靠Claude協助，雖然Claude上下文的容量不如Gemini，但是Claude的模型是專精於程式語言，所以很會下Prompt。當然Claude免費版很容易用完，但如果你沒有很急著推出程式，慢慢磨總會磨完整個程式的製作。
四、 品質把關：雙階段測試與盲點修正（開發後・檢驗）
現代人注意健康，所以在吃便當時想到idea，就試作看看
1. 測試功能，修正 Bug
測試功能我認為可以分兩個階段：
【第一階段：本機伺服器測試】
先在本機伺服器測試，把所有你建的功能都測一遍，而且要來回測試。當然測試時，可以請AI協助你要怎麼測試，軟體就應該在電腦上先模擬或者測試沒問題，才會進行下一步。而本機測試就會遇到很多問題，這時候可以先記下來，同樣功能系列的Bug擺在一起，然後請AI寫Prompt讓Cursor一起修正同系列的Bug。我還遇過有那種是網路快取沒清掉遇到的Bug，這種最煩，抓半天抓不到，因為程式碼就是正確的，一清快取以後才知道程式碼沒問題，白白浪費很多Cursor的tokens。
【第二階段：上線與實機測試】
接著就是上線測試了，找到網站代管伺服器，比如說Google的Firebase，免費的容量就很大了。上線以後用實機真的跑網址測試，或者你寫的不是網頁App，而是iOS或Android的App，除了在模擬器上跑之外，也一定要直接Build進去你的手機裡面實際跑看看，否則模擬器真的會不準。很多問題是在實機測試上面才會知道的，因為手機百百種，就算都是iPhone好了，你用的是舊的版本 and 新的版本，有時候也會有差異。
2. 開放封測與人性邏輯調適
走到你自己測試的差不多的時候，基本上就可以把軟體命名為v1.0了，因為這時就開始可以給你的親朋好友，甚至網友們實測之後給回饋了。因為你做軟體用的絕對是你的邏輯，他人邏輯很容易看到你的死角，而回饋就可以給你把軟體做得更好，走得更遠，甚至未來想商業化，這條路也非走不可。
所以封測第一次結束後，你一定可以得到很多很有趣的回饋，仔細思考回饋，想想哪些回饋是有價值的，哪些回饋是無效的。這一步已經不是理性，要靠你的感性，而這正是AI無法做到的部分，畢竟AI給你的建議是「理性的」，但你自己，或者你自己也有朋友可以討論的話，你們的思考才會是「人性的」，有時候使用軟體的直覺在於人性，而非理性。
五、 永續經營：技術文件與效能減肥（專案維護與交付）
1. 檔案架構功能說明書（Technical Specification）
你在App做好以後，可以請AI協助你下指令，掃描整個專案資料夾中，製作App所需要的檔案（node_modules基本上太大，可以跳過不用掃），然後請AI製作一份「檔案結構說明」。這等於是檔案地圖，你未來請任何AI協作時，只要先提供這份檔案給它，它就能先明白檔案架構，加速修改流程與正確性了。
2. 開發日誌與 README 產出
其次，製作App的過程中，每過一次大的製作過程，也記得請AI寫開發日誌，每次製作差異比較大時，都請AI更新，這樣確保你的開發流程都能夠管理。
完成以後，則可以請AI參考這些內容，然後請 AI 製作一個 README.md 檔案放在專案根目錄，裡面只記錄最重要的核心檔案路徑與其對應功能。這樣即使專案變大，地圖依然精確。再依此幫你寫一份使用說明書，說明書也可以是專業版和一般使用者的版本。
3. 最佳化程式（安全減肥計劃）
可以請AI協助擬定風險由大到小，不要動到程式功能的多步驟程式減肥計劃（最佳化）。例如清理廢碼、lazy loading等等，都可以在安全的範圍內進行。當然指令要下對，基本上就是先要求每一次減肥前，先進行檔案的備份，檔案備份可以設定，保留沒出問題的近三次備份就好，其餘刪除。這樣一來，整支程式可以更輕盈，而且讓使用者用得更順。
沒有留言:
張貼留言