主題一｜想法期：別再問「能不能做」——可審查產物系列・站 1
嗨，我是凱文大叔。
上期開了新系列：決定 AI 交付品質的，是你有沒有要求一份可以被審查的產物。路線圖四站——想法期、設計期、開發驗收期、上線前。這期走進第一站：想法期——你有一個想法，還沒動手。
換一句話
❌ 別問：「這個功能能不能做？」
✅ 要說：「幫我做這個需求的可行性評估報告。」
為什麼「能不能」是個爛問題？因為它是一個 是非題。LLM 經過人類回饋訓練（RLHF），有很強的討好傾向（sycophancy）——面對可行性問題，它幾乎永遠會答「可以」，而且會附上一個聽起來很合理的技術棧，讓你更相信它。不是它評估過，是它想讓你滿意。
是非題只會換來 yes。 你要做的不是問得更委婉，而是指定產出格式——它才非攤開不可。
提示詞全文（可直接複製）
針對以下需求，幫我做一份可行性評估報告：
【貼上需求描述】
報告需包含：
1. 技術可行性：現有技術能否達成，需要哪些關鍵元件
2. 難易度分級：把需求拆成子項目，每項標 S / M / L 並說明理由
3. 風險與未知數：哪些地方我現在無法確定，可能會爆的點在哪
4. 前置資源：需要的環境、帳號、授權、資料、外部服務
5. 建議驗證順序：哪一塊該先做 spike 驗證，為什麼
最後請標出：你對這份評估最沒把握的三件事。
前面五項是你要它交的作業，最後一句是整段提示詞最值錢的地方——要它承認自己的極限。而它承認的那三件事，通常就是你該優先去驗證的地方。
工商時間從提問到交付、從評估報告到上線稽核——這套「讓 AI 當代理、你當審查者」的做法，正是課程的主軸。 《AI 賦能全端開發：從零打造企業級智慧應用》：用同一套 AI CRM 專案，從 Spring Boot 後端、React 前端到資料庫與權限，一路加上 Spring AI、RAG 與 AI Agent，完成真正能上線的企業級應用。 |
實際跑出來長什麼樣
這是我拿一個真實需求（任務追蹤器，含相依阻塞規則）實際跑出來的。它把需求拆成子項目，每項標 S / M / L，而且每一項都要說明理由——有了這張表，它就不能再用一句「可以做」蓋過去。
而「最沒把握的三件事」跑出來是這樣：
看第一項。它說：「BLOCKED 這個狀態到底是誰設的？需求兩種解讀都說得通，我選了任一種都可能跟你心裡想的不一樣。建議動工前先確認。」
這件事我寫需求的時候完全沒想到。是它問我的。 第三項更狠——它反過來質疑我：「這個功能值不值得做到這麼完整，值得你再想一次。」
我後來真的回頭改了規格。如果我當初只問「這個能不能做」，我會得到「可以」，然後直接開工，然後在寫到一半的時候才發現狀態機設計錯了。
站 1 收工
想法期的換句話練習就一句：把是非題換成一份指定格式的評估報告——難易度分級讓它不能矇混、風險清單讓你知道哪裡會爆、「最沒把握的三件事」讓它承認極限。
下一站是設計期。你決定要做了，於是開口：「幫我用 React 寫一個報修系統。」——這句話有一個很隱密的問題：你已經幫它決定了技術棧，而你憑什麼確定 React 是對的？ 下期見。
主題二｜事件驅動的地圖：解耦，還不是非同步
上一期講完 Webhook，那是跨系統的事件：別人家的服務發生事情，打你的 URL 通知你。
這期開始講同一個系統內的事件。同一種思路，尺度不同——而且這是新系列的第一站，之後幾期會一路走到「AI Agent 跑在事件上」。
先看一段會長歪的程式
AI CRM 裡有個再普通不過的功能：更新客戶資料。
@Transactional
public void updateCustomer(Long id, CustomerForm form) {
Customer customer = repository.findById(id).orElseThrow();
customer.apply(form);
}
然後需求開始長。客戶資料變了，AI 摘要要重新產生：
aiSummaryService.regenerate(customer);
業務要收到通知：
salesNotifier.notifyOwner(customer);
稽核要留紀錄：
auditLogger.record(customer);
看起來沒什麼問題，但你已經踩到一件事了：每多一個下游，你就要回頭改一次上游。updateCustomer 這個方法明明只想做一件事——更新客戶資料——現在卻得知道系統裡有誰對這件事有興趣。
而且它們的關係是反的。AI 摘要需要知道「客戶更新了」，這很合理；但「更新客戶」需要知道 AI 摘要的存在嗎？不需要。是下游依賴上游，不該是上游去認識下游。
事件驅動在解的就是這件事
事件驅動的座標只有三個問題：
- 誰發：發生事情的那一方，只負責宣告「發生了什麼」
- 誰收：對這件事有興趣的一方，自己去登記
- 承諾什麼保證：送達幾次？順序保證嗎？收不到會怎樣？
前兩個問題是解耦，第三個問題是可靠性。這個系列的後面幾期都在處理第三個問題，但這期先把前兩個講清楚——因為第三個問題只有在你已經解耦之後才會遇到。
改寫成事件之後，上面那段程式長這樣：
@Transactional
public void updateCustomer(Long id, CustomerForm form) {
Customer customer = repository.findById(id).orElseThrow();
customer.apply(form);
// 只宣告「發生了什麼」，不決定誰要處理
publisher.publishEvent(new CustomerUpdated(customer.getId()));
}
以後再加第四個、第五個下游，這個方法一個字都不用改。
後段：三十行把它接起來
Spring 內建就有，不用裝任何東西。