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