我的 AI 輔助工作流：在開發速度與可維護性之間取得平衡

背景

這篇文章探討了開發者在 AI 輔助開發時代面臨的困境：雖然 AI 能極速產出程式碼，卻往往導致開發者對系統架構的理解力下降，並埋下難以維護的隱患。作者提出了一套以「思考」為核心的 AI 工作流，強調在撰寫程式碼之前，必須透過自由草案、結構化 PRD、垂直切分的 Issue 以及細化的 Task 等步驟，利用 AI 作為壓力測試的對象而非僅是代碼生成器，藉此確保軟體開發的意圖與品質。

社群觀點

這套工作流在 Hacker News 社群引發了兩極化的討論。部分資深開發者對此類「AI 工作流」文章感到疲勞，認為這不過是將過去二十年前開發者熱衷於分享編輯器設定檔的行為，轉化為現代的「影響者內容」。批評者指出，這種高度結構化的流程在本質上是「瀑布式開發」的變體，過度依賴繁瑣的規格文件，反而可能陷入「生產力劇場」的陷阱，讓開發者在處理瑣碎且平庸的任務上耗費過多精力。更有意見直指，如果需要如此刻意且費力的引導才能讓 AI 產出正確結果，那麼 AI 承諾的自動化效率便顯得名不虛傳，甚至有人質疑這類流程是為了在 LinkedIn 等平台獲取關注而刻意包裝的產物。

然而，另一派觀點則對此持開放態度，認為分享經驗是社群進步的基石。支持者指出，這套流程的核心價值在於「強迫開發者在動手前先思考」，這正是許多人在使用 AI 時最容易忽略的環節。有留言提到，這種以規格驅動的工作模式能有效釐清邏輯漏洞，例如透過 AI 的「壓力面試」來發現未考慮到的邊緣案例或身分驗證邏輯。此外，社群中也出現了關於「敏捷」與「瀑布」定義的辯論，有觀點認為，只要回饋週期夠短且具備靈活性，預先撰寫規格並非壞事，反而是找回軟體工程嚴謹性的一種方式。

在實務操作層面，社群成員也分享了各自的優化方案。有人建議將 AI 引入「橡皮鴨偵錯」階段，用來驗證初步構想而非直接生成 PRD；也有人提到「變異測試」的概念，即要求 AI 在程式碼中刻意製造合理的錯誤，以測試現有的測試案例是否足夠強健。值得注意的是，有開發者利用 AI 對這套工作流本身進行了元編程分析，指出雖然流程完整，但在技能設計上可能過於依賴強制性程序，缺乏對異常模式的處理。整體而言，社群共識趨向於認為 AI 工具確實改變了開發節奏，但如何平衡「開發手感」與「自動化流程」，仍是每位開發者需要根據自身需求去調整的課題。

延伸閱讀

在討論串中，開發者們分享了多項實用的工具與資源，包含 Matt Pocock 開發的 Sandcastle 專案與相關 Agent 技能，這些是作者工作流的核心基礎。此外，也有人推薦了針對任務自動化的 tasks-ai 工具，以及將類似工作流整合進 Notion 的 notion-agent-hive 專案。對於偏好專案管理工具的開發者，則有留言提到如何將此流程與 Linear 平台結合，實現更自動化的 Issue 追蹤與執行。