Plandex 能帮你完成什么工作
下面是根据工具能力整理的操作建议，输入、交付标准和人工核对由你确定。
场景 01 · 维护较大项目的开发者审阅跨文件重构方案
- 先准备
- 目标接口、调用方、约束和现有测试
- 怎么做
- 编辑建议：先加载必要上下文并讨论计划，再把修改积累到差异区，按调用关系审阅后应用。
- 得到什么
- 有计划依据的跨文件差异
- 使用建议
- 检查遗漏调用方、导入关系及相关测试，不把沙箱候选当成已应用代码。
查看操作流程示意
场景 02 · 需要评估设计方向的工程师比较两种实现思路
- 先准备
- 相同需求、约束及两种候选思路
- 怎么做
- 编辑建议：使用计划版本和分支分别探索，比较文件影响、复杂度和测试方式后再选择路径。
- 得到什么
- 可比较的方案记录
- 使用建议
- 确认使用相同输入，避免把模型差异与需求差异混在一起。
场景 03 · 能够管理 Docker 的团队评估本地部署条件
- 先准备
- 系统环境、模型账户和可用计算资源
- 怎么做
- 编辑建议：先阅读自托管路径和模型要求，限定测试项目并核对权限、网络及 API 消耗，再决定是否采用。
- 得到什么
- 自托管适配清单
- 使用建议
- Cloud 的关闭安排不等于自托管已运行成功；分别验证环境。
Plandex 软件界面
Plandex CLI 2.2.0 官方演示中的模型配置流程：运行 set-model 后选择编辑模型 JSON，再选择 Cursor、Vim、Nano 等编辑方式。
Plandex 是什么
它将候选修改放在累积差异审阅区，待开发者确认后再应用到项目。计划、上下文和模型组合是其工作流的重要组成部分。
此页按仓库保留的本地路径说明能力，不引导注册已停止接收新用户的云服务；自托管仍需要 Docker、模型服务和兼容环境。
Plandex 的主要功能
累积修改与项目文件分离
官方设计使用累积 diff 审阅沙箱，在修改准备好之前与真实项目文件分开。适合把多次模型修改合并阅读后再决定应用。
按任务组织大型项目上下文
通过项目地图和按需加载文件为每一步提供上下文，并使用 tree-sitter 处理项目结构；不需要把所有代码一次送入同一对话。
组合模型与控制执行程度
可选择来自不同提供方的模型组合，并在自主执行与细粒度确认之间调整工作方式，按任务平衡成本和检查强度。
保留计划分支和 Git 衔接
计划更新具有版本控制，并允许分支探索不同路径；还提供 Git 集成和可选自动提交，使用前应明确何时把修改写入仓库。
如何开始使用 Plandex
区分云端与自托管路径
先阅读仓库中的 Cloud 收尾说明，新评估以本地或自托管方案为前提。
准备运行环境与模型
按仓库说明确认 Docker、自有模型提供方凭据和系统条件；Windows 使用 WSL shell。
在项目中建立计划
进入目标项目目录，从小范围上下文开始讨论任务，再配置需要的自动化程度。
审阅累积差异再应用
对照计划和测试逐项检查候选修改，应用后再验证真实工作区与 Git 差异。
费用与使用条件
选择前了解
- 使用方式
- 命令行 / 私有部署
Cloud 已停止接收新用户；本地路径需要 Docker、模型账户，Windows 使用 WSL。
Cloud 不再接收新用户
官方仓库明确 Plandex Cloud 自 2025 年 10 月 3 日起收尾。此条件不能改写为所有本地代码已经无法运行，也不能省略后继续推荐注册云服务。
Windows 依赖 WSL
仓库说明仅在 WSL shell 下正确工作，不支持直接在 Windows CMD 或 PowerShell 使用同一流程。
自托管需要另备模型与服务
本地路径使用 Docker 或自有服务器，并接入自己的模型账户或 API Key；开源工具本身不包含这些服务的免费用量。
Plandex 常见问题
现在还能把 Plandex Cloud 当作新用户入口吗？
不能。官方仓库已说明 Cloud 收尾且不再接受新用户，应先评估本地自托管条件。
候选修改会直接覆盖项目文件吗？
其核心设计是先在累积差异审阅区保留修改，准备好后再应用；仍需了解所选自动化与命令执行配置。
Windows 可以直接用 PowerShell 跑吗？
仓库明确要求通过 WSL shell 使用，不能把 CMD 或 PowerShell 当成同等支持的入口。
自托管就没有模型费用了吗？
不能这样理解。自托管需要自有模型提供方账户或 API Key，实际用量条件由相应服务决定。
