Imza:用计划文档串起编码与审查

Imza 是一款运行在终端中的编码代理。它把代码修改拆成三个阶段：先共同制订计划，再按计划编写代码，最后集中审查改动。它试图解决的问题是，代理生成代码很快，开发者却可能来不及理解项目发生了哪些变化。

这套工具更适合愿意检查规格和代码、经常处理多文件修改，并且希望控制代理权限的开发者。如果只是生成一个小脚本，或者不准备投入时间审阅计划和代码，这套流程增加的步骤未必值得。

目前的功能和资源占用数据主要来自项目自己的公开介绍，缺少独立测试。因此，Imza 更适合被视为一种值得小范围验证的工作流，而不是已经证实能够提高效率或代码质量的工具。

把计划从聊天记录变成独立文档

编码代理通常会在对话中混合需求、计划、命令输出和修改摘要。会话变长以后，开发者可能难以确认代理依据的是哪一版要求，也容易只看总结而忽略实际代码。

Imza 的 Plan 模式把计划保存为独立的 Markdown 规格文档。Markdown 是一种便于阅读和修改的纯文本格式。在这个阶段，代理可以调查代码仓库，但不会修改文件。开发者和代理都能编辑计划，历次修订会被保留。计划中的具体位置还可以添加批注，再将这些意见合并成一次修订请求。

这份文档为双方提供了共同参照：准备修改什么、涉及哪些文件、如何验证结果，都可以在动手前检查。它并不能保证计划正确，但能让遗漏和误解更容易被发现。

进入 Build 模式后，代理按照确认过的计划编辑文件、运行命令，也可以调用子代理。每次写入产生的差异都会显示出来。这里的“差异”是指修改前后具体增加、删除或改变了哪些代码，而不只是任务完成后的文字总结。

完成修改后，全部变更进入 Review 模式。开发者可以自行记录问题，也可以让代理辅助检查，再把审查结果送回 Plan 模式，形成下一轮计划。整个循环是：

Plan → Build → Review → Plan → Build

Imza 的核心特点不是给工作过程换了三个名称，而是让计划、实际修改和审查意见保持关联。

一个小任务可以怎样完成闭环

比如可以设想，要为现有项目增加“导出数据”功能。初次试用时，不宜直接交给它一项范围模糊的大型改造，而应选择边界明确、结果容易验证的任务。

在 Plan 阶段，可以让代理调查相关目录、数据结构和现有测试。开发者随后检查计划是否覆盖权限判断、异常处理、输出格式和测试范围。如果描述仍然含糊，就修改文档或添加批注，直到预期变化足够清楚。

进入 Build 阶段后，需要对照计划阅读持续显示的代码差异，确认代理有没有修改范围之外的文件、引入不必要的依赖，或者改变原有行为。完成后，再在 Review 阶段集中检查全部改动并运行项目已有的测试。发现问题时，可以把审查意见送回计划，而不是仅在聊天框里追加一句笼统的“修一下”。

这套过程符合 Imza 的公开设计，但现有材料没有提供大型仓库、长会话或复杂重构的独立测试。计划是否会遗漏约束、差异过大时是否仍然便于阅读，以及不同模型能否稳定遵循计划，都需要在实际项目中验证。

权限和模型选择需要自行配置

Imza 支持 OpenAI 兼容接口和 Anthropic Messages API，也能连接本地部署的 OpenAI 兼容模型。用户需要提供自己的 API 凭据、使用受支持的订阅连接，或者准备本地模型。公开材料没有提供各类模型服务的具体费用。

在非交互运行，也就是由脚本或持续集成系统自动调用时，Imza 可以只开放指定目录和命令。例如，可以允许代理访问某个资源目录，同时只准运行 `git status` 和项目构建命令。文件访问、命令执行和代码修改仍会进入权限与变更记录系统。

细分权限有助于限制代理的活动范围，但配置本身也需要时间。权限过窄可能让任务无法继续，权限过宽则会削弱限制的作用。使用者仍要理解每项授权允许代理执行什么操作。

项目还介绍了一种沙箱 Lua 脚本执行方式。模型可以把读取、搜索、编辑和命令组合成一次操作，并在结果进入对话上下文前过滤无关内容。开发者称这种方式能减少模型与工具之间的往返次数和上下文占用，但现有材料没有给出足够完整的对照数据，不能据此断言它一定更快、更省费用。

客户端轻量，完整使用成本并不只看内存

Imza 是原生 C++ 应用，不依赖 Electron 或 JavaScript 运行时。项目介绍给出的数据是：二进制文件约为 20 MB，启动时约占用5至8 MB内存，典型代理任务中约占用20至40 MB。这些数字描述的是 Imza 客户端，不能代表模型推理、长上下文或并行子代理的全部资源消耗。

macOS 可以通过 Homebrew 安装，Linux 和 Windows 提供预编译包。当前下载的 macOS 包没有签名，首次启动需要手动通过 Gatekeeper 放行。安装后还要配置服务提供方并选择模型。

决定是否采用时，至少需要计算以下投入：

• 外部模型服务或本地推理设备的成本；
• 熟悉三个工作模式和权限配置所需的时间；
• 阅读计划、检查代码差异和运行测试的人力；
• 升级软件、调整模型及维护项目配置的工作。

现有材料没有给出 Imza 应用本身的完整收费说明，也缺少可确认商业使用条件的许可证信息。用于公司项目之前，应核对仓库当时采用的许可证、版本政策和模型服务条款。代码公开并不自动代表可以免费商用。

与人工流程相比，它主要减少信息散落

不用 Imza，开发者也可以自己编写需求文档，调用其他编码工具修改代码，再通过 Git 差异完成审查。Imza 的区别是把这些动作放进同一套终端界面，并让审查意见回到下一版计划。

如果团队已经严格执行规格评审、代码审查和变更记录，Imza 能带来的额外价值可能有限。如果代理经常在长对话中直接修改大量代码，独立计划文档、实时差异和集中审查界面可能更有帮助。

目前没有统一的对照测试证明 Imza 比其他编码代理更快、更准确或更省钱。公开材料能够支持的判断是：它选择用可检查的中间文档和代码差异，让开发者持续看到计划与实现如何变化。

是否值得用，应先做一次小范围验收

Imza 适合愿意审阅计划和代码、经常处理多文件修改，并且能够配置模型与权限的开发者。它不太适合不熟悉终端、缺少代码复核能力，或者只追求尽快生成结果的人。涉及敏感代码的生产仓库，也不应仅凭产品介绍直接接入。

试用时，可以选择一项范围清楚、人工能够在较短时间内完成的真实任务，记录以下结果：

• 计划是否准确覆盖需求；
• 修改是否超出约定范围；
• 代码差异是否容易阅读；
• 目录和命令权限是否得到遵守；
• 原有及新增测试是否通过；
• 模型费用和人工耗时是否可以接受。

完成后，开发者还应在不依赖代理总结的情况下解释关键改动。如果代码能够运行，但负责审查的人仍说不清它为什么这样实现，那么 Imza 想要维持的“人在开发循环中”并未真正实现。

现阶段，Imza 值得重视计划和代码审查的开发者用一个小任务试验，但还没有足够证据支持把它作为普遍提高开发效率的答案。