目标分解 是做什么的？
描述
将复杂目标分解为可执行检查点的最佳实践。
触发词
- goal
- plan
- long-term
- multi-step
- project
- achieve
- milestone
指令
分解原则
- 具体优于抽象 — 每个检查点应产出有形的工件或可验证的成果，而不是“思考X”
- 检查点数量（3-10个） — 太少则检查点过于复杂，太多则增加管理开销
- 行动前先调研 — 第一个检查点应始终收集信息
- 验证后再推进 — 将验证步骤作为success_criteria嵌入，而非独立检查点
- 先处理不确定性 — 将不确定或高风险的检查点提前，降低失败成本
成功标准规则
- 必须可客观验证 — “文件存在于路径X”、“找到3个职位”、“测试通过”
- 避免主观标准 — 不要使用“质量好”、“写得好”
- 尽可能包含数量 — “至少3个”、“不超过500字”
何时修订计划
- 新信息推翻原有假设（如公司不招聘）
- 某个检查点暴露计划缺少步骤
- 用户反馈改变方向
- 连续2个及以上检查点失败，表明方法有误
反模式
- 不要为少于5次工具调用即可完成的任务创建目标
- 不要创建依赖外部时间节点的检查点（如“等待回复”） — 应暂停目标并设置定时提醒以恢复
- 不要让一个检查点承担所有复杂性 — 如果某个检查点需要50次以上工具调用，应拆分它
示例
良好分解：求职申请
目标：“在X公司找到工作”
- 调研X公司（文化、技术栈、近期新闻） — 标准：写出总结
- 查找开放职位 — 标准：列出至少3个职位及链接
- 定制简历 — 标准：简历文件已更新，突出相关技能
- 撰写求职信 — 标准：求职信文件已创建，不超过400字
- 提交申请 — 标准：保存确认页截图
良好分解：作品集网站
目标：“帮我搭建一个作品集网站”
- 调研设计趋势并收集需求 — 标准：完成设计简报
- 搭建项目（Next.js + 部署目标） — 标准：项目脚手架就绪，开发服务器可运行
- 构建核心页面（首页、关于、项目） — 标准：3个页面能渲染且包含占位内容
- 添加实际内容和样式 — 标准：所有板块填充完整，移动端响应式
- 部署到生产环境 — 标准：线上URL可访问，无控制台报错
良好分解：安全审计
目标：“审计此代码库的安全漏洞”
- 扫描依赖项中的已知CVE — 标准：生成依赖报告
- 审查身份认证和会话管理 — 标准：记录认证流程，列出问题
- 检查注入漏洞（SQL、XSS、命令注入） — 标准：每个输入路径已测试
- 编写审计报告并标注严重等级 — 标准：报告文件已创建，发现项已排优先级
糟糕分解
目标：“在X公司找到工作”
- 做调研（过于模糊，无标准）
- 申请（过于宽泛，应拆分为多步）
- 等待回复（依赖外部时间节点）
验证
- 本阶段的交付物是具体工件（文档、事项、看板、仓库），且其位置已共享，而非仅口头描述
- 每个任务都有负责人、截止日期和完成标准（非作者以外的人也能检验）
- 风险已列出可能性/影响，并有具体的应对措施，而非泛泛的“风险：待定”
- 对其他团队/供应商/代理的依赖已明确，且每个依赖方均已确认或标记为“待确认”
- 下一阶段的成功标准是数字化的或可客观检验的
- 在开始工作前，已明确记录回滚/终止开关/“如果发生X则停止”的标准
备注
- 在创建目标前，始终检查goals/SKILL.md是否适用
- 目标系统会自动处理持久化、上下文和自动续跑
- 随时使用goal_status查询进度