一、导读
2026 年 11 月 15 日，GitHub 日榜上出现了一个当日涨星 860 的项目：backnotprop/plannotator。它不生成代码、不做推理、也不当编排器——它只做一件事：把编码智能体（coding agent）产出的计划、规格文档、HTML 原型与代码 diff，摊在一个可以在浏览器里逐段标注的界面上，再把你标注的结果原路送回给那个智能体。本文要回答三个问题：它凭什么在一天里涨 860 星？它那套「宿主适配层 / 本地服务器层 / 可复用 UI 层」的三层架构，是怎么把「十种 agent、四套命令语法」的适配负担收进一个仓库的？以及它在真实工程里到底能替代哪一步、不能替代哪一步。核心结论先说：它卖的不是功能，是节奏——把「等你看的东西」集中到一个面，把「你的意见」集中到一条回路。
二、项目速览
| 项目 | 内容 |
|---|---|
| 仓库 | backnotprop/plannotator |
| 作者 | backnotprop（单人主导，累计 8,959 次提交） |
| 主语言 | TypeScript |
| Star 总数 | 11,777（2026-11-15 抓取） |
| 当日涨星 | 860（2026-11-15 日榜） |
| License | Apache-2.0 或 MIT 双许可（由使用者择一） |
| 首次发布 | 仓库创建于 2025-12-28 |
| 最新版本 | v0.28.65（2026-11-15 发布） |
| 代码规模 | 7,183 个文件；13 个 packages + 27 个 apps |
有一处待确认的历史信息需要提前说明：部分第三方聚合站点至今仍把该项目标注为「Business Source License 1.1（BSL）」。但截至 2026-11-15，仓库根目录同时存在 LICENSE-APACHE 与 LICENSE-MIT，README 明确写着「Dual-licensed under Apache 2.0 or MIT at your option」。可以判断 BSL 是早期版本的许可，后来已变更。
三、为什么是它：问题背景与定位
过去两年，编码智能体从「一个」变成了「十几个」：Claude Code、Codex、Copilot CLI、Gemini CLI、OpenCode、Kiro、Droid、Amp、Pi、DeepSeek Harness，再加上 Qwen Code、Mistral Vibe、Cline、Hermes、OpenClaw 等。每一个都有自己的命令语法、自己的配置目录、自己的脾气，以及一个共同的假设——你应该住在它的终端里。
问题不是 agent 不够强，而是它们产出太多了。一个 agent 跑完，丢给你一份计划、一份规格、一个 HTML 原型、一个 diff；十个 agent 跑完，你面前堆着几十份东西，每一份都等着你说「行」或者「不行」。于是出现了这个行业最荒诞的一幕：我们发明了一堆替你干活的工具，然后被它们的产出淹了。瓶颈从「写代码」挪到了「人点头」这一步，而且这一步比写代码更硬——代码可以并行，点头不能。
Plannotator 的定位就卡在这里。它不试图让 agent 更聪明，它试图让你别被踢出循环。它做的事情非常窄：把 agent 想给你看的东西，摊在一个可以标注的界面上，然后把你标注的结果原路送回去。它填的是一个很具体的坑：agent 的输出，不适合在终端里审。终端是给「一行行往下滚」的东西准备的；而一份计划有层级、一份规格有段落、一个 HTML 原型有布局。你没法在终端里指着第三段的第二句话说「这里不对」，浏览器可以。
从涨星动因看，2026 年 11 月这波增长有三个可观察的推力。第一，v0.28.x 系列在 11 月 9 日至 11 月 15 日之间连发了十个版本（v0.28.56 到 v0.28.65），把 Inbox、Guided Reviews、Windows 支持、Claude Code 插件自更新等功能密集落地——GitHub 统计的 52 周提交总量为 9,115 次，而最近四周分别是 576、1,677、2,992、2,192 次，明显处于加速段。第二，它把「多 agent」这个正在爆发的场景做成了产品叙事：Inbox 面同时服务编码 agent 与个人助理（Grok Bot、Muse、Hermes、OpenClaw）。第三，2026 年 6 月 11 日在 Hacker News 的 Show HN 帖、以及后续多次「What are you working on?」线程里的自发推荐，为它积累了持续的外部曝光——第三方统计称其在 5 个来源的 61 次提及中正面评价占 84%（数据来源：rightaichoice.com，2026-11-15 抓取，第三方口径，待确认）。
四、架构原理
Plannotator 的架构可以概括为一句话：一个仓库、三层复用、两种宿主运行时。
4.1 整体架构
┌──────────────────────────────────────────────────────────────┐
│ 宿主适配层 apps/*-plugin, apps/codex, apps/gemini, ... │
│ Claude Code / Codex / Copilot / Gemini / OpenCode / Pi / │
│ Amp / Droid / Kiro / Qwen / Vibe / Cline / Hermes / OpenClaw │
│ 职责：把各家 hooks / 插件 / 斜杠命令 / MCP 工具翻译成统一调用 │
└───────────────────────────┬──────────────────────────────────┘
│ 统一契约（stdin JSON / 事件 / 工具调用）
┌───────────────────────────▼──────────────────────────────────┐
│ 本地服务器层 packages/server (688 文件) + packages/shared │
│ plan / review / annotate / goal-setup / inbox 五类服务器 │
│ 随机端口 + 单文件 HTML 应用（openPackedApp 从内存应答） │
│ 决策出口：/api/approve、/api/deny、/api/feedback │
└───────────────────────────┬──────────────────────────────────┘
│ HTTP + 同源守卫
┌───────────────────────────▼──────────────────────────────────┐
│ 可复用 UI 层 packages/ui (1,101 文件) + packages/editor │
│ + packages/core (209 文件，浏览器安全的纯工具与类型) │
│ 通过 configurePlannotatorUI() 一次性注入宿主后端 │
└──────────────────────────────────────────────────────────────┘
三个 packages 的规模很能说明分层意图：packages/ui 1,101 个文件、packages/server 688 个、packages/shared 616 个、packages/core 209 个。UI 层比服务器层还大，是因为它把 Markdown 渲染、主题、标注编辑器、设置、评论、布局全部做成了可安装的构建块——README 给出的理由是：商业版 Workspaces 需要同一套文档体验，但要接自己的存储、鉴权、实时与 AI。与其 fork 或重写，不如让 Workspaces 安装这些包、插上自己的后端。这也是 packages/ui/README.md 里那段近乎警告的话的由来：「复用文档 UI 前，先读这份 README」——它记录了历史上一次「从零重写 UI」的事故，最后被回滚。
4.2 分层模块拆解
第一层：宿主适配层（apps/）。 27 个 apps 目录里，apps/hook（228 文件）是 Claude Code 插件与 CLI 入口，apps/pi-extension（168 文件）是 Pi 扩展，apps/opencode-plugin（78 文件）是 OpenCode 插件，apps/vscode-extension（162 文件）是 VS Code 扩展，其余是 Amp、Droid、Kiro、Qwen、Vibe、Cline、Hermes、OpenClaw 等薄适配。这一层的关键设计是统一契约：不管宿主是谁，最终都要落到同一组 stdin JSON 事件与同一组 HTTP 决策端点上。
以 Claude Code 为例，经典路径是 PermissionRequest 钩子拦截 ExitPlanMode：钩子从 stdin 读到 tool_input.plan，启动服务器、打开浏览器，用户决策后往 stdout 写：
{"hookSpecificOutput":{"decision":{"behavior":"allow"}}}
{"hookSpecificOutput":{"decision":{"behavior":"deny","message":"# Plan Feedback\n..."}}}
而 OpenCode、Pi、DeepSeek Harness 走「工具调用 + 事件回调」路径：Pi 扩展注册 plannotator_submit_plan 工具，OpenCode 插件拦截 submit_plan 并处理 review/annotate 事件。
第二层：本地服务器层（packages/server + packages/shared）。 五类服务器共用一套静态资源应答逻辑：没有处理器认领的路由返回单页应用；/assets/ 下的名字返回打包在页面背后的分块，从内存读取、无文件系统路径、带内容哈希的不可变缓存、nosniff 与同源 CORP，其余名字返回 404。计划服务器的核心端点包括 /api/plan（返回 plan、origin、previousPlan、versionInfo、approvalNotesSupported）、/api/plan/version、/api/plan/versions、/api/plan/revision、/api/approve、/api/deny、/api/save-notes。其中 /api/plan/revision 配合 planRevisions: true 选项，让「评审还开着、agent 又改了计划」变得可处理：/api/approve 与 /api/deny 会拒绝过期的 planRevision，返回 409 { code: "plan_revised" }。
第三层：可复用 UI 层（packages/ui + editor + core）。 这一层通过一个函数完成宿主注入：
import { configurePlannotatorUI } from "@plannotator/ui/configure";
configurePlannotatorUI({
storageBackend, // 设置持久化到哪
identityProvider, // 当前用户是谁
draftTransport, // 草稿怎么存
externalAnnotationTransport, // 实时/agent 评论
aiTransport, // AI 调用怎么走
skillCatalogTransport, // 评论器里的技能目录
serverSync,
webmcp, // 浏览器智能体（WebMCP）策略
// ... 共三十余个可选项
});
每个「UI 与后端对话的地方」都是一个可选 seam，默认行为就是 Plannotator 自己的行为。Plannotator 本身不传任何 seam，行为与从前完全一致。这是典型的「宿主覆盖缝」模式：把差异点收敛成显式的注入点，而不是靠分支散落在代码里。
4.3 核心机制与算法原理
机制一：Plan Diff 与版本链。 每次计划提交都会在 ~/.plannotator/history/{project}/{slug}/ 下留一份版本文件，slug 由「标题 + 日期」推导；annotate 模式改用文件路径哈希（annotate-{sanitized-basename}-{hash8}），这样同一个文件即使标题变了也能归到同一条版本链，完全相同的重复提交会被去重。这里有一个值得单独说的工程细节：项目归属的解析。{project} 取 git toplevel 的 basename，从 CLI 的 cwd 读取；但 shell 里的 cd 会让 cwd 漂移，所以对 Claude Code 还额外参考会话根目录——mod 每会话读一次 $.session.root() 并通过 stdin 的 projectRoot 传下去，经典钩子则用 CLAUDE_PROJECT_DIR。resolveHistoryChain() 先按 cwd 的项目解析、再按根目录的项目解析，取第一个已经有版本链的，否则在 cwd 项目下开新链。结果是：在根目录开始、在嵌套 clone 里重新提交的计划能延续同一条链，而新计划落在哪不受影响；两个 clone 的同名计划永远不会被合并。
机制二：AES-256-GCM 的零知识分享。 分享分两条路。小计划（Markdown）直接压进 URL fragment——fragment 不会随请求发给分享门户，但未加密，任何拿到完整链接的人都能读。大计划与原始 HTML 走短链服务：先在浏览器里压缩（CompressionStream('deflate-raw') + base64url），再用一次性 AES-256-GCM 密钥加密，密钥留在 URL fragment 里、从不发给服务器，服务器只存密文，托管粘贴 7 天后过期。packages/core/crypto.ts 的实现很短，值得看它的字节布局：
const iv = crypto.getRandomValues(new Uint8Array(12));
const encrypted = await crypto.subtle.encrypt({ name: 'AES-GCM', iv }, cryptoKey, plaintext);
// 布局：base64url(IV || ciphertext+tag)，密钥单独 base64url(32 字节)
const combined = new Uint8Array(iv.length + encrypted.byteLength);
combined.set(iv, 0);
combined.set(new Uint8Array(encrypted), iv.length);
这套模型与 PrivateBin 同构，且粘贴服务本身可自托管；PLANNOTATOR_SHARE=disabled 可以整体关掉分享。
机制三：决策控制器的纯函数化。 计划评审头部的「Approve / Send Feedback」不是散落的 if-else，而是从一个纯函数推导出来的：
buildDecisionSpec({ app: 'plan', plan: { answers, directEdits, answersOnly, agentName, approveTarget } })
它决定当前该显示「Approve」还是「Send Feedback」、caret 里有哪些项（「Approve with a note…」「Request changes…」「Approve, discard N annotations…」），以及哪些项因宿主不支持而被隐藏。哪些宿主支持「批准时带备注」这件事，也不是按 agent 名字硬编码，而是服务器在 /api/plan 里广告一个 approvalNotesSupported 布尔值：Claude Code mod、OpenCode 桥、DeepSeek Harness 桥、Pi 会话都置 true；经典 Claude Code 钩子（它的 allow 不带 message）、Gemini CLI（systemMessage 只给人看）、Qwen Code（它忽略钩子对 exit_plan_mode 的 allow）、Codex、Copilot CLI、Mistral Vibe 与 archive 模式都置 false。用一个显式的服务器广告代替隐式的名字判断，是这个项目里反复出现的取舍模式。
4.4 性能优化手段与设计取舍
取舍一：单文件 HTML + 内存应答，而不是静态文件目录。 四类服务器都把前端打成一个单文件应用，/assets/ 下的分块从内存里按名字取出。代价是构建顺序变得敏感——bun run build:hook 会拷贝 apps/review/dist/ 里预构建的 HTML，所以改了 packages/ui、packages/editor、packages/review-editor 之后必须先重建 review 应用再构建 hook。收益是：没有文件系统路径暴露、没有目录穿越面、缓存头天然正确。
取舍二：设置存在 Cookie 而不是 localStorage。 README 给的理由很短但很实在：每次钩子调用都跑在一个随机端口上，localStorage 按 origin 隔离，随机端口意味着每次都是新 origin。Cookie 能跨端口共享，所以设置放 Cookie。
取舍三：远程模式默认全接口监听且无登录。 检测到 SSH 会话时自动切到固定端口 19432；PLANNOTATOR_REMOTE=1 可手动开。README 的措辞非常直白：远程模式下服务器监听 0.0.0.0 且没有登录，「任何能访问该端口的人都能用它，即使你用了 SSH 隧道」。
取舍四：版本迭代极快，稳定性靠可验证性补。 11 月 9 日到 15 日之间发了十个版本。项目的应对是把可验证性做厚：每个发布的二进制都带 SHA256 sidecar；SLSA 溯源证明从 v0.17.2 起提供；当前发布流程还会附一份 CycloneDX JSON SBOM，用全新的 Grype 数据库评估后才发布。README 还坦白了一个罕见局限：SBOM 是「发布级」清单，不是精确的逐二进制运行时清单。
4.5 与其他架构路线的差异
同样是「让人审 agent 产出」，业界至少有四条不同路线。第一条是终端内审（Herdr Annotate、Plannotator TUI 等），它和 Plannotator 的主张正好相反：不回浏览器，就在终端里标；Plannotator 自己也提供了这条路径，并且让终端标注与应用标注存在同一个数据目录里，两种审阅会累积成一条连续的讨论。第二条是托管式 PR 评审（CodeRabbit 一类），它审的是已经推到远端的 PR，优势是团队协作与审计记录成熟，劣势是它出现在 PR 之后，而 Plannotator 最有差异化的位置恰恰是 PR 之前、agent 会话还开着的时候。第三条是计划生命周期管理（Flanner 一类）：Flanner 在计划「值得留下」之后接管，给计划在仓库里安家、每个修订成为版本、拿计划去比对 git 历史判断是否 stale。第四条是持久化执行/编排平台（Temporal AI 一类），它解决的是长时工作流的可靠性与状态管理，与「审阅面」完全不是一个问题。
Plannotator 的架构选择，本质上是把赌注押在「本地优先 + 宿主无关 + 反馈闭环」这三点上：本地优先换来隐私与零后端依赖，宿主无关换来跨十个 agent 的覆盖面，反馈闭环换来「标注不是终点、而是下一轮 agent 的输入」这一核心价值。
五、应用场景
场景一：在「计划批准」这一步做真正的评审
业务痛点。 计划模式的结尾通常只有两个选择：批准一屏终端文本，或者用一段自由文本拒绝。当 agent 要改的是认证逻辑、数据库 schema、部署配置或仓库的一大块时，「我有点担心」这种反馈太模糊，agent 只能猜。
如何用它解决。 计划结束时 Plannotator 在浏览器里打开一份文档式评审面：选中文字加评论、标删除、写替换文本、逐段请求修改。计划被修订后，同一标签页更新到新版本，你的评论还在；Plan Diff 显示这一版与上一版的差异。
最小可用示例（Claude Code，可复现）。
curl -fsSL https://plannotator.ai/install.sh | bash
# 在 Claude Code 中：/plugin marketplace add backnotprop/plannotator
# /plugin install plannotator@plannotator
# 重启 Claude Code，进入计划模式；Claude 调用 ExitPlanMode 时自动打开评审面
收益与量化指标。 官方文档给出了一条可测量的行为差异：在 Claude Code 2.1.287 及以上的交互式终端里，「mod」默认开启——Claude 不会等你，它结束当前回合，你的决策稍后作为一条消息到达会话。这意味着评审期间你可以继续和 Claude 对话，也可以关掉终端（用 claude --continue 恢复会话后决策仍会送达）。旧版 Claude Code、claude -p 与 SDK 运行、Windows、或关掉 mod 时，钩子会挂住 ExitPlanMode，Claude 一直等。
适用边界。 小改动不值得为它加一层评审仪式；一份打磨得很漂亮的计划仍然可能描述一个糟糕的实现——Plannotator 改善的是评审面，不是替你验证计划。官方也明确：批准控制的是当前 agent 会话，它不识别评审人、不创建共享授权记录。
场景二：PR 之前的本地代码评审，把反馈直接送回会话
业务痛点。 本地 agent 改完代码，git diff 能看但不好评；推到远端开 PR 再评，又错过了「会话还开着、agent 还能立刻改」这个窗口。
如何用它解决。 /plannotator-review 打开浏览器 diff 查看器，支持相对基线的全部改动、已暂存/未暂存/未提交、单个提交与分支对比、本地 worktree、GitHub PR 与 GitLab MR、堆叠改动（layer 与 full-stack 视图）、Git/Jujutsu/Perforce 仓库，以及行内、token 级、文件级与全局评论。
最小可用示例（可复现）。
/plannotator-review # 本地未提交改动
/plannotator-review https://github.com/owner/repo/pull/123 # 远端 PR
plannotator review --gitbutler # GitButler 工作区
plannotator review --patch-file reading.diff # 静态统一 diff
收益与量化指标。 这一流程把「评审 → 反馈 → agent 修改」压成一个循环，而不必等 PR 创建。官方文档说明内置评审 agent 是只读运行、不会自动发评论——你去决定留哪些发现、什么时候发反馈。这一点很重要：AI 层是可选建议，责任仍在人。
适用边界。 如果你的团队已有成熟的 IDE + PR 评审流程、且本地没有评审空缺，这个场景的边际价值有限。另外，官方明确 Approve 返回的是配置好的代码评审批准消息，它不会提交、合并或部署。
场景三：把任意文档与 URL 变成可标注的上下文
业务痛点。 你最想吐槽的往往不是仓库里的文件，而是 agent 刚在对话里写的那三百字，或者一份外部规范文档。终端里你只能回一句「不对，重来」，它还得猜哪里不对。
如何用它解决。 /plannotator-annotate 接受文件、目录、URL 或原始 HTML；/plannotator-last 直接标注 agent 的上一条消息。
最小可用示例（可复现）。
/plannotator-annotate README.md # 本地 markdown
/plannotator-annotate src/ # 浏览并标注文件夹
/plannotator-annotate https://docs.rs/... # 抓取并标注 URL
/plannotator-annotate report.html --render-html # 按原样渲染 HTML
/plannotator-last # 标注 agent 上一条消息
收益与量化指标。 文件解析不再要求精确路径：依次尝试精确匹配、大小写不敏感的相对路径、以及跨项目的裸文件名搜索；裸文件名有歧义时列出全部候选让你选，node_modules/、.git/、dist/ 等目录被排除。
适用边界。 需要留意 --render-html 这个开关的存在理由：默认行为是把 HTML 转成更适合标注的形态，这对长文档是对的，但对原型是灾难——把带布局、带交互、带状态的页面转成文本，等于把要审的东西审没了。这个开关等于承认了「审文字」和「审界面」是两种不同的审阅。另外，标注模式会在 ~/.plannotator/history/ 下写入每个被标注文件内容的副本；PLANNOTATOR_ANNOTATE_HISTORY=0 可关掉（代价是版本 diff 与提交反馈记录一并失效）。
场景四：多 agent 并行时，用一个 Inbox 收拢「在等你决定的事」
业务痛点。 多 agent 工作最难受的不是某个 agent 不听话，而是你不知道现在该看哪个。谁在等审批、谁跑完了、谁跑歪了，全靠你在脑子里维护一张表，而这张表总会漏。
如何用它解决。 Inbox 是每台机器一个长驻本地服务器。agent 把消息、:::question 块、文件和引导式评审留在那里，你方便时再答。没有任何东西占着 agent 会话不放：回复通过 Claude Code、Pi 或 OpenCode 的连接唤醒发问的那个会话；其他 agent 稍后用 read_thread 读取。
最小可用示例（可复现）。
plannotator inbox # 前台启动并打开浏览器
plannotator inbox --background # 后台启动，打印 URL 后退出 0
plannotator inbox --open <thread> # 直接定位到某个线程
plannotator inbox --tailscale # 同时发布到 tailnet
列表的分区顺序是固定的：Stopped on you、Holding up work、Waiting on you、New since you looked、Sent、Quiet。Sent 排在 New 之后，因为它在等 agent 而不是等你。
收益与量化指标。 线程路由规则是「第一个匹配获胜」：先看 reply_to，再看线程名（NFKC 归一化、丢弃默认可忽略码点、空白折叠、大小写折叠，所以形近拼写算同一个线程），都没有就开新线程。路由只读日志、同步执行，所以并发的发送会落进同一个线程，重放也能得到与实时存储一致的路由结果。已解决的线程再收到同名发送会开新线程（「resolved 就是 done」）。
适用边界。 官方坦白了两个缺口：Mac 通知助手尚未构建（只有一个 spike）；plannotator inbox call 这条脚本化命令在等待 90 秒或连接断开后返回 inbox_no_answer。另外 Inbox 的 /mcp 边界是 127.0.0.1 only——永远不会面向浏览器、tailnet 或已链接的机器。
六、快速上手
curl -fsSL https://plannotator.ai/install.sh | bash # macOS / Linux / WSL
irm https://plannotator.ai/install.ps1 | iex # Windows PowerShell
curl -fsSL https://plannotator.ai/install.sh | bash -s -- --minimal # 只要二进制
curl -fsSL https://plannotator.ai/install.sh | bash -s -- --verify-attestation # 校验 SLSA 溯源
安装器会自动探测已安装的 agent，并为每个 agent 配置钩子、技能与斜杠命令。各宿主的收尾步骤不同：Claude Code 需 /plugin marketplace add backnotprop/plannotator 再 /plugin install plannotator@plannotator 并重启；Codex 与 Gemini CLI 无需额外操作（Gemini 需 0.36.0+）；Copilot CLI 走插件市场；OpenCode 在 opencode.json 加 "plugin": ["@plannotator/opencode@latest"]；Pi 用 pi install npm:@plannotator/pi-extension；DeepSeek Harness 在 Plugins 页加 @plannotator/dsh；Droid 目前仅命令、暂无计划拦截。
七、横向对比
| 维度 | Plannotator | 终端 diff/标注 TUI | 托管 PR 评审（如 CodeRabbit） | 计划生命周期管理（如 Flanner） |
|---|---|---|---|---|
| 介入时机 | 批准那一刻 / PR 之前 | 终端内，随时 | PR 创建之后 | 计划保存之后 |
| 审阅面 | 浏览器文档式 UI + 终端 TUI | 仅终端 | 托管 Web | 仓库内文件 + CLI |
| 支持的 agent | 10 个编码 agent + 4 个个人助理 | 5 个编码 agent 的回复 | 与 agent 无关 | Claude Code / Codex / Claude Desktop |
| 反馈闭环 | 标注直接回到原 agent 会话 | 回到 agent 下一条消息 | 回到 PR 评论 | 供 agent 检索 |
| 版本对比 | 计划版本之间 | 累积在同一数据目录 | PR 历史 | 计划版本之间 + 计划与代码比对 |
| 分享 | URL fragment 或 AES-256-GCM 短链 | 无 | 平台内 | 设备到设备（付费） |
| 许可与价格 | Apache-2.0 / MIT，免费 | 视项目而定 | 免费档 + 付费档 | MIT 免费，Mesh 起价 $9/月 |
第三方目录站（toolradar.com、rightaichoice.com）给出了 Plannotator 的「Team $4/用户/月、Enterprise $21/用户/月」等价格，但这些页面同时把定价来源标注为 github.com/pricing，且官方站点当前对 Workspaces 只提供 waitlist。这些价格数字属于待确认，不应作为采购依据。
八、局限、风险与社区观察
维护活跃度。 极高，但结构上高度集中：100+ 贡献者中，主作者一人贡献 8,959 次提交，其余贡献者多在 10–24 次量级。这既是「单人驱动的精品项目」的典型形态，也是 bus factor 风险。正面信号是 Release Notes 里反复出现首次贡献者，说明外部参与通道是通的。
License 风险。 当前是 Apache-2.0 / MIT 双许可，对商业使用友好。但第三方页面仍残留 BSL 标注，团队做合规审查时应以仓库当前文件为准，并注意历史版本可能适用不同条款。
生产可用性。 第一，发布节奏极快：11 月 9–15 日发了十个版本，依赖 hooks 与评审闸门的团队应先在小范围仓库试跑再铺开。第二，集成深度不均：Claude Code 的计划评审路径最直接，Codex 的计划评审是实验性的且钩子文档只覆盖 macOS/Linux/WSL，Droid 目前只有命令、没有计划拦截。第三，远程模式无登录且监听全接口。第四，UI 与本地 API 不做用户鉴权——官方文档明确写了这一点，它假设的使用模型是「单机、单用户、本地面」。
已知缺口（官方文档自述）。 Mac 通知助手未构建；plannotator inbox call 在 90 秒后返回 inbox_no_answer；SBOM 是发布级清单而非逐二进制运行时清单；OpenCode 2 适配有已知限制。
社区观察。 Hacker News 上多次出现自发的使用推荐，典型表述是「用 Claude Code、Codex、Pi 处理不同层级的工作，用 Plannotator 评审 agent 消息、规格与本地代码」。第三方评审（vibecodinghub.org，2026-07-28）的核心判断值得引用：它最强的特性不是浏览器 UI 本身，而是从人类标注回到 agent 的闭环；主要弱点是「安装与行为随 agent、操作系统与评审模式而变」。
九、小结与行动建议
- 先在一个非关键仓库、一条工作流上试跑——要么是计划批准，要么是提交前的 diff 评审——再衡量这个新增的检查点是否真的抓到了有意义的问题，而不是平白拖慢日常节奏。
- 把 Plan Diff 当作迭代追踪工具而不是审批装饰。它的价值在「agent 改完第二版、你能一眼看出改了什么」，这需要你确实会拒绝第一版。
- 把自定义评审技能当成团队资产来经营。你反复提的评审意见应该沉淀成
~/.plannotator/review-skills.json里的一条技能，而不是每次手写——但注意只认全局技能。 - 显式管理安全边界：远程模式无登录且监听全接口；评审 UI 与本地 API 不做鉴权；标注模式会复制被标注文件的内容到
~/.plannotator/history/。 - 锁定版本再上生产。发布节奏极快是优点也是风险；
--minimal与--verify-attestation提供了「只要二进制」和「校验 SLSA 溯源」两条收敛路径，值得在正式采用前用一遍。
回到开头那个荒诞：我们花两年让 agent 能自己干活，然后发现瓶颈挪到了「人点头」这一步。Plannotator 是这个方向上做得挺老实的一个——它不假装能替你做决定，只是把「要看的东西」和「你的意见」这两端接起来，中间那一下还是你自己按。听着不够革命，但说真的，这个行业现在缺的未必是更多会写代码的东西，而是更少需要你来回切换窗口的东西。
资料来源与数据获取日期：GitHub 仓库与 API（2026-11-15 抓取）、项目 README 与 docs/agent-guides/ 系列文档（2026-11-15）、Release Notes v0.28.63–v0.28.65（2026-11-15）、packages/core/crypto.ts 与 compress.ts（2026-11-15）、packages/ui/README.md（2026-11-15）、docs/custom-reviews.md（2026-11-15）、第三方评审 vibecodinghub.org/blog/plannotator-review（2026-07-28）、对比页 flanner.io/compare/plannotator（2026-09-23）、rightaichoice.com 与 toolradar.com 对比页（2026-10 至 2026-11）、腾讯云开发者社区《我们造了十个 agent，然后发明了一个新岗位：审阅员》（2026-11-14）。
读者留言
COMMENTS 暂无还没有留言，来说第一句？