從想法到上線，都在同一個討論串裡：MeetAndy 在做什麼
個人 AI 讓每個角色變快，MeetAndy 把產品洞察、規畫、實作與回饋收進同一個討論串，減少團隊交接的摩擦。
English version: From Idea to Delivery in One Thread: What We’re Building at MeetAndy
Codex 和 Claude Code 讓工程師寫程式變快了。但對許多團隊來說，產品交付並沒有等比例變快。
瓶頸在產品、設計、工程與 QA 之間的交接。
在上一篇〈我讓 AI 助理做什麼：把行程、新聞與寫作接起來〉裡，我寫了個人 AI 助理 Aria 如何把行程、聯絡人、新聞、研究與寫作接起來。每一件事留下的資訊，都可以成為下一件事的起點。
ChatGPT、Claude 和 Aria 對我來說都是第二大腦。它們把個人知識外部化、自動化個人流程，讓每個人各自變快。
但每個角色帶著自己的第二大腦進入團隊後，交接仍然存在。
每個人都有 AI，交付仍然卡在交接點
以前做一個產品功能，PM 先撰寫產品需求文件 (PRD)，再開會跟設計師、工程師與 QA 討論。設計師依需求完成設計，工程師規畫實作，QA 準備測試規畫。
現在每個人都有自己的 AI：
- PM 用 AI 寫出 PRD，接著還是要跟設計師、工程師與 QA 開會確認需求。
- 設計師把 PRD 與討論內容交給自己的 AI，產生設計稿與介面規格 (UI Specification)，再回到會議跟 PM 確認畫面與互動是否符合需求。
- 工程師讓自己的 AI 讀 PRD、設計稿與程式碼，撰寫技術設計文件 (Technical Design Document) 與架構決策紀錄 (Architecture Decision Record, ADR)，再跟 PM 來回釐清範圍、限制與取捨。
- QA 也用自己的 AI 讀過這些文件，產生測試規畫 (Test Plan)，再跟 PM、設計師與工程師確認驗收條件與例外情境。
每個角色都變快了，接著還是要帶著自己的文件回到會議，跟 PM 來回確認需求。討論一有修改，所有文件就要跟著更新，再分別餵回每個人的 AI。
每個 AI 看到的是自己的文件，不是完整討論。架構限制、訪談脈絡、規格取捨與驗收條件的變更，仍然散在不同角色的腦中。
只要其中一段有歧義，大家就要再開一次會、補一份文件，或把背景重新餵給各自的 AI。
AI 加速了每個角色的工作，卻沒有消除角色之間的交接 (handoff)。產品交付仍然卡在同一個地方。
我常開玩笑說，PRD 之類的文件是一個 page，作用就是讓 people on the same page。
問題是每個人帶著自己的 AI 回去之後，又各自進入不同的 page。每個 AI 有自己的對話、記憶與資訊來源。到了下一次交接，還是得重新對齊。
如果能把這些個人 AI 合併成一個團隊共同使用的 AI，交接的摩擦就會大幅減少。
這不是讓大家共用同一個 ChatGPT 帳號，而是讓同一位 AI 隊友參與整支團隊的討論。需求從哪裡來、規格為什麼這樣寫、工程師提出什麼限制，以及最後核准哪個版本，它都在場。
這就是第三大腦。
從想法到上線，都在同一個討論串
MeetAndy 是產品團隊的 AI 隊友，從想法、規畫到上線，整段交付都在一條討論串裡完成。每一次交付都把知識累積進團隊的大腦，一路複利，所以越用越聰明。
MeetAndy 支援 Slack 與 Google Chat，背後接的是團隊已經在使用的工具：Jira 裡的工單、Google Drive、Notion、Guru 或 Confluence 裡的知識，以及 GitHub、GitLab 裡的程式碼。Andy 可以讀取這些資料，也能把規畫、進度與整理結果寫回團隊的工具。
PM、設計師、工程師與 QA 不必各自把 PRD 餵給自己的 AI，再交換失去脈絡的產出。大家直接在同一個討論串補充資訊、提出疑問與調整方向。
Andy 參與原本的討論，知道誰補了哪一段資訊、規畫為什麼改過，以及最後核准的是哪一個版本。
人負責挑選洞察、做取捨、拍板與把關。Andy 負責整理、草擬規畫、更新進度、執行與留下紀錄。
走完整個流程，就是一個 Loop
一件事可以從產品使用訪談開始，也可以來自客服紀錄、數據異常或業務帶回來的需求。
-
先整理洞察
Andy 讀過訪談紀錄與其他資料點 (data point)，整理出反覆出現的問題、可能的機會，以及需要進一步確認的地方。
AI 可以先做大量閱讀與萃取，但決定要做什麼的人仍然是團隊。人負責挑出值得投入的洞察。
-
一起完成規畫
選定方向後，Andy 先草擬一份規畫，列出已知條件、缺少的資訊與預計的實作方式。PM、設計師與工程師直接在同一個討論串補充。
Andy 也會替每份規畫標示風險與複雜度，補上 PM 可能缺少的技術判斷。工程師可以提早補上原本只存在腦中的技術脈絡，例如底層架構目前有哪些限制，以及為什麼應該改用另一種做法。團隊能在寫下第一行程式之前，先調整實作方式與驗收條件。
-
Andy 持續整理進度
討論過程中，Andy 會更新規畫、決議與待辦。新加入討論的人不必從頭翻完所有訊息，也不用再請某個人整理目前進度。
-
拍板後開始實作
簡單的網站功能可以直接交給 Andy 實作、測試並開出 PR。
手機 App 或需要本機開發環境的工作，可以讓 Claude Code 或 Codex 連接 Andy，取得已核准的規畫，再於本機執行。討論與規畫留在團隊的討論串，實作則放在最適合的環境完成。
-
人完成 QA、審查與上線
Andy 可以動手，但最後仍由人做 QA、code review 與上線確認。功能推出後，新的使用數據與訪談回饋再回到流程最前面。
這在邏輯上是一個 Loop。
洞察變成規畫，規畫變成產品，產品帶回新的數據與使用者回饋。下一輪開始時，Andy 已經知道上一輪討論了什麼、試過什麼，以及為什麼做出那些決定。
在一次使用者訪談中，客戶提到 PM 原本要花三到五天反覆詢問工程師、逐張填寫工單。現在 PM 可以先和 Andy 完成大部分規畫，工程師只在需要技術判斷與審查時加入。客戶估計規畫時間縮短了約 70%，工程師也不再一直被基本問題打斷。
我們自己也用 Andy 開發 MeetAndy。截至 2026 年 8 月，MeetAndy 的程式碼全由 AI 產生，其中約 40% 由 Andy 直接交付；官網、使用者文件與支援流程也在使用同一套方式。
每一次交付，都餵回團隊的大腦
每一次交付、每一次程式碼提交，Andy 都參與了前面的討論。需求怎麼形成、規畫為什麼修改、最後做了什麼取捨，這些知識就能跟著累積進團隊的大腦。
沒有人想長期負責「記住我們怎麼做事」。這份工作除了繁瑣，每次流程改變還得回頭維護。
Andy 會從工作過程中自動回溯。當有人說「不是這樣，是那樣」，它會把修正連同當時的脈絡記下來。下次遇到類似問題時，不必等同一個人再次出面糾正。
第三大腦也不是把公司過去的所有文件一次塞進搜尋系統。以軟體開發來說，程式碼通常是最接近現況的 source of truth。Andy 先掃描程式碼，再於任務需要時漸進式檢索相關文件與紀錄。
有資料就引用資料，找不到就說找不到。團隊可以再把 rollback 方法、backlog、成員職責、專案文件與工作規則教給它，讓記憶隨著真實工作逐步形成。
這也改變了團隊學習 AI 的方式。Andy 在開放頻道裡工作，大家看得到別人怎麼問、AI 怎麼回答，以及資深成員在哪裡補上判斷。原本藏在個人 prompt 裡的技巧，變成整支團隊看得到的學徒制。
理想上，Andy 會越用越了解這支團隊，也會逐步減少下一次交付前面的摩擦。
這就是 MeetAndy 的飛輪：每一次交付都把知識累積進團隊的大腦，一路複利，所以越用越聰明。
當開發能力大幅增加，團隊做產品的方法也會改變。
以前有三個方案，可能只能選成本最低的一個。當實作成本下降，三個方案都可以先做出來，快速進行 A/B 測試。真正重要的問題會變成：資料能不能快速收回來？團隊能不能理解發生了什麼？這次學到的東西，能不能直接成為下一次工作的起點？
我把這件事看成另一種數位轉型。以前我們幫客戶做數位轉型，現在輪到軟體公司自己轉自己。
工程師會投入更多時間建設 infrastructure 與 guardrails，讓其他角色也能安全地做出東西。Designer 把更多判斷放進 design system。PM 則負責挑選真正值得解決的問題，讓團隊多出來的速度變成營收、更好的產品，或更快的學習。
第二大腦讓每個人各自變快。
第三大腦讓這些人與 AI 在同一份脈絡裡工作，減少交接，完成整段產品交付。
如果你的產品交付仍然卡在交接，歡迎 找我們聊聊。
Related
