這一年，我讓 AI（人工智慧）幫我維護一套真的在運作的產品。

不是練習專案。
不是做一個登入頁。
也不是只要畫面好看就好的展示頁。

而是一套 AI 客服 SaaS。
SaaS 可以理解成「線上軟體服務」，使用者不用安裝，只要打開網頁就能用。

這套產品大約三萬行程式碼。
裡面有資料庫、快取、知識庫、向量庫，也有一整條讓 AI 先查資料再回答的流程。

我不是傳統工程師出身。
我比較像產品人。

我在意的是：

功能能不能跑。
使用者會不會用。
壞掉時我能不能修。
產品能不能長期維護。

這一年下來，我最大的體會是：

AI 真的能讓非工程師開始做產品。
但真正的難題，不是叫 AI 寫出程式碼。
而是你要知道，它寫完之後到底能不能相信。

問題不是提示詞，而是流程
很多人剛開始用 AI 寫程式，會一直研究提示詞。

例如：

請你扮演資深工程師。
請你一步一步思考。
請你寫出乾淨、可維護的程式碼。
請你不要出錯。

這些話有沒有用？
有一點。

但不夠。

因為提示詞比較像你對 AI 說：

「你這次要好好表現。」

可是產品不是靠一句「好好表現」活下來的。
產品靠的是流程。

大公司為什麼比較不容易因為一個人手滑就整個炸掉？
不是因為大公司的人都不會犯錯。
而是因為它有很多關卡。

有人寫程式碼。
有人檢查程式碼。
有人測試。
有自動化檢查。
有版本紀錄。
壞了還能回頭查。

但一個人做產品時，這些人通常都不存在。

所以我後來做的事，不是追求一個神級提示詞。
而是把本來應該由團隊完成的檢查流程，變成一套我和 AI 都要遵守的協議。

我把它叫做：

D / A / B / GO / S / P。

AI 的錯其實很固定
用久之後我發現，AI 寫程式最可怕的地方，不是它完全不會。
而是它常常用固定的方式犯錯。

它會還沒看完真實檔案就開始猜。
它會改好一個地方，忘記另一個地方。
它會說「完成了」，但真實檔案其實沒有變。
它會專心做新功能，然後忘記原本的規範。

最危險的一種，我叫它「截斷」。

截斷就是：
AI 修改比較長的檔案時，檔案尾巴被吃掉了。

某個函式可能寫到一半。
某段邏輯可能直接消失。
最後一行可能只剩半句。

你可能會想，這不是馬上就會壞嗎？

不一定。

如果被吃掉的地方剛好不是這次會跑到的功能，頁面可能照開。
主功能可能照跑。
測試也可能看起來沒問題。

你以為沒事。
繼續做下一版。
再下一版。
再下一版。

直到某一天，使用者剛好點到那條路徑，問題才爆出來。

這種錯最麻煩的地方是：
它不是當下爆炸，而是延遲爆炸。

當場壞掉反而好查。
你知道就是剛剛那次改壞的。

但如果隔了三版、五版才爆，你會開始懷疑資料庫、伺服器、套件、部署環境。
結果真正的原因，是很久以前某個檔案被悄悄截斷。

這也是我後來很堅持一件事：

AI 說完成，不代表真的完成。
畫面能打開，不代表系統是完整的。

我的六個暗號
我的流程很簡單。

D：下載真實專案到沙箱環境。
A：先討論，不准動手。
B：列出修改清單，等我確認。
GO：確認後才開始實作。
S：成品自我檢查。
P：整理成一次版本紀錄再推上去。

沙箱環境可以理解成「安全測試區」。
也就是先在不會影響正式產品的地方修改。

這六個字母不是魔法。
它們只是把 AI 容易失控的地方，一個一個加上關卡。

D 的重點是：不要讓 AI 用猜的。
一定要看真實檔案。

A 的重點是：先講清楚，再動手。
AI 必須先用白話說明它理解了什麼、可能影響哪裡、有什麼不確定。

B 的重點是：先列範圍。
會改哪些檔案、每個檔案要改什麼、哪些地方不碰，都要先攤開。

GO 才是開始實作。
而且只能改 B 階段確認過的範圍。
中途發現新問題，要先停下來問，不能自己擴大修改。

S 是整套流程的核心。

S 不是叫 AI 說一句：

「我已檢查，沒有問題。」

那沒有意義。

真正的 S，是檢查 AI 最常翻車的地方：

真實檔案有沒有真的被寫入。
大檔案有沒有假成功。
檔案尾巴有沒有被截斷。
改前改後行數是否合理。
版本差異裡有沒有奇怪殘句。
舊變數、舊引用、舊文字有沒有殘留。
多語系文字有沒有補齊。
權限、快取、資料同步有沒有漏掉。

P 是最後整理版本。
一次任務盡量整理成一次清楚的版本紀錄。
不要一個檔案推一次，否則未來出事很難回頭查。

最容易騙人的，是 AI 講得很像真的
有一次，我跟 AI 討論要不要把兩條檢查加進 S。

一條是非同步流程有沒有漏等結果。
另一條是快取失效和向量資料重算有沒有漏。

AI 講得很合理。

它說：
你的產品有非同步、有快取、有向量庫、有知識庫寫入，所以一定要小心這些問題。

聽起來非常專業。
專業到我差點開始懷疑自己。

後來我叫它不要猜，直接去看真實程式碼。

結果發現，這兩個問題我早就處理掉了。

快取失效已經接在該接的位置。
向量資料也會跟著資料更新一起重算。
我甚至在程式碼裡留了註解，說明哪些地方刻意不清快取，以及為什麼不清。

也就是說，AI 不是發現了我的問題。
它是在沒有看真實檔案前，用一套「聽起來很合理」的常見問題污染我的判斷。

這件事給我的提醒很大。

AI 最危險的地方，不只是寫錯程式碼。
而是它會用很專業的語氣，讓你懷疑自己原本做對的事。

所以我的原則很簡單：

不要讓它猜。
逼它看真實檔案。

給新手的提醒
AI 會讓越來越多非工程師開始做產品。

以前不會寫程式，很多想法只能停在腦中。
現在不一樣了。

你可以做網站。
做工具。
做內部系統。
甚至做一個小型線上服務。

但門檻降低，不代表風險消失。

以前最大的問題是：
你寫不出來。

現在最大的問題可能變成：
AI 寫出來了，但你不知道它哪裡其實壞了。

所以未來真正重要的能力，不只是會下提示詞。
而是會設流程。

你不一定要變成資深工程師。
但你要知道：

「完成」不等於「可靠」。
「畫面能開」不等於「系統完整」。
「AI 說沒問題」不等於「真的沒問題」。

如果你也在用 AI 做產品，我的建議是：

不要只追神級提示詞。
從你第一次被坑開始，把錯誤記下來。
同樣的錯發生第二次，就把它變成檢查點。
檢查點累積多了，就會變成你自己的協作流程。

短期看，會下提示詞的人很快。
長期看，會設流程的人才走得遠。

AI 讓小白也能開始寫程式。
但真正拉開差距的，不是誰先叫 AI 寫出來。
而是誰先學會檢查 AI 寫出來的東西，能不能真的交給使用者。

補充：
這些經驗來自我自己維護的 AI 客服產品 Chungtair。
如果你想看實際產品，可以參考：
https://chungtair.com/