haizei-okr-writing

Imported from wuchubuzai2018/expert-skills-hub (skills/haizei-okr-writing/SKILL.md). Install upstream with npx skills add wuchubuzai2018/expert-skills-hub --skill haizei-okr-writing. Copyright stays with the author (MIT).

OKR 撰写与润色技能

技能用途

将零散的工作想法、领导给出的方向或已有实践，整理为可以直接填入 OKR 系统的目标和举措。输出既要满足 SMART 和 PDCA，也要保留具体工作内容，使用本人视角表达，避免写成解释材料、口号或对他人的要求。

适用触发词包括：OKR、季度目标、举措、SMART、PDCA、个人行为、目标名称、领导汇报话术、润色举措。

核心原则

1. 目标必须可验收

目标不是方向标签。目标句至少包含以下信息：

• 时间范围：例如 Q3、9 月底前。
• 工作对象：例如 AI 代码审查、端到端 PRD 生成、跨 Session 记忆。
• 应用范围：例如不少于 3 个需求、实际开发提交、指定业务域。
• 可验证结果：例如准确率、复用率、数量、完成轮次或交付物。

优先使用以下句式：

Q3 在 [范围] 中完成 [具体动作]，形成/达到 [可衡量结果]，并在 [时间点] 前完成 [交付物或复盘]。

没有可靠历史数据时，不虚构“提升 20%”等对比指标；改用覆盖数量、有效素材数、试点次数、复盘次数或可交付物数量。

2. 举措必须是“本人能做的事”

举措以“我会”或“我将”开头，清楚说明本人要采取的动作、怎样做、留下什么证据。不要把举措写成向团队下指令、介绍一个体系，或描述他人应当做什么。

每条举措建议使用 1 个自然段，控制在 120 至 220 字。保留足够的业务细节，让读者能看出工作不是空话。

推荐结构：

我会先/持续 [本人动作]，针对 [场景或已有问题] 采用 [具体做法]，
并记录/交付 [可检查证据]；在 [时间或节奏] 根据 [反馈或数据] 调整，
以支撑 [目标中的结果]。

3. 用 PDCA 组织 4 条举措，但不必把缩写写进正文

将 4 条举措自然组织为闭环：

1. P，找准问题：盘点已有实践、基线、拒绝原因或适用范围。
2. D，真实落地：在真实需求、代码提交或平台功能中完成试点。
3. C，检查结果：记录采纳情况、问题类型、评审反馈、测试证据或指标变化。
4. A，持续固化：按周或双周优化，将有效经验沉淀为规则、Skill、Agent、模板、用户偏好或项目知识。

如果用户已经完成部分工作，应从已有成果出发写“继续提升”，不把 Q3 写成从零建设。

4. 保留“像人”的表达

可以使用简短的拟人化小标题帮助阅读，例如“先把地基打牢”“守住质量底线”“用数据证明结果”，但标题后必须接具体动作和事实。

使用自然、专业的中文：

• 好：我会把 Q2 被拒绝的问题按误报、上下文不足和规则不适用分类，再据此调整审查记忆。
• 不好：构建全链路智能化质量赋能体系，全面提升协同效能。
• 好：写完不验证不算完成，我会保留构建、测试和评审结果。
• 不好：要求团队严格执行五道门禁。

避免过多的四字口号、堆叠概念和“赋能、抓手、闭环、全链路”等词。需要使用这些词时，后面必须紧跟实际动作或结果。

工作流程

第一步：提取事实

从用户描述中识别并列出：

• 当前已经完成的实践，以及本季度是新建还是继续优化。
• 领导给出的方向、已知平台能力和不能臆测的能力边界。
• 可量化的指标、时间节点、试点范围和已知数据基线。
• 最终用途：系统填写、领导汇报、个人工作计划或团队复用。

缺少关键口径时，用稳妥、可验收的数量型结果替代虚构的提升比例，并在必要时给出一个待确认项。

第二步：先给目标，再给举措

默认输出顺序：

1. 目标名称/目标描述：一段完整 SMART 句子，可直接填入系统。
2. 4 条举措：每条 1 个自然段，第一人称，按 P-D-C-A 递进。
3. 可选口径说明：仅在准确率、复用率等计算方式可能有歧义时，用一两句定义，不展开讲课。

若用户只要“目标名称”，只输出一条 SMART 目标句和一个无基线时的保守备选，不扩写举措。

第三步：根据任务类型补足实质内容

AI 代码审查

• 以 Q2 已有结果为输入，先盘点采纳/拒绝问题及其原因。
• 将已验证的规则、历史缺陷和业务约束接入 Memory；借助 CodeGraph 补足调用链和依赖上下文。
• 在真实提交中记录每条问题的采纳、拒绝、类型与处理结果。
• 每周盘点拒绝问题和理由，每双周调整提示词、规则、Memory 或 CodeGraph 范围。
• “准确率”默认定义为：被采纳或确认需要修复/纳入修复计划的问题数 ÷ AI 提出的问题总数。

AI 生图与端到端 PRD 生成

• 先确认端到端平台的输入、输出、图文挂载方式和边界，不能假定平台已有某项能力。
• 将 PRD 中流程、角色、页面状态、异常规则整理为图文一致的结构化输入。
• 在真实 PRD 中完成“图示生成 - 平台生成 - 评审 - PRD 回写”的验证。
• 记录生成偏差与反馈，沉淀提示词、图文模板和可复用操作指引。

跨 Session 记忆

• 会话结束时只沉淀经需求确认、代码验证或测试支撑的经验。
• 分类为项目规则、业务知识、用户偏好、调试经验、审查规则或 Skill/Agent 候选项。
• 下次会话按项目、模块和触发条件检索相关记忆，不把全部历史信息塞入上下文。
• 对重复出现且多次验证有效的经验，经人工确认后升级为正式规则、Skill、Agent、审查规则或用户偏好。

输出模板

## 目标 [序号]：[一句完整 SMART 目标]

**举措 1：[自然的小标题]**
我会……

**举措 2：[自然的小标题]**
我会……

**举措 3：[自然的小标题]**
我会……

**举措 4：[自然的小标题]**
我会……

交付前自检

• 目标写出了时间、范围、结果和至少一个可验证口径。
• 每条举措都是本人能直接执行的行为，没有变成“要求团队”或“平台必须”。
• 内容基于用户给出的已有实践，没有把“继续提升”写成“从零搭建”。
• 4 条举措能形成从问题识别、落地、检查到迭代沉淀的闭环。
• 术语、平台能力和指标口径没有凭空编造。
• 语言能直接给领导或填入系统，不像对读者解释写法的说明稿。