上一篇我們談了為什麼 AI 用不起來，這一篇拆開第一面牆：系統沒有門。
AI Native 基礎建設的核心命題是：如何讓系統不只是給人用，也讓 AI Agent 能理解、能操作、能規模化複製。 從 API 設計、介面標準化到 Agent 知識轉移，這篇文章用真實開發案例，拆解傳統系統為什麼讓 AI 寸步難行，以及 AI Native 的系統該怎麼蓋。
上一篇我們說了，AI 已經準備好了，但我們的世界還沒有。三面牆擋在 AI 前面：系統沒有門、知識沒有序、思維沒有換。
這篇，我們來拆第一面牆。
系統沒有門：你以為 AI 做不到，其實是系統不讓他做
你有沒有想過，叫 AI 幫你做這些事？
幫你從公司的 ERP 拉出這個月的銷售報表。幫你在 CRM 裡把上週的客戶跟進紀錄整理成摘要。幫你看一下專案管理工具裡哪些任務 delay 了，自動發提醒。
這些事情，AI 其實都「會」。他理解你的需求、知道該怎麼組織資訊、甚至能幫你寫出分析。但他做不到。
不是因為他不夠聰明，而是你的系統根本沒有留一扇門給他走進來。
ERP 的介面是給人登入、人點選、人操作的。CRM 的資料要打開瀏覽器、選日期、勾篩選條件。專案管理工具要你自己登入、自己看看板、自己判斷。AI 站在這些系統門外，就像一個能力很強的新同事，但辦公室的門禁卡還沒發給他——他能幫你，但他進不去。
這就是「系統沒有門」的意思。不是系統沒有技術接口，而是這些接口從來不是為 AI 設計的。
API 的技術債：門是有的，但上面沒寫怎麼開
讓我用一個最近的真實案例說得更具體。
我們自己開發的系統有一份 API 文件——你可以理解成一份「系統操作手冊」，寫了所有可以對系統下的指令和格式。文件是自動產出的，格式漂亮、欄位清楚，看起來很專業。
我把這份文件交給 AI，讓他基於這些指令去開發一層新的服務。
然後他就開始撞牆。
有一個欄位叫 category——系統只接受特定幾個值，但文件裡沒列出來。AI 不知道，自己填了一個看起來很合理的值，結果一直被系統擋回來。他試了十幾種組合，每一個都失敗。
另一個欄位叫 post_type——其實早就停用了，現在只接受一個固定值。但文件沒寫。AI 一直在猜，猜得都很合理，但全部都錯。
這些「潛規則」哪裡來的？是工程師們一路開發、一路溝通，用程式碼和片段文件傳承下來的默契。人類工程師碰到問題，可以走過去問隔壁同事。AI 不行——他只看得到文件上寫的東西，而文件只記了格式，沒記「為什麼」和「要注意什麼」。
你給了他一張地圖，但沒標出哪些路已經封了、哪些路口有隱藏的單行道。
老實說，我們的 API 確實有技術債。但我待過不少團隊，坦白講——一份乾淨漂亮、零技術債的 API？我沒見過。每個系統都是需求疊需求、版本疊版本長出來的，在人類之間靠默契跑了很多年也沒出事。只是到了今天 AI 要用的時候，這些沉默的債才一次爆發出來。
AI Native 的系統設計思維：AI 也是使用者
傳統的開發思維是：人設計、人開發、人使用。「使用者」預設就是人類。
AI Native 的思維多了一句話：AI 也是使用者。
這不是說要多蓋一個「AI 專用系統」，而是從設計的第一天就把 AI 的需求考慮進去。欄位命名要讓 AI 一看就懂、每個參數要有清楚的說明、可選的值要全部列出來、停用的功能要明確標註。這些事情對人類開發者是「有的話更好」，對 AI 是「沒有就不能動」。
業界已經在往這個方向走。像 OpenAPI 3.x 這樣的規範在推動更完整的介面描述，Anthropic 主導的 MCP（Model Context Protocol）在建立 AI 與系統溝通的標準協定——目前已捐贈給 Linux Foundation 旗下的 Agentic AI Foundation，由 Google、Microsoft、OpenAI 等共同參與。這些不是遙遠的未來，是現在正在發生的事。
但我想分享一個我自己更激進的實踐。
我最近開發了一套系統，從第一天就決定：這個系統要讓 AI 和人都能操作。整個開發流程跟傳統完全不同：
第一步，我跟 AI 討論系統的想法框架，在對話中不斷收斂邊界和規格，然後讓他去開發。
第二步，開發完一版之後，需要調整的地方我不自己改——我讓 AI 直接去做。比如他要調整資料庫裡的內容，調完之後我就讓他把這個操作包成 API，確保他之後能透過 API 完成剛才那些「手工活」。每一次的手動操作，都是下一次自動化的原型。
第三步，也是最反直覺的一步：在參數命名和規格設計上，我全盤接受 AI 給的方案。為什麼？因為 AI 自然產出的命名方式，就是模型在面對這類問題時最直覺的理解方式。如果我因為個人偏好硬改成別的，反而是在製造下一個「潛規則」——未來其他 AI 來用的時候，又要重新猜一遍。
最後，我把整套操作方式寫成一份叫做 SKILL.md 的結構化指南——這是一個由 Anthropic 發起、現已成為開放標準的 Agent Skills 格式，你可以想像成一份「AI 專用的 SOP」。任何 AI Agent 拿到這份文件就能直接上手，不需要有人在旁邊手把手教。
這個流程最關鍵的轉變在於：不是讓 AI 幫人寫程式，而是讓 AI 成為系統的第一個使用者，用他的卡點來驅動設計。
Agent 知識轉移：不只是你的 AI 能用
做到這裡，很多人會覺得：好，我的 AI 跑得動了，搞定。
但這只做了一半。
你有沒有想過——如果換一個 AI 來操作你的系統，他也跑得動嗎？還是你花了大量力氣教會了「你的 AI」，結果那些經驗全部鎖死在你們之間的默契裡，跟當初工程師之間的潛規則一模一樣？
真正的 AI Native 基礎建設，不是「我的 AI 能用」，而是「任何 AI 拿到都能用」。就像你寫的不是一封只有自己看得懂的筆記，而是一本任何新人拿到都能照著做的操作手冊。
你蓋的不是一個 AI 功能，你蓋的是一條 AI 能走的路——而且要讓任何 AI 都能走。
AI Native 成熟度：你的系統在哪一級？
在「基礎建設」這個維度上，我把系統的 AI 就緒程度分成三級：
Level 0 — 有門但打不開。 系統有技術接口，但 AI 無法直接使用。文件不完整、潛規則沒寫出來、介面設計預設使用者是人。你最後還是得自己登入、自己操作，再把結果複製貼上給 AI 看。
Level 1 — 硬撬開了，但只有你能走。 你花了大量力氣讓自己的 AI 能用——靠補充說明填脈絡、靠各種變通繞限制。能跑，但換一個 AI 又要從頭教起。本質上，你只是把工程師之間的默契，換成了你跟你的 AI 之間的默契。
Level 2 — 任何 AI 都能走。 從設計階段就考慮 AI 作為使用者。介面描述完整、命名清楚易懂、操作指南標準化且可轉移。任何 AI 拿到文件就能上手，不需要額外的人工翻譯。
大部分組織目前在 Level 0。這不是批評——半年前根本沒人覺得需要為 AI 設計系統。但現在，AI 已經站在門口了。
門開了，AI 走進來了。但他走進來之後看到什麼？
散落在三個平台的產品文件、五個版本搞不清楚哪個最新的開發規格、還有全部存在人腦袋裡從來沒寫下來的部門知識。
下一篇，我們來拆第二面牆：知識沒有序。
延伸閱讀
- Model Context Protocol（MCP）——AI 與系統溝通的開放標準協定
- Agent Skills 開放標準（SKILL.md）——讓任何 AI Agent 都能學會新技能的標準格式
- Anthropic Skills 開源範例——Agent Skills 的實作範例與官方技能庫
- OpenAPI Specification——API 介面描述的業界標準規範
本文作者每天與 AI 深度協作，從產品規劃、架構設計到團隊導入，持續探索 AI Native 的實踐方法。這個系列記錄的不是趨勢預測，而是真實踩過的坑與找到的路。