真正成熟的系統設計，會先埋好備援與成本邊界

上一篇還沒講完，我又回頭把六份開發指令整個掃了一次！上一篇寫完之後我自己也很好奇，只有這樣嗎？還是其實我腦子裡藏的東西沒講完？結果我把六份指令全部攤開來重看一次，欸，還真的再抓出五個前一篇沒講到的東西，而且這五個彼此不重複，是真的五種不同的本能。那就再寫一篇，反正我不寫完不蘇胡！（底下那些ＯＯＯ都是同學的專案，保護一下隱私）

永遠在埋備援，而且是系統性的埋

這個規律很隱蔽，但六份放在一起掃就跳出來了。

ＯＯＯ網站那份我寫「知識庫的組合採用 Claude API，備援使用 OpenAI」；ＯＯ網站那份我寫「AI 模型採用 openai, claude, deepseek，由管理員自選首用與備援」；ＯＯＯＯ那份客戶端要能看到「若有災情產生，視其保險方案發送申請理賠的流程通知」。

我發現我腦子裡想的從來不是「這個功能會不會失敗」，是「我依賴的這個東西（廠商、模型、天氣、任何我控制不了的外部條件）什麼時候會失效，失效之後下一步是什麼」。

這跟前面講過的驗證器、HITL 是同一種風險治理本能沒錯，但層級更高，那兩個是防「AI 或人會犯錯」，這個是防「我整條供應鏈本身會斷」，斷了之後系統不能死在那裡，要有備案自動接手。

成本天花板我會直接寫進架構需求，不是等做完才管

ＯＯＯ 網站那份有一句我自己都忘記我寫過，「後端使用 Neon 儲存，不希望超過免費門檻」。

這句話乍看很小，但其實是把一個具體的財務約束，直接寫進技術選型的指令裡，不是先把系統做出來，上線後才發現超支再回頭砍架構（拜託，砍架構比砍功能痛苦一百倍誒）。

這跟我上一篇講的「先問錢在哪」是同一個本能，只是這次不是問「這門生意怎麼賺錢」，是滲透到「這個技術決策本身的成本邊界在哪」，連資料庫要挑哪一款都被管到了。

主動幫對方合法趨吉避凶，不是只顧自己

ＯＯＯＯ那份有一句我自己在輸入時想的是我要讓 end user 覺得欸這個公司很貼心誒！

「AI 自動針對規範更新生成提供給使用者（客戶）的通知信，客戶要針對產業與產品自動貼標，通知信只發給對應貼標的客戶，以幫助他們合法規避OOOO的困擾」。

這不是單純的客服通知，是我站在客戶的立場，主動幫客戶避開他們自己可能都還沒意識到的風險。

ＯＯＯＯ那份的「黑洞版位」某種程度也是同一種心思，幫使用者發現他們自己還沒看到的機會，這跟我上一篇講的「多立場建模」有關，但更進一步，不只是知道每個角色要看到什麼，是主動幫某個角色趨吉避凶，把善意內建進系統邏輯裡，而不是留到人工去做。

預警機制幾乎都會順手接一句「然後通知誰」

ＯＯＯＯ那份，「進度過慢發生時，優先通知該成員的主管」；ＯＯＯＯ那份，「HILP 後才正式排入寄送」。

我發現我每次設計預警，幾乎都會習慣性接一句「然後通知誰」，而且這個誰常常不是當事人自己，是往上一層的人。

這代表我腦中的預警從來不是孤立的「這裡有問題」，是一條組織裡的升級鏈，出事了要往上通報到誰。

這個跟「多立場建模」不完全一樣，多立場是「每個人要看到什麼」，這個是「出事之後責任要往上傳給誰」，是兩種不同的設計本能，前者是資訊透明，後者是責任歸屬。

連資料庫索引我都在幫自己省成本，真的走火入魔

ＯＯＯ網站那份有一句技術細節深到我自己都覺得誇張，「資料庫索引方式盡可能可重複使用索引，避免單一資料單一索引，以加速索引時間」。

這句話已經下探到資料庫 schema 設計層級了，但驅動它的還是同一個財務本能，索引重複使用可以省算力、省時間、省成本。

代表我這套「錢在哪、洞在哪」的思維，不是只停在商業策略層，而是一路往下滲透到最底層的技術決策，連怎麼設計索引都在替老闆（就是我自己啦）的預算著想。

結論

寫到這裡我自己也覺得有點好笑，原來我不是只有一套「六步驟方法論」，是這套方法論長了觸角，從商業策略一路鑽到資料庫 schema，鑽到系統怎麼失效、失效了通知誰、通知了之後誰要負責，全部都被同一種本能滲透。

我覺得這才是「方法論而不是工具操作」真正的意思，不是說背了一套步驟去套用就有用，而是我的判斷標準本身就是滲透到每一層決策裏面，從要不要開一個新功能，到資料庫索引要不要重複使用，用的都必須是同一把尺。

工具會換，這把腦內思考的尺不會隨便換，這也是我一直想教給學員的東西：怎麼練出這把尺！

#圖文不符地獄梗

本文原發表於 2026/07/09 的 Facebook 貼文，原文照登，僅調整網頁排版；文中提及的產品、價格與活動以當時為準。