你你

Agentic Engineering for PMs: Review Artifacts, Not Code (PM的代理工程：審查產出物，而非程式碼)

原始來源與檔名：2026-06-02T092302+0800-Agentic Engineering for PMs Review Artifacts, Not Code.md

NAPKIN | 餐巾纸

餐巾纸公式

代理工程中的 PM 價值 = 審查架構與決策產出物 (Artifacts) + 建立護欄 (Boundaries) - 逐行審查程式碼

在AI代理工程時代，PM 不需親自看程式碼，而是透過維護「知識層」與設定硬性護欄來確保代理工程的產出品質。

一句话

產品經理的職責已從撰寫規格書，轉變為維護能引導AI代理的知識上下文與決策產出物。

餐巾纸草图

[ PM 意圖 ] 
    |
    v
[ Artifacts (docs/rules/CLAUDE.md) ] <--- Review Focus
    |
    v
[ AI Agents ] ---> [ Code / Tests ] ---> [ Product ]
    |
    +-----[ Hard Boundaries (Gates/Hooks) ]

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

• 核心问题: 在 AI 代理可以自動寫程式的時代，產品經理 (PM) 應該如何調整工作流程與審查機制？
• 核心答案: PM 應該停止把時間花在寫規格和看程式碼上，轉而建立原型，並審查紀錄決策與系統上下文的「產出物 (Artifacts)」。
• 论证结构: 經驗歸納與案例分析

章节骨架

1. 審查產出而非程式: 程式碼屬於代理，PM 審查知識層。
2. 先建構再尋求共識: 原型比規格書更能促成有效共識。
3. 策略放在工作區內: 策略必須在代理的上下文之中。
4. 交叉質詢自信回答: 挑戰 AI 代理，並用多模型交叉驗證。
5. 讓系統從失敗學習: 每次失敗都應轉換成測試或政策。
6. 單一真相來源: 所有代理必須指向同一個核心指導文件。
7. 給予自治與護欄: 以硬性限制（程式碼層級）確保邊界。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

论证链

AI 生成程式碼的成本急劇下降 --> 寫出可運作原型的速度大於討論規格的速度 --> 傳統的 PRD 與規格撰寫變得沒有效率 --> PM 必須將焦點從「定義規格」轉移到「管理 AI 上下文與決策記錄 (Artifacts)」 --> 透過硬性護欄與自動化測試確保品質。

关键证据

1. 作者在兩週內，沒有閱讀大量程式碼的情況下，利用 AI 代理發布了三個專案（包含 VS Code 擴充功能與知識管理工具），並通過 800 多個自動化測試。
2. Meta 與 LinkedIn 已經改變 PM 職責，例如 Meta 增加原型製作的面試，LinkedIn 以 “Associate Product Builder” 取代 APM 計畫。
3. 作者在實際開發中發現，給予代理 CLAUDE.md 或 AGENTS.md 的明確指導，比單次對話的提示更能穩定產出。

隐形假设与边界

• 隐形假设:
  • AI 代理有足夠的能力可以基於高層次的上下文生成正確的程式碼。
  • 自動化測試與 LLM 評委 (Judges) 可以有效地捕捉大部份的系統錯誤。
• 边界条件:
  • 在高度監管的產業中（如醫療、金融核心），先建構再討論的模式可能因為合規性而失效。
  • 設計美感與使用者體驗的細節（如按鈕重疊等UI問題），目前 AI 仍無法完全把關，需要人類介入。

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

• 作者盲点: 作者假設 PM 擁有足夠的技術判斷力來設定「硬性護欄 (Hard Boundaries)」並寫出高質量的測試/評委架構，這對完全沒有技術背景的 PM 仍有門檻。
• 知识连接: 這與軟體工程中的「測試驅動開發 (TDD)」及「基礎設施即程式碼 (IaC)」概念相似，只是將「規格」變成了「上下文即代碼 (Context as Code)」。
• 行动触发: PM 應該立刻停止撰寫鉅細靡遺的 PRD，改為撰寫 architecture.md 或 decisions.md，並練習使用 AI 快速建立產品原型。

跨域映射

• 在 軟體工程，這叫 聲明式配置 (Declarative Configuration)
• 在 企業管理，這叫 賦能授權與底線管理 (Empowerment with Guardrails)

Agentic Engineering for PMs: Review Artifacts, Not Code (Architectural Deep Dive)

前言/背景

隨著 AI 開發代理 (Coding Agents) 技術的成熟，軟體開發的瓶頸已從「撰寫程式碼」轉移至「釐清意圖與驗證」。本文探討產品經理 (PM) 在此變革中應如何調整其工作流，從過去的「撰寫規格書 (PRD)」轉向「審查知識產出物 (Artifacts)」，並透過建構護欄與原型來引導 AI 代理，實現快速且高質量的產品交付。

章節詳細總結

審查產出物，而非程式碼 (Review Artifacts, Not Code)

作者認為 PM 不必學習撰寫程式碼，程式碼的所有權屬於 AI 代理（如同傳統團隊中屬於工程師）。PM 的職責是審查在程式碼之上的「知識層 (Knowledge Layer)」或產出物。

• 知識層的定義：這並非指 README，而是記錄決策的檔案。例如，架構決策 (architecture.md)、拒絕的方案 (why-this-matters.md)、安全模型 (security.md) 或是代理間的合約。
• 審查機制：PM 在工作交付時不看程式碼的 diff，而是閱讀這些產出物的變更。這保證了意圖與實作的對齊，並確保這份「收據」能在上下文中存續。

先建構再尋求共識 (Build Before Building Agreement)

傳統流程是寫 PRD、開會尋求共識，然後開發。現在這個順序被顛倒了。

• 實驗成本低於共識成本：建立第一個可運作版本的成本（一個下午）已低於開會討論的成本。因此，先建構一個原型，然後基於這個可見的實體來對齊團隊意見，能消除規格書帶來的模糊性。
• 取代文件：會議不應再針對尚未實現的文件進行爭論，而是應該檢視螢幕錄影、錯誤路徑或實際的使用者操作。

將策略置於代理的工作環境中 (Put Strategy Where the Agent Works)

PM 仍需制定策略（目標客群、不做什麼、權衡標準），但這份策略必須存在於程式碼儲存庫中，成為代理每次行動必讀的上下文。

• strategy.md 與 CLAUDE.md：如果策略不放在代理的上下文內，代理就會根據最近的對話或預設模式做出微觀產品決策。專案的儲存庫成為了產品的記憶體（包含實驗、決策與評估標準）。

交叉質詢與模型多樣性 (Cross-Examine Confident Answers)

AI 代理經常會給出過度自信但錯誤的答案，特別是在無法輕易復原的決策上。

• 質詢預算：PM 需要將注意力集中在具破壞性、涉及安全性、認證或資料模型的變更上，對其進行挑戰（如反問 “Are you sure?”）。
• 第二模型的交叉審查：作者引入了 Codex 或其他不同家族的模型來互相審核。一個模型可能會忽視自己的邏輯漏洞，但另一個以不同方式訓練的模型則能捕捉到這些問題。

讓系統從失敗中學習 (Make Failures Teach the System)

每一次的失敗都不應只被修復，而應被記錄為系統的防禦機制。

• 化失敗為政策：作者在 CLAUDE.md 加上「不要推測性地引入抽象層 (Don’t introduce abstractions speculatively)」，這是來自於真實失敗的教訓。
• 最小測試用例：當發現 Bug，不僅要修復，還要找出能捕捉該 Bug 的「最小測試用例」，將其加入測試套件或 LLM 的評估函數 (Judges) 中。

為所有代理提供單一真相來源 (Point Every Agent at One Source of Truth)

當使用多個代理（如 Claude Code, VS Code Grok, Codex）在同一個儲存庫工作時，必須避免他們各自產生不同的架構理解。

• 重定向機制：維護單一的 CLAUDE.md 作為專案慣例與決策的真相來源，給予其他代理的 AGENTS.md 只負責將它們指向 CLAUDE.md。例如使用 @AGENTS.md 匯入規則。

給予自治權，同時執行硬性護欄 (Grant Autonomy, Enforce Boundaries)

為了實現規模化，PM 必須讓代理自主運行（例如定時的自動化 Triage 工作流），但這需要區分「偏好」與「非妥協項目」。

• 軟性提示 (Steering prompts)：文字上的提醒，模型在壓力下可能會忽略。
• 硬性護欄 (Hard boundaries)：在程式碼與工具層面執行的限制。例如：
  • 必須有第二模型的簽核文件才能關閉 Issue。
  • 在安全與大範圍修改上不允許自動合併。
  • 在計畫未被批准前，實體阻擋代理對檔案系統的寫入權限（如透過 Python Hooks 阻擋）。

總結與結論

• 規格書已死，上下文即代碼：PM 應停止撰寫傳統 PRD，轉而維護儲存庫中的 Markdown 產出物（如決策記錄、架構說明、系統提示詞），以直接引導 AI 代理。
• 原型驅動對齊：利用 AI 高效的開發能力，將「先達成共識再建構」轉變為「先建構原型再基於實體進行決策與對齊」。
• 透過硬性邊界實現自治：要讓 AI 代理安全地處理自動化任務，必須依賴系統層面的硬性限制（如權限控管、Git Hooks），而非單純的文字提示，確保關鍵決策不被模型自行推翻。