我如何與 AI 協作開發,我的開發步驟分享

我如何與 AI 協作開發,我的開發步驟分享

昨天到工程師場子分享,想說跟大家對照一下,現在是否多數人都跟我一樣,寫程式完全不手打任何一行 code,全部都是 AI 做的。
結果發現,現場只要有在用 AI 開發的人,多數時候真的都是讓 AI 來完成程式撰寫工作。

目前我的開發組合是 Claude Code / Claude Design / Fly.io / Github / Cloudflare,其他還有根據程式功能需要而使用的第三方元件。

做一個新系統的習慣是:

  1. 跟 Claude 討論我想解決的問題,以及我的核心需求,中間我可能會用 Claude Cowork 做本地資料的分析,然後請他廣泛收集一下資訊,做幾輪 prototype 的模擬。確認方向是否是我所期待的。
  2. 對完需求後,請他產出系統定位、限制、邊界與 PRD。
  3. 把 PRD 跟幾個 md 檔丟給 Claude Design。產出系統設計稿。這邊必須稱讚一下 Claude Design,他產出的設計又快又好,還可以一次出多個版本供我挑選。順便連 icon 都幫忙設計好了,有夠讚。
  4. 把 PRD、md、設計檔提供給 Claude Code 請他幫忙規劃開發計畫。並告訴他優先以功能完整性為主,不用在意 MVP。對我來說,一個完整可動的東西,其實就是 MVP 了,對 AI 來說,一次到位跟 MVP 交付的時間,很可能就是一兩個小時的差別。
  5. 通常我會在睡覺前進行新系統的首次任務交付。我會說,你按計畫依序開發,直到 Phase XX 為止,我希望我早上起床時可以有一個能正常運作的系統。因為我本機開 auto mode,除了prod 環境需要我許可外,其他都讓 AI 自行處理。在部分專案中,我甚至是直接連 prod 都隨便它。

上述工作中,步驟 1 是最花時間的,常見的問題有兩個:

  1. 我想法還不具體,期望太大,但 context 太少。
  2. 又或者手邊的 raw data 達不到我想要的結果,可能是資料量不夠,時間跨度不足,欠缺關鍵資訊。

想法不具體,那就回到需求跟問題本身,請他多提幾個解決方案;資料不足,我會請他模擬更多數據,讓我能感受一下數據到位的樣子。這個步驟就算卡,最多也就是半天的時間我能搞定。

後面幾個步驟,除了開發外,速度其實都很快。

確認功能 OK 後,我還會補上幾個比較重要的步驟:

  1. 資安,這塊除了典型的資訊安全問題外,還會針對因 prompt 有關的 AI sercuity issues,如 prompt injection 做處理。
  2. Log 機制,前面一兩個系統忘了 log,所以追查問題時反覆來回了很多趟,AI 一直要我幫他下指令,然後跟他回報我看到的訊息。我覺得這就像以前我沒寫 log,然後要使用者告訴我他的步驟跟畫面一樣煩。我問他:「你看不到錯誤 log 嗎?」才發現他根本沒寫 log。所以後來我都是直接補上了。
  3. Unit test,確保整體程式碼品質。這在以前真的得花不少時間,但現在真的就是分分鐘搞定。
  4. Integration test,我會讓 AI 生成多個使用者帳戶,逐一跑過所有的 test cases,並產生個別的測試報告。這是用來替代原先的人工測試動作,這幫我省下了不少時間。
  5. 定期重構,每隔一兩周,我都會請 AI 針對現在的 codebase 檢視技術債。只要是有道理的,我通常會請他直接全部改完。
  6. 維運機制,以前會很重視監控面板,但現在我關鍵是讓 AI 可監控異常,所以我基本不做監控面板,因為我自己是不看的。這邊的設計就比較單純了,當出現異常,自己發 issue,自己 hot-fix。如果是硬體資源的問題,就自己 scale-up / scale-out,但會設定一個上限值。

大多數的時間都在提需求 + 規劃,執行的時間真的很少。

雖然中間發生過幾次 AI 反覆改都改不好一些問題,或者說有 deploy 了,但我怎麼看都沒有。最後總會發現是他自己搞錯方向了,或者有些說有做的事根本沒做。

也有發生 claude.md hell,也就是開錯 Folder,開到本機根目錄,所以一堆 claude.md + memory.md 檔全部混在一起。效能慢不說,context 混亂連需求都搞錯,參數亂讀當然無法產生預期中的結果。

不論技術怎麼進步,軟體工程的核心還是在「品質」,包含可預期性、可管理性、可延展性。

做出功能是基礎,可持續維護才是挑戰。

如果你覺得我內容寫得還不錯,歡迎訂閱我的電子報,我每雙週會發送一封電子報到你的信箱。訂閱連結在這,過往的電子報也在這:Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們,也許你的舉手之勞,將會改變另一個人的思維與習慣。

Read more

[徵才]方圓國際誠徵兩個新職務

[徵才]方圓國際誠徵兩個新職務

今年四月份,我加入了方圓國際擔任策略長,方圓是一家茶飲連鎖公司,旗下有兩個主要品牌「吃茶三千」與「喫茶小舖」。吃茶三千在海外 30 多的城市有約 130 家門市,喫茶小舖在台灣則約有 60 家門市。 我從去年底開始擔任方圓的顧問,主要協助梳理公司的管理制度、流程與阻礙成長的問題。四月份我轉任策略長,過去這一個多月,我除了 AI 的引入與建置外,我也花了大量的時間重新構思公司的整體策略。 我們進行了「未來十年不變的事」的策略探討,最終設定了十年戰略方向,三年目標,以及 2026 年的關鍵任務。 透過這樣深度的策略思考,我們也藉這個機會盤點了公司目前的人才缺口。 以下有兩個很關鍵的角色是我迫切在找尋的。如果你覺得自己或身邊的人很適合加入方圓,請自薦或推薦給我,謝謝。 歡迎將履歷投遞到:gipi@teashop168.com.tw 門市體驗經理(Store Experience Manager) 門市是接觸終端消費者的最後一哩路,也是品牌傳遞價值的關鍵接觸點。我們在全球因應不同的市場有不同的店型設計,

By gipi
克服 AI 焦慮的方法,唯有實作

克服 AI 焦慮的方法,唯有實作

2018-2019 年左右,線上學習在台灣整個大爆發,線上課程一大堆,每個禮拜都有很多線下學習活動。每天都可以看到大量的學習心得與活動心得,每個人講的內容都很有道理。全台灣好像瞬間變成一個知識島,所有人都學識淵博,而自己似乎懂得有點少。 知識焦慮年代 在那個時候,很多人染上了「知識焦慮」的病症。 害怕別人知道自己不知道的,擔心自己沒跟上世界的節拍,所以哪邊有新知往哪兒去,哪邊學習氛圍濃厚就往哪兒鑽。看起來是因為熱愛學習,但內心的煩惱其實是「害怕失去」。 害怕失去話語權,害怕失去社交談資,害怕失去機會,害怕失去競爭力,害怕自己不再是別人眼中領先的族群。 而克服焦慮最有效的方法,不是知道更多,而是實踐,從時間中獲得成果,獲得進步。 那些仍在學而沒有做的人,焦慮是無法停止的,因為他並沒有真的改變現況。 這也是當年為何我們想舉辦 case study、學習營、打卡、案例練習,並且鼓勵大家多多輸出的原因了。因為輸出,其實就是最輕量的實踐,而動手做,則是讓自己學有所用的基本配備。 在那個知識焦慮的年代裡,因為我本來就熱愛學習,也經常輸出,

By gipi
加快了速度,少了回饋

加快了速度,少了回饋

2022 年時我曾推出了一堂課《打造高效軟體開發團隊》。 在這堂課程中我繪製了一張軟體開發過程管理的架構,這張圖我從公司策略->產品策略->需求管理,一路到開發過程管理、交付、市場回饋,最後再回到產品需求管理。 當年我曾說過,軟體開發最重要的其實不是程式開發本身,而是 align 公司策略與產品策略,同時兼顧好短期需求,將需求管理做好。 但我們也可以看到產品需求管理是上述架構中最主要的節點,上承策略,下接短期需求,右邊則是成為所以開發計畫的起頭,同時還要承接來自市場回饋,並能持續優化管理過程與技術債務管理。 簡單的說,決定做什麼,決定了產品定位,決定先做什麼,則決定了策略重心。但要做出決定,除了對目標有清晰的認知外,更重要的是「回饋」。包含市場回饋、使用者回饋、利害關係人回饋(研發/行銷/客服...)。 這陣子透入 AI 開發後我對這張架構圖有一些新的想法: 首先,是生產力過剩。 因為 AI 不用休息,生產力幾乎沒上限,

By gipi
AI 在商業決策層面給我帶來的三層改變

AI 在商業決策層面給我帶來的三層改變

從二月開始,台灣就陷入一陣 AI 瘋,一堆人都開始投入龍蝦、Claude Code、Codex 等超級生產力的任務中。不寫程式的人開始寫程式,包含老闆、設計師、行銷、創作者。而其中最瘋狂的,莫過於身邊的一堆老闆們。 有人批評說:「這些老闆們放錯重點,應該好好回到自己的位置上去做出好的決策,讓專業的人來處理專業的工作,不要瞎搞。」 關於這個批評我個人極端不認同。 我的看法是老闆不多花點時間深入理解 AI,他在未來就很難做出好決策。 今天看到 Coinbase 的 CEO 在 X 上發布了裁員的消息。 而我也在 FB 寫下了我對這件事情的想法。 今年不知道第幾家公司了,幾乎都不是因為經濟不景氣,而是各家公司都在為變化儲糧。很多軟體公司之所以裁員,都是為了有更多的資本支出可以投入在 AI 的團隊、產品或基礎建設上。 扁平化只是一種不再需要「管理代理人」的訊息。現代的管理概念還是很崇尚那個一人最多管七人的科層組織管理概念。 為了「有效管理」,一個人管七個人是個看似科學,

By gipi