goal-tracking：脱胎于 TRAE Code，适配 TRAE Work 的 /goal 技能，帮你省下 token
起因
事情是这样的。
我让 AI 做一个长期任务，跨好几轮对话的那种。AI 一开始没多想，干就完了。但干着干着发现一个问题：AI 没有一个"记住自己承诺"的机制。 上一轮说"接下来做这个"，下一轮可能就忘了。不是 AI 不努力，是 AI 确实没有这个能力——上下文压缩不是虚的，压缩完你还得重新录入，token 哗哗地没。
然后我看到了 /goal。但它没法在 TRAE Work 上用。
难受。于是我自己做了一个：/goal-tracking 。
这玩意儿是什么
一句话：goal-tracking 是一个帮 AI 跨轮追踪长期目标的系统。它让 AI 记住自己正在做什么、做到哪了、什么时候算做完、什么时候真的做不下去了。
听起来简单，但做到"靠谱"其实挺难的。
我见过太多假装在追踪的设计了。建个任务，打个勾，完事。但现实中的长期任务根本不是这样的——你做到一半发现方向偏了，或者卡住了，或者你觉得做完了其实根本没做完。goal-tracking 最让我喜欢的地方，就是它认真对待这些现实问题。
为什么它能节省 token
没有 goal-tracking 的时候，每一轮新对话你都得重新告诉 AI："我在做什么、做到哪了、接下来该干嘛。"上下文一压缩，之前的进度全丢，你得把背景、目标、已完成的部分重新喂一遍。轮次越多，重复越多，token 烧得越狠。
有了 goal-tracking，目标、进度、状态都被结构化地记在一个地方。新一轮对话开始，AI 查一下就知道自己在哪、该干嘛，不用你重新铺陈一大段。查询本身也是轻量的——一次 get_goal，拿到全部上下文，不用翻聊天记录，不用重建语境。
省的不是某一轮的 token，是每一轮都在重复交的那笔"重新理解税"。
三个核心动作
一、创建目标
用户说"帮我追踪一个目标"的时候，AI 才会创建。AI 不会自己猜。 “嗯，这个需求看起来像是个目标，先建一个再说”——不行，必须是显式要求。
创建时要记录完整的 objective。不能因为"哦这轮做不完"就把目标缩小一点。目标就是目标，做不完就做不完，下一轮继续，但目标不能缩水。这个原则我挺喜欢的，它逼 AI 诚实。
还有一个可选参数叫 token_budget。用户说"这个任务最多花 5000 token"，AI 就设上；否则不设。不给自己挖坑。
二、查询进度
任何时候用户问"做到哪了"，AI 都能回答。不是猜，是真能回答。当前目标是什么、状态是什么、进度到哪了、token 用了多少。无副作用，随便问。
三、更新状态
只有两个终态：complete 和 blocked。没有暂停，没有搁置，没有"差不多做完了"。你要么确实做完了，要么确实做不下去了。
但这两个状态都不能随便说。要过审计。
完成审计：最硬的一关
这是我最喜欢的设计。
标记 complete 之前，AI 必须证明自己真的做完了。逐条逐项，拿证据说话。
具体流程：从 objective 里拆出每个需求，然后对每个需求去找权威证据——文件内容、命令输出、测试结果、渲染产物、运行行为，都算。不是"AI 记得做过"，不是"AI 好像改过这个文件"，是 “现在这个文件的内容确实满足了这个需求”。
每一条，要么证明完成，要么证明矛盾，要么承认证据不够。不确定就算没完成，继续干活。
这个规则阻止了 AI 一件特别爱干的事：因为做得差不多了就宣告胜利。 没有这道审计门，AI 可能早就偷偷标记 complete 然后跑去干别的了。有了它，AI 必须老老实实把每件事核验完。
阻塞审计：别为困难找借口
blocked 也一样，不能随便说。
第一次遇到阻塞？不算。第二次同样的阻塞？也不算。第三次？还是不算。
必须是同一个阻塞条件连续出现至少三轮，而且 AI 确实没有任何办法推进了，这才叫 blocked。
而且达到阈值之后，AI 还不能直接放弃。AI 要先用 AskUserQuestion 问用户："我卡在这里了，你能帮我一下吗？"用户给了方向，继续推进；只有用户也帮不了，才标记 blocked。
这条规则阻止了 AI 另一件特别爱干的事：遇到困难就想放弃。“这个好难，我 blocked 了”——不行，你得先试三次，还得先问人。
从 TRAE Code 到 TRAE Work
这个技能不是从零写的。它脱胎于 TRAE Code 的 goal 系统，原版包含：
- 三个工具：
create_goal、get_goal、update_goal - 一套运行时行为规则：continuation、fidelity、work from evidence、completion audit、blocked audit
- 一份 README
但 TRAE Code 那套是三把独立的工具，每把有自己的描述文件、JSON Schema、调用方式。适配到 TRAE Work 原生环境时，我把三把合并成了一体：
三个工具 → 一个技能工作流。工具描述、JSON Schema、README 全部收敛成一个
SKILL.md，外加一个references/audit.md放审计模板。
改动不大。核心原则是：不保留形式，保留精神。
能力缺口
适配过程中有些东西没能完全带过来，如实交代：
| 缺口 | 原因 | 补偿方案 |
|---|---|---|
| token 预算倒计时 | TRAE Work 没有系统级 token 统计机制 | 目标完成时汇报最终消耗量 |
| 阻塞计数器 | 没有内置的"连续 N 轮"计数器 | AI 自行跨轮记录出现次数（第 1 次→第 2 次→第 3 次→触发） |
不是系统级的，但效果一样。这两个缺口都记在了技能文档里。
写在最后
goal-tracking 不是什么酷炫的技术，它是一套让 AI 对自己诚实的机制。
完成审计逼 AI 证明自己真的做完了。阻塞审计逼 AI 不能遇到困难就放弃。这两件事听起来简单，做起来比写十行代码难多了。
现在你问 AI"做到哪了"，它能回答你。而且回答是可信的。
这大概就是它给我最大的收获。
skill.zip（/goal-tracking V0） (5.9 KB)
TRAE code的skill_goal(源文件).zip (11.9 KB)