Codex /goal 功能

核心结论

/goal 适合被当成 Codex 的“长任务驾驶舱”：它不是替代普通 slash command 的短指令，而是给一个线程设置持续目标、预算和完成标准，让 Codex 围绕同一个结果跨多轮对话、跨多步工具调用持续推进。

目前公开官方网页还没有把 /goal 做成单独文档化功能；本机 codex-cli 0.128.0 中 goals feature 已启用，状态为 under development。从本机可见能力看，Goal 是线程级对象，包含 objective、可选 token budget、token/time usage，以及 active / paused / budgetLimited / complete 等状态。

在这个 vault 里，/goal 最有价值的用法不是“让 AI 忙起来”，而是把已经存在的工作流包成长期目标：

• Daily Note -> graduate -> 01_知识库
• raw -> wiki-ingest -> 05_Wiki -> 个人判断
• AI 原生游戏工作台 -> 概念推进 -> demo 方案
• vault-health -> 自检 -> 修复 -> 文档同步

使用原则

1. 小任务不要用 /goal，直接让 Codex 执行即可。
2. 适合 /goal 的任务应当有明确的完成标准，而不是“长期保持关注”。
3. /goal 的 objective 要写清楚：工作目录、必须读取的文档、执行顺序、边界、停止条件、完成标准。
4. 在本 vault 中，/goal 应尊重既有分层：
   • 01_知识库/：个人知识与判断。
   • 05_Wiki/：客观编译层。
   • 03_工作台/：活跃项目推进。
   • 04_素材库/raw/：原始素材，只读。
5. 对 Obsidian 改造任务，仍遵守“讨论 → 更新文档 → Review → 执行 → 自检 → Commit”。

当前仓库中的高价值 /goal 任务

2026-06-01 重评估：在当前这个 vault 里，/goal 最值得用在“跨多轮、跨目录、有验收、有边界”的任务上，不适合单次整理。它应该留给需要持续推进到完成标准的工作，而不是把普通任务包装成更大的 prompt。

最值得用 /goal 的事情

1. Vault 维护闭环

适合把 /vault-health、断链、MOC 候选、tag/frontmatter、raw/distill 积压串成一轮：先只读体检，再给修复批次，用户确认后执行，自检收尾。这是 /goal 在当前仓库里最稳的用途。

2. AI 原生游戏 Demo 推进闭环

尤其是 军令如山 和 TokenPunk。军令如山 已有 Demo 项目、TAPD 子需求和工程入口；TokenPunk 当前设计母稿仍是“待重写”。这类任务很适合 /goal：读 vault 设计源头，补项目总览或母稿，对齐工程/TAPD 边界，输出可执行 demo 验证包。

3. TokenPunk 单项深挖 Goal

如果只挑一个，优先选 TokenPunk。当前它已经有强概念资产，但 Demo 母稿还没定型。/goal 可以专门负责把它从“完整概念源流”压缩成：3-5 分钟 Demo 流程、玩家 30-90 秒原子循环、AI 伙伴幕后共犯、Token 成本、PV 表达和验收问题。

4. AI 原生游戏灵感池筛选升级

10_灵感池/ 里有言出法随、签证官、神笔马良、粘贴世界、朕已阅等方向。适合用 /goal 做一轮“概念盘点 → 选择最值得 Demo 化的 1-2 个 → 写升级建议 → 必要时迁入 20_Demo验证/”。

5. Kubee 42 个小游戏优化流水线

当前 Kubee 已有 35 个记录、34 个评级，下一步是确认缺失序号、选 5-8 个试评审、沉淀共性问题。这不是单个小游戏笔记任务，而是一条批量工作流，适合 /goal 控制范围和节奏。

6. 哆啦A梦百宝箱：从项目雷达到可复用 Skill

当前已经完成“vault 做控制台、F:\Coding\Doraemon 做执行仓库”的分层。适合 /goal 处理一个完整口袋：从项目雷达/场景索引，到调研、候选池、Doraemon repo 实现，再到全局 skill 注册记录。

7. 研究 → Wiki → 个人判断飞轮

适合主题型研究，例如“runtime AI 玩法到底哪些成立”。/goal 的价值在于保持层级不乱：外部资料进 04_素材库/raw/ 和 05_Wiki/，个人设计判断回 01_知识库/ 或 03_工作台/AI原生游戏/。

不太值得用 /goal 的事情

单篇笔记改名、补一个 MOC 链接、回答一次问题、跑一次 /wiki-health、修一个明确断链，都不值得开 /goal。这些直接让 Codex 执行即可。

当前优先级判断

如果现在就开一个 /goal，建议优先级是：

1. TokenPunk Demo 母稿重写。
2. Vault 维护闭环。
3. Kubee 第一批试评审。
4. 哆啦A梦百宝箱口袋产品化。

推荐方案一：Vault 驻场维护 Goal

适合每周或大改造前运行，用来把 /vault-health、断链、tag、MOC、signal tag 积压等维护工作串成闭环。

建议 token budget：120000

目标：作为 LD_CooperZheng Obsidian Vault 的 Codex 驻场维护者，完成一次高质量 vault 维护闭环，让这个 vault 更可用、更少断裂、更符合既有规则，但不擅自扩展范围。
 
工作目录：D:\GoogleDrive\Obsidian\LD_CooperZheng
 
必须先读并遵守：
- AGENTS.md
- 03_工作台/Obsidian改造/00_Obsidian改造计划.md
- 03_工作台/Obsidian改造/Note规范.md
- 03_工作台/Obsidian改造/Vault运转手册.md
- 05_Wiki/CLAUDE.md
- .Codex/commands/vault-health.md
- .Codex/commands/graduate.md
- .Codex/commands/weekly-review.md
 
核心纪律：
- 99_过往 不动。
- 04_素材库/raw 只读，不修改不删除。
- 05_Wiki 结构或规范变更必须先问用户；普通 wiki-ingest/wiki-lint/wiki-query 可按现有命令执行。
- Obsidian 改造相关事项遵守“讨论 -> 更新文档 -> Review -> 执行 -> 自检 -> Commit”。
- 批量修改 Markdown 时做精确替换，不整体重写。
- 不主动创建项目 MEMORY.md，除非任务需要跨会话接续或用户明确要求。
- git 命令统一使用 git -C "D:/GoogleDrive/Obsidian/LD_CooperZheng"。
 
执行顺序：
1. 先做只读诊断：运行或模拟 .Codex/commands/vault-health.md 的完整检查，覆盖 tag 合规、frontmatter、Markdown wikilink、Canvas file nodes、孤儿笔记、#distill/#待沉淀、raw 待 ingest。
2. 输出按优先级排序的维护计划，分为“必须修”“建议修”“暂缓”。
3. 等用户确认要修哪一批后，再执行修改。
4. 每次只处理一个明确批次，例如断链修复、tag 补全、MOC 更新、distill 积压整理，不混在一起。
5. 修改后自检：重新跑相关检查，证明问题已解决。
6. 如果修改了结构、规范或使用方式，同步更新 AGENTS.md / Vault运转手册 / Note规范 / 改造计划中的对应状态；不要重复写同一段理念，保持单一权威来源。
7. 最后给出变更摘要、剩余风险、建议下一步。只有用户明确要求 commit 时才提交。
 
完成标准：
- 已读权威文档并按规则行动。
- 输出过完整健康报告。
- 用户确认的维护项已完成。
- 自检结果能证明本轮问题被解决或清楚说明未解决原因。
- 没有碰 99_过往，没有破坏 05_Wiki/04_素材库/raw 边界。

推荐方案二：AI 原生游戏概念推进 Goal

适合把 03_工作台/AI原生游戏/ 里的一个方向推进成可给团队讨论的概念包，尤其适合 TokenPunk、签证官影像审核模拟器、言出法随、魔法战斗等方向。

建议 token budget：220000

目标：把 03_工作台/AI原生游戏/ 中最有价值的一个 AI 原生游戏方向推进成“可给团队讨论的完整概念包”，包括核心体验、玩家行为、玩法循环、AI 使用边界、demo 版本、风险与下一步验证计划。
 
工作目录：D:\GoogleDrive\Obsidian\LD_CooperZheng
 
必须先读：
- AGENTS.md
- 03_工作台/AI原生游戏/00_全景总览.md
- 03_工作台/AI原生游戏/20_Demo验证/TokenPunk/TokenPunk.md
- 03_工作台/AI原生游戏/20260430_签证官影像审核模拟器.md
- 03_工作台/AI原生游戏/20260425_魔法战斗-咒语驱动的世界实时演化.md
- 03_工作台/AI原生游戏/20260429_言出法随-东方灵异.md
- 相关 Canvas 文件只作为线索，不要直接重写。
 
设计原则：
- 从玩家体验和核心循环开始，不从技术炫技开始。
- 不要被已有文档限制，现有笔记是证据，不是最终答案。
- AI 原生判断优先看：去掉 AI 后体验是否崩溃；玩家是否必须通过 AI 中介影响世界；AI 不确定性是否可解释、可追责、可利用。
- 默认偏向“AI 生产期资源生成 + 轻量稳定 runtime”，除非该概念确实需要 runtime AI。
- 玩家不能被 AI 推着跑。玩家提出目标、愿景、风格；AI 做后台整合、约束求解、执行准备；人前显圣留给玩家。
- 对 TokenPunk 保持“AI 都市怪盗 + 被垄断智能 + Token 成本 + AI 伙伴幕后共犯”的核心，不要写成普通黑客/开放世界犯罪游戏。
- 对签证官方案保持“有限识人 + 规则冲突 + 价值观结算”，不要膨胀成重度互动电影。
 
执行顺序：
1. 先做概念盘点：列出当前 AI原生游戏工作台中 5-8 个方向，各自的一句话概念、核心循环、AI 原生点、当前成熟度、demo 可行性。
2. 给出判断：本轮最值得推进的 1 个主方向，以及 1 个备选方向。说明为什么。
3. 默认选择最值得推进者继续，除非用户改选。
4. 对选中方向做“从 0 开始”的需求澄清：玩家是谁、玩家想要什么、玩家一分钟内在做什么、AI 如何进入 gameplay、失败/代价/成长是什么。
5. 输出完整概念包草稿，结构必须包含：
   - 本文定位
   - 一句话概念
   - 玩家愿景
   - 核心体验，最多 3 条
   - 玩家身份
   - 玩家行为
   - 30-90 秒原子循环
   - 中层循环
   - 长线目标
   - AI 参与方式
   - AI 生产期资产
   - Runtime 边界
   - Demo 版本设想
   - 关键风险
   - 下一步验证问题
6. 自己 review 一遍草稿：删掉比较式废话，删掉泛泛 AI 口号，压缩过多核心体验，检查是否让玩家失去高光。
7. 若需要写入 vault，先展示草稿并等待用户确认。确认后按 Note规范.md 写入或更新 03_工作台/AI原生游戏/ 下对应笔记。
8. 最后输出团队讨论版摘要：3 分钟口头 pitch + 5 个待讨论问题。
 
完成标准：
- 不是罗列点子，而是推进出一个可评审概念包。
- 有明确 gameplay loop。
- 有 AI 使用边界，不把 runtime 做重。
- 有 demo 范围。
- 有自我 review 后的取舍。

推荐方案三：研究 → Wiki → 个人判断飞轮 Goal

适合把外部资料研究、05_Wiki 客观编译、01_知识库 主观判断转译串成生产线。

建议 token budget：260000

目标：围绕“AI 原生游戏”建立一次从外部研究到 vault 沉淀的完整知识生产飞轮：联网研究权威资料，编译进 05_Wiki，再把对我有价值的设计判断转译进 01_知识库 或 03_工作台/AI原生游戏/。
 
工作目录：D:\GoogleDrive\Obsidian\LD_CooperZheng
 
必须先读：
- AGENTS.md
- 05_Wiki/CLAUDE.md
- 05_Wiki/index.md
- 05_Wiki/hot.md（如果存在）
- 03_工作台/Obsidian改造/Vault运转手册.md
- .Codex/commands/autoresearch.md
- .Codex/commands/ingest.md
- .Codex/commands/wiki-query.md
- .Codex/commands/save.md
- 03_工作台/AI原生游戏/00_全景总览.md
 
研究主题默认：
“2025-2026 AI 原生游戏中，哪些 runtime AI 交互真的形成了新玩法，而哪些只是生产提效或内容包装？”
 
如果用户指定新主题，以用户主题为准。
 
研究纪律：
- 优先找官方资料、论文、开发者博客、产品文档、可信媒体和真实产品案例。
- 资料尽量近两年；基础理论可用旧资料，但必须标注时效。
- 区分事实、判断、推测。
- 05_Wiki 只写客观编译，不写我的个人价值判断。
- 个人判断、设计原则、项目启发写入 01_知识库 或 03_工作台/AI原生游戏/，并用 Related Wiki 链接回 wiki。
- raw 文件保留来源声明。
- 不修改 04_素材库/raw 原始来源内容，只新增经过流程保存的资料。
- 不把来源不足的趋势包装成确定结论。
 
执行顺序：
1. 先读现有 wiki index/hot/overview，判断 vault 已有什么、缺什么。
2. 把研究主题拆成 3-5 个搜索角度，例如：
   - 已上线 AI 原生游戏案例
   - runtime AI gameplay
   - production-time AI asset pipeline
   - AI NPC/agent 社会模拟
   - 世界模型/可交互生成环境
3. 最多 3 轮搜索。每轮后总结已知、矛盾、缺口。
4. 每个高价值来源保存到 04_素材库/raw/research/<topic-slug>-<date>/，带 source URL。
5. 按 05_Wiki/CLAUDE.md 编译 source/entity/concept/synthesis 页面，更新 index/log/hot 以及各 _index。
6. 生成一个 master synthesis，回答：
   - 什么案例真的“去掉 AI 就崩溃”
   - 什么只是 AI 增强或生产提效
   - runtime AI 最适合承担哪些玩法职责
   - 哪些体验值得我们当前阶段跟进
   - 哪些方向不适合现在投入
7. 再写一份“个人设计转译草稿”，放在用户确认后再写入 01_知识库 或 03_工作台/AI原生游戏/：
   - 对 TokenPunk 的启发
   - 对签证官方案的启发
   - 对言出法随/世界模型模块的启发
   - 对未来 demo 选择的启发
8. 最后输出一份简报：研究了哪些来源、创建/更新哪些 wiki 页、形成哪些设计判断、下一轮最该追的问题。
 
完成标准：
- 至少形成一个 05_Wiki synthesis。
- 来源与判断分层清楚。
- 有面向 AI 原生游戏项目的设计转译，不停留在资料摘要。
- 没有把主观判断写入 wiki 正文。

推荐使用顺序

如果要真正提升生产力，建议按以下顺序尝试：

1. 先跑 Vault 驻场维护 Goal，把地基扫干净。
2. 再跑 AI 原生游戏概念推进 Goal，把 TokenPunk 或其他方向推进成团队可讨论的概念包。
3. 最后跑研究飞轮 Goal，用外部资料反哺 wiki 和个人判断。

这样 /goal 才不是一个“更大的 prompt”，而是把 Codex 放进真实工作系统里，持续围绕同一个结果推进。

参考链接

• Codex 产品页
• What is Codex?
• Working with Codex
• How OpenAI uses Codex