最近在技術(shù)社區(qū)里有一個討論讓我印象很深陶哲軒在菲爾茲獎大師課內(nèi)容被反復(fù)轉(zhuǎn)發(fā)核心觀點(diǎn)是“AI 還沒有學(xué)會頂級數(shù)學(xué)家的思維但普通人卻可以通過訓(xùn)練掌握這種思維”。評論區(qū)里很多同學(xué)在爭論——大模型不是已經(jīng)能解競賽題、寫證明過程、做符號計算了嗎為什么說它還沒學(xué)會數(shù)學(xué)思維普通人又憑什么能學(xué)會作為一個經(jīng)常用大模型做代碼生成、算法驗證和 AI 應(yīng)用開發(fā)的工程師我理解這個問題的角度不太一樣。AI 缺的不是計算能力也不是知識量而是“提問、猜想、構(gòu)造反例、驗證、重構(gòu)”這一整套閉環(huán)。而恰恰是這套閉環(huán)才是數(shù)學(xué)思維的核心。本文我想從技術(shù)角度拆解這件事為什么大模型會在這類任務(wù)上露出短板普通開發(fā)者如何把“驗證閉環(huán)”補(bǔ)進(jìn) AI 應(yīng)用里以及我們?nèi)绾斡靡惶卓蛇\(yùn)行的工程方案讓大模型在做數(shù)學(xué)推理時更接近人類思維。這篇文章適合對 AI 大模型應(yīng)用、AI Agent 開發(fā)、數(shù)學(xué)思維訓(xùn)練感興趣的開發(fā)者閱讀內(nèi)容包含完整代碼示例和項目調(diào)試思路。1. 背景與核心概念A(yù)I 的“會做題”和數(shù)學(xué)家的“會思考”是兩回事1.1 計算能力不等于數(shù)學(xué)思維要理解陶哲軒這段話的深意我們得先區(qū)分兩個概念“會做數(shù)學(xué)題”和“具備數(shù)學(xué)思維”。大模型在數(shù)學(xué)題上的表現(xiàn)本質(zhì)上是一種基于海量語料的條件概率生成。它見過大量數(shù)學(xué)題的解法、證明過程、題目套路所以在面對類似題目時可以生成看起來非常合理的解題步驟。這也是為什么很多人在用 AI 解高等數(shù)學(xué)、線性代數(shù)、競賽題時會覺得“它好聰明”。但“會做題”和“會思考”之間有巨大的鴻溝。題目通常有明確條件和固定答案模型要做的只是從訓(xùn)練數(shù)據(jù)中檢索相似的解題模式并組合輸出。而真正的數(shù)學(xué)思維是在沒有明確提示的情況下主動提出“這個問題可能和哪個領(lǐng)域相關(guān)”“這個猜想是否可能被反例推翻”“這個定義是否還可以再抽象一層”。這種能力不是簡單的模式匹配而是對概念結(jié)構(gòu)的深層理解。實際開發(fā)中我們也能觀察到這個現(xiàn)象。你讓大模型證明一個經(jīng)典結(jié)論比如“n 的三次方減 n 能被 6 整除”它可以很快給出漂亮的因式分解證明。但如果你讓一個大模型獨(dú)立探索一個開放性問題比如“是否存在某個多項式它對前 k 個整數(shù)都給出素數(shù)但之后失效”它很可能會順著經(jīng)驗給出“應(yīng)該存在”的猜測卻很難主動構(gòu)造出那個反例。這就是計算能力與思維能力的差距。1.2 頂級數(shù)學(xué)家的思維到底指什么陶哲軒作為菲爾茲獎得主談到的數(shù)學(xué)思維并不是某種玄學(xué)而是可以拆解成具體能力的組合。我把它歸納為以下幾點(diǎn)。第一是提問能力。數(shù)學(xué)家最重要的工作不是解題而是提出一個好問題。比如“連續(xù)函數(shù)是否一定在某點(diǎn)可導(dǎo)”這個問題本身就比答案重要。第二是類比遷移能力?？吹揭粋€陌生結(jié)構(gòu)時能聯(lián)想到以前見過的結(jié)構(gòu)把新問題映射到舊框架中。第三是構(gòu)造反例的能力。面對一個猜想不是先想著證明它而是先嘗試推翻它。這種“先找反例再找證明”的習(xí)慣在普通人的思維訓(xùn)練中經(jīng)常被忽略。第四是審美判斷。數(shù)學(xué)家會在多個證明方案中選擇更優(yōu)雅、更通用的那一個這種品味來自大量實踐和經(jīng)驗沉淀。這些能力有一個共同點(diǎn)它們都需要與外部世界交互。提出猜想之后要去驗證構(gòu)造反例之后要去檢查證明寫完以后要反復(fù)尋找漏洞。數(shù)學(xué)思維不是一次生成出來的而是在“猜想—驗證—推翻—修正”的循環(huán)中打磨出來的。1.3 普通人為什么反而可以學(xué)會為什么陶哲軒說“普通人卻可以學(xué)會”關(guān)鍵在于數(shù)學(xué)思維不是天賦而是一套可以刻意練習(xí)的思維習(xí)慣。它像編程中的調(diào)試思維一樣不是天生就會而是在反復(fù)報錯、定位、修復(fù)中練出來的。普通人在學(xué)習(xí)數(shù)學(xué)時可以隨時做試驗、舉例子、畫圖、構(gòu)造反例。這種“試錯—反饋—修正”的閉環(huán)是大腦學(xué)習(xí)最自然的路徑。而當(dāng)前的大模型在標(biāo)準(zhǔn)推理模式下缺少這種外部驗證閉環(huán)——它生成一個結(jié)論后往往無法自己判斷這個結(jié)論是否真的成立。它看起來“知道很多”但缺少“驗證自己知道的東西是否正確”的這個環(huán)節(jié)。換句話說普通人的優(yōu)勢在于可以調(diào)用計算器、畫圖工具、符號計算系統(tǒng)甚至紙張和鉛筆來驗證自己的想法。只要愿意花時間去試錯大多數(shù)人都能培養(yǎng)出相當(dāng)不錯的數(shù)學(xué)直覺。而大模型如果只停留在“生成文本”這一步就永遠(yuǎn)停留在“紙上談兵”的階段。2. 拆解大模型在數(shù)學(xué)任務(wù)上的能力邊界2.1 大模型在數(shù)學(xué)任務(wù)中的強(qiáng)項在討論弱點(diǎn)之前先客觀看看大模型在數(shù)學(xué)任務(wù)上的強(qiáng)項。這樣我們才能在工程實踐中合理利用它的能力而不是一味否定。第一大模型擅長檢索與匹配典型題型。它訓(xùn)練語料中包含了大量教材、論文、博客、競賽題解所以對“常見題型”的解題套路非常熟練。例如求極限、求導(dǎo)數(shù)、解微分方程、常見不等式證明等它都能給出規(guī)范的步驟。第二大模型擅長生成候選思路。面對一個陌生問題時它可以快速給出多個方向的猜測這相當(dāng)于一個“思路生成器”。雖然不一定每個思路都對但能提供很有價值的啟發(fā)。第三大模型擅長文本翻譯與形式化描述。它可以把一段自然語言描述的問題轉(zhuǎn)換成數(shù)學(xué)公式也可以把一段符號推導(dǎo)用自然語言解釋出來這種能力對數(shù)學(xué)交流非常有幫助。在我實際使用經(jīng)驗里大模型最好用的地方不是“直接給答案”而是“生成多個候選證明方案”讓人類去篩選。它像一個知識面極廣但缺乏判斷力的助手可以快速產(chǎn)出大量半成品而人類負(fù)責(zé)驗證和篩選。2.2 大模型在數(shù)學(xué)任務(wù)中的薄弱點(diǎn)大模型的薄弱點(diǎn)同樣明顯。首先是幻覺問題。大模型在不確定答案時會生成一段“看起來正確”的內(nèi)容而不是承認(rèn)自己不知道。這在數(shù)學(xué)任務(wù)是致命的因為數(shù)學(xué)對嚴(yán)謹(jǐn)性要求極高。比如讓模型證明一個結(jié)論它可能在中間步驟偷換概念、跳過關(guān)鍵條件甚至編造一個不存在的定理。其次是缺少對反例的敏感度。模型在語料中學(xué)到的是“某個命題經(jīng)常成立”但它很難主動去尋找邊界條件。一個命題可能在前 1000 個整數(shù)上都成立卻在第 1001 個整數(shù)上失效大模型生成的思路往往會忽略這類邊界檢驗。第三是缺少長期規(guī)劃能力。復(fù)雜的數(shù)學(xué)證明往往需要幾十步甚至上百步的邏輯鏈模型在生成長文本時容易遺忘前文假設(shè)導(dǎo)致推導(dǎo)到后面出現(xiàn)自相矛盾。這些問題的根源都在于大模型的訓(xùn)練目標(biāo)——它只學(xué)習(xí)“下一個詞是什么”卻沒有學(xué)習(xí)“這句話在數(shù)學(xué)上是否成立”。就像一個人背了整本數(shù)學(xué)書卻從沒動手做過一道需要檢驗的題目。2.3 從陶哲軒的公開討論中看 AI 與數(shù)學(xué)研究陶哲軒在公開場合多次表達(dá)過對 AI 工具的興趣。他的態(tài)度并不是全盤否定 AI而是認(rèn)為 AI 需要與人類數(shù)學(xué)家形成互補(bǔ)。他更看重的場景是AI 幫助數(shù)學(xué)家快速處理計算、窮舉搜索反例、驗證復(fù)雜推導(dǎo)而人類數(shù)學(xué)家負(fù)責(zé)提出有意義的問題、選擇研究方向、判斷哪些結(jié)果真正重要。這個觀點(diǎn)對普通開發(fā)者非常有啟發(fā)。我們使用大模型的時候也應(yīng)該是“讓 AI 負(fù)責(zé)生成和計算讓人類負(fù)責(zé)提問和驗證”的分工模式。尤其在 AI Agent 和 AI 應(yīng)用開發(fā)中不能把大模型的輸出當(dāng)作最終答案而要把“驗證模塊”嵌入整個系統(tǒng)流程。這也是本文后面實戰(zhàn)項目要解決的問題。3. 環(huán)境準(zhǔn)備與工具版本3.1 運(yùn)行環(huán)境與版本說明在開始寫代碼之前先明確環(huán)境準(zhǔn)備。本文的實戰(zhàn)項目使用 Python 編寫核心依賴是requests和sympy。大模型部分采用 OpenAI 兼容接口也可以替換為本地部署的模型服務(wù)。版本號不需要與我的環(huán)境完全一致只要滿足基本功能即可重點(diǎn)在于掌握整體思路。本文示例環(huán)境的參考版本如下工具/依賴版本說明Python3.9 及以上requests2.31.0 及以上sympy1.12 及以上大模型接口任意 OpenAI 兼容的/chat/completions接口操作系統(tǒng)Windows / macOS / Linux 均可如果你本地不方便調(diào)用遠(yuǎn)程大模型接口也可以使用 Ollama 部署本地模型然后把base_url指向本地服務(wù)。本文的代碼封裝了對base_url的可配置支持切換成本很低。需要注意的是不同大模型對數(shù)學(xué)推理的支持差異很大。在實際項目里建議選擇數(shù)學(xué)能力較強(qiáng)的模型并在正式使用前用固定的測試集做效果對比。本文示例以“思路生成 程序驗證”為核心即便模型能力一般也能通過驗證模塊兜底。3.2 安裝依賴創(chuàng)建項目目錄后先安裝依賴。建議使用虛擬環(huán)境。mkdir math-thinking-ai cd math-thinking-ai python3 -m venv venv source venv/bin/activate # Windows 系統(tǒng)使用 venv\Scripts\activate pip install requests sympy安裝完成后創(chuàng)建一個config.py文件用來管理大模型接口配置。為了安全和靈活性敏感配置建議通過環(huán)境變量注入而不是寫死在代碼里。# config.py import os # 使用 OpenAI 兼容接口 MODEL_NAME os.getenv(MODEL_NAME, qwen2.5-math) # 按實際模型名修改 BASE_URL os.getenv(BASE_URL, http://localhost:11434/v1) # 本地 Ollama 示例 API_KEY os.getenv(API_KEY, ollama) # 本地服務(wù)通常不需要真實密鑰如果你使用云廠商的 OpenAI 兼容服務(wù)把BASE_URL改為服務(wù)商提供的地址再把API_KEY改成自己的密鑰。環(huán)境變量可以寫到項目根目錄的.env文件中但注意不要把真實密鑰提交到代碼倉庫。3.3 項目目錄結(jié)構(gòu)整個項目采用如下結(jié)構(gòu)math-thinking-ai/ ├── config.py # 配置文件 ├── llm_client.py # 大模型調(diào)用封裝 ├── verifier.py # 數(shù)學(xué)命題驗證器 ├── pipeline.py # 主流程生成思路 - 驗證 - 反思 └── requirements.txt # 依賴清單這樣的結(jié)構(gòu)把配置、模型調(diào)用、驗證邏輯和主流程分開方便后續(xù)擴(kuò)展。比如你想增加新的數(shù)學(xué)命題只需要在verifier.py中新增驗證函數(shù)想更換模型只需修改config.py。4. 核心原理把“驗證”補(bǔ)進(jìn) AI 的推理閉環(huán)4.1 為什么單獨(dú)的生成式推理不可靠大模型的標(biāo)準(zhǔn)使用方式是“輸入 Prompt輸出答案”。這種方式在寫作、翻譯、代碼生成等場景下表現(xiàn)不錯但在數(shù)學(xué)推理中有一個嚴(yán)重問題沒有反饋信號。人類數(shù)學(xué)家在做證明時每推進(jìn)一步都會自我檢查這個條件用到了嗎這個推導(dǎo)是否有反例中間步驟是否跳過了必要限制這種自我檢查不需要外部系統(tǒng)也能部分完成。但大模型在訓(xùn)練時沒有經(jīng)過這種自我驗證的強(qiáng)化它只會順著概率生成下去即使生成到某一步已經(jīng)錯了也可能繼續(xù)沿著錯誤方向推進(jìn)。要讓大模型在數(shù)學(xué)任務(wù)上表現(xiàn)得更可靠不能只靠換一個更大的模型而要在系統(tǒng)設(shè)計上增加外部驗證器。把“模型輸出”從終點(diǎn)變成中間產(chǎn)物讓驗證器去檢查、糾錯再把錯誤信息反饋給模型進(jìn)行二次生成。這就是 AI Agent 開發(fā)中常見的“生成—評估—反思”循環(huán)。4.2 一個可靠的閉環(huán)設(shè)計我們設(shè)計的數(shù)學(xué)猜想驗證工具采用以下閉環(huán)流程用戶輸入一個數(shù)學(xué)命題例如“對所有正整數(shù) nn^2n41 都是素數(shù)”。大模型生成一組解題思路或證明方向。程序調(diào)用驗證器對命題進(jìn)行窮舉、符號推演或反例搜索。如果驗證器發(fā)現(xiàn)反例把反例信息作為上下文反饋給大模型。大模型基于反例信息進(jìn)行反思輸出修正后的結(jié)論。最終輸出包括模型初始思路、驗證結(jié)果、反思結(jié)論。這個流程的核心思想是不要信任大模型的結(jié)論只信任驗證器驗證過的結(jié)論。驗證器可以是程序化的窮舉檢查也可以是符號計算系統(tǒng)甚至可以是一個人工審核步驟。無論形式如何它一定要提供獨(dú)立的、可靠的反饋信號。4.3 提示詞設(shè)計思路在這個系統(tǒng)中提示詞設(shè)計直接決定模型生成質(zhì)量。我們需要設(shè)計兩類提示詞初始思路生成提示詞以及反思修正提示詞。初始思路生成提示詞的關(guān)鍵是讓模型輸出“思考過程”而不是直接給結(jié)論。這樣可以保留更多中間信息供驗證和反思。反思提示詞則需要把反例信息完整地提供給模型并明確要求它找出自己的錯誤假設(shè)。我們可以在實際代碼中體現(xiàn)這個設(shè)計。后面小節(jié)會給出完整實現(xiàn)。5. 完整實戰(zhàn)設(shè)計一個數(shù)學(xué)猜想驗證與思路診斷工具5.1 創(chuàng)建項目結(jié)構(gòu)先創(chuàng)建項目文件逐步填充代碼。項目目錄結(jié)構(gòu)在第 3.3 節(jié)已經(jīng)給出。我們先寫requirements.txtrequests2.31.0 sympy1.12接著寫config.py代碼在 3.2 節(jié)已經(jīng)給出。這里不再重復(fù)。5.2 封裝大模型調(diào)用llm_client.py負(fù)責(zé)與大模型交互。這里使用requests直接請求 OpenAI 兼容的/chat/completions接口避免引入額外的 SDK 依賴。# llm_client.py import requests import config def chat(messages, temperature0.3, max_tokens1024): 調(diào)用 OpenAI 兼容接口。 messages 格式示例 [ {role: system, content: 你是一個數(shù)學(xué)助手。}, {role: user, content: 請證明n的三次方減n能被6整除。} ] url f{config.BASE_URL}/chat/completions headers { Authorization: fBearer {config.API_KEY}, Content-Type: application/json, } payload { model: config.MODEL_NAME, messages: messages, temperature: temperature, max_tokens: max_tokens, } response requests.post(url, headersheaders, jsonpayload, timeout60) response.raise_for_status() data response.json() return data[choices][0][message][content]這里有幾個設(shè)計要點(diǎn)。第一temperature設(shè)置為 0.3是為了在數(shù)學(xué)任務(wù)中保持輸出相對穩(wěn)定減少隨機(jī)性如果你希望模型生成更多發(fā)散候選思路可以適當(dāng)調(diào)高到 0.7 左右。第二timeout60防止模型響應(yīng)過慢導(dǎo)致程序卡死。第三這個函數(shù)完全獨(dú)立于具體模型服務(wù)只要對方兼容/chat/completions接口就能使用。5.3 編寫反例驗證器verifier.py是整個項目中最關(guān)鍵的模塊。它負(fù)責(zé)對數(shù)學(xué)命題做獨(dú)立的程序化驗證。我們實現(xiàn)兩個經(jīng)典命題第一個命題是“對于任意正整數(shù) nn^3-n 能被 6 整除”。這個命題是正確的我們可以用窮舉驗證也可以讓模型給出證明思路。第二個命題是“對于任意正整數(shù) nn^2n41 都是素數(shù)”。這個命題在 n 取較小值時看起來成立但在 n40 時會失效因為 40^24041168141^2。這是一個非常經(jīng)典的“看起來對但實際不對”的例子非常適合用來展示“驗證閉環(huán)”的價值。# verifier.py from sympy import isprime def check_n3_minus_n_divisible_by_6(limit10000): 驗證命題對于所有 1 n limitn^3 - n 是否能被 6 整除。 返回 (是否通過, 反例或None) for n in range(1, limit 1): if (n ** 3 - n) % 6 ! 0: return False, n return True, None def check_n2_plus_n_plus_41_is_prime(limit10000): 驗證命題對于所有 1 n limitn^2 n 41 是否為素數(shù)。 返回 (是否通過, 反例或None) for n in range(1, limit 1): val n ** 2 n 41 if not isprime(val): return False, n return True, None這里的isprime來自sympy是確定性的素數(shù)判定函數(shù)比自己在循環(huán)里試除要可靠得多。每個驗證函數(shù)都返回兩個值是否通過以及反例。這樣主流程可以很方便地把反例信息反饋給模型。在實際項目中驗證器不一定是純窮舉。對于更復(fù)雜的命題可以接入符號積分、矩陣運(yùn)算、約束求解器等工具。核心原則是驗證器必須獨(dú)立于大模型必須能給出確定性的判斷結(jié)果。5.4 編寫主流程pipeline.py是主流程文件把大模型生成和驗證器結(jié)合起來。流程如下用戶輸入命題描述。調(diào)用大模型生成初始思路。調(diào)用對應(yīng)的驗證器檢查命題。如果發(fā)現(xiàn)反例將反例信息拼接到提示詞中讓模型反思并修正。輸出最終結(jié)果。# pipeline.py import llm_client import verifier SYSTEM_PROMPT 你是一位嚴(yán)謹(jǐn)?shù)臄?shù)學(xué)思維教練。請給出推理過程和結(jié)論并明確指出你使用了哪些假設(shè)。 def generate_initial_thought(problem): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f請分析以下數(shù)學(xué)命題是否成立并給出理由\n{problem}}, ] return llm_client.chat(messages) def generate_reflection(problem, initial_thought, counterexample): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f請分析以下數(shù)學(xué)命題是否成立\n{problem}}, {role: assistant, content: initial_thought}, { role: user, content: f你的上述分析可能有誤。程序找到了一個反例n{counterexample} 時命題不成立。 f請檢查你的分析過程指出錯誤原因并重新給出結(jié)論。, }, ] return llm_client.chat(messages) def run_pipeline(problem, verifier_func, problem_key): print( * 60) print(數(shù)學(xué)命題, problem) print( * 60) # 第一步生成初始思路 print(\n[1/4] 大模型生成初始思路中 ...) initial_thought generate_initial_thought(problem) print(模型思路) print(initial_thought) # 第二步驗證器檢查 print(\n[2/4] 程序驗證中 ...) passed, counterexample verifier_func() if passed: print(驗證結(jié)論在驗證范圍內(nèi)未發(fā)現(xiàn)反例命題通過程序檢查。) print(\n[3/4] 無需反思直接結(jié)束。) print([4/4] 完成。) return print(f驗證結(jié)論發(fā)現(xiàn)反例 n {counterexample}命題不成立。) # 第三步反思修正 print(\n[3/4] 將反例反饋給模型請求反思 ...) reflection generate_reflection(problem, initial_thought, counterexample) print(模型反思) print(reflection) # 第四步輸出結(jié)果 print(\n[4/4] 完成。最終結(jié)論以驗證器為準(zhǔn)。) print(f反例n {counterexample}) if __name__ __main__: problem1 對于所有正整數(shù) nn 的三次方減 n 能被 6 整除。 problem2 對于所有正整數(shù) nn 的平方加 n 加 41 都是素數(shù)。 print(示例一正確命題) run_pipeline(problem1, verifier.check_n3_minus_n_divisible_by_6, p1) print(\n\n示例二存在反例的命題) run_pipeline(problem2, verifier.check_n2_plus_n_plus_41_is_prime, p2)這個主流程把整個“生成—驗證—反思”的 AI Agent 閉環(huán)串起來了。運(yùn)行之后你會看到模型對第二個命題初始可能給出“這個表達(dá)式由歐拉發(fā)現(xiàn)前很多項都是素數(shù)”之類的分析但程序驗證直接找到 n40 這個反例并觸發(fā)模型反思。這個對比非常直觀地展示了“AI 思路”和“數(shù)學(xué)事實”之間的差距。5.5 運(yùn)行與結(jié)果演示在項目根目錄下運(yùn)行python pipeline.py預(yù)期輸出大致如下實際內(nèi)容取決于你使用的模型 數(shù)學(xué)命題 對于所有正整數(shù) nn 的三次方減 n 能被 6 整除。 [1/4] 大模型生成初始思路中 ... 模型思路 可以將 n^3 - n 分解為 n(n-1)(n1)這是三個連續(xù)整數(shù)之積。 三個連續(xù)整數(shù)中必有一個能被 3 整除至少有一個能被 2 整除 所以它們的乘積能被 6 整除。 [2/4] 程序驗證中 ... 驗證結(jié)論在驗證范圍內(nèi)未發(fā)現(xiàn)反例命題通過程序檢查。 [3/4] 無需反思直接結(jié)束。 [4/4] 完成。 數(shù)學(xué)命題 對于所有正整數(shù) nn 的平方加 n 加 41 都是素數(shù)。 [1/4] 大模型生成初始思路中 ... 模型思路 這個多項式在 n0 到 39 時都給出素數(shù)看起來很可能對所有正整數(shù)成立。 但需要進(jìn)一步證明。 [2/4] 程序驗證中 ... 驗證結(jié)論發(fā)現(xiàn)反例 n 40命題不成立。 [3/4] 將反例反饋給模型請求反思 ... 模型反思 我之前的分析過于依賴局部觀察。雖然 n0 到 39 都成立 但當(dāng) n40 時40^24041168141^2不是素數(shù)。 這說明一個命題不能通過有限個例子來證明。 [4/4] 完成。最終結(jié)論以驗證器為準(zhǔn)。 反例n 40這個輸出很好地展示了整個系統(tǒng)的價值大模型負(fù)責(zé)生成人類可讀的思路程序驗證器負(fù)責(zé)給出確定性結(jié)論反例信息再反饋給模型促成反思。你還想繼續(xù)深挖的話可以在這個基礎(chǔ)上增加更多的驗證器例如不等式驗證、數(shù)值積分驗證、方程求解驗證甚至接入形式化證明工具。6. 常見問題與排查思路在跑這個項目或者擴(kuò)展類似 AI Agent 應(yīng)用時你可能會遇到一些問題。下面按照常見程度做一個匯總。問題現(xiàn)象常見原因解決思路調(diào)用大模型接口超時模型較大或網(wǎng)絡(luò)延遲較高增大timeout參數(shù)改用流式請求使用本地模型返回內(nèi)容被截斷max_tokens設(shè)置太小調(diào)大max_tokens例如 2048 或 4096模型輸出大量無關(guān)內(nèi)容提示詞沒有限定輸出格式在 System Prompt 中要求結(jié)構(gòu)化輸出窮舉驗證范圍過大數(shù)據(jù)量太大單線程循環(huán)太慢使用numpy向量化計算或只驗證關(guān)鍵邊界區(qū)間模型反復(fù)堅持錯誤答案反例信息在上下文中不夠醒目把反例放在 Prompt 末尾并使用加粗或強(qiáng)調(diào)格式sympy.isprime對大數(shù)很慢大素數(shù)判定本身計算量較大縮小驗證范圍或先用概率性素數(shù)判定方法更換云廠商后鑒權(quán)失敗API_KEY或接口路徑不正確檢查服務(wù)商的接口文檔確認(rèn)/chat/completions路徑本地 Ollama 無法連接服務(wù)未啟動或端口不對確認(rèn) Ollama 服務(wù)已啟動檢查BASE_URL是否指向 11434如果模型在反思之后仍然給出錯誤結(jié)論不要感到奇怪。這不是代碼 bug而是反映了大模型在某些數(shù)學(xué)推理任務(wù)上的真實局限。此時驗證器的“一票否決權(quán)”就顯得格外重要。在實際 AI 工程實踐中我們應(yīng)該始終把驗證器作為最終裁判把大模型作為輔助生成器。另外提醒一點(diǎn)如果你把這類工具用于生產(chǎn)環(huán)境比如接入自動化解題系統(tǒng)、數(shù)學(xué)教育平臺一定要對驗證器的覆蓋范圍做充分測試。窮舉驗證只能證明“在驗證范圍內(nèi)成立”不能證明“對所有情況成立”。對于需要嚴(yán)格證明的場景建議接入符號計算系統(tǒng)或人審流程。7. 最佳實踐與工程建議7.1 把數(shù)學(xué)思維遷移到軟件開發(fā)陶哲軒談到的數(shù)學(xué)思維其實可以直接映射到軟件開發(fā)中。提問能力對應(yīng)需求分析中的“識別真正的問題”類比遷移能力對應(yīng)設(shè)計模式復(fù)用構(gòu)造反例的能力對應(yīng)測試用例設(shè)計審美判斷對應(yīng)代碼重構(gòu)和架構(gòu)設(shè)計。很多開發(fā)者寫代碼時習(xí)慣“先寫了再說”遇到 bug 再慢慢調(diào)試。這就像不做驗證就直接讓大模型輸出答案。更好的做法是先構(gòu)造反例這個函數(shù)的邊界條件是什么如果輸入為空、為最大值、為 None會發(fā)生什么把這些反例前置到編碼階段能顯著降低返工率。我在工程實踐中發(fā)現(xiàn)數(shù)學(xué)思維好的開發(fā)者在排查線上問題時往往會先問“這個假設(shè)在什么情況下不成立”而不是急于翻日志。這種習(xí)慣本質(zhì)上就是數(shù)學(xué)中的“反例思維”。如果你想提升自己的編程能力可以從刻意練習(xí)“給自己挑錯”開始。7.2 使用 AI 學(xué)習(xí)數(shù)學(xué)思維的正確姿勢既然大模型在數(shù)學(xué)推理上需要驗證閉環(huán)那我們普通人使用 AI 學(xué)習(xí)數(shù)學(xué)時也應(yīng)該建立這個閉環(huán)。不要把大模型當(dāng)成答案機(jī)器而是當(dāng)成“可以對話的思維陪練”。一個推薦的做法是拿到一個數(shù)學(xué)問題后先自己嘗試提出猜想再讓大模型給你多個證明方向然后用計算工具去驗證最后把驗證結(jié)果反饋給大模型讓它反思。這個過程不是“用 AI 抄答案”而是“用 AI 做演練”。長期堅持下來你訓(xùn)練的是自己的提問能力、反例敏感度和驗證意識而不只是記住某個題的解法。在 AI Agent 開發(fā)的語境下這也意味著好的 AI 應(yīng)用不應(yīng)該只是“Prompt 包裝”而應(yīng)該包含工具調(diào)用、驗證反饋、自我反思等模塊。當(dāng)前的 AI Agent 框架已經(jīng)支持這類設(shè)計但核心思路仍然是那條讓模型生成讓工具驗證讓反饋閉環(huán)。7.3 面向 AI 工程的生產(chǎn)建議如果你準(zhǔn)備把類似“AI 數(shù)學(xué)驗證”的方案落地到生產(chǎn)中有幾點(diǎn)建議。第一把驗證器設(shè)計成可插拔的模塊。不同的數(shù)學(xué)問題需要不同的驗證工具建議定義統(tǒng)一的驗證接口方便后續(xù)擴(kuò)展。第二日志要記錄模型的原始輸出、驗證器結(jié)果、反例信息以及反思輸出。這些日志既可以用于調(diào)試也可以用于構(gòu)建測試集來評估模型效果。第三對模型輸出做內(nèi)容安全過濾。尤其是面向教育場景時要避免模型輸出包含不當(dāng)內(nèi)容。第四注意模型幻覺對用戶體驗的影響。如果產(chǎn)品面向普通用戶建議在 UI 上區(qū)分“AI 生成內(nèi)容”和“程序驗證結(jié)果”避免用戶混淆。安全方面要特別提醒在使用大模型 API 時不要在 Prompt 中提交敏感個人信息在生產(chǎn)環(huán)境中為 API Key 配置最小權(quán)限任何涉及自動執(zhí)行代碼的功能都要放在沙箱環(huán)境中運(yùn)行并經(jīng)過嚴(yán)格的合法授權(quán)。8. 總結(jié)與下一步學(xué)習(xí)路線本文從陶哲軒關(guān)于 AI 與數(shù)學(xué)思維的討論切入拆解了 AI 在數(shù)學(xué)推理上的能力邊界并設(shè)計了一個可運(yùn)行的“數(shù)學(xué)猜想驗證與思路診斷工具”。在這個小項目中大模型負(fù)責(zé)生成解題思路程序驗證器負(fù)責(zé)檢查命題真?zhèn)畏蠢畔⒈环答伣o模型進(jìn)行反思。這個過程還原了人類數(shù)學(xué)家“猜想—驗證—修正”的思維閉環(huán)也展示了 AI Agent 開發(fā)中的經(jīng)典模式。如果你對下一步學(xué)習(xí)方向感興趣可以沿著三個方向繼續(xù)深入。第一學(xué)習(xí)符號計算與形式化驗證。sympy只是起點(diǎn)更深入的方向包括 Coq、Lean、Isabelle 等證明助手。這些工具能讓 AI 的推理過程被機(jī)器嚴(yán)格校驗也是目前 AI 數(shù)學(xué)研究的前沿方向之一。第二學(xué)習(xí) AI Agent 開發(fā)框架。把本文的“生成—驗證—反思”循環(huán)用 LangChain、LlamaIndex 等框架重寫并加入記憶、工具調(diào)用、多步規(guī)劃能力就是一個功能更完整的 AI Agent 應(yīng)用。重點(diǎn)仍然是保持“驗證器獨(dú)立、反饋閉環(huán)”的設(shè)計原則。第三練習(xí)構(gòu)造反例。你可以從經(jīng)典數(shù)學(xué)問題開始比如歐拉多項式、連續(xù)但不可導(dǎo)的函數(shù)、滿足一定條件的反常積分等嘗試自己構(gòu)造反例再把這些反例做成上述工具的新驗證器讓模型在反思時面對更豐富的素材。這個過程既訓(xùn)練數(shù)學(xué)思維也鍛煉工程實現(xiàn)能力。如果本文對你理解 AI 與數(shù)學(xué)思維的關(guān)系有幫助可以收藏備用。也歡迎你根據(jù)自己的項目場景把驗證閉環(huán)的思路應(yīng)用到代碼生成、數(shù)據(jù)分析、自動化測試等更多 AI 工程實踐中。