Day12-客戶管理原型：從成功協作到代碼管理的新挑戰

今天設計客戶管理系統時，我延續昨天學到的成功方法：先想好需求，用人話表達，再寫Prompt讓AI協作。

本以為會遇到類似的業務邏輯挑戰，沒想到這次AI協作出奇順利，90%的功能一次到位！但就在我為這次成功感到滿意時，卻發現了一個更基礎但同樣重要的問題：代碼文件管理。

客戶管理的實際需求：就是簡單的CRUD

按照這個流程，我先分析了客戶管理在門市的真實使用情境。與昨天產品查詢的複雜業務邏輯不同，客戶管理系統其實相對簡單直接。

核心功能需求：

• 客戶資料的新增、查看、編輯、刪除
• 基本的搜尋和篩選功能
• 客戶資料包含：姓名、電話、地址、會員等級、備註

門市使用情境：

• 客戶進門時快速查詢客戶資料
• 新客戶註冊時建立檔案
• 客戶資料異動時即時更新

沒有複雜的暫存機制，沒有多維度篩選，就是最基本的資料管理功能。相比昨天的產品查詢，這應該是輕鬆的一天。

第一版Prompt：延續成功的協作模式

基於前幾天累積的經驗，我設計了第一版Prompt：

根據Layout框架設計.md和業務邏輯.md，設計一個客戶管理系統：

使用情境：
- 店員需要快速查看和管理客戶資料
- 支援客戶的新增、編輯、刪除功能
- 客戶資料包含：姓名、電話、地址、會員等級、備註
- 需要基本的搜尋和篩選功能

Layout要求：
- 沿用Dashboard的固定框架設計
- 左側客戶列表，右側客戶詳細資料
- 支援新增/編輯的彈出視窗
- 保持與其他頁面的視覺一致性

功能需求：
- 客戶CRUD操作
- 搜尋功能（按姓名、電話）
- 篩選功能（按會員等級、地區）
- 會員等級的視覺標識

請產出完整的HTML原型，包含互動效果。

90%完成度的第一版成果

Cursor的表現超乎預期！第一版產出就已經90%符合需求：

幾乎沒有需要大幅修正的問題，只有一些小細節需要調整，比如會員標籤的顏色深度、表單驗證的提示訊息等。

相比昨天產品查詢第一版的化妝品假資料問題，今天的客戶管理一次到位的成功率讓我很驚喜。

但是，代碼行數的無情增長

正當我為這次順利的協作感到高興時，突然意識到一個被忽略的問題：代碼檔案又變成巨獸了！

行數統計的現實：

• Dashboard: 800行
• Products: 1500行
• Client: 1500行

這還只是第二階段的開始！後續還有訂單系統、退換貨系統等更複雜的頁面，如果繼續用單一HTML檔案的方式，很快就會面臨維護災難。

實際遇到的問題：
當我想調整客戶卡片的背景顏色時，要在1200行混合代碼中搜尋對應的CSS規則，經常找錯位置。

當我想理解新增客戶的邏輯時，JavaScript函數散佈在HTML的各個角落，需要來回跳轉才能看懂完整流程。

當我想統一調整底部Tab樣式時，需要在Dashboard、Products、Client三個檔案中重複修改，很容易漏改或不一致。

Cursor協作效率的下降

1500行混合代碼對Cursor協作造成的影響比想像中嚴重：

修改定位困難：
「請修改客戶卡片的樣式」→ Cursor需要花時間在1200行中找到正確位置，有時會修改錯區域。

上下文理解複雜：
HTML結構、CSS樣式、JavaScript邏輯混在一起，Cursor需要更多時間理解整體架構。

修改精確度下降：
複雜的檔案結構讓Cursor的修改建議變得不夠精準，經常需要多次來回調整。

這些問題隨著檔案大小增加而惡化，必須找到解決方案。

基本解決方案：檔案分離

解決方案其實很簡單：把CSS和JavaScript拆分成獨立檔案。

我向Cursor提出了分離需求：

請將這個客戶管理系統拆分為三個檔案：

1. client-management.html - 只包含HTML結構
2. client-management.css - 所有CSS樣式
3. client-management.js - 所有JavaScript邏輯

HTML檔案用<link>和<script>引用外部檔案，功能保持完整。

分離後的顯著改善

拆分效果立竿見影：

檔案結構清晰：

• client-management.html：從1200行縮減到180行，只有乾淨的HTML結構
• client-management.css：750行純CSS，樣式規則井然有序
• client-management.js：540行純JavaScript，函數邏輯清楚易懂

Cursor協作效率大幅提升：

• 要改樣式？「請修改client-management.css中的.customer-card背景色」
• 要改功能？「請在client-management.js中加入客戶排序功能」
• 修改定位精確，不會影響其他部分

開發維護更容易：

• HTML結構語義清楚，容易理解頁面架構
• CSS集中管理，視覺調整更直觀
• JavaScript邏輯獨立，函數關係一目了然

後續擴充更方便：

• 想複製樣式到其他頁面？直接參考CSS檔案
• 要理解某個功能？只需專注JS檔案
• 檔案職責清楚，降低意外修改風險

適用時機和經驗總結

什麼時候該分離檔案？

• 當單一HTML檔案超過800行時
• 當Cursor開始出現定位困難時
• 當需要重複修改相同元素時
• 當協作效率明顯下降時

分離的好處：

• 提升AI協作精確度
• 簡化代碼維護工作
• 改善檔案可讀性
• 便於後續功能擴充

這不是過度工程化，而是基本的代碼管理實踐。即使是prototype階段，當複雜度超過某個門檻時，適當的檔案組織仍然必要。

客戶管理系統讓我學到：好的協作不只需要好的方法論，還需要好的代碼管理。當工具開始限制效率時，就是改進工作方式的時機。檔案分離雖然簡單，但對協作效率的提升非常明顯。
好的工具配上好的組織方式，才能發揮最大的協作效率。