大部分工具只講 AI 能做什麼。我們反過來——先老實講它不能做什麼，再講我們的核心怎麼接住那些洞。因為在 PLC 這一行，「好像可以」會在客戶的產線上變成事故。
一條貫穿全部的原則：
AI 擅長「確定性、自我封閉、手冊寫得清楚」的部分；不擅長「取決於你這套實體安裝的運行時特性」的部分。
底下五個邊界，全部是這條原則的不同長相。
把布林邏輯寫成 ST，或把單純的接點串並聯轉成階梯圖。
這是數學上的不對稱：階梯圖→ST 容易，ST→階梯圖會失真。ST 裡的迴圈、CASE、陣列索引、浮點運算式，在階梯圖裡沒有對應的原生圖形。而 AI 天生偏好吐 ST——因為 ST 是純文字，模型就是文字模型;階梯圖是二維圖形結構，先驗弱很多。
現場維護技師排故看的是即時階梯圖——線路帶電會亮起來，一眼看出卡在哪。純 ST 的交付物在現場有落地阻力。
我們的核心同時輸出 ASCII 階梯圖 + 助記碼 + ST + IO 表四種表示，不是只給 ST。但也誠實：純布林/順序邏輯給乾淨階梯圖，一旦進到製程運算(類比縮放、迴圈)，ST 才是它的自然形態。我們不假裝任何邏輯都能給完美階梯圖。
在全新機台上自己取一套一致的變數名。
棕地(改既有廠)是災難。你的 HMI、SCADA、報警庫、歷史點表全都引用著既有 tag 名;AI 發明一個 Motor1_Start、而全廠用 M1_ST，程式就是「語法對、接不進去」。UDT(自訂資料型態)更尖——AI 不知道你的結構，只能吐扁平 tag。而「把幾百頁 IO 表與 UDT 餵給 AI」就算 context window 再大也不可靠。任何家都一樣，包括我們。
但有一件事我們做到、且可公開驗證:每個品牌的位址與資料型別定義，是照原廠手冊查證的。三菱/西門子/歐姆龍/台達/永宏的位址編碼(八進制、%I0.0、CIO 通道.位元…)都有手冊出處;士林則老實標「指令架構已依士林官方文件查證、32 位元變體仍待確認」。查證狀態公開在 /api/health。手冊規範的是位址與型別，命名風格是各公司規範，靠現場設定檔注入。
對機台級(幾十個點):貼上你的 IO 表、設定命名規則，產出來就用你的編號。我們不宣稱能無縫接進你全廠的 UDT——那是所有人共同的底線。
單一功能塊(FB)、標準控制邏輯——泵浦交替運轉、輸送帶順序啟動,一個掃描週期內就決定完的東西。
這不是寫程式的問題,是時序與物理的問題。多台 PLC 靠 EtherNet/IP、PROFINET 同步時,要算 RPI、update time、網路 jitter、各台掃描週期、交換器負載——這些是你現場拓撲決定的,不在程式裡。高速計數器跑在中斷驅動的專用硬體;伺服動態補償要知道你的慣量、增益、機械共振點,那是拿示波器一格一格調出來的。
它的失敗模式不是紅字報錯,是「實驗室好好的,上線後偶發卡一下」——掃描與網路更新之間的 race condition。看不到、找不到,是最貴的那種 bug。
我們產「跑在單台 PLC 上的製程/順序邏輯」——正好是 AI 擅長那一側,也是我們 20 題基準的甜蜜區。多台 PLC 網路同步、伺服調機、高速計數交握,是依現場硬體實測的調機工作,不在產碼範圍——那需要工程師到廠(這剛好是易歐特的本業服務)。
正常流程:「按 A 啟動 B」。這是誰都會寫的 20%。
真正的工程是那 70%:感測器斷線、閥沒回授到位、通訊斷了、操作員亂按順序、過載後要不要鎖定。AI 常漏極端狀況——例如「馬達啟動後 3 秒內感測器斷線怎麼辦」。因為訓練資料裡幾乎都是 happy path,而異常是組合爆炸、又跟製程綁死的。若每個 edge case 都得你寫進 prompt,那工程還是你做的,AI 只是打字員。
會寫正常流程不算會寫 PLC,會處理異常才算。漏掉的那一條,就是工安隱患。
三招針對它:①把通用的安全與異常搬進確定性核心——過載鎖定、類比斷線偵測(<3.8mA)、失效安全方向、遲滯、安全接點方向,是核心強制加的,不靠 prompt;②產生前主動訪談把 edge case 問出來;③編譯+行為測試+規則守門抓漏。誠實劃線:核心保證的是通用異常樣式;製程專屬的 edge case 仍要靠訪談問、或工程師補。我們的行為測試分數(約 45–55%)誠實反映的正是這一段——編得過、結構對、通用安全有,但「每種製程異常都對」還差一截。
產出第一版草稿,輸出成可匯入的格式(西門子 .scl 可直接進 TIA Portal)。
AI 平台永遠不是「最終環境」——真正燒進 PLC 的程式從 TIA Portal / Studio 5000 / GX Works 出去。真正的痛不是匯入,是匯入之後:工程師會在 IDE 裡改(調機、現場修 bug),從那一刻起 AI 手上那份就過期了。這是「兩份副本」的漂移問題——只要有兩份,就會發散。下次回去找 AI 改,它拿著舊版,很可能蓋掉你現場改的東西。
這個「陳舊記憶」的坑,傷得最重的是那種宣稱記住你整個專案的工具——它一載進去就開始過期,還假裝自己是最新的。這問題本質是版本控制問題,產業正解是給 PLC 專案做 git 式版控,讓版控後的專案當唯一真理來源。
我們是無狀態的:每次把當前程式碼貼回來再迭代,所以 AI 永遠照你這次貼的版本改,不會有一份假裝最新、其實過期的隱形副本在背後漂。代價是你要手動貼;好處是沒有靜默漂移——你永遠知道 AI 拿哪一版在改。IDE 才是你的真理來源,我們不搶這個位置。
因為假裝 AI 能算網路延遲、能記住你的全廠 UDT、能自己想到每一種製程異常的人,才會在客戶的產線上被抓包。我們寧可先把邊界劃清楚。
我們做的是「約束它、驗證它、並且誠實告訴你它哪裡不能信」的那一層。邊界之外的需求(到廠調機、系統整合、網路同步),我們用工程服務接,不用產碼假裝。