AI-native 的價值，不是把判斷外包給模型，而是重新設計人與 AI 各自應該做什麼。
這篇文章整理我目前在 AI-native 產品打造中的實作原則。它不是宣稱這些做法已經被所有產品情境驗證，也不代表 AI 可以取代產品、工程或人的判斷。
AI-native，不只是「產品裡有 AI」
這兩年，「AI-native」很容易被理解成：產品有聊天機器人、有 LLM、有 Agent，就算 AI-native。
但我愈做產品，愈覺得真正重要的差別不在「用了多少 AI」，而在於：
AI 被放在整個產品與工作的哪個位置？它加速了什麼？又有哪些判斷一定要留給人？
對我來說，一個好的 AI-native 系統，不是把人從迴路中移除，而是讓人把注意力放在更值得判斷的地方。
1. 先定義問題，再決定 AI 要做什麼
最危險的順序是：先拿到一個很強的模型，再找地方塞進產品。
更好的順序，是先問：
- 使用者真正卡在哪裡？
- 哪一段工作很慢、很模糊、很容易漏掉？
- 哪些步驟需要大量搜尋、整理、比對或生成？
- 哪些步驟其實需要的是價值判斷、責任承擔或人際理解？
只有前面幾個問題清楚了，AI 才有一個合理的位置。
在我目前打造 Haven，以及處理其他產品與交付工作時，我會先把使用者真正遇到的問題、限制條件、流程、需求與驗收條件拆清楚，再決定 AI 是要協助理解、生成、整理、檢查，還是根本不該介入。
2. 把 AI 當成「可加速的能力」，不是新的真相來源
AI 很擅長幫忙產生選項、整理資訊、找模式、寫初稿、補測試、檢查邊界。
但「模型說了」不能直接等於「事情是真的」。
我會刻意區分三種東西：
- Reality：真實使用者、真實程式狀態、真實數據、真實外部回饋。
- AI inference：模型根據已知資訊提出的判斷、摘要、建議或假設。
- Human decision：最後採取什麼行動、承擔什麼風險、如何排序取捨。
這個區分看似很基本，實際上卻決定了一個 AI-native 系統會不會在速度變快的同時，把錯誤也放大。
3. 讓 AI 產生選項，但不要偷偷替人做重要決定
AI 很適合幫我們看見更多可能的選項。
- 提出多個產品解法；
- 把模糊需求拆成不同範圍與優先順序；
- 產生測試案例；
- 找出可能怎麼失敗、哪裡容易出錯；
- 提供不同語氣與呈現方式；
- 整理不同選擇的利弊與取捨。
但在不可逆、涉及他人、涉及金錢、隱私、安全或公開承諾的情境，我傾向保留一個明確的人工確認關卡。
原因很簡單：效率不是唯一目標。責任、同意與主體性也是產品品質的一部分。
如果一個系統為了「完全自動」而拿走使用者本來應該保有的決定權，那它可能更 AI-native，卻不一定更 humane。
4. AI 的輸出必須進入驗證迴路，而不是直接變成「完成」
在 AI-assisted development 裡，我最重視的不是「模型能不能一次寫對」，而是有沒有一個可靠的完成與驗證迴路：
Intent → Draft / Build → Test → Observe → Compare against criteria → Repair → Re-test
這個迴路很重要，因為 AI 可以非常快地產生「看起來完成」的東西。
- 程式能跑，不代表產品行為正確。
- 畫面出現，不代表使用者理解。
- 測試通過，不代表真實環境沒有問題。
- 文件寫完，也不代表外部世界真的改變。
AI-native 的速度，必須和證據紀律一起成長：做完一件事之後，要知道自己憑什麼相信它真的完成了。
一個我實際採用的產品邊界：Haven 的下一步一定由人決定
在 Haven 這類 relationship product 裡，這個原則尤其重要。
AI 可以協助一個人把關係時刻拆成「已知的事實、自己的感受、目前的假設、還不確定的地方」，也可以提出幾個可能的下一步。但產品不應該把 AI 的推測當成伴侶的真實動機，也不應該替使用者自動把私人內容送給另一個人。
所以我們刻意把「AI 產生理解／選項」和「人真正採取行動」分開。
這不是因為 AI 不夠聰明，而是因為關係裡的責任與同意，本來就不該被效率吃掉。
截至本文發布時，Haven 仍處於 MVP validation；broader real-user exposure 仍受 Founder QA / release-readiness gate 約束。這裡說明的是設計原則與工作方式，不是宣稱 Haven 已經被證明能改善關係。
5. 把失敗設計成可被看見、可被定位、可被恢復
我現在愈來愈重視系統會怎麼失敗，而不是只看一切順利時的理想流程。
一個成熟的 AI-native workflow 應該能回答：
- 失敗發生在哪一層？
- 是產品問題、環境問題、資料問題、provider 問題，還是驗證工具本身的問題？
- 當不同工具、文件或環境互相矛盾時，哪一個才是我們真正採信的狀態？
- 這個失敗是否能安全重試？
- 什麼情況應該安全地停下來，而不是「猜一個結果繼續跑」？
對我而言，真正有價值的自動化不是永遠不失敗，而是失敗時不會偷偷把錯誤包裝成成功。
另一個實作例子：staging 通過，不等於 production 完成
在一次實際產品交付裡，我們曾經取得真實的 staging E2E evidence。
但這並不代表可以把狀態直接改成「已正式上線」。中間仍然有 UAT、handover、release safety、Production Go / No-Go 等不同 gate。每一層回答的是不同問題：
- 流程在 staging 能不能走通？
- 真實操作情境有沒有遺漏？
- 必要的驗收是否完成？
- production 的資料、權限、通知與 rollback 是否準備好？
- 如果 release 後出問題，能不能安全恢復？
這也是我現在對 AI-assisted work 很重視的一件事：不要讓「產出完成」偷換成「現實完成」。
6. 把人類注意力當成稀缺資源
如果 AI-native 系統只是每天產生更多通知、更多文件、更多任務與更多「請你確認」，那它很可能只是把原本的運算成本，轉成更昂貴的人類注意力成本。
我會問：這個步驟真的需要人嗎？
能由明確規則、既有資料或低風險自動化解決的，就不要再把它推回給人。
但真正需要人的地方，應該更清楚地呈現：
- 要決定什麼？
- 為什麼現在需要決定？
- 有哪些證據？
- 有哪些選項與風險？
- 如果不處理，會發生什麼？
AI 的角色不是讓人消失，而是讓人的注意力更有槓桿。
7. 最終 North Star 不是「更自動」，而是「人與系統一起變得更有能力」
我真正想做的，不是單純追求 autonomous agents 的數量，也不是把每一個流程都自動化。
我更在意的是：這個系統有沒有讓人更能理解問題、更能做出好的判斷、更能採取行動，也更能保有自己的主體性？
這也是我目前對 humane technology（以人的福祉與主體性為中心的科技） 的理解。
好的 AI-native 產品，應該讓使用者得到新的能力，而不是只得到新的依賴。
它可以幫助人看見自己原本看不到的資訊、整理複雜情境、縮短執行時間、降低重複工作，但最後仍應該讓人知道：發生了什麼、為什麼、有哪些選擇，以及自己仍然可以決定什麼。
我目前採用的一個簡單判準
當我要判斷一個 AI 功能值不值得做，我會先問四個問題：
- Capability — 它有沒有真的提高使用者或團隊的能力？
- Agency — 它有沒有保留重要的人類選擇權？
- Evidence — 它的輸出能不能被檢查、驗證或追溯？
- Recovery — 它錯的時候，我們能不能看見、停下、修復並恢復？
如果四個答案都不清楚，我通常不會因為「AI 做得到」就把它放進產品。
這套工作方式，可以濃縮成一個迴路
Reality → AI inference → Human decision → Action → Evidence → Learn → 回到 Reality
AI 可以協助整理、生成、提出假設與選項；人負責判斷、取捨、同意與責任；真正的行動發生後，再用測試、使用結果與外部訊號回到現實，更新下一輪的理解。
結語
AI-native 產品最有趣的地方，不只是 AI 變得更強。
而是我們第一次有機會重新設計：人應該做什麼、機器應該做什麼，以及兩者如何形成一個更好的學習與決策系統。
我還在持續實作、修正這套方法。但目前有一件事我愈來愈確定：
真正好的 AI-native 系統，不應該讓人變得更被動。它應該讓人變得更清楚、更有能力，也更能為自己的選擇負責。
