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