AI能幫忙取名字，也能發現命名異常。我們需要懂的，是這個名字在系統裡代表什麼。

昨天談到，同樣叫做庫存，可能是在庫量，也可能是可售量。名稱提供了理解的起點，而我們如何命名，也會影響同事與AI接下來怎麼使用這份資料。

例如，要替既有訂單流程加上出貨通知，規格已經寫清楚：寄給訂單指定的收件人。讀到訂單裡的User，卻還要確認它究竟是購買的人、操作帳號，還是收件人。

這個疑問可以由工程師提出，也可以在AI分析程式時被主動指出。接下來要做的，是把名稱與實際用途核對清楚。

先知道在說誰，才知道名字怎麼取

以公司採購為例，登入的是採購人員，訂單歸屬的客戶是公司，收件人可能是倉管。同一張訂單，這幾個角色各有用途。

因此，命名時可以分別表達：

• CreatedByAccountId：建立訂單的操作帳號。
• CustomerId：訂單歸屬的客戶。
• RecipientEmail：訂單指定的收件Email。

這些名稱的價值，在於讓讀程式的人知道該拿哪個欄位做判斷。查操作紀錄、統計客戶訂單與寄送出貨通知，需要的是不同資料。

如果自己也沒分清楚，請AI「幫我取個更好的名字」，得到的可能只是英文更順，含義仍然模糊。

AI提出的提醒，也需要有依據地判斷

提供規格、資料模型與相關程式後，AI可以協助追查欄位的寫入與使用位置，找出名稱和用途不一致的地方。例如它可能提醒：某個叫做User的物件，實際只保存收件資料，建議改成Recipient。

這是很有用的協助。但接受建議前，還要確認這個物件是否真的只代表收件人。如果其他流程也把它當成購買者使用，就需要先釐清資料混用的原因，不能直接整批換名字。

反過來，AI也可能受到名稱影響，把CustomerId當成客戶識別，卻沒有發現它在某段舊流程中保存的是操作帳號。這是需要核對的風險，並不表示AI必然會漏看。

我覺得，懂得命名背後的概念，讓我們能和AI討論「為什麼這樣改」。它指出異常時，我們能判斷是否合理；它沿用舊名稱時，我們也知道要追查哪些關係。

團隊說的是同一件事，AI才有一致的脈絡

這件事在人與人之間也一樣。如果規格裡的「客戶」指公司，開會時卻拿來稱呼操作人員，程式再全部寫成User，接手的人就得重新猜一次。

在同一個業務範圍裡，同一概念盡量使用一致的名稱；不同角色會影響處理規則時，就明確區分。不同系統有自己的用語，也應交代對應關係。

確認過的定義可以留在專案Markdown文件裡，讓團隊與AI在修改前讀取。例如簡短記錄：「Account是操作帳號，Customer是交易對象，出貨通知使用訂單的RecipientEmail。」這比只有「請遵守良好命名」更能提供判斷依據。

若命名檢查已成為固定工作，再考慮把追查來源、核對定義與檢查影響的步驟整理成Skill。文件記錄的共識需要保持正確，也要讓AI在相關任務中實際讀到。

名稱改清楚了，再確認資料真的用對

回到出貨通知，若實作改成：

await SendShipmentNotificationAsync(order.RecipientEmail);

審查時仍要確認，這個值確實來自訂單指定的收件資料。只把登入帳號的Email放進新名稱，並沒有解決問題。

測試可以讓購買者與收件人使用不同Email，確認通知寄到規格指定的對象。這個情境能檢查角色是否被混用，而不只是看程式中的名字是否一致。既有公開欄位若需要更名，也要核對使用端的相容性。

清楚的命名，讓我們能把業務概念交代清楚、判斷AI的建議，並確認修改符合原本的意思。 AI可以一起找出問題，團隊也能把釐清過的共識留下來，減少下一次修改時的猜測。

工程師問前輩：「這個叫Temp的資料夾可以刪嗎？」
前輩：「不行，正式環境還在用。」
「那為什麼叫Temp？」
「因為五年前，我們以為只會用一個禮拜。」