公司的客戶資料散落在四個地方：Google Sheets 存基本聯絡資料、LINE 聊最新進度、Email 留報價記錄、Notion 放會議筆記。每次要認真了解一個客戶，我得開四個視窗，來回切換，拼湊出一份背景，前後至少二十分鐘。
有一次開會前我還在趕，Ernie 在旁邊說：「不如我們自己蓋一個。」
我第一個反應是：可以嗎？
我們試過 HubSpot。功能很齊，但大雜燴——光是把它摸清楚，導入、設定、訓練團隊，就是一筆隱形成本。對當時的我們來說，那個學習負擔比資料散落還痛。
所以我們決定直播，邊蓋邊讓大家看。一個文組創辦人，2026 年，能把一套 CRM 蓋到哪裡？
▋第一週：先想清楚要什麼（BRD ・ PRD ・ 前端）
第一週我們沒有急著開 Claude，而是先坐下來走完一整套規劃流程：Business Requirement → PRD → ERD → Epic → Issue Ticket。
把規格丟給 Claude 之後，前端五十分鐘就渲染出來了。
直播間的反應是「哇 AI 好厲害」。
但我那時候的感受是：說到底，關鍵在前面想清楚了。
Garbage in, garbage out，這句話大家都聽過，但它真正的意思不只是「輸入的資料要乾淨」——更根本的是，你得先想清楚要什麼。AI 沒辦法替你做這一步。規劃仍然是人的工作。
時間分配的結構也跟著變了。
以前的邏輯大概是 10% 規劃、80% 執行、10% QA。但這週我感覺到那個比例不再成立了。AI 接手了大多數的執行工作，所以規劃那端被放大了——在規劃上多花一個小時，後面省的時間可能是十倍。
新的結構比較像 50% 規劃、AI 執行、50% QA。
第一週感受到的是「規劃」的那 50%。QA 那 50% 是什麼感覺，後面幾週才會兌現。
▋第二週：用截圖逆向工程，後端長出來（Data schema ・ 後端）
Ernie 解釋 data schema 的方式讓我印象很深：每一張資料表就像一道菜，自助餐的便當盒就像規範，規定了哪些食材、什麼格式——不能缺、也不能亂放。
我們當時要建「交易」這張表。
我的做法是：截一張 HubSpot「新增交易」視窗的圖，丟給 Claude，讓它逆向工程出欄位設計，再透過 Supabase MCP 直接建表。全程沒有開後台，沒有自己寫 SQL。建好之後串上前端的「新增」按鈕，新增一筆測試交易，確認寫入。
把意圖講清楚的極致，是直接給它一個畫面，讓它讀你的意圖，而不是用文字一個欄位一個欄位翻譯。
但這週也碰到了第一個陷阱：scope creep。
Claude 自作主張幫我加了 PRD 裡沒定義的欄位——priority、backlink。我和 Ernie 討論後當下直接刪掉。我們的邏輯是：每多一個 AI 節點，就多一個失敗機率，整條鏈的成功率是各節點相乘的結果。
「有時候少即是多，先聚焦在 MVP 打中 niche 比較重要。」
在 AI 生成速度這麼快的時代，「決定什麼不要加」比「加什麼」更需要判斷力。模型會給你很多，但你得知道哪些是你真正要的。
▋第三週：把前後端串起來，學會放手平行（Database ・ 串起前後端）
這週有一個畫面讓我很興奮：Ernie 在他的畫面把一張卡片拖到「成交」欄，我這邊一 refresh，馬上更新了。
看板拖拉即時同步，聽起來是小事，但那是第一次整個系統「活」起來的感覺。
我們也逆向工程了 HubSpot 的 deal detail 頁，但只留四個我們真正需要的模組：筆記・電子郵件・任務・會議，拆成三個 commit 分別完成。每一塊獨立測試、獨立 merge，不會因為其中一塊有問題就卡住全部。
這週還有另一件事讓我印象很深：平行跑 agents。
主線 agent 蓋 deal detail 的同時，我開第二個 agent 蓋 Contacts 頁。兩個 scope 不衝突，就可以平行推。邏輯有點像：先蓋手臂、再蓋腿、再蓋身體，最後合回主幹。
但有個陷阱要知道：兩個 agent 同時改同一個 Contacts 介面，會互相覆蓋。判斷什麼任務能平行、什麼不行，本質是工程思維，但不需要工程背景，需要的是邏輯。
最理想的狀態是 spec-driven：每個節點都有 spec，白色代表執行中、黃色代表需要人介入、綠色代表完成。黃色就是系統在說「這裡需要你的判斷」。
這週也第一次清楚體感到為什麼交易看板要設計成「拉」的邏輯。Toyota 精實生產的 pull system：接到訂單才把票拉上來，不先大量生產再找訂單；某個環節出問題，就停線一起 debug。我們的看板也是——把有機會成交的聯絡人，從漏斗上端「拉」進來。
▋第四週：部署上線，AI 的第一個 MVP（Vercel ・ Supabase ・ AI 功能 MVP）
這週做了兩件事：deploy，跟第一個 AI 功能。
透過 Vercel MCP，import GitHub repo、填上 Supabase 環境變數、一鍵 deploy。之後每次 git push 都會自動更新，不用再開 localhost 跑 demo。
這個感覺很重要——東西從「只有我能看到」，變成「在網路上運行」。
AI 功能是名片辨識。
點「新增聯絡人」旁邊的星星，上傳名片，後端自動把資訊轉成 schema、prefill 表單。
Ernie 補了一個細節，讓我更理解為什麼選語言模型而不是傳統 OCR：舊 OCR 碰到直式名片、欄位標籤不統一的設計，常常亂碼或欄位錯位；語言模型不管版面怎麼排都讀得出來。
當然 OCR 比較便宜，如果 schema 非常穩定，仍然值得考慮——這其實也是一種「決定什麼不要加」的思維。
名片辨識那個當下，我有一個很真實的感受：跑展場收回來的一疊名片，以前要花一個下午整理，現在上傳就好了。
這是六週裡第一次讓我覺得「AI 真的省了事」的功能。
但這個感受很快就被下一週的進度推翻了。
▋第五週：接上網域與登入，把 AI 功能補完整（網域 ・ DNS ・ OAuth ・ AI 完整化）
這週從 vercel.app 變成 crm.zynkr.ai。
公司本來就掛在 zynkr.ai 底下——kms、cms、accounting 都在——所以在 Cloudflare 手動加一筆 DNS record 理論上不複雜。但我還是不熟，全程截圖問 AI：點哪裡、填什麼、存下去。
AI 把我當完全不懂的新手在教，意外地很好用。
登入也在這週接上：原本知道網址就能進，這週加上 credential，authentication 綁在 Supabase。
第一次啟動成本較高，要手動 wire service role key，但接好一次之後就快了。Google / Email 登入都上。
然後是 AI 功能的完整化，也是這週最難的部分。
背景研究功能我覺得難度還好——兩三分鐘爬官網、資本額、新聞，抓的是 signal：擴廠、募資、新投資 AI 的訊號，這種事 AI 做得不差。
但 AI 撰寫開發信、任務建議、AI 復盤，就沒那麼單純了。
測試的時候我注意到自己一個反應：「直接按下去讓 AI 寄信，我反而不放心。」
這就是第一週留下的那個 50% QA 開始兌現的地方。最難外包的不是寫 code，是「local 測試 → 確認 → 推上 production」這個驗證迴圈。它需要你真的理解這個產品在做什麼。
AI 要做對，取決於我給它什麼、它讀什麼、它輸出什麼——這個 input-process-output 的判斷還是人的工作。
「你沒辦法對著一個黑盒子說『去幫我維繫客戶關係』，然後期待它做得比你更有判斷力。科技始終來自於人性的需求。」
真正的關鍵不是模型夠不夠強，是 context。
以「幾天沒回要追」這個功能為例，如果我寫死一個數字——七天追一次——這個邏輯套在大客戶身上可能反而惹人煩。要餵給 AI 的，是資深業務在判斷的那個邏輯：這個 account 在整個 lifecycle 的哪個位置？它現在需要的是推進還是等待？
Context 有幾個層次：長期記憶（像 CLAUDE.md，跨任務的背景設定）、這次的 prompt 和指令（frame 輸出方向）、知識庫和 domain knowledge（爬的時候要 follow 哪些準則）、還有 database 本身（任務看板已經排了十五個 task，這本身就是一個 alarm——對其他客戶的 service level 是 tradeoff）。
AI 復盤按鈕的邏輯也在這裡：每筆成交或輸掉的案子都該復盤，但實務上只有最自律的業務會做——做了的人表現更好，但大多數人不會做。一個 AI 復盤按鈕，把學習自動 append 進知識庫，等於把「頂尖業務才做得到的動作」變成每個人的標準步驟。
▋第六週：網站做好了，真正的考驗才開始（Landing page ・ 開始 distribution）
第五週的「按下去寄信不放心」，第六週時我們把那個功能改了。
從「一鍵生成」改成「先下一個 prompt frame 你要的方向，再生成」。不同階段的信要寫的東西不一樣——首次跟進跟根據最新任務 follow up，語氣和重點完全不同，如果讓 AI 自己決定，信很難 contain。多一個人工的 frame 步驟，輸出才能準。
這週也有個發現讓我重新定義了這整套系統：CRM 上的每個按鈕，本質上是一個打包好的 skill。
名片那顆星星，背後跑的是：OCR → 欄位轉換 → schema 確認 → 找官網 → 填表。那就是一個 sales specialist skill。
問題是，CLI 跑 skills 的 rampup 成本太高，一般人學不來。所以 CRM 介面變成 skills 的「載體」——點一個按鈕，就調用底下的 skill，使用者不需要知道底層在跑什麼。後面有一個 orchestrator 顧著 CI/CD，確保上下游都有 update。
Landing page 是一個 one-shot prompt spin 出來的。加了 pricing page，start for free，signup via Google 或 Email。
做這一頁的理由很直觀：直接把人丟到 login 頁，信任的摩擦力太高。要先有一層落地頁建立信任，讓人知道這是什麼、為什麼值得試。本來想做 14 天試用、再接金流，但金流還沒串，乾脆先讓第一批使用者免費玩。
然後是 distribution。
以前一萬名天才要籌幾千萬，才有可能做出一個產品。現在一兩週就做得出來。
這代表 0→1 變簡單了。但 1→100 反而更難——雜訊更多，attention 更稀缺，光是讓對的人找到你就是一件事。
2C 和 2B 的玩法又完全不同。Ernie 有一個觀察我覺得很準：2C 靠的是病毒和口碑，Reddit、Product Hunt，makesomethingpeoplewant 就會被傳開——那種截圖自動建知識庫的產品，用過的人會想分享。
2B 的決策流程長，要垂直解決真問題，製造業從 Purchase order 到訂購單到發票到 Packing List 到海關代碼，要一條龍吃下來，靠的是 referral、inbound、LinkedIn，本質是客戶買的是你這個人、你的團隊、你的 reference。先拿下第一個 enterprise success story，再橫向複製、往下打中小企業。
要盯的是 CAC、LTV，還有能自己轉的飛輪。
這一路幾週的 Vibe code 下來讓我體感最深的，其實是另一件事：我的工作方式變了。
我不再逐行看它寫的 code，也不再 micromanage 整個工具。我把它當成一個下屬、一個領域專家——spec 寫好，ultracode 切下去，就放手讓它跑，自己同步去處理別的事。整場直播三十幾分鐘，我幾乎沒回頭看 code。抓到錯再回去跟它說就好。
這個習慣的改變，可能才是六週裡最大的轉變。
六週過去，Zynkr CRM 上線了，crm.zynkr.ai，第一批使用者現在可以免費用。
老實說：蓋東西比我想像的容易，難的是後面的推廣和找到客群。
工具強了十倍，但 1→100 需要的東西沒變——真實的用戶需求、解決一個真正的問題、撐下去的意志力。這些 AI 沒辦法替你做。
如果你也在考慮自己蓋一個工具，這六週最大的收穫不是哪個 prompt 技巧。
而是一個在打開任何 AI 工具之前，值得先坐下來想的問題：你夠清楚知道你要什麼嗎？