前幾天有位寫作營的學員跟我說，他用 AI 做了一個活動報名頁，功能都能動，客人也真的報得進來。但他打開程式碼，一行都看不懂。他問我：這樣繼續下去，會不會哪天出事？

我先講結論：看不懂程式碼，本身不是問題。我自己做網站十五年，現在大量用 AI 寫程式，很多程式碼我也沒有逐行讀。

真正的風險不在「看不懂」，而在你除了 AI 的回答之外，沒有任何別的方法確認它是對的。

一、看不懂程式碼，跟說不出它在做什麼，是兩件事

專業的人用 AI，是把原本的判斷力放大。他不用看每一行，但他知道這個功能應該碰到哪幾個地方，不該碰到哪裡；改完之後，他知道去哪裡確認。

非專業的人缺的不是讀程式的能力，而是需求拆解、架構判斷、錯誤排查、結果驗證這幾件事。缺了這些，就只能用大量試錯來補。

所以問題從來不是「我看不懂這段程式」，而是「我說不出這個功能牽動了哪些東西」。前者是技術門檻，後者才是風險來源。技術門檻可以靠 AI 跨過去，風險來源只能靠你自己補。

二、三個真正會發生的風險

第一，你分不出「能動」和「正確」。

表單送出有跳「成功」，但資料存到哪裡、存了什麼、有沒有存到一半失敗，你不知道。畫面上看起來對，不代表背後對。

第二，出事的時候你沒有起點。

有人說「我付了錢但沒收到通知」，你能做的只有把整段對話貼回去問 AI。它會給你一個看起來很合理的解釋，但你沒有辦法判斷這個解釋對不對。它猜錯了，你也照著改，事情就從一個問題變成兩個。

第三，每一次修改都在你看不見的地方累積變動。

AI 這次為了修 A，順手動了 B，你不知道。下次修 C，又動了 B。三個月後，這個網站真正的行為只有 AI 記得，而 AI 其實也不記得，因為那些對話早就被你關掉了。

我常說一套系統真正值錢的不是程式碼，是踩過的坑。你用 AI 做出來的網站，坑一樣會踩，只是踩的時候你不知道自己踩到了什麼。

三、不用學會讀程式，但要學會讀三樣東西

我不會叫你去學程式。你要學的是三種「讀法」，都不需要懂語法。

讀行為。把網站的每個功能列成一張表：輸入什麼、應該發生什麼、去哪裡確認。報名表送出後，後台應該多一筆、信箱應該收到一封、名單應該多一個人。這張表是你的，不是 AI 的。

讀變動範圍。每次請 AI 改東西之前，先問它「你會動到哪些檔案，為什麼」；改完之後再問「你實際動了哪些」。兩份對不起來，就先停下來，不要急著往下改。你只要改一個按鈕的顏色，它卻動了五個檔案，這件事不需要懂程式也看得出來不對勁。

讀資料。進後台或資料庫看一眼，資料真的長什麼樣。很多問題不是程式壞掉，而是存進去的東西跟你以為的不一樣。報名表上填的是手機，存進去的欄位卻叫電話；你以為存了日期，其實存的是一串文字。這種事看一眼就知道，但你要真的去看。

我自己的做法是：任何東西要上線之前，先把原本的檔案下載備份，再看修改前後的差異。我不一定每一行都懂 AI 為什麼這樣寫，但我看得出它動了不該動的檔案。這一眼，比讀懂全部程式碼還有用。

常見的兩種反應，都不太對

一種人聽完會說：那我去學程式。

學基礎語法要幾個月，而且學完你還是不會架構判斷。更划算的是先學會問「這會動到哪裡」，並且把驗收步驟寫下來。這兩件事一個下午就能開始。

另一種人會說：反正能動就好，管它怎麼寫的。

能動，只代表你想像中的使用者可以走完流程。真實的使用者進來之後，才會出現你沒想過的操作組合。到那時候，你需要的不是程式能力，是一個知道去哪裡看的起點。

看不懂程式碼可以繼續做。但你現在能不能用一張紙，寫出你的網站有幾個功能、每個功能出錯的時候你會先去哪裡看？寫不出來，風險就在那裡。

如果你做到一半卡住，可以把狀況寫信給我。我每週會在電子報聊這類做網站、用 AI 的判斷，訂閱在這裡：https://iamlouis.ai/subscribe/edm