5,000 行不是分水嶺，沒餵清入口、規則、既有函式才是雷。
你昨天用 coding-AI 寫的東西，今天才發現結果不對
你只是叫 AI 寫程式助手(coding-AI)改一個「看起來很小」的功能：表單送出前多檢查一個狀態。它前面改單一檔案超順，這次卻開始表演魔術：自己生一個其實已經存在的輔助函式(helper)、元件鉤子(hook)引錯層、狀態管理(store)的 action 名字只猜對一半，最後還很自信地說「已完成」。你跑起來，畫面沒炸，也沒有紅字，但資料流已經歪掉。對，最煩的是這種：不是直接報錯給你看，是看起來能用，實際上在背後偷偷歪。
真正的問題不是行數，是地圖不完整
5,000 行程式碼庫對人來說不算巨大，對 coding-AI 來說也不是一碰到就陣亡。真正麻煩的是：目前多數工具看到的不是「整個專案地圖」，而是被塞進上下文視窗(context window)的幾塊拼圖。你以為它知道元件鉤子怎麼接狀態管理、工具函式哪個能用、命名慣例長什麼樣；它其實常常只看到幾個開啟的檔案，再加上一點搜尋結果。
所以它會用「合理猜測」把缺的洞補起來。聽起來很聰明，實際上很容易歪掉：看到 `useUser` 就猜有 `useOrder`，看到 `formatDate` 就再寫一個 `formatCurrency`，看到某個狀態管理模式，就以為所有狀態管理都長一樣。小專案猜中率高，看起來像神；真實專案一有歷史包袱、例外命名、跨層依賴，它就開始迷路。
Ryz Labs 做過 6 個月測試，超過 10k 行的程式碼庫裡，coding-AI 準確率掉到約 50%。這不是說 5,000 行就不能用，而是提醒：規模一上來，上下文管理會從「可有可無」，變成「不管就會被雷」。
它是怎麼悄悄迷路的
第一種：重複造輪子。專案早就有 `normalizeUserPayload`，但 AI 沒看到，或搜尋不到，就在新檔案裡再寫一個 `formatUserData`。功能短期能跑，半年後兩邊邏輯分岔，PM 問「為什麼同一個欄位兩頁顯示不同」，大家一起沈默。
第二種：接錯抽象層。你要它改元件鉤子(hooks)，它直接去改元件(component)；你要它用狀態管理(store)的 action，它改成元件裡自己 call API。這種最陰，因為展示(demo)可能過，但專案原本的快取(cache)、載入狀態(loading)、錯誤處理(error handling)、權限檢查都被繞掉。
第三種：忘記專案習慣。這個程式碼庫(codebase)可能規定 API 都走 `client.ts`，錯誤都丟 `AppError`，日期都用同一個 utility。AI 沒拿到規則(rules)，就會寫出「語法沒錯、風格很外包」的程式碼。review 時看了會想問：這位同事第一天來嗎？
今天就能補穩的 4 個動作
**先給它入口地圖，不要只丟任務。** 開工前貼一段「專案導覽」：主要資料流從哪個元件(component)進來、元件鉤子放哪、狀態管理管什麼、工具函式(utility)放哪、API client 怎麼走。不用長，像交接新同事那樣 10 行就有差。
**要求它先找既有實作，再寫程式碼(code)。** 提示詞(prompt)裡直接加：「改動前先搜尋是否已有相同輔助函式(helper)、元件鉤子、狀態管理 action；列出你找到的可重用項目。」這招很土，但能擋掉一堆重複函式。不要讓它一上來就開寫，先逼它逛專案。
**把 project rules 寫成固定檔。** 例如：命名規則、資料流規則、不能直接呼叫 API 的地方、錯誤處理格式、測試放哪。放在 repo 裡，讓 coding-AI 每次任務都讀。這不是儀式感，是讓它少靠猜。
**Review 時專抓跨檔邏輯，不只看語法。** Simon Willison 提過，假套件這種凸槌(hallucination,AI 一本正經亂講)反而沒那麼可怕，因為跑一下就爆；真麻煩的是「跑得起來但邏輯不對」。所以 review 要問：有沒有繞過既有流程？有沒有少用既有輔助函式(helper)？有沒有改到不該改的層？
拿走的一句話
大型程式碼庫不是不能交給 AI，而是要先餵它地圖、規則、還有原本大家怎麼走的既有路徑；不然它會很努力，但很可能一路走錯。
