larksuite / larksuite/cli

[lark-doc] 建议补充共享文档写前重读与最小修改范围规则

Open Beginner friendly
#2,457 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

domain/auth domain/core domain/doc enhancement
Dominant language
Go
Stars
17.3k
Forks
1.4k
Avg merge
2d 4h
Merged PRs (30d)
105

Description

背景

当前 lark-doc Skill 已经要求:

  • 更新前先 docs +fetch 读取目标范围;
  • 优先使用 str_replace / block_replace 等局部操作;
  • 写入后重新 fetch 验证,并按 block ID 已变化处理;
  • 非必要不使用 overwrite

这些规则可以降低全文覆盖和资源丢失风险,但还没有覆盖一个常见的共享编辑窗口:Agent 完成 fetch 和修改方案后,用户或其他协作者可能继续编辑同一篇文档。此时 Agent 如果仍基于早期正文、block ID 或 revision 执行写入,可能覆盖新内容,或者顺带重写用户本轮没有授权修改的相邻结构与措辞。

我目前在本地长期维护这组补充规则,每次同步新版 Skill 都需要重新合并,希望可以上游化。

当前缺口

截至 main56ad837c3d8f4c49d6b9725a3530c37408533ead

  • skills/lark-doc/references/lark-doc-update.md 的 Observe 阶段只要求开始编辑前 fetch;
  • Verify 阶段要求写后 fetch;
  • --revision-id 已存在,但 Skill 没有要求 Agent 在每次实际写入前重新取得最新目标内容与 revision;
  • Skill 也没有明确限制 Agent 只能修改用户本轮授权的最小范围。

因此,“最初读过一次”和“最后验证一次”之间仍存在 stale read / lost update 风险。

建议

建议在 skills/lark-doc/SKILL.md 的编辑入口,以及 skills/lark-doc/references/lark-doc-update.md 的通用安全规则中补充以下语义:

  1. 编辑用户可能同步维护的已有文档时,每次写操作前重新局部 fetch 目标内容、block ID 和可用的最新 revision。
  2. 如果内容相较先前读取结果已变化,基于最新内容重新生成局部修改,不沿用早期正文、block ID 或 revision 重写目标章节。
  3. 只修改用户本轮明确授权的最小范围,不顺带调整未请求的结构、措辞或相邻内容。
  4. 只有用户明确要求整体重建时才使用 overwrite

可参考的文案:

- 对用户可能同步维护的已有文档,每次写操作前都重新局部 fetch 目标内容、block ID 和可用的最新 revision。若内容较先前读取结果已经变化,基于最新内容重新生成局部修改,不要沿用早期正文、block ID 或 revision 重写目标章节。
- 只修改用户本轮明确授权的最小范围,不要顺带调整未请求的结构、措辞或相邻内容;仅当用户明确要求整体重建时才使用 `overwrite`。

与现有问题的区别

#641 主要讨论 overwrite 导致图片、画板等非文本 block 丢失,后续通过 Doc v2 的 XML/block-level 局部更新能力解决。本提案不要求新增 CLI 命令,重点是补齐 Agent Skill 在共享文档场景下的写前重读、并发变化处理和用户授权范围约束。

预期收益

  • 减少用户与 Agent 同时维护文档时的覆盖风险;
  • 避免 Agent 使用过期 block ID / revision 连续写入;
  • 防止“顺手润色”或重组用户未要求修改的内容;
  • --revision-id、局部 fetch 和 block-level update 形成完整的安全编辑流程。

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading skills/lark-doc/SKILL.md and skills/lark-doc/references/lark-doc-update.md, focusing on the editing entry, Observe stage, and safety rules. Add the requested pre-write refetch, changed-content handling, minimum authorized scope, and overwrite restriction in the relevant sections. Done means both files consistently describe the shared-editing safeguards without unrelated changes.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
84/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.