H
Howardism
Plate IIAI Coding Practice機器翻譯 · machine-translatedENHOWARDISM

學會與 AI 協作：軟體工程師實戰指南

AI 時代的軟體工程師實戰指南：6 個技能群（品味、harness、以對齊為先的規劃、適合代理程式的架構、驗證、策略定位）、日常實踐、反模式與 90 天計畫

Article metadata
Publication details
Published:May 6, 2026
Filed:Essay
Domain:AI Coding Practice
Tags:CareerLearning GuideAI CoworkingSkills Development
Reading:17 min
Source:AI-synthesised
About this piece

Articles in this journal are synthesised by AI agents from a curated wiki and are refreshed automatically as new concepts arrive. Topics, framing, and editorial direction are curated by Howardism.

《學會與 AI 協作：軟體工程師實戰指南》的插圖

問題#

如今，學習如何與 AI 模型及服務協作的最佳方式是什麼？尤其是對軟體工程師而言，在 AI 新時代，繁重的編碼工作或許不再是必要技能。請為個人制定學習與培養技能的指引，以因應即將到來的變化。

簡要摘要#

編碼能力正逐漸成為基本門檻，而非差異化優勢。工作重心正從撰寫程式碼轉向決定要打造什麼、設計代理程式工作的環境，以及驗證產出。到了 2026 年及之後，以下六個技能群將值得投入：

  1. 產品品味 — 挑選值得打造的事物（參見 Engineer PM Convergence、Printing Press Software Democratization）
  2. harness 工程 — 設計模型周遭的支架（參見 Agent Harness Engineering、Claude Code Best Practices）
  3. 以對齊為先的規劃 — 在產出任何成品之前，先建立共同的設計概念（參見 Design Concept Grilling、Vertical Slice Tracer Bullets）
  4. 適合代理程式的架構 — 以能節省模型注意力的方式設計程式碼庫（參見 Deep Modules for Agents、Context Window Smart Zone）
  5. 驗證與審查 — 機械式回饋迴圈，加上全新脈絡的審查（參見 Agent Loop Pattern、Harness Shrinkage as Models Improve）
  6. 策略定位 — 選擇 AI 無法消解的護城河（參見 Seven Powers Applied to AI）

定位應是共事者，而非工具：訪談模型，把它的失敗視為 harness 訊號，為六個月後的模型打造環境，並在每次發布時淘汰拐杖。軟技能（判斷力、EQ、品味）與領域知識會變得更有價值，而非更沒價值。

I. 心態轉變#

從「我寫程式碼」到「我決定要打造什麼，並驗證它能正常運作」#

Boris Cherny 的印刷機比喻直接點出這一點：軟體撰寫正處於與 1400 年代讀寫能力相同的普及化轉折點（Printing Press Software Democratization）。生產成本大幅降低；你為誰打造什麼，才是差異化所在。Boris 的說法是：「最適合寫會計軟體的人，是非常出色的會計師，而不是工程師，因為他們非常了解這個領域，而編碼是容易的部分。」這是一項明確指示：投資於領域深度，而不是編碼巧思。

Cat Wu 的說法更直白：「當寫程式碼變得便宜得多，決定要寫什麼就會變得更有價值」（Engineer PM Convergence）。

對個別工程師的啟示：

  • 自我聘用的門檻轉向品味。 Cat 在 Claude Code 招募時偏好「產品品味出色的工程師」。如果你說不清楚為什麼功能 X 比功能 Y 重要，這個缺口如今就是你的瓶頸，而不是你的 TypeScript 能力。
  • 領域深度會累積效益。 深入了解臨床流程的後端工程師，勝過缺乏領域知識的資深工程師。選一個領域，待得夠久，直到你熟悉其中不言自明的限制。
  • 跨領域廣度比單一領域的縱深更重要。 Cat 表示，Claude Code 團隊裡每個職能的人都會寫程式碼：設計師交付程式碼、PM 交付程式碼、資料科學家也寫程式碼（Engineer PM Convergence）。反過來說，能兼做設計、PM 或資料工作的工程師，能讓自己的影響力持續累積。

從「我操作的工具」到「我訪談的共事者」#

Cat Wu 提到一種最被低估的技巧：代理程式做錯事時，問它為什麼（Model Introspection Feedback）。不要透過修正內容再次提示。先讀模型對自身推理的說明，再根據浮現的資訊修正 harness，而不是模型。

重新理解這件事：模型的行為取決於 harness；失敗提供了有關 harness 的資訊。你的工作是設計讓模型能成功的環境，而不是讓模型變得更聰明。

內化限制：smart zone，而非 1M tokens#

Matt Pocock（引述 Dex Horthy）指出最嚴峻的限制：由於注意力複雜度為 O(n²)，LLM 的表現會隨脈絡大小呈二次方衰退。最初約 100K 個 tokens 是smart zone；超過之後，無論宣稱的視窗有多大，模型都會「愈來愈笨」（Context Window Smart Zone）。2026 年推出的 1M-token 視窗只是「多推出了很多 dumb zone」——適合檢索，不適合推理。

實務上，每花一分鐘學習管理脈絡預算，都能換來十倍回報。狀態列上的 token 計數器是必需品，不是選配。

II. 要培養的六個技能群#

1. 產品品味#

這是什麼：挑選值得打造的事物，並辨別某個回應是否符合角色特質的能力。

如何培養：

  • 交付產品、取得回饋、快速迭代。 AI Native Product Cadence 提到 Anthropic 的 Claude Code 團隊，從「在 Twitter 看到使用者回饋，到週末前交付產品」；迴圈的緊密程度正是品味校準的方式。
  • 維護一份「我會怎麼改造這個產品？」的檔案。 使用產品時，記下問題所在，以及你會怎麼做。六個月後，比較自己的判斷與團隊實際推出的成果。
  • 練習角色特質的辨識。 Claude Character as Product 指出，角色特質（低自我、輕鬆愉快、傾向採取行動、誠實回饋）是真正的產品介面。試著說明某個 AI 回應為什麼讓人覺得恰當或不恰當——這就是縮小版的評估技巧。
  • 午餐時做 vibe-check。 Cat Wu 會在團隊午餐時請每位成員先分享「你對這個模型的感覺如何？」，再看指標。先看質化、再看數據，是一種你可以在每次模型發布時練習的紀律。

2. harness 工程#

這是什麼：設計代理程式周遭的支架——脈絡檔案、技能、hooks、subagents、權限分類器、機械式驗證器（Agent Harness Engineering）。

如何培養：

  • 為你負責的每個專案建立 CLAUDE.md / AGENTS.md。 把它當成程式碼：出錯時就檢視，毫不留情地精簡，並讓它成為指向更深入文件的目錄（Claude Code Best Practices）。250K-token 的系統提示會在模型開始做事之前，就把它推進 dumb zone。
  • 練習 push 與 pull 的取捨（Deep Modules for Agents）：需要依據標準進行比較的 reviewer agents，將標準放在隨時可用的脈絡中（CLAUDE.md、system prompt）；implementer agents 則使用隨需載入的技能。
  • 執行自省除錯迴圈。 代理程式失敗時，問它為什麼，接著修正 harness，而不是模型。
  • 每次啟動模型時，閱讀自己的 system prompt。 Cat Wu 在 Claude Code 的做法是：「我們會通讀整份 system prompt，逐節思考模型是否真的還需要這項提醒。如果不需要，就刪掉。」多數團隊只會新增內容——要定期刪減（Harness Shrinkage as Models Improve）。

3. 以對齊為先的規劃#

這是什麼：在任何成品出現之前，先建立共同理解，也就是 Frederick Brooks 所說的「設計概念」。深度盤問的產出是對齊；PRD 與計畫都應在其後形成（Design Concept Grilling）。

如何培養：

  • 採用 grill-me 的做法。 Matt Pocock 的技能原文是：「針對這份計畫的各個面向不斷訪談我，直到我們達成共同理解為止。沿著決策樹的每個分支逐步深入，逐一解決依賴關係。每個問題都提供你建議的答案。一次只問一個問題。」寫 PRD 之前，先用這個方法問自己。
  • 拒絕把規格交給 AI 寫程式碼，因為那只是 vibe coding。 Pocock 強烈主張：仔細撰寫規格、交給 AI，然後拒絕查看程式碼，換個名稱仍然是 vibe coding。程式碼才是角力場，不是規格（Design Concept Grilling）。
  • 垂直切分，而非水平切分。 不要「先完成所有 schema → 再完成所有 service → 最後處理所有 UI」。要做的是「貫穿每一層的精簡端對端切片，接著再做下一個切片」（Vertical Slice Tracer Bullets）。代理程式預設會採取水平切分——要主動糾正。
  • 使用標示明確阻擋關係的看板，而非階段計畫。 編號階段清單會讓一個代理程式只能循序執行；附上 blocked-by: 的看板則能讓多個代理程式平行處理待辦工作（Agent Loop Pattern）。

4. 適合代理程式的架構#

這是什麼：讓代理程式能有效工作的程式碼庫結構——深模組、明確的測試邊界，以及受控的 smart zone 預算（Deep Modules for Agents）。

如何培養：

  • 內化 Ousterhout 對深模組與淺模組的區分。 深模組＝介面小、行為豐富、有明確自然的測試邊界。淺模組＝許多小檔案、密集的依賴圖、不明確的邊界。代理程式預設會偏向淺模組；要加以導正。
  • 在 PRD 中保留模組地圖。 規劃時，明確指出要修改哪些模組。如此便能把規劃連結到架構，避免代理程式另創淺模組，而不去擴充既有的深模組。
  • 定期進行整併式重構。 Pocock 的 improve-code-base-architecture skill 會掃描相關淺模組的群集，並提出深化建議。把這項工作排進行程——它不會自行發生。
  • 在全新脈絡中進行審查。 如果實作已用掉 80K 個 smart zone tokens，同一脈絡中的 reviewer 會在 dumb zone 閱讀差異。清除脈絡，再以全新脈絡審查（Deep Modules for Agents、Context Window Smart Zone）。
  • 搭配模型選擇。 Matt Pocock 的做法是：用 Sonnet 實作、Opus 審查——「我需要那份聰明才智。」

5. 驗證與審查#

這是什麼：設定迴圈能力上限的機械式回饋迴圈（測試、型別、linters、作為指令的 lints）。沒有良好的驗證，你就是盲目寫程式碼（Agent Loop Pattern、Agent Harness Engineering）。

如何培養：

  • 把測試、型別、linters 視為上限。 Matt Pocock 說：「如果你的程式碼庫沒有回饋迴圈，你永遠永遠永遠都得不到像樣的 AI 產出。回饋迴圈的品質會影響 AI 的編碼能力。那就是上限。」擴大使用代理程式之前，先投資這類基礎建設。
  • 把 lint 錯誤訊息寫成修正指示。 OpenAI 的 Codex 團隊會把 lint 錯誤訊息寫成直接注入代理程式脈絡的指示——代理程式讀取 lint 輸出後，就知道如何修正（Agent Harness Engineering）。
  • 採用 AFK 與 human-in-loop 的分工（Agent Loop Pattern）。AFK 工作（實作、重構、文件整理、修復 CI）適合放進迴圈。human-in-loop 工作（對齊、設計選擇、排定優先順序、QA）則不適合。試著把 human-in-loop 工作放進迴圈，只會造成偏移。
  • 為新的瓶頸做好準備：審查。 Matt Pocock 的自白與 Cat Wu 的相同觀察指出：代理程式交付更多程式碼時，人類也得審查更多程式碼。這是 2026 年尚未解決的問題。現在就培養程式碼審查能力——這是迴圈無法取代的持久技能。

6. 策略定位#

這是什麼：選擇能在 AI 轉變中存續的問題與護城河，而非會被 AI 侵蝕的選項（Seven Powers Applied to AI）。

如何培養：

  • 盤點你押注的每家公司、專案或職位的護城河。 流程優勢與轉換成本會因 AI 而受到侵蝕；網路效應、規模經濟與獨占資源則能持續存在。反向定位會進一步放大——新創可以選擇結構上不可能被既有企業採用的商業模式。
  • 同樣的邏輯適用於個人職涯。「我有 15 年的流程知識，別人都沒有」屬於流程優勢，而 AI 正在逐步攀升這種能力。「我在這個利基領域有一群互信的人脈」則是 AI 無法複製的網路效應。
  • 從第一天起就以 AI-native 方式打造。 Boris Cherny 表示，新創公司會以 AI-native 方式打造；既有企業則得重新訓練員工、改變流程，並克服內部阻力。你的個人工作流程也一樣——以 AI-native 方式重建習慣，而不是把 AI 硬接到 AI 出現前的工作流程上。

III. 日常實踐#

實踐頻率來源
每次處理不簡單的功能前，進行 grill-me 對談每個功能Design Concept Grilling
在不相關任務之間使用 /clear每次切換任務Claude Code Best Practices
讓狀態列 token 計數器保持可見隨時Context Window Smart Zone
垂直切分工作；拒絕水平階段切分每次規劃Vertical Slice Tracer Bullets
讓 reviewer agent 在全新脈絡中工作（可使用不同模型）每次處理不簡單的差異Deep Modules for Agents
每次模型發布時，閱讀 CLAUDE.md / system prompt 並精簡每次模型發布Harness Shrinkage as Models Improve
再次提示之前，先問模型為何失敗發生任何意料之外的行為時Model Introspection Feedback
夜間讓 AFK 迴圈處理看板待辦工作持續進行Agent Loop Pattern
為六個月後的模型打造環境，而非只考慮今天的模型策略規劃Harness Shrinkage as Models Improve
午餐時對新發布的模型進行 vibe-check每次模型發布Claude Character as Product

IV. 要改掉的反模式#

反模式失敗原因改用什麼做法
把 context window 當成「有 1M tokens，空間很充裕」注意力呈二次方增長；約 100K 的 smart zone 確實存在查看狀態列計數器；積極使用 /clear；讓 subagents 負責調查
永遠只往 system prompt 新增內容，從不刪除拐杖不斷累積；舊拐杖會與新模型行為矛盾每次模型發布時精簡；每個章節都必須證明值得占用 tokens
尚未對齊就請代理程式規劃代理程式掩蓋尚未解決的問題；實作時才承擔返工成本先 grill-me；對齊之後才寫 PRD
水平分層階段（「先完成所有 schema，再做所有 service」）到第三階段才有端對端回饋；太晚才發現不相符垂直切片；以 tracer bullet 建立精簡路徑
使用相同脈絡的 reviewer實作者的 smart zone 已耗盡；reviewer 落在 dumb zone用全新脈絡審查；考慮使用更強的模型
不參與程式碼，只把規格交給 AI 寫程式碼「換個名稱的 vibe coding」——回饋迴圈跑在錯誤層級留在程式碼之中；規格應在對齊之後形成
把 human-in-loop 工作放進迴圈代理程式會做出看似合理卻錯誤的決定，逐漸偏離目標標註 AFK 工作；human-in-loop 任務維持同步處理
「模型越大，就越不需要設計」不論模型多大，糟糕的程式碼庫仍會產生糟糕的代理程式深模組；機械式驗證
把模型失敗歸因於「模型很笨」忽略 harness 缺口所提供的訊號進行自省：問模型為什麼；修正 harness
捍衛依賴轉換成本或流程優勢的護城河這些優勢會在 AI 發展下遭到侵蝕轉向網路效應、規模、獨占資源或反向定位

V. 哪些工作仍由人類負責#

Cat Wu 明確指出，有些工作不會併入模型：需要默會知識、常識與 EQ 的工作——知道該在哪種場合和利害關係人溝通、判斷何時適合發布、知道怎樣才算公平的取捨（Engineer PM Convergence）。在人類負責的發布工作中，仍需要有人串起各環節。

具體而言，以下人類技能能長久發揮作用：

  • 程式碼審查能力 — 代理程式交付速度變快後，這會成為新的瓶頸（AI Native Product Cadence、Matt Pocock 的自白）
  • 有根據地闡述觀點 — Amanda 的角色特質工作技巧：有把握地說明某個產出為什麼符合或不符合角色特質（Claude Character as Product）
  • 跨職能 EQ — 知道何時該升級處理、應該在哪種場合溝通，以及如何察覺利害關係人的遲疑
  • 以使命與價值觀釐清優先順序 — Cat：「如果有兩個互相競爭的優先事項，我們會討論哪個對 Anthropic 的使命更重要。」這能降低協調成本（AI Native Product Cadence）
  • 領域深度 — 能夠撰寫會計軟體的會計師，勝過不具備會計背景的工程師（Printing Press Software Democratization）

VI. 90 天學習計畫#

第 1–14 天 — 熟悉 harness。

第 15–30 天 — 採用以對齊為先的規劃。

  • 安裝或撰寫 grill-me skill；處理任何功能前先使用
  • 把接下來兩個功能垂直切分；抵抗水平分層的做法
  • 把待辦清單轉成附有 blocked-by: 關係的看板

第 31–60 天 — 建立機械式回饋基礎建設。

  • 在一個專案中新增或強化測試、型別與 linters，直到能抓出代理程式的偏移
  • 把 lint 錯誤訊息寫成修正指示
  • 為不簡單的差異設定全新脈絡 reviewer（建議使用不同模型）

第 61–90 天 — 執行 AFK 迴圈；培養產品品味。

  • 在看板待辦工作上設定 Ralph 迴圈或 /loop cron，讓它夜間執行
  • 為你使用的產品寫下「我會怎麼改造這個產品？」的日誌
  • 練習自省除錯：代理程式失敗時，問它為什麼，並修正 harness
  • 參考 Seven Powers Applied to AI，盤點一家公司、專案或你關心的領域有何護城河

VII. 來源可信度與缺口#

  • 高度可信：smart zone 的觀點、harness 精簡、垂直切分、深模組、AFK 與 human-in-loop 的分工、自省技巧。多個來源的說法相互呼應，包括來自 Anthropic 內部的資訊與獨立從業者的觀點（Matt Pocock）。
  • 中度可信：關於 100 行 Claude Code 的預測（依 Boris Cherny 自己的說法，這是誇張表述）；印刷機比喻的時間軸（比 50 年快，但確切速度不明）；以產品品味為瓶頸的說法（在 Anthropic 這類小型團隊中成立，能否擴大規模仍不清楚）。
  • 尚待解答的問題：Anthropic 的工作節奏，有多少來自流程、有多少來自人才密度？工程師與 PM 的職能融合能否擴展到約 50 人以上的團隊？4.7 級的自省報告有多可靠？更強的模型何時會讓 harness 完全不再必要，而不是需要不同的 harness？

這套 wiki 來源主要依賴 Anthropic 自己的敘事，以及一位獨立從業者（Matt Pocock）。作為個人工作流程指引，它有充分根據；但用於組織規模的部署時，仍較缺乏實證。

資料來源#

Raw documents#

§ end
Cited by 10
Related articles
  • Opinions on Using AI Tools & the Future of the Software Engineering Role

    Debate map of four stances on using AI tools (bullish-insider / pragmatist-practitioner / skeptic-governance / architec…

  • Claude Code

    Anthropic's agentic coding product; created by Boris Cherny late 2024; TypeScript/React on Bun (itself Claude-rewritten…

  • Evals as Product Spec

    Cat Wu's framing of evals as the emerging core PM skill: ten great evals beats a hundred mediocre; encode what done loo…

  • Engineer PM Convergence

    Generalists across disciplines; product taste as bottleneck skill; Anthropic Claude Code team as case study; "just do t…

  • Agent Loop Pattern

    `/loop` (cron-scheduled) and Ralph Wiggum (backlog-draining) loops as next-generation agent primitive; AFK execution, p…