Ultracode 把編排從 opt-in 改為常態預設。
概述
開關由 harness 控制。
開啟時 context 中會出現 system-reminder 確認 ultracode 已開啟,這是常態 opt-in 生效的信號;reminder 顯示關閉時回復一般行為,僅在明確要求時執行 workflow。
預設傾向編排與驗證。
除非工作瑣碎或已驗證,否則傾向以 workflow 編排,並對發現進行對抗式驗證。
仍有單執行緒的例外。
即使開啟,瑣碎的機械式修改與純對話回合仍單執行緒處理。規則是「實質」任務,而非字面上的所有事。
模式對照 Mode contrast
Ultracode 改變的是預設行為與成本取捨,而非個別原語。
模式對照
NORMAL VS ULTRACODE
排名 01/04
預設行為opt-in 變為常態.
一般模式須明確要求;Ultracode 預設對每個實質任務編排.
一般模式下多數委派交給單一 agent,workflow 須使用者明確要求。Ultracode 開啟後,workflow 成為實質任務的預設路徑。
- 常態 opt-in
- 預設 fan-out
- /
- 04
- Normal
- 須明確要求
- Ultra
- 預設 workflow
排名 02
成本取捨token 視為非約束.
一般模式衡量 token 成本;Ultracode 以品質為目標.
一般模式會權衡 token 成本。Ultracode 將 token 成本視為非約束條件,目標是最完整、最正確的答案。這是使用者主動選擇的取捨。
- 品質優先
- 成本非約束
- Normal
- 衡量成本
- Ultra
- 品質優先
排名 03
驗證深度單次變為對抗式.
一般模式單一 agent 嘗試後迭代;Ultracode 多獨立觀點後合成.
一般模式由單一 agent 嘗試,再由主迴圈迭代。Ultracode 預設以多個獨立觀點與對抗式檢查,在採納前淘汰看似合理但錯誤的發現。
- 對抗式驗證
- 多觀點
- Normal
- 單次
- Ultra
- 多數決
排名 04
例外範圍瑣碎任務仍單做.
瑣碎與對話任務不編排.
即使開啟,純對話回合與小型機械式編輯仍單執行緒。可在任一單一請求上要求「快速處理、不要 workflow」。
- 對話回合
- 機械式修改
- Solo
- 瑣碎任務
- Override
- 逐請求
分階段編排 Phased orchestration
對多階段工作,Ultracode 依序執行多個 workflow,每階段一個,讓使用者在階段間保持參與。
分階段編排
UNDERSTAND → DESIGN → IMPLEMENT → REVIEW
排名 01/04
Understand平行理解.
多個讀者並行掃描相關子系統,產出結構化地圖.
理解階段以平行 reader 覆蓋相關子系統,回傳結構化地圖,作為後續設計的依據。
- 平行讀者
- 結構化地圖
- /
- 04
- In
- 子系統
- Out
- 地圖
排名 02
Design方案評審.
N 個獨立方案評審團評分合成.
設計階段以評審團從不同角度產生獨立方案,評分後合成。屬於 design 型單階段 workflow。
- 評審團
- 評分合成
- In
- 多方案
- Out
- 合成
排名 03
Implement隔離實作.
每個變更點一個 agent,必要時 worktree 隔離.
實作階段對每個變更點派出 agent;若 agent 並行改檔會衝突,以 isolation:'worktree' 隔離。
- 逐點實作
- worktree
- Per
- 變更點
- Isolation
- worktree
排名 04
Review審查驗證.
維度展開、尋找、對抗式驗證.
審查階段沿維度展開,各維度的發現一經審查完成即進入對抗式驗證。最後一個 agent 可作為完整性評論者,詢問還缺什麼。
- 維度展開
- 對抗式驗證
- 完整性評論
- Flow
- find→verify
- Critic
- 完整性
品質模式 Quality patterns
這些模式是工具,依任務挑選並組合。規模對齊使用者所求:小檢查從簡,稽核從深。
品質模式
QUALITY PATTERNS · TOOLS
排名 01/04
Adversarial verify對抗式驗證.
每個發現派出多個 skeptic,要求反駁,多數反駁則淘汰.
派出 N 個獨立 skeptic,每個被指示嘗試反駁,不確定時預設「已反駁」。避免看似合理但錯誤的發現存活。發現可能以多種方式失效時,給每個驗證者不同視角優於相同的重複者。
- 多數決
- 視角多樣
- /
- 04
- Votes
- N
- Survive
- 多數未反駁
排名 02
Multi-modal sweep多模掃描.
多代理各以不同方式搜尋,彼此不知對方所見.
依容器、依內容、依實體、依時間等不同角度並行搜尋,適合單一角度找不全時。
- 多角度
- 互盲
- Angles
- 容器 內容 實體 時間
排名 03
Loop-until-dry掃到無新發現.
持續派 finder,直到連續 K 輪無新發現.
規模未知的探索以 seen 集合去重,連續若干輪無新發現才停。固定次數迴圈會漏掉長尾。
- 未知規模
- 收斂
- Stop
- K 輪無新
排名 04
Completeness critic完整性評論.
最後一個 agent 詢問還缺什麼.
完整性評論者檢視:有無未執行的模態、未驗證的主張、未讀的來源。它找出的內容成為下一輪工作。若以 top-N 或抽樣限制覆蓋,以 log() 說明捨棄項。
- 缺口檢查
- 不靜默截斷
- Asks
- 還缺什麼
開啟到收尾的操作流程。
使用說明書
Ultracode 是常態 opt-in 模式。以下是從開啟、確認到收尾的步驟。
開啟 Ultracode
Ultracode 由 harness 切換。開啟後,context 中會出現 system-reminder 確認 ultracode is on,這是常態 opt-in 生效的信號。
確認狀態
查看 context 是否出現 ultracode is on 的 system-reminder。顯示 off 時,Claude 回復一般行為,僅在明確要求時才編排 workflow。
交付任務
給一個實質任務即可。Claude 會預設撰寫並執行 workflow,對多階段工作依序展開 understand、design、implement、review。
監看各階段
以
/workflows即時檢視進度。每個階段在背景執行,完成時送出通知。讀完每階段結果再進入下一階段。逐請求調整
對任一請求可要求「快速處理、不要 workflow」,該次即單執行緒。瑣碎修改與對話回合本來就維持單做。
收尾
關閉 Ultracode 後回復一般 opt-in 行為。已完成的 workflow 腳本仍持久化,可日後以 scriptPath 重跑或 resumeFromRunId 續跑。
多階段任務在 Ultracode 下的展開
# 每階段一個 workflow,依序執行,階段間讀結果
phase 1 understand → 平行 reader 掃描子系統,產出結構化地圖
phase 2 design → 評審團產生 N 個方案,評分後合成
phase 3 implement → 每個變更點一個 agent(必要時 worktree 隔離)
phase 4 review → 維度展開 → 對抗式驗證 → 完整性評論四個適合開啟 Ultracode 的情境。
使用情境
Ultracode 適合需要徹底覆蓋、高信心、或超出單一 context 規模的工作。
全面程式碼稽核
comprehensive audit
大型 finder pool + 多輪對抗式驗證 + 合成
對「徹底稽核這個 codebase」這類請求,Ultracode 預設展開較大的 finder pool,以 loop-until-dry 掃到無新發現,再以多數決對抗式驗證,最後合成。
loop-until-dry
對抗式驗證
合成
Scope
全 codebase
Verify
多數決
多階段功能開發全流程
understand → review
每階段一個 workflow,階段間讀結果
對一個完整功能,依序執行理解、設計、實作、審查四個 workflow。使用者在每個階段之間檢視結果再決定下一步,全程在迴圈中。
分階段
sequential
保持參與
Phases
4
Flow
sequential
深度研究與事實查核
research report
多模掃描 → 深讀 → 對抗式查核 → 引用合成
對需要可信來源的研究問題,並行多角度搜尋、深讀來源、對抗式查核主張,最後合成帶引用的報告。完整性評論者補上未涵蓋的角度。
多模掃描
查核
完整性評論
Sources
多源
Verify
查核
大範圍 bug 獵捕到無新發現
bug hunt
loop-until-dry + 視角多樣驗證
持續派出 finder 直到連續若干輪無新 bug,以 seen 去重,每個 bug 由多個不同視角的驗證者判定真偽。捕捉固定次數迴圈會漏的長尾。
loop-until-dry
去重
視角多樣
Stop
K 輪無新
Dedup
seen
開啟前先想清楚取捨。
落地建議
Ultracode 以深度換取完整與正確。它適合稽核、研究、審查;不適合瑣碎或已驗證的工作。
01 · 何時開啟
用在稽核與研究
需要徹底覆蓋、高信心結論、或單一 context 裝不下的工作最受益。一句話的查詢或單檔小修改不需要。
02 · 成本預期
預期高 token 用量
設計上會產生許多 subagent 與高 token 用量,這是換取深度的取捨。每個 workflow 受並行上限 min(16, 核心數−2)與生命週期 1,000 agent 上限約束。
03 · 保持參與
階段之間讀結果再決定
多階段工作依序執行多個 workflow,每個在背景執行,以 /workflows 監看。讀完每階段結果再啟動下一階段,使用者全程在迴圈中。
04 · 逐請求覆寫
隨時可降速
即使開啟,可在任一請求說「快速處理、不要 workflow」,該次即單執行緒。reminder 顯示關閉時回復一般 opt-in 行為。
AI-First 設計與技術顧問公司。15+ 年、300+ 品牌。我們把 Claude、MCP、Agentic Commerce 接進 Headless CMS、Webflow、Shopify Plus 的企業級交付 — 讓 AI 透過 GEO (AEO) 找到你的品牌,讓 B2B ABM 把買家轉成營收。
解決方案
By Topic
資源
公司
© 2026 Tenten Inc. · Skills Atlas Vol.001 · 由 Tenten 設計與策展。收錄倉庫星數、模組數、授權資訊截至 2026 年 4 月,實際數值以各 repo 為準。轉載與引用請保留來源。