H
Howardism
Plate II機器翻譯 · machine-translatedENHOWARDISM

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

PublishedMay 28, 2026FiledEssayTagsCareerLearning GuideAI CoworkingSkills DevelopmentReading17 minSourceAI-synthesised

AI 時代軟體工程師實戰指南：6 大技能群組（品味、harness、對齊優先規劃、agent 友善架構、驗證、策略定位）、日常實踐、反模式、90 天計畫

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

問題#

在當今時代，學習並與 AI 模型和服務協作的最佳方式是什麼——特別是對於在新 AI 時代可能不再需要大量編碼任務的軟體工程師？為個人制定學習和發展技能的指南，以應對即將到來的變化。

TL;DR#

編碼技能正在成為基準線，而非差異化因素。工作正從寫程式碼遷移到決定要建構什麼、設計 agent 工作的環境，以及驗證輸出。六大技能群組在 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. 為 agent 設計的架構 — 節省模型注意力的程式碼庫形態（參見 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 提到的最被低估的技巧：當 agent 做錯事時，問它為什麼（Model Introspection Feedback）。不要用修正重新提示。閱讀模型對自身推理的描述，然後根據浮現的資訊修復 harness——而非模型。

重新框定：模型的行為是 harness 的函數；失敗是關於 harness 的資訊。你的工作是設計一個模型能成功的環境，而不是讓模型更聰明。

內化約束：smart zone，而非 1M tokens#

Matt Pocock（引用 Dex Hardy）框定了最困難的約束：LLM 隨著上下文大小呈二次方退化，因為注意力是 O(n²)。前約 100K tokens 是 smart zone；超過之後模型「越來越笨」，無論宣傳的視窗大小（Context Window Smart Zone）。2026 年推出的 1M-token 視窗「只是推出了更多的笨區」——對檢索有用，對推理無用。

實務上：每一分鐘花在學習管理 context 預算上的時間都會十倍回報。狀態列 token 計數器是必要的，不是可選的。

II. 六大技能群組#

1. 產品品味#

定義：選擇正確的東西來建構，並辨識回應是否符合角色特質的能力。

如何培養：

  • 交付產品、獲取回饋、快速迭代。 AI Native Product Cadence 報告 Anthropic 的 Claude Code 團隊從「在 Twitter 上看到使用者回饋到週末前交付產品」——迴圈的緊密度就是品味校準的方式。
  • 維護一份「我會怎麼做不同？」的檔案。 當你使用一個產品時，記下什麼是錯的以及你會怎麼做。將你的判斷與團隊六個月後實際交付的內容進行比較。
  • 練習角色工作。 Claude Character as Product 展示了角色（低自我、輕鬆、偏向行動、誠實回饋）是真正的產品表面。試著闡述為什麼一個給定的 AI 回應感覺對或錯——那就是同樣的 eval 技能的縮影。
  • 午餐時間氛圍檢查。 Cat Wu 在團隊午餐時問每個成員「你對模型的感覺如何？」然後才看指標。定性優先、數據其次是一種你可以在每次模型發布時練習的紀律。

2. Harness 工程#

定義：設計 agent 周圍的腳手架——上下文檔案、技能、hooks、subagents、權限分類器、機械式驗證器（Agent Harness Engineering）。

如何培養：

  • 為你擁有的每個專案建立 CLAUDE.md / AGENTS.md。 像對待程式碼一樣對待它：出問題時審查、無情地修剪、將其保持為指向更深文件的目錄（Claude Code Best Practices）。250K-token 的 system prompt 在模型做任何事之前就把它推入笨區。
  • 練習推送 vs 拉取的紀律（Deep Modules for Agents）：對需要標準來比較的審查者 agent 使用始終在上下文中的內容（CLAUDE.md、system prompt）；對實作者 agent 使用按需技能。
  • 執行內省除錯迴圈。 當 agent 失敗時，問它為什麼，然後修復 harness——而非模型。
  • 在每次模型發布時閱讀你自己的 system prompt。 Cat Wu 在 Claude Code 的紀律：「我們通讀整個 system prompt 並反思，對於每個部分，模型真的還需要這個提醒嗎？如果不需要，就移除它。」大多數團隊只會增加——按節奏減少（Harness Shrinkage as Models Improve）。

3. 對齊優先規劃#

定義：在任何產出物之前達成共同理解（Frederick Brooks 意義上的「設計概念」）。grilling 的產出是對齊；PRD 和計畫是下游的（Design Concept Grilling）。

如何培養：

  • 採用 grill-me 紀律。 Matt Pocock 的技能，原文：「針對這個計畫的每個面向不斷面試我，直到我們達成共同理解。走過決策樹的每個分支，逐一解決依賴關係。對每個問題提供你建議的答案。一次問一個問題。」在寫 PRD 之前對自己使用這個。
  • 拒絕將規格到程式碼視為 vibe coding。 Pocock 的強烈主張：寫一份仔細的規格、交給 AI、然後拒絕看程式碼，這是另一種形式的 vibe coding。程式碼是戰場，不是規格（Design Concept Grilling）。
  • 垂直切片，而非水平切片。 不要做「所有 schema → 所有服務 → 所有 UI」。要做「穿過每一層的薄切片，端到端，然後下一個切片」（Vertical Slice Tracer Bullets）。Agent 預設會水平切——要主動推回。
  • 建立帶有明確阻塞邊的 Kanban，而非階段計畫。 編號的階段列表將一個 agent 鎖定在順序執行中；帶有 blocked-by: 的 Kanban 讓多個 agent 並行消化它（Agent Loop Pattern）。

4. 為 agent 設計的架構#

定義：讓 agent 能有效工作的程式碼庫形態——深模組、清晰的測試邊界、節省的 smart-zone 預算（Deep Modules for Agents）。

如何培養：

  • 內化 Ousterhout 的深 vs 淺區分。 深模組 = 小介面、大行為、一個自然的測試邊界。淺模組 = 許多小檔案、密集的圖、不清晰的邊界。Agent 預設會漂向淺模組；要推回。
  • 在你的 PRD 中保留模組地圖。 規劃時，明確命名要修改的模組。這將規劃連接到架構，防止 agent 發明新的淺模組而非擴展現有的深模組。
  • 定期執行整合的重構。 Pocock 的 improve-code-base-architecture 技能掃描相關淺模組的叢集並提議加深它們。排程這項工作——它不會自己發生。
  • 在全新上下文中審查。 如果實作使用了 80K tokens 的 smart zone，同一上下文的審查者在笨區閱讀 diff。清除並在全新上下文中審查（Deep Modules for Agents、Context Window Smart Zone）。
  • 搭配模型選擇。 Matt Pocock：實作用 Sonnet，審查用 Opus——「那時候我需要聰明的。」

5. 驗證與審查#

定義：機械式回饋迴圈（測試、型別、linters、lint-as-instructions），設定迴圈能做到的上限。沒有好的驗證，你就是盲目編碼（Agent Loop Pattern、Agent Harness Engineering）。

如何培養：

  • 將測試/型別/linters 視為上限。 Matt Pocock：「如果你的程式碼庫沒有回饋迴圈，你永遠不會得到像樣的 AI 輸出。你的回饋迴圈品質影響你的 AI 能寫多好的程式碼。那就是上限。」在擴展 agent 使用之前投資這個基礎設施。
  • 將 lint 錯誤訊息寫成修復指令。 OpenAI 的 Codex 團隊將 lint 錯誤訊息寫成直接注入 agent 上下文的指令——agent 讀取 lint 輸出並知道如何修復它（Agent Harness Engineering）。
  • 採用 AFK vs human-in-loop 的分割（Agent Loop Pattern）。AFK 任務（實作、重構、文件維護、CI 修復）適合迴圈。Human-in-loop 任務（對齊、設計選擇、優先排序、QA）不適合。試圖迴圈 human-in-loop 工作會產生漂移。
  • 為新瓶頸做準備：審查。 Matt Pocock 的坦白和 Cat Wu 的相同觀察：當 agent 交付更多程式碼時，人類審查更多程式碼。2026 年未解決的問題。現在就培養你的程式碼審查流暢度——這是迴圈無法取代的持久技能。

6. 策略定位#

定義：選擇在 AI 轉變中存活的問題和護城河，而非在其下被侵蝕的（Seven Powers Applied to AI）。

如何培養：

  • 審計你押注的任何業務/專案/角色的護城河。 流程力量和轉換成本在 AI 下被侵蝕；網路效應、規模經濟和壟斷資源持續存在。反定位放大——新創公司可以選擇既有企業在結構上無法採用的商業模式。
  • 在個人職涯層面，同樣的邏輯適用。 「我有 15 年沒有其他人擁有的流程知識」是 AI 正在爬坡的流程力量。「我在這個利基市場有一個信任關係網路」是 AI 無法複製的網路效應。
  • 從第一天就以 AI 原生方式建構。 Boris Cherny：新創公司以 AI 原生方式建構；既有企業必須重新培訓人員、改變流程、克服內部阻力。同樣適用於你的個人工作流程——以 AI 原生方式重建你的習慣，而非將 AI 嫁接到 AI 之前的工作流程上。

III. 日常實踐#

實踐頻率來源
在任何非瑣碎功能前執行 grill-me session每個功能Design Concept Grilling
在不相關任務之間 /clear每次任務切換Claude Code Best Practices
保持狀態列 token 計數器可見始終Context Window Smart Zone
垂直切片工作；拒絕水平分階段每次規劃 sessionVertical Slice Tracer Bullets
在全新上下文中使用審查者 agent（不同模型亦可）每個非瑣碎 diffDeep Modules for Agents
在每次模型發布時閱讀你的 CLAUDE.md / system prompt；修剪每次模型發布Harness Shrinkage as Models Improve
在重新提示之前問模型為什麼失敗任何非預期行為時Model Introspection Feedback
在 Kanban 待辦事項上整夜執行 AFK 迴圈持續Agent Loop Pattern
為六個月後的模型建構，而非今天的策略視野Harness Shrinkage as Models Improve
新模型發布時的午餐氛圍檢查每次模型發布Claude Character as Product

IV. 需要戒除的反模式#

反模式為何失敗應該怎麼做
將 context window 視為「1M tokens，空間充裕」二次方注意力；約 100K 的 smart zone 是真實的狀態列計數器；積極 /clear；用 subagents 做調查
永遠只增加 system prompt，從不移除拐杖累積；舊拐杖與新模型行為矛盾每次模型發布時修剪；每個部分必須證明其 tokens 的價值
在對齊之前要求 agent 制定計畫Agent 掩蓋未解決的問題；重工成本在實作中支付先 grill-me；對齊之後才寫 PRD
水平分層階段（「所有 schema，然後所有服務」）直到第三階段才有端到端回饋；不匹配的代價付得晚垂直切片；tracer bullets 薄路徑
同一上下文的審查者實作者的 smart-zone 已耗盡；審查者在笨區全新上下文審查；考慮用更強的模型審查
規格到程式碼但不接觸程式碼「另一種形式的 vibe coding」——回饋迴圈跑在錯誤的層留在程式碼中；規格是對齊的下游
迴圈 human-in-loop 工作Agent 做出看似合理但錯誤的決定；漂移累積AFK 標記；human-in-loop 任務保持同步
「更大的模型 = 不需要設計」糟糕的程式碼庫無論模型大小都產生糟糕的 agent深模組；機械式驗證
將模型失敗視為「模型很笨」錯過關於 harness 缺口的訊號內省：問模型為什麼；修復 harness
防守轉換成本/流程力量護城河這些在 AI 下被侵蝕轉向網路效應/規模/壟斷資源/反定位

V. 什麼仍屬於人類#

Cat Wu 明確指出什麼不會融入模型：隱性的、常識性的、高 EQ 的工作——知道與利害關係人溝通的正確場合、感知何時準備好發布、知道什麼算是公平的取捨（Engineer PM Convergence）。人類仍然提供貫穿整個發布的連接組織。

具體持久的人類技能：

  • 程式碼審查流暢度 — 當 agent 交付更快時的新瓶頸（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 技能；在任何功能之前使用它
  • 將你接下來的兩個功能垂直切片；抵抗水平分層
  • 將你的待辦清單轉換為帶有 blocked-by: 邊的 Kanban

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

  • 在一個專案中增加或強化測試/型別/linters，直到它們能捕捉 agent 漂移
  • 將 lint 錯誤訊息寫成修復指令
  • 為非瑣碎 diff 設定全新上下文審查者（偏好不同模型）

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

  • 在你的 Kanban 待辦事項上設定 Ralph loop 或 /loop cron 整夜執行
  • 為你使用的產品維護一份「我會怎麼做不同？」日誌
  • 練習內省除錯：當 agent 失敗時，問為什麼，修復 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 的節奏有多少是流程 vs 人才密度？工程師-PM 融合能否擴展到約 50 人以上的團隊？4.7 級內省報告有多可靠？更強的模型何時會使 harness 完全不必要 vs 需要不同的 harness？

wiki 來源集嚴重依賴 Anthropic 自己的敘事和一位獨立實踐者（Matt Pocock）。作為個人工作流程指導有充分根據，對組織規模部署的實戰測試較少。

資料來源#

Raw documents#

§ end
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.

Cited by 8
Related articles