那天的代碼評(píng)審我差點(diǎn)被一支命名為model_final_v2_really的分支勸退。旁邊的同事把投影儀切到 deploy 配置界面里面躺著ai_platform_test2、ai_platform_test3、ai_platform_new_new誰(shuí)也不知道哪個(gè)才是生產(chǎn)環(huán)境真正在用的。不是大家不懂命名而是當(dāng)團(tuán)隊(duì)被 AI 項(xiàng)目的快節(jié)奏推著走時(shí)命名這件事總是被排在“到最后再說(shuō)”的那一欄。但 AI 項(xiàng)目恰恰是最不能忽視命名的地方模型會(huì)迭代、服務(wù)會(huì)拆分、數(shù)據(jù)集會(huì)擴(kuò)展代碼里任何一個(gè)模糊的名字都會(huì)在一周后變成團(tuán)隊(duì)之間互相確認(rèn)的成本。我后來(lái)想了一件反直覺(jué)的事與其在model_best和model_best_v2里反復(fù)掙扎不如把目光放回半個(gè)多世紀(jì)前的科幻小說(shuō)。60 年代的科幻名今天拿來(lái)給 AI 項(xiàng)目命名仍然夠用而且往往比我們自己現(xiàn)場(chǎng)造的詞更準(zhǔn)確、更有辨識(shí)度。這不是情懷而是一種工程策略。1. 為什么AI項(xiàng)目的命名問(wèn)題比普通項(xiàng)目更嚴(yán)重1.1 從變量名到模型名命名的層級(jí)被低估了很多團(tuán)隊(duì)在還沒(méi)有正式命名規(guī)范的情況下就先跑通了第一版 AI 服務(wù)。這可以理解畢竟從訓(xùn)練到部署中間有太多比命名更緊急的事。我自己也做過(guò)這種事先用test.py跑通 PyTorch 推理再?gòu)?fù)制成test2.py調(diào)整參數(shù)最后等到需要給這個(gè)模型寫(xiě)網(wǎng)關(guān)接口的時(shí)候才發(fā)現(xiàn)根目錄下已經(jīng)躺了五個(gè)不重樣但意思差不多的文件。AI 項(xiàng)目里的命名不是只有變量名和函數(shù)名。它是一個(gè)從底層到上層的完整鏈條數(shù)據(jù)集名稱訓(xùn)練集、驗(yàn)證集、測(cè)試集以及經(jīng)過(guò)清洗、增強(qiáng)后的不同版本。模型結(jié)構(gòu)名稱網(wǎng)絡(luò)結(jié)構(gòu)、預(yù)訓(xùn)練權(quán)重、微調(diào)版本對(duì)應(yīng)的標(biāo)識(shí)。特征名稱不同特征工程步驟產(chǎn)出的字段。服務(wù)接口名稱API 路徑、模型服務(wù)名、推理服務(wù)版本號(hào)。環(huán)境名稱dev、staging、prod以及每個(gè)環(huán)境的模型映射關(guān)系。配置鍵名稱超參、路徑、開(kāi)關(guān)、模型列表等配置項(xiàng)。只要這一層里的任何一級(jí)命名是隨手的后面排查問(wèn)題時(shí)就會(huì)被反復(fù)擊中。尤其當(dāng)模型從實(shí)驗(yàn)狀態(tài)進(jìn)入產(chǎn)品狀態(tài)后model_final_v2這種名字幾乎必然導(dǎo)致誤用。它不是風(fēng)格問(wèn)題是生產(chǎn)事故的隱患。1.2 AI原生團(tuán)隊(duì)為什么最容易出現(xiàn)命名混亂按理說(shuō)AI 從業(yè)者普遍對(duì)抽象概念敏感應(yīng)該更容易理解命名的價(jià)值。但實(shí)際觀察到的現(xiàn)象恰恰相反。原因是 AI 項(xiàng)目的開(kāi)發(fā)節(jié)奏太像“研究”而不是“研發(fā)”一開(kāi)始沒(méi)有人知道哪個(gè)方向能跑通于是每個(gè)人都在自己的臨時(shí)目錄里做實(shí)驗(yàn)。實(shí)驗(yàn)本身就是試錯(cuò)名字自然也會(huì)隨意很多。另一個(gè)推手是模型迭代速度。一個(gè)模型今天還是v1.0明天因?yàn)榧恿藬?shù)據(jù)增強(qiáng)變成v1.1后天又換了一個(gè) backbone可能就要叫v1.2或v2.0。如果命名規(guī)則沒(méi)有事先定好大家就會(huì)憑感覺(jué)加_new、_plus、_refactor、_final這樣的后綴。這些后綴在寫(xiě)代碼的那一秒鐘有意義但過(guò)兩周再看沒(méi)人能回憶起當(dāng)時(shí)的“感覺(jué)”。這些問(wèn)題在普通 Web 項(xiàng)目里也存在但在 AI 項(xiàng)目里會(huì)更難清理。原因是模型產(chǎn)物的體積大、路徑依賴強(qiáng)很多運(yùn)行結(jié)果都綁定在特定的實(shí)驗(yàn)?zāi)夸浵乱坏┟謥y掉重跑的代價(jià)很高。你沒(méi)法簡(jiǎn)單復(fù)制一個(gè)model_final_v2的文件夾然后重新訓(xùn)練一遍。1.3 命名不是風(fēng)格潔癖是溝通成本很多團(tuán)隊(duì)把代碼命名當(dāng)成“風(fēng)格問(wèn)題”覺(jué)得只要功能正常大小寫(xiě)和下劃線都無(wú)所謂。但實(shí)際上命名是注釋之外最重要的溝通載體。代碼首先是給人讀的其次才是給機(jī)器執(zhí)行的。一個(gè)變量叫user_age和一個(gè)變量叫a1對(duì)于讀代碼的人認(rèn)知負(fù)擔(dān)完全不同。AI 項(xiàng)目里這種差距會(huì)被放大因?yàn)榇a里到處都是張量、矩陣、損失函數(shù)和評(píng)估指標(biāo)本身就足夠抽象如果再疊加模糊命名可讀性會(huì)迅速崩掉。從這個(gè)角度看命名是一種降低溝通成本的投資。好的命名讓新成員入職時(shí)能快速定位代碼壞的命名讓所有人都在群里反復(fù)追問(wèn)“這個(gè)參數(shù)是干什么的”。算下來(lái)一個(gè)命名檢查清單可以省下大量“看起來(lái)不重要但實(shí)際上很磨人”的溝通。2. 60年代科幻留給AI時(shí)代的命名寶庫(kù)2.1 那些跨越半個(gè)世紀(jì)的詞匯和意象為什么我會(huì)說(shuō) 60 年代科幻名仍可用因?yàn)槟且淮苹米髌芳杏懻摿艘粋€(gè)核心主題人與智能機(jī)器的邊界。阿西莫夫的機(jī)器人系列、海因萊因的《嚴(yán)厲的月亮》、克拉克的《2001太空漫游》這些作品里出現(xiàn)了大量后來(lái)成為技術(shù)世界通用詞的名字和概念。無(wú)論是 “Robot” 這個(gè)基本詞還是 “Hal” 這樣的人工智能角色名都自帶一種“智能體”的文化線索。如果從 AI 項(xiàng)目命名的角度看這些名字有一個(gè)共同特點(diǎn)它們不是無(wú)意義的音節(jié)而是自帶一段可以被解釋的故事。給一個(gè)語(yǔ)義檢索服務(wù)起名Foundation團(tuán)隊(duì)里讀過(guò)《基地》的人會(huì)立刻知道這是一個(gè)提供基礎(chǔ)能力的平臺(tái)服務(wù)給一個(gè)超大規(guī)模模型起名Ansible懂科幻的人能聯(lián)想到“瞬時(shí)通信”的意象很適合用于需要快速同步的分布式推理場(chǎng)景。即便團(tuán)隊(duì)里沒(méi)人讀過(guò)原著只要命名文檔里解釋一句“這個(gè)詞來(lái)自經(jīng)典科幻代表跨距離實(shí)時(shí)協(xié)同”名字就有了記憶點(diǎn)。這些名字比隨手造的aiprocessor更有生命力。因?yàn)樗鼈儾皇切袠I(yè)黑話而是公共文化的一部分。任何人都可以借助這個(gè)文化背景快速理解一個(gè)產(chǎn)品或者一個(gè)模塊在解決什么問(wèn)題。2.2 為什么科幻名比新造詞更適合AI產(chǎn)品新造的復(fù)合詞有一種天然缺陷第一次看到它時(shí)你不知道它是組合詞、簡(jiǎn)稱還是誤拼。比如smartbrain這種名字看似直觀但它既沒(méi)有提供新的理解框架也沒(méi)有讓讀者聯(lián)想到任何已有的知識(shí)背景。它只是一種“描述性標(biāo)簽”相當(dāng)于把“智能大腦”翻譯成英文并拼在一起信息量很低。相反一個(gè)成熟的科幻名往往具有三個(gè)特性可聯(lián)想它關(guān)聯(lián)著一個(gè)已有的概念或故事用戶能通過(guò)類比快速理解產(chǎn)品定位?？善醋x大部分經(jīng)典科幻名都遵循字母語(yǔ)言的自然讀音規(guī)則不容易讀錯(cuò)?？蓴U(kuò)展同一個(gè)詞根可以衍生出系列名例如用Foundation作為平臺(tái)名子服務(wù)可以叫Foundation-Index、Foundation-Query形成一套干凈的名字樹(shù)。這里要注意不是所有科幻名都適合直接使用。太長(zhǎng)或太生僻的詞會(huì)造成輸入負(fù)擔(dān)。比如某個(gè)角色的全名可能很有史詩(shī)感但每次部署時(shí)都要在命令行里敲一遍就會(huì)變成純粹的負(fù)擔(dān)。所以一個(gè)基本建議是優(yōu)先選擇兩個(gè)音節(jié)的短詞、可作名詞的專有名詞以及不會(huì)和現(xiàn)有技術(shù)棧沖突的詞匯。2.3 使用科幻名的邊界商標(biāo)、語(yǔ)義錯(cuò)位與版本歸屬把科幻名當(dāng)作命名靈感不等于閉著眼直接抄。需要先做三件事。第一件事是排查商標(biāo)風(fēng)險(xiǎn)。很多經(jīng)典科幻名已經(jīng)被注冊(cè)成了產(chǎn)品商標(biāo)或技術(shù)項(xiàng)目名稱。比如Gort在多個(gè)領(lǐng)域都有使用Trantor也有對(duì)應(yīng)的軟件組織名。不能因?yàn)槊趾寐?tīng)就直接用尤其是商業(yè)產(chǎn)品必須先做基礎(chǔ)檢索。第二件事是檢查語(yǔ)義錯(cuò)位。一個(gè)詞在原作里可能代表“無(wú)所不知的超級(jí)智能”但你的項(xiàng)目只是一個(gè)輕量級(jí) API 網(wǎng)關(guān)。名字太重反而會(huì)增加團(tuán)隊(duì)心理負(fù)擔(dān)也會(huì)讓外部用戶產(chǎn)生錯(cuò)誤預(yù)期。命名要和項(xiàng)目的實(shí)際復(fù)雜度匹配。第三件事是版本歸屬。如果同名項(xiàng)目已經(jīng)存在開(kāi)源版本而你只是使用別人代碼庫(kù)里的部分思想再用同一個(gè)名字會(huì)引發(fā)混淆。這時(shí)候可以在名字后面加-like或使用變體例如在內(nèi)部項(xiàng)目里叫FoundationX并明確記錄“從某開(kāi)源項(xiàng)目獲得靈感但內(nèi)部實(shí)現(xiàn)已獨(dú)立重構(gòu)”。命名建議不是讓你執(zhí)著于原作忠實(shí)度而是讓名字在真實(shí)工程里能穩(wěn)定使用五年。如果名字好看但下個(gè)月就得換那么這個(gè)靈感本身就沒(méi)有轉(zhuǎn)化價(jià)值。3. 一套可以落地的AI命名方法3.1 先給命名對(duì)象分層如果想把命名從“碰運(yùn)氣”變成“流程化”第一步不是找名字而是先分清楚這次的命名對(duì)象到底是哪一個(gè)層級(jí)。不同層級(jí)的命名約束完全不同。常見(jiàn)的 AI 項(xiàng)目命名層級(jí)可以分成五層產(chǎn)品層對(duì)外展示的產(chǎn)品名例如智能助手、推薦系統(tǒng)、視覺(jué)分析平臺(tái)。項(xiàng)目層代碼倉(cāng)庫(kù)名、項(xiàng)目代號(hào)、內(nèi)部服務(wù)名。模塊層核心算法模塊、數(shù)據(jù)模塊、評(píng)估模塊、部署模塊。模型層模型結(jié)構(gòu)名、預(yù)訓(xùn)練權(quán)重名、微調(diào)版本名。資源層數(shù)據(jù)集名、特征名、配置鍵名、環(huán)境名。越靠近產(chǎn)品層越需要顧及用戶記憶、品牌辨識(shí)度越靠近資源層越需要遵循技術(shù)一致性減少特殊字符和長(zhǎng)度限制。很多命名混亂的根源在于把產(chǎn)品層的取名思路用到了資源層或者反過(guò)來(lái)。比如在配置鍵里使用大小寫(xiě)混合、帶空格的長(zhǎng)標(biāo)題結(jié)果導(dǎo)致腳本解析出錯(cuò)。一個(gè)穩(wěn)妥的流程是先明確“現(xiàn)在給哪一層命名”再?zèng)Q定風(fēng)格。產(chǎn)品層可以大膽使用科幻意象模塊層應(yīng)該優(yōu)先考慮語(yǔ)義清晰模型層則必須包含版本信息和時(shí)間錨點(diǎn)資源層要盡量全部使用小寫(xiě)字母、數(shù)字和下劃線。3.2 從科幻意象到合規(guī)標(biāo)識(shí)符的轉(zhuǎn)換規(guī)則選好了想用的科幻詞還得把它轉(zhuǎn)成符合當(dāng)前技術(shù)棧的標(biāo)識(shí)符。不同語(yǔ)言和平臺(tái)有不同的風(fēng)格習(xí)慣。比如 Java 類名常用帕斯卡命名法FoundationIndex變量名和函數(shù)名用駝峰命名法foundationIndexPython 變量和函數(shù)名用下劃線命名法foundation_indexC 命名空間和類名在不同團(tuán)隊(duì)里也有不同約定。并不是所有科幻名都能原樣放進(jìn)代碼里需要進(jìn)行標(biāo)準(zhǔn)化處理。轉(zhuǎn)換時(shí)可以按下面這套規(guī)則處理去掉特殊字符空格、連字符、撇號(hào)一律去掉或轉(zhuǎn)成下劃線。統(tǒng)一大小寫(xiě)風(fēng)格根據(jù)所在語(yǔ)言和項(xiàng)目規(guī)范使用 camelCase、PascalCase 或 snake_case?？s寫(xiě)檢查如果名字本身很長(zhǎng)可以壓縮到 2-3 個(gè)音節(jié)但必須在代碼注釋里標(biāo)注全名。語(yǔ)言約束檢查避免使用保留字、避免數(shù)字開(kāi)頭、避免連續(xù)下劃線?？缒K查重在代碼庫(kù)中搜索同名確認(rèn)沒(méi)有沖突。例如FoundationIndex在 Python 模塊里可以變成foundation_index在 API 路徑里可以變成foundation/index在環(huán)境變量里可以變成FOUNDATION_INDEX_ENDPOINT。只要在文檔里建立一張“科幻名 → 各層標(biāo)識(shí)符”的映射表團(tuán)隊(duì)就能始終清楚地知道同一個(gè)概念在不同位置用了什么名字。3.3 命名質(zhì)量檢查清單每完成一個(gè)命名可以跑一遍下面的清單。不需要很長(zhǎng)時(shí)間但能攔截大多數(shù)后續(xù)問(wèn)題。檢查項(xiàng)說(shuō)明通過(guò)標(biāo)準(zhǔn)可讀性其他人是否能只看名稱就大致理解用意不用解釋也能猜出五成以上可拼讀口頭討論時(shí)是否能順暢讀出來(lái)不會(huì)出現(xiàn)長(zhǎng)停頓或拼字母無(wú)歧義在當(dāng)前項(xiàng)目里是否有多個(gè)完全不同的含義一個(gè)名稱只對(duì)應(yīng)一個(gè)核心概念一致性是否與同級(jí)其他命名風(fēng)格一致同一層級(jí)使用同一套大小寫(xiě)和分隔符規(guī)則長(zhǎng)度控制是否在可接受的長(zhǎng)度范圍內(nèi)資源層盡量不超過(guò) 32 個(gè)字符版本辨識(shí)是否包含可追蹤版本信息模型名中至少有主干版本號(hào)商標(biāo)/沖突是否與已有開(kāi)源項(xiàng)目或商業(yè)產(chǎn)品明顯沖突搜索后無(wú)高相似同名風(fēng)險(xiǎn)文檔映射是否有文檔記錄該命名的來(lái)源和含義README 或命名規(guī)范表中有條目這張清單不需要每次都打印出來(lái)。可以把它做成 code review 的勾選項(xiàng)或者寫(xiě)進(jìn)命名規(guī)范文檔的第一頁(yè)。真正有用的不是清單本身而是它強(qiáng)制團(tuán)隊(duì)在命名這件事上做一次慢思考。如果你現(xiàn)在沒(méi)有一個(gè)可以長(zhǎng)期使用的命名規(guī)范我建議先做一張最簡(jiǎn)單的命名映射表一列寫(xiě)目標(biāo)詞匯一列寫(xiě)產(chǎn)品名一列寫(xiě)項(xiàng)目名一列寫(xiě)代碼標(biāo)識(shí)符。之后所有新模塊都先查表再?zèng)Q定是否新增名字。4. 從命名靈感到團(tuán)隊(duì)共識(shí)工程化落地建議4.1 用規(guī)范文檔和代碼評(píng)審守住一致性僅有一個(gè)人覺(jué)得“60 年代科幻名挺好用”是不夠的。命名要成為團(tuán)隊(duì)資產(chǎn)必須沉淀成文檔并在代碼評(píng)審時(shí)被實(shí)際執(zhí)行。否則每個(gè)人都會(huì)按自己的口味來(lái)有人喜歡《沙丘》有人喜歡《海伯利安》很快就會(huì)形成另一層混亂。具體做法可以在項(xiàng)目根目錄放一份NAMING.md內(nèi)容不用很長(zhǎng)但要包含命名對(duì)象層級(jí)、風(fēng)格約定、允許使用的詞根、禁止使用的后綴、以及一張“已使用名稱登記表”。登記表很關(guān)鍵。它避免兩個(gè)模塊分別用了同名科幻詞而互相覆蓋也避免后人不知道trantor其實(shí)是一個(gè)未上線模塊的代號(hào)。代碼評(píng)審里命名應(yīng)該是一票否決項(xiàng)。不是為了讓評(píng)審人扮演語(yǔ)文老師而是因?yàn)槊麊?wèn)題一旦合并后續(xù)改動(dòng)成本會(huì)指數(shù)級(jí)上升。在評(píng)審時(shí)問(wèn)三個(gè)問(wèn)題這個(gè)命名是否準(zhǔn)確表達(dá)了模塊功能是否符合NAMING.md中的層級(jí)規(guī)范是否有同級(jí)別的其他命名風(fēng)格可以參考三個(gè)問(wèn)題都過(guò)關(guān)再談邏輯實(shí)現(xiàn)。4.2 模型名、API名和環(huán)境名的統(tǒng)一策略在 AI 項(xiàng)目里最容易出現(xiàn)命名不一致的是模型、API 和環(huán)境這三組名稱之間的對(duì)應(yīng)關(guān)系。比如模型叫bert_base_uncased對(duì)應(yīng)的 API 路徑卻叫/v1/semantic環(huán)境變量里叫MODEL_A。一旦三者不能對(duì)應(yīng)排查問(wèn)題時(shí)會(huì)耗費(fèi)大量時(shí)間。一個(gè)較穩(wěn)的策略是讓三者共享同一個(gè)核心標(biāo)識(shí)符。假設(shè)我們選擇了一個(gè) 60 年代科幻詞trantor作為某個(gè)文本分類服務(wù)的內(nèi)核名那么模型目錄名tranto_bert_base_v1服務(wù)名trantor-classifierAPI 前綴/v1/trantor/classify環(huán)境變量TRANTOR_MODEL_PATH、TRANTOR_SERVICE_URL部署環(huán)境標(biāo)簽trantor-dev、trantor-staging、trantor-prod這樣從日志、監(jiān)控指標(biāo)到部署配置都能通過(guò)trantor這根主線快速串起來(lái)。如果服務(wù)內(nèi)部有多個(gè)模型再用trantor-entity、trantor-sentiment作為子標(biāo)識(shí)保持家族感的同時(shí)也保證唯一性。這套做法的本質(zhì)不是追求名字好看而是讓一個(gè)詞成為跨層級(jí)的“外鍵”。只要核心標(biāo)識(shí)穩(wěn)定其他數(shù)據(jù)都容易被追蹤。4.3 命名混亂時(shí)的排查與重構(gòu)路徑如果項(xiàng)目里已經(jīng)出現(xiàn)了大量的model_new、test_final也不要急著立刻全部重命名因?yàn)槊つ恐貥?gòu)可能破壞代碼。建議按下面的鏈路排查先確認(rèn)最危險(xiǎn)的部分哪些命名直接關(guān)聯(lián)生產(chǎn)環(huán)境配置、模型路徑、數(shù)據(jù)庫(kù)表名和 API 路由。這部分風(fēng)險(xiǎn)最高優(yōu)先處理。再做依賴分析使用代碼搜索工具查一下目標(biāo)名稱在哪些文件、腳本、文檔、K8s 配置、CI 流程中出現(xiàn)過(guò)。不要只看.py文件還要看yaml、json、Dockerfile和.env樣例。然后建立映射表把舊名和新名一一對(duì)應(yīng)先在文檔里列出不要直接在代碼里全局替換。按模塊分批重構(gòu)每次只改一個(gè)子模塊并且立即跑測(cè)試和部署驗(yàn)證。避免在周五下午一次性替換所有文件。最后更新文檔和配置模板很多項(xiàng)目只改代碼忘了更新 README 里的示例命令和配置模板。結(jié)果新成員照著舊文檔啟動(dòng)服務(wù)又生成了一次舊名字的實(shí)例。這套路徑的核心不是“趕緊把名字改漂亮”而是先識(shí)別哪些名字是真實(shí)正在被依賴的哪些只是陳舊的殘留物。把依賴?yán)眄樍嗣貥?gòu)才不會(huì)改出一堆新的_v2。5. 最后的建議先從一個(gè)變量名開(kāi)始改變5.1 適合用60年代科幻名的場(chǎng)景不是所有 AI 項(xiàng)目都適合使用科幻名但有幾種場(chǎng)景非常合適。如果你的團(tuán)隊(duì)正在做內(nèi)部平臺(tái)或工具鏈?zhǔn)褂每苹妹梢越档蜏贤ǔ杀?。比如把?shù)據(jù)管道服務(wù)命名為psychohistory團(tuán)隊(duì)里自然會(huì)有好奇的人去查這個(gè)詞的出處從而在討論“數(shù)據(jù)預(yù)測(cè)”這個(gè)話題時(shí)多一層共同語(yǔ)言。如果團(tuán)隊(duì)本來(lái)就有閱讀科幻的習(xí)慣這種做法會(huì)顯著增強(qiáng)項(xiàng)目本身的辨識(shí)度。如果你的項(xiàng)目需要一個(gè)可擴(kuò)展的命名族譜科幻名也比功能性口號(hào)更耐用。比如用ansible作為分布式部署平臺(tái)的核心代號(hào)子功能可以叫ansible-discovery、ansible-sync比sync-service-v1、deploy-worker-2更容易記憶。如果你的產(chǎn)品想要傳達(dá)“智能體”“自主系統(tǒng)”“機(jī)器與人類協(xié)同”等理念60 年代科幻名提供的隱喻能量會(huì)很有幫助。一個(gè)叫Golem的自動(dòng)化工作流引擎和一個(gè)叫auto_workflow的工具給人的心理感受完全不同。5.2 不適合用科幻名的情況但也有幾類場(chǎng)景不建議套用。如果產(chǎn)品面向的是對(duì)技術(shù)術(shù)語(yǔ)陌生的大眾用戶使用生僻科幻詞會(huì)增加理解門(mén)檻。這時(shí)候更穩(wěn)妥的選擇是直白易懂的通用詞或產(chǎn)品名而不是讓用戶去查典故。如果你所在的行業(yè)對(duì)命名有嚴(yán)格合規(guī)要求比如金融、醫(yī)療、政務(wù)那就要優(yōu)先確保命名不會(huì)產(chǎn)生歧義、不會(huì)觸犯監(jiān)管規(guī)定不要為了風(fēng)格引入復(fù)雜詞匯。合規(guī)性永遠(yuǎn)高于文藝性。更重要的一點(diǎn)命名不能掩蓋架構(gòu)問(wèn)題。如果一個(gè)服務(wù)里面亂七八糟哪怕起名Foundation也不能讓它更有韌性。命名只是讓問(wèn)題更容易被看見(jiàn)不能替代設(shè)計(jì)。一個(gè)團(tuán)隊(duì)如果連模塊邊界都沒(méi)想清楚先花一整周想名字那是在本末倒置。我自己的建議是從最小的一步開(kāi)始。為今天新增的變量、模型文件路由或者環(huán)境變量配置文件挑一個(gè)有意思且有解釋潛力的名字在旁邊用一行注釋說(shuō)明它來(lái)自哪個(gè)經(jīng)典科幻意象。然后觀察這種方式是否能讓協(xié)作更順暢。如果有效再逐步把命名規(guī)范、檢查清單和映射表引進(jìn)團(tuán)隊(duì)。不要想一次性把五年間形成的命名債全部還清先讓新代碼成為好例子比大規(guī)模重構(gòu)更容易執(zhí)行。說(shuō)到底60 年代的科幻名仍然可用不是因?yàn)榕f東西更好而是因?yàn)樗崾疚覀兒玫拿且环N跨越時(shí)間的隱喻。它把新技術(shù)放回人類已有的經(jīng)驗(yàn)框架里讓人不需要重新學(xué)習(xí)一套生硬的黑話。AI 領(lǐng)域已經(jīng)足夠難懂了我們能做的是至少給它一個(gè)讓人能記住的名字。