在建立了財務管理相關的討論時,與AI模型的討論過程中發現了幾個痛點:
痛點1:跨對話時對於目前建立的系統規則、數字、使用者(我)自己本身的狀況有不一致的情況。如果是聊天也就算了,但對於決策一個幾萬乃至於幾百萬的資產移動配置來說,長期累積的認知與規則偏移是危險的。
痛點2:目前我是使用EVA裡的「MAGI」(三賢人)模式,同樣的決策會需要chatgpt、gemini、claude的討論與審閱,但如果讓三個模型對於我的財務狀況與目前已經訂好以及執行的規則有同步的認知,也是非常需要一個好的協作流程。
痛點3:我自身對於已經定好的規則可能哲學邏輯上有記憶,但對於「數字上」(比如說股價多少要停損) 則可能忘卻,但這會讓我執行上面對困難…
以財務為出發,我借用了人類「憲政」的精神,花了兩周和三個模型討論出下列工作流和模版,上文寫相關心得與精神,模板就附錄在文後 (非常長)供自己記錄以及有興趣者參考。
從「用 AI」到「跟 AI 長期共事」
多數人使用 AI 的方式,是把它當一次性的問答機:問完、拿到答案、關掉視窗。但當一個專案開始跨越數十次對話、更換不同模型、累積大量決策時,你會發現真正的敵人不是 AI 不夠聰明,而是漂移(drift)——上次講好的原則,這次被新建議悄悄覆蓋;暫時的靈感,不知何時被當成了正式規則;A 對話達成的共識,B 對話又重吵一遍。
AI 是一個會換班、會壓縮記憶、會受上下文影響的協作者。要跟這樣的夥伴長期共事,靠聊天記憶是不夠的,你需要一套可攜、可維護、可追溯的治理系統。
三道防線,對付三種漂移
這套工作流由三部分組成,各自防守一種失效模式:
**Governance(治理文件)**防「規則漂移」——定義最高原則、修改門檻與衝突時的優先序,讓核心規則不被短期情緒或新模型的一時建議推翻。
**Protocol(互動協議)**防「啟動失敗」——每次新對話、每次換模型,用固定的觸發指令讓 AI 先讀取治理文件、回報它理解的專案狀態,確認接手正確才開工。
**Self-check(自檢機制)**防「執行漂移」——治理文件寫得再好,AI 當次回答仍可能偏離,所以要能隨時要求它自檢:這個任務歸哪一層?做過衝突掃描嗎?是否誤把草案當定案?
幾個核心精神
**討論過,不等於定案;寫下來,不等於生效。**規則要分層——最高原則、量化門檻、戰術規則、暫時靈感各有位階,temporary 不得自動升格為 active。任何新規則進場,先過三道海關:歸層、相容性檢查、狀態標記。
**數字不是答案,是有身世的決策痕跡。**每個重要數字都要有履歷:理由、來源、建立日期、下次檢查時間。同樣地,重要結論進 Decision Log,灰色地帶先立判例(interpretation case)而非急著修法——條文不足才修訂。
**AI 有挑戰權,沒有逕自改憲權。**新模型可以質疑舊結論,但仲裁順序是:已封裝的有效文件 > 決策紀錄 > 人類當下的明確指示 > 新 AI 的推論。人類永遠是最終裁決者,AI 是顧問、整理者與風險提示者。
**治理也要受治理。**如果流程越來越儀式化、維護成本高過它省下的摩擦,就該優先簡化而不是繼續加規則。治理的目的是降低遺忘與漂移,不是自我繁殖。
結語
這套系統的本質,是把軟硬體工程裡的版本控制、design review 與 spec 管理思維,移植到人與 AI 的協作關係上。它不追求一次產出完美答案,而是確保專案走得越久、換過越多模型,累積的智慧仍然完整、可交接、可追溯。
這套治理系統並不適合所有人。如果只是詢問旅遊、美食、寫信或一次性的問題,它反而會增加成本。它真正適合的是跨數十次對話、涉及高價值決策、需要多年維護的長期專案。治理的目的不是增加流程,而是在專案愈來愈大時,降低遺忘、衝突與漂移。這也是我最後保留「治理也要受治理」這條原則的原因。
當 AI 成為長期戰力,值得為它建一套作業系統。