看見全貌：公司的系統地圖與一套共同語言
前八堂你學的是做法：怎麼跟 AI 說、怎麼看它改了什麼、資料住在哪、誰有權限、手腳怎麼接。工作坊之後每個人手上都有一份自己的計畫書，揪團頁的任務已經結束了。今天做三件事：把公司已經有的系統攤成一張地圖；給你三組看事情的方法——東西怎麼組、怎麼做對、做的東西有沒有人要；最後用一張表描述你自己的題目。這套說法之後四週的個案討論都會一直用。
開始之前 · 30 秒
- 把你第 8 堂交的
plan.md打開放在旁邊——今天整堂都拿它當材料 - 今天沒有新工具要裝，也不改揪團頁。動手的那一節用的是 Claude Code 對話，跟第 8 堂一樣
- 這堂會過 27 張「方法卡」，不用背——每張都有一句白話和「你其實碰過」，完整版在附錄：方法卡，之後要用再翻
計畫書上一堂已經寫過、也討論過了，今天不重來。開場只做一件事：挑兩份同學的，各看三分鐘——聽的時候在紙上猜它會動到哪幾塊、是 ①②③ 哪一種。猜不出來沒關係，這整堂就是在教怎麼猜。
前八堂你其實已經把一個系統的每一塊都摸過了，只是它們一直沒有名字。今天先給名字。
| 塊 | 白話 | 前面哪一堂碰過 | 公司誰在管這塊 |
| 畫面 | 人看到、點到的地方 | 第 1–3 堂：揪團頁、區塊、互動 | 各系統自己（有共用的 Design System） |
| 資料 | 東西存在哪、誰看得到同一份 | 第 4–5 堂：localStorage、fetch、Notion 那張表 | Notion、資料庫、KV |
| 身分 | 「這是誰」由誰說了算 | 第 6 堂：你自己出面授權那次 | MIXXIN Gate／Auth |
| 通知 | 事情發生了要告訴誰 | 沒教過，第 04 節補 | Notify Hub |
| 接口 | 別的東西怎麼接進來 | 第 7–8 堂：MCP、公司的 plugin | MCP、API |
描述一個需求，先說它動到哪幾塊。「我想做一個貼文排程工具」講不清楚；「它要一個畫面讓我填、資料放 Notion、發文前要通知我、不用管誰登入」四塊講完，工程師跟 AI 都聽得懂，你自己也會突然發現：這題其實沒有那麼大。
五塊是零件清單，這一節講零件之間怎麼相處。八張卡，前四張今天展開講，後四張先認得名字就好——之後個案討論撞到哪張就翻哪張。
每一塊都有「裡面」和「外面」。你只需要知道它承諾什麼，不用知道它裡面怎麼做。
這是你不用變成工程師也能指揮系統的原因：Auth 承諾「告訴你這是誰」，你就不用管它怎麼驗密碼。描述需求時只講承諾，不講裡面，工程師跟 AI 都省事。
同一份資料只能住一個地方。多複製一份，就多一個要同步的問題。
非工程師做工具最常見的第一步是「先抄一份到我的表」——三週後兩邊對不起來，沒人知道哪份是對的。判斷一個題目健不健康，先問：它的每一種資料，權威版本在哪。
描述系統不是列功能，是講「一筆東西從出生到結束會經過哪些狀態」。
列功能會漏（「還要能取消嗎？取消後能復原嗎？」），講一生不會漏。工程師畫架構圖就是這樣畫的，你用同一種講法，對話直接對上。
「已審核」不是一個欄位，是「有一筆審核紀錄」推出來的。系統只記發生過的事，狀態是算出來的。
表單、簽核、退回、軌跡——只要你的題目有「狀態」，這是第一個會踩的坑：狀態欄跟紀錄對不上、退回後不知道退到哪。記事實就不會，因為事實不會互相矛盾。
其餘四張 · 先認得名字
五塊裡有一塊你完全沒碰過：通知。它值得補，因為很多人的計畫書其實就是「某件事發生的時候提醒我」——庫存低於某個數、有人填了表單、某個案子到期。
公司有一台專門負責「發通知」的系統，叫 Notify Hub（notify-log.mixxin.tw）。任何系統要發 Google Chat 訊息，都是把內容交給它，它代發，並且留下一筆紀錄：什麼時候、發給誰、有沒有送到。
① 寄了沒紀錄——對方說沒收到，你拿不出證據。
② 失敗沒人知道——寄信的那行程式壞了，半年後才發現。
③ 收件人換了要改十個地方——每個小工具各自寫死一個 email。
Notify Hub 就是把這三件事一次做完的地方。所以你的計畫書如果有「提醒我」這一塊，答案是接它，不是自己做。（這三個坑剛好對到上一節三張卡：失敗要有人知道、真相只有一份、改一處要動幾處。）
你不用會接。你只要在計畫書上寫得出「通知這塊走 Notify Hub」，工程師或 AI 就知道該做什麼了。這正是這門課一直在講的：會看形狀、會指路，比會自己蓋重要。
現在把公司已經有的東西攤開。這張圖分兩圈：外圈是同事每天在用的業務系統，按「給誰用」分群；內圈是它們共用的基礎設施——剛好就是那五塊。
外圈明細 · 你認得幾個？
| 全體員工 | 假勤、代墊款報帳、Bugxin（回報 bug）、公司儀表板、員工入口頁、Wiki 懶人包、Formlab 問卷、短網址（也能接）、用印申請、手寫簽名、名片辨識 |
| 集資顧問 | drip 募資看板、SOP 節點看板、嘖嘖頁面預覽、drip 追蹤 extension |
| 財務／主管 | 內帳與獎金結算、data-platform、數據會議 Dashboard |
| 客服 | AI 客服後台、EXTRACT |
| HHG | OMS、採購審核、權限申請、上架檔、商品建檔（圖上縮成一群） |
| BREW | 訂單系統 |
employee_index 這個 repo 裡、庫存管理（IMS）是 mixxims-next、mixxin-imgbox 是公司圖床（上嘖嘖用的）。名字對不上很正常——完整對照表在附錄：系統清單，要查的時候再開。（也能接）的意思是：它除了給人用，也開了接口給別的系統接。上面那張圖是手畫的快照。公司真正的地圖在 arch.mixxin.tw——每個 repo 的架構圖，工程師 push 之後自動送上去。現場開給大家看：點進一個系統，你會看到它的五塊各接了什麼、它對外的承諾是哪些（第 03 節「邊界與承諾」那張卡的實物）。之後你要判斷「公司有沒有這個」，就來這裡。
反面教材 · 為什麼「先查地圖」不是客氣話
準備這堂課的時候，我們把公司 GitHub 上的 repo 全部盤了一次：
| 138 | 個 repo |
| 61 | 個是業務系統，其中很多 README 還是樣板文字，看不出它做什麼 |
| 13 | 個接上了 arch.mixxin.tw 的架構圖 |
意思是：系統已經多到連工程師都要靠地圖才找得到。同一件事被做了兩次、三次的情況真的存在。所以做之前先查地圖，是必要動作——而且你查完寫在計畫書上的那一行「這塊公司已經有了」，比你自己蓋一個更有價值。（這也是第 08 節「減法」那張卡的現場證據。）
第 02、03 節是「一個系統長什麼樣」，這一節是「怎麼從一句想法走到動手」。三步，其中兩步你已經會了。接下來兩節的方法卡，每一張都掛在這三步的某一步上。
這就是第 8 堂規劃模式練的東西——你的 plan.md 前兩段就是它。今天只是給它一個名字：需求。寫得具體的需求長這樣：「每週三我要從三個地方抄數字進同一張表，大概花 40 分鐘」。
這是今天新加的一步，也是不重複造輪子真正發生的地方。把需求拆成畫面、資料、身分、通知、接口，每一塊拿去對第 05 節的地圖：有了就寫「接 X」，沒有才寫「要做」。設計做完，你手上的清單通常會比想像中短很多。
第 8 堂的判斷題現在有了判斷依據：只動到一塊（多半是畫面或資料）的，通常是 skill 或腳本，你自己跟 AI 就能收掉；動到身分和資料兩塊以上的，才是系統——而「系統」就是該喚工程師的訊號，不是你做不到，是它牽涉到別人的資料和權限。
這一組是公司工程師現在就在用的做法，也是你跟 AI 一起做東西時最容易自欺的地方。十二張卡，展開講四張：它們同時是公司 AI 開發守則和 MCP 設計的實際規則，你之後跟工程師對話會直接對上。
動手前先寫「怎樣算做完」。AI 說做完不算，要它拿證據。
沒有完成定義，AI 會自己決定做到哪，通常是「看起來像了」就停。有的話，你可以要它逐條證明：截圖、實跑結果、測試輸出。
先預覽再確認。AI 或人都不准一步到位。
上一張卡說不可逆要停下來問人，這張卡是「怎麼問」：系統先算好、把結果攤給你看，你點確認才真的做。你自己做的工具如果有「送出」「發通知」「刪除」，照抄這個。
AI 說做完了，要另一個沒看過過程的 AI 或人來驗。
做的人會替自己找理由，AI 也一樣——它讀自己改的東西一遍就說沒問題。開一個新對話、只給它完成定義，要它自己去跑去看，抓到的問題完全不同。
同一個問題修三次修不好就停，換方法或找人，不是再修第四次。
「再跟 AI 講一次就好」是無底洞：第四次通常跟第三次一樣，而且每次都在原地多繞一圈。三次是預算，用完就換路，這是紀律不是放棄。
其餘八張 · 先認得名字
前兩組管「怎麼組」「怎麼做對」，這一組管做出來的東西有沒有人要。對非工程師來說這一組最貼身，因為你的優勢就在這裡：你比工程師更接近使用者，而且 AI 讓你半小時就能生出一頁給人看。七張卡，展開講三張。
先找到一個真實的人，看他現在怎麼做、卡在哪，再想功能。
「大家應該會需要」是最貴的一句話。找一個真的人，看他現在的做法，痛點會自己跑出來，而且比你想像的十個功能都具體。
不是功能少的版本，是「能證明值得做」的最小版本。做出來先給人用。
很多人把 MVP 理解成「先做個陽春版」，然後陽春版永遠沒人用。MVP 的重點是驗證：做到剛好能讓那個真實的人用一次、告訴你值不值得繼續。
先讓 AI 生一頁假的畫面給使用者看，比寫需求文件快十倍，改也便宜。
非工程師最大的優勢就在這：你不用會寫，AI 半小時能生一頁看得到的東西。拿它去問使用者「是這樣嗎」，得到的回答比看文件準得多。
其餘四張 · 先認得名字
你要做的事：把你的 plan.md 丟給 AI，要它照今天這套走一遍，最後填出一張七欄的表。這張表就是之後四週個案討論時，大家講你的題目用的格式。
| 給誰用 | 一個真實的人或一群人，不是「大家」（第 08 節：使用者導向） |
| 他現在怎麼做 | 現況流程，花多久、卡在哪（第 06 節：需求） |
| MVP | 能證明值得做的最小版本長什麼樣（第 08 節：MVP） |
| 主體的一生 | 那筆東西從出生到結束經過哪些狀態（第 03 節：主體的一生） |
| 動到哪幾塊 | 畫面／資料／身分／通知／接口（第 02 節） |
| 公司已有 | 哪幾塊直接接現成的，接哪一個（第 05 節：地圖） |
| ①②③ | skill、腳本、還是工具系統，理由一句（第 06 節：實作） |
- 在 Claude Code 對著課程 repo，開規劃模式（Shift+Tab）——今天只討論，不動手
- 用下面的 Prompt A，把
plan.md的內容整段貼進去 - 看它拆出來的五塊：有沒有哪一塊它自己補上、你沒講過的？（第 8 堂練過的攔截）
- 它說「公司已經有」的那幾塊，去 arch.mixxin.tw 或附錄清單對一下——AI 不一定知道公司有什麼，你現在知道了
- 七欄填進Notion 資料庫「Vibe Coder 專案追蹤」你的那一列（欄位名一樣：給誰用、MVP、主體的一生、動到哪幾塊、公司已有、類型），GitHub 帳號欄填你的 login——填完重新整理專案追蹤表就會出現
起手式 · 用自己的話改
下面是我的計畫書。請照這幾步幫我走一遍，過程中不要動任何檔案： 第一步（需求）：用一句話寫出「給誰用」——要是一個具體的人或一群人， 不能是「大家」。再用一句話寫「他現在怎麼做」：現況流程、花多久、卡在哪。 第二步（MVP）：能證明這件事值得做的最小版本是什麼？ 不是功能少的版本，是「給那個人用一次就知道值不值得繼續」的版本。 第三步（主體的一生）：這個工具處理的那筆東西， 從出生到結束會經過哪些狀態？一行列出來。 第四步（拆五塊）：把它拆成畫面、資料、身分、通知、接口。 每一塊用一句話說它需要什麼；用不到的塊就寫「不需要」。 第五步（對照公司）：公司的基礎設施有：身分＝MIXXIN Gate/Auth、 通知＝Notify Hub、接口＝MCP 與 skills marketplace、 資料＝Notion/Cloud SQL/KV、畫面＝Design System。 每一塊寫「接 X」或「要自己做」，並說明理由。 第六步（判斷）：它是 ① skill、② 腳本、還是 ③ 工具系統？ 判斷依據：只動一塊多半是 ①②；動到身分和資料兩塊以上才是 ③。 最後用一張表總結，七列： 給誰用／他現在怎麼做／MVP／主體的一生／動到哪幾塊／公司已有／①②③ 我的計畫書： [把 plan.md 整段貼在這裡]
課程不是今天結束，是換一種上法。接下來四週每週拿幾個人的題目出來，用今天那張七欄表一起走，卡在哪就翻對應的方法卡。每週開場固定帶一張今天沒展開的卡：
| 第 1 週 | 失敗要有人知道——每個接口都會壞，壞了誰收到訊息 |
| 第 2 週 | 改一處要動幾處——改的地方越多越危險，也是為什麼要有共用件 |
| 第 3 週 | 決策留痕——為什麼這樣做寫下來，PR 描述就是最小版本 |
| 第 4 週 | 上線不是結束——看使用的人怎麼用，下一輪改什麼 |
其餘的卡遇到案子撞到再講。專案追蹤表就是進度板——每個人的七欄、狀態、連結都在上面，討論完自己更新。
作業：把第 09 節產出的七欄，填進 Notion 資料庫「Vibe Coder 專案追蹤」你的那一列。資料住在 Notion，專案追蹤表只是把它畫出來——你改哪裡，畫面就跟著哪裡，這正是「真相只有一份」那張卡。
選配加碼：用第 8 堂學的規劃模式，把你的 plan.md 改成「設計」版本——每一塊後面標出「接 X」或「要做」，並在最前面加一段 MVP。這份會是四週個案討論時你手上的底稿。
講師 / 助教檢核重點
- 每人在追蹤表上七欄填滿：給誰用、現況、MVP、主體的一生、動到哪幾塊、公司已有、①②③
- 「給誰用」不是「大家」；「公司已有」至少對到一個現成系統——一個都對不到的，多半是還沒查地圖，回去查
- 每人能用一句話說出為什麼要先查地圖再動手，以及什麼情況該找工程師（可逆與不可逆那張卡）