InPlan 交互式规划编辑器
先与编码智能体共同定稿可审查的 Markdown 计划，再开始实现。
- Star 数
- ★ 23
- 最近更新
- 29 天前
- License
- AGPL-3.0
- 主语言
- TypeScript
- FA 评分
- 81/100 · 表现良好
30 秒速览
- 可在哪里用
- 通用 · 跨平台Claude CodeCodex（部分支持）
- 开始前需要
- 典型场景
- 准备重写认证系统的开发者，可先让编码智能体起草需求、迁移边界和待确认问题，再逐项审阅后实施。
- 主要局限
- 需要 Node.js 22 或更高版本，并依赖本地 shell、文件系统和能够执行 CLI 的编码智能体。
- 源码审查
- 81/100 · 表现良好
这个 Agent 能做什么，适合哪些场景？
InPlan 是一个面向人类与编码智能体协作的 Markdown 规划工作区，目标是在写代码之前把模糊需求收敛为版本化规格。仓库由 `@inplan/core`、`@inplan/cli` 和 `@inplan/app` 三部分组成，分别提供可嵌入的编辑及计划格式逻辑、智能体侧命令，以及面向人的 Electron 桌面编辑器。编码智能体通过随包安装的 skill 和 `inplan open`、`inplan wait`、`inplan signal` 等命令驱动协作循环；用户则在编辑器中回复行内评论、选择答案或直接修改正文。最终产物是普通 Markdown 文件，其中评论保存在一个尾部 HTML 注释内的 JSON 数组中，因此可由 Git 跟踪并在代码审查中查看差异。项目提供可自行运行的开放核心以及托管版 inplan.ai，但当前主要在 macOS、轮次模式和 Claude Code 组合上开发与测试。
智能体先创建 <name>.plan.md，在 Markdown 正文中编写需求结构，并用形如 [文本](#cmt-id) 的链接标记评论范围；评论、回复、文档级评论和选择题数据统一存入文件末尾的 <!--inplan ... --> JSON 块。随后它运行 inplan open <file> 打开桌面编辑器并等待用户操作。用户可以回复评论、选择选项或直接编辑计划，并选择 Auto-accept 或 Review、Turn 或 Instant 工作方式。智能体读取这些修改，修订计划并继续讨论；inplan wait <file> 用于等待下一次操作，inplan signal <file> --done 用于建议计划已就绪，但最终决定仍由用户作出。编辑器把控制日志、规范基线和备份存放在 ~/.inplan/sidecars/<key>，而可提交、审阅和传递给实现阶段的输出仍是 Markdown 计划文件。
- 准备重写认证系统的开发者，可先让编码智能体起草需求、迁移边界和待确认问题，再逐项审阅后实施。
- 需求仍有歧义的工程团队，可在同一份 Markdown 计划中通过行内评论记录答案、理由和后续修订。
- 需要控制智能体改动的资深工程师，可启用 Review 和 Turn 模式，在每轮计划变更后检查差异。
- 希望提高快速原型可追溯性的个人开发者，可把临时对话转化为能够进入 Git、长期保留的版本化规格。
- 产品经理、开发者与架构师需要共享实施依据时，可围绕同一计划分别补充需求、实现细节和架构决策。
- 受限网络、隔离环境或源码开发场景中的团队，可运行开放核心，并通过环境变量文档调整启动与 sidecar 路径。
如何安装或部署这个 Agent？
前提是 Node.js 22 或更高版本。常规安装：npm install -g inplan，然后运行 inplan --version 验证。该安装会提供 inplan 命令、由 inplan open 启动的桌面编辑器，并尝试为检测到的 Claude Code、Pi 和 Codex 安装 agent skill；如需跳过自动安装，可设置 INPLAN_NO_SKILL_INSTALL=1，之后运行 inplan install-skill。从源码开发时执行：git clone https://github.com/melly-lgtm/inplan.git，cd inplan，npm install，npm run build。源码检出环境可用 INPLAN_APP_CMD 指向构建后的 @inplan/app，或通过 npm run dev -w @inplan/app 单独运行编辑器。
如何使用这个 Agent？
安装后，用自然语言要求受支持的编码智能体规划具体工作，例如“Plan the auth rewrite with me.”。skill 会让智能体创建 <name>.plan.md，调用 inplan open <file> 并在文档中提出行内问题。你在桌面编辑器中回复评论、选择 choice chip 或直接修改文本，然后审阅智能体下一轮修订。底层命令包括 inplan open <file>、inplan wait <file> 和 inplan signal <file> --done。如果没有自动检测到智能体，可让它读取随包提供的 skill/SKILL.md，前提是该智能体能够执行 inplan CLI。
这个 Agent 有哪些优点和局限？
- 计划、评论和决策记录保存在同一个可读的 Markdown 文件中，可由 Git 版本化并像代码变更一样审阅差异。
- 同时提供自动接受与逐项审阅、轮次与即时模式，可按风险选择不同的人类监督强度。
@inplan/core、CLI 和 Electron 应用边界明确，既能使用打包桌面体验，也为嵌入或源码运行提供基础。- 通过 skill 和 CLI 串联 Claude Code、Codex 与 Pi，而不是把规划流程绑定到单一模型提供商。
- 需要 Node.js 22 或更高版本，并依赖本地 shell、文件系统和能够执行 CLI 的编码智能体。
- 目前主要开发和测试组合是 macOS、Turn 模式和 Claude Code；Windows、Instant、Codex 与 Pi 仅轻度验证，可能存在粗糙环节。
- 评论采用专用的 Markdown 链接及尾部 JSON 注释格式；其他编辑器虽然能显示正文和差异，但未必理解其交互语义。
- 采用 AGPL-3.0-or-later 开源许可；希望用于专有产品或不受 AGPL copyleft 约束的 SaaS 团队需要另行取得商业许可。
- 安装过程会检测并写入编码智能体的 skill 与 hooks；不希望自动修改这些环境的用户需要设置
INPLAN_NO_SKILL_INSTALL=1。
这个 Agent 与同类方案有什么区别？
相较于只依赖线性聊天记录的编码流程，InPlan 把需求、问题、回答和修订集中到一份可版本化的 Markdown 规格中，并提供类似文档评论与代码审查的差异确认机制。它并非代码生成模型的替代品，而是位于人类与现有编码智能体之间的规划和决策层。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|
| InPlan 交互式规划编辑器 当前 | 81 · 表现良好 | ★ 23 | 29 天前 | TypeScript | Claude Code |
| Pilot Shell | 53 · 缺口较多 | ★ 2.1k | 5 天前 | JavaScript | Claude Code |
| Agent Skills — 生产级工程技能包 | 71 · 存在缺口 | ★ 99k | 1 天前 | JavaScript | Codex · Claude Code · OpenAI API |
| Ateam 多智能体开发工作台 | 70 · 存在缺口 | ★ 12 | 8 天前 | TypeScript | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示 CI 工作流仅授予 contents: read，检出时禁用凭据持久化；遥测须用户选择加入，并使用一次性标识且禁止建立个人档案；无令牌时不会访问本地化云端接口。Review 模式、提案 diff、用户最终决定以及集中保存的规范副本和备份，为确认与恢复提供了充分机制，因此 user_confirmation 和 rollback 可获满分。扣分点是全局安装会自动探测并向多个代理目录写入 skill，外部影响虽有说明但默认仍较广；README 未完整列出遥测端点、事件字段、令牌及云端本地化的数据流；敏感数据证据集中于令牌门控和匿名遥测，未见全面的数据保留、加密或凭据生命周期说明。依赖方面有锁文件一致性检查、固定提交的 GitHub Actions 和发布密钥构建门禁，但未提供漏洞扫描、依赖审计或关键依赖风险处置证据。许可证、公司联系地址和作者字段提供归属线索，但发布者身份未经企业注册验证，维护主体及来源链并未完全确立。
README 描述的工作流、文件格式、Review 行为、离线降级和会话事件处理均得到所给测试或 CI 配置的直接呼应，自洽性充分。依赖可用性方面明确要求 Node.js 22，并为无令牌、云端不可达、提案查询失败以及源代码运行提供降级路径；但 Electron 二进制在 CI 中被刻意跳过，部分本地化依赖云服务，而且非主要平台和代理仅轻度验证，因此扣分。失败处理测试覆盖网络失败、缺少目录状态、竞态和锁查询失败，不过用户可见错误信息与恢复指引的覆盖证据有限，不能评为彻底。
项目清楚面向需要与编码代理共同完善需求的开发者和团队，解释了起草、评论、审阅、接受及构建等具体场景。能力边界写得明确：它是 Markdown 规划编辑器和 CLI，不是自主实现器；支持矩阵还区分主要支持和轻度验证的代理、操作系统与节奏模式。环境变量、无头模式、自托管路径、CI/受限网络说明以及纯 Markdown 格式体现出较强环境适配。触发规则仅概括为任何“plan X”请求，且实际 skill 内容未提供，无法确认歧义处理、排除条件或复杂意图的触发精度，因此扣分。
README 的安装、快速开始、内部机制、文档格式、兼容性、项目状态和许可结构清楚；命令、包名、文件后缀及事件概念保持稳定，并给出可操作示例。Node 版本、npm 安装、源码构建、跳过自动 skill 安装和开发模式均有具体说明。限制部分明确承认主要在 macOS、Turn 模式和 Claude Code 上测试，值得满分。许可证正文和双许可说明完整。扣分在于没有真正的 FAQ，疑难排查示例有限；虽然有 npm 版本徽章和锁文件版本防漂移检查，但未提供 changelog、发布节奏或兼容性政策；贡献入口和商业许可联系人存在，但未经验证的发布者身份以及缺少明确维护者名单、支持承诺和更新责任界定，使维护责任只能评为部分充分。
输出是可移植、可渲染、可进行 Git diff 的 Markdown，并将评论、回复、问题和选择保存在文档内；Review 提案、规范基线和备份机制使产物直接可用于后续实现，因此 output_usability 充分。相较线性聊天，版本化计划和内联决策记录具有可信的增量价值，但关于更安全重构、更少漂移和显著提高正确率的量化主张只在 README 中概述并链接到未提供的外部文章，现有材料不能完整验证。安装路径简短且通常无需配置，但需要 Node 22、全局 npm 包、Electron 桌面组件，并可能涉及云端功能和 AGPL/商业许可权衡，所以成本收益并非无条件充分。
多个具体行为可追溯到测试：遥测选择加入与匿名属性、本地化令牌门控及离线缓存、提案基线、竞态保护、保存状态和 CI 发布密钥门禁。README、测试与工作流对核心架构和安全机制形成较强交叉印证，因此 cross_source_corroboration 可获满分。扣分是若干高层效果和性能主张没有随附实验数据、实现文件或本仓库测试；提供的证据也未包含实际 skill、环境变量文档、CLI 实现和完整发布材料。项目对“aims”、主要测试环境和轻度验证状态有明确措辞，但部分营销性因果结论仍未清楚区分已证明事实与预期效果。
- 全局安装默认会探测 Claude Code、Codex 和 Pi，并向检测到的代理目录安装 skill；受管控环境应设置 INPLAN_NO_SKILL_INSTALL=1，并先审查 skill 内容。
- 选择加入遥测后会向 PostHog 端点发送事件名及操作系统、Electron 运行时等聚合属性；尽管测试显示使用一次性标识，部署前仍应核对实际构建配置和隐私要求。
- 非英语本地化会使用登录令牌访问 inplan.ai，并在本地缓存目录保存目录数据；源材料未完整说明令牌存储、保留期或服务端处理。
- Windows、Instant 模式、Codex 和 Pi 被明确标为轻度验证，不应按主要 macOS、Turn、Claude Code 路径的成熟度来假定。
- AGPL-3.0-or-later 与商业双许可可能影响专有分发或 SaaS 使用；采用前应审阅 LICENSING.md 和适用义务。
- 本评估仅基于所给静态片段，未执行程序、测试或依赖漏洞检查。
常见问题
它可以完全在本地运行吗？
是否必须使用 Claude Code？
inplan CLI 的智能体参与。不过 Claude Code 是主要开发和测试目标，Codex 与 Pi 目前仅轻度验证。计划和评论存在哪里？
.plan.md 文件中；评论数据是尾部 HTML 注释中的 JSON 数组。控制日志、规范基线和备份则集中存放在 ~/.inplan/sidecars/<key>。商业或 SaaS 产品能否直接采用？
如果桌面编辑器无法启动会怎样？
INPLAN_APP_CMD 指向构建后的 @inplan/app；否则 CLI 会以 headless 方式运行。也可执行 npm run dev -w @inplan/app 单独启动编辑器。