手上那個要改幾十個檔案的任務，該不該交給 Plandex？

會冒出這個問題的人，通常已經在用 Claude Code，也通常剛被同一件事煩過：改動一多，你想要的是先把 AI 的修改全部堆在旁邊，看完整份 diff，再決定要不要寫進專案。Plandex 的 README 第一段就把自己定位在這裡，「terminal-based AI development tool that can plan and execute large coding tasks that span many steps and touch dozens of files」。它還宣稱能直接處理最多 2M tokens 的 context，再用 tree-sitter 做的 project map 索引 20M tokens 以上的目錄。

聽起來正好對症。可是要不要把一個工具放進每天的工作流程，看功能只看了一半。另一半是：這東西壞掉的時候，誰會修？

Plandex 我沒有安裝，沒跑過任何一個指令。下面的內容出自它的 README、六份官方文件、install.sh 的幾行，以及 2026 年 10 月 7 日用 GitHub API 查到的 repo 資料。

打開 repo，先看到的是收攤公告

plandex-ai/plandex 是 MIT 授權，2023 年 10 月 24 日建立。2026-10-07 查的時候有 15,701 顆星、1,176 個 fork，archived 是 false，看起來還活著。

往下翻 README 的 Hosting 表格，雲端那一格寫著：

Plandex Cloud: Winding down as of 10/3/2025 and no longer accepting new users.

倉庫最後兩筆 commit 都在 2025 年 10 月 3 日，一筆叫「updates for Plandex Cloud wind down beginning 10/3/2025」，一筆叫「link to cloud wind down post」。最後那筆改的就是 README、docs/docs/hosting/cloud.md 和 docs/docs/quick-start.md 幾行字。再往前一筆是 2025 年 7 月 16 日，也就是最後一個 release（cli/v2.2.1 與 server/v2.2.1）發布那天。

2025 年 7 月 16 日之後，倉庫只剩跟收攤有關的那兩筆。到 2026-10-07，離那次 push 剛好一年又四天。

收攤的原因寫在 README 連到的 https://plandex.ai/blog/winding-down，可是這篇讀不到。2026-10-07 12:26 UTC 對 8.8.8.8 查，plandex.ai、docs.plandex.ai、app.plandex.ai 三個網域回的都是 SERVFAIL，1.1.1.1 沒有回應紀錄。repo 裡的 docs/blog 也沒有存檔，只有 Docusaurus 自帶的範例文章。

所以「為什麼收」「開源版還會不會有人管」，答案都在一篇讀不到的公告裡，下面不替它猜。網域是過期還是 DNS 設定壞了，也沒查。

網域不通還有一個連帶影響。README 的安裝指令是 curl -sL https://plandex.ai/install.sh | bash，而 repo 裡的 app/cli/install.sh 第 66 行會去讀 https://plandex.ai/v2/cli-version.txt 拿版本號。二進位檔本身放在 GitHub Releases（同一支腳本第 10 行的 RELEASES_URL），但照這個寫法，網域不通的時候腳本拿不到版本。這是讀程式碼推出來的，腳本我沒跑。

它真正值得看的地方：改動先不落地

讀到這裡很容易直接關掉分頁。可是 Plandex 有一塊設計，比它現在的處境好太多。

預設情況下，AI 產生的改動不會直接寫進你的專案檔案，而是累積在一個受版本控制的 sandbox 裡。你用 plandex diff 看累積起來的整份差異（加 --ui 會開一個本機瀏覽器介面），不滿意就 plandex reject 退回，滿意才 plandex apply 一次套進去。

連要執行的指令也走同一條路。計畫可以把指令寫進一個特殊路徑 _apply.sh，它一樣先堆在 sandbox；執行失敗會 roll back，你可以選擇把錯誤送回模型自動除錯。plandex debug '<指令>' 預設最多重試 5 次，次數由 auto-debug-tries 調整。官方文件對執行指令的態度偏保守，原文是「It generally won’t, for example, run a test suite unless you’ve specifically asked it to」。

最值得細看的，是它把「AI 可以自己做多少事」拆成一條五格的刻度：

等級 在前一級之上多開的自動化 仍然要手動的
none 無，全部手動 指令執行停用
basic auto-continue、auto-build 其餘全部（文件註明等同 Plandex v1 的自治度）
plus smart-context、auto-update-context、can-exec、auto-commit apply、執行指令
semi auto-load-context（全新安裝的 v2 預設就是這級） apply（auto-exec 要到 full 才開）
full auto-apply、auto-exec、auto-debug 無

切換的方法有三種：plandex set-auto <level>、啟動時帶 --no-auto／--basic／--plus／--semi／--full，或在 REPL 裡打 \set-auto。不想照套餐走的話，set-config 可以逐項自訂。

這條刻度的好處，是把「信任」拆成可以分開給的小塊。你可以讓它自己載 context、自己 commit，卻保留「寫進檔案」和「跑指令」這兩個最後關卡。全新安裝的預設停在 semi，照矩陣一級一級往上疊，semi 也包含 plus 開的 auto-commit，所以 context 怎麼載、要不要 commit 都交給它；寫進檔案和真正跑指令那一下，還是你按。

官方文件對最右邊那格的警告寫得很重：

Be extremely careful with full auto mode! It can make many changes quickly without any prompting or review, and can run commands that could potentially be destructive to your system.

並建議開之前先確保 git 狀態乾淨、切到隔離的分支。

如果你只是想知道「漸進式授權」可以拆到多細，這份 autonomy.md 值得從頭讀到尾。

#369 打的就是這條刻度

整份設計的賣點就是那條刻度：每往右推一格，都是你自己決定的。issue #369 主張的，正是這個前提會失效。

#369 在 2026 年 9 月 23 日開，到 2026-10-07 還是 open、0 則留言。它主張的事情是這樣：apply 失敗後跳出來的選單裡有一個選項「Debug in full auto mode」，看起來像是「這一次用全自動模式除錯」，實際上會透過 server 端的 UpdatePlanConfig，把這個 plan 的 AutoMode 永久改成 full。影響範圍是該 plan 的所有 branch，以及之後的每一個 session。它還說 plandex apply --full 在背景也做了同樣的永久改寫。

如果這是真的，問題不在 full 本身危險，官方文件早就警告過了。問題在於你以為自己推了一格、而且只推這一次，刻度卻被整個撥到最右邊，然後停在那裡。一個以「授權分級」為核心的工具，分級在你沒察覺的時候失效，這比沒有分級更糟，因為你會照著「我現在是 semi」的假設繼續做事。

同一天還有一則 #367，作者是 GitHub 使用者 @Tardfyou。它主張 apply 和 rewind 用 filepath.Join(fs.ProjectRoot, path) 接上模型產生的路徑，接完卻沒檢查是否還在專案根目錄裡。路徑帶 ..，就能寫入或刪除專案外的檔案。它又說確認提示只顯示「Apply changes to N files?」這種檔案數量，看不到是哪些檔案；而明確下 plandex apply 指令時，會把 AutoConfirm 永久設成 true，之後連這個提示都跳過。

這兩則的證據等級要講清楚。#367 的作者自己標了「Verified statically against main @ e2d7720」，說明是離線讀程式碼的分析，沒有實際操作系統；#369 一樣是靜態分析。兩則都鎖在 commit e2d7720，也就是倉庫最後一次更動。我沒有重現任何一則，也沒去讀它們引用的那幾行原始碼。所以它們目前只是「有人提出、沒人回應」的主張，不是已確認的漏洞。

讓我在意的反而是「沒人回應」這一半。2025 年 10 月 3 日之後到 2026-10-07，倉庫新開了 50 筆 issue 加 PR；用 issues/comments?since=2025-10-04 撈到這段期間的 22 則留言，作者身分是 NONE 21 則、CONTRIBUTOR 1 則，OWNER 或 MEMBER 0 則。還開著的 issue 和 PR 加起來 66 筆，最新的 issue 是 9 月 28 日的 #372。

這組數字只能證明 GitHub 上看不到維護者的動作，證明不了他們在 Discord 或私訊裡什麼都沒做。不過對使用者來說，結果差不多：你如果碰上 #369 描述的狀況，沒有一個公開的地方能得到上游的答覆。

反過來問：什麼情況下它是壞選擇

第一種：你需要有人維護。團隊共用、要上正式環境、出了安全問題得有人修，這三種情況只要中一個，上面那組 0 則維護者留言就直接出局。MIT 授權讓你可以自己 fork、自己修，那 1,176 個 fork 裡有沒有人真的在接手維護，我沒有一個一個去看；就算有，你要評估的也變成那個 fork，不是 Plandex。

第二種：你不想自己架 server。Plandex 是 client-server 架構，CLI 跑在你的機器上，server 得自己用 Docker 架起來。本機模式的 quickstart 要求先裝好 git、docker、docker-compose，步驟是 git clone、進 plandex/app、跑 ./start_local.sh，再用 plandex sign-in 選「Local mode host」，預設連 http://localhost:8099。文件寫明這是「designed for local use with a single user」。雲端收了之後，這是唯一的路。

第三種：你在 Windows 原生環境。README 說它只支援 WSL，「doesn’t work in the Windows CMD prompt or PowerShell」。

第四種最容易被忽略：在你沒讀過的 repo 上開 full。#367 主張的路徑問題如果成立，模型產生的路徑就是攻擊面，而 prompt injection 正好是讓模型產生奇怪路徑的方法。這一條我沒驗證，但沒驗證正是重點：沒有上游會替你驗。

15,701 顆星很容易讓人覺得「這麼多人用，應該沒問題」。可是星數記錄的是過去的注意力，它不會因為維護者離開而減少。看到星數就放心，等於拿一年前的熱度替今天的狀態背書。

對 Claude Code 使用者，有一點特別誘人：Plandex 可以連你的 Claude Pro／Max 訂閱，首次啟動就會問，對應指令是 plandex connect-claude、disconnect-claude、claude-status。文件說在自架或自備金鑰的模式下，訂閱額度用完會切到你設好的備援 provider（Anthropic API、Vertex、Bedrock 或 OpenRouter），沒設就回 rate limit 錯誤，等額度重置。它也能組合 Anthropic、OpenAI、Google 和開源模型，用 model pack 切換取捨；自架時官方建議用 OpenRouter 金鑰。不用另外付 API 錢，聽起來很划算。但這只解決「用什麼模型」，解決不了「誰維護這個工具」。

那它到底適合誰？大概是這種人：你本來就想研究「改動先進 sandbox、授權分級」這套做法，想 fork 一份來改；你在 macOS 或 Linux 上跑 Docker 毫無負擔；你打算一直待在 none 到 plus 之間，apply 和執行指令都自己按；出了問題，你準備自己讀原始碼、自己修。

符合這幾條的人不多。

我會怎麼選

任何 AI coding 工具要放進每天的流程之前，先跑這兩行：

1
2
gh api repos/<owner>/<repo> --jq '{archived, pushed_at, license: .license.spdx_id}'
gh api repos/<owner>/<repo>/releases --jq '.[0] | {tag_name, published_at}'

pushed_at 和最新 release 的日期離今天超過一年，就去 issue 區看最近的留言是誰回的。這一步會比讀完整份 README 更快告訴你答案。

換成 Plandex，兩行吐回來的是 2025-10-03T21:49:58Z 的 pushed_at，和 2025-07-16 發布的 server/v2.2.1，都超過一年；2025 年 10 月 3 日之後的 22 則留言，前面算過，維護者 0 則。

所以如果你是 Claude Code 使用者，正在找第二個能扛大型多檔改動的主力工具，不要選 Plandex。GitHub 上出現維護者回應 #367 或 #369、出現 v2.2.1 之後的新 release，或那篇 winding-down 公告讀得到、而且明確承諾開源版會繼續維護，任一件發生，這個答案就值得重算。有人指出某個 fork 已經穩定接手的話也值得看，只是評估對象就換成那個 fork 了。

Plandex 的 autonomy.md 和 reviewing-changes.md 讀完，把它留在書籤裡，不要放進你的 PATH。

參考來源