學習筆記

TL;DR

ToSback 是一個將 AI 對話轉化為可驗收、可執行的工程規範 (Specification) 的工具，旨在確保 AI 專案中的決策與共識能被記錄、傳承，並便於後續由 AI 代理 (Agent) 進行實現。

快速結論

AI 專案的最大挑戰之一，不是達成共識，而是如何將這些共識有效地記錄下來，以便在不同時間、不同對話、或不同 AI 代理之間傳遞。若決策未被明確記錄，AI 可能會因記憶限制或理解偏差而「腦補」或「跑偏」，導致專案重蹈覆轍。

ToSback 的核心價值在於它是一個「工程規範」工具，專注於將已定義的需求和決策，轉化為一份結構化、可驗收的文檔，而不是進行新一輪的需求探詢。它透過識別和抽象出程式碼中的「接縫」(Seam)，來確保規範的穩定性，即使底層程式碼被 AI 大量改寫，測試仍能穩定運行，降低 AI 進行大規模程式碼修改的風險。

最終，ToSback 的產出是能直接交由 AI 代理 (Agent) 實現的「Sback」，通常會以建立在任務管理系統（如 GitHub Issues）的形式呈現，並包含明確的「問題」、「方案」、「用戶故事」(User Story)、「實現決策」、「測試決策」以及「不做事項」，確保 AI 能夠清晰理解並執行任務。

ToSback 是 AI 工程流程中的重要一環，與 Grooming (需求釐清) 和 ToTickets (任務拆分) 共同構成一個完整的「工程鏈」。它承接 Grooming 的輸出，將模糊的對話轉化為清晰的規範，為 ToTickets 將規範拆解成具體工單奠定基礎，最終實現 AI 驅動的真實專案開發。

這支影片在說什麼

這支影片介紹 Man Pokeke 倉庫中的一個名為 "ToSback" 的工具，它屬於「工程分類」，旨在將 AI 與人類之間對話中討論並確立的共識，轉化為一份結構化的工程規範文檔 (Specification)。影片探討了若不進行這種轉化，AI 專案可能面臨的挑戰，例如對話記憶的遺失、決策的遺忘、以及 AI 代理的理解偏差。

最重要的 3-5 個重點

1. 解決 AI 協作中的知識傳承問題： ToSback 填補了 AI 協作中，將臨時對話共識轉化為持久、可驗收規範的斷層，避免了因 AI 記憶限制導致的重複解釋和決策跑偏。
2. 將討論轉化為可執行的工程規範： ToSback 的核心功能是將已確立的需求與決策，整合成一份包含問題、方案、用戶故事、實現與測試決策、以及不做事項的結構化 Sback 文檔，可直接交由 AI 代理實現。
3. 強調「接縫」(Seam) 的重要性，提升規範的穩定性： ToSback 在生成規範前，會識別和抽象出程式碼中的「接縫」，即獨立的函數或模塊。這使得規範的穩定性不受底層程式碼重構的影響，為 AI 大膽改寫程式碼提供了安全網。
4. 是 AI 工程鏈中的關鍵一環： ToSback 作為 Grooming (需求釐清) 和 ToTickets (任務拆分) 之間的橋樑，與之共同構成了一個完整的、AI 驅動的工程流程，確保了從想法到實現的順暢轉化。
5. 自動化與整合能力： ToSback 能掃描代碼庫，理解專案上下文，並能將生成的 Sback 直接發送到任務管理系統（如 GitHub Issues），具備高度的自動化和系統整合能力。

知識架構

• AI 工程流程鏈 (Engineering Chain):

  • Grooming (需求釐清、智能提問) ->
  • ToSback (將共識轉化為工程規範) ->
  • ToTickets (將規範拆解為獨立工單) ->
  • AI Agent (實現工單) ->
  • 評審 (Review)

• ToSback 的核心功能與原則：

  • 輸入： AI 與人類的對話共識。
  • 處理：
    • 掃描代碼庫，理解項目上下文。
    • 識別和抽象出程式碼中的「接縫」(Seam)，優先使用高級別的接口。
    • 撰

寫 Sback 規範文檔。 * 輸出： * 結構化的 Sback 文檔，包含： * 問題 (Problem) * 方案 (Solution) * 用戶故事 (User Story) - 清晰描述功能行為，可驗收。 * 實現決策 (Implementation Decisions) * 測試決策 (Testing Decisions) - 基於接縫，提供具體測試數據與期望結果。 * 不做事項 (What Not To Do) * 發送到任務管理系統 (如 GitHub Issues)，標記為 Ready for Agent。 * 原則： * Sback 記住決策，而非實現細節（如文件路徑、代碼片段）。 * 接縫優先，確保測試的穩定性。

• ToSback 的配置：
  • 透過 Setup Man Pokeke Skills 命令進行一次性配置。
  • 掃描倉庫，確定遠端連結（如 GitHub）。
  • 配置任務系統整合方式（如 GitHub CLI）。
  • 配置發送至任務系統的標籤。

關鍵概念

• ToSback: 一個將 AI 對話中的共識轉化為工程規範 (Specification) 的工具。
• Sback: Specification 的縮寫，指由 ToSback 產生的規範文檔。
• AI Agent: 指能夠執行具體任務的 AI 程式或系統。
• 共識 (Consensus): 在 AI 與人類互動中，雙方就某事達成的一致意見。
• 任務管理系統 (Task Management System): 如 GitHub Issues，用於追蹤和管理專案任務。
• 接縫 (Seam): 程式碼中可被獨立提取和測試的邏輯單元，例如一個獨立的函數。
• Grooming: 指釐清需求、智能提問的過程，影片中提到上期內容。
• ToTickets: 指將工程規範拆分成可執行工單的工具，為下一期內容預告。
• 工程鏈 (Engineering Chain): 指一連串 AI 協作的開發流程，包含 Grooming, ToSback, ToTickets 等環節。

重要例子與細節

• 對話遺失的代價： 若不記錄共識，換個新會話或第二天再開啟 Agent，需要從頭解釋「播客當主角」、「大圖排除早讀」、「日報」、「常問」等概念，極為低效。
• AI 腦補的風險： 未白紙黑字寫下的決策，AI 可能會自行腦補，導致結果跑偏。
• Sback 的結構內容：
  • 問題 (Problem): 描述需要解決的具體問題。
  • 方案 (Solution): 提出解決方案。
  • 用戶故事 (User Story):
    • 例子：「作為作者，當我只發了早讀，沒發常文，首頁大圖要保持上一篇常文，不會被日報頂掉。」
    • 特點：不是模糊的要求（如「首頁要好看」），而是清晰、可測試、可驗收的行為。
  • 實現決策 (Implementation Decisions):
  • 測試決策 (Testing Decisions):
    • 例子：測試一個函數，輸入「最新幾篇全是早讀，更早一篇是常文」，期望結果為「大圖是那篇常文」。
  • 不做事項 (What Not To Do): 明確約定不實施的部分。
• 不寫具體文件路徑或代碼片段： 因為這些內容容易過時，Sback 應記錄決策，而非實現細節。
• 「接縫」的例子：
  • 將一段散在頁面組件裡的邏輯，抽取成一個獨立的函數，

定義好輸入與輸出。 * 這樣只需測試這個函數，而非整個頁面組件。 * ToSback 提議將「首頁展示什麼」的邏輯，封裝成一個名為 getHomepageContent 的純函數。

• 配置過程：
  • 執行 Setup Man Pokeke Skills。
  • 掃描倉庫，確定遠端為 GitHub。
  • 選擇 GitHub CLI 作為任務系統的命令行工具。
  • 配置 Ready for Agent 標籤，以及發送至任務系統的規則。
• ToSback 實際運作流程 (改造首頁範例)：
  • AI 掃描代碼，發現首頁展示邏輯混在頁面組件，且缺乏測試。
  • ToSback 提出抽取 getHomepageContent 函數作為「接縫」，獲取用戶確認。
  • ToSback 撰寫 Sback，包含用戶故事「大圖排除早讀日報」，並明確測試決策，如何驗證該行為。
  • 最終，Sback 成為任務管理系統上的、可驗收的規範。

可學習的洞察

• 知識的持久化是 AI 協作的關鍵： 對話的價值在於其產出的持久化輸出，而非僅停留在暫時的溝通中。
• 結構化規範有助於 AI 執行： AI 更擅長處理明確、結構化的指令，模糊的口頭協定容易導致誤解。
• 關注「接口」而非「實現細節」： 在軟體開發和 AI 協作中，抽象出穩定的接口（接縫）是應對變化的有效策略。
• AI 工程應有清晰的流程與工具鏈： 將 AI 融入真實專案，需要像 ToSback 這樣的工具來銜接不同環節，形成標準化流程。
• 測試的早期介入與明確定義： 在規範階段就定義好測試方法和標準，能確保 AI 實現的結果符合預期。

可行動的整理

• 檢視現有 AI 協作模式： 是否將與 AI 討論的結果記錄下來？記錄的方式是否結構化？
• 思考專案中的「接縫」： 如何將現有程式碼中的邏輯單元化、模塊化，使其更易於測試和維護？
• 試驗 ToSback 或類似工具： 探索如何將 AI 對話轉化為任務管理系統中的規範。
• 學習 Grooming 和 ToTickets 的概念： 了解 Man Pokeke 完整的 AI 工程鏈，以便更全面地應用 AI。
• 將「不做事項」納入需求討論： 明確定義不做的內容，與定義要做的事情同樣重要。

複習問題

1. ToSback 主要解決 AI 協作中的哪一個核心問題？
2. 一份 ToSback 產生的 Sback 文檔通常包含哪些關鍵部分？
3. 在 ToSback 的設計中，「接縫」(Seam) 的目的是什麼？它如何影響規範的穩定性？
4. ToSback 在整個 AI 工程鏈中，處於 Grooming 和 ToTickets 之間的什麼位置？
5. 為什麼 ToSback 在 Sback 文檔中會避免記錄具體的文件路徑或代碼片段？

待確認資訊

• 無明顯待確認資訊。