第一天就能問 Andy 的四個問題
第一天先問幾個只讀、不改的問題，幾分鐘內你就能判斷 Andy 到底懂不懂你們的系統。
Andy 是誰
Andy 是產品團隊的 AI 隊友。它就在你們的 Slack 裡，讀得懂你們的程式碼、票和過去的討論。
你在討論串裡 @ 它，它會讀 repo、查 backlog、提出計畫，等你點頭之後實作並開 PR，整個過程都留在同一串討論裡。
我們設計 Andy 的出發點很簡單：每個人都有自己的 AI，團隊卻沒有變快多少。因為每次交接，脈絡都要靠人重新講一遍。Andy 待在團隊共用的討論串裡，讓脈絡跟著工作走，不會停在某個人的對話視窗裡。
人負責決策，Andy 負責執行。
第一天，從問問題開始
很多團隊接上 Andy 的第一個任務就是「幫我把整個功能做出來」。這不是不行，但不是認識一個新隊友最好的方式。
我們建議第一天先問幾個只讀、不改的問題。這些問題不會動到任何一行程式碼，幾分鐘內你就能判斷：它到底懂不懂我們的系統？
以下是我們推薦你第一天先問的四個問題。
1. 「這些 repo 各自在做什麼？」
對你：接手新專案、新成員到職的那幾天，最花時間的就是「先搞懂現在長什麼樣」。Andy 讀的是程式碼本身，不是可能早就過時的 README，所以你拿到的是現在的樣子。這也是驗證 Andy 是否真的了解你們專案最快的方式。
對團隊：資深工程師不用一再被打斷，回答「這個 repo 是幹嘛的」。
真實情境：一位客戶的工程師加入新專案，面對十幾個 repo。他沒有約人花一個下午講解，而是先讓 Andy 說明一遍，當天就知道該從哪裡下手。
2. 「我們的程式碼做得到這件事嗎？」
對你：需求還在討論、還沒決定要不要做的時候，你需要的是一個有根據的答案，而不是一句「應該可以吧」或一份三天後才出來的評估。
對團隊：PM 和工程主管在同一個討論串看到同一份分析，討論的是同一組事實。可行性從工程師腦中的判斷，變成大家都看得到的紀錄。
真實情境：我們想讓付費客戶自己升降級方案。Andy 的回答是「做得到，不需要改資料庫，但這是真正的帳務後端工作」，並列出缺口，以及決定做之前必須先回答的問題。CTO 回答完、我們決定要做之後，prototype、計畫和 PR 都在同一串完成。
3. 「這張票修好了沒？」
對你：backlog 裡很多票其實早就被順手修掉了，只是沒人回頭關。以前要一張一張翻 commit，現在你只要讀結論。
對團隊：backlog 反映的是真實狀態，排優先順序的時候不會被一堆幽靈票干擾。
真實情境：我們把 backlog 最舊的幾張票交給 Andy 同時查，發現有兩張已經修好。Andy 附上修正的 PR 和原因，並註明哪些部分它沒有實際驗證。兩張直接關掉，人花的時間只有讀結論的幾分鐘。
4. 「這個需求我們已經有票了嗎？」
對你：客戶提了一個需求，你隱約記得以前討論過，但想不起來在哪裡。
對團隊：不會重複開票，也不會把一個月前已經討論過、已經有結論的事重來一次。過去的決定和理由都找得回來。
真實情境：客戶問能不能接自己的 MCP server。Andy 找出已經存在的 roadmap 項目和 backlog 票，整理了來龍去脈和還沒決定的問題，也提醒哪些票只是看起來相關。決定要做之後，我們在同一串接著研究做法，讓 Andy 實作並上線。
第一天之後
這四個問題，帶出的是 Andy 最核心的價值：
- 對個人：少花時間在「先搞清楚現況」，把時間留給判斷和決策。
- 對團隊：脈絡不再只存在某個人的腦中或某個人的 AI 對話裡。每一個問題和答案都留在團隊共用的討論串，下一個人接手的時候不用重講。
- 對交付：決定要做的那一刻，Andy 已經有完整的脈絡。同一串接著畫 prototype、寫計畫、開 PR，不需要再交接一次。
用越久，這些累積下來的脈絡就越完整，Andy 也就越懂你們的團隊。
想看看 Andy 在你們的 codebase 上會怎麼回答這四個問題嗎？ 找我們聊聊 →
