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