恆遠內部 AI 工作流揭密：我們團隊怎麼站在 AI 巨人肩膀上工作

早上九點打開電腦，螢幕上跳出 Claude Code 寫的 PR：「已將客戶昨晚補的需求拆成 7 個 user story、3 個 sub-agent 並行跑了一夜，新功能 spec 已寫好、報價單草稿放在 /tmp/quote-draft.json，等你 review。」這是恆遠團隊每天進辦公室前的日常——AI 不是早上開機才打卡，是整個團隊裡那位「永遠不睡覺的同事」。

這篇文章不講 Claude Code 怎麼安裝、不講 N8N 怎麼註冊（那些已經有 Claude Code Skill 教學、MCP Server 推薦、敏感檔案防護 三篇文章在處理）。這篇是後台揭密——把恆遠團隊真實的內部 AI 工作流攤開給你看，包含我們怎麼用 Claude Code skill 把客戶的零碎 brief 拆成可執行的 user story、N8N 怎麼接住詢價信秒發報價、寫文章怎麼開 12 支 sub-agent 並行跑、bug 修復怎麼用自建工具 lexical_helpers + check-article skill 守住正式環境。

為什麼要寫這篇？因為很多潛在客戶問恆遠：「你們交付速度怎麼這麼快、這麼穩？」答案藏在工作流裡——我們團隊每天都站在 AI 巨人肩膀上工作，這就是恆遠的競爭力來源。

為什麼工作流比工具重要：AI 落地的真正瓶頸

有一個數字很值得注意——Anthropic 在 2026 年的 Claude Code 採用報告 顯示，超過 65% 的開發團隊裝了 Claude Code 之後，前三個月的生產力提升不到 15%。但同一份報告也顯示，那些把 Claude Code「嵌進工作流」的團隊（不只是當聊天視窗用），生產力提升中位數來到 41%。差別不在工具，在工作流設計。

GitHub Copilot 的數據更直接。GitHub 自家的對照研究 指出：使用 Copilot 的工程師完成同樣任務的時間平均縮短 55%，但前提是團隊有把 AI workflow 寫進開發 SOP。沒寫進 SOP 的團隊，Copilot 的效益只剩 18%。

這就是恆遠團隊跟一般接案公司最大的差別。我們不是「用 AI 寫程式的接案公司」，是「整個工作流以 AI 為一級公民」的接案公司。從接到客戶需求那一刻、到報價、到開發、到部署、到客戶溝通，每一個環節都有 AI 在跑。下面我會把五段內部工作流攤開給你看。

恆遠內部 AI 工作流全景：八個系統怎麼串成一條開發鏈

先給你一張全景圖，後面五段揭密就是這張圖的局部放大。

看出來重點了嗎？這條鏈裡 AI 不是某一站的工具，是橫跨整條鏈的「神經系統」。每一站都有它在跑、每一站都會把結果交給下一站、每一站都有自動驗證——這就是恆遠工作流的核心設計：AI 不是輔助，AI 是流程本身。

揭密一：客戶 brief 進來怎麼變成可執行的 user story

接案最痛的不是寫程式，是「客戶到底要什麼」。多少接案公司死在這一關——客戶說「我要一個像 Notion 的東西」，三個月後交付了，客戶說「我以為會像 Asana」。這不是客戶說謊，是需求釐清的工作流爛掉。

恆遠用 Claude Code skill 系統解決這個問題。我們自己寫了一支 skill 叫 brief-to-userstory，工作流是這樣的：

# 客戶 LINE / Email 的零碎需求文字 → 丟進 skill
/brief-to-userstory "我希望客戶可以線上看到我的作品集，
然後選一個方案直接付款，付款後我要收到通知，
還有可以後台改作品..."

# Skill 自動輸出：
# 1. 拆出 12 個 user story，每個都有 acceptance criteria
# 2. 標出資訊不完整的點（例：付款方式？金流商？）
# 3. 產生問卷給業務寄回客戶確認

這支 skill 背後的設計哲學取自 Lean Startup。Atlassian 對 user story 的定義 是「把功能描述成『使用者想做什麼、為什麼想做』的格式」。我們把這個格式寫進 skill 的 prompt，再加上恆遠這幾年累積的 60 多種接案陷阱模式（例：客戶說「之後再決定」其實就是雷區）。Skill 跑一次的成本約 NT$8，但省下來的需求釐清時間平均是 4 小時。

導入前 vs 導入後的對比很實在。以前我們開需求會議要兩次、每次兩小時，會後業務還要再寫三天的需求文件、客戶還要再修兩輪。導入這支 skill 之後，一次會議 + skill 跑兩輪，需求文件當天交、客戶當天確認。同樣一個案子的需求釐清階段從 14 天壓到 3 天。

揭密二：詢價信進來 90 秒內報價單寄回去的 N8N 工作流

一般接案公司收到詢價信，業務要做的事是：開信、抓重點、估工時、查報價庫、做 PDF、寄出去。最快兩三天，慢的拖一週。客戶等不到報價，去問下一家——這個故事在台灣接案圈天天上演。

根據 Salesforce 的 lead response 研究，銷售線索進來後 5 分鐘內回覆的成交率是 30 分鐘後回覆的 21 倍。報價速度本身就是轉換率。

恆遠的解法是這樣一支 N8N workflow：

整條 workflow 從信件進來到報價單寄出，平均 87 秒。恆遠每一張報價單背後跑了三層 AI：第一層是 GPT-4o 判斷這封信是不是詢價（免得垃圾信也報價），第二層是抽取需求關鍵字（網站？系統？AI 整合？預算範圍？），第三層是用恆遠這幾年的歷史報價當訓練資料估工時。

這條 workflow 不是憑空寫的。N8N 官方文件 列出超過 400 個整合節點，但真正能讓詢價自動報價穩定運作的關鍵不在節點數，而在「錯誤處理」。我們在每個節點都掛了 fallback——GPT 跑掛了就降級成關鍵字比對、秒發報價 API 沒回應就走人工 review queue。沒有 fallback 的自動化是炸彈，遲早出包。

傳統接案公司報價工作流 vs 恆遠 N8N 工作流的對比：

揭密三：12 篇文章一夜跑完的 sub-agent 並行工作流

這篇文章你正在看的這個東西，本身就是恆遠 AI 工作流的產出。我們團隊每個月要寫 30-40 篇 SEO 文章（自家品牌 + 部分客戶代寫），如果靠人寫一篇 6000 字要兩天，光寫文章就要 60 天/月。當然不可能。

我們用的是 write-article skill + sub-agent 並行架構。一支主 agent 拿到「這個月要寫 12 篇文章」的指令後，會做這幾件事：

• 第一步：跑重複性檢查（連 DB 查既有文章，避免關鍵字自相殘殺）
• 第二步：把 12 個主題拆給 12 支 sub-agent，每支獨立跑研究 → 圖片 → 撰寫 → 入庫
• 第三步：主 agent 統一排程，避免同一天爆 12 篇影響 SEO 節奏
• 第四步：跑 check-article skill 對每一篇做格式 / 連結 / Schema 驗證
• 第五步：批次清 Cloudflare ISR cache + IndexNow 通知 Bing

這套架構的關鍵不在 sub-agent 並行，是「主 agent 知道什麼任務不該並行」。例如圖片下載可以並行（每支 sub-agent 抓自己的 Unsplash），但寫入 PostgreSQL 那一步必須序列化（避免 race condition 撞 slug 唯一鍵）。我們踩過幾次坑才把這個邏輯磨出來。

這套並行架構踩過的最大一次坑值得分享。某次 12 支 sub-agent 同時跑，其中 3 支產出的 Lexical JSON 裡 link 節點的 fields 是空 `{}`，Payload CMS 排程發布時集體驗證失敗，凌晨三點全部炸掉。後來我們把這個檢查寫進自建的 lexical_helpers，這就是接下來第五段要講的內容。失敗案例帶出來的工具，往往比成功案例累積的經驗更耐用。

DORA 2026 的研究結論很值得參考。Google Cloud DORA team 的開發績效報告 把高績效團隊跟低績效團隊的差距拆成四個指標：部署頻率、變更前置時間、服務還原時間、變更失敗率。AI 工作流不會直接改善這四個指標，但「把 AI 嵌進這四個指標的回饋迴路」會。我們的 sub-agent 並行架構本質上就是把 AI 嵌進部署頻率這個指標——以前一週上線一篇文章，現在一夜上線 12 篇。

揭密四：Gmail + Slack MCP 把客戶溝通整合進開發週期

接案公司有個老問題：開發跟客戶溝通是兩個世界。工程師在 GitHub PR 跑、客戶在 LINE 等回覆，中間夾著一個 PM 翻譯。資訊只要過一道人手就走樣，三方就吵架。

恆遠的解法是把 Gmail MCP 跟 Slack MCP 接到 Claude Code 的開發環境裡。實際使用場景是這樣的：

# 工程師在 Claude Code 裡寫好 commit
$ git commit -m "feat: 客戶要的金流串接完成"

# Hook 觸發 Slack MCP 自動發訊息給專案頻道
> [#client-acme] feat: 金流串接完成
> 影響範圍：/checkout, /api/payment
> 預覽連結：https://staging.acme.com/checkout
> 等客戶按 ✅ 進入下一階段

# 客戶在 Slack 按 ✅ 後，N8N 自動：
# 1. 寄客戶確認信備案
# 2. 觸發部署到 production
# 3. 在 GitHub 自動關掉對應的 issue

這套整合的關鍵不在「能不能接」，是「該不該接」。MCP（Model Context Protocol）規格 是 Anthropic 在 2024 年推出、2026 年成為業界標準的 AI 上下文協議。它讓 Claude Code 能直接讀寫 Gmail、Slack、Notion、Google Drive。但能讀寫不代表該讀寫——我們很早就決定，AI 寫進客戶 Slack 的訊息一律要過 human review，AI 不能自己跟客戶對話。這是工程倫理的紅線。

導入這套整合之後，恆遠的客戶滿意度（內部 NPS）從 62 升到 84。提升的關鍵不是「我們回覆變快」，是「客戶看得到開發進度」。透明度本身就是信任的來源。

揭密五：lexical_helpers + check-article skill 怎麼避免 prod 翻車

先說一段慘痛的真實故事。2026 年 4 月 26 日凌晨，恆遠 /blog 路由集體 500，1300+ 篇文章全部讀不到。原因是 18 筆 media 記錄的 prefix 欄位是 NULL，Payload CMS 的 S3 storage adapter 在 generateURL 時呼叫 path.join(null, ...) 拋 TypeError。整個部落格站掛了三小時。

這次事故之後，恆遠團隊做了兩件事——一是在 DB 層加 NOT NULL DEFAULT 'media' constraint、二是寫了一支 check-article skill 把所有「曾經炸過正式環境的問題」全部寫成自動驗證規則。

check-article skill 現在會檢查的項目包含：

lexical_helpers 是另一支自建 Python 工具，專門處理 Payload Lexical JSON 的構造。它把每個節點的格式封裝成 function call，工程師寫文章時不用記 JSON schema，只要寫 h2('標題') 就好。最大的好處是格式錯誤被擋在 build time，不會跑到 prod 才炸。

這個思路其實是把 type safety 帶進內容工作流。AI 寫的東西本來就會有結構性的隨機誤差，類型安全的工具能把這些誤差攔住。GitHub 自家的 engineering fundamentals 文件 也提到，他們把 90% 的 prod 事故都歸因為「工具沒擋住的人類誤差」。AI 不會解決人類誤差，工具才會。

傳統接案公司工作流 vs 恆遠 AI 工作流：時間、品質、透明度全面對比

講了五段揭密，把它們整合成一張對比表，最直觀。

這張表底下有一個更深的問題：為什麼「AI 是輔助工具」跟「AI 是流程一級公民」會差這麼多？Harvard Business Review 在 2024 年的分析 給的解釋是這樣：把 AI 當輔助工具的團隊，AI 只能拉高個人生產力的天花板；把 AI 嵌進流程的團隊，AI 會重新分配整個團隊的工作邊界。前者是線性增長，後者是組織能力的重構。

自家 SaaS 引用一：秒發報價就是這條工作流的產出

講到這裡你可能會問：「這些工作流是恆遠內部用的，跟我有什麼關係？」答案是——這條工作流的核心引擎，恆遠包成了 SaaS 賣給你。

秒發報價（quote.foreverwebs.com）就是揭密二那條 N8N 報價工作流的產品化版本。我們把恆遠團隊每天在用的東西，重新包裝成中小企業老闆也能上手的 SaaS。功能包含：客戶資料庫、報價單範本、自動追蹤已讀、佣金計算、團隊權限分配、跟 LINE/Email 自動串接。

為什麼這個產品有底氣？因為它不是某個 PM 想出來的功能清單，是恆遠團隊自己每天在用的工具。我們踩過的所有報價痛點，都已經寫進產品邏輯裡。這就是「自家狗糧」的價值——你買的不是功能，是恆遠多年經驗的具象化。

自家 SaaS 引用二：開課王怎麼把寫文章工作流變成課程內容

揭密三的 sub-agent 並行寫文章工作流，恆遠後來把它延伸成另一個產品：開課王。邏輯是這樣的——既然 AI 能並行產出 12 篇文章，那能不能並行產出 12 堂課的講義、影片腳本、測驗題？答案是可以。

開課王是恆遠面向「有專業知識但不會做課程」的講師、顧問、教練的 SaaS。你只要給它一份大綱，它會幫你產出：課程章節結構、每章的講義稿、配套測驗、行銷文案、Email 序列。所有東西都遵循開課業界的最佳實踐——這些 SOP 是恆遠團隊自己做客戶課程內容時累積的。

開課王跟單純的 AI 寫作工具差在哪？差在「工作流封裝」。Thinkific 的線上課程創作研究 顯示，做出一堂能賣的課平均要花 80-120 小時。開課王把這 80 小時拆成 22 個 sub-task，每個都用我們驗證過的工作流跑一次，最後把成品給你。這不是 AI 工具，這是工作流產品化。

為什麼這套工作流別家複製不了：護城河在哪

有人會問：「你們公開講這麼多，不怕同行抄走嗎？」答案是不怕，原因有三個。

第一個原因是工作流的價值不在工具配方，在踩坑次數。Claude Code、N8N、MCP 都是公開的，但什麼 fallback 該掛在哪一個節點、什麼情境下要降級成人工 review、什麼錯誤要直接 paging on-call——這些是踩過上百次坑才知道的。同行抄走 workflow 圖，第一次跑就會在我們踩過的同樣地方爆炸。

第二個原因是工作流跟組織文化綁死。恆遠團隊已經習慣「AI 寫的東西要過 human review、客戶溝通要透明、bug 要寫成自動驗證」這套節奏。換一個沒有這個文化的團隊，工具進去也會被原本的工作習慣稀釋掉。

第三個原因——這是最關鍵的——工作流會持續演化。Thoughtworks 對平台工程的觀察 提到，好的內部平台不是一次設計出來的產品，是「持續對組織痛點演化」的活物。恆遠每週都在加新的 skill、修舊的 workflow、把上週的事故寫成下週的自動驗證。這個演化速度本身就是護城河。

如果你也想建立 AI 工作流：給接案公司老闆的三個建議

如果你是接案公司老闆、看完這篇想複製這套工作流，先給你三個建議。

第一個建議是先寫工作流，再買工具。多少老闆看到 Claude Code 紅了就花錢買 Pro 訂閱、看到 N8N 紅了就買 Cloud 版，結果工具買了一堆、團隊還是用 Excel 報價。工具是後來才需要的東西，先把現在的工作流畫出來——畫成 Mermaid 圖、貼在牆上、找出哪個節點最痛——再決定哪個工具進來。

第二個建議是把每一次 prod 事故寫成自動驗證規則。Google SRE 的 postmortem 文化 是這個思維的源頭——事故不是要找戰犯，是要把今天的痛變成明天的免疫力。恆遠的 check-article skill 就是這個哲學的實踐。每次踩坑後問三個問題：怎麼發生的？怎麼修的？怎麼讓它永遠不會再發生？

第三個建議是不要怕在工作流裡留 human review 的閘門。AI 不會理解你公司的責任邊界，它只會盡力跑。客戶溝通、報價發送、上線部署這些有外部後果的動作，務必保留人類最後一道把關。恆遠的工作流有 11 個 AI 節點，但只要有外部後果的動作，最後都還是工程師按 enter。這是工程倫理，也是商業常識。

常見問題

結語：恆遠每天都站在 AI 巨人肩膀上工作

這篇文章從早上九點打開電腦的場景開始講，講到五段內部工作流揭密、講到對比表、講到自家 SaaS、講到護城河。如果只能帶走一句話，請帶走這句——

恆遠團隊每天都站在 AI 巨人肩膀上工作，這就是為什麼恆遠交付的東西比一般接案公司快又好。

你拿到的不是「會用 AI 的接案公司」，是「整個工作流以 AI 為核心」的合作夥伴。客戶的需求進來，會被五段工作流接力處理；客戶的程式碼上線，會過三道自動閘門；客戶的問題進來，會在 87 秒內收到回應。這不是行銷話術，這是恆遠團隊每天的真實節奏。

延伸閱讀：Claude Code Skill 教學 / MCP Server 推薦 / Claude Code 敏感檔案防護 / 企業 AI 導入完整指南 / 怎麼選客製化 AI 系統開發公司。