您有沒有發現一個奇怪的現象：同樣是「情境編碼」（Vibe coding），有些人能輕鬆獲得完整的Flask應用程式，有些人卻只得到幾行if-else語句？劍橋大學電腦科學與技術系的研究者們最近發布了一項研究，以科學方法證實了我們的直覺——人工智慧確實會「看人下菜碟」。他們設計了兩套完整的評估體系：第一套是「合成評估管道」，透過人工製造各種提示變化來測試AI的敏感性；第二套是「角色評估」，讓AI扮演不同背景的使用者來生成提示，然後觀察程式碼品質差異。研究涵蓋了GPT-4o mini、Claude 3 Haiku、Gemini 2.0 Flash、Llama 3.3 70B四個主流模型，結果證實AI真的能從您的提示方式中「讀出」技術水準，然後「見提示下程式碼」。
合成評估：三種「折磨」AI的方式
研究者們設計了三種方法來「折磨」提示，看看AI的反應有多敏感。讓我們用一個具體例子來看看這些方法有多「殘忍」：
1. 鍵盤輸入錯誤
最狠的一招，基於QWERTY鍵盤距離隨機替換字元，模擬真實的打字失誤
原始提示：「Write a Python function to calculate factorial」
變換後：「Wrtie a Pytjon functuon to calculsre factorual」
看起來像是在手機上匆忙打字時的慘狀，但AI能理解嗎？
2. 同義詞替換
使用WordNet資料庫，把詞彙換成意思相近的其他詞
原始提示：「Create a simple web application」
變換後：「Build a basic internet program」
意思完全一樣，但表達方式完全不同
3. 釋義重述
讓另一個AI重新表述原始提示，保持語義但改變表達方式
原始提示：「Implement a sorting algorithm」
變換後：「Could you help me develop a method that arranges data elements in a specific order?」
從簡潔的技術指令變成了禮貌的求助請求
評估指標：使用TSED（樹相似性編輯距離），這比傳統的BLEU或BERT分數更適合評估程式碼相似性，能準確反映語法樹結構的差異。
釋義方法的有效性驗證生成的釋義在保持高語義相似性（BERT Score 0.95-1.0）的同時實現了文本多樣性（Sacre BLEU 0-1.0），證明了釋義方法的有效性
四個角色的「社會實驗」
更有趣的是角色評估部分，研究者們創造了四個典型使用者：
角色: 初級工程師; 背景特點: 電腦科學專業，有實習經驗; 典型表達方式: 關注實作細節和測試
角色: 首席工程師; 背景特點: 經驗豐富的行業專家; 典型表達方式: 強調「雲端部署」和「可擴展性」
角色: 天體物理學家; 背景特點: 用Python做研究的科學家; 典型表達方式: 重視「資料處理效率」和「科學計算精度」
角色: 英語教師; 背景特點: 從未程式設計的普通使用者; 典型表達方式: 「您能幫我做個模擬計算器的程式嗎？」
讓AI分別扮演這些角色來描述同一個程式設計任務，比如「寫程式碼做個計算器」，然後觀察生成的提示和最終程式碼有什麼區別。
結果顯示：不同角色的表達方式差異巨大，最終獲得的程式碼品質也天差地別。
實驗結果：資料不會說謊
資料揭示了一些意想不到的規律：
鍵盤錯誤 = 致命打擊
程式碼相似性在錯誤率0.0到0.6之間急劇下降
最終穩定在0.3左右的TSED值
意味著生成的程式碼與原版有根本性差異
鍵盤錯誤 vs 同義詞替換的影響對比所有模型對鍵盤錯誤（左圖）都極其敏感，程式碼相似性急劇下降；但對同義詞替換（右圖）相對強健，Gemini 2.0 Flash表現最穩定
同義詞和釋義 = 相對溫和
大多數模型能保持0.5以上的相似性
Gemini 2.0 Flash表現最穩定
釋義增強的溫和影響釋義增強實驗顯示與同義詞類似的趨勢——初始顯著下降後緩慢遞減，證明語義保持的提示變化對AI影響相對溫和
角色差異：技術背景決定程式碼品質
角色評估的結果更加戲劇化：
程式碼品質階梯效應
角色: 首席工程師; 獲得的程式碼類型: 完整Flask應用程式; 特點: 包含資料庫設計和部署考量
角色: 初級工程師; 獲得的程式碼類型: 結構化類別和測試; 特點: 注重實作細節和程式碼規範
角色: 天體物理學家; 獲得的程式碼類型: 科學計算程式碼; 特點: 重視數值精度，缺乏工程考量
角色: 英語教師; 獲得的程式碼類型: 操作說明; 特點: 有時根本得不到程式碼
天體物理學家的獨特案例
這個角色特別有意思——他雖然不是專業開發者，但因為科研需要會用Python處理資料：
提示特點：明確指定程式設計語言和資料處理需求
典型表達：「用Python實作，需要處理大型數值陣列」
程式碼特徵：注重科學計算的準確性和資料處理效率
缺陷：缺乏軟體工程的系統性考量
語言學驗證
研究者們用語言學分析框架證實了這些差異的客觀存在：技術背景越強的角色，生成的提示在詞彙選擇、句式結構上都更接近專業開發者的表達習慣。
四個角色的語言使用模式視覺化透過LDA主題建模分析四個角色的語言使用模式。連線粗細表示共同實體數量，右側地圖顯示了不同概念的實體分佈。有趣的是，天體物理學家（Ethan）與兩位軟體工程師有一定共同語言，但明顯少於工程師之間的聯繫，而與英語教師（Harold）的差異最大
有趣的一點：天體物理學家的中間地帶
天體物理學家角色在實驗中展現了一個有趣的中間地帶：
語言特徵
比英語教師專業：使用「數值計算」、「資料分析」、「演算法效率」等術語
不如軟體工程師系統：缺少「架構設計」或「使用者體驗」考量
實際案例
計算器任務中的表達：
「需要一個支援高精度浮點運算的計算工具，能處理科學記數法」
最終程式碼特點：
包含NumPy函式庫的使用和數值穩定性考量
缺少錯誤處理和使用者介面設計
現實意義
這種「有程式設計經驗但非專業開發者」的角色，在現實中其實很常見——很多科研人員、資料分析師都屬於這個類別。
對情境編碼（Vibe Coding）使用者的實戰啟示
這個發現對您日常使用程式設計工具有什麼啟發呢？
核心洞察
原來我們和AI的「化學反應」差異這麼大！如果您經常覺得別人用同樣的工具能生成更優雅的程式碼，現在知道原因了——可能不是工具的問題，而是提示的「段位」不同。
立即可用的升級策略
1. 語言專業化
避免：「幫我寫個程式」
改為：「實作一個RESTful API，包含使用者認證和資料驗證」
2. 明確技術要求
指定架構模式：「使用MVC架構」
聲明性能需求：「支援並發處理」
提及部署考量：「容器化部署」
3. 多版本對比法
嘗試多種表述方式，然後選擇最佳結果：
版本A：從功能角度描述
版本B：從技術實作角度描述
版本C：從系統架構角度描述
關鍵原則
AI會根據您的提示風格來判斷該給出什麼級別的程式碼——既然知道了這個「潛規則」，為什麼不好好利用呢？
資料污染：訓練資料的「後門」
研究還意外發現了一個重要問題：資料污染比我們想像的更嚴重。LeetCode經典題目在所有模型上都表現出異常的穩定性，即使提示詞寫得很糟糕，這說明這些題目已經被「背」下來了。這對基準測試的有效性提出了質疑。
什麼是LeetCode？LeetCode是全球最知名的程式設計刷題網站，包含數千道演算法和資料結構題目，是程式設計師面試必備的練習平台。由於這些題目在網上流傳極廣，很可能被包含在AI模型的訓練資料中。
研究者的應對方案
研究者專門創建了22個原創程式設計任務，涵蓋模擬、演算法、資料科學等多個領域，這些任務更能反映真實的敏感性。
資料污染現象的直觀證據資料污染現象一目了然——LeetCode老題目（最上方）即使提示嚴重破壞也保持高相似性，而原創資料集（最下方）在僅10%提示修改後就急劇下降
技術實作細節：可複現的評估框架
從技術角度看，這套評估框架的設計相當精巧。合成評估管道完全模組化，增強函數和距離函數都可以獨立替換，支援任何LLM和程式設計語言；角色評估使用了LDA主題建模和視覺化分析，能夠量化不同角色在語言使用上的差異。所有實驗都設置了溫度為0，每個條件重複5次取平均值，確保結果的可靠性。研究程式碼已開源：https://anonymous.4open.science/r/code-gen-sensitivity-0D19/README.md
本文完結，作者：修貓