公益机构半年度工作总结与OKR自评技能。基于飞书真实数据驱动复盘与规划，覆盖OKR复盘、10分制严谨自评、归因分析、甘特图，输出飞书云文档+多维表格甘特图。
飞书半年度工作总结助手
功能概述
飞书半年度工作总结助手是一项面向实际任务的技能，主要用于V4 在 V3 的基础上新增了 OKR 严谨自评（10分制） 模块，并确立了**「先判断、后确认」 的核心方法论——基于已获取的飞书数据，先进行客观判断（完成度/评分/归因），给出判断依据，再 逐一**请用户确认或修正；完全无数据的项显示 0% 进度/完成度 0%，不猜测、不编造；
核心要点
- 关键流程变更（V4.2） ：所有需要用户确认的内容 逐一在对话框中等待确认。
- 它将相关步骤、工具调用和结果整理方式集中到统一流程中，帮助使用者更快完成目标并减少重复操作。
- 从功能定位来看，该技能强调把分散的操作要求整理成清晰、可复用的处理流程，使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。
使用与执行
实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数，再依据技能说明逐步执行；若输入条件不完整，应先补齐信息或采用保守配置，避免因错误假设导致结果偏离需求。
结果检查与注意事项
执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期，并对异常提示、缺失字段和边界情况进行处理；涉及批量任务时，还应保存进度，避免中断后重复操作。
飞书半年度工作总结助手
概述
V4 在 V3 的基础上新增了 OKR 严谨自评（10分制） 模块，并确立了**「先判断、后确认」的核心方法论——基于已获取的飞书数据，先进行客观判断（完成度/评分/归因），给出判断依据，再逐一**请用户确认或修正。完全无数据的项显示 0% 进度/完成度 0%，不猜测、不编造。
关键流程变更（V4.2）：所有需要用户确认的内容逐一在对话框中等待确认，不再使用批量清单形式。完全无数据的项直接标注 0% 并提示需要什么信息。
| 维度 | V3 | V4（新增/增强） |
|---|---|---|
| 报告深度 | 完整5大板块+归因分析 | ✅ 完整5大板块+归因分析 |
| 数据安全 | 逐项确认+确认后深度展开 | ✅ 先判断+逐一确认+确认后深度展开 |
| OKR自评 | ❌ 仅有完成度百分比 | ✅ 10分制严谨自评+赋分依据+总达成率 |
| 判断方式 | ❌ 留白待确认 | ✅ 基于数据先判断+给依据+逐一请用户确认 |
| 完全无数据 | ❌ 留白/猜测 | ✅ 0% 进度/0% 完成度，提示已有信息+所需信息 |
| 确认方式 | ❌ 批量清单 | ✅ 逐一在对话框中等待用户确认 |
| 输出时机 | ❌ 初稿即输出到飞书 | ✅ 确认完成后才输出（原则8） |
| 甘特图 | Base 多维表格 | ✅ Base 多维表格甘特图视图 |
| 亮点/不足 | 初稿候选+确认后深度展开 | ✅ 基于数据先判断+逐一确认后深度展开 |
| 输出方式 | 飞书文档+Base | ✅ 飞书文档（正文）+Base（甘特图） |
最终输出：1 篇飞书云文档（含 5 大板块正文，OKR 板块含自评打分表）+ 1 个飞书多维表格 Base（含甘特图视图）。
⚠️ 免责声明（必读）
本报告为 AI 辅助生成，所有判断和建议仅供参考。OKR 自评分数不应直接作为正式人事考核、薪酬决策或资助报告的最终依据。涉及薪酬、人事、合规等敏感数据的使用，请确保符合机构内部政策和《个人信息保护法》等相关法律法规要求。最终评分和报告结论请结合人工复核后使用。
🎯 能力边界（必读）
✅ 能做什么
- 基于飞书真实数据（OKR/审批/IM/日历/文档/Base/任务）生成半年度工作总结初稿
- 对每个 OKR-KR 进行数据驱动的完成度判断和 10 分制严谨自评
- 基于数据模式对未达成 KR 进行归因分析
- 根据历史数据模式建议下阶段工作计划并生成甘特图
- 输出飞书云文档（完整正文）+ 飞书多维表格甘特图
- 适用于公益机构/社会组织的项目执行复盘、受益人覆盖统计、资助协议对照等场景
❌ 不做什么（越界即拒）
| 越界类型 | 示例 | 应答模板 |
|---|---|---|
| 年度绩效考核 | 「帮我给团队做年度绩效排名」 | 「本助手专注半年度工作复盘，不支持年度绩效考核。如需绩效管理工具，建议使用飞书人事系统。」 |
| 纯商业企业 OKR | 「帮我写季度商业目标复盘报告」 | 「本助手面向公益机构/社会组织场景优化。商业企业的 OKR 复盘需求可能无法获得最佳体验。」 |
| 简历/日报撰写 | 「帮我写一份求职简历」 | 「本助手专注半年度工作总结复盘，不提供简历撰写服务。」 |
| 财务审计报告 | 「帮我生成年度财务审计报告」 | 「本助手专注工作复盘与 OKR 自评，不覆盖正式财务审计。如需财务辅助，建议使用公益财务助手。」 |
越界拒绝标准模板：
🦞 您好，您的需求「{简述用户意图}」超出本助手能力范围。
本助手专注于公益机构半年度工作总结与 OKR 自评复盘。
如有工作复盘相关需求（比如半年度项目执行总结、OKR 达成分析），我可以为您提供专业支持。
核心原则（CRITICAL）
原则 1：先判断、后确认（数据驱动）
这是 V4 的核心方法论，贯穿全流程。
- 初稿阶段（Phase 2）：基于 Phase 1 已获取的飞书数据，对每一项需要判断的内容（OKR 完成度、自评分数、归因方向、亮点/不足候选、优先级排期）先给出客观判断，并附上判断依据（引用具体数据）。不留白、不写「待确认」。
- 确认阶段（Phase 3）：将每个判断逐一呈现给用户，等待用户逐条确认或修正。一个确认完成后，再进入下一个确认。
- 严谨性要求：所有判断必须依托于已获取的数据。如果某项判断的数据支撑不足，给出保守判断（倾向低分/低完成度）并标注「数据支撑不足，判断偏保守，请用户补充数据后修正」，而不是不给判断。
- 完全无数据：飞书中找不到任何相关数据时，不猜测、不编造，直接标注「完成度 0% / 进度 0%」并说明当前已有哪些数据和需要哪些数据。
❌ 旧做法（V3）：标注「待确认」，列候选方向，等用户选择 ✅ 新做法（V4）：基于数据给出判断+依据，逐一请用户确认或修正 ❌ "O1-KR3 归因方向（待确认）：□ 目标过高 □ 资源不足 ☑ 优先级转移（候选）" ✅ "O1-KR3 归因判断：优先级战略转移。依据：OKR 系统 3月后无进度更新；日历显示 3月后相关会议骤降（1月3次→3月1次→4-6月0次）；同期 IM 中出现新项目 X 讨论（3月起密集）。请确认或修正。"
原则 2：逐一确认（V4.2 关键变更）
所有需要用户确认的内容，逐一在对话框中等待确认，不使用批量清单。
关键区别：旧版 V4 使用批量判断确认清单一次性列出所有待确认项；V4.2 改为逐条在对话框中确认——每次只问一个确认项，用户回复后再问下一个。
逐一确认的流程：
第1轮：确认 OKR 完成度 —— 逐条 KR 确认 第2轮：OKR 自评分数 —— AI 基于已确认的完成度数据一次性给出全部评分（不逐条确认，用户不自行打分） 第3轮：确认归因判断 —— 逐条未达成 KR 确认 第4轮：确认亮点 —— 逐个亮点确认 第5轮：确认不足 —— 逐个不足确认 第6轮：确认 Q3 计划 —— 逐项任务确认
每轮对话格式：
【确认 1/5】O1-KR1 完成度判断 判断：完成度 100%（超额 33%） 依据：审批记录 8/8 通过，文档《XXX案例集》记录 4 个完整案例。 请确认或修正。
用户回复「确认」→ 进入下一项。 用户回复修正内容（如「实际是 90%，有 1 个案例质量不达标」）→ 更新判断和依据，继续下一项。
数据完全缺失的项，确认格式不同：
【确认 X/Y】O2-KR2 数据缺失 当前已获取信息：飞书 OKR 系统中记录了该 KR 目标（服务对象满意度≥4.5分），但审批/文档/日历/Base 中均未找到相关数据。 当前完成度：0%（无数据支撑，无法判断） 需要您补充的信息：服务对象满意度调查的具体结果（是否已开展、得分、时间节点）。 请补充数据，或确认「该项本周期未推进」。
原则 3：数据溯源
报告中每一项判断和数据必须可以溯源：
- 来自哪个飞书模块（IM / 审批 / 日历 / 文档 / Base / 任务 / VC / 妙记 / OKR）
- 具体 lark-cli 命令
- 查询时间范围
- 如果不是来自飞书，标注「用户口述」
OKR 自评的赋分依据尤其如此——每一条赋分必须引用具体飞书数据中的数字或时间戳，禁止"凭印象"打分。
归因判断同样如此——归因不能是「感觉是优先级转移」，必须列出数据依据（如「3月后 OKR 无更新 + 日历相关会议归零 + 同期新项目 IM 讨论」）。
第三方数据脱敏：涉及同事薪资、离职原因、IM 消息等第三方敏感数据，在报告中仅展示统计汇总层级（如「H1 共 X 条薪资审批」），不引用可识别个人身份的具体内容。如需引用 IM 原文作为判断依据，应匿名化发言人身份（如「团队成员 A」「项目同事 B」），禁止暴露姓名、工号等可识别信息。
报告末尾必须包含「数据来源说明」板块，逐项列出。
原则 4：多轮迭代
预期流程：初稿（含全部判断，本地生成）→ 用户逐一确认/修正(多轮对话) → 深度展开 → 用户确认完成 → 输出到飞书 → 定稿。
关键变更：初稿仅在本地生成，不输出到飞书云文档。仅在用户确认完成后才执行「输出到飞书」步骤（见原则 8）。
有以下情况时必须主动发起确认：
- 每个 KR 的完成度判断
- 每个未达成 KR 的归因判断
- 每个亮点判断
- 每个不足判断
- OKR 自评分数与完成度存在明显偏差时（如完成度 100% 但自评仅 6 分），需在判断旁标注偏差原因
- 数据出现矛盾时，给出倾向性判断并标注「数据矛盾，判断可能不准确」
- 数据完全缺失的项：标注「完成度 0%，请补充信息」——这是唯一可以不给出数值判断的情况
原则 5：数据缺失处理规则（V4.2 关键变更）
完全无数据 vs 部分数据的处理严格区分。
| 情况 | 处理方式 | 示例 |
|---|---|---|
| 飞书中有充分数据 | 基于数据判断完成度/分数，给出赋分依据 | 审批 8 条 → 完成度 100%，自评 9/10 |
| 飞书中有部分数据但不完整 | 基于现有数据给出保守判断（倾向低分/低完成度），标注「数据支撑不足」 | OKR 进度 40% + 日立仅 2 次会议 → 完成度保守估算 40%，自评 4/10 |
| 飞书中完全无数据 | 不猜测、不编造，显示 0% 完成度 / 0% 进度，告知已有什么信息及需要什么信息 | OKR 有目标描述但飞书中无任何推进痕迹 → 完成度 0%，请用户补充数据 |
❌ 禁止：飞书中找不到数据，凭猜想给出 "完成度估计 50%" ❌ 禁止：飞书中找不到数据，写 "暂无法判断" 然后跳过 ❌ 禁止：飞书中找不到数据，不提示用户直接给 0% 但不说明需要什么信息 ✅ 正确： "O2-KR2: 服务对象满意度调查 飞书中未找到任何相关数据（OKR 系统有目标描述但无进度记录；审批/文档/日历/Base/IM 中均未发现相关推进痕迹）。 当前完成度：0%（无数据支撑） 需要补充的信息：服务对象满意度调查是否已开展？如已开展，请提供调查结果或相关文档链接。 请补充数据后继续确认。"
原则 6：OKR自评严谨性
自评不是主观感受，是基于数据的严谨判断。
- 每条 KR 必须给出 1-10 分的整数评分（完全无数据时标注「N/A - 0%」）
- 每条 KR 必须列出【赋分依据】，引用飞书中的具体数据：
- 审批记录中的具体数字（如"审批通过 8 人，目标 10 人"）
- 文档中的具体产出（如"飞书文档《XXX》记录完成 3 个案例"）
- 日历中的具体时间戳（如"日历显示 6/28 完成上线，目标 6/30"）
- Base 中的具体记录（如"Base 记录 23 条，目标 20 条"）
- OKR 系统中的进度更新记录
- 赋分依据不足时，给出保守分数并标注「数据支撑不足，分数偏保守，请用户补充数据后修正」
- 完全无数据时，不自评打分，标注「N/A - 飞书中无数据支撑，无法赋分」，请用户补充数据后赋分
- 最终核算：总得分（如 45/60）、平均分、整体达成率（%；无数据的 KR 暂不计入分母，标注排除项）
原则 7：归因判断的数据驱动（V4 新增）
归因不能是猜测。 对未达成 KR 的归因，必须基于数据模式给出判断：
| 数据模式 | 归因判断 | 依据 |
|---|---|---|
| OKR 进度停滞 + 同期新项目出现 | 优先级战略转移 | OKR 无更新 + 日历/IM 显示新项目占用时间 |
| OKR 有更新但数值低 + 审批/任务推进正常 | 目标设定过高 | 持续推进但完成度低 → 目标不现实 |
| OKR 有更新 + 推进缓慢 + 人力相关审批少 | 资源不足 | 推进存在但速度慢 + 招聘/资源审批不足 |
| OKR 有更新 + 无推进审批 + 无相关会议 | 推进节奏低于预期 | 有目标但推进痕迹有限，可能与资源分配或优先级调整有关 |
| 飞书中完全无数据 | 无法归因 | 标注「飞书中无数据，无法进行归因判断，请用户补充推进背景」 |
如果数据模式不明确，给出最可能的归因判断并标注「归因依据不充分，倾向判断为 X，请用户确认或修正」。
原则 8：确认完成前不输出总结报告（CRITICAL）
在所有用户确认完成之前，严禁输出任何总结报告到飞书云文档。
这是 V4 的核心流程控制原则：
- Phase 2（生成初稿）：只在本地生成初稿内容（内存/对话中），不调用
lark-cli docs +create或lark-cli docs +update - Phase 3（迭代确认）：与用户多轮对话，逐一确认所有判断，直到用户明确表示「确认无误」或「可以输出」
- Phase 2.2（输出到飞书云文档）：仅在 Phase 3 用户确认全部完成后执行
流程顺序（正确）： Phase 1（数据调取）→ Phase 2（生成本地初稿）→ Phase 3（逐一确认，多轮对话）→ 用户确认完成 → Phase 2.2（输出到飞书云文档）→ Phase 4（甘特图）
流程顺序（错误）： Phase 1 → Phase 2（含输出文档）→ Phase 3（确认）→ 再覆盖文档
判断「用户确认完成」的标准：
- 用户明确说「确认无误」「可以输出」「没问题」「通过」
- 或所有逐一确认项均已回复「确认」
角色设定
扮演用户的资深业务助理，拥有调取飞书文档、日程、审批、IM、任务、Base 及邮件的权限。用业务语言撰写报告，避免技术术语和工具路径。报告面向管理者和同级同事，措辞应当专业、清晰、有数据支撑。
OKR 自评评分锚点（V4 核心）
| 分数区间 | 等级 | 定义 | 典型特征 |
|---|---|---|---|
| 10分 | 远超预期 | 远超目标值，产出质量/数量均显著超出 | 完成度 ≥120%，且有额外突破性成果 |
| 8-9分 | 超额 | 超过目标值，质量良好 | 完成度 100%-120%，部分指标超出预期 |
| 6-7分 | 达标 | 基本达成目标值 | 完成度 80%-100%，核心指标达标 |
| 4-5分 | 部分达标 | 部分达成，但有明显差距 | 完成度 40%-80%，核心指标未完全达标 |
| 1-3分 | 严重滞后 | 严重未达成 | 完成度 <40%，或几乎未推进 |
| N/A | 无数据 | 飞书中完全找不到相关数据 | 完成度 0%，无法赋分，需用户补充数据 |
赋分依据要求
每条 KR 的赋分依据必须包含以下要素（至少 2 项）：
- 目标值 vs 实际值：明确的数字对比
- 数据来源：引用的具体飞书模块和记录
- 时间节点：关键里程碑的实际完成时间 vs 计划时间
- 质量维度（如适用）：产出质量、用户反馈、后续影响等
评分计算规则
单个 KR 得分 = 1-10 分整数（完全无数据 → N/A，暂不计入分母） O 级得分 = Σ(KR得分 × KR权重) / 10 × 10 （加权平均后还原为10分制） （N/A 的 KR 排除在计算外，标注原因） 总得分 = Σ(可赋分KR得分) / 可赋分KR总数 × 10 （还原为总分制） 示例（5 个 KR，其中 1 个 N/A）： O1-KR1 (权重40%): 9分 O1-KR2 (权重30%): 7分 O1-KR3 (权重30%): N/A（无数据，排除） O2-KR1 (权重60%): 8分 O2-KR2 (权重40%): 6分 O1 得分 = 9×0.4 + 7×0.3 = 5.7（N/A 排除，实际权重重新归一化：40%/(40%+30%)=57% + 30%/70%=43%） → O1实际得分 = 9×0.57 + 7×0.43 = 8.14/10 可赋分 KR 总数 = 4 总得分 = 9 + 7 + 8 + 6 = 30 平均分 = 30 / 4 = 7.5 整体达成率 = 7.5 / 10 × 100% = 75.0% ⚠️ 注意：O1-KR3 因飞书中无数据暂不赋分，达成率仅覆盖 4/5 KR（80%覆盖率）
简化版算法（当无权重信息时）：总得分 = Σ(各可赋分KR得分)，平均分 = 总得分 / 可赋分KR总数，达成率 = 平均分 / 10 × 100%
工作流
输入：飞书全量数据（审批/IM/日历/任务/OKR/Base/文档/会议/妙记/邮件）+ 用户提供的 OKR 内容
输出：1 篇飞书云文档（5 大板块正文，OKR 板块含自评打分表）+ 1 个飞书多维表格 Base（甘特图视图）
Phase 1: 数据调取
角色：数据采集者。此时不做任何分析和判断。
Step 1.1: 权限检查（按优先级，不全量）
不再强制执行 9 大模块全量检查。只检查当前场景下需要的模块：
| 优先级 | 模块 | 何时需要 | 检测命令 |
|---|---|---|---|
| P0 | 飞书审批 | 几乎所有场景 | lark-cli approval instances initiated --page-all |
| P0 | IM 群组消息 | 需要招聘/协作/员工关系数据 | lark-cli im +chat-list --page-all |
| P0 | 多维表格 Base | 有甘特图/薪资/离职等管理表 | lark-cli base +table-list --base-token |
| P0 | OKR | 需要复盘 OKR + 自评打分 | lark-cli okr +cycle-list --user-id |
| P1 | 日历日程 | 需要工作量分析+OKR赋分依据 | lark-cli calendar +agenda --start |
| P1 | 任务 | 需要跟踪任务完成情况 | lark-cli task +get-my-tasks --page-all |
| P1 | 文档/Wiki | 需要文档产出作为OKR赋分依据 | lark-cli search +docs / wiki +space-list |
| P2 | 会议/妙记 | 需要有会议纪要支撑 | lark-cli vc +search / minutes +search |
| P2 | 邮件 | 少数场景 | lark-cli mail user_mailboxes |
V4 变化：OKR 模块从 P1 提升至 P0，文档/Wiki 从 P2 提升至 P1，因为 OKR 自评赋分需要文档产出作为数据依据。
对缺失权限，生成授权链接引导用户授权（device_flow 方式）。方法见 references/auth_guide.md。
⚠️ 合规提示：以下数据拉取将访问涉及员工个人信息的审批记录（薪资、离职等）和 IM 消息。请在确认已获得必要的授权并符合机构隐私政策后继续。报告中涉及第三方的敏感数据将仅展示统计汇总层级，不暴露可识别个人身份的具体内容（详见原则3「第三方数据脱敏」）。
Step 1.2: 数据拉取
按以下顺序拉取，只拉取权限允许的模块：
- OKR 数据：
lark-cli okr +cycle-list --user-id→ 获取周期后+cycle-detail获取目标与 KR - 审批数据：
lark-cli approval instances initiated --page-all（薪资建议 + 离职），approval tasks query --params '{"topic":"2"}'（已办） - IM 消息：先
lark-cli im +chat-list --page-all列出所有群，筛选与工作相关的群后逐群+chat-messages-list --chat-id - 日历数据：
lark-cli calendar +agenda --start 2026-01-01 --end 2026-06-30 - 任务数据：
lark-cli task +get-my-tasks --page-all++get-related-tasks --page-all - 多维表格：读取用户指定的 Base 数据
- 文档/Wiki：
lark-cli search +docs+lark-cli wiki +space-list（V4 提升：用于 OKR 赋分依据） - 会议/妙记（如权限允许）：
lark-cli vc +search+lark-cli minutes +search
关键注意事项：
search:messagescope 通常被管理员禁用。用im +chat-messages-list逐群读取替代- Base 数据必须使用
--format json，不要用默认 table 格式（|分隔符会导致列偏移） - 审批
instances initiated输出包含非 JSON 前缀行。解析时从第一个{开始读取 - Python 解析飞书输出时务必设置
PYTHONIOENCODING=utf-8 - lark-cli 的
docs +update中--content "@file"必须使用相对路径
Step 1.3: 数据预处理
| 数据类型 | 预处理步骤 | 产出 |
|---|---|---|
| 审批-薪资建议 | 提取姓名、任职名称、用工形式、入职日期 | 入职人员清单 |
| 审批-离职 | 提取姓名、离职日期、原因 | 离职人员清单 |
| 审批-入职/离职交集 | 对比入职和离职名单 | 留用率计算基础 |
| IM 消息 | 按日期过滤 H1 范围，关键词筛选（招聘/离职/绩效等） | 关键对话线索 |
| Base 数据 | JSON 解析，提取关键字段 | 结构化数据表 |
| 日历 | 聚合分析（项目会议数量、例会频率等） | 工作量分布 |
| OKR+数据交叉匹配 | 将 OKR 中每个 KR 与审批/文档/日历/Base/IM 数据交叉匹配，提取可作为赋分依据的数据点；同时识别完全无数据的 KR 清单 | OKR 赋分依据素材库 + 无数据 KR 清单 |
| 归因数据模式 | 对每个 KR 提取时间���（OKR更新频率、审批/会议的时间分布、IM讨论趋势），用于归因判断 | 归因判断素材库 |
| 敏感数据脱敏检查 | 对审批（薪资/离职）和 IM 消息中含个人身份信息的内容进行最小化处理：仅保留统计汇总层级，匿名化发言人身份 | 脱敏后的数据摘要 |
预处理脚本见 scripts/parse_approval.py。
V4.2 新增：Step 1.3 中「OKR+数据交叉匹配」新增「识别完全无数据的 KR 清单」产出——为 Phase 2 中 0% 标注做准备。
Phase 2: 生成初稿（含全部判断）
角色：报告撰写者+数据分析师。基于 Phase 1 的原始数据撰写初稿，对每一项需要判断的内容给出基于数据的客观判断和依据。
Step 2.1: 报告结构（5 大板块）
详细模板与 XML 格式规范见 references/report_template.md。OKR 自评评分方法论详见 references/okr_scoring_guide.md。
板块 1：整体概况
用一段 200-300 字高度精炼文字概括：
- 核心工作重心（从 OKR 提炼，1-2 个关键词）
- 投入时间最多的项目领域（基于日历/任务数据分析）
- 整体产出节奏（按季度/月度，基于审批/文档时间分布）
- 关键量化指标（审批数、会议数、日历日程数、文档数等）
- 数据覆盖率：XX 个 KR 中有飞书数据支撑 vs 无数据的比例
初稿规则：使用客观数据，避免「成效显著」「成果丰硕」等主观形容词。
格式要求：飞书 XML 使用
板块 2：OKR 达成复盘 + 严谨自评（重点）
这是 V4 的核心增强板块。 逐条列出每个 Objective 及其下所有 Key Results，包含三个层次的分析：
层次一：KR 状态表（含判断）
### Objective [编号]: [名称] (权重 X%) | KR | 指标描述 | 目标值 | 当前值 | 完成度 | 状态 | 判断依据 | |----|---------|--------|--------|--------|------|---------| | KR1 | ... | 6 | 8 | 133% | ✅ 超额 | 审批记录 8 条，超额 33% | | KR2 | ... | 20 | 17 | 85% | ⚠️ 部分达成 | Base 记录 17/20 | | KR3 | ... | 10 | 4 | 40% | ❌ 严重滞后 | OKR 系统 40%，3月后无更新 | | KR4 | ... | 5 | - | 0% | ⬜ 无数据 | 飞书中未找到任何推进记录 |
V4.2 新增：完全无数据的 KR 行，目标值填写 OKR 中的目标描述，当前值填
-，完成度填0%，状态标记为「⬜ 无数据」，判断依据注明「飞书中未找到相关数据，请补充」。
层次二：OKR 严谨自评打分表
| KR | 自评得分 | 赋分依据 | 数据来源 | |----|---------|---------|---------| | KR1 | 9/10 | 审批记录显示完成 8 个案例（目标 6 个），超额 33%；文档《XXX案例集》记录完整产出 | 飞书审批 + 文档 | | KR2 | 7/10 | 日历显示 6/28 完成上线（目标 6/30），按时交付；但 Base 中记录 2 个遗留问题待修复 | 飞书日历 + Base | | KR3 | 4/10 | OKR 系统进度仅 40%；审批中未发现相关推进记录；日历中 H1 仅 3 次相关会议 | 飞书 OKR + 审批 + 日历 | | KR4 | N/A | 飞书中未找到任何相关数据，无法赋分。已获取信息：OKR 系统中有目标描述。需要补充的信息：[具体说明] | - |
自评打分规则：
- 严格依据飞书实际数据赋分，不凭感觉
- 每条 KR 必须列出赋分依据（引用具体数字或时间戳）
- 赋分依据不足时给出保守分数，标注「数据支撑不足，分数偏保守」
- 完全无数据时不自评，标注「N/A - 无数据支撑」
- 评分锚点：10分远超预期，8-9分超额，6-7分达标，4-5分部分达标，1-3分严重滞后，N/A 无数据
自评汇总：
自评总得分：30/40（7.5 平均分）【4 个 KR 可赋分，1 个 N/A 排除】 整体达成率：75.0% 覆盖率：80%（4/5 KR 有数据支撑） | Objective | KR数 | 可赋分KR | O级得分 | 权重 | |-----------|------|---------|---------|------| | O1 | 3 | 2 | 8.14/10 | 60% | | O2 | 2 | 2 | 7.20/10 | 40% | | **合计** | **5** | **4** | **7.66/10** | **100%** | ⚠️ O1-KR3 因飞书中无数据暂不赋分，待用户补充数据后重新计算。 ⚠️ *本评分由 AI 基于飞书数据生成，仅供参考，最终评分请结合人工复核。*
层次三：归因分析（含判断）
对每个 KR 给出归因判断，而非列出候选方向等用户选择：
**✅ 已完成 KR 的成功因素判断：** - KR1: 超额完成。判断依据：审批记录显示 1-6 月持续稳定推进（每月 1-2 条），日历显示 6 次相关专题会议，节奏稳定。 **❌ 未达成 KR 的归因判断：** - KR3 (完成度 40%, 自评 4/10): 归因判断：优先级战略转移 判断依据： 1. OKR 系统 3月15日后无进度更新（此前每月更新） 2. 日历显示 1月3次→3月1次→4-6月0次相关会议，呈递减趋势 3. 同期 IM 中出现新项目 X 讨论（3月起密集，占比从 5%→40%） 请确认或修正。 **⬜ 无数据的 KR：** - KR4 (完成度 0%): 归因判断：无法判断（飞书中无数据支撑） 需要用户补充：该 KR 的实际推进情况、是否有飞书以外的记录。
归因判断规则：
- 基于数据模式给出判断（参考原则 7 的归因数据模式表）
- 必须列出判断依据（至少 2 条数据支撑）
- 如果数据模式不明确，给出倾向性判断并标注「归因依据不充分，倾向判断为 X」
- 如果数据完全矛盾，标注「数据矛盾，无法判断」并请用户补充
- 完全无数据时，不猜测归因，标注「无法判断 - 飞书中无数据」并请用户补充背景
确认后的深度展开（Phase 3）：
- 用户逐一确认归因后，补充更深层的分析
- 如有新数据支撑，修正自评分数和归因判断
格式要求：飞书 XML 使用
板块 3：亮点与不足（深度剖析）
Made it（亮点，3 个）
初稿直接给出亮点判断（非候选），每个亮点包含：
- 亮点标题（一句话概括）
- 客观数据事实（引用飞书数据中的具体产出）
- 量化指标（如有）
- 判断依据（为什么判断为亮点）
### 亮点1: 项目执行流程标准化 **判断依据**： - 审批记录：H1 共 6 份项目方案审批通过（去年同期 0 份） - 日历数据：H1 共 20+ 场项目推进会议，均使用标准化流程 - 文档产出：《项目执行标准化手册》文档创建于 2/15，后续 3 次更新 - 量化指标：项目按期交付率 85%（行业平均 60-70%） 请确认或修正。
确认后的深度展开（Phase 3）：
- 引用具体飞书文档产出或会议结论
- 分析亮点成因（为什么能做好）
- 提炼可复用的经验
Missed（不足，2-3 个）
初稿直接给出不足判断（非可供探讨的方向），每个不足包含：
- 不足标题
- 数据中发现的异常/缺口（引用具体数据）
- 判断依据（为什么判断为不足）
- 归因判断（基于数据判断是主观还是客观原因）
### 不足1: 项目监测体系推进滞后 **判断依据**： - OKR 系统：进度仅 20%，最新更新 3/15 - 审批记录：H1 无监测相关审批 - 日历数据：H1 仅 2 次监测相关会议（1/20、3/15） - 文档搜索：未找到监测体系相关文档 **归因判断**：客观原因（资源分配冲突） - 判断依据：3月起日历中新项目 X 会议占比 40%，挤压了监测体系推进时间 - IM 记录显示 3/10 有关于"监测先放一放"的讨论 请确认或修正。
格式要求：亮点用
重要提示：归因判断必须基于数据，不能从数据推断「能力不足」「意识不够」等无数据支撑的主观评价。只引用数据事实，基于数据模式给出归因判断。
板块 4：下半年工作计划 & 甘特图
Q3 任务清单（6-10 项）：
- 基于未达成 KR 和用户业务重点给出任务建议
- 给出优先级和时间排期建议（基于 H1 数据模式判断）
- 标注「请确认或修正」
| # | 任务 | 优先级 | 时间 | 判断依据 | 预期产出 | |---|------|--------|------|---------|---------| | 1 | 监测体系搭建 | 高 | 7月 | H1 进度仅 20%，需优先补齐 | 覆盖 100% 项目 | | 2 | KR4 数据补充后纳入 | 待定 | 待定 | 需用户补充 KR4 数据后确定 | 待定 | 请确认优先级和排期，或修正任务内容。
飞书多维表格甘特图（Phase 4 执行，非 Phase 2）：
- 在飞书新建 Base
- 字段：任务名称（文本）、开始时间（日期）、截止时间（日期）、优先级（单选：高/中/低）、当前状态（单选：未开始/进行中/阻塞）
- 创建甘特图视图
- 将 Base 链接附在云文档本板块末尾
板块 5：补充数据来源
逐项标注本次分析的数据来源：
| 数据项 | 来源模块 | 时间周期 | 调取内容范围 | 工具路径 |
|---|---|---|---|---|
| OKR 数据 | 飞书 OKR | H1 | X 个周期，Y 个 O，Z 个 KR | lark-cli okr +cycle-list / +cycle-detail |
| 审批记录 | 飞书审批 | H1 | 薪资建议 X 条 + 离职 Y 条 | lark-cli approval instances initiated |
| IM 消息 | 飞书 IM | H1 | N 个关键群组消息 | lark-cli im +chat-messages-list |
| 日历日程 | 飞书日历 | H1 | X 条日程 | lark-cli calendar +agenda |
| 任务记录 | 飞书任务 | H1 | 个人 X 条 + 协作 Y 条 | lark-cli task +get-my-tasks |
| 文档产出 | 飞书文档/Wiki | H1 | X 篇文档 + Y 个 Wiki（用于OKR赋分） | search +docs / wiki +space-list |
| ... | ... | ... | ... | ... |
非飞书来源的数据单独标注为「用户口述」。
Step 2.2: 生成本地初稿（不输出到飞书）
⚠️ 关键：此步骤仅生成本地初稿，不输出到飞书云文档（见原则 8）
- 将报告转为飞书 XML 格式（参考
references/report_template.md格式规范） - 保存为本地文件（如
summary_content.txt，必须使用 XML 格式，不是纯文本） - 不调用
lark-cli docs +create或lark-cli docs +update - 在对话中预览初稿内容（可选）
Step 2.3: 开始逐一确认（对话形式，V4.2 关键变更）
⚠️ 此步骤以对话形式逐一确认，不使用批量清单。
按以下顺序逐一在对话框中等待用户确认，每次只确认一项，用户回复后再进入下一项：
第1轮：OKR 完成度确认（逐条 KR） → 【确认 1/5】O1-KR1 完成度... → 等待用户回复 → 【确认 2/5】O1-KR2 完成度... → ... → 【确认 0/5】O1-KR4 无数据，完成度 0%... → 等待用户补充数据 第2轮：OKR 自评分数（AI 一次性给出全部评分，不逐条确认） → AI 汇总展示所有 KR 评分及赋分依据，用户无需逐条确认 → 直接进入第3轮 第3轮：归因判断确认（逐条未达成/无数据 KR） → 【确认 1/2】O1-KR3 归因：优先级转移... → 【确认 2/2】O1-KR4 无数据，无法归因，请补充... 第4轮：亮点确认（逐个） → 【确认 1/3】亮点1：项目执行流程标准化... → ... 第5轮：不足确认（逐个） → 【确认 1/2】不足1：项目监测体系滞后... → ... 第6轮：Q3 计划确认（逐项） → ...
确认对话格式（每一项都在对话框中单独发送）：
【确认 {序号}/{总数}】{确认类型}: {判断内容}
判断: {基于数据的判断结果}
依据: {数据来源和具体数字}
请确认或修正。
数据完全缺失的项，确认格式不同：
【确认 {序号}/{总数}】{KR编号} 数据缺失
当前已获取信息: {列出飞书中找到的所有相关信息}
当前完成度: 0%（无数据支撑，不猜测）
需要您补充: {列明具体需要什么信息}
请补充数据或确认「该项本周期未推进」。
⏸️ Phase 2 结束 —— 等待用户逐一确认，不输出报告
Phase 3: 逐一确认与深度展开
这是整个流程中最关键的阶段。 用户在对话框中逐条确认或修正判断，然后深度展开。
Step 3.1: 逐条确认流程
- 按 Phase 2.3 的顺序，在对话框中逐条发送确认消息
- 每条确认消息发送后，等待用户回复，收到回复后再发送下一条
- 用户回复后立即处理：
- 「确认」→ 记录为已确认，发送下一条
- 修正内容（如「实际 90%，不是 85%」）→ 更新判断和依据，发送下一条
- 补充数据（如「KR4 的数据在外部系统中...」）→ 更新完成度/自评，发送下一条
- 「补充信息后再确认」→ 暂停该类型确认，先确认其他类型
- 一轮确认完成后，重新计算关联数据（如完成度变化→自评需重算）
- 全部确认完成后，进入深度展开
迭代规则：如果用户对某条确认有修正，可能影响后面的判断（如 KR 完成度从 85%→90%，自评可能从 6→7）。修正后立即更新所有关联数据，后续确认项基于最新数据发送。
Step 3.2: 典型迭代场景
| 场景 | 用户反馈 | 处理方式 |
|---|---|---|
| OKR 完成度修正 | "KR1 已完成，不是 85%" | 修正为 100%，更新依据，重新计算自评分数，重算总达成率 |
| 赋分依据补充 | "KR2 还有 Base 里的数据可以引用" | 补充赋分依据，确认是否调整分数 |
| 归因修正 | "不是优先级转移，是资源不足" | 修正归因判断，请用户补充资源不足的数据依据 |
| 亮点修正 | "这不是亮点，是常规工作" | 删除该亮点，从数据中重新寻找其他亮点 |
| 不足修正 | "这不是不足，有客观原因" | 修正归因判断，补充客观原因的数据依据 |
| 推断被指出 | "这个不是我的工作" | 立即删除，不辩解 |
| Q3任务调整 | "删除A，新增B和C" | 修正文档任务清单，同步甘特图 |
| 数据补充 | "KR4 的数据在外部系统里" | 标注「用户口述」，0%→用户提供的完成度，补充赋分依据，重新评估 |
| 确认未推进 | "KR4 本周期确实没推进" | 标注「用户确认本周期未推进」，完成度 0%，归因标注为「用户确认未推进」 |
Step 3.3: 深度展开
所有确认完成后，对以下板块深度展开：
OKR 自评深度展开：
### O1-KR3: [名称] — 自评 4/10，完成度 40% **赋分依据**： - OKR 系统最新进度：实际值 4，目标值 10，完成度 40% - 审批记录中 H1 未发现相关推进审批 - 日历显示 H1 仅 3 次与该 KR 相关的会议（1月15日、3月8日、5月20日） - 文档搜索未找到相关产出文档 **分数说明**：4分 = 部分达标（完成度 40%），有推进但差距明显 **数据支撑充分度**：高（4 项数据源一致指向低完成度）
归因深度展开：
### O1-KR3: [名称] — 完成度 40%，自评 4/10，未达成 **归因判断**：优先级战略转移（用户已确认） **数据事实**： - OKR 系统进度记录：3月15日后无更新（此前每月更新） - 日历时间分配：该 KR 相关工作 1月占 15%→3月占 5%→4-6月占 0% - IM 讨论：3月起新项目 X 讨论占比从 5%→40% - 同期新项目 X 审批记录：3月起 8 条相关审批 **影响分析**：该 KR 的停滞直接影响了 O1 的整体达成率，若按原计划推进，O1 得分可从 8.14 提升至 9.0+
亮点深度展开：
### 亮点1: [标题] **事实依据**： - 飞书文档《XXX》：[引用具体产出] - 审批记录显示：[量化支撑] **量化指标**：XX 数据达到 XX，超出/达到预期 **亮点成因**：[用户确认] **可复用经验**：[可迁移到其他场景的经验]
不足深度展开：
### 不足1: [标题] **事实依据**： - 群消息《XXX》：[引用原文] - 审批/Base 数据：[量化数据支撑] **归因判断**：[基于数据判断的主观/客观原因]（用户已确认） **改进方向**： 1. [具体改进措施] 2. [时间节点]
Step 3.4: 输出总结报告到飞书（仅在所有确认完成后执行）
⚠️ 此步骤仅在用户确认完成后执行（见原则 8）
判断「用户确认完成」的标准：
- 用户明确说「确认无误」「可以输出」「没问题」「通过」
- 或所有逐条确认项均已回复「确认」
执行步骤：
- 将最终确认后的报告（含所有修正和深度展开）转为飞书 XML 格式
- 保存为本地文件（如
summary_content_final.txt） - 写入云文档：
- 用户指定已有文档 →
lark-cli docs +update --doc--command overwrite --content @./summary_content_final.txt - 用户未指定文档 →
lark-cli docs +create创建新文档（不覆盖 aily 草稿）
- 用户指定已有文档 →
--content "@file"必须使用相对路径，先cd到文件所在目录- 返回飞书文档链接给用户
重要：如果用户未明确确认完成，继续执行逐一确认流程，不执行此步骤。
Phase 4: 甘特图生成（Base 多维表格）
Q3 任务确认后，在飞书创建多维表格 Base 并生成甘特图视图。
字段设计
| 字段 | 类型 | 说明 |
|---|---|---|
| 任务名称 | 文本 | Q3 任务描述 |
| 开始时间 | 日期 | 计划开始日期 |
| 截止时间 | 日期 | 计划完成日期 |
| 优先级 | 单选 | 高 / 中 / 低 |
| 当前状态 | 单选 | 未开始 / 进行中 / 阻塞 |
创建流程
# 1. 创建 Base lark-cli base +create --name "Q3工作计划_甘特图" # 2. 获取 Base token 和默认表 ID lark-cli base +table-list --base-token--format json # 3. 添加字段 # 任务名称 → 文本字段（默认表已有"文本"列可用） # 开始时间 → lark-cli base +field-create --base-token --table-id --field-name "开始时间" --field-type "datetime" # 截止时间 → 同上 # 优先级 → lark-cli base +field-create --base-token
--table-id --field-name "优先级" --field-type "select" --property '{"options":[{"name":"高","color":1},{"name":"中","color":2},{"name":"低","color":3}]}' # 当前状态 → lark-cli base +field-create --base-token
--table-id --field-name "当前状态" --field-type "select" --property '{"options":[{"name":"未开始","color":1},{"name":"进行中","color":2},{"name":"阻塞","color":0}]}' # 4. 逐条写入记录（使用 +record-upsert 不带 --record-id） lark-cli base +record-upsert --base-token
--table-id --json '{"fields":{"任务名称":"任务A","开始时间":"2026-07-01 00:00:00","截止时间":"2026-07-31 00:00:00","优先级":"高","当前状态":"未开始"}}' # 5. 创建甘特图视图 lark-cli base +view-create --base-token
--table-id --view-type gantt --view-name "甘特图" # 6. 将 Base 链接附在云文档板块 4 末尾
常见错误
错误做法 正确做法 lark-cli base +record-addlark-cli base +record-upsert（不带 record-id）lark-cli base +record-batch-create逐条 +record-upsertlark-cli base +record-list默认格式lark-cli base +record-list --format json字段值用中文字符串直接传 用 --json '{"fields":{...}}'传🛠️ 工具能力声明（allowed-tools）
本技能声明以下工具依赖，所有工具调用均受
allowed-tools白名单约束：
工具/依赖 可用范围 禁止用途 不可用时处置 Bash(lark-cli:*) 仅限 lark-cli前缀的飞书 CLI 命令（审批/IM/日历/文档/Base/OKR/任务/VC/妙记/邮件）❌ 通用 Bash 命令、Python/Node.js 脚本、 curl等非 lark-cli 命令提示用户手动访问飞书后台获取数据，或引导完成 device_flow 授权 Read 读取本地参考文件（ references/、scripts/）和本地生成的临时文件（summary_content.txt）❌ 读取 ~/.ssh、~/.aws、系统配置文件等敏感目录提示文件路径错误，请用户确认文件存在 Write 生成本地临时文件（ summary_content.txt等 XML 格式初稿）❌ 覆盖已有飞书文档、修改用户原始数据 降级到对话中直接输出内容 WebFetch 仅限飞书开放平台官方文档（ open.feishu.cn）和技术公益官方站点（techforgood.qq.com）❌ 任意 URL、第三方网站 提示用户手动查阅对应网页 ⚠️ 核心依赖：
lark-cli是本技能的数据源命脉。若lark-cli整体不可用（未安装/未授权），技能将无法执行 Phase 1 数据调取，需引导用户完成安装和授权流程（见references/auth_guide.md）。🛡️ 失败降级机制（统一规则）
失败类型 阈值 降级动作 lark-cli 权限不足（模块未授权） 1 次 生成授权链接引导用户 devic 更多相关专题
Go-Zero API开发使用教程本专题聚焦Go-Zero的API开发，拆解.api描述文件的语法结构、路由与分组定义、参数绑定与校验规则，说明统一响应体、JWT鉴权、跨域与接口文档生成的落地方式，并给出网关聚合与接口测试的实践建议。
2026.11.12
0
15
Go-Zero安装与goctl环境配置教程本专题围绕Go-Zero的安装与工具链配置展开，讲清Go版本要求、goctl安装方式、代理镜像、protoc依赖与环境变量设置，说明多版本共存、升级回退与CI流水线安装的做法，并整理安装阶段的常见报错与验证步骤。
2026.11.12
0
15
Go-Zero零基础入门教程本专题整理Go-Zero的入门知识，从框架定位、环境准备到跑通第一个API服务，讲清目录分层、配置加载、日志与中间件的基本用法，并对比Gin、Kratos的差异，帮助Go开发者建立整体认知，判断它是否适合当前项目。
2026.11.12
0
15
Postman身份认证怎么配置本专题从实际API接口调试场景出发，讲解Postman身份认证的完整配置流程，包括常见认证协议介绍、授权参数设置、访问令牌填写、OAuth 2.0授权及认证失败排查，帮助用户正确完成接口授权与访问验证。
2026.11.06
0
12
Postman请求头Headers怎么设置围绕Postman HTTP请求头配置展开，讲解Headers选项的具体使用方式，包括Key和Value参数填写、请求头信息添加、常见Header字段设置及请求头修改方法，帮助用户解决接口调试过程中遇到的请求头配置问题。
2026.11.06
0
13
Postman接口请求发送教程详细介绍Postman接口请求的创建与发送方法，涵盖GET和POST请求、URL配置、请求参数、Headers请求头、Body请求体设置以及响应结果查看，帮助用户掌握Postman接口请求的完整操作流程。
2026.11.06
0
10
DBeaver怎么导入数据DBeaver数据导入专题，整理Excel、CSV、SQL、TXT等常见文件的数据导入方法，涵盖目标数据库选择、数据表创建、字段映射、数据类型设置及导入参数配置等操作，帮助用户将本地文件中的数据写入数据库，并了解批量导入、重复数据处理和导入失败等常见问题的解决方法。
2026.11.05
0
12
DBeaver安全防护教程大全DBeaver安全防护专题，围绕数据库连接安全、账号密码保护和访问权限管理展开，整理SSL/TLS加密连接、SSH隧道、数据库凭据保存及证书验证等配置方法，同时介绍敏感信息保护、远程连接风险和高权限账号使用等注意事项，帮助用户提高数据库日常管理的安全性。
2026.11.05
0
12
DBeaver连接创建与配置教程本专题聚焦DBeaver数据库连接配置与管理，覆盖从新建连接、选择数据库类型到填写连接参数和验证连接的完整流程。针对MySQL、PostgreSQL、SQL Server等常见数据库，整理相应的连接设置方法，并提供驱动缺失、认证失败和连接异常等问题的排查方向。
2026.11.04
0
16
更多热门下载
更多相关下载
更多精品课程
相关推荐/热门推荐/最新课程更多最新文章
