目錄

• 一句話結論（先給結論）
• 一、在需求説明書（PRD / BRD）中，接口設計“應該出現到什麼程度”

• ✅ 應該包含（產品經理職責）

• 1️⃣ 系統間的交互關係
• 2️⃣ 業務語義層面的接口契約（Business Contract）
• 3️⃣ 業務邊界與職責歸屬（非常重要）
• 4️⃣ SLA / 非功能性要求（業務視角）

• ❌ 不應該包含（不屬於產品經理職責）

• 二、跨微服務接口 ≠ 純技術問題（這是很多團隊的誤區）

• 為什麼？

• 三、產品經理 vs 技術人員：職責清晰劃分

• 產品經理（必須負責）
• 技術負責人 / 架構師（必須負責）

• 四、成熟團隊的“正確姿勢”（推薦）

• PRD 中的接口描述長這樣（示意）

• 五、總結一句“職能邊界話術”（你可以直接用）

一句話結論（先給結論）

跨系統、跨微服務的接口設計：

屬於需求説明書的一部分，但通常只到“契約級 / 業務級”，而不是“技術實現級”；
產品經理對其“定義需求與邊界”負責，技術負責人對其“具體設計與落地”負責。

一、在需求説明書（PRD / BRD）中，接口設計“應該出現到什麼程度”

✅ 應該包含（產品經理職責）

在正式、可落地的需求説明書中，以下內容必須出現：

1️⃣ 系統間的交互關係

• 哪些系統參與
• 調用方向（誰調用誰）
• 同步 / 異步
• 關鍵業務鏈路

例：
「訂單創建後，需要同步調用風控系統進行風險校驗，校驗通過後才能進入支付流程」

2️⃣ 業務語義層面的接口契約（Business Contract）

不是技術細節，而是業務含義：

• 接口目的（Why）
• 觸發條件（When）
• 輸入輸出的業務字段
• 成功 / 失敗的業務含義
• 關鍵業務規則

例：
「調用庫存系統 reserveStock 接口
輸入：SKU、數量、訂單號
輸出：是否鎖庫存成功
失敗時訂單需進入待處理狀態」

3️⃣ 業務邊界與職責歸屬（非常重要）

• 哪個系統是最終裁決者
• 哪個系統負責兜底
• 異常由誰處理

例：
「庫存不足的判斷以庫存系統為準，訂單系統不做二次校驗」

4️⃣ SLA / 非功能性要求（業務視角）

• 是否強一致
• 是否允許延遲
• 可接受失敗率
• 超時後的業務行為

❌ 不應該包含（不屬於產品經理職責）

以下內容不要求產品經理在需求説明書中給出：

• HTTP / gRPC / MQ 選型
• REST / RPC 接口路徑
• 參數類型（string / int）
• 重試策略、熔斷算法
• 鑑權方式（OAuth / AKSK）
• DTO / VO / Protobuf 定義

這些屬於技術設計説明（TDD / 技術方案）。

二、跨微服務接口 ≠ 純技術問題（這是很多團隊的誤區）

很多衝突源於一句話：

“接口是技術的事情，產品不用管”

這是錯誤的。

為什麼？

因為接口本質上是業務協作的邊界：

• 誰擁有數據主權
• 誰對業務結果負責
• 出錯誰兜底
• 重試會不會造成重複下單

這些如果不在需求階段定清楚，技術階段一定會扯皮。

三、產品經理 vs 技術人員：職責清晰劃分

產品經理（必須負責）

技術負責人 / 架構師（必須負責）

四、成熟團隊的“正確姿勢”（推薦）

PRD 中的接口描述長這樣（示意）

【接口名稱】庫存鎖定
【調用方】訂單系統
【被調用方】庫存系統
【觸發時機】用户提交訂單
【業務入參】SKU、數量、訂單號
【業務返回】
  - 成功：庫存已鎖定
  - 失敗：庫存不足 / 系統異常
【異常處理】
  - 庫存不足：提示用户
  - 系統異常：訂單進入“待確認”狀態
【一致性要求】強一致

👉 不出現任何技術細節，但業務邊界非常清楚

五、總結一句“職能邊界話術”（你可以直接用）

跨系統、跨微服務的接口設計，屬於需求説明書的內容，但只到業務契約層；
產品經理定義“要什麼、何時要、出錯怎麼辦”，
技術負責“怎麼實現、怎麼保證穩定”。

如果你願意，我可以幫你：

• 給你一個 PRD 中“跨系統接口説明”的標準模板
• 或直接幫你 review 你現在的需求文檔，看哪些接口責任沒寫清楚