最近我一直在想：
如果不會寫程式，PM 和設計師還有機會真正趕上 AI 的浪潮嗎？
大家都在想 vibe coding, 但事實上 vibe coding 離真實的產品還有些距離，
一個完整的產品不是單個功能的展示，
而是多個功能的組合，所以當功能變的複雜，
vibe coding 的效果，很容易取決於執行者對於技術的掌握程度。
當然也有另一個 ai 工作流派，就是自動化，例如透過工具自動產出文件、報告或設計稿。
但實際上，在產品開發的日常裡，我發現自己大部分的時間並不是在「執行任務」，
而是在思考、紀錄、整理、與歸納。
這些事情，本質上就是「脈絡」、「關聯」與「累積」
所以如何透過 AI 建立一份可以像程式碼一樣，持續累積迭代的產品需求文件？
而這份文件會變成 pm、設計師與工程師的共同資料庫。
我的解法是：
Obsidian + GitHub + Claude Code + Graph RAG（可能可以）
在這個組合之下，我們要求文件盡量不包含程式碼，
但若需要邏輯推理與驗證，
就可以在文件中導入 BDD（行為驅動開發，Behavior-Driven Development） 的概念。
以 BDD 為核心的知識結構設計
在這套方法中，我以 BDD（行為驅動開發，Behavior-Driven Development） 為基礎，讓需求與設計文件具備可驗證的邏輯結構。
BDD 不僅是測試框架，它提供一種跨角色的共用語言（簡單來說就是白話文的程式碼），使 PM、設計師與工程師能以同樣的句式描述業務邏輯與行為情境。
以 Given-When-Then 為核心語法：
Given（前置條件）：描述場景發生前的狀態與條件。
When（觸發事件）：明確指出使用者或系統行為。
Then（預期結果）：定義可觀察、可驗證的結果。
在文件層級上，我讓每個需求或場景都能對應到一個 BDD 結構，使這些文件不僅可讀，還能成為自動化驗證的基礎。
例如，假設我們在開發一個「會員登入功能」，可以用 BDD 這樣撰寫場景：
Given 使用者已註冊帳號
When 輸入正確的帳號與密碼並按下登入
Then 系統應顯示登入成功並導向首頁 這樣的寫法有幾個特點：
- PM 能清楚描述業務邏輯；
- 設計師 能理解畫面與互動狀態；
- 工程師 也能根據這些行為撰寫測試或程式邏輯。
因此，BDD 在這裡的角色是：讓所有職能都能以統一語言「敘述行為、驗證結果」，最終形成可被 AI（例如 Claude Code）解析與驗證的需求文件。
從筆記開始：Obsidian 的文件結構與思考模式
這套筆記軟體看似簡單，但它的核心理念其實非常適合構建知識系統。
它讓筆記之間能透過「雙向連結」 ([[ ]]) 自動建立關聯，
每個檔案又都是獨立的 Markdown 文件（.md），可以完全掌握結構與版本。
我的產品需求筆記架構大致如下：
/Vault
├── requirements/
│ ├── entities/ # 定義核心實體
│ ├── scenarios/ # 描述業務場景
│ ├── rules/ # 規則與邏輯
│ └── workflows/ # 流程與狀態轉換
├── glossary/ # 術語表與概念定義
└── index.md每份筆記都包含 metadata（YAML Front Matter），
記錄內容類型、狀態、更新時間與關聯的文件，例如：
---
type: scenario
domain: 使用者登入
priority: P1
status: 草稿
updated: 2025-11-04
tags: [auth, user]
entities: [使用者]
rules: [登入驗證規則]
---透過這樣的結構，我能把每一個知識點都「模組化」起來。
PM 可以描述流程，設計師可以描述介面邏輯，而所有筆記都能以連結的方式串起來。
久而久之，這就不只是筆記，而是一張能反映產品邏輯的「知識地圖」。
Obsidian、Claude Code、GitHub 與 BDD 的協作方式
我目前主要聚焦在這三個工具的結合：Obsidian、Claude Code、以及 GitHub，並將 BDD（行為驅動開發，Behavior-Driven Development） 的結構化思維融入其中。這套組合形成了一個可持續演化、可驗證的知識協作環境。
1. Obsidian：思考與結構的起點
Obsidian 是知識的載體。它讓我以 Markdown 方式紀錄產品邏輯、設計決策與需求變更。透過雙向連結（[[ ]]）與 YAML metadata，我能以模組化的方式構建完整的產品知識網。
我同時在筆記中融入 BDD 的層次結構，將每份文件分為：
- 業務實體（Entity）：描述系統中的核心對象，如「客戶」、「訂單」、「維修單」。
- 場景（Scenario）：以
Given-When-Then格式撰寫業務情境與流程。 - 規則（Rule）：定義約束條件、驗證邏輯或計算邏輯。
- 流程（Workflow）：描述端到端的行為鏈結與狀態轉換。
透過這樣的結構，我可以讓文件兼具「自然語言可讀性」與「機器可解析性」，使 BDD 的描述成為 AI 可理解的需求單元。
2. GitHub：版本控制與共編平台
GitHub 扮演「知識源碼庫」的角色。每一份 Obsidian 文件都能被 commit、diff、review，就像開發程式碼一樣進行版本控制。這讓設計師與 PM 的工作成果可以像工程師一樣追蹤、回溯與合併。
搭配 GitHub Action，也可以自動生成文件索引或 changelog，形成設計與開發共用的歷史時間線。
更進一步，若每個 Scenario 文件都遵循 BDD 格式，就能讓自動化測試或文件驗證系統直接讀取這些內容，形成需求與測試對應的橋樑。
3. Claude Code：知識的助理與解譯層
Claude Code 是這套系統中的「理解引擎」。我透過它讓 AI 直接讀取 GitHub 上的 Markdown 文件，並根據上下文提供建議、生成摘要或進行文件分析。
Claude 能夠辨識 BDD 的 Given-When-Then 結構，進而推斷出流程邏輯。例如：
- 驗證場景描述是否完整覆蓋實體與規則；
- 生成新功能的行為範例；
- 檢查規則之間是否有衝突或冗餘。
透過 Claude Code 的 agent，我可以限制 AI 的訪問範圍，使其只在特定資料夾（如 requirements/scenarios）運作，確保不同角色（PM、設計師、工程師）在知識空間中各自有清晰的職責範圍。
💡 延伸構想：Graph RAG 的未來整合
雖然目前我主要使用 Obsidian、Claude Code 與 GitHub 這三者形成基礎的知識協作系統，未來仍可考慮將 Obsidian 的連結結構導入 Neo4j，轉化為知識圖譜。
若再配合 Graphiti MCP 工具，就能進一步將文件節點與語意檢索結合，讓 AI 不只是「讀懂文件」，而能「推理文件間的邏輯關係」。
重新思考 PM 與設計師的工作方式
我為什麼會重新思考這樣的工作方式？
是因為我發現，目前許多 PM 與設計師都開始嘗試轉向具備 coding 能力的角色，
但在需求端與 AI 協作的方式卻很少被討論。
或許是因為工具限制了我們的想像力。
當我們長期依賴像 Jira 或 Notion 這類知識管理工具，
我們也就很難再去思考其他更自由、更有彈性的可能性。
我會有這樣的想法，也是因為這些工具我都接觸過，
長期與 AI 互動，才發現原來 Obsidian + Claude Code 的組合其實非常強大。
或許這套方法能帶給現在的 PM 與設計師一種新的思考方向。
當然，這樣的工作流程還有許多需要調整與改良的地方。
我先提出一個思考方向，如果大家能找到更好的方式，也歡迎與我分享。
本文由我本人撰寫，AI 潤稿
huangruilin 