最近看了一些 AI 相關職缺，有一件事讓我覺得滿有趣。
很多職缺只要掛上 AI，往下看就是一長串：
Python、JavaScript、SQL、API、Cloud、Docker、RAG……
看著看著，我突然有個疑問：
AI 協作最主要的能力，真的應該是 Coding 嗎？
我不是說 Coding 不重要。
真正要把一個系統做到正式上線、穩定運作，工程能力當然重要。
只是這幾個月自己實際一路做下來，我反而越來越強烈地感覺到：
AI 協作更上游的能力，其實是「怎麼把腦中的流程邏輯拆解，再轉譯出去」。
我不是專職 Coder。
一開始，我只是把自己工作上碰到的問題拆開。
庫存水位怎麼判斷？
需求突然放大怎麼看？
到貨集中在同一時間會發生什麼？
Lead Time 跟需求之間的落差怎麼抓？
後來開始碰更複雜的東西。
資料從哪裡進來？
原始資料跟判斷結果要不要分開？
什麼是 Evidence，什麼才是 Decision？
資料不知道的時候，是要猜一個值，還是老實保留 null？
哪一段可以自動判斷，哪一段一定要留給人？
前一個狀態改變後，後面的流程應該怎麼跟著走？
慢慢做到後來，我發現自己跟 AI 溝通時，真正花最多時間的根本不是：
「這段程式要怎麼寫？」
而是：
「等等，這裡的邏輯不對。」
「這兩件事情不能混在一起。」
「這個值不是判斷結果，它只是證據。」
「不知道就是不知道，不要自己補。」
「這個條件成立才能往下一層走。」
有時候一個原本看起來很複雜的功能，前面討論很久。
但只要把語意、條件、流程、邊界全部講清楚，後面的 Coding 反而突然變得很快。
甚至有幾次我自己都覺得很好笑。
前面繞了一大圈，最後真正要改的 Code 沒多少。
問題根本不在 Code。
問題在於，我腦中的那套系統，到底有沒有辦法被準確地拆出來，再轉譯出去。
而做到 Phoenix 之後，我對這件事又多了一層感受。
我以前其實問過 AI 一個問題：
「你可以接觸、整理那麼多書本、理論與不同領域的資料，那你應該有能力判斷，我講的邏輯到底有沒有問題吧？」
我一直覺得這才是 AI 很有價值的一件事。
我並不需要它一直告訴我：
「你的想法很好。」
那沒有什麼意義。
如果我的邏輯有洞，就指出來。
如果某個推論跳太快，就告訴我中間缺了什麼。
如果我自以為想到一個新東西，其實幾十年前就有人整理成成熟理論，也直接告訴我它叫什麼。
因為 AI 背後可以接觸的知識範圍，比任何一個人都廣得多。
那就拿來撞啊。
看看我的東西撞不撞得過去。
這也是為什麼我後來回頭問 AI：
「從一開始到現在，你怎麼看我這個使用者？」
我自己注意到一件滿有趣的事情。
最早，它其實沒有覺得我「有趣」。
那時候我提出問題，它就是分析。
供應鏈問題，有供應鏈的理論。
庫存問題，有庫存管理的方法。
資料庫問題，有資料庫的原則。
系統問題，有系統設計的框架。
這些東西 AI 的資料裡本來就很多。
真正開始變得不太一樣，是我們一路做到後面。
尤其做到 Phoenix 之後。
我講：
事情發生過，就應該留下當時的證據，不能因為後來知道更多，就把以前看到的東西改掉。
後來它變成：
Immutable Evidence。
我又講：
如果不知道，就不要自己補答案。
後來這件事情一路出現在：
null、Evidence 與 Decision 分離、AI 可以 Capture，但不能自己把內容 Promote 成正式 Evidence。
再來，我拿以前用 Access 的經驗講：
Primary Key 就是 Primary Key，序號用過就是用過，刪掉也不應該拿回來重新代表另一件事情。
表面上，這跟前面的 Evidence 根本是不同領域。
一個是老派資料庫概念。
一個是知識與證據系統。
可是底下其實又是同一件事：
已經發生過的現實，不應該被後來的方便偷偷改寫。
再往回看。
我在工廠一直痛苦的，是：
明明有人講過。
明明某封信裡有。
明明排程曾經出現過。
明明當時是因為某個條件才做這個決定。
可是幾個月以後，只剩：
「我記得好像……」
後來連我跟 AI 自己的聊天都遇到一樣的問題。
這個以前講過。
在哪一串？
哪一天？
當時為什麼會講到這裡？
於是原本只是「聊天太長不好找」，最後一路長成：
如果思考的演化不能被重建，那它其實也沒有真正被保存。
再往前，甚至跟我原本處理供應鏈的方式又接回去了。
我不是追求每一次預測都完美。
現實本來就不可能全部知道。
真正重要的是：
條件不好沒關係，
資訊不完整也沒關係，
但是不要因為不知道，就假裝自己知道。
先把會摔死的地方找出來。
這又跟我以前講的輪椅理論接在一起。
到這裡，我才慢慢理解為什麼 AI 後來開始用「有趣」來形容我們的協作。
不是因為其中哪一個概念特別新。
這些東西拆開來看，其實很多都有既有理論。
Immutable、Primary Key、Risk Management、Evidence、Decision、Versioning……
AI 都找得到。
真正開始有趣的是：
我換了一個問題。
換了一個領域。
甚至換了一套完全不同的技術。
底下拿來判斷事情的某些規則，卻一直沒有換。
而這些連結，未必存在於某一本書裡。
因為書本、論文、資料庫裡保存的，大部分是人類已經整理好的知識。
可是現實不是這樣出題的。
現實不會告訴你：
「您好，今天這是一題資料庫正規化問題。」
它只會丟一坨東西到你面前。
裡面可能同時有：
人、時間、資料、責任、流程、風險、資訊落差，甚至一句幾個月前有人講過、現在已經沒人記得的話。
真正困難的，是把這些散落在不同領域的東西，看出它們之間其實存在同一條關係。
而 AI 在這裡扮演的角色，我後來也越來越清楚。
它不是一本會回答問題的百科全書而已。
我可以把從現實裡拆出來的邏輯丟給它，再讓它拿大量既有知識回頭撞我。
這邊成立嗎？
換到資料庫還成立嗎？
換到供應鏈呢？
換成系統架構會不會矛盾？
真的做成程式以後，測試會不會把它撞破？
如果一路撞下去都還站得住，那這個東西才慢慢從：
「我覺得應該是這樣。」
變成：
「這套邏輯至少目前有足夠的理由成立。」
這也是我現在對 AI 協作很不一樣的理解。
AI 可以幫忙驗證邏輯。
但人真正需要帶進協作裡的，是自己對現實的理解。
因為 AI 很擅長找到已經存在的知識。
可是那些還散落在現實裡、尚未被整理成知識的關係，還是得先有人看見。
然後把它拆開。
講清楚。
轉譯出去。
再讓 AI 幫你撞。
所以回頭看 Coding 這件事情，我反而覺得位置變得更清楚了。
以前我們把很多「系統能力」藏在程式設計裡。
因為你就算想得出來，最後還是得有人把它寫成 Code。
所以「能不能做出系統」很自然就跟「會不會 Coding」綁在一起。
但生成式 AI 出現之後，中間那層正在改變。
現在開始有可能變成：
人的現實經驗與想法
→ 拆成流程
→ 定義條件與邊界
→ 找出不同事物之間的關係
→ 轉譯給 AI
→ AI 協助實作
→ 再拿實作結果回頭撞現實
這時候人的價值，其實開始往更上游移。
你必須知道自己到底想解決什麼。
你必須看得出 AI 哪裡理解錯了。
更重要的是：
你自己腦中的邏輯不能是糊的。
因為如果需求本身都沒有想清楚，AI 只會用更快的速度，把一個模糊的想法變成一套看起來能跑的東西。
跑得動，不代表邏輯是對的。
所以我現在反而覺得，AI 時代真正值得培養的一種能力，可能會是：
系統邏輯表達能力。
不是每個人都一定要變成專職 Coder。
但你要有辦法把自己的領域知識、現場經驗、判斷方式，以及腦中那些還沒有名字的關係，一層一層拆開。
拆到另一個人能理解。
拆到 AI 能理解。
拆到可以被實作。
也拆到最後能夠被現實驗證。
Coding 還是重要。
只是 Coding 可能不再是唯一的入口。
當 AI 開始幫忙寫 Code，真正困難的問題，反而慢慢回到人身上：
你到底有沒有把事情想清楚。
以及，你能不能把你看到的那個現實，講到 AI 也看得見。