如果你在文档、看板与会议工具里反复做OKR 跟踪，可以考虑把经验沉淀为一个 Skill：写清触发条件、步骤、输出格式和边界，让智能体代劳重复部分，人只负责把关。

「OKR 跟踪」技能出问题时，先别急着重写。按下面的表格对号入座，大部分问题都能在几分钟内定位。

症状对照表

症状常见原因处理办法
技能完全不触发描述没写触发条件；文件位置或文件名不对；平台未重新加载补写“当用户……时使用”；核对目录；新开会话
不该触发时触发描述过于宽泛缩小描述范围，写明不适用的情况
跳过步骤步骤写成段落，或步骤之间缺少依赖说明改成编号列表，写明每步产出
输出格式每次不同没有给出固定结构给出标题或表头模板，附一份范例
内容有编造没要求缺信息时提问；没要求标注依据加上“不确定标注需人工确认”
脚本或工具调用失败运行环境缺依赖、路径错误、权限不足单独运行脚本或工具排查，把错误原文反馈给智能体
越用越偏对话过长，早期指令被稀释新开会话，或把关键约束放在技能最前面

排查顺序

  1. 确认技能是否被加载（大多数平台会在回复或日志中显示使用了哪些规则或技能）
  2. 用标准样例复现问题
  3. 检查最近一次修改，必要时回退
  4. 一次只改一处，改完重跑测试用例

针对这个技能的特别检查

  • 输入是否真的是OKR 与数据，格式差异会导致后续步骤失败
  • “更新进度”这一步是否有足够信息
  • 是否混入了与本技能冲突的其他规则
  • 风险较低，但输出仍需快速过目再使用

什么时候该求助

如果确认是平台本身的问题（例如更新后入口变化、规则不再读取），查阅平台的官方文档与更新说明，比反复改技能更有效。

每一步要产出什么

把每一步的中间产出写清楚，智能体就不容易跳步，人也方便定位问题：

  1. 更新进度：产出一段简短的中间结果，并注明依据来自OKR 与数据的哪一部分
  2. 评估信心：产出一段简短的中间结果，并注明依据来自OKR 与数据的哪一部分
  3. 识别风险：产出一段简短的中间结果，并注明依据来自OKR 与数据的哪一部分
  4. 建议调整：产出一段简短的中间结果，并注明依据来自OKR 与数据的哪一部分

最后一步之后，再把这些中间结果汇总成进展报告。中间结果可以折叠或省略展示，但在技能指令中要求智能体“先完成再汇总”，能明显减少遗漏。

领域注意事项

「OKR 跟踪」属于产品与项目管理领域，使用者多是产品经理与项目经理，工作环境通常是文档、看板与会议工具。这个领域最重要的一条底线是：优先级与对外承诺需要团队确认。

建议把这条底线原样写进技能的约束部分，而不是指望智能体自己意识到。同时，在团队内部明确：智能体给出的进展报告只是初稿或建议，最终由谁签字确认、出了问题由谁负责。

延伸阅读

说明：文中的配置、代码与目录结构均为示意，用于说明思路；各平台的入口、字段名与能力会更新，落地前请以对应官方文档为准。示例中的数据与场景为虚构，不代表真实案例。