背景

本文探討了一套針對 Claude Code 的開發工作流，核心原則在於將「規劃」與「執行」嚴格分離。作者主張在讓 AI 撰寫任何代碼之前，必須先經過深度的研究階段並產出研究報告，接著制定詳細的實作計畫，並由開發者在 Markdown 文件中進行多次人工標註與修正，確保 AI 完全理解系統架構與業務邏輯後才開始動工。

社群觀點

針對這套高度結構化的 AI 開發流程，Hacker News 社群展現了兩極化的反應。支持者認為這種方式能有效克服 AI 容易產生的「幻覺」與表面化理解。有留言指出，將計畫與待辦事項轉化為持久性的 Markdown 文件，不僅是為了應對當前大型語言模型的上下文限制，更是一種優良的專案管理實踐。透過這種方式，開發者可以隨時重置對話視窗而不遺失進度，甚至能將這些文件視為輕量級的工單系統，用於追蹤長期項目的演進。部分資深工程師分享，這種工作流讓他們能維持在更高層次的架構思考，避免被瑣碎的語法細節消耗精力，且 AI 在處理重複性高、容易因疲勞出錯的任務時，表現往往比人類更穩定。

然而，反對聲音則質疑這種流程的生產力效益。部分經驗豐富的開發者認為，對於具備中高階能力的工程師而言，花費大量時間進行繁瑣的提示詞工程、撰寫研究報告並反覆標註計畫，其工作量可能已經超過了直接動手寫代碼。他們批評這是在追求「寫最少的代碼」而非「最高的生產力」，甚至戲稱這只是在增加 Anthropic 的營收。對此，支持者反駁道，雖然簡單的任務直接撰寫較快，但面對複雜的既有系統，AI 往往能在幾十分鐘內完成人類需要一兩天才能搞定的功能，關鍵在於開發者是否願意投入時間學習如何正確地與 AI 協作。

討論中另一個有趣的技術爭議點在於提示詞的有效性。原文提到的「深入研究」、「不要停下」等強調語氣，被部分網友質疑是否真的能影響模型行為。有觀點從注意力機制解釋，認為這類措辭能引導模型將更多權重放在實作細節而非僅是函數簽名；但也有人感嘆，軟體開發正進入一個奇怪的時代，開發者必須像對待小孩一樣用各種強調語氣來「哄騙」電腦執行任務，這讓原本強調確定性與可重複性的工程領域變得充滿了隨機性與不確定感。

此外，社群也延伸出許多自動化管理的討論。有開發者分享了更進階的「子代理人」模式，即由主代理人負責規劃，再指派多個子代理人分別執行實作、測試與代碼審查，最後自動生成拉取請求。這種將複雜任務拆解為微小單元並平行處理的趨勢，顯示出開發者正試圖在人工干預與全自動化之間尋找新的平衡點。

延伸閱讀

• Antigravity Implementation Plan：Google 內部使用的實作計畫文檔規範。
• Plannotator：一個專為標註與視覺化 AI 計畫而設計的工具。
• Superpowers：一套用於驅動子代理人開發流程的工具集。
• Dozy：將規劃與執行分離概念應用於時間管理的排程工具。