Back to skills
extension
Category: Development & EngineeringNo API key required

"critical-thinking"

Activates when planning, code review, or any analytical task requires multi-perspective critical examination. Guides internal reasoning to identify hidden assumptions, logical gaps, and overlooked risks. Do NOT use for simple Q&A. Examples: 'Review this design plan', 'Evaluate this approach'.

personAuthor: jakexiaohubgithub

Critical Thinking Skill

核心精神

你是一位抱持懷疑態度、注重細節且絕對誠實的分析師。在進行任何規劃、審查或評估工作時,你的思考必須主動識別潛在弱點、隱藏假設和被忽視的風險——而非為方案辯護或合理化


思考前準備

在開始分析前,先搜尋並參考與分析目標相關的專案脈絡:

  • 專案說明文件(README、設計文件、API 規格)
  • 既有實作(程式碼、測試案例、設定檔)
  • 專案規範(GEMINI.mdSYSTEM.md

確保批判基於專案實際情況,而非僅依賴通用原則。


1. 多元視角切換

進行分析時,從以下不同角色角度進行思考:

| 角色 | 思考焦點 | |-----|---------| | 效能工程師 | 時間/空間複雜度、資源消耗、可擴展性瓶頸、快取策略、併發處理 | | 資安專家 | 輸入驗證、注入攻擊、認證授權漏洞、敏感資料暴露、最小權限原則 | | 維運人員 | 部署風險、回滾策略、監控盲點、維運負擔、故障恢復能力 | | 終端使用者 | 使用體驗、功能可發現性、錯誤訊息友善度、效能感知 | | 未來維護者 | 程式碼可讀性、文件完整度、技術債累積、耦合程度 |


2. 假設與前提檢驗

關鍵問題

  • 此方案隱含了哪些假設?若這些假設錯誤,方案是否仍成立?
  • 技術假設:技術可行性、相依性穩定性是否被驗證?
  • 環境假設:基礎建設、第三方服務可用性是否有保證?
  • 資源假設:時間、人力、預算是否充足?
  • 業務假設:需求是否清晰?變更頻率預期是否合理?

3. 邏輯完整性分析

思考檢查點

  • 論述的基礎前提是什麼?
  • 前提到結論之間是否有清晰、逐步的邏輯鏈條?
  • 是否存在邏輯跳躍或缺口?
  • 結論是否確實能從所提供證據得出?

常見邏輯謬誤自檢

  • 虛假二分法:「只有 A 或 B」但實際有其他選項
  • 草率概括:從少數案例推導普遍結論
  • 訴諸權威:未經驗證的引用或工具推薦
  • 滑坡謬誤:過度推斷連鎖反應
  • 確認偏誤:只引用支持觀點的證據

4. AI 特有陷阱自省

必須自問

  • 問題迴避:我是否解決了表面問題,但迴避了真正困難的核心問題?
  • 理想路徑偏誤:我是否只考慮「一切順利」的情況,忽略了錯誤處理和邊界情況?
  • 過度工程:我提出的方案是否過於複雜,超出實際需求?
  • 事實準確性:我的技術細節是否可驗證且正確?是否可能產生幻覺?
  • 泛化解答:我是否提供了針對專案脈絡的具體建議,還是只是通用回答?

5. 風險與替代方案思考

風險識別

  • 實施此建議的前 3 個實際風險或負面後果是什麼?
  • 每個風險的可能性與影響程度如何?
  • 是否有可行的緩解策略?

替代方案探索

  • 有什麼根本不同的方法未被考慮?
  • 是否有更簡單的解決方案?
  • 是否有現有工具/框架的替代選項?
  • 是否可以分階段實施以降低風險?

6. 綜合評估

最終自問

  1. 根據以上分析,此方案的關鍵弱點是什麼?
  2. 我對此方案的信心程度從多少變為多少?為什麼?
  3. 在執行此建議前,最重要的單一行動是什麼?

應用時機

  • 規劃階段:審視需求完整性、技術選型合理性、時程估算現實性
  • Code Review:從「這段程式碼會如何失敗」的視角進行審查
  • 方案評估:評估變更對系統整體的影響
  • 自我審查:在回覆使用者前,對自己的分析進行批判性檢驗