需求描述
CLI 能把现有桌面功能变成可批量调用、可集成、可复现的基础能力，只需先给现有服务增加一个薄的命令行入口。如果易标要成为“投标领域的 OpenClaw”，CLI 不是附属功能，而是让其他 Agent 调用易标能力的重要基础设施。
使用场景
对易标用户来说，CLI 可以带来：
- 批量解析和检查多份招标文件；
- 夜间或无人值守执行耗时任务；
- 通过配置文件复用同一套标书流程；
- 接入 OA、企业网盘、RPA、飞书机器人和内部投标系统；
- 让 AI 助手直接调用解析、生成、查重和废标检查能力。
普通用户不一定亲自使用命令行，但可以使用建立在 CLI 上的一键脚本、企业工作台和 AI 助手，因此最终受益者仍然是业务用户。
对项目开发来说，CLI 也有长期价值：
- 促使核心业务逻辑与 Electron 页面解耦；
- GUI 和 CLI 可以复用同一套服务，避免重复实现；
- 更容易编写无界面的集成测试和回归测试；
- 用户能够通过命令、参数、退出码和日志准确复现 Bug；
- 社区可以开发机器人、MCP、批处理工具和企业集成，而不必修改易标本体；
- 将来增加 Web、HTTP API 或服务端模式时，也有更稳定的核心边界。
易标目前已经有文档解析、AI 生成、知识库、查重、废标项检查、导出和后台任务等比较明确的能力模块，也将自身定位为投标领域的 OpenClaw，因此 CLI 和项目方向是比较契合的。
期望效果
- 促使核心能力与 Electron 界面解耦
易标当前主要是 Electron 桌面客户端，本地文件、配置、导出和后台任务等能力由 Electron Main/Preload 承担，Renderer 负责业务界面。
这会带来长期收益：
- 业务逻辑不再依赖页面生命周期；
- 将来改界面时不容易破坏核心功能；
- 更容易增加 Web、MCP、SDK 或服务端入口；
- 不同入口的处理结果保持一致。
- 自动化测试更容易
桌面 GUI 的端到端测试通常较慢，也容易受窗口状态、系统环境和渲染时序影响。
CLI 可以直接用于集成测试：
- yibiao parse ./fixtures/sample.pdf --output ./tmp
- yibiao check rejection ./tmp --json
然后测试程序判断：
- 退出码是否正确；
- 是否生成预期文件；
- JSON 字段是否完整；
- 某类招标文件是否仍能正常解析；
- 新版本是否改变了检查结果。
这能让真实业务流程进入 CI，而不是只测试零散函数。
- 降低 Bug 复现和支持成本
GUI 用户反馈问题时，通常只能说：
CLI 用户可以直接提供：
Command:
yibiao parse tender.pdf --parser mineru --json
Version:
1.4.2
Exit code:
12
Error:
PARSER_TIMEOUT
作者可以更快复现问题，也更容易判断是：
- 文件问题；
- 模型问题；
- 配置问题；
- 权限问题；
- 解析器问题；
- 软件回归。
所以 CLI 虽然短期增加开发工作，长期可能降低排障成本。
- 扩大开源社区的贡献范围
没有官方 CLI 时，社区成员想做自动化，往往只能：
- 直接调用项目内部模块；
- 自己分析 Electron IPC；
- 修改源码；
- 维护非官方脚本；
- Fork 出不同版本。
这些方案依赖内部实现，很容易随着项目升级而失效。
官方 CLI 相当于作者声明了一个稳定边界：
- 输入是什么
- 参数是什么
- 输出是什么
- 错误是什么
- 兼容性如何
这样社区可以在不深入修改易标内部代码的情况下，开发：
- 飞书机器人；
- 企业内部工作台；
- MCP Server；
- 批量标书检查器；
- 文件夹监控工具；
- NAS 或服务器任务；
- 第三方插件。
这会把社区贡献从“修改易标本体”，扩展为“围绕易标建设生态”。
- 新功能可以先提供命令，再开发完整界面
有些功能业务价值明确，但 GUI 设计成本较高。作者可以先以实验性命令开放：
yibiao experimental compare-bids ...
社区和高级用户验证需求后，再决定是否投入时间制作完整界面。
CLI 因而也可以成为：
低成本验证新能力的入口。
- 为未来 API、MCP 和服务化奠定基础
CLI 不等于最终形态，但它可以成为中间层：
核心服务
├── Electron GUI
├── CLI
├── MCP Server
├── HTTP API
└── 第三方 SDK
相比直接开发网络 API，CLI 通常更容易先复用本地文件、模型配置和工作区，也不必立即处理服务器部署、端口、远程认证和多用户隔离等问题。
参考示例
飞书也是类似思路。它保留完整的客户端体验，同时提供官方 CLI，让人类和 AI Agent 可以通过命令调用文档、多维表格、日历、消息、任务等能力。它开发 CLI，并不是因为普通办公用户更喜欢终端，而是为了让产品能力能够被自动化和组合。
需求描述
CLI 能把现有桌面功能变成可批量调用、可集成、可复现的基础能力，只需先给现有服务增加一个薄的命令行入口。如果易标要成为“投标领域的 OpenClaw”，CLI 不是附属功能，而是让其他 Agent 调用易标能力的重要基础设施。
使用场景
对易标用户来说，CLI 可以带来：
普通用户不一定亲自使用命令行，但可以使用建立在 CLI 上的一键脚本、企业工作台和 AI 助手，因此最终受益者仍然是业务用户。
对项目开发来说，CLI 也有长期价值：
易标目前已经有文档解析、AI 生成、知识库、查重、废标项检查、导出和后台任务等比较明确的能力模块，也将自身定位为投标领域的 OpenClaw，因此 CLI 和项目方向是比较契合的。
期望效果
易标当前主要是 Electron 桌面客户端，本地文件、配置、导出和后台任务等能力由 Electron Main/Preload 承担，Renderer 负责业务界面。
这会带来长期收益：
桌面 GUI 的端到端测试通常较慢，也容易受窗口状态、系统环境和渲染时序影响。
CLI 可以直接用于集成测试：
然后测试程序判断：
这能让真实业务流程进入 CI，而不是只测试零散函数。
GUI 用户反馈问题时，通常只能说：
CLI 用户可以直接提供：
Command:
yibiao parse tender.pdf --parser mineru --json
Version:
1.4.2
Exit code:
12
Error:
PARSER_TIMEOUT
作者可以更快复现问题，也更容易判断是：
所以 CLI 虽然短期增加开发工作，长期可能降低排障成本。
没有官方 CLI 时，社区成员想做自动化，往往只能：
这些方案依赖内部实现，很容易随着项目升级而失效。
官方 CLI 相当于作者声明了一个稳定边界：
这样社区可以在不深入修改易标内部代码的情况下，开发：
这会把社区贡献从“修改易标本体”，扩展为“围绕易标建设生态”。
有些功能业务价值明确，但 GUI 设计成本较高。作者可以先以实验性命令开放：
yibiao experimental compare-bids ...
社区和高级用户验证需求后，再决定是否投入时间制作完整界面。
CLI 因而也可以成为：
低成本验证新能力的入口。
CLI 不等于最终形态，但它可以成为中间层：
核心服务
├── Electron GUI
├── CLI
├── MCP Server
├── HTTP API
└── 第三方 SDK
相比直接开发网络 API，CLI 通常更容易先复用本地文件、模型配置和工作区，也不必立即处理服务器部署、端口、远程认证和多用户隔离等问题。
参考示例
飞书也是类似思路。它保留完整的客户端体验，同时提供官方 CLI，让人类和 AI Agent 可以通过命令调用文档、多维表格、日历、消息、任务等能力。它开发 CLI，并不是因为普通办公用户更喜欢终端，而是为了让产品能力能够被自动化和组合。