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

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

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

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

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

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

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

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

名稱是線索，寫入的資料才是證據

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

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

名稱也可能同時誤導人和AI。CustomerId看起來是客戶識別，在某段舊流程中保存的卻可能是操作帳號。判斷一個欄位代表什麼，要看它在哪裡被寫入、寫進了什麼，而不只是它叫什麼。

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

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

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

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

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

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

await SendShipmentNotificationAsync(order.RecipientEmail);

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

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

名稱是團隊與AI共用的約定。約定要成立，名稱、定義與實際寫入的資料得是同一件事；只改名字，資料並不會跟著變正確。

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