feishu-okr-drafter

name	feishu-okr-drafter
description	基于当前与历史飞书 OKR、上级目标、同事目标、绩效总结、自评和工作材料，生成、改写、审阅、写入并艾特协作者的 Objective / Key Result。用户要求写 OKR、制定目标、拆解 KR、承接上级目标、检查对齐关系、优化 OKR 表述，或将草稿保存到飞书时使用。

飞书 OKR 草稿

目标与边界

把多源工作事实整理成可讨论、可衡量、可对齐的飞书 OKR，并在用户明确授权后写入草稿、艾特对应协作者。接口用于提速，飞书页面、历史文档、截图、用户粘贴内容和工作总结同样是有效输入。默认先完成判断和草稿，不创建、不发布、不修改现有 OKR。

遵守三条底线：

• 不凭空补目标值、基线、截止日期、负责人、业务结果或对齐对象；缺失信息写成 [待确认]。
• 把草稿、写入、保存、发布分开报告；没有读回证据就不宣称完成。
• 涉及敏感收入、成本、客户、人员或战略数据时，优先使用经确认的比例、区间、完成率或脱敏表达，并标注需要单独沟通的部分。

工作流

1. 判定任务模式

识别用户要做的是：

1. 从工作笔记生成新草稿；
2. 改写已有 O/KR；
3. 审阅质量和对齐关系；
4. 将草稿写入飞书；
5. 在周期中调整目标、KR、权重或截止时间。

没有明确写入意图时，停留在只读和草稿模式。

2. 建立上下文与资料路径

先阅读 lark-shared 和 lark-okr 的当前版本说明。需要读飞书内容时，执行身份、租户和权限核验：

lark-cli auth status --json --verify
lark-cli contact +get-user --as user

支持 auth status --json --verify 的环境必须确认 identity=user、verified=true。当前 CLI 构建若没有 auth 子命令，可退回 contact +get-user --as user 解析当前用户；需要继续草稿模式时，再用 task +get-my-tasks --as user 证明 user-context 可读。真正写入 OKR 或 @ 协作者前，仍要确认目标用户和租户。

按以下顺序选择可用资料路径，不能把“接口不可用”当作任务终点：

1. 接口/CLI 路径：权限允许时，用接口批量读取周期、O/KR、指标、进展和对齐关系。
2. 飞书页面路径：接口缺失、scope 不足或需要确认页面保存状态时，使用 control-in-app-browser。优先接管用户当前已打开的 OKR 页面；没有可用页面时，只做一次明确的飞书 OKR 入口导航。依据可见页面读取，不猜测 URL、字段顺序或按钮含义。
3. 用户材料路径：读取用户提供的文本、截图、文档、会议纪要、绩效总结、H1 自评和工作复盘。
4. 飞书文档路径：搜索并读取当前租户可访问的 OKR 制定、撰写、对齐、填写助手和岗位示例文档。

接口成功时也要结合页面或原文核验关键状态；页面成功时也要保留页面事实，不因无法形成 API ID 就丢弃证据。

按需获取：

• 当前用户的目标周期：okr +cycle-list；
• 周期下的 O/KR：okr +cycle-detail；
• O 的指标、KR 的指标：objective.indicators list、key_result.indicators list；
• O 的对齐关系：objective.alignments list；
• 相关进展记录：okr +progress-list；
• 相关飞书文档：搜索 OKR、制定、撰写、对齐、填写助手，优先读取当前租户可访问的规范与示例。

周期判断以起止日期与当前日期的重叠为首要条件，再参考周期状态；用户没有明确要求时，不把年度周期当作默认当前周期。

若 OKR 专用 scope 缺失，停止盲目重试，说明缺失的 scope 和影响。可继续基于用户提供的工作材料及有权限读取的飞书文档生成标注了上下文边界的草稿。

2.1 使用历史材料

历史 OKR 是重点参考项。至少检查最近一个已完成周期，条件允许时再看更早周期、进展记录、评分、评论、绩效总结和 H1 自评。

把历史内容分成四类：

• 已完成事实：作为基线、能力证明或案例证据，不原样抄成新 KR；
• 未完成或反复出现的高优事项：作为本周期候选主线，重新定义阶段结果；
• 上级或同事反复提出的反馈：转成质量、协作或机制类结果；
• 已经形成但尚未复制的能力：转成规模化、标准化、他人可独立运行或商业结果。

建立简短的来源台账：事实 → 来源 → 时间 → 对新 O/KR 的作用 → 是否仍需确认。把过去的成绩和未来的承诺分开。

2.2 读取四类 OKR 关系上下文

写当前周期 OKR 前，固定检查以下四类关系；缺少接口时通过飞书 OKR 页面、截图、用户粘贴内容或可访问文档补齐：

1. 上周期本人完成情况：逐项对照 O/KR 的目标值、进度、评分、评论和实际结果。区分已完成、部分完成、未完成、目标变化和证据缺失；只把对本周期仍有意义的未闭环事项或新阶段结果带入。
2. 本周期本人被 @ 的情况：收集在哪些 O/KR 被 @、来自谁、对应什么协作期待、交付节点和责任边界。把它们归类为主责候选、协作者、需确认事项或信息性 @，不能把被 @ 自动理解为承诺。
3. 上周期本人 @ 他人的情况：回看用户曾 @ 的对象、对应 O/KR、协作内容和是否完成闭环。识别持续依赖、重复找人、协作失配和可以沉淀为机制的关系；本周期只保留仍然有效的协作关系。
4. 直属上级 OKR：确认直属上级身份、当前周期、O/KR 顺序、重点结果、指标口径和协作边界。判断个人 O 是承接、支撑、横向协作还是独立主线；上级 OKR 缺失、周期不明或身份无法核验时标注边界，不自行推断。

建立关系台账：关系类型 → 来源对象 → O/KR → 对方/协作者 → 事实或期待 → 本周期处理 → 是否已确认。四类信息分别作为“历史结果”“协作输入”“协作回溯”“纵向承接”使用，避免混成一张待办清单。

3. 收集最小必要输入

至少确认：周期、角色或责任范围、要达成的业务结果、已知基线、目标值或判断标准、主要协作方、约束和敏感信息。

已有上级或团队 OKR 时，先识别：

• 哪些 O 需要承接；
• 哪些 KR 是同级协作；
• 哪些工作属于用户主责，哪些属于协助；
• 用户提出的工作是否与已有 O 重复或存在冲突。

若存在直属上级，直属上级当前周期 OKR 是纵向承接的首要参照；团队 OKR、同级 OKR 和被 @ 内容用于补充承接范围与协作边界。被 @、@ 他人和“看起来相关”都只能形成候选关系，只有内容、主责、周期和双方确认共同成立时，才报告为已对齐。

缺少关键输入时，用最少的问题补齐；仍无法确认时继续产出，但把不确定性显式放入 [待确认]。

4. 生成草稿

O 的写法

• 聚焦高优、高价值工作，排除日常职责堆砌；建议 3–5 个，工作范围较窄时允许更少。
• 写清方向、预期价值和时间范围；保持颗粒度适中，避免口号化或任务清单化。
• 保留一定挑战性，避免把“继续做”当成目标。
• 对长期事项拆成当前周期的阶段性结果。
• 使用读者第一次阅读就能理解的业务词汇；沿用组织已确认的专有名词。

当用户一次列出多件项目或战役时，先按业务结果聚类，再决定 O 的数量。项目名称通常进入 KR、实现路径或证据栏；只有代表独立结果主线时才单独成为 O。常见聚类方向包括客户/商业结果、端到端流程效率、产品化与复制、组织机制与影响力。

KR 的写法

• 每个 O 建议 3–5 条，分别覆盖不同的关键支撑面。
• 先写结果和状态，再补充必要的实现路径；避免只写“完成、负责、推进、跟进”。
• 给出客观可观察的定性或定量判断标准；“提升、优化、增强”后面补足起点、终点或验收条件。
• 写明周期内时间节点；目标值未知时保留 [目标值待确认]。
• 在需要协作时标明主责、协作者和责任边界；主要协同人一般不超过 4 人。
• 如需解释 KR 的方向，使用简短小标题，例如 【客户价值】、【流程提效】，避免把多条主线揉成一条。

优先按以下结构组织一条 KR：

【关键方面】通过[必要路径]，于[时间节点]达到[可观察结果/目标值]，由[主责]负责，@ [协作者]协同。

路径过长时删减；结果、时间和验收标准必须保留。

5. 执行质量检查

逐条检查 O 和 KR，并把问题分成“阻塞发布”和“建议优化”。详细规则见 references/okr-writing-principles.md。

重点检查：

• O 是否高优、清楚、适度挑战，是否对应当前周期；
• KR 是否直接支撑 O，是否描述结果，是否可衡量、可实现、有时间边界；
• KR 之间是否重复、漏掉关键支撑面或互相冲突；
• 目标值、基线、日期和负责人是否有来源；
• 是否存在纵向承接、横向协作、明确主责和实际对齐对象；
• 是否已核对上周期完成度、本周期被 @、上周期 @ 他人和直属上级 OKR；
• 是否保持目标顺序、专有名词、隐私和敏感信息口径一致；
• 是否把分数、进度、权重和目标值混为一谈。

6. 输出草稿

按以下顺序交付：

1. 周期与上下文：使用了哪些周期、上级 O、文档和用户输入；说明读取边界。
2. OKR 草稿：每个 O 下列出 KR、结果标准、时间、主责、协作方和证据来源。
3. 历史承接：哪些历史事实变成基线，哪些事项延续，哪些成果被提升为复制或规模化结果。
4. 关系与承接清单：上周期完成度、本周期被 @、上周期 @ 他人、直属上级承接、建议 @ 的对象、冲突和待沟通事项。
5. 质量诊断：阻塞项、建议优化项、尚未验证的假设。
6. 待确认：只列会改变目标含义、结果标准或系统写入的事项。

禁止用一套看似完整的数字掩盖不确定性。质量判断应解释“为什么这条 KR 能证明 O 达成”。

7. 写入飞书

只有用户明确要求写入或保存时才执行写操作。写入前：

1. 再次确认当前用户、租户、周期、目标归属和完整草稿；
2. 建立“写入与 @ 清单”：每个 O/KR 对应的协作者、@ 原因、主责边界、来源和核验状态；
3. 对姓名或邮箱逐个使用 lark-cli contact +search-user 解析为 open_id。命中多个候选、跨租户或身份信息不足时暂停该条 @，要求确认，不能猜选；
4. 先用 --dry-run 检查请求；
5. 普通文本和 @ 优先使用 simple 风格；需要精确控制 @ 位置时使用 richtext 的 mention 元素；
6. 新建多个 O/KR 优先使用 okr +batch-create，单个 O 或 KR 使用 okr +create；将 mention 写在对应 O/KR 上，避免把所有人集中 @ 在一个目标里；
7. 不因“草稿”自动设置分数；分数只在用户明确要求评分时处理；
8. 写入后重新读取周期详情，核对 O/KR 数量、正文、顺序、权重、截止时间、mention 和保存/发布状态；
9. 读回不完整、mention 未落地或系统语义可能直接发布时，停止并向用户说明，不继续推进。

写入与艾特的判定

• 用户只说“起草、生成、优化”时，只输出本地草稿和 @ 建议清单。
• 用户明确说“写入、保存到飞书、帮我填入”时，可以创建草稿；用户同时明确“艾特某人”或关系台账已有核验通过的协作者时，才写入 mention。
• mention 是真实用户 ID，不是正文中的 @姓名 字符串。接口路径将 mention: ["ou_xxx"] 放入对应 O/KR；页面路径使用用户选择器，并回读页面中的真实用户标签。
• @ 主责、协作者、直属上级要分别说明原因；仅因“相关”或“被 @”形成的候选关系，先进入待确认清单。
• 写入结果分开报告：已创建/已保存、已艾特、未艾特及原因、未发布。任何一项没有读回证据，都保留为待核验。

接口无法写入时，可在已登录的飞书 OKR 页面使用“批量粘贴 OKR”或页面编辑控件保存草稿。页面路径必须遵守以下顺序：

1. 先确认当前用户、周期和页面标题；
2. 粘贴 O/KR 后检查解析预览，确认 O/KR 数量和层级；批量粘贴无法生成真实 @ 时，改用页面编辑控件逐条选择协作者；
3. 对每个需要 @ 的 O/KR 使用页面用户选择器，核对显示姓名与部门，避免只输入普通文本 @姓名；
4. 只执行保存确认，不点击发布；
5. 回到最终页面核对“已保存”、O/KR 正文和真实用户标签，并确认每个目标仍保留“发布”按钮；
6. 页面弹窗关闭、保存提示缺失、@ 标签未出现或字段数量异常时，重新读取页面，不宣称保存成功。

对齐关系只作用于 Objective。创建对齐前确认两个目标属于不同目标、周期存在时间重叠且确有承接或协作关系；不要把“相关”直接写成“已对齐”。完整流程见 references/okr-alignment-review.md。

参考资料路由

• 写作原则、O/KR 诊断和反例：读 references/okr-writing-principles.md。
• 会前、会中、会后对齐与冲突处理：读 references/okr-alignment-review.md。
• 飞书 OKR 实体、读取、写入、权限和读回：读 references/feishu-okr-operations.md。