質(zhì)性內(nèi)容為何不可靠：從幻覺到工程驗(yàn)證實(shí)踐)
請你換個(gè)頭像吧這個(gè)頭像看著像機(jī)器人。不對換個(gè)話題。標(biāo)題值得先說清楚You Should Almost Never Use AI to Write Anything Substantive這句話不是說“AI 無用論”也不是勸大家放棄 ChatGPT、Cursor、Copilot 這些工具。它真正想提醒的是AI 可以幫你把空白頁填滿但不應(yīng)該替你做決定、背書事實(shí)、承擔(dān)后果。如果你是一個(gè)寫過技術(shù)方案、提交過 PR、維護(hù)過文檔庫的工程師大概率經(jīng)歷過這樣的場景讓 AI 生成一段技術(shù)方案讀起來?xiàng)l理清晰、語氣專業(yè)幾乎可以直接發(fā)布。但當(dāng)你準(zhǔn)備引用里面的某個(gè) API 時(shí)打開官方文檔卻發(fā)現(xiàn)這個(gè) API 根本不存在或者你用 AI 生成的代碼在測試環(huán)境跑得好好的到了生產(chǎn)環(huán)境因?yàn)橐粋€(gè)隱蔽的邊界條件出了事故。這類問題的根源不是“AI 太笨”而是“AI 的生成機(jī)制和實(shí)質(zhì)性內(nèi)容的要求之間存在結(jié)構(gòu)性矛盾”。這篇文章會先分析這個(gè)矛盾到底是什么然后給出一個(gè)可落地的判斷框架最后分享一套能讓 AI 進(jìn)入工作流、但不成為責(zé)任主體的工程實(shí)踐。讀完你會得到兩樣?xùn)|西第一一套判斷“什么內(nèi)容可以交給 AI、什么內(nèi)容必須人工主導(dǎo)”的標(biāo)準(zhǔn)第二一個(gè)可以直接復(fù)制使用的 AI 內(nèi)容風(fēng)險(xiǎn)掃描腳本和 CI 集成方式。1. “實(shí)質(zhì)性內(nèi)容”到底指什么1.1 四類典型特征很多人聽到“substantive”就理解為“長的內(nèi)容”或者“重要內(nèi)容”其實(shí)不準(zhǔn)確。一篇文章 5000 字但全是正確的廢話也算不上實(shí)質(zhì)性內(nèi)容。真正意義上的實(shí)質(zhì)性內(nèi)容一般同時(shí)具備下面四個(gè)特征。第一個(gè)特征是有事實(shí)邊界。技術(shù)文檔、API 參考、配置說明、基線報(bào)告這些內(nèi)容里寫的每一個(gè)名詞、每一個(gè)命令、每一個(gè)數(shù)字都對應(yīng)現(xiàn)實(shí)世界里的某個(gè)對象。如果你寫錯了讀者按你的文檔操作就會失敗或者更糟糕以為走通了實(shí)際沒走通。第二個(gè)特征是有責(zé)任歸屬。PR 描述、架構(gòu)決策記錄、發(fā)布說明、安全公告這些內(nèi)容發(fā)布之后是要有人為它負(fù)責(zé)的。上線后出現(xiàn)問題第一件事是回溯當(dāng)時(shí)寫了什么、為什么這么寫。如果這段內(nèi)容是 AI 生成的而人只是簡單復(fù)制粘貼回溯鏈條就斷了。第三個(gè)特征是有長程一致性。復(fù)雜系統(tǒng)的設(shè)計(jì)文檔往往橫跨十幾個(gè)模塊前面約定了一個(gè)名詞后面必須繼續(xù)沿用前面確定了方案 A后面就不能再出現(xiàn)方案 B 的結(jié)論。AI 生成的文本在局部看是流暢的但跨區(qū)間的一致性很難保證。第四個(gè)特征是有驗(yàn)證要求。實(shí)質(zhì)性內(nèi)容必須能被測試、被編譯、被審查、被查證。寫代碼有編譯器兜底寫配置有程序校驗(yàn)寫技術(shù)方案則要靠人的推理和實(shí)驗(yàn)驗(yàn)證。能驗(yàn)證的內(nèi)容才談得上質(zhì)量不能驗(yàn)證的內(nèi)容只是“看起來像內(nèi)容”。1.2 判斷標(biāo)準(zhǔn)錯誤是否能被低成本發(fā)現(xiàn)如果覺得四個(gè)特征不好記可以壓縮成一個(gè)更實(shí)用的標(biāo)準(zhǔn)判斷內(nèi)容是否實(shí)質(zhì)性的關(guān)鍵不是它有多長、多重要而是錯誤被發(fā)現(xiàn)的成本有多高。一封語氣寫錯的郵件對方回復(fù)前就能發(fā)現(xiàn)代價(jià)很低一個(gè)充滿幻覺的架構(gòu)方案三個(gè)月后系統(tǒng)出問題才發(fā)現(xiàn)代價(jià)極高。同一個(gè) AI 工具生成的代碼如果編譯器能立刻報(bào)錯它其實(shí)是安全的如果它編譯通過但業(yè)務(wù)邏輯是錯的它就是高風(fēng)險(xiǎn)內(nèi)容因?yàn)殄e誤成本被推遲了。這也是為什么“用 AI 寫代碼”比“用 AI 寫技術(shù)論述”更可行。代碼有編譯器、類型系統(tǒng)、單元測試來做驗(yàn)證AI 生成的內(nèi)容會立即被程序檢查而技術(shù)論述沒有“編譯器”它只能靠讀者逐句判斷“這句話對不對”。當(dāng)驗(yàn)證成本高到接近人工重寫時(shí)AI 的優(yōu)勢就被抵消了。2. AI 生成內(nèi)容為什么“看起來對但靠不住”2.1 生成機(jī)制與驗(yàn)證機(jī)制的錯位我們需要先理解大語言模型生成文本的原理。它的核心是“下一個(gè) token 預(yù)測”給定前文計(jì)算下一個(gè)最可能出現(xiàn)的 token 是什么。訓(xùn)練完成之后它會記住大量的語言模式所以生成的句子非常流暢、結(jié)構(gòu)非常合理。問題在于流暢和合理都不等于正確。模型在生成一句話時(shí)不是去數(shù)據(jù)庫里查“這個(gè) API 是否存在”而是計(jì)算“這段話在訓(xùn)練數(shù)據(jù)中是否常見”。如果某個(gè)錯誤說法在互聯(lián)網(wǎng)上反復(fù)出現(xiàn)模型很可能認(rèn)為它是對的如果某個(gè)知識只存在于訓(xùn)練數(shù)據(jù)截止日期之后模型就只能憑模式推斷。這就造成了生成機(jī)制與驗(yàn)證機(jī)制的錯位模型判斷“該怎么說”的能力很強(qiáng)判斷“這么說對不對”的能力很弱。而實(shí)質(zhì)性內(nèi)容最需要的恰恰是后者。2.2 技術(shù)寫作中的三種典型失效第一種是憑空創(chuàng)造事實(shí)。比如讓 AI 寫某個(gè)框架的配置文檔它列出了一個(gè)看起來很合理、但官方根本不存在的參數(shù)。讀者照做跑不起來查文檔又查不到最后只能浪費(fèi)幾小時(shí)。第二種是版本混淆。技術(shù)領(lǐng)域的變化非?？霢I 的訓(xùn)練數(shù)據(jù)有一定的截止時(shí)間。當(dāng)你問一個(gè)“如何配置”的問題時(shí)它可能會把舊版本的配置方式和新版本的命令混在一起生成一份在任何一個(gè)版本下都無法工作的文檔。第三種是上下文錯位。AI 給出的答案在“一般情況”下是對的但不適合你的具體場景。比如你問的是單體項(xiàng)目的性能優(yōu)化它建議引入微服務(wù)因?yàn)樗挠?xùn)練數(shù)據(jù)里充滿了“微服務(wù)是高性能架構(gòu)”的表述。這就是典型的“沒有上下文意識”它在生成一篇關(guān)于性能優(yōu)化的文章而不是在解決你的系統(tǒng)問題。2.3 幻覺真正可怕的地方錯誤分布不可預(yù)測人類寫作者也會犯錯但人的錯誤通常集中在“我不懂的地方”或“我粗心的地方”作者自己心里有數(shù)。AI 的錯誤則不同它均勻地分布在整篇內(nèi)容里一段完全正確的文字旁邊可能藏著一個(gè)完全錯誤的結(jié)論而且沒有任何標(biāo)記。這種錯誤分布不可預(yù)測的性質(zhì)才是 AI 內(nèi)容真正難處理的地方。審閱者沒法用“重點(diǎn)檢查某幾段”的策略因?yàn)殄e誤可能出現(xiàn)在任何一個(gè)角落。每一句都要像對待可疑聲明一樣去核實(shí)這等于把 AI 節(jié)省下來的時(shí)間又花回去了。這也是為什么越來越多的人感覺到“用 AI 寫文章騙不了人了”不是說 AI 語言不夠流暢而是讀者一旦帶著質(zhì)疑去核查事實(shí)那些沒有事實(shí)支撐的流暢表述很快會瓦解。3. 可以用 AI 寫什么任務(wù)分級框架3.1 低風(fēng)險(xiǎn)任務(wù)格式化、改寫、結(jié)構(gòu)整理第一類可以放心交給 AI 的任務(wù)是不對事實(shí)負(fù)責(zé)的機(jī)械性任務(wù)。典型包括把筆記整理成結(jié)構(gòu)化提綱、把一段話改寫成更專業(yè)的表達(dá)、把英文技術(shù)文檔翻譯成中文、給變量或函數(shù)重新命名、生成郵件模板。這些任務(wù)的核心困難在“表達(dá)”而表達(dá)恰恰是 AI 最擅長的地方。就算它生成的內(nèi)容不完全符合要求修改成本也很低。這一類任務(wù)可以大膽用 AI效率提升非常明顯。3.2 中風(fēng)險(xiǎn)任務(wù)草稿、測試骨架、探索性方案第二類是可以讓 AI 參與、但必須有人工驗(yàn)證的任務(wù)。典型包括技術(shù)文檔的初稿、測試用例骨架、某個(gè)功能的探索性實(shí)現(xiàn)、頭腦風(fēng)暴階段的方案備選。中風(fēng)險(xiǎn)任務(wù)的特點(diǎn)是AI 能提供一個(gè)看似完整的基礎(chǔ)版本但這個(gè)版本默認(rèn)缺少“真實(shí)環(huán)境的約束”。比如 AI 生成的測試骨架能幫你省去手寫框架的時(shí)間但測試數(shù)據(jù)需要你根據(jù)業(yè)務(wù)修正AI 生成的方案草稿能給你提供思路但結(jié)論需要你用實(shí)驗(yàn)證實(shí)。處理中風(fēng)險(xiǎn)任務(wù)時(shí)比較好的做法是把 AI 的輸出當(dāng)作一個(gè)能力很強(qiáng)的實(shí)習(xí)生初稿而不是可以發(fā)布的終稿。你需要明確列出哪些地方需要檢查然后逐項(xiàng)核驗(yàn)。3.3 高風(fēng)險(xiǎn)任務(wù)架構(gòu)決策、生產(chǎn)配置、對外承諾第三類是幾乎不該用 AI 直接生成終稿的任務(wù)。典型包括核心架構(gòu)決策記錄、生產(chǎn)環(huán)境配置、對外發(fā)布的安全公告、涉及合規(guī)和審計(jì)的文檔、以及任何“寫了就要負(fù)責(zé)任”的內(nèi)容。為什么這些任務(wù)不該交給 AI不是因?yàn)?AI 一定會出錯而是因?yàn)殄e誤的代價(jià)遠(yuǎn)大于節(jié)省的成本。架構(gòu)決策影響幾個(gè)月甚至幾年的系統(tǒng)演進(jìn)生產(chǎn)配置錯誤可能直接導(dǎo)致線上事故對外承諾一旦失真損害的是信任。高風(fēng)險(xiǎn)任務(wù)的正確用法是把 AI 控制在“咨詢顧問”的位置讓它列出需要考慮的維度、指出你沒想到的風(fēng)險(xiǎn)點(diǎn)、幫你組織思路。最終結(jié)論必須由人來下理由必須由人來寫。3.4 任務(wù)分級速查表風(fēng)險(xiǎn)等級典型場景AI 參與方式人工責(zé)任低風(fēng)險(xiǎn)改寫、翻譯、格式化、命名建議直接生成結(jié)果簡要檢查即可中風(fēng)險(xiǎn)技術(shù)草稿、測試骨架、方案初稿生成初稿 列出待確認(rèn)點(diǎn)逐條核驗(yàn)事實(shí)和上下文高風(fēng)險(xiǎn)架構(gòu)決策、生產(chǎn)配置、對外公告詢問分析角度 組織思路親自得出結(jié)論并撰寫終稿4. 讓 AI 輸出可驗(yàn)證內(nèi)容一個(gè)落地流程4.1 第一步強(qiáng)制“事實(shí)清單”先行很多人在使用 AI 寫作時(shí)直接要求“寫一篇完整的技術(shù)方案”于是拿到一個(gè)所有內(nèi)容混在一起的成品。這其實(shí)是最難審查的形態(tài)。更穩(wěn)妥的方式是先讓 AI 生成一個(gè)“事實(shí)清單”而不是正式文檔。事實(shí)清單是指把內(nèi)容里涉及的所有斷言單獨(dú)列出并標(biāo)記它的來源類型。下面這個(gè)提示詞模板可以直接復(fù)制使用。任務(wù)基于下面的需求草稿先只輸出事實(shí)清單不要寫正式文檔。 要求 1. 每一條事實(shí)標(biāo)記來源類型官方文檔 / 代碼實(shí)現(xiàn) / 經(jīng)驗(yàn)判斷 / 推測 2. 來源為推測的條目必須單獨(dú)列出并給出驗(yàn)證方法 3. 不寫任何結(jié)論性陳述除非它能被事實(shí)清單中的條目直接支撐 4. 如果需求中存在你無法從上下文確定的內(nèi)容輸出待確認(rèn)事項(xiàng) 5. 最后輸出一個(gè)不能直接使用的風(fēng)險(xiǎn)點(diǎn)列表 需求草稿 在此粘貼你的需求描述使用這個(gè)提示詞時(shí)不要直接跳過一定要把需求寫清楚。需求里包含已知的約束、項(xiàng)目背景、涉及的框架和版本AI 才能給出更準(zhǔn)確的清單。如果 AI 輸出的待確認(rèn)事項(xiàng)很多說明當(dāng)前的信息不足以支撐實(shí)質(zhì)性寫作這時(shí)候應(yīng)該先補(bǔ)信息而不是硬寫。4.2 第二步程序化掃描風(fēng)險(xiǎn)信號人工審查永遠(yuǎn)需要但可以先讓程序做一輪初篩。下面這個(gè) Python 腳本可以掃描文檔中的“模糊表述”和“未驗(yàn)證斷言”適合放在本地或 CI 里使用。# 文件路徑scripts/scan_ai_content.py AI 生成內(nèi)容風(fēng)險(xiǎn)掃描器 用于掃描 AI 生成的技術(shù)文檔、PR 描述、方案草稿 找出模糊表述和未經(jīng)驗(yàn)證的強(qiáng)斷言兩類風(fēng)險(xiǎn)信號。 用法: python scripts/scan_ai_content.py docs/ai-draft.md import re import sys from pathlib import Path # 模糊表述出現(xiàn)時(shí)需要核實(shí)是否有具體依據(jù) VAGUE_WORDS [ 可能, 大概率, 通常, 一般來講, 根據(jù)資料, 從文檔看, 應(yīng)該, 似乎, 業(yè)界普遍認(rèn)為 ] # 強(qiáng)斷言出現(xiàn)時(shí)必須能在同一文檔或倉庫內(nèi)找到引用來源 STRONG_CLAIMS [ 最佳實(shí)踐, 官方推薦, 性能大幅提升, 完全兼容, 絕對安全, 沒有副作用, 生產(chǎn)環(huán)境可用 ] def scan_file(path: Path) - int: text path.read_text(encodingutf-8) problems [] for line_no, line in enumerate(text.splitlines(), 1): # 跳過以 # 開頭的注釋行 clean_line line.strip() if clean_line.startswith(#): continue for word in VAGUE_WORDS: if word in clean_line: problems.append((line_no, 模糊表述, word)) for word in STRONG_CLAIMS: if word in clean_line and TODO not in clean_line: problems.append((line_no, 未驗(yàn)證斷言, word)) for line_no, ptype, word in problems: print(f[{ptype}] {path}:{line_no} 出現(xiàn){word}需要補(bǔ)充可驗(yàn)證依據(jù)) return len(problems) def main(): files [Path(p) for p in sys.argv[1:]] total 0 for f in files: if f.exists(): total scan_file(f) else: print(f文件不存在: {f}) print(f\n共發(fā)現(xiàn) {total} 處風(fēng)險(xiǎn)信號) # 有風(fēng)險(xiǎn)信號時(shí)返回非零退出碼方便接入 CI return 1 if total else 0 if __name__ __main__: raise SystemExit(main())這個(gè)腳本不是一個(gè)完美的內(nèi)容質(zhì)檢器但它能幫你建立一個(gè)心理防線當(dāng)文檔中的模糊表述太多時(shí)它提醒你不要直接發(fā)布而是先補(bǔ)充依據(jù)。要注意這個(gè)腳本的作用是“發(fā)現(xiàn)問題”不是“證明沒問題”。即使腳本輸出 0 個(gè)風(fēng)險(xiǎn)信號也不代表文檔是正確的只代表它沒有明顯的模糊表述和強(qiáng)斷言。4.3 第三步逐條人工核驗(yàn)程序化掃描完成之后需要人工做的事是取出事實(shí)清單中的每一條問三個(gè)問題。第一這個(gè)說法在官方文檔里有沒有技術(shù)文檔和配置說明必須以官方文檔為準(zhǔn)。如果 AI 引用的 API、參數(shù)、命令在官方文檔中查不到直接刪掉或標(biāo)為待查。第二這個(gè)說法在你的項(xiàng)目里成立嗎AI 給出的“通用最佳實(shí)踐”不一定適合你的場景。你需要結(jié)合項(xiàng)目的技術(shù)棧、團(tuán)隊(duì)約定、實(shí)際運(yùn)行環(huán)境來判斷。第三如果這個(gè)說法錯了后果是什么如果是“文檔寫錯了用戶會困惑”的程度可以修復(fù)后發(fā)布如果是“按照這個(gè)配置上線會出事故”的程度必須由你重寫而不是修改 AI 的草稿。4.4 第四步保留版本與審查記錄最后一步是工程上最容易被忽略的給 AI 生成的內(nèi)容留下版本和審查記錄。具體做法是在文檔庫或代碼倉庫中要求所有包含 AI 生成內(nèi)容的文件在文件頭部添加一段元信息--- title: 支付模塊架構(gòu)方案 authors: [張三(審核), Cursor(初稿)] created: 2025-01-15 review_status: reviewed verification: | - 并發(fā)設(shè)計(jì)已核對官方文檔版本 2.3.1 - 數(shù)據(jù)庫選型結(jié)論由架構(gòu)組評審確認(rèn) - 風(fēng)險(xiǎn)點(diǎn)一已與運(yùn)維團(tuán)隊(duì)確認(rèn) --- !-- 正文內(nèi)容 --這樣做的價(jià)值在于當(dāng)這個(gè)文檔被質(zhì)疑時(shí)你能立刻知道 AI 在哪個(gè)部分參與了寫作、誰負(fù)責(zé)核驗(yàn)了事實(shí)。沒有這份記錄出了問題就是“文檔不知道誰寫的、不知道誰審的”這對工程團(tuán)隊(duì)是致命的。5. 工程團(tuán)隊(duì)如何建立 AI 內(nèi)容驗(yàn)收機(jī)制5.1 把 AI 輸出當(dāng)成外部依賴很多團(tuán)隊(duì)對 AI 生成內(nèi)容的處理方式是“用了就用了反正生成者是人還是 AI 又沒人知道”。這種做法的問題在于它繞過了工程團(tuán)隊(duì)對質(zhì)量的正常預(yù)期。更合理的做法是把 AI 輸出當(dāng)成一個(gè)外部依賴來管理就像你引入一個(gè)第三方開源庫一樣。你會直接相信一個(gè)第三方庫沒有任何 bug 嗎不會。你會查看它的文檔、版本、已知問題然后做集成測試。AI 內(nèi)容同樣需要這個(gè)流程。具體來講團(tuán)隊(duì)可以在代碼倉庫的.github/pull_request_template.md或CONTRIBUTING.md中明確使用 AI 生成的內(nèi)容必須在提交說明中標(biāo)注。所有 AI 生成內(nèi)容必須經(jīng)過與人工內(nèi)容相同的 code review / doc review 流程。高風(fēng)險(xiǎn)文檔必須有明確的責(zé)任人。提交 AI 生成內(nèi)容時(shí)必須附上事實(shí)核對記錄。5.2 在 CI 中加入內(nèi)容質(zhì)量門禁如果團(tuán)隊(duì)使用 GitLab CI 或 GitHub Actions可以把剛才的掃描腳本接入流水線作為文檔變更的質(zhì)量門禁。下面是一個(gè) GitLab CI 的示例。# 文件路徑.gitlab-ci.yml stages: - validate ai-content-check: stage: validate script: - pip install --quiet pyyaml - python scripts/scan_ai_content.py docs/ai-generated/ rules: - changes: - docs/ai-generated/*這段配置的邏輯是當(dāng)docs/ai-generated/目錄下有任何文件變化時(shí)運(yùn)行掃描腳本。如果腳本發(fā)現(xiàn)風(fēng)險(xiǎn)信號CI 任務(wù)返回非零退出碼流水線失敗禁止合并。這套機(jī)制的價(jià)值在于把“審查 AI 內(nèi)容”從個(gè)人自覺變成團(tuán)隊(duì)制度。5.3 責(zé)任矩陣在團(tuán)隊(duì)協(xié)作中建議明確一個(gè)簡單的內(nèi)容責(zé)任矩陣內(nèi)容類型生成方式審核角色最終責(zé)任人技術(shù)方案初稿AI 起草 人工修改技術(shù)負(fù)責(zé)人技術(shù)負(fù)責(zé)人配置文檔AI 生成 人工核對版本運(yùn)維或相關(guān) owner文檔 owner架構(gòu)決策記錄人工撰寫AI 可提供分析素材架構(gòu)組架構(gòu)師對外技術(shù)公告人工撰寫AI 可潤色技術(shù)負(fù)責(zé)人 法務(wù)/公關(guān)CTO 或指定負(fù)責(zé)人責(zé)任矩陣的核心原則是AI 可以出現(xiàn)在“生成方式”里但不能出現(xiàn)在“最終責(zé)任人”里。凡是重要內(nèi)容最后署名和責(zé)任的一定是一個(gè)具體的人。5.4 反幻覺護(hù)欄術(shù)語表、版本表、上下文包AI 生成內(nèi)容的很多錯誤源于它缺少你項(xiàng)目的上下文。一個(gè)很有效的改進(jìn)方式是給 AI 提供“上下文包”。上下文包可以包含三樣?xùn)|西。第一是術(shù)語表。把項(xiàng)目里使用的專有名詞、縮寫、命名規(guī)范列出來告訴 AI 必須使用這些術(shù)語不得自創(chuàng)。第二是版本表。列出當(dāng)前項(xiàng)目依賴的框架版本、數(shù)據(jù)庫版本、運(yùn)行時(shí)版本并注明“生成的命令和配置必須與這個(gè)版本匹配”。第三是已知約束。把團(tuán)隊(duì)已經(jīng)做出的技術(shù)決策、踩過的坑、不允許使用的方案寫清楚防止 AI 無意識推翻之前的決定。在實(shí)際操作中可以把這三樣內(nèi)容放在一個(gè)固定的文件夾下比如docs/context/在每次讓 AI 生成重要內(nèi)容時(shí)把相關(guān)文件內(nèi)容粘貼進(jìn)對話。這個(gè)過程本身也能幫助團(tuán)隊(duì)積累知識。6. 最常見的認(rèn)知誤區(qū)6.1 誤區(qū)一Review 過就等于安全不少開發(fā)者的真實(shí)狀態(tài)是讓 AI 生成了代碼或文檔自己快速翻一遍感覺“沒什么問題”就提交了。這是典型的確認(rèn)偏誤——你默認(rèn) AI 的產(chǎn)出是對的所以你的審查變成了“找反例”而不是“逐項(xiàng)驗(yàn)證”。更可靠的做法是之前提到的“事實(shí)清單先行”。先把文檔拆成獨(dú)立的斷言逐個(gè)驗(yàn)證再組合成整體。如果跳過事實(shí)清單直接 review 成品很容易被流暢的表達(dá)帶著走。6.2 誤區(qū)二更強(qiáng)的模型、更長的提示詞能根治幻覺很多人認(rèn)為換用更強(qiáng)的模型或者在提示詞里加上“不要編造事實(shí)”就能解決幻覺問題。從工程實(shí)踐看這只能降低幻覺出現(xiàn)的頻率不能消除它。原因是幻覺來自模型的知識來源機(jī)制它不是在查證而是在做條件概率計(jì)算。提示詞可以約束輸出的“形式”很難約束輸出的“事實(shí)正確性”。尤其是當(dāng)提問本身包含錯誤預(yù)設(shè)時(shí)再強(qiáng)的模型也會順著錯誤預(yù)設(shè)生成完整答案。6.3 誤區(qū)三代碼能編譯通過說明 AI 寫代碼沒問題編譯通過只能證明語法和類型正確不能證明邏輯正確。AI 生成的代碼經(jīng)常在“能跑”和“能正確完成業(yè)務(wù)功能”之間存在差距例如邊界條件考慮不周、并發(fā)場景處理錯誤、隱藏的副作用等。代碼類內(nèi)容也不能完全跳過人工審查只是它的驗(yàn)證工具比文檔更友好。正確的做法是代碼要過單測、走 code review文檔要過事實(shí)清單、走 doc review。6.4 誤區(qū)速查表常見誤區(qū)真實(shí)情況改善方式“Review 過就等于安全”默認(rèn) AI 正確會降低審查質(zhì)量先拆事實(shí)清單逐條驗(yàn)證“加提示詞就不會幻覺”只能降低頻率不能根除用外部工具和人工核驗(yàn)兜底“編譯通過就沒問題”只能證明語法正確寫單測、做邏輯走查“AI 生成的內(nèi)容不屬于任何人”發(fā)布后出了事團(tuán)隊(duì)要背鍋明確責(zé)任人寫清來源7. 總結(jié)應(yīng)該怎么做把前面所有內(nèi)容壓縮成一句話就是AI 是高效的草稿生成器但任何實(shí)質(zhì)性內(nèi)容的驗(yàn)證和決策都必須由人來完成。這不是保守而是工程上的必然選擇。AI 的價(jià)值不在于替代人的判斷而在于把人的精力從“生成”中解放出來投入到“驗(yàn)證”中。你可以用 AI 生成提綱、草稿、候選方案但最終發(fā)布的內(nèi)容必須含有你的判斷、你的經(jīng)驗(yàn)、你對真實(shí)環(huán)境的理解。對不同角色的建議是如果你是開發(fā)者最值得練習(xí)的技能是“向 AI 提問之前先把約束條件說清楚”如果你使用 AI 寫代碼請把單元測試當(dāng)作結(jié)論的裁判如果你使用 AI 寫文檔請至少建立一份事實(shí)清單。如果你是技術(shù)負(fù)責(zé)人建議盡快在團(tuán)隊(duì)規(guī)則中明確 AI 內(nèi)容的使用邊界和責(zé)任矩陣并讓 CI 或類似的自動化工具幫助你執(zhí)行。否則 AI 使用量越大潛在的技術(shù)債就越隱蔽。如果你正在負(fù)責(zé)技術(shù)內(nèi)容或開發(fā)者關(guān)系A(chǔ)I 可以用于潤色和素材整理但涉及版本號、命令、兼容性說明的部分請務(wù)必以實(shí)測和官方文檔為準(zhǔn)。后續(xù)值得深入學(xué)習(xí)的方向包括RAG檢索增強(qiáng)生成在事實(shí)性增強(qiáng)中的作用和局限、模型評測領(lǐng)域?qū)Α盎糜X”的量化方法、提示工程中的結(jié)構(gòu)化輸出與約束解碼以及在團(tuán)隊(duì)內(nèi)部搭建“AI 內(nèi)容事實(shí)核查流水線”的實(shí)踐。你可以從這些小實(shí)驗(yàn)開始把今天分享的掃描腳本跑在團(tuán)隊(duì)最近一份 AI 生成的文檔上看看會掃出多少風(fēng)險(xiǎn)信號。 AI寫實(shí)質(zhì)性內(nèi)容為何不可靠：從幻覺到工程驗(yàn)證實(shí)踐
請你換個(gè)頭像吧這個(gè)頭像看著像機(jī)器人。不對換個(gè)話題。標(biāo)題值得先說清楚You Should Almost Never Use AI to Write Anything Substantive這句話不是說“AI 無用論”也不是勸大家放棄 ChatGPT、Cursor、Copilot 這些工具。它真正想提醒的是AI 可以幫你把空白頁填滿但不應(yīng)該替你做決定、背書事實(shí)、承擔(dān)后果。如果你是一個(gè)寫過技術(shù)方案、提交過 PR、維護(hù)過文檔庫的工程師大概率經(jīng)歷過這樣的場景讓 AI 生成一段技術(shù)方案讀起來?xiàng)l理清晰、語氣專業(yè)幾乎可以直接發(fā)布。但當(dāng)你準(zhǔn)備引用里面的某個(gè) API 時(shí)打開官方文檔卻發(fā)現(xiàn)這個(gè) API 根本不存在或者你用 AI 生成的代碼在測試環(huán)境跑得好好的到了生產(chǎn)環(huán)境因?yàn)橐粋€(gè)隱蔽的邊界條件出了事故。這類問題的根源不是“AI 太笨”而是“AI 的生成機(jī)制和實(shí)質(zhì)性內(nèi)容的要求之間存在結(jié)構(gòu)性矛盾”。這篇文章會先分析這個(gè)矛盾到底是什么然后給出一個(gè)可落地的判斷框架最后分享一套能讓 AI 進(jìn)入工作流、但不成為責(zé)任主體的工程實(shí)踐。讀完你會得到兩樣?xùn)|西第一一套判斷“什么內(nèi)容可以交給 AI、什么內(nèi)容必須人工主導(dǎo)”的標(biāo)準(zhǔn)第二一個(gè)可以直接復(fù)制使用的 AI 內(nèi)容風(fēng)險(xiǎn)掃描腳本和 CI 集成方式。1. “實(shí)質(zhì)性內(nèi)容”到底指什么1.1 四類典型特征很多人聽到“substantive”就理解為“長的內(nèi)容”或者“重要內(nèi)容”其實(shí)不準(zhǔn)確。一篇文章 5000 字但全是正確的廢話也算不上實(shí)質(zhì)性內(nèi)容。真正意義上的實(shí)質(zhì)性內(nèi)容一般同時(shí)具備下面四個(gè)特征。第一個(gè)特征是有事實(shí)邊界。技術(shù)文檔、API 參考、配置說明、基線報(bào)告這些內(nèi)容里寫的每一個(gè)名詞、每一個(gè)命令、每一個(gè)數(shù)字都對應(yīng)現(xiàn)實(shí)世界里的某個(gè)對象。如果你寫錯了讀者按你的文檔操作就會失敗或者更糟糕以為走通了實(shí)際沒走通。第二個(gè)特征是有責(zé)任歸屬。PR 描述、架構(gòu)決策記錄、發(fā)布說明、安全公告這些內(nèi)容發(fā)布之后是要有人為它負(fù)責(zé)的。上線后出現(xiàn)問題第一件事是回溯當(dāng)時(shí)寫了什么、為什么這么寫。如果這段內(nèi)容是 AI 生成的而人只是簡單復(fù)制粘貼回溯鏈條就斷了。第三個(gè)特征是有長程一致性。復(fù)雜系統(tǒng)的設(shè)計(jì)文檔往往橫跨十幾個(gè)模塊前面約定了一個(gè)名詞后面必須繼續(xù)沿用前面確定了方案 A后面就不能再出現(xiàn)方案 B 的結(jié)論。AI 生成的文本在局部看是流暢的但跨區(qū)間的一致性很難保證。第四個(gè)特征是有驗(yàn)證要求。實(shí)質(zhì)性內(nèi)容必須能被測試、被編譯、被審查、被查證。寫代碼有編譯器兜底寫配置有程序校驗(yàn)寫技術(shù)方案則要靠人的推理和實(shí)驗(yàn)驗(yàn)證。能驗(yàn)證的內(nèi)容才談得上質(zhì)量不能驗(yàn)證的內(nèi)容只是“看起來像內(nèi)容”。1.2 判斷標(biāo)準(zhǔn)錯誤是否能被低成本發(fā)現(xiàn)如果覺得四個(gè)特征不好記可以壓縮成一個(gè)更實(shí)用的標(biāo)準(zhǔn)判斷內(nèi)容是否實(shí)質(zhì)性的關(guān)鍵不是它有多長、多重要而是錯誤被發(fā)現(xiàn)的成本有多高。一封語氣寫錯的郵件對方回復(fù)前就能發(fā)現(xiàn)代價(jià)很低一個(gè)充滿幻覺的架構(gòu)方案三個(gè)月后系統(tǒng)出問題才發(fā)現(xiàn)代價(jià)極高。同一個(gè) AI 工具生成的代碼如果編譯器能立刻報(bào)錯它其實(shí)是安全的如果它編譯通過但業(yè)務(wù)邏輯是錯的它就是高風(fēng)險(xiǎn)內(nèi)容因?yàn)殄e誤成本被推遲了。這也是為什么“用 AI 寫代碼”比“用 AI 寫技術(shù)論述”更可行。代碼有編譯器、類型系統(tǒng)、單元測試來做驗(yàn)證AI 生成的內(nèi)容會立即被程序檢查而技術(shù)論述沒有“編譯器”它只能靠讀者逐句判斷“這句話對不對”。當(dāng)驗(yàn)證成本高到接近人工重寫時(shí)AI 的優(yōu)勢就被抵消了。2. AI 生成內(nèi)容為什么“看起來對但靠不住”2.1 生成機(jī)制與驗(yàn)證機(jī)制的錯位我們需要先理解大語言模型生成文本的原理。它的核心是“下一個(gè) token 預(yù)測”給定前文計(jì)算下一個(gè)最可能出現(xiàn)的 token 是什么。訓(xùn)練完成之后它會記住大量的語言模式所以生成的句子非常流暢、結(jié)構(gòu)非常合理。問題在于流暢和合理都不等于正確。模型在生成一句話時(shí)不是去數(shù)據(jù)庫里查“這個(gè) API 是否存在”而是計(jì)算“這段話在訓(xùn)練數(shù)據(jù)中是否常見”。如果某個(gè)錯誤說法在互聯(lián)網(wǎng)上反復(fù)出現(xiàn)模型很可能認(rèn)為它是對的如果某個(gè)知識只存在于訓(xùn)練數(shù)據(jù)截止日期之后模型就只能憑模式推斷。這就造成了生成機(jī)制與驗(yàn)證機(jī)制的錯位模型判斷“該怎么說”的能力很強(qiáng)判斷“這么說對不對”的能力很弱。而實(shí)質(zhì)性內(nèi)容最需要的恰恰是后者。2.2 技術(shù)寫作中的三種典型失效第一種是憑空創(chuàng)造事實(shí)。比如讓 AI 寫某個(gè)框架的配置文檔它列出了一個(gè)看起來很合理、但官方根本不存在的參數(shù)。讀者照做跑不起來查文檔又查不到最后只能浪費(fèi)幾小時(shí)。第二種是版本混淆。技術(shù)領(lǐng)域的變化非?？霢I 的訓(xùn)練數(shù)據(jù)有一定的截止時(shí)間。當(dāng)你問一個(gè)“如何配置”的問題時(shí)它可能會把舊版本的配置方式和新版本的命令混在一起生成一份在任何一個(gè)版本下都無法工作的文檔。第三種是上下文錯位。AI 給出的答案在“一般情況”下是對的但不適合你的具體場景。比如你問的是單體項(xiàng)目的性能優(yōu)化它建議引入微服務(wù)因?yàn)樗挠?xùn)練數(shù)據(jù)里充滿了“微服務(wù)是高性能架構(gòu)”的表述。這就是典型的“沒有上下文意識”它在生成一篇關(guān)于性能優(yōu)化的文章而不是在解決你的系統(tǒng)問題。2.3 幻覺真正可怕的地方錯誤分布不可預(yù)測人類寫作者也會犯錯但人的錯誤通常集中在“我不懂的地方”或“我粗心的地方”作者自己心里有數(shù)。AI 的錯誤則不同它均勻地分布在整篇內(nèi)容里一段完全正確的文字旁邊可能藏著一個(gè)完全錯誤的結(jié)論而且沒有任何標(biāo)記。這種錯誤分布不可預(yù)測的性質(zhì)才是 AI 內(nèi)容真正難處理的地方。審閱者沒法用“重點(diǎn)檢查某幾段”的策略因?yàn)殄e誤可能出現(xiàn)在任何一個(gè)角落。每一句都要像對待可疑聲明一樣去核實(shí)這等于把 AI 節(jié)省下來的時(shí)間又花回去了。這也是為什么越來越多的人感覺到“用 AI 寫文章騙不了人了”不是說 AI 語言不夠流暢而是讀者一旦帶著質(zhì)疑去核查事實(shí)那些沒有事實(shí)支撐的流暢表述很快會瓦解。3. 可以用 AI 寫什么任務(wù)分級框架3.1 低風(fēng)險(xiǎn)任務(wù)格式化、改寫、結(jié)構(gòu)整理第一類可以放心交給 AI 的任務(wù)是不對事實(shí)負(fù)責(zé)的機(jī)械性任務(wù)。典型包括把筆記整理成結(jié)構(gòu)化提綱、把一段話改寫成更專業(yè)的表達(dá)、把英文技術(shù)文檔翻譯成中文、給變量或函數(shù)重新命名、生成郵件模板。這些任務(wù)的核心困難在“表達(dá)”而表達(dá)恰恰是 AI 最擅長的地方。就算它生成的內(nèi)容不完全符合要求修改成本也很低。這一類任務(wù)可以大膽用 AI效率提升非常明顯。3.2 中風(fēng)險(xiǎn)任務(wù)草稿、測試骨架、探索性方案第二類是可以讓 AI 參與、但必須有人工驗(yàn)證的任務(wù)。典型包括技術(shù)文檔的初稿、測試用例骨架、某個(gè)功能的探索性實(shí)現(xiàn)、頭腦風(fēng)暴階段的方案備選。中風(fēng)險(xiǎn)任務(wù)的特點(diǎn)是AI 能提供一個(gè)看似完整的基礎(chǔ)版本但這個(gè)版本默認(rèn)缺少“真實(shí)環(huán)境的約束”。比如 AI 生成的測試骨架能幫你省去手寫框架的時(shí)間但測試數(shù)據(jù)需要你根據(jù)業(yè)務(wù)修正AI 生成的方案草稿能給你提供思路但結(jié)論需要你用實(shí)驗(yàn)證實(shí)。處理中風(fēng)險(xiǎn)任務(wù)時(shí)比較好的做法是把 AI 的輸出當(dāng)作一個(gè)能力很強(qiáng)的實(shí)習(xí)生初稿而不是可以發(fā)布的終稿。你需要明確列出哪些地方需要檢查然后逐項(xiàng)核驗(yàn)。3.3 高風(fēng)險(xiǎn)任務(wù)架構(gòu)決策、生產(chǎn)配置、對外承諾第三類是幾乎不該用 AI 直接生成終稿的任務(wù)。典型包括核心架構(gòu)決策記錄、生產(chǎn)環(huán)境配置、對外發(fā)布的安全公告、涉及合規(guī)和審計(jì)的文檔、以及任何“寫了就要負(fù)責(zé)任”的內(nèi)容。為什么這些任務(wù)不該交給 AI不是因?yàn)?AI 一定會出錯而是因?yàn)殄e誤的代價(jià)遠(yuǎn)大于節(jié)省的成本。架構(gòu)決策影響幾個(gè)月甚至幾年的系統(tǒng)演進(jìn)生產(chǎn)配置錯誤可能直接導(dǎo)致線上事故對外承諾一旦失真損害的是信任。高風(fēng)險(xiǎn)任務(wù)的正確用法是把 AI 控制在“咨詢顧問”的位置讓它列出需要考慮的維度、指出你沒想到的風(fēng)險(xiǎn)點(diǎn)、幫你組織思路。最終結(jié)論必須由人來下理由必須由人來寫。3.4 任務(wù)分級速查表風(fēng)險(xiǎn)等級典型場景AI 參與方式人工責(zé)任低風(fēng)險(xiǎn)改寫、翻譯、格式化、命名建議直接生成結(jié)果簡要檢查即可中風(fēng)險(xiǎn)技術(shù)草稿、測試骨架、方案初稿生成初稿 列出待確認(rèn)點(diǎn)逐條核驗(yàn)事實(shí)和上下文高風(fēng)險(xiǎn)架構(gòu)決策、生產(chǎn)配置、對外公告詢問分析角度 組織思路親自得出結(jié)論并撰寫終稿4. 讓 AI 輸出可驗(yàn)證內(nèi)容一個(gè)落地流程4.1 第一步強(qiáng)制“事實(shí)清單”先行很多人在使用 AI 寫作時(shí)直接要求“寫一篇完整的技術(shù)方案”于是拿到一個(gè)所有內(nèi)容混在一起的成品。這其實(shí)是最難審查的形態(tài)。更穩(wěn)妥的方式是先讓 AI 生成一個(gè)“事實(shí)清單”而不是正式文檔。事實(shí)清單是指把內(nèi)容里涉及的所有斷言單獨(dú)列出并標(biāo)記它的來源類型。下面這個(gè)提示詞模板可以直接復(fù)制使用。任務(wù)基于下面的需求草稿先只輸出事實(shí)清單不要寫正式文檔。 要求 1. 每一條事實(shí)標(biāo)記來源類型官方文檔 / 代碼實(shí)現(xiàn) / 經(jīng)驗(yàn)判斷 / 推測 2. 來源為推測的條目必須單獨(dú)列出并給出驗(yàn)證方法 3. 不寫任何結(jié)論性陳述除非它能被事實(shí)清單中的條目直接支撐 4. 如果需求中存在你無法從上下文確定的內(nèi)容輸出待確認(rèn)事項(xiàng) 5. 最后輸出一個(gè)不能直接使用的風(fēng)險(xiǎn)點(diǎn)列表 需求草稿 在此粘貼你的需求描述使用這個(gè)提示詞時(shí)不要直接跳過一定要把需求寫清楚。需求里包含已知的約束、項(xiàng)目背景、涉及的框架和版本AI 才能給出更準(zhǔn)確的清單。如果 AI 輸出的待確認(rèn)事項(xiàng)很多說明當(dāng)前的信息不足以支撐實(shí)質(zhì)性寫作這時(shí)候應(yīng)該先補(bǔ)信息而不是硬寫。4.2 第二步程序化掃描風(fēng)險(xiǎn)信號人工審查永遠(yuǎn)需要但可以先讓程序做一輪初篩。下面這個(gè) Python 腳本可以掃描文檔中的“模糊表述”和“未驗(yàn)證斷言”適合放在本地或 CI 里使用。# 文件路徑scripts/scan_ai_content.py AI 生成內(nèi)容風(fēng)險(xiǎn)掃描器 用于掃描 AI 生成的技術(shù)文檔、PR 描述、方案草稿 找出模糊表述和未經(jīng)驗(yàn)證的強(qiáng)斷言兩類風(fēng)險(xiǎn)信號。 用法: python scripts/scan_ai_content.py docs/ai-draft.md import re import sys from pathlib import Path # 模糊表述出現(xiàn)時(shí)需要核實(shí)是否有具體依據(jù) VAGUE_WORDS [ 可能, 大概率, 通常, 一般來講, 根據(jù)資料, 從文檔看, 應(yīng)該, 似乎, 業(yè)界普遍認(rèn)為 ] # 強(qiáng)斷言出現(xiàn)時(shí)必須能在同一文檔或倉庫內(nèi)找到引用來源 STRONG_CLAIMS [ 最佳實(shí)踐, 官方推薦, 性能大幅提升, 完全兼容, 絕對安全, 沒有副作用, 生產(chǎn)環(huán)境可用 ] def scan_file(path: Path) - int: text path.read_text(encodingutf-8) problems [] for line_no, line in enumerate(text.splitlines(), 1): # 跳過以 # 開頭的注釋行 clean_line line.strip() if clean_line.startswith(#): continue for word in VAGUE_WORDS: if word in clean_line: problems.append((line_no, 模糊表述, word)) for word in STRONG_CLAIMS: if word in clean_line and TODO not in clean_line: problems.append((line_no, 未驗(yàn)證斷言, word)) for line_no, ptype, word in problems: print(f[{ptype}] {path}:{line_no} 出現(xiàn){word}需要補(bǔ)充可驗(yàn)證依據(jù)) return len(problems) def main(): files [Path(p) for p in sys.argv[1:]] total 0 for f in files: if f.exists(): total scan_file(f) else: print(f文件不存在: {f}) print(f\n共發(fā)現(xiàn) {total} 處風(fēng)險(xiǎn)信號) # 有風(fēng)險(xiǎn)信號時(shí)返回非零退出碼方便接入 CI return 1 if total else 0 if __name__ __main__: raise SystemExit(main())這個(gè)腳本不是一個(gè)完美的內(nèi)容質(zhì)檢器但它能幫你建立一個(gè)心理防線當(dāng)文檔中的模糊表述太多時(shí)它提醒你不要直接發(fā)布而是先補(bǔ)充依據(jù)。要注意這個(gè)腳本的作用是“發(fā)現(xiàn)問題”不是“證明沒問題”。即使腳本輸出 0 個(gè)風(fēng)險(xiǎn)信號也不代表文檔是正確的只代表它沒有明顯的模糊表述和強(qiáng)斷言。4.3 第三步逐條人工核驗(yàn)程序化掃描完成之后需要人工做的事是取出事實(shí)清單中的每一條問三個(gè)問題。第一這個(gè)說法在官方文檔里有沒有技術(shù)文檔和配置說明必須以官方文檔為準(zhǔn)。如果 AI 引用的 API、參數(shù)、命令在官方文檔中查不到直接刪掉或標(biāo)為待查。第二這個(gè)說法在你的項(xiàng)目里成立嗎AI 給出的“通用最佳實(shí)踐”不一定適合你的場景。你需要結(jié)合項(xiàng)目的技術(shù)棧、團(tuán)隊(duì)約定、實(shí)際運(yùn)行環(huán)境來判斷。第三如果這個(gè)說法錯了后果是什么如果是“文檔寫錯了用戶會困惑”的程度可以修復(fù)后發(fā)布如果是“按照這個(gè)配置上線會出事故”的程度必須由你重寫而不是修改 AI 的草稿。4.4 第四步保留版本與審查記錄最后一步是工程上最容易被忽略的給 AI 生成的內(nèi)容留下版本和審查記錄。具體做法是在文檔庫或代碼倉庫中要求所有包含 AI 生成內(nèi)容的文件在文件頭部添加一段元信息--- title: 支付模塊架構(gòu)方案 authors: [張三(審核), Cursor(初稿)] created: 2025-01-15 review_status: reviewed verification: | - 并發(fā)設(shè)計(jì)已核對官方文檔版本 2.3.1 - 數(shù)據(jù)庫選型結(jié)論由架構(gòu)組評審確認(rèn) - 風(fēng)險(xiǎn)點(diǎn)一已與運(yùn)維團(tuán)隊(duì)確認(rèn) --- !-- 正文內(nèi)容 --這樣做的價(jià)值在于當(dāng)這個(gè)文檔被質(zhì)疑時(shí)你能立刻知道 AI 在哪個(gè)部分參與了寫作、誰負(fù)責(zé)核驗(yàn)了事實(shí)。沒有這份記錄出了問題就是“文檔不知道誰寫的、不知道誰審的”這對工程團(tuán)隊(duì)是致命的。5. 工程團(tuán)隊(duì)如何建立 AI 內(nèi)容驗(yàn)收機(jī)制5.1 把 AI 輸出當(dāng)成外部依賴很多團(tuán)隊(duì)對 AI 生成內(nèi)容的處理方式是“用了就用了反正生成者是人還是 AI 又沒人知道”。這種做法的問題在于它繞過了工程團(tuán)隊(duì)對質(zhì)量的正常預(yù)期。更合理的做法是把 AI 輸出當(dāng)成一個(gè)外部依賴來管理就像你引入一個(gè)第三方開源庫一樣。你會直接相信一個(gè)第三方庫沒有任何 bug 嗎不會。你會查看它的文檔、版本、已知問題然后做集成測試。AI 內(nèi)容同樣需要這個(gè)流程。具體來講團(tuán)隊(duì)可以在代碼倉庫的.github/pull_request_template.md或CONTRIBUTING.md中明確使用 AI 生成的內(nèi)容必須在提交說明中標(biāo)注。所有 AI 生成內(nèi)容必須經(jīng)過與人工內(nèi)容相同的 code review / doc review 流程。高風(fēng)險(xiǎn)文檔必須有明確的責(zé)任人。提交 AI 生成內(nèi)容時(shí)必須附上事實(shí)核對記錄。5.2 在 CI 中加入內(nèi)容質(zhì)量門禁如果團(tuán)隊(duì)使用 GitLab CI 或 GitHub Actions可以把剛才的掃描腳本接入流水線作為文檔變更的質(zhì)量門禁。下面是一個(gè) GitLab CI 的示例。# 文件路徑.gitlab-ci.yml stages: - validate ai-content-check: stage: validate script: - pip install --quiet pyyaml - python scripts/scan_ai_content.py docs/ai-generated/ rules: - changes: - docs/ai-generated/*這段配置的邏輯是當(dāng)docs/ai-generated/目錄下有任何文件變化時(shí)運(yùn)行掃描腳本。如果腳本發(fā)現(xiàn)風(fēng)險(xiǎn)信號CI 任務(wù)返回非零退出碼流水線失敗禁止合并。這套機(jī)制的價(jià)值在于把“審查 AI 內(nèi)容”從個(gè)人自覺變成團(tuán)隊(duì)制度。5.3 責(zé)任矩陣在團(tuán)隊(duì)協(xié)作中建議明確一個(gè)簡單的內(nèi)容責(zé)任矩陣內(nèi)容類型生成方式審核角色最終責(zé)任人技術(shù)方案初稿AI 起草 人工修改技術(shù)負(fù)責(zé)人技術(shù)負(fù)責(zé)人配置文檔AI 生成 人工核對版本運(yùn)維或相關(guān) owner文檔 owner架構(gòu)決策記錄人工撰寫AI 可提供分析素材架構(gòu)組架構(gòu)師對外技術(shù)公告人工撰寫AI 可潤色技術(shù)負(fù)責(zé)人 法務(wù)/公關(guān)CTO 或指定負(fù)責(zé)人責(zé)任矩陣的核心原則是AI 可以出現(xiàn)在“生成方式”里但不能出現(xiàn)在“最終責(zé)任人”里。凡是重要內(nèi)容最后署名和責(zé)任的一定是一個(gè)具體的人。5.4 反幻覺護(hù)欄術(shù)語表、版本表、上下文包AI 生成內(nèi)容的很多錯誤源于它缺少你項(xiàng)目的上下文。一個(gè)很有效的改進(jìn)方式是給 AI 提供“上下文包”。上下文包可以包含三樣?xùn)|西。第一是術(shù)語表。把項(xiàng)目里使用的專有名詞、縮寫、命名規(guī)范列出來告訴 AI 必須使用這些術(shù)語不得自創(chuàng)。第二是版本表。列出當(dāng)前項(xiàng)目依賴的框架版本、數(shù)據(jù)庫版本、運(yùn)行時(shí)版本并注明“生成的命令和配置必須與這個(gè)版本匹配”。第三是已知約束。把團(tuán)隊(duì)已經(jīng)做出的技術(shù)決策、踩過的坑、不允許使用的方案寫清楚防止 AI 無意識推翻之前的決定。在實(shí)際操作中可以把這三樣內(nèi)容放在一個(gè)固定的文件夾下比如docs/context/在每次讓 AI 生成重要內(nèi)容時(shí)把相關(guān)文件內(nèi)容粘貼進(jìn)對話。這個(gè)過程本身也能幫助團(tuán)隊(duì)積累知識。6. 最常見的認(rèn)知誤區(qū)6.1 誤區(qū)一Review 過就等于安全不少開發(fā)者的真實(shí)狀態(tài)是讓 AI 生成了代碼或文檔自己快速翻一遍感覺“沒什么問題”就提交了。這是典型的確認(rèn)偏誤——你默認(rèn) AI 的產(chǎn)出是對的所以你的審查變成了“找反例”而不是“逐項(xiàng)驗(yàn)證”。更可靠的做法是之前提到的“事實(shí)清單先行”。先把文檔拆成獨(dú)立的斷言逐個(gè)驗(yàn)證再組合成整體。如果跳過事實(shí)清單直接 review 成品很容易被流暢的表達(dá)帶著走。6.2 誤區(qū)二更強(qiáng)的模型、更長的提示詞能根治幻覺很多人認(rèn)為換用更強(qiáng)的模型或者在提示詞里加上“不要編造事實(shí)”就能解決幻覺問題。從工程實(shí)踐看這只能降低幻覺出現(xiàn)的頻率不能消除它。原因是幻覺來自模型的知識來源機(jī)制它不是在查證而是在做條件概率計(jì)算。提示詞可以約束輸出的“形式”很難約束輸出的“事實(shí)正確性”。尤其是當(dāng)提問本身包含錯誤預(yù)設(shè)時(shí)再強(qiáng)的模型也會順著錯誤預(yù)設(shè)生成完整答案。6.3 誤區(qū)三代碼能編譯通過說明 AI 寫代碼沒問題編譯通過只能證明語法和類型正確不能證明邏輯正確。AI 生成的代碼經(jīng)常在“能跑”和“能正確完成業(yè)務(wù)功能”之間存在差距例如邊界條件考慮不周、并發(fā)場景處理錯誤、隱藏的副作用等。代碼類內(nèi)容也不能完全跳過人工審查只是它的驗(yàn)證工具比文檔更友好。正確的做法是代碼要過單測、走 code review文檔要過事實(shí)清單、走 doc review。6.4 誤區(qū)速查表常見誤區(qū)真實(shí)情況改善方式“Review 過就等于安全”默認(rèn) AI 正確會降低審查質(zhì)量先拆事實(shí)清單逐條驗(yàn)證“加提示詞就不會幻覺”只能降低頻率不能根除用外部工具和人工核驗(yàn)兜底“編譯通過就沒問題”只能證明語法正確寫單測、做邏輯走查“AI 生成的內(nèi)容不屬于任何人”發(fā)布后出了事團(tuán)隊(duì)要背鍋明確責(zé)任人寫清來源7. 總結(jié)應(yīng)該怎么做把前面所有內(nèi)容壓縮成一句話就是AI 是高效的草稿生成器但任何實(shí)質(zhì)性內(nèi)容的驗(yàn)證和決策都必須由人來完成。這不是保守而是工程上的必然選擇。AI 的價(jià)值不在于替代人的判斷而在于把人的精力從“生成”中解放出來投入到“驗(yàn)證”中。你可以用 AI 生成提綱、草稿、候選方案但最終發(fā)布的內(nèi)容必須含有你的判斷、你的經(jīng)驗(yàn)、你對真實(shí)環(huán)境的理解。對不同角色的建議是如果你是開發(fā)者最值得練習(xí)的技能是“向 AI 提問之前先把約束條件說清楚”如果你使用 AI 寫代碼請把單元測試當(dāng)作結(jié)論的裁判如果你使用 AI 寫文檔請至少建立一份事實(shí)清單。如果你是技術(shù)負(fù)責(zé)人建議盡快在團(tuán)隊(duì)規(guī)則中明確 AI 內(nèi)容的使用邊界和責(zé)任矩陣并讓 CI 或類似的自動化工具幫助你執(zhí)行。否則 AI 使用量越大潛在的技術(shù)債就越隱蔽。如果你正在負(fù)責(zé)技術(shù)內(nèi)容或開發(fā)者關(guān)系A(chǔ)I 可以用于潤色和素材整理但涉及版本號、命令、兼容性說明的部分請務(wù)必以實(shí)測和官方文檔為準(zhǔn)。后續(xù)值得深入學(xué)習(xí)的方向包括RAG檢索增強(qiáng)生成在事實(shí)性增強(qiáng)中的作用和局限、模型評測領(lǐng)域?qū)Α盎糜X”的量化方法、提示工程中的結(jié)構(gòu)化輸出與約束解碼以及在團(tuán)隊(duì)內(nèi)部搭建“AI 內(nèi)容事實(shí)核查流水線”的實(shí)踐。你可以從這些小實(shí)驗(yàn)開始把今天分享的掃描腳本跑在團(tuán)隊(duì)最近一份 AI 生成的文檔上看看會掃出多少風(fēng)險(xiǎn)信號。