把專案結構組織得讓 AI 能導航

AI 模型靠讀你的程式碼來推理。一個混亂、鋪得很開、不一致的專案，對它們來說和對你來說一樣難。你不需要完美的架構，但有幾個習慣能立刻見效：

• **保持可預測的佈局。**原始碼放一個地方，測試挨著原始碼或映象原始碼的結構，配置放在根目錄。
• 使用清晰、描述性的命名。calculateMonthlyInvoiceTotal 勝過 calc2。AI 把名字當作線索。
• **偏好更小的檔案。**對你們倆來說，一個 200 行的檔案都比一個 2000 行的更容易正確地修改。
• **把相關的東西放在一起。**當一個功能的程式碼、樣式和測試坐在一處時，AI 一次讀取就能收集到上下文。
• **保留一個清晰的入口點。**應用啟動的那個明顯的單一位置，給了 AI 一根在梳理專案時可以順著拉的線。

一個典型的、對 AI 友好的佈局可能長這樣：

my-app/
├── AGENTS.md            # 給 AI 的專案規則 & 上下文
├── README.md            # 專案簡介、如何執行
├── .env.example         # 記錄所需金鑰(無真實值)
├── .gitignore           # 排除 .env、構建產物、node_modules
├── package.json         # 指令碼: dev, test, lint, build
├── src/
│   ├── features/
│   │   └── invoices/    # 單個功能的程式碼 + 測試,放一起
│   ├── lib/             # 共享輔助函式
│   └── index.ts         # 入口點
└── tests/               # 橫切 / 整合測試

回報會複利式增長：你的專案越容易讓 AI 導航，它的改動就越小、越精準。一個井井有條的倉庫，讓 AI 去碰三個相關檔案，而不是在三十個檔案之間瞎猜——這意味著更小的 diff、更少的事故，以及你真能讀得下去的審查。如果你發現 AI 在做大刀闊斧、漫無焦點的編輯，真正的罪魁禍首往往是結構，而不是提示詞。