wuchubuzai2018 OKR 撰写与润色技能
技能用途
将零散的工作想法、领导给出的方向或已有实践，整理为可以直接填入 OKR 系统的目标和举措。输出既要满足 SMART 和 PDCA，也要保留具体工作内容，使用本人视角表达，避免写成解释材料、口号或对他人的要求。
适用触发词包括：OKR、季度目标、举措、SMART、PDCA、个人行为、目标名称、领导汇报话术、润色举措。
核心原则
1. 目标必须可验收
目标不是方向标签。目标句至少包含以下信息：
- 时间范围：例如 Q3、9 月底前。
- 工作对象：例如 AI 代码审查、端到端 PRD 生成、跨 Session 记忆。
- 应用范围：例如不少于 3 个需求、实际开发提交、指定业务域。
- 可验证结果：例如准确率、复用率、数量、完成轮次或交付物。
优先使用以下句式：
Q3 在 [范围] 中完成 [具体动作]，形成/达到 [可衡量结果]，并在 [时间点] 前完成 [交付物或复盘]。
没有可靠历史数据时，不虚构“提升 20%”等对比指标；改用覆盖数量、有效素材数、试点次数、复盘次数或可交付物数量。
2. 举措必须是“本人能做的事”
举措以“我会”或“我将”开头，清楚说明本人要采取的动作、怎样做、留下什么证据。不要把举措写成向团队下指令、介绍一个体系，或描述他人应当做什么。
每条举措建议使用 1 个自然段，控制在 120 至 220 字。保留足够的业务细节，让读者能看出工作不是空话。
推荐结构：
我会先/持续 [本人动作]，针对 [场景或已有问题] 采用 [具体做法]，
并记录/交付 [可检查证据]；在 [时间或节奏] 根据 [反馈或数据] 调整，
以支撑 [目标中的结果]。
3. 用 PDCA 组织 4 条举措，但不必把缩写写进正文
将 4 条举措自然组织为闭环：
- P，找准问题：盘点已有实践、基线、拒绝原因或适用范围。
- D，真实落地：在真实需求、代码提交或平台功能中完成试点。
- C，检查结果：记录采纳情况、问题类型、评审反馈、测试证据或指标变化。
- A，持续固化：按周或双周优化，将有效经验沉淀为规则、Skill、Agent、模板、用户偏好或项目知识。
如果用户已经完成部分工作，应从已有成果出发写“继续提升”，不把 Q3 写成从零建设。
4. 保留“像人”的表达
可以使用简短的拟人化小标题帮助阅读，例如“先把地基打牢”“守住质量底线”“用数据证明结果”，但标题后必须接具体动作和事实。
使用自然、专业的中文：
- 好：
我会把 Q2 被拒绝的问题按误报、上下文不足和规则不适用分类，再据此调整审查记忆。 - 不好：
构建全链路智能化质量赋能体系，全面提升协同效能。 - 好：
写完不验证不算完成，我会保留构建、测试和评审结果。 - 不好：
要求团队严格执行五道门禁。
避免过多的四字口号、堆叠概念和“赋能、抓手、闭环、全链路”等词。需要使用这些词时，后面必须紧跟实际动作或结果。
工作流程
第一步：提取事实
从用户描述中识别并列出：
- 当前已经完成的实践，以及本季度是新建还是继续优化。
- 领导给出的方向、已知平台能力和不能臆测的能力边界。
- 可量化的指标、时间节点、试点范围和已知数据基线。
- 最终用途：系统填写、领导汇报、个人工作计划或团队复用。
缺少关键口径时，用稳妥、可验收的数量型结果替代虚构的提升比例，并在必要时给出一个待确认项。
第二步：先给目标，再给举措
默认输出顺序：
- 目标名称/目标描述：一段完整 SMART 句子，可直接填入系统。
- 4 条举措：每条 1 个自然段，第一人称，按 P-D-C-A 递进。
- 可选口径说明：仅在准确率、复用率等计算方式可能有歧义时，用一两句定义，不展开讲课。
若用户只要“目标名称”，只输出一条 SMART 目标句和一个无基线时的保守备选，不扩写举措。
第三步：根据任务类型补足实质内容
AI 代码审查
- 以 Q2 已有结果为输入，先盘点采纳/拒绝问题及其原因。
- 将已验证的规则、历史缺陷和业务约束接入 Memory；借助 CodeGraph 补足调用链和依赖上下文。
- 在真实提交中记录每条问题的采纳、拒绝、类型与处理结果。
- 每周盘点拒绝问题和理由，每双周调整提示词、规则、Memory 或 CodeGraph 范围。
- “准确率”默认定义为：被采纳或确认需要修复/纳入修复计划的问题数 ÷ AI 提出的问题总数。
AI 生图与端到端 PRD 生成
- 先确认端到端平台的输入、输出、图文挂载方式和边界，不能假定平台已有某项能力。
- 将 PRD 中流程、角色、页面状态、异常规则整理为图文一致的结构化输入。
- 在真实 PRD 中完成“图示生成 - 平台生成 - 评审 - PRD 回写”的验证。
- 记录生成偏差与反馈，沉淀提示词、图文模板和可复用操作指引。
跨 Session 记忆
- 会话结束时只沉淀经需求确认、代码验证或测试支撑的经验。
- 分类为项目规则、业务知识、用户偏好、调试经验、审查规则或 Skill/Agent 候选项。
- 下次会话按项目、模块和触发条件检索相关记忆，不把全部历史信息塞入上下文。
- 对重复出现且多次验证有效的经验，经人工确认后升级为正式规则、Skill、Agent、审查规则或用户偏好。
输出模板
## 目标 [序号]：[一句完整 SMART 目标]
**举措 1：[自然的小标题]**
我会……
**举措 2：[自然的小标题]**
我会……
**举措 3：[自然的小标题]**
我会……
**举措 4：[自然的小标题]**
我会……
交付前自检
- 目标写出了时间、范围、结果和至少一个可验证口径。
- 每条举措都是本人能直接执行的行为，没有变成“要求团队”或“平台必须”。
- 内容基于用户给出的已有实践，没有把“继续提升”写成“从零搭建”。
- 4 条举措能形成从问题识别、落地、检查到迭代沉淀的闭环。
- 术语、平台能力和指标口径没有凭空编造。
- 语言能直接给领导或填入系统，不像对读者解释写法的说明稿。