在寫完AI 時代的軟體工程與學習方法後，我開始把AI納入我的工作流程，以下是我實際使用後的心得紀錄。
（持續更新中…）
Hard Work Still Counts
這點是寫給自己的，我看了太多vibe coding的驚人成果，被「做一個產品很簡單」這樣的風氣影響。
但實則不然，要把一個產品做出來，中間需要許多思考、部署環境設置、問題解決的能力，並不是下個prompt就能解決的。
比較合理的認知是「用AI快速把自己帶到該有的平均值」，而剩下更細緻的使用者體驗、設計、特殊邏輯，這些才是人需要跨越門檻、發揮創造力的部分，而這部分仍然需要許多研究和思考。
該花更多時間的部分：市調與設計
當把實作外包給AI，產品可以快速達到平均值，但要讓一個軟體變得好用，仍然需要靠人去跨越門檻。
一、先針對某個應用做市場調查
一想到某個應用，就把所有相關的app都下載來測試，會發現幾乎所有想法都已經有人實踐了。這部分做的越充足，才越知道仍有什麼突破口存在。
二、針對特定功能，先拆解市場上的做法
最近在做模板記帳(【軟體】給懶人用的記帳軟體)，發現大部分記帳軟體早就有了自動記帳的功能，但每家做法都不太一樣，這些細微的差異帶來不同的使用體驗，也在底層實作有差異。
理解現有的功能有哪些常見做法，才比較不會把功能想得太複雜、做出沒人要的功能。
我第一版的模板記帳，想實作iCalendar（RFC 5545）這個重複頻率的標準，結果搞到太複雜。後來調查後才發現，市面上的軟體根本沒有做那麼複雜，這顯示出我把功能想的過度複雜，卻不是使用者要的。
三、對市場現有產品的理解後，才知道什麼是我要改進的，再針對這部分做設計
沒有調查的設計，就像是沒有文獻回顧的研究論文，不可能有太好的解法。
程式碼還需要理解嗎？
我知道網路上有越來越強的聲勢，是關於完全不看AI產生的程式碼，只測試軟體行為。老實說我不知道哪個比較好，我認為開發的哲學要自己在實踐中確立。
我心中有一把尺，左側是「完全手刻、完全理解、完全掌握」，缺點是開發緩慢、受限於人的經驗而無法突破；右側是「完全AI產出、完全不看程式碼、完全放手」，缺點是不理解程式碼的不安，但優點是開發快速。
開發時就是不斷在這把尺上找位置，我預設是90%走完全代理的模式，而剩下10%的時間還是會用來看程式碼。
但自己看程式碼這種消耗認知資源的工作，就要花在刀口上，不應該為了理解而理解，這兩個情境下，花時間理解仍然很有價值：
一、花時間理解，是為了降低未來爆炸的風險
這是因為從AI得到結果很容易，但有可能底層的寫法已經累積了技術債，擋住未來開發新功能的機會。
我在做【軟體】加速上架流程的黑膠貼紙產生器時，雖然是小專案，但那時候沒有認真審核AI採取的方案，發現他在planning階段因為沙盒環境裝套件失敗，就直接不用套件，硬幹去操作xml檔案，這是一個很不好的寫法。
二、花時間理解，是為了能做好產品設計
如果完全不看程式碼，雖然做出了功能，但被人問到能不能調整時，就突然回答不出來，因為不知道底層到底做了什麼？
所以在用AI衝很快的時候，還是要停下來問自已幾個問題，確保有high-level理解，才不會不知道目前系統能夠支援什麼功能、要怎麼設計新功能。