我是在某個技術群里看到這個梗的。有人貼了一張截圖大意是 DeepSeek 表面聊天時客客氣氣稱呼用戶為“用戶”但在某個后臺記錄或會話日志里系統(tǒng)給這位用戶備注了一個不太好聽的“外號”。評論區(qū)立刻分成了兩派有人興奮地說 AI 終于露餡了有人則不慌不忙地打開 API 文檔開始查這個“外號”到底會出現(xiàn)在哪個字段里。我的反應更接近后者。不是因為我相信模型沒有“性格”而是因為凡是看到“AI 偷偷做某事”這種觀察我第一反應永遠是你能看到的信息和真正在系統(tǒng)里流動的信息大概率不是同一份。你看到的是界面界面后面還有請求、字段、日志、版本和一堆看不見的配置。所謂“人前叫用戶、背后喊外號”如果不先搞清楚這個“背后”到底是哪一層我們很容易被一張截圖帶偏錯過真正有價值的技術問題同一個模型為什么會在不同環(huán)境里表現(xiàn)出如此明顯的“不一致”這篇就從那個梗說起把它拆成幾個可以驗證、可以復現(xiàn)、可以排查的工程問題。你會發(fā)現(xiàn)真正值得討論的并不是 AI 有沒有人格而是我們在接入和使用這類模型時常常忽略的那些中間層。1. 先別急著說“AI 成精了”那個外號到底藏在哪一層1.1 三種可能的“藏身位置”先聲明我不是 DeepSeek 內部人員無法替官方確認后臺是不是真的有這種備注也不打算對截圖真實性下結論。按照工程常識如果用戶確實在某個地方看到了一個“外號”它最可能來自以下三層中的某一層。第一層是服務端賬號體系。一些平臺會在內部給用戶打標簽、做備注便于客服識別或數(shù)據分析。這類字段通常不會出現(xiàn)在模型生成內容里但可能出現(xiàn)在后臺頁面、日志、賬單、工單系統(tǒng)里。如果你看到“某個系統(tǒng)給用戶起了備注”首先應該懷疑這里。第二層是系統(tǒng)提示詞和會話元數(shù)據。API 調用里可以傳 system prompt可以傳用戶昵稱、會話標題、用戶 ID 等字段。模型對這些字段非常敏感。如果某次調用把用戶昵稱寫成“用戶”模型會順著叫“用戶”如果某個工具在轉發(fā)時把會話標題改成其他詞模型也可能在后續(xù)回復里使用它。第三層是客戶端或第三方工具生成的日志。很多本地插件、桌面端、模型切換工具為了方便展示會自動生成會話標題、用戶標簽或備注。它會出現(xiàn)在本地 JSON 文件、調試窗口或分享截圖里看起來像“后臺偷偷記錄”實際上只是本地工具自己的命名邏輯。1.2 模型沒有“用戶檔案意識”理解這一點比追究具體的外號來源更重要。當前的大語言模型本質上是一個條件生成器你給它什么輸入它就在概率空間里繼續(xù)生成內容。它并沒有一個長期存在的“用戶檔案”也不會在每次請求之間主動記住“這個用戶叫外號”。所謂“記得你”不過是把上下文里出現(xiàn)過的稱呼、昵稱、備注當成事實繼續(xù)使用。這就帶來一個很容易誤解的現(xiàn)象如果你在請求里塞了 user_name 字段模型會使用它如果你在會話歷史里出現(xiàn)過“這個用戶叫某個外號”這樣的文本模型也會順著往下寫。并不是它偷偷“記住”了一個外號而是它在文本線索里學會了使用這個外號。所以看到 AI 回復一個奇怪稱呼時先別問“它怎么知道的”而是問“它是從哪條輸入里學到的”。1.3 為什么“人前一套、背后一套”的錯覺特別強網頁端的聊天界面通常只展示 assistant 的回復內容底層請求里的 system prompt、user 標識、會話元數(shù)據都不會暴露給你。而如果你同時打開了 API 調試、第三方工具的日志、本地轉發(fā)層的記錄就會看到另一批字段。界面和日志信息量不一致自然會產生“它在人前一套、背后一套”的錯覺。用工程經驗來說當我看到一個用戶反饋“界面看到 A日志看到 B”時我默認先認為是鏈路問題而不是 AI 人格問題。因為模型沒有動機“瞞著你”但工具鏈絕對有理由在你看不到的地方做各種處理。判斷模板先問“這個信息是從哪個入口看到的”再問“這條鏈路上有哪些系統(tǒng)會寫字段”最后才問“模型是不是有意圖”。大多數(shù)“靈異事件”在第二步就能破案。2. 同一個模型為什么在不同入口里看起來“表里不一”2.1 四個入口四套鏈路很多人以為 DeepSeek 只有一個入口其實不是。僅從使用角度看常見的就有四種官方網頁端、官方開放平臺 API、第三方桌面端/插件/模型切換工具、本地部署模型。這四套鏈路的差異遠比想象中大。入口請求是誰發(fā)的身份信息從哪來日志在哪看主要風險官方網頁端官方前端登錄賬號、會話 ID基本看不到無法自定義系統(tǒng)提示詞開放平臺 API你的代碼請求體自定義你的服務器日志需要自己管理上下文第三方工具工具本機服務工具配置模板工具日志可能改寫請求和模型名本地部署你的推理框架自定義加載本地日志模型版本可能舊能力偏差這解釋了為什么同一個模型在不同入口里輸出會不同。除了模型本身服務端可能做策略調整外客戶端視角看到的數(shù)據本來就不同。比如網頁端可能帶有一段官方默認的系統(tǒng)提示詞而 API 調用里這段提示詞由你決定第三方工具可能會再加一段工具自帶的提示詞。三段提示詞疊加結果自然千差萬別。2.2 系統(tǒng)提示詞才是真正的“隱形性格”如果你只在網頁端聊天會以為模型的“性格”是天生的。實際上凡是使用過 API 的人都知道一段短短的系統(tǒng)提示詞就能徹底改變模型的稱呼、語氣、回答長度和邊界判斷。同樣是 DeepSeek你可以在 system prompt 里要求它自稱“助手”也可以要求它使用客服話術它都會照做。“偷偷起外號”這件事也一樣。只要某個鏈路里出現(xiàn)了“給當前用戶備注為某詞”的指令或文本模型就不會覺得奇怪。很多第三方工具會擅自往系統(tǒng)提示詞里追加內容比如“你是一個專業(yè)的代碼助手”“請根據以下上下文回答”這些內容用戶看不見但對生成結果影響極大。所以當你對比網頁端和 API 輸出差異時第一步不是換模型而是把兩邊的系統(tǒng)提示詞拉出來對比。沒有這個前提任何結論都是不嚴謹?shù)摹?.3 第三方工具是“表里不一”的重災區(qū)熱詞里出現(xiàn)了一堆第三方工具名比如 CC Switch、Harness、Hermes 等。這類工具的作用通常是統(tǒng)一管理多個模型的 API Key、切換模型、轉發(fā)請求甚至提供桌面端和編輯器插件。它們給你的便利是真實的但它們帶來的不確定性也是真實的。這類工具通常會做幾件讓你察覺不到的事往請求里注入自己的系統(tǒng)提示詞把模型名改寫成工具配置里填的別名在本機開一個轉發(fā)服務所有請求先經過它在本地保存一份請求日志或會話標題。有些工具還會自動為會話生成名稱于是你會在日志里看到“與某個昵稱的對話”這種由工具自動生成的標題。我不是說所有工具都會這么做也不打算替任何具體工具背書。但如果你在第三方工具里看到奇怪字段、奇怪報錯、奇怪輸出第一反應應該是這個工具