核心用法
Lark Doc Reviser 是一款面向飞书（Lark/Feishu）文档的智能化修订工具，专为团队协作场景设计。其工作流程分为五个关键步骤：首先通过 fetch_doc.py 脚本获取文档完整状态，包括所有包含未解决评论的区块及其上下文；随后将评论内容以结构化方式呈现给用户，由用户确认需要处理的修订点；接着使用 patch_blocks.py 脚本对指定区块进行精准的文本元素级编辑，支持普通文本、加粗、斜体、代码样式等多种富文本格式；修订完成后通过 resolve_comments.py 批量标记评论为已解决；最后重新获取文档状态以同步最新变更。
该工具采用"块级替换"机制，每个区块的 elements 会完全覆盖原有内容，确保修订的精确性和可追溯性。所有操作均通过本地调用 lark-cli 子进程完成，文档状态以 JSON 格式保存在本地 workspace 目录，支持跨会话的断点续修。
显著优点
官方生态深度整合：直接调用飞书 Docx API 和 Drive API，与飞书原生协作体验无缝衔接，无需额外配置复杂的 OAuth 流程，依赖用户已认证的 lark-cli 环境即可运行。
精准块级编辑：区别于全文替换的粗放模式，该工具识别文档的区块结构（block-level），仅修改收到评论的具体段落，保留文档整体格式和层级关系，避免误删相邻内容。
评论驱动的工作流：将"评论-修订-确认"的协作闭环自动化，特别适合 PM 审需求文档、法务审合同、编辑审稿件等多轮反馈场景，显著减少人工核对成本。
零第三方依赖：仅使用 Python 标准库（subprocess、json、argparse 等），无供应链攻击风险，代码体积极小（约 20KB），部署轻量。
数据隐私友好：所有文档内容和状态文件本地存储，不经过第三方服务器，符合企业数据合规要求。
潜在缺点与局限性
结构操作受限：当前版本不支持创建空区块、删除区块、移动区块等结构性变更，此类需求需用户手动操作或直接使用 lark-cli api 命令，对于涉及大纲重组的修订场景不够完整。
依赖前置环境：必须预先安装并认证 lark-cli 工具，对未配置飞书开发环境的用户存在使用门槛，且 lark-cli 的版本兼容性可能影响功能稳定性。
评论状态耦合风险：update_text_elements 操作会自动清空元素的 comment_ids，意味着修订后原评论锚点会丢失，必须通过 Step 4 主动标记解决，否则可能出现"评论消失但未标记"的状态不一致。
富文本格式有限：支持的文本样式仅限于 bold、italic、code、strikethrough、underline 基础格式，对于表格、图片、嵌套区块等复杂内容类型无法处理。
单文档会话制：每次工作流程围绕单一文档 token 展开，跨文档批量处理需多次调用，不适合大规模文档集的管理场景。
适合的目标群体
- 产品经理与运营团队：处理需求文档、PRD、活动方案的多人评审反馈
- 内容编辑与知识管理者：维护飞书知识库，处理读者留下的批注和勘误建议
- 法务与合规人员：审核合同条款、政策文档，按批注逐项修订
- 小型研发团队：在技术文档、API 文档的协作编写中快速响应 review 意见
- 飞书深度用户：已将飞书作为核心协作平台，希望扩展其自动化能力的组织
使用风险
性能与 API 限流：频繁调用飞书开放 API 可能触发平台限流策略，建议在非高峰时段处理大型文档，或增加调用间隔。
数据持久化风险：本地 workspace/<token>_state.json 文件若未妥善管理，可能残留敏感文档内容，需定期清理或设置目录权限隔离。
操作不可逆性：块级替换为覆盖写操作，虽有评论留存机制，但无内置版本回滚功能，建议修订前通过飞书原生功能创建文档副本。
lark-cli 依赖性：该工具的所有网络能力均委托给 lark-cli，若后者配置失效、认证过期或版本不兼容，将导致功能完全不可用。
误操作放大风险：批量解决评论（Step 4）若输入错误的 comment_id，可能错误标记未处理的反馈，建议分批次小量验证。