AI 給你 code、給不了你 軟體
─ 14 個分水嶺檢查清單

AI 寫出來的 code 能跑、不等於你做出了「軟體」。寫得快、跟做得出能維護的東西、是兩件事。這篇拆給你看 ─ 從「會跑」到「能維護、能交接、能賺錢」之間、隔著 14 個工程檢查點。每一條你都能對著自己的 project 勾一遍。

寫得快 ≠ 寫得出軟體

這個年代發生了一件 30 年來沒發生過的事 ─ 寫 code 不再稀缺。

以前寫一個 CRUD 功能要 1-2 天、現在用 AI 助手 15 分鐘就能跑起來。連完全沒寫過程式的人、也能用自然語言生出一個能動的小工具。

這是好事。也是壞事。

好事是 ─ 任何人有想法都能變 code 了。
壞事是 ─ 很多人以為「code 跑得起來」= 「我做了一個軟體」。但這完全是兩件事。

AI 給你的、通常是「今天會跑的一段 code」。
軟體要的、是「明年還能繼續長的東西」。

這篇要拆給你看 ─ code 跟軟體、差在 14 個你可能沒想過的地方。每一條都是檢查清單、你能對著自己的 project 勾一遍。

01 陌生人能不能 5 分鐘內把它跑起來

檢查一個 repo 是不是「軟體」、最快的方式不是看 code、是試「能不能跑」。

常見的失敗情境 ─ clone 下來跑 npm install 噴一堆錯、沒有 README、沒有 .env.example、環境變數可能直接寫死在 code 裡。

這不是軟體、是「作者自己電腦上跑得起來的 code」。

檢查清單：

• 有沒有 README.md、寫明怎麼啟動
• 有沒有 .env.example、列出需要哪些環境變數
• 有沒有鎖版本（package-lock.json / requirements.txt）
• 跑起來的 commands 是不是 3 行內

02 它有沒有 git history

很多用 AI 助手起的 project、根本沒有 git ─ 整個資料夾直接打包丟上線。

git history 不只是「ctrl+z」、它是軟體的「記憶體」：記錄了「為什麼這段 code 長這樣」。3 個月後出 bug、看 git blame 能知道是「那次為了趕 demo 改的」、知道當時的 trade-off、現在該怎麼動。

沒有 git history 的 code ─ 你看到的不是「軟體」、是「考古現場」。

最低標：

• 有 git repo（不是「打包丟 zip」）
• commit message 看得出「為什麼改」、不是 fix / 修一下 / final
• 有分支策略（至少 main / dev）

03 有沒有任何 1 個測試

這是最常見的「我寫完了」陷阱 ─ 沒寫測試、自己手動點幾下、就說「OK」。

測試不是為了「證明 code 是對的」、是為了「6 個月後改了東西、你知道有沒有破壞別的」。

沒測試的軟體會走向廢墟：

• 第 1 個月：自己改、還記得
• 第 3 個月：忘了當初為什麼這樣寫
• 第 6 個月：不敢動了、改一處壞三處
• 第 12 個月：放生、寫新的

軟體要至少有 1 個 測試。不用 100% 覆蓋率。1 個就好。但要有 ─ 這條測試會在你改 code 時告訴你「哪裡壞了」。

04 Production 跟你電腦上是不是一樣

這是 vibe code 最常爆的點 ─ 自己電腦能跑、上線後 500 error 滿天飛。

典型情境：

• 本機：DATABASE_URL=localhost:5432 能跑
• 線上：用雲端 DB、連不到
• 本機：node 18
• 線上：雲服務跑 node 20、API 行為不同

軟體會明確區分「dev / staging / prod」三個環境、每個環境的設定都清楚記錄、不能寫死在 code 裡。

最低標 ─ 至少分 .env.development 跟 .env.production、不要 hardcode URL。

05 用戶看到 bug 時你會收到通知嗎

很多 production 在掛掉之前、用戶其實看到 500 error 看了好幾個小時 ─ 而開發者本人是「同事傳訊息說網站打不開」才知道。

軟體會主動告訴你「它壞了」。

最便宜的方式：接錯誤監控服務（多數有免費額度）、API 噴 error 就會 Slack/Email 通知。Setup 通常 10 分鐘。

這 10 分鐘、是「我做了 code」跟「我做了軟體」的差別。

06 你能不能說出「為什麼這樣設計」

一個簡單的測試 ─ 隨便挑你 project 一段 code、自問：「這裡為什麼用 reduce 不用 for？為什麼這個資料用陣列不用物件？」

答得出來 ─ 這段 code 在做軟體。
答不出來、或心裡浮現「AI 給我的、我沒細看」 ─ 這段是 code、不是軟體。

軟體 = code + 背後的決策。

沒決策的 code、改起來像猜謎。每改一個地方都在賭「會不會壞別的」。

07 第二個工程師接得下去嗎

這條最殘忍 ─ 你離職後、它還活得下去嗎？

很多 startup 的工程師離職、整個產品停在那好幾個月。新人接手要從 0 摸索：怎麼 deploy、API 在哪 host、為什麼用 PostgreSQL 不用 MongoDB、為什麼這段 code 寫得這麼奇怪⋯⋯

軟體會有「新人 onboarding 文件」：30 分鐘讀完、能在自己電腦跑起來、能改第一個 PR。

code 通常是 ─ 「我寫的 code、只有我看得懂」。

08 你能用 1 句話解釋它在做什麼嗎

一個好的 PR review 習慣 ─ 每個改動都能用 1 句話講清楚「這個 PR 在做什麼、為什麼」。

說得清楚 ─ 表示作者真的懂。
說不清楚、或要說 5 分鐘 ─ 作者其實也在猜。

軟體有「可解釋性」。每段 code、每個決策、都能被講清楚。

09 安全嗎

這裡不是要講教科書的 OWASP Top 10。是要問你 ─ 你有沒有想過「會被搞」這件事？

最常見的 vibe code 漏洞：

• IDOR（直接物件參照漏洞）─ API 路徑是 /users/123/email、別人改個數字就看得到別人資料
• SQL 注入─ 字串拼 SQL、沒用 prepared statement
• 密鑰外洩─ API key 寫死在前端 JS、F12 就看得到
• CORS 全開─ Access-Control-Allow-Origin: * 配上 credentials

軟體會至少做到「最基本的 access control + 輸入驗證」。code 通常沒想過這件事。

10 加新功能會不會弄壞舊的

這是 vibe code 的經典死亡螺旋：

• 階段 1：加新功能、爽
• 階段 2：加新功能、舊的有 bug、修
• 階段 3：加新功能、舊的壞、新的也壞、再修
• 階段 4：不敢動了

軟體有「邊界」：一個 module 改、不會影響另一個。code 沒邊界 ─ 改一個壞十個。

檢查方式 ─ 你能不能畫出「這個 project 有幾個模組、彼此怎麼互動」？畫不出來、表示沒邊界。

11 你能解釋它怎麼賺錢嗎

這條對 founder 來說最關鍵。

很多人做 code 是為了「做出來」。但軟體要回答的是「為什麼存在」。

你的軟體解決了誰的什麼問題？他願意付多少？多久付一次？怎麼讓他續訂？

這些不是「商業問題」、是軟體本身的設計問題。code 可以無視、軟體不行。

12 有沒有人在用

這條最簡單、也最殘酷。

很多人 GitHub 上有 10 個 repo ─ 但問「哪個有人在用？」、答案通常是「沒」；再問「你自己呢？」、答案還是「沒」。

那 10 個 repo 是 code。0 個是軟體。

軟體一定有「使用者」── 就算只是你自己每天在用、也算。沒人用、它就只是「練習題答案」、不是軟體。

13 它會自我復原嗎

軟體不只是「會跑」、是「壞了會自己醒」。

• Server crash → 自動重啟（PM2 / systemd / k8s）
• DB connection lost → 自動 reconnect
• Memory leak → 定時 restart
• 第三方 API 暫時掛 → exponential backoff retry

這些不是「進階功能」、是「軟體該有的基本反射」。

14 你能跟另一個工程師討論它嗎

最後一條、也是最關鍵的。

軟體 ─ 你能跟另一個工程師討論「下一步該怎麼走」。
code ─ 你只能說「我 prompt 它就會出新功能」。

一個是「對話」、一個是「獨白」。

AI 時代、工程師最大的價值不是「寫 code」、是「能跟人討論軟體的方向」。AI 不會跟你討論、它只會輸出。

14 條檢查結果

這 14 條 ─ 你能勾幾條？

• 0-3 條：你做的是 code。先補 #01-03（README / git / 1 個測試）
• 4-8 條：你的 code 還算有救。補 #04-08（環境 / 監控 / 文件）
• 9-12 條：你做的是「勉強算軟體」。補 #09-12（安全 / 邊界 / 商業價值）
• 13-14 條：你做的是真的軟體、可以開始想「怎麼長大」

AI 給你的、永遠只到第 1 條（能跑）。
剩下的 13 條 ─ 你才能補。

這篇是檢查清單、不是教學文。我之後會在 Newsletter 拆 ─ 「如果你只能補 1 條、該補哪 1 條？」答案可能會讓你意外。

訂閱 Newsletter、跟著我用 100 天、把這 14 條一條條補滿給你看。全程公開在 mentry.dev。