這項由韓國科學技術院（KAIST）與DeepAuto.ai聯合開展的研究，於2026年6月3日以預印本形式發布，論文編號為arXiv:2606.04743v1，歸屬電腦科學·計算與語言（cs.CL）方向。有興趣深入探究的讀者可通過該編號在arXiv平台檢索完整論文。
你有沒有遇到過這種情況：工作群里的消息堆積如山，日曆上的會議一個接一個，文件夾里的文檔越來越多，但某個關鍵截止日期悄悄溜走了，某份報告裡的數據自相矛盾了，某個會議早就沒人去開了，卻還占著最重要的時間窗口——而你完全沒有察覺，直到問題爆發。現在的AI助手再聰明，也只在你開口問的時候才會行動，它不會主動翻一翻你的日曆說"你下周有個大麻煩"。
KAIST與DeepAuto.ai的研究團隊認為，這種"等著被差遣"的模式根本上是一種缺陷。真正有用的助手，應該像一個經驗豐富的同事，能在你還沒意識到問題存在之前，就已經幫你把隱患找出來。正是帶著這個想法，他們設計出了一套名為TIDE的框架——全稱Template-guided Iterative Discovery and rEsolution，直譯過來叫"模板引導的疊代發現與解決"。這個名字有點拗口，但背後的思路其實非常貼近日常經驗，後面會慢慢道來。
一、只等吩咐的助手，為什麼是個根本性的問題
現有的AI助手，無論多麼強大，本質上都處於一種"被動等候"的狀態。你告訴它"幫我安排周三下午一點跟James的會議"，它就去安排；你不說，它就靜靜地待著。這種模式有一個隱含的前提：用戶自己已經知道哪裡有問題，只需要AI去執行。
但現實恰恰相反。最麻煩的問題往往是那些你還不知道自己不知道的事。研究團隊舉了幾個非常具體的例子：某部門口頭批准了一筆預算，但沒有人把這個決定記錄在案，導致供應商訂單因無據可查而卡住，而截止日期就在眼前；同一份報告存在兩個版本，數據互相矛盾，兩份都要進入即將召開的高層評審；某個例行會議大家已經默契地不去參加了，但日曆上的時間塊還在，把唯一合適的緊急啟動會窗口堵死了。這些問題並不藏在什麼神秘角落裡——它們就明明白白地躺在郵件、文檔、日曆條目里，AI原本完全可以讀到，卻從來沒人讓它主動去找。
同樣的結構在軟體開發領域也普遍存在。一個代碼倉庫里可能同時潛伏著多個互相關聯的Bug，其中一個修了，另外幾個還在，用戶只報告了一個問題，AI只修了那一個，其餘的繼續等著在某個深夜引發事故。
研究團隊把這類情景歸納為一個新任務：從上下文中發現多個隱藏問題。它的關鍵特徵有三點：問題從來沒有被明確表達為一個請求；同時存在的問題數量事先未知；只解決最顯眼的那一個，其餘的仍舊原封不動。這與以往那些"預測用戶想要什麼"的研究不同——以往大多是預測一個單一需求，而這裡面對的是一片散落的隱患，數量不定，相互競爭注意力。
二、最直覺的做法為什麼行不通
看到這裡，你可能會想：那就直接讓AI把所有問題一次全找出來不就行了？或者乾脆多開幾個AI並行工作，一人找一個，這樣覆蓋得更全？
研究團隊確實考慮過這兩種方案，並且在實驗中認真測試了它們。結果卻頗為出乎意料，兩種方案都失敗了，而且失敗的方式很有啟發性。
先說"一次找完"這條路。當你把整個工作區的郵件、文檔、日曆全塞給AI，讓它一口氣找出所有問題時，AI的注意力會不由自主地被最顯眼的東西吸引。就像一個偵探走進亂成一團的房間，第一眼看到的肯定是最大的那堆亂——床上亂扔的衣服、桌上的外賣盒——而不是抽屜角落裡那張記錯日期的便條。AI會把精力壓在最突出的問題上，給出幾個描述模糊的"通用結論"，而那些更隱蔽但同樣重要的問題就這樣被遺漏了。
再說"多個AI並行"這條路。表面上看，開多個獨立的AI同時掃描，應該能看到更多地方。但問題在於，這些AI之間互相不通氣。每一個都從零開始審視同樣的資料，每一個都會被同樣最顯眼的信號所吸引，於是它們找到的，大多是同一批問題的重複。研究團隊在實驗裡實際測量了這一點：從第二個AI開始，新發現的問題急劇減少，重複發現的問題迅速占據主導。到最後，十個並行AI湊在一起，效果甚至比不上TIDE用兩次疊代取得的結果。更根本地說，多開幾個AI並沒有改變任何結構——問題在於沒有人告訴後來的AI"前面已經找到什麼了，不要重複"，並行只是把同樣的盲點複製了好幾遍。
三、TIDE的兩個核心武器：疊代發現與思維模板
面對上述兩個失敗，研究團隊的解法是兩個互補的機制，它們從不同角度各攻一個弱點。
第一個機制叫做疊代發現。不再要求AI一次找完所有問題，而是讓它每一輪只找少量新問題，然後明確知曉"我已經找到了什麼"，再開始下一輪。這個"明確知曉"是關鍵——後續的每一輪，AI都是在"剩餘未發現問題"這片空間裡搜索，而不是重新掃描整個空間。回到偵探的比喻：第一輪偵探清點了最顯眼的證物；第二輪他再來，知道那些顯眼的已經記錄在案，就開始注意那些更不起眼的細節；第三輪他清楚了更多已有線索，目光繼續向更隱秘處延伸。每一輪的"已發現清單"都在推著他往更深處走。
在技術層面，這個機制的表述相當簡潔：第t輪的新發現，等於"把整個文檔集合、模板庫、以及截至第t-1輪的所有已發現問題"一起餵給AI，讓它生成最多k個新候選。發現集隨著輪次累積，直到某輪返回空結果，或者達到預設的最大輪次T為止。對於個人工作區任務，T設為10輪；對於代碼倉庫任務，T設為3輪，因為代碼問題通常更集中，不需要那麼多輪。
第二個機制叫做思維模板。即便有了疊代，AI在每一輪面對文檔時，如果沒有任何"先驗知識"，它的推斷仍然可能飄向模糊或投機性的描述，因為它不知道這類問題通常長什麼樣。思維模板解決的就是這個問題：從過去已經解決過的案例里，把問題的結構抽象出來，形成可以反覆使用的"偵查模式卡片"，讓AI在遇到新情況時能對號入座。
每張模板包含三個部分：一個名字，標明這是哪一類問題；一個模式描述，說明這類問題的結構性特徵；以及一個證據流程，告訴AI應該按什麼順序去查看哪些信號、怎麼把它們串聯起來推斷出問題的存在。
舉一個論文裡給出的具體模板作為例子。這張模板叫做"衝突資訊源在截止日期下阻礙審批"。它的模式描述是：同一份原始材料在不同渠道里存在互相矛盾的版本，而一個迫在眉睫的截止日期要求必須在審批完成之前確定哪個版本是權威的。它的證據流程分三步：第一步，找到那份可交付物以及它聲稱引用的來源；第二步，在不同渠道里找到這份材料的多個副本，確認存在實質性的差異；第三步，把這個衝突與有時間限制的審批節點以及負責解決它的人聯繫起來。
有了這張模板，AI就不用從零開始猜"這堆文檔里可能有什麼問題"，而是可以按圖索驥地去問："這裡有沒有某個材料存在多個版本，且審批因此卡住了？"這不是在限制AI只能找模板里描述的問題——研究團隊特別設計了一條規則：對於代碼倉庫的任務，AI同樣被鼓勵報告不符合任何模板但確實是真實Bug的問題，兩種情況同等有效。模板的作用是提供一批"已知的常見模式"作為抓手，而不是設置邊界。
模板是從訓練集裡的已解決案例中構建出來的：對於工作區任務，研究團隊生成了40個模板；對於代碼倉庫任務，生成了108個模板。這些模板在推斷時保持固定，不會隨著當前任務的進展而修改，但可以跨不同AI後端轉用。
四、兩個測試戰場：個人工作區與軟體倉庫
為了檢驗TIDE的實際效果，研究團隊搭建了兩套真實感極強的測試場景，因為沒有任何現有基準專門針對"從上下文中發現多個隱藏問題"這個任務，他們必須自己構建評估數據。
第一套場景是個人工作區。每個測試實例代表一位真實用戶的數字工作環境，包含一份描述該用戶角色、工作風格、當前優先事項、痛點和人際關係的畫像，以及這位用戶的工作文檔、郵件和日曆條目構成的"文件庫"。每一個隱藏問題通常需要AI把多份不同文檔、郵件和日曆條目里的資訊拼接起來才能識別——沒有任何單一文檔會直接寫明"這裡有個問題"。文件庫里還穿插著大量干擾材料，它們看起來與正在進行的項目相關，但實際上並不牽涉任何真實問題。解決方案的形式是從預設動作集裡選取一個具體行動，比如"發送郵件"、"安排會議"、"共享文檔"、"向上級匯報"，並填寫執行所需的全部參數。研究團隊藉助一套數據構建流程生成了30個多問題工作區，共包含150個問題，每個工作區包含4到6個隱藏問題，以及88到113個候選文件。
第二套場景是軟體代碼倉庫。每個測試實例是一個真實開源Python項目在某個提交節點的快照，此時代碼里同時存在多個未解決的Bug，修復它們需要對代碼庫里多個函數各自打補丁。每個問題對應一位真實GitHub用戶提交的Issue，金標準解決方案是實際合併進主分支的Pull Request補丁。文件庫由從快照里解析出的候選函數構成，其中只有一部分函數包含待修的Bug，其餘都是干擾函數。研究團隊從SWE-BENCH和TESTEXPLORA兩個數據集裡收集了Python倉庫的GitHub Issue，按"同一倉庫、同一錨點提交、至少兩個Bug分布在至少兩個不同函數"的標準進行分組，最終得到20個多Bug測試實例，涵蓋11個真實項目，共146個問題，每個實例包含2到41個問題，候選函數數量從6個到646個不等。
五、實驗結果：數字背後的故事
研究團隊用四個主流大語言模型作為後端進行測試：GPT-5 mini、Claude Sonnet 4.5、Gemini 3.5 Flash和Qwen 3.6 Flash，這四個模型都支持超長上下文，能一次性讀入完整的文件庫。評估維度分為三個：檢索（AI找到的支持證據與金標準證據的重合度）、識別（AI對問題本身的描述是否正確）和解決（AI提出的行動方案是否有效）。每個維度都分別計算"覆蓋率"和"F1分"，前者衡量金標準里有多少問題被成功發現，後者綜合考慮覆蓋率和精準度，對那些找了很多但大多是錯的情況予以懲罰。
以GPT-5 mini為例，在工作區任務上，單次單智能體的檢索覆蓋率是47.60，TIDE達到了69.06；識別覆蓋率從47.85提升到67.64；解決覆蓋率從49.67躍升到76.08。平行多智能體的表現甚至不如單次單智能體——多個獨立AI合力下來，檢索覆蓋率只有32.15，TIDE的成績幾乎是它的兩倍。在代碼倉庫任務上，各方分數普遍偏低（這個任務本身更難），但TIDE相對於基線的提升幅度依然十分明顯，檢索覆蓋率從8.66提升到16.82，識別從11.15到17.29，解決從12.19到15.52。四個模型後端的結果高度一致，TIDE在每一種模型下都是最佳。
從具體實例分布來看，在工作區任務里，單次單智能體和多智能體大多只能發現一到兩個問題，而每個實例其實藏著四到六個。TIDE則頻繁能發現四個甚至更多。隨著每個實例中金標準問題數量的增加，兩個基線的覆蓋率越來越跟不上，TIDE卻始終保持相對穩定的覆蓋能力。
研究團隊還做了一個非常直觀的拆解實驗：把每一輪的新預測和重複預測分開統計。結果顯示，多智能體從第二個AI開始，新發現急劇下滑，重複發現迅速占據主導；而TIDE在每一輪疊代里都持續貢獻真正新的發現，這種"持續擴張"的特性，正是它覆蓋率領先的根本原因。
六、兩個機制各自貢獻了什麼
疊代和模板到底各自貢獻了多少？研究團隊做了細緻的消融實驗來拆解這個問題。
在逐輪跟蹤覆蓋率和精準度的對比中，有模板的TIDE與無模板的TIDE相比，覆蓋率的差距相對較小，而精準度的差距則在每一輪都顯著可見。這說明，疊代本身主要貢獻的是"找到更多"，而模板主要貢獻的是"找得更准"。兩者作用於不同維度，缺一不可。
研究團隊還測試了一個很自然的替代方案：既然模板是從訓練樣本里提煉出來的，那直接把原始訓練樣本作為"few-shot示範"塞進疊代循環，效果會不會和模板一樣好？答案是否定的。帶有原始示範的疊代在檢索、識別和解決三個維度上都明顯低於使用模板的TIDE。這說明，模板的價值不在於"讓AI見過例子"，而在於把例子背後的結構抽象出來形成可復用的推理模式——這兩件事有本質區別。
模板池的大小也有直接影響。研究團隊在代碼倉庫任務上逐步增加可用模板的數量，三個指標隨模板數量增加而穩步提升。而且值得注意的是，即便一個模板都沒有，只用疊代的版本也已經超越了單次單智能體基線——這說明疊代本身就有獨立價值，模板在此基礎上疊加進一步增益。
另一個值得關注的發現是模板的跨模型遷移性。GPT構建的模板交給Gemini用，或者Gemini構建的模板交給GPT用，效果與各自用自己構建的模板相當，甚至在某些維度上還略有提升。這意味著模板作為一種抽象化的"問題結構知識"，具有相當程度的通用性，不依附於特定模型的思維風格。兩個模型在使用模板時的偏好倒有所不同：GPT傾向於集中引用少數幾個高頻模板，Gemini則更分散，廣泛引用更多模板——但最終結果上的差距遠小於這種風格差異所暗示的程度。
七、兩個具體案例：偵探破案的全過程
論文裡給出了兩個詳細的對比案例，非常清楚地展示了單次單智能體和TIDE在實際表現上的差距。
第一個案例來自工作區場景。金標準問題是：某企業社區影響力經理的志願者追蹤平台在3月8日"社區建設日"活動中出現了重複計數，供應商的修復程序已經就緒，但被一個待審批的IT安全權限申請單卡住，而這批數據將在3月20日的高層匯報中使用。正確答案需要五份文檔共同支撐：3月12日供應商支持工單、3月13日權限審批請求、重複的志願者記錄、3月20日高層匯報預讀材料、以及數據凍結協調線程。正確的行動是向特定主管發出緊急提醒，附上權限申請卡單情況、供應商部署窗口和匯報截止日期。
單次單智能體找到了什麼？它找到了一個完全無關的"設施採購停滯"問題，沒有檢索到任何一份金標準文檔，發出的郵件既沒有對準正確的主管，也沒有提及權限申請或高層匯報截止。
TIDE在第三輪疊代中找到了這個問題，五份金標準文檔全部檢索到位，問題描述精確命中了平台重複計數、卡住的權限申請和高層匯報的時間鏈條，行動方案也正確指向了該主管，並附上了所有關鍵細節。驅動這一發現的是一張編號TID_11的模板，模式描述為：一份有時間約束的高層交付物依賴於某個修復就緒但被內部審批拖住的正確材料，向主管鏈路升級可以在交付窗口前解除卡點。
第二個案例來自代碼倉庫場景。金標準問題是mlxtend庫中McNemar檢驗相關的多函數Bug：兩個配對的函數mcnemar_table和mcnemar_tables在構建2×2列聯表時，都把對角線以外的兩個格子賦值顛倒了，修復必須在兩個函數裡同步進行。
單次單智能體把這兩個函數的問題當作兩個獨立Bug來處理，每個函數各自打了一個補丁，確實都在局部做了正確修改，但從來沒有意識到這是一個跨函數的共同模式，也就沒有把它們作為一個關聯缺陷統一表述和修復。
TIDE在一個單獨的發現條目里同時檢索到了兩個函數，把tb[1,0]和tb[0,1]的賦值顛倒追溯到了兩個構造函數共同違反的文檔約定，並生成了一個統一的補丁，在兩個函數裡同步交換對角線賦值。驅動這一發現的是編號TID_47的模板：兩個兄弟工廠函數為相關輸入構建相同形狀的容器，兩者都計算了同一個判別值，但賦值時索引順序相對於文檔約定是反的，這種失敗在調用處靜默無聲，只有在下游消費者按文檔約定讀取容器時才會暴露。
這兩個案例共同呈現了一個清晰的模式：TIDE的改進不是偶發的，而是由可識別的、可復用的推理結構系統性地驅動的。
說到底，這項研究回答的問題相當基本：一個智能助手，如果只在你開口的時候才有反應，那它幫到你的，只是你已經知道的問題。而真正讓你措手不及的，恰恰是那些你沒想到要問的事。
TIDE的核心貢獻並不是一個複雜的算法突破，而更像是一種認知策略的轉變：把"找問題"這件事從一次性的大掃描，變成一個有記憶的、不斷縮小搜索範圍的疊代過程；同時把過去解決過的案例里提煉出的結構性知識，以可復用的形式注入到每一輪推斷中。這兩件事分別對應"找得更多"和"找得更准"，互不干擾，疊加在一起效果顯著。
在實際應用層面，這項研究意味著未來的AI助手不只是一個更聰明的執行工具，而有可能成為一個真正意義上的"主動看護者"——能在你的工作流里自己找到那些正在悄悄積累的麻煩，在它們釀成真正的危機之前送到你眼前。從日常工作管理到代碼維護，這種能力都有直接的落地價值。
當然，這套方案也有它尚未完全解決的地方。模板目前是一次性構建好的，在推斷時不會根據新發現自動擴充；如何讓模板庫隨著AI積累的經驗動態成長，是研究團隊明確指出的下一步方向。同樣，疊代多輪意味著需要多次調用語言模型，這是一種計算成本的投入，儘管實驗表明哪怕只用兩輪疊代，效果已經超過了用十個並行AI的方案。
如果你對這個話題感興趣，有一個值得思考的問題：在你自己的日常工作或生活里，有哪些隱患是你很清楚"可能存在"卻總沒機會系統排查的？如果有一個AI助手每周幫你主動掃描一遍，你最希望它先關注哪個角落？原論文可通過arXiv編號2606.04743v1查閱。
---
Q&A
Q1：TIDE框架中的"思維模板"是怎麼來的，普通人能自己造嗎？
A：思維模板是從已經解決過的案例里自動提煉出來的，具體方式是把一個已解決問題的描述、相關文檔和解決方案一起餵給大語言模型，讓它把其中的具體細節抽象掉，只保留結構性的"問題形態"和"應該按什麼順序看哪些信號"。這個過程本身是自動的，不需要人工手寫。研究團隊為工作區任務生成了40個模板，代碼任務生成了108個。普通用戶如果有足夠多自己領域裡的已解決案例，理論上可以用同樣的流程構建屬於自己場景的模板庫。
Q2：TIDE疊代多輪會不會讓同一個問題被重複發現，浪費計算資源？
A：這正是TIDE與多智能體並行方案的根本區別所在。多智能體每個都從零開始，確實會大量重複發現相同的顯眼問題。TIDE的每一輪疊代都明確知曉"前幾輪已經找到了什麼"，並被要求只報告全新的問題，如果某輪沒有新發現就直接終止。實驗數據顯示，TIDE在每一輪都持續貢獻新的發現，而多智能體從第二個開始新發現就急劇減少。
Q3：TIDE只能用於工作區和代碼倉庫場景嗎？
A：從框架設計來看，TIDE並不綁定特定場景，其核心邏輯是：給定任意一組文檔集合，通過帶記憶的疊代搜索和可復用模板，發現其中同時存在的多個隱藏問題。只要能提供足夠的歷史已解決案例來構建模板庫，原則上這套方法可以遷移到其他場景，比如法律文檔審查、醫療記錄分析或項目管理文件審核。研究團隊選擇工作區和代碼倉庫，主要是因為這兩個場景都有現成的數據來源可以構建評估集。
