主題一｜決定 AI 交付品質的，不是模型強弱，是你怎麼問
嗨，我是凱文大叔。
這期增加一個較軟性的主題。你怎麼問。第二個主題把即時通訊系列收尾。
先講一個場景
同一個需求、同一天、同一個模型，兩個人去問 AI。
A 問：「這個功能能不能做？」他得到一句話——「可以做，建議用 React」。
B 問：「幫我做這個需求的可行性評估報告。」他得到一份文件，裡面有難度分級、有風險清單、有建議的驗證順序。
差別不在模型，在問法。
所以這個系列的核心主張只有一句話：
決定 AI 交付品質的，不是提示詞寫得漂不漂亮，也不是模型強不強，是你有沒有要求它交出一份可以被審查的產物。
「能不能做」換來的是一句話——沒得反駁、沒得追蹤、也沒得改。「可行性評估報告」換來的是一份文件——可以拿去簡報、可以回頭對照當初評估對不對。
基礎觀念一：AI 是代理，不是自動販賣機
現在 AI 開發的標準做法有個名字，叫 agentic coding。AI 不是你丟一句話、它吐一段程式碼就結束的自動販賣機；它是一個代理（agent）：理解需求 → 規劃 → 生成 → 驗證 → 修正——自己會把這個迴圈跑完。
人的角色也跟著變了：從「逐行下指令」變成審查每一站的產物。這句話是整個系列的地基——你要審查，就得先有「可以被審查的東西」。
基礎觀念二：問法決定你除錯幾次
模糊的提問，AI 會自行腦補規格。腦補出來的東西跟你心裡想的有偏差，你就開始除錯——改一次、跑一次、再改一次。每一次來回，都是重跑一整圈「生成、驗證、修正」。
精準的提問，把規格在生成之前就對齊了。錯誤根本沒機會被寫進程式碼裡。
除錯次數不是運氣，是提問品質的函數。錯誤在需求期被發現，改一句話；寫完程式才發現，改一天；上線後才發現，再放大十倍。正確的提示詞，就是把錯誤攔在最便宜的階段。
接下來的路線圖
這個系列會沿著開發生命週期走四站，每站各有一句大家最常講、但最不該講的話：
- 想法期：「這個能不能做？」→ 可行性評估報告
- 設計期：「幫我用 React 寫一個 X」→ 選型分析＋開發計畫
- 開發驗收期：「幫我測試有沒有問題」→ TDD＋E2E＋自動生成 SOP
- 上線前：「幫我看看有沒有漏洞」→ OWASP／CWE 逐項稽核
下期走進第一站：想法期——為什麼「能不能做」幾乎永遠只會換來「可以」？那不是 AI 評估過，是它想讓你滿意。
工商時間金流串接、webhook 入帳、狀態機守護——這些「整合的髒活」正是企業級應用的日常。 《AI 賦能全端開發：從零打造企業級智慧應用》：用同一套 AI CRM 專案，從 Spring Boot 後端、React 前端到資料庫與權限，一路加上 Spring AI、RAG 與 AI Agent，完成真正能上線的企業級應用。 |
主題二｜Webhook——伺服器之間的即時通訊，與它的深水區
上期結尾提到那位「常被誤會的親戚」：Webhook。它不在瀏覽器即時技術的選型清單裡（瀏覽器接不到它），但在系統整合的世界，它是「它來說」哲學的伺服器版——而且幾乎每個接過金流、串過第三方服務的人，都在它身上摔過跤。
這期是系列完結篇：把 Webhook 講深，尤其是摔跤最多的接收端。
Webhook 是什麼：一支反過來打的 API
一般的 API 是你去問：你的程式呼叫金流服務「這筆付款成功了嗎？」。Webhook 把方向反過來，變成它來說：你先在對方後台登記一個 URL，事件發生的當下，對方主動對這個 URL 發 HTTP POST，把事件內容送上門。
所以 Webhook 也常被叫做「反向 API」（Reverse API）或 HTTP 回呼。你不用輪詢對方的查詢介面，事件自己找上門——熟悉嗎？這就是 008 講過的「輪詢 vs 推送」，只是舞台從瀏覽器搬到了伺服器之間。
到處都是它：你可能已經在用了
- 金流：付款成功／失敗／退款，金流服務用 webhook 通知你的後端入帳
- GitHub／GitLab：push、PR、issue 事件觸發你的 CI 或機器人
- 通訊平台：LINE、Telegram、Slack 的 bot 收訊息，本質都是 webhook
- Email 服務：寄送成功、開信、退信事件回報（這份電子報系統的寄送狀態就是這樣收的）
- 自動化平台：n8n、Zapier、IFTTT 的「觸發器」，一大半是 webhook 包裝
判斷句很簡單：「外部服務發生事件時，要通知『你的後端』」→ Webhook。要再通知到使用者的瀏覽器，就接上這系列前三期的技術（webhook → 後端 → SSE/WS → 畫面）。
為什麼說坑都在接收端
提供方（金流、GitHub）的工作很單純：事件發生、發 HTTP 請求、收不到 2xx 就重試。接收方卻要面對四個現實：
- 請求可能是假的——任何人知道你的 URL 都能對它 POST
- 同一事件可能送好幾次——對方採「至少一次」送達，逾時就重送
- 你處理太慢，對方會判定失敗——然後又重送，雪上加霜
- 事件可能亂序到達——「付款成功」比「處理中」先到
這四題就是後段的全部內容。
