haizei-okr-writing

v2026.09.24

OKR 目标与举措撰写及润色技能。当用户需要编写季度 OKR、SMART 目标、PDCA 举措、个人行为描述,或要求将汇报话术改得更实在、更像本人表达时使用。适用于 AI 研发、产品、平台集成和代码质量等工作场景。

GitHub
安装命令
npx skhub add wuchubuzai2018/haizei-okr-writing
Markdown
SKILL.md

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 条举措能形成从问题识别、落地、检查到迭代沉淀的闭环。
  • 术语、平台能力和指标口径没有凭空编造。
  • 语言能直接给领导或填入系统,不像对读者解释写法的说明稿。
发现
标签

此技能尚未发布标签。

版本
最新版本元数据

版本

v2026.09.24

发布时间

2026年9月24日

分类

未分类

许可证

未指定

源路径

skills/haizei-okr-writing

默认分支

main

最新提交

bff644e

Tree SHA

d296d16