C# .NET Blazor MAUI Xamarin Research

2026年6月10日星期三

[AI 分享] Vibe Coding 專案不失控的工作流

摘要 : 用 AI 做 Vibe Coding 前先定需求、打地基、立規矩；開發中小步迭代、限制變更與守住安全，才能避免專案失控。

內容:

最近 Vibe Coding 很火，很多人用 AI 推進專案的速度非常快，但常見的問題是：前期很順，後期程式碼卻越來越亂，最後變成難以維護的「屎山」。一旦持續在混亂的基礎上修改，就容易牽一髮動全身，甚至讓整個專案崩盤。

問題的核心不在於 AI 強不強，而在於 Vibe Coding 並不是把工作直接丟給 AI 就好。真正重要的是，人仍然需要建立一套工程流程去駕馭 AI。以下整理出一套標準工作流，分成「開發前 9 個步驟」與「開發中 5 個關鍵點」，目的就是提高專案成功率。

開發前的 9 個步驟，可以理解為在 AI 寫下第一行程式碼之前，先把地基打好。這 9 步又可分成三個階段：定圖紙、打地基、立規矩。

第一階段是「定圖紙」。第一步不是急著寫程式，而是先導需求。可以像和朋友聊天一樣，把痛點、目標使用者、使用場景，以及理想中的核心功能都告訴 AI。這個階段先追求資訊量，不必過度強調形式上的嚴謹。

第二步是把需求整理成 PRD 文件。這份文件最好結構化，包含功能列表、使用者流程、頁面清單等內容。但更重要的是，每個功能都要補上驗收標準。所謂完成不能只寫一句「登入成功」，而是要定義清楚：登入失敗會怎麼提示、是否會鎖定帳號、登入成功後跳轉到哪裡。若沒有驗收標準，AI 往往會越寫越發散。

第三步是提早定好視覺方向與頁面框架。可以找兩到三個參考網站，或請 AI 提出幾種風格方案，再從中決定導航欄配置、頁面區塊差異，以及整體風格是簡約、華麗或其他方向。這樣做是為了避免 AI 在開發功能時，同時不斷推翻 UI 設計。

第二階段是「打地基」。第四步是明確專案邊界與非功能需求。可以先回答三個問題：這個專案是本地自用還是要公開上線？是否涉及使用者資料、支付或隱私合規？效能與成本有沒有上限？安全、效能、可用性、成本這些非功能需求若沒先說清楚，後面通常都得返工。

第五步是鎖定技術棧。原則不是越新潮越好，而是越可驗證越好。主流技術通常更穩定，因為資料較多、工具鏈成熟，AI 也比較不容易亂編。但真正關鍵的是：你選用的技術是否有足夠的官方文件、社群資源、清楚範例，並且能跑測試、能做 code review。重點不是追求最新，而是追求可控與可查證。

第六步是請 AI 先產出一份輕量化架構草案。內容可以包含目錄分層方式、核心模組、資料模型，以及哪些邏輯必須放在服務端。這份架構不需要一開始就寫死，它應該可以迭代，但每次調整都必須記錄原因，避免架構演變失去脈絡。

第三階段是「立規矩」。第七步是把專案核心資訊固化成文件，作為 AI 的全域上下文。可以至少準備三份文件，例如 PRD.md、Arc.md、Project.md。前者描述需求，第二份描述架構，第三份記錄專案目前進度、已知問題與下一步計畫。每逢重大變動，這三份文件都要同步更新，否則 AI 會依照舊的理解去產生新的程式碼。

第八步是制定開發規範並建立參考資料。要讓 AI 有標準可依循，例如明確規定使用 TypeScript、元件命名方式、檔案大小上限等。同時也可以建立一個 Reference 資料夾，放入自己認可的按鈕、表單、彈窗等標準實作，讓 AI 能照著一致風格去生成。

第九步是在開始寫第一行程式碼前，就先把 Git 與品質閘門建立起來。Git 是版本管理工具，也可以視為安全帶。當 AI 把程式碼寫壞時，可以快速回溯到先前穩定版本；透過分支管理，也能讓不同功能並行開發，降低互相干擾與衝突風險。

完成開發前的 9 個步驟後，就進入開發中的 5 個關鍵點。這裡最重要的一句話是：人負責邊界與驗收，AI 負責體力活。

第一個關鍵點是堅守小步迭代與 MVP 原則。不要一次讓 AI 寫一大坨功能，而是一次只做一個可驗證的小切片。例如先做到頁面能打開，再做到表單能提交，再做到服務端能儲存，接著驗證權限，再到列表展示。每完成一個可跑通的小切片，就測試、檢查、提交 Git 一次。

第二個關鍵點是人類必須介入模組拆分。不能放任 AI 把所有程式碼都塞進同一個檔案。雖然短期看起來進展很快，但後期要查找某個功能、維護某段邏輯時，會非常痛苦。

第三個關鍵點是限制 AI 權限，禁止它擅自主導變更。可以透過狀態摘要管理上下文，也可以在每次任務結尾明確補充限制，例如：「只修改我指定的檔案與範圍，不要順手重構，不要改 UI 風格，不要動無關邏輯。」因為你只是叫它修一顆按鈕，它卻可能順便把整頁都重寫。

第四個關鍵點是守住安全底線，而且這必須是一份具體清單，而不是口號。AI 寫程式常常只求能跑，不會預設替你做好安全設計。因此至少要盯住幾個底線：API key 不要放前端，不要提交進版本庫，要透過環境變數與服務端調用；服務端必須進行驗證與授權校驗，不能信任前端輸入。

第五個關鍵點是要科學地處理報錯。遇到錯誤時，可以先把錯誤資訊交給 AI 修一次；但如果連續兩次都沒有新增證據，只是在猜，就應該立刻停下來，不要讓它繼續盲修。正確的做法分三步：第一，先做最小重現，把問題縮小到最小輸入；第二，加日誌、加斷點，列印關鍵變數與分支；第三，在有新證據的前提下再讓 AI 協助分析與修復。

總結來說，AI 能大幅提升 Vibe Coding 的速度，但不能取代工程紀律。真正穩定的做法，是在開發前先定需求、定驗收、定架構、定規則；開發中則堅持小步迭代、人類把關、限制 AI 變更範圍、守住安全底線，並用有證據的方法處理錯誤。這樣才能讓 AI 成為加速器，而不是把專案一步步推向失控。

[AI 分享] 深度使用 Codex 的六個高階實戰經驗

摘要：深度使用 Codex 後的六個高階技巧，涵蓋通知、引導提交、檢視思考、結果反饋、初始指令與流程沉澱。

內容:

分享深度使用 Codex 之後，總結出的六個高階實戰經驗，認為這些方法非常實用，能明顯提升工作效率與協作效果。

第一，建議在電腦設定中開啟通知功能。因為 Codex 可以同時處理多個任務，當手上有多條長任務並行時，很容易在回覆某個任務時，忘記另一個任務其實早已完成。作者提到自己甚至在兩臺電腦都安裝了 Codex，每天同時有四五個長任務在跑，因此特別需要系統主動提醒。開啟通知後，尤其設定為「持續提醒」，每個任務完成時都會主動跳出提示，並停留在螢幕角落直到手動關閉。作者認為這個小設定對效率提升非常明顯。

第二，要善用「引導提交」功能。作者表示，自己常常在下達指令後，又想到需要補充的資訊，或發現某個關鍵點漏講了，甚至覺得模型執行中的某個步驟可能有問題，但又不想整個中止任務重來。這時可以直接輸入補充內容，再透過「引導」功能送出，讓 Codex 在不中斷整體任務的情況下被打斷，並調整思考方向。作者認為這是非常強大的能力，而且自己使用頻率高達八成。

第三，完整的思考過程很有價值。Codex 在正式給答案前，會先梳理需求、進行一段像自問自答的思考，只是這段內容通常會被收起來。作者很喜歡主動點開查看，因為這不只能幫助判斷模型有沒有出錯、卡在哪裡，更能從中學習它的工作邏輯與整理能力。作者提到，有時自己說了一大段話，Codex 卻只用兩行就精準總結出核心，這讓他反過來學到如何更精煉地表達。

第四，記得把結果反饋給 Codex。作者以前習慣任務完成就結束，直到後來做了一個表達訓練的任務，Codex 主動要求他提供口播練習影片觀看。作者因此發現，Codex 不只是接收文字，還能根據內容觀察他的表達狀態、記錄進步，並在第十天回顧時，整理出一套非常適合他的訓練方法。因為作者習慣用畫面思考，Codex 就教他用畫面去記稿，讓他有一種被徹底打通的感覺。作者認為，一旦形成反饋閉環，最佳化速度會不斷加快；就像演員需要導演給明確反饋一樣，AI 也需要持續收到結果，才能越調越準。現在作者會把生成後的影片效果、甚至修改過的提示詞都同步回饋給 Codex，讓它能推理自己為何調整、調整後產生了什麼改變，進而讓之後產出的提示詞越來越精準。

第五，初始指令要好好寫。作者建議第一次交辦任務時，儘量把需求當成一篇小作文來寫，把自己的想法、要求與背景資訊交代清楚。若懶得打字，也可以先用語音轉文字，再進一步修改。因為資訊越完整，agent 的理解就越準確，越有可能做出你真正想要的東西。不過作者也補充，如果你要它做的是一件自己也還不清楚怎麼做的事，那就另當別論。這種情況下，應該先大量提問，等自己建立起初步概念後，再重新開一個對話，整理成具體的任務需求清單。

第六，要透過深度磨合，沉澱出專屬流程。作者認為，agent 一向是「遇強則強」，你投入得越深、要求越高，它就越可能產出接近專業水準的結果。若想做的是能商業化、夠專業的內容，前期就不能完全放手，而是要把自己的經驗與思路充分投入，把步驟拆得更細，增加人工參與，讓 Codex 去反覆測試工作流、打磨提示詞與內容。作者也建議每天都可以儲存一次專案 skill，等整套流程逐漸成熟穩定後，再沉澱成可公用的 skill，進一步實現自動化運轉，兼顧效率與品質。

在製作一部系列影片的經驗為例，說明這種流程磨合的重要性。一開始嘗試全自動輸出時，效果大概只能打 30 分；但後來透過不斷修改流程與提示詞，反覆測試並找出更適合的工具組合後，品質逐漸提升到 80 分左右。接下來還會持續打磨，等整體效果達到 90 分時，再把整套流程正式固定成 skill。

最後，作者補充一個附加觀點：Codex 再強，也仍然需要搭配各種外部工具。無論是 runway、cdex、gemini、github、hitsfield、highframes、suno 等，這些年學過的工具都不會白學。作者形容，不會使用這些工具的 Codex 就像小學生；而懂得接入並運用這些「兵器」的 Codex，則更像高中生，能力會出現明顯差距。

整體而言，這些經驗是作者親自整理後的心得。他形容，當這些方法逐步理順後，現在每天的工作就像開上了一條六車道的高速公路，每個專案各行其道，速度與效率都明顯提升。

[AI 分享] AI Claude Code / Codex 必裝十個外掛全流程應用整理

摘要 : 整理AI裝的10個外掛，涵蓋開發、設計、辦公、資料分析與影片製作等完整工作流程。

內容:

這是 AI 裝的十個外掛，整體定位像是一個覆蓋開發、設計、辦公、資料分析等多種工作場景的全流程合作夥伴。若把這些外掛都串接並跑通，整體工作效率有機會出現明顯提升。

第一個外掛是 Chrome 外掛。它可以讓 AI 直接操作瀏覽器、訪問網頁、取得資訊，並執行頁面自動化操作，等於讓 AI 擁有像瀏覽器一樣的能力。常見應用包含 SEO 分析、關鍵字分析、網頁資訊抓取、頁面結構分析、競價投放監測、廣告落地頁觀察、競爭對手資料蒐集，以及網頁除錯、設計驗收、元素定位檢查與內容自動採集等。簡單來說，它讓 AI 能像人一樣瀏覽、理解並操作網頁。

第二個外掛是 GitHub。這是一個用於程式碼倉庫管理與協作的外掛，可以讓 AI 連接 GitHub，協助管理程式碼倉庫、建立 PR、執行程式碼審查、追蹤問題與參與協作討論。它涵蓋 PR 的建立、更新與合併，程式碼審查與 issue 管理等工作。搭配這個外掛後，AI 可以從需求分析、程式碼實作、測試到部署上線，參與整個開發流程，提升整體開發效率。

第三個外掛是 Compute Use。它讓 AI 像擁有雙手一樣，能直接控制電腦，進行點擊、輸入、開啟應用程式、切換視窗與執行各種操作。這類能力特別適合自動化辦公、重複性任務、批次作業與資料處理等場景。它可以全天候運作，幫助使用者減少大量機械式操作，提升工作效率。

第四個外掛是 View the Web Apps。這是一個可以透過描述需求，直接生成完整網頁版應用的工具，前端、後端與資料庫都能一次完成。適用情境包括快速搭建 SaaS 產品、建立 MVP 驗證想法、製作簡易電商網站、商品展示、購物車流程，或建立公司內部管理系統、資料看板與工作流工具等。它的重點在於，AI 會根據需求自動選擇合適技術棧，生成可執行、可部署的完整應用，並支援本地執行與一鍵部署。

第五個外掛是 Figma。它能讓設計稿直接轉為程式碼，AI 可讀取 Figma 設計稿並生成元件、頁面與前端程式碼，縮短設計到開發之間的交接流程。對於 UI 設計、產品原型、Design System 與前端開發來說都很有幫助。若產品已在 Figma 中完成完整設計稿，這個外掛能有效降低設計與開發之間的溝通成本。

第六個外掛是 Document。它主要用來協助撰寫、編輯與美化文件，讓文件結構更清楚、內容更專業、格式更規範。適用場景包括 PRD、方案書、週報、月報、專案文件、操作手冊與知識沉澱等。不論是對外提案，還是對內報告與總結，都能透過 AI 快速完成排版與撰寫，提高文件工作的效率與品質。

第七個外掛是 Presentations。它可以幫助使用者生成高品質 PPT，包含簡報內容生成、自動排版、設計美化與資料視覺化。使用者可以指定主題、風格、對象與頁數，描述越詳細，生成結果通常越貼近需求。這個外掛適合需要快速完成簡報製作的人，能節省時間，也提升專業感。

第八個外掛是 AI Spreadsheets。它可以視為 AI 資料分析師，能自動分析資料、生成圖表與報表，並將複雜數據整理成可執行的結論。它不只是像 Excel 的工具，更像是能直接協助做分析、產出洞察與輸出結果的智慧分析助手，適合資料處理、報表產出與決策支援。

第九個外掛是 HyperFrames。它能把網頁直接轉成影片，透過內部智慧渲染，將網頁 HTML 匯出為高品質影片。這對產品展示、教學影片、行銷宣傳素材與社群內容製作都很實用，能更快速地把原本靜態的網頁內容轉化為動態展示素材。

第十個外掛是 Emotion。這是一個程式化影片生成工具，與前面的網頁轉影片不同，它是透過程式碼來生成影片，適合製作動態圖表、資料影片與大量相似內容的批次輸出。基本流程包含撰寫程式碼、渲染預覽，最後輸出影片。它特別適合規模化影片生產、自動化工作流與 AI 內容工廠。若前面的 AI 腳本與分鏡都已完成，甚至可以進一步實現一鍵式全流程自動渲染。

總結來說，這十個外掛涵蓋了瀏覽器操作、程式開發、電腦控制、網頁應用生成、設計轉程式碼、文件處理、簡報製作、資料分析，以及影片生成等完整工作環節。若能把這些能力整合起來，確實有機會讓整體工作流程產生質的飛躍。

[AI 分享] Fable5實測觀察

摘要 : Fable5整體更強但更貴，視覺與推理表現亮眼，安全限制也更嚴格，部分任務仍未全面勝過GPT5.5。

內容:

最近 Cloud 釋出了 Fable5，定位大致和 Mythos5 同級，但它更面向一般使用者，且預設帶有更強的安全防護。整體來看，Fable5 的價格非常高，約是 GPT 模型的兩倍；如果把思考強度開高，會變得又慢又貴。不過從實際表現來看，它的品質確實不錯，在多個基準測試上都優於 GPT5.5。

Fable5 這次的一個重點升級是視覺能力更強。它已經可以透過極簡的純視覺工具鏈完成像寶可夢這類任務，不再像以前那樣高度依賴複雜的輔助工具。Curser 方面也認為它是 Curser Bench 上目前最先進的模型，其中 Fable5 MAX 最強，但同時也是最昂貴的；High 與 Medium 則相對更有性價比。而這幾個版本的整體能力，都被認為超過 GPT5.5 Extra High，不過 GPT5.5 在價格上仍便宜非常多。

在專業應用方面，Physics 公司表示，Fable5 是他們在前沿物理研究中測過最強的模型。它花 36 小時，幾乎達到 GPT 用 4 天才能到的位置，顯示出它在高強度研究任務上的潛力。

Curser 工程師也分享了使用經驗。過去團隊主要是在驗證 Curser 是否「把工作做對」，需要人工拆分任務、逐步檢查輸出、捕捉提前停止等問題；但現在他們更多是在驗證 Curser 是否「在做正確的工作」。也就是說，它不再只是被動執行指令的工具，而能成為思考夥伴。實務上，可以在早期就讓它參與思考，只給一個小規格（Spec），再讓 Curser 反過來訪談需求、補齊細節。若再結合 CC 的相關工作流，就能讓 Curser 持續工作，並平行驗證自己的計畫。這也帶來一個很重要的啟發：那些以前覺得大語言模型做不到的任務，現在也值得交給 Fable5 試試看。

目前官網已經能看到 Fable5 的選項，但有使用限制：在 6 月 22 日前，Pro 或 Max 會員可以使用；從 6 月 23 日開始，不論是 Pro 還是 Max，用 Fable5 都必須額外啟用用量額度，並改為按 API 計費。

也有不少外部評測出現。AK 認為 Fable5 的重要性，大致相當於去年 11 月 Curser Opus 4.5 的那種等級。Augmentor 的測試則顯示，Fable5 整體上比 GPT5.5 更聰明，正確率也略高；處理時間差不多，但在相同任務下，Fable5 平均消耗的 token 幾乎是 GPT5.5 的兩倍，費用也幾乎是兩倍。

不過，Fable5 這次的安全防護也強到讓人相當有感。如果模型判定話題涉及它認為不安全的網路問題、生物化學，或蒸餾相關風險，它可能會直接降級，退回到 Opus 4.8。這點非常令人困擾，因為花了更高的價格，結果卻可能被切換到較弱的模型。另外，對話資料目前似乎只保留 30 天。

官方也提供了一些提示詞指南。Ansysopic 建議多數任務預設用 Hi 模式；Fable5 的指令遵循能力更強，通常不需要把每個行為都寫得非常死。若是長時間執行的任務，則要要求模型在回報前，對照工具呼叫結果逐條審計進度說明。由於 Fable5 有時會主動做超出請求的事，因此在提示中應明確規範它的行動邊界。另外有一點非常重要：不要要求 Fable5 重述推理頁，這被認為是官方用來防止模型蒸餾的保護措施之一。

接下來是一些實測結果。我把 Fable5 和 GPT5.5 都開在 Hi 推理模式，拿來比較複雜前端互動任務的表現。從 Curser Bench 的花費來看，Fable5 Hi 單個任務大約要 10 美元，而 GPT5.5 Hi 約為 3.5 美元，成本差距很明顯。

在「彩色玻璃萬花筒」這個任務上，認為 GPT5.5 做得更好。

但到了「動態字型海報排版機」，Fable5 的表現就非常突出，幾乎是全面壓過 GPT5.5。不論是斜切網路、圓形路徑、巨型字母裁切，還是縱橫混排的密集報紙欄、自由散點構圖，它都做得非常完整，設計感也很強。就我目前測過的多個模型來看，這是海報排版類任務中表現最好的一個。

在「機械腕錶爆炸圖」上，Fable5 生成的結果雖然可以展開並標示零件，但拖曳互動沒有做好；整體視覺上，我反而覺得 GPT5.5 稍微更好一些。

「桌面行星儀」這題則是 Fable5 很亮眼。它對球體材質的處理非常高級，像景泰藍、琉璃等質感表現得很好，而且球體移動時，下方還會有影子跟隨，玻璃反射效果也相當到位。不過它還是有錯，例如齒輪擺放位置不正確。即便如此，整體效果仍明顯優於 GPT5.5；如果用 MAX 模式，理論上應該還會更好。

在「咖啡館排隊曆劇場」這類任務裡，Fable5 雖然比 Opus 4.8 有進步很多，但以我目前的觀察，GPT5 在這題上還是表現更好一些。

至於「迷你印刷機」，Fable5 的整體理解已經很不錯。以前不少模型根本不理解活字排版，字模甚至會做成鏡像；Fable5 至少已經理解概念，也能做出壓印動畫。不過它仍有細節錯誤，例如字應該是凸出的，結果卻做成凹進去。

也在 CC 裡調用 Fable5 X-High 生成「縴夫拉船」場景。這是測過眾多模型中表現最好的一次。水流模擬非常到位，遠山、江面飛鳥等背景細節都有做出來。雖然繩索綁定位置不完全符合現實，但模型有注意到船上應該安排船伕，這點非常關鍵，因為連 GPT5.5 Pro 在內的其他模型都忽略了。更厲害的是，船伕的步態也有動感，整體思考相當完整。

另外，也讓 CC 生成一個展示森林露營房車的體素藝術場景。結果細節非常豐富：房車、展開的棚子、野餐墊、小桌子、花草元素、車頂工具，以及穿過森林縫隙灑落的陽光，都表現得很漂亮，整體是一個非常美的畫面。

最後，讓它嘗試做交通模擬，同樣選擇 X-High 模式。這次就不太理想了，模型思考了 20 多分鐘仍然沒有結果，甚至消耗了額外積分。這個任務至少花了 10 美元都沒解決，最後我只能手動暫停。

總結來說，Fable5 確實是一個更強、更聰明的模型，特別是在視覺理解、設計感、複雜場景細節與部分高階研究任務上，都展現出非常強的能力。但它的缺點也很明顯：價格高、token 消耗大、安全限制嚴格，而且在部分任務上仍不一定全面勝過 GPT5.5。若你追求最前沿能力，Fable5 很值得關注；但若從成本與穩定性來看，是否划算仍要依照實際場景評估。

Codex 核心功能與實戰上手

[AI 分享] Codex核心功能與實戰上手

摘要 : 關於 Codex安裝、登入、專案實作、版本控制與Plugin擴充功能。

內容:

這篇內容主要是在完整介紹 OpenAI 的 Codex，並將它定位為一個功能很全面的 AI 開發工具。除了能寫程式、排查 Bug、執行測試之外，還能管理 Git、操作瀏覽器、控制電腦完成任務。因為功能很多，原文的重點是希望透過系統化講解，幫使用者建立一套清楚的使用思路。

整體內容大致分成三個部分。第一部分是基礎篇，重點在快速上手、安裝登入、核心設定與常見踩坑。第二部分是進階篇，聚焦版本控制、對話管理，以及更有效率地組織與推進開發任務。第三部分則是擴充篇，介紹如何透過 Plugin、Skill、Automation、Mobile 等方式延伸 Codex 的能力邊界。

在安裝與登入部分，內容提到可以直接下載 Codex 安裝到電腦上，例如在 macOS 上拖入 Applications 即可。首次開啟後，Codex 會要求登入，主要有兩種方式：一種是使用 ChatGPT 帳號登入，對應不同訂閱方案；另一種則是透過 OpenAI API Key。原文認為若是一般使用者，直接訂閱方案通常比 API 更方便，並建議至少使用 Plus 方案，才能比較完整體驗 Codex 的能力。

登入完成後，Codex 會先詢問工作類型，並提示是否匯入相關配置或設定手機版，這些步驟都可以先略過。進入主介面後，就能正式開始使用。原文透過一個「筆記軟體」作為示範案例，帶大家理解 Codex 的實際操作流程。

示範中先建立一個專案資料夾，再透過「Work in Project」功能讓 Codex 綁定這個資料夾作為工作目錄。接著直接輸入需求，例如用 HTML 寫一個左右分欄的筆記軟體：左邊是筆記列表，右邊是筆記內容，並提醒它做好測試。Codex 便會開始生成程式碼，必要時還會請求授權啟動本地伺服器來驗證結果。這裡也說明了 Codex 在執行某些操作時，會提供同意、永久允許、跳過或自訂處理方式等不同授權選項。

完成後，可以直接預覽 Codex 產出的 HTML 頁面。原文也展示了如何透過介面按鈕隱藏側欄、放大預覽區，以及持續追問來修改介面內容。這部分想傳達的是，Codex 不只是一次性生成程式碼，而是能在互動中持續迭代。

接著內容進入對話與版本管理。原文特別介紹了 fork 功能，指出它不是傳統意義上的「回滾」，而是從某一則訊息分叉出一個新的對話。fork 有兩種形式：一種是 fork into local，會沿用原本的專案目錄；另一種是 fork into new work tree，會建立一個新的獨立目錄。兩者都只會複製對話脈絡，不會自動回滾程式碼。

如果希望讓程式碼也回到先前狀態，就必須配合 Git 操作。例如先用 git log 找到對應 commit，再手動切回那個版本。原文強調，這也是為什麼 Git 在 Codex 的工作流中非常重要。特別是當對話內容與程式碼版本需要同步時，Git 幾乎是不可或缺的工具。

除了 fork，內容也介紹了對話歸檔功能。使用者可以將不需要的對話先 archive 起來，而不是直接刪除。歸檔後仍可在設定中找回、解除歸檔，或進一步永久刪除。這讓多分支、多任務並行時的對話管理更有彈性。

在 Git 自動化方面，原文提出一個常見需求：希望 Codex 每次修改完程式碼後都自動提交一次 Git commit。雖然可以直接在對話裡要求它這麼做，但這種方式只會在當前對話有效。若想讓這個規則跨對話生效，就需要在專案根目錄建立一個 agents.md 檔案。Codex 在每次新對話啟動時都會自動讀取這個檔案，並把其中內容當作長期指令執行。透過這個方式，就能把像是「每次改完程式碼都要 commit」這類規則固定下來。

後續內容也展示了功能迭代與除錯流程，例如加入淺色／深色主題切換、修復程式問題、啟動 npm 專案檢查運作狀態，以及驗證 markdown 高亮與預覽功能是否正常。這些例子都是在說明 Codex 不只是生成初版，而是能逐步參與真實開發流程中的修正、測試與優化。

在擴充能力部分，原文重點介紹 Plugin。Plugin 可以理解為 Codex 的外掛系統，用來賦予它更多外部操作能力。例如有控制電腦的、操作 Chrome 的、編輯 Excel 的，甚至還有製作簡報的。每個 Plugin 可能包含 App 與 Skill。App 比較像實際可呼叫的工具集合，Skill 則更像是提供給模型參考的操作說明與使用策略。

以 Gmail Plugin 為例，裡面包含可對郵件加標籤、封存郵件等多種 action，也有說明怎麼總結郵件、怎麼分類信件優先級的 Skill。這表示 Plugin 不只是單純增加一個按鈕，而是同時提供操作能力與任務知識。

原文也實測了 Presentations 這個 Plugin，讓 Codex 為筆記軟體產出一份介紹產品設計與技術架構的 PPT。使用者可以直接描述需求，也可以明確指定要使用哪個 Plugin。雖然產出的簡報還有進一步優化空間，但已足以作為初版內容的基礎。

另外兩個較受矚目的 Plugin 是 Chrome 與 Computer Use。Chrome Plugin 讓 Codex 能直接操作瀏覽器，例如打開 Product Hunt 首頁、搜尋今日熱門產品、逐一閱讀產品頁，再整理其特點與連結。這說明 Codex 已經不只是在本地寫程式，也能主動到網路上蒐集資訊並彙整結果。

Computer Use 則讓 Codex 可以直接操作電腦應用程式。示範中，它被要求打開系統日曆，新增一個指定日期時間的行程。Codex 會用獨立的虛擬滑鼠執行操作，不會干擾使用者本身的滑鼠與工作流程。即使在背景執行，也能持續完成指定任務。這部分很清楚地展現出 Codex 已具備某種程度的電腦代理能力。

最後，內容也提到 Skill 的瀏覽與使用方式，指出其實很多 Plugin 背後都依賴 Skill 來指導模型如何完成任務。雖然文末沒有完全展開，但核心意思已很明確：Codex 的能力不只來自模型本身，也來自這些外掛、技能與工具的整合。

總結來看，這篇內容的核心價值在於，透過一個具體專案與多個實戰場景，把 Codex 從安裝登入、專案建立、程式開發、對話分支、Git 管理，到 Plugin 擴充與電腦操作能力，做了一次完整梳理。重點不是單一功能有多炫，而是幫使用者建立一套較完整的 Codex 使用框架。

[AI 分享] Claude Dynamic Workflows解析

摘要 : Claude可自動拆解任務、平行調度大量Agent，並在背景驗證與收斂結果，加速大型工作的完成。

內容:

Anthropic 近期為 Claude Code 加入了名為 Dynamic Workflows 的新功能。用白話來說，過去你交代 Claude 一件大事，通常是由它單獨慢慢完成；現在則是你只要下達一句指令，它就能在背景自動組建一個由數十甚至上百個 Agent 構成的團隊，同時分工處理不同子任務，最後再透過交叉檢查與驗證，整理出一份完整答案。

這項功能的核心，其實是 Claude 先根據你的需求自動寫出一段 Javascript 指令碼，並由這段程式去負責後續的任務編排與執行。這個流程會在背景獨立環境中運作，因此主對話不會被卡住。也就是說，當 Workflow 在執行時，你仍然可以繼續和 Claude 在同一個 Session 中做其他事，等整個流程完成後，Claude 再把最終結論帶回來給你。

Dynamic Workflows 的強大之處，在於它不只是「多叫幾個 Agent 一起做事」而已，而是能夠有層次地拆解任務。舉例來說，一開始可能會先派出少量 Agent，從不同角度蒐集資料；第二階段再擴大 Agent 數量，對取得的內容進行深入閱讀與整理；最後還會再派另一批 Agent 專門負責挑錯、反駁與驗證，直到結論逐漸收斂。各階段要使用多少 Agent、採用哪一種模型，也都由 Claude 自行安排。

另一個重要特色是，這些大量 Agent 在執行過程中產生的中間結果，並不會全部塞進主對話的 Context 中，而是保留在 Workflow 的指令碼變數裡。主對話最後只會收到一份整理完成的結果。這使得 Claude 能在不污染主要 Context 的情況下，處理規模極大的任務，這也是 Dynamic Workflows 與一般 Subagent 或 Agent Team 很大的差別。

此外，Dynamic Workflows 內建了品質把關的概念。它可以讓多個 Agent 從不同角度分析同一問題，再由其他 Agent 專門負責反駁、挑錯與驗證。經過這種多輪攻防後還能成立的結論，通常會比單一模型一次生成的答案更可靠。這種機制就像不是只讓一個人自己檢查作業，而是再找一群人專門來找漏洞。

在成本與效率方面，Dynamic Workflows 還可以依不同階段切換模型。例如在前期大量平行搜尋時，使用較便宜、速度較快的模型；到了最後需要高推理能力來總結與收斂時，再切換到更強的旗艦模型。這樣的配置可以同時兼顧速度、品質與成本。

如果要用一句話總結 Dynamic Workflows，那就是：Claude 會先幫你寫一段指令碼，再由這段指令碼去指揮大量 Agent 完成任務。過去使用者可能需要自己設計複雜的拆解流程與提示詞，現在這部分的工作很大程度被 Claude 自動包辦了，但前提仍是你要知道自己想交付什麼任務。

文中也進一步釐清了幾個容易混淆的概念，包括 Skill、Subagent、Agent Team 與 Workflow。區分它們最簡單的方法，就是看「下一步由誰決定」。如果下一步是由程式碼事先安排好的，那就是 Workflow；如果是 Claude 根據當下情況臨場決定，那就是 Skill、Subagent 或其他 Agent 類型。

其中，Skill 比較像是一份食譜或說明書，用來告訴 Claude 在某種情境下應該怎麼做、使用哪些工具、遵守哪些限制。它本身不是 Agent，而是一組給 Agent 看的規則，因此會佔用主 Context。Skill 主要回答的是「事情怎麼做」，而 Workflow 處理的是「怎麼調度很多人一起做」，兩者不在同一層級，甚至可以搭配使用。

Subagent 則比較像 Claude 臨時派出去執行單一任務的小幫手。它完成工作後，會把結果直接帶回主對話，因此雖然能減少搜尋過程對主 Context 的污染，但如果一次派出太多 Subagent，回傳的大量結果仍可能把主 Context 塞滿。作者用「實習生查資料後把整疊文件堆回桌上」來形容這件事：少量還可以，但一多就會讓桌面爆掉。

相較之下，Workflow 更像是一個在桌子外面先做好整理的人。它能在外部協調大量 Subagent 的工作，把眾多資料先統整、驗收、驗證過後，再只把濃縮後的結論放回主對話。也因為這樣，Workflow 才能真正支撐數十、數百甚至更多 Agent 同時運作，而不讓主對話 Context 爆炸。

整體來看，Dynamic Workflows 的價值在於，它把原本需要人工設計的任務拆解、編排、平行處理與交叉驗證，自動化成一個可在背景運作的工作機制。對於大型研究、長流程分析、需要高可靠度驗證的工作，它能大幅縮短時間，也讓使用者不必自己寫出極其複雜的提示詞或流程控制邏輯。

[AI 分享] 從零打造網頁抓取 Skill

摘要 : 本文示範用一個 Markdown 檔，從零建立網頁抓取 Skill，讓 AI 能自動訪問網頁、解析資料並輸出結構化結果。

內容:

Skill 是 AI 的外掛能力包，現在進一步進入實作。重點在於：如果 AI 只能對話，實際上仍只是聊天工具；只有加上 Skill，AI 才能像被裝上「手和眼」，具備訪問網頁、讀取資料、調用工具與執行任務的能力，真正成為能做事的數位員工。

文中強調，開發 Skill 的門檻其實很低。最小結構只需要一個資料夾，裡面放一個 `Skill.md` 檔案即可。這個檔案分成兩部分：上方是 YAML 後設資料，包含 `name` 與 `description`；下方則是 Markdown 正文，用自然語言寫清楚執行指令。後設資料像名片，讓 AI 快速判斷用途；正文則像操作手冊，在確定要使用時才細讀。

實作範例是一個 `Web-Scraper` Skill。做法是先建立資料夾與 `Skill.md`，目標是讓 AI 接收網址後，自動抓取網頁內容、解析 HTML，並提取結構化資料。技術上可採用 Python 的 `requests` 發送請求，再以 `Beautiful Soup` 解析頁面，足以應付多數基礎抓取需求。

在撰寫內容時，`description` 特別關鍵，因為 AI 會依靠這段文字判斷何時觸發 Skill，因此必須明確描述功能與使用場景，例如：當使用者要求抓取網站、提取頁面資訊時啟用。正文則可依序定義角色、分析頁面結構、選擇解析策略、編寫抓取腳本、驗證資料完整性，並規範輸出格式如 JSON，同時補上錯誤處理與最佳實踐，例如遵守 Robots.txt、設定合理請求間隔與處理超時。

文章也說明了為何採用這種分層設計：因為 AI 的上下文空間有限，若所有 Skill 內容一開始就全部載入，很容易耗盡 Token。透過後設資料先做快速判斷，只有在需要時才載入正文，附屬檔案也按需引用，便能讓多個 Skill 並存且維持效率。Skill 寫完後還要測試 YAML 語法、檔名與觸發效果，若無法正確啟動，通常是描述不夠精準，應從簡單功能開始逐步調整。

對一人公司或小型團隊而言，這類網頁抓取 Skill 的應用非常廣，像是競品價格監控、產業新聞聚合、客戶資料補全等，都能大幅減少手動工作與 SaaS 成本。不過文中也提醒，實際抓取時必須遵守網站服務條款與資料保護法規，只有合規使用，這類自動化能力才能長期發揮價值。

[AI 趨勢] 軟體工程的終結？

摘要 : AI Agent 正逐步改變軟體工程的本質，未來競爭力不再只是寫程式，而是定義意圖、協調代理與驗證成果。

內容:

過去數十年來，軟體工程的核心邏輯一直沒有改變：人類先定義規則，再將規則寫成程式碼，最後讓電腦按照既定邏輯執行。然而，隨著大型語言模型與 AI Agent 的快速發展，這個長期存在的模式正在被重新定義。

傳統軟體的價值建立在程式碼本身。開發團隊透過架構設計、功能開發與持續維護，將業務邏輯固化在系統中。但在 Agent 時代，程式碼開始從核心資產逐漸轉變成執行媒介。當 AI 可以根據目標、上下文與限制條件，在執行過程中動態推理與生成程式碼時，真正重要的已不再是固定規則，而是持續推理的能力。

從軟體商業模式來看，這也是一次重大轉變。第一代軟體是安裝式產品，使用者需要自行維護環境；第二代 SaaS 則將基礎設施與維運交由服務提供商負責。而下一階段的 AaaS（Agent as a Service），使用者甚至不需要操作功能介面，只需描述目標，由代理自主規劃、執行並交付成果。軟體的價值將從提供功能，逐步轉向提供結果。

這樣的變化，也讓軟體工程師的角色開始向上移動。未來的重要能力不再只是撰寫程式，而是成為意圖架構師、代理協調者與結果稽核員。工程師需要將模糊需求轉化為清晰目標，設計多個代理如何分工合作，並建立評估與驗證機制，確保最終結果符合品質要求。

不過，現實並不像許多人想像得那麼樂觀。現階段 AI Agent 在單一、邊界清楚的任務上，成功率已經相當驚人；但當面對真實世界長期演進的大型系統時，仍然會遭遇上下文遺失、錯誤累積、知識斷層以及跨任務一致性等問題。這也是為什麼許多 Agent 在 Demo 中表現亮眼，實際投入企業級開發後卻仍需要大量治理與監控。

從技術演進路徑來看，我們正處於從「工具化」走向「自治化」的過渡階段。未來幾年，AI 將從開發助手進一步成長為能夠獨立完成單一任務的代理，再逐步發展成由 PM、架構師、開發者、測試人員等多角色代理組成的協作團隊。更長遠來看，甚至可能出現具備自我學習、自我修正與自我優化能力的代理生態系統。

因此，真正值得思考的問題已經不是「AI 會不會取代工程師」，而是「工程師是否能夠完成角色升級」。未來的競爭力不在於寫出多少程式碼，而在於能否高品質地定義目標、管理代理、建立監控機制、控制風險並驗證成果。當程式碼逐漸被自動生成時，人類最重要的價值，將是決定方向、建立規則以及確保系統持續朝正確目標收斂。

軟體工程或許不會真正終結，但它的重心正在發生轉移。從程式碼導向走向意圖導向，從功能開發走向結果交付，從單人開發走向代理協作。未來最具價值的人才，可能不再是最會寫程式的人，而是最懂得指揮 AI Agent 團隊的人。

這篇內容與您近期整理的「Prompt Engineering → Loop Engineering」其實形成了一條很有意思的主線：

Prompt Engineer → Context Engineer → Workflow Engineer → Agentic Engineer → Intent Commander

前者講的是 AI 技術能力的演進路徑，後者講的是軟體工程師角色的演進路徑。兩條路線最終都指向同一件事：

未來的核心競爭力，不是產生程式碼，而是讓一群 AI 能穩定產生正確結果。

[AI 分享] AI 應用成熟度六階段

摘要 : AI 的重點已從提示詞設計，逐步演進到建立能自主優化、持續收斂的智慧系統，形成完整的 AI 導入成熟度框架。

內容:

隨著 AI 技術快速發展，許多人仍把焦點放在 Prompt Engineering（提示工程），認為只要會寫提示詞就能充分發揮 AI 能力。但實際上，提示詞只是 AI 應用發展的起點，而不是終點。AI 的使用方法正逐漸從單一互動，演進成完整的系統設計與治理能力。

第一階段是「提示工程（Prompt Engineering）」。這個階段的核心是學習如何與模型溝通，將需求轉換成清楚、可重複使用的指令，提升輸出的品質與穩定性。重點不只是會提問，而是建立能夠重複利用的提示模板。

第二階段是「上下文工程（Context Engineering）」。當模型能力逐漸提升後，影響結果品質的關鍵開始從提示詞本身，轉向模型是否取得足夠且正確的背景資訊。此時需要思考如何管理知識來源、歷史記錄、文件內容與相關資料，讓模型能在完整脈絡下進行判斷。

第三階段是「工具工程（Tool Engineering）」。AI 不再只是生成文字，而是開始具備執行任務的能力。透過串接 API、資料庫、企業系統與各種工具，讓模型能夠查詢資料、操作系統、執行流程，從單純回答問題進化為真正解決問題。

第四階段是「執行環境工程（Harness Engineering）」。當 AI 開始接觸企業系統與重要資料後，管理與治理的重要性大幅提升。此階段重視權限控管、任務狀態管理、驗證機制、安全防護以及監控觀測能力，確保 AI 的運作過程具備可靠性、可追蹤性與可控性。

第五階段是「工作流程工程（Workflow Engineering）」。企業需求往往不是單一步驟即可完成，因此需要將多個任務、多個工具甚至多個代理人（Agent）進行編排，形成可維護、可擴展且可持續運作的工作流程架構。AI 的價值開始從單點能力提升到系統化運作能力。

第六階段則是「迴圈工程（Loop Engineering）」，也是目前最進階的方向。系統不只是執行任務，而是能夠持續進行觀察、行動、評估、反思與重試。透過回饋機制不斷修正決策與策略，逐步收斂到更好的結果，形成真正具備自我優化能力的閉環系統。

從整體發展脈絡來看，AI 的核心演進其實是一條清晰的路徑：

輸出 → 資訊 → 能力 → 環境 → 流程 → 收斂

一開始關注的是模型回答得好不好；接著關注模型是否取得正確資訊；之後重視模型是否具備執行能力；再來建立安全可靠的執行環境；接著將能力組織成完整流程；最後則讓系統具備持續學習與優化的能力。

如果將這套概念套用到企業 AI 導入上，它其實也是一個非常實用的成熟度框架。企業可以藉此檢視目前所處的階段：究竟是還停留在提示詞優化、正在建置知識庫與上下文管理、開始串接工具與系統，還是已經進入工作流程自動化與多 Agent 協作。更重要的是，它能幫助團隊明確判斷下一步該補強的能力，最終朝向具備自主優化與持續成長能力的 AI 系統邁進。

[AI 影響] AI裁員潮下，真正稀缺的是判斷力

摘要 : AI讓程式碼與工時愈來愈便宜，但收入未同步成長；未來更難被取代的，不是高產出者，而是能判斷、對齊並把成果轉成商業價值的人。

內容:

一名工程師面臨公司可能裁掉8000人、自己有10%機率上榜，卻沒有等結果，而是先重新思考「AI裁員」背後的邏輯。他將工作拆成三層：Input（程式碼、Token、工時）、Output（上線功能）、Outcome（使用者願意付費的結果）。

他的核心觀察是：AI讓底層的Input幾乎接近免費，程式碼產出量可能暴增5倍，但真正的商業結果與使用者收入卻未必成長，產品看起來甚至和半年前差不多。問題不在於寫得不夠快，而在於多出來的產出沒有有效轉成價值。

其中有兩道主要瓶頸。第一是「想法品質」：當寫程式的成本變低，原本會被成本淘汰的點子也都能快速上線，結果是垃圾產出變多。第二是「對齊稅」：不同團隊都能用AI高速做出MVP，但彼此假設可能完全衝突，最後卡在判斷、協調與整合，而不是卡在開發速度。

從公司角度看，裁員變成一筆算術題：AI的Token成本遠低於人力成本，標準化、可替代、對齊成本高的職位，最容易被優先裁撤。省下的人力支出，某種程度上正轉化為AI公司的收入，這也是企業加速用AI補位的現實原因。

因此，稀缺能力正在改變。過去值錢的是生產力，如今AI讓大量執行能力快速貶值；未來更重要的是判斷力：知道哪個想法值得做、如何從大量AI輸出中挑出真正有效的方案，以及如何讓互相衝突的方向收斂成一致目標。

面對這種變化，普通人可從三件事開始：第一，停止「會用AI就安全」的幻覺；第二，從Outcome倒推工作，先想清楚它會為誰創造價值；第三，成為能整合技術、產品、數據與業務的人。當Input愈來愈便宜，真正難被取代的，是能把Token變成Outcome的人。

訂閱：文章 (Atom)

2026年6月10日 星期三

2026年6月10日星期三