Goal 这个词最近确实火。Claude Code 和 Codex 里都有了，官方文档也把它放在长任务、迁移、重构、实验这类场景里讲。
它的意思很清楚——给 AI 一个能持续对照的目标，别让它每一步都靠人重新提醒。
但问题也在这。很多人一听 goal 重要，立刻把它写成一段超级长的提示词。角色、背景、步骤、约束、验收、风险全塞进去。看着专业，复制进去以后，AI 也显得很认真。
然后它开始一路认真地跑偏。你本来只想修一个问题，它开始整理全仓库；你本来只想重构一小块，它开始抽象架构；你本来只想让它写个目标，它已经准备继续改文件了。
这就是 GoalPro 诞生的原因。
先装起来，别先背概念
GoalPro 是一个给 Codex 和 Claude Code 共用的 goalpro Skill。Skill 可以先理解成一套能被 AI 调用的工作方法，它不是普通模板，也不是执行工具，而是执行前把目标写清楚的规则。
它同时支持两套目录。Codex 看 .agents/skills/goalpro，Claude Code 看 .claude/skills/goalpro。你可以装到用户全局 skills 目录，也可以放进某个项目里，只给这个项目用。
最省事的方式，是直接让 AI 帮你装。复制这一句就够：
请帮我把GoalPro安装到这台电脑的Codex和Claude Code全局skills里。项目地址是github.com/KimYx0207/GoalPro。先确认当前系统和工作目录，如果仓库还没下载就从GitHub获取，然后把.agents/skills/goalpro复制到用户目录下的.agents/skills/goalpro，把.claude/skills/goalpro复制到用户目录下的.claude/skills/goalpro。最后读取两个SKILL.md开头，确认name是goalpro，并告诉我安装结果。
如果你想手动装，Win 和 Mac 分开看，别混着抄。
Windows 用 PowerShell：
git clone https://github.com/KimYx0207/GoalPro.git
cd GoalPro
New-Item -ItemType Directory -Force "$env:USERPROFILE\.agents\skills" | Out-Null
Copy-Item -Recurse -Force ".agents\skills\goalpro" "$env:USERPROFILE\.agents\skills\goalpro"
New-Item -ItemType Directory -Force "$env:USERPROFILE\.claude\skills" | Out-Null
Copy-Item -Recurse -Force ".claude\skills\goalpro" "$env:USERPROFILE\.claude\skills\goalpro"
Mac 和 Linux 用 Bash：
git clone https://github.com/KimYx0207/GoalPro.git
cd GoalPro
mkdir -p ~/.agents/skills ~/.claude/skills
cp -R .agents/skills/goalpro ~/.agents/skills/goalpro
cp -R .claude/skills/goalpro ~/.claude/skills/goalpro
如果你只是想在某个项目里试，就不用装到全局。把 .agents/skills/goalpro 放进目标项目给 Codex 用，把 .claude/skills/goalpro 放进目标项目给 Claude Code 用。
这里不用把命令想复杂。真正要记住的是，GoalPro 装进去以后，它的任务不是替你干活，而是先把活说清楚。
技术含量在五个闸门里
GoalPro 不是把提示词写长。它真正做的是给 AI 动手前加五个闸门。
第一个是意图。用户说优化项目，背后可能是不满意可维护性，也可能是不满意交付可信度，还可能是前一个 AI 已经跑偏。GoalPro 不能复述用户原话，它要把真实不满翻出来。
第二个是边界。哪些做，哪些不做，哪些文件不能碰，哪些风险必须问人。没有边界，AI 会把自己的合理扩展当成你的需求。
第三个是证据。命令通过、结构检查、本地验证、线上验证、人工验收，这几件事不能混在一起。很多假完成，就是把其中一个当成全部。
第四个是暂停。遇到删除数据、处理密钥、改公共接口、发布上线、路线互斥、无法验证，它必须停。这个停不是软建议，是写进目标里的规则。
第五个是验收。最后不是汇报“我努力了”，而是交出能证明目标达成的材料。测试、截图、diff、行为变化、剩余风险，都要和用户最初的目标对上。
这里面最值得重视的是第三和第四。因为 AI 现在最吓人的地方，不是它懒，是它太勤快。方向一旦歪，它会非常认真地把错误做完整。
用起来，其实是一条很短的路径
装完以后，你可以这样问：
用goalpro，帮我把下面这个请求整理成可执行、可验证、可暂停的Goal Contract：把订单模块重构一下，现在太乱了。
GoalPro 会输出一份 Goal Contract。你确认没问题，再把它交给 Codex 的 /goal、Claude Code 或其他 Agent 执行。
注意这个顺序。GoalPro 默认只输出可复制的 goal 提示词，然后停住——这是强制规定，人该检查的时候不能偷懒。
它不会因为目标里写了 Execution policy、Verification、Checkpoints，就继续替你改文件。用户没有明确说按这个 goal 执行，它就不能执行。
这是故意设计的 prompt-only 闸门。Skill mention 不等于执行授权。你说 goalpro，它就写目标；你说按这个目标执行，它才进入下一轮执行任务。
这个边界看起来有点保守，但真实项目里很有用。
因为很多失控不是从大错误开始的，而是从一句顺手的“我来继续”开始的。
为什么我不把它做成自动执行工具
有人可能会问，既然 GoalPro 能写得这么清楚，为什么不顺手执行？
这里需要想清楚一件事：目标生成和任务执行是两件事。目标生成阶段，最怕的是越权；执行阶段，最怕的是没有目标。把两件事混在一起，体验上确实省一步，但边界会变糊。
GoalPro 的默认交付物是一段可复制的 goal 提示词。它写完就停。你可以复制到 Codex 的 /goal 里，也可以发给 Claude Code，也可以交给另一个 Agent。只有你明确授权，它才进入新的执行任务。
好的 goal 要有清楚的完成条件、验证方式和停止规则，适合那些比一条 prompt 更长、但又不能无限发散的任务。
AI 越来越能干以后，人最容易偷懒的地方，不是把步骤交给 AI，而是把目标也交给 AI。GoalPro 干的事，就是把这个目标重新拿回人手里。
谁该用，谁没必要用
小任务别上 GoalPro。改一个错别字、查一个文件名、补一句文案，直接让 AI 做就行。流程太重，会拖慢你。
但只要任务会跨文件、跨模块、影响发布、牵涉外部事实、需要研究判断，或者你自己都觉得这事容易跑偏，就该先写 Goal Contract。
它特别适合三类人。
一类是经常用 Codex 或 Claude Code 做项目的人。你不缺 AI 能力，缺的是让 AI 少乱跑的边界。
一类是做内容、方案、课程、产品文档的人。你不一定每天写代码，但你会把大任务交给 AI，这时候更需要先讲清验收。
还有一类，是已经被 AI 长任务折磨过的人。你看着它很努力，最后却不知道它到底完成了什么。GoalPro 就是给这种场景准备的。
最后留一句
这两年越来越少相信“万能提示词”。
万能提示词最容易让人产生错觉，以为只要写得够全，AI 就会按人的意思走。真实情况更粗糙一点：目标没写对，提示词越全，跑偏越稳。
GoalPro 不是让 AI 少干活。
它是让 AI 先确认，自己到底在替谁、为了什么、按什么证据干活。
人负责目标、判断、取舍和验收。AI 负责搜索、生成、执行和检查。最后要的不是模型自己觉得合理的结果，而是符合人类目标的结果。
这个边界如果守不住，再强的 Agent 也只是跑得更快。
跑得更快，有时候不是进步。
是更难追回来。
