尧图网站建设 
Define Goal用 Codex 目标工具将模糊意图打磨成可量化、可验证的执行目标【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本指南深入解析 Codex Skills 仓库中define-goal技能的完整用法如何在开始工作前把用户一句模糊的意图如“让结账更快”“再调查一下 PR 评论”塑造成 Agent 可以诚实执行、可量化验证的具体目标并正确调用create_goal/get_goal目标工具。读完本文你将掌握一套从目标确认、目标重述、量化增强、质量把关到工具调用的完整工作流可直接复用于 Codex 会话中的目标驱动开发。技能定位与触发边界define-goal是 Codex Skills Catalogskills中 curated 类技能之一其本体位于 skills/.curated/define-goal/SKILL.md配套的界面声明位于 agents/openai.yaml。技能的定位非常克制它只负责目标定义与目标工具创建绝不越界去管理持久化快照、决策日志、台账或长时间运行的任务产物。这一点在 SKILL.md 的 Overview 与 frontmatter 中反复强调description明确列出触发场景用户请求$define-goal、要求创建或设置目标、请求使用 goal 工具、希望明确成功标准、或想把模糊意图变成量化结果时才激活本技能。技能明确声明本技能不创建中间规划产物、不创建持久快照、不创建台账、不创建决策日志、不创建恢复resume文件。配套的 agents/openai.yaml 提供了面向界面的描述display_name: Define Goal、short_description: Shape clear measurable goals其default_prompt为interface: display_name: Define Goal short_description: Shape clear measurable goals default_prompt: Use $define-goal to turn this intention into a concrete, measurable goal before starting work.这意味着在实际会话中用户既可以直接键入$define-goal触发技能也可以在表达“把这个意图转成具体可衡量的目标”时由 Agent 自动路由到本技能。核心哲学只有一个把用户意图塑造成 Agent 能诚实追求的目标——优先可衡量的结果、明确的证据和受限的范围而不是活动描述。六步工作流从意图到已创建的目标SKILL.md 给出了完整的目标定义工作流共六个步骤。每一步都解决一个具体问题下面逐一展开并结合底层原理说明。第 1 步确认目标定义是否真的必要不要对任何请求都强行创建目标。技能给出的判定规则应当使用本技能用户请求$define-goal、要求创建或设置目标、请求使用 goal 工具、或希望把意图转化为清晰目标。不应使用本技能用户只是要求普通的实现工作。此时应直接执行工作而不是强迫创建目标。这一“防滥用”闸门是整套工作流的第一道质量防线——目标工具是用于需要可验证成果的工作而非例行多步任务。第 2 步用具体术语重述目标一个可用的目标必须点名以下要素完成后将成立的具体结果the specific outcome that will be true涉及的主要工件系统、仓库、环境或用户可见行为如何验证完成completion verification范围内包含什么in scope当歧义会影响到结果时范围外不包含什么out of scope停止条件何时应停下询问用户而不是继续硬磨stop condition for asking the user instead of grinding。重述目标的价值在于把“用户脑海中的期望”翻译成“Agent 可检查的事实”让后续的量化与验证有锚点。第 3 步在领域允许时量化目标量化不是堆数字而是选择能代表真实成功的数字而不是装饰性精度。SKILL.md 给出了四类可量化的维度通过/失败验证器精确的测试、检查、CI 任务、评估eval、命令或验收标准质量阈值延迟、错误率、成本、准确率、召回率、精确率、覆盖率、flake 率、打包体积、内存、可用性、完成率或人工审查标准工件约束文件路径、受影响模块、允许的命令、输出格式、目标环境、截止日期或最大爆炸半径maximum blast radius证据计数复现失败的次数、成功重跑次数、审查过的示例数、迁移记录数、已处理的评论数、已验证用例数。这四类维度直接对应 Codex 目标工具goal tool中目标字符串的写法习惯——把验证证据写进目标本身目标才具备可判定性。第 4 步在设置目标前修复弱目标遇到含糊目标时按以下优先级处理当本地上下文使重写是安全的时直接把含糊目标改写成可衡量的目标当缺失的细节会改变预期结果或验证方式时提出一个简明澄清问题拒绝纯活动型目标例如“make progress”推进一下、“keep investigating”继续调查、“improve things”改善一些东西、“work on X”做一下 X除非它们被锐化成可验证的结果。第 5 步创建目标前检查当前目标状态这是与 goal 工具交互的关键一步调用链为调用get_goal检查当前激活目标若没有激活目标且目标满足质量标准 → 调用create_goal若存在激活目标且仍匹配用户意图→ 继续使用现有目标而不是创建重复目标若存在激活目标但与新请求冲突→ 询问用户是完成当前目标还是将其标记为完成如果已完成或开启一个独立的、由目标支撑的新会话线程goal-backed thread。这一步骤确保目标系统始终只有一个明确的执行方向避免多目标互相覆盖或重复创建。第 6 步仅当目标通过质量门槛后才创建create_goal的调用规范非常明确使用单一、简明的目标字符串把验证证据包含在目标本身中当范围约束会限制工作时把范围边界包含进来仅在用户明确要求时才包含 token 预算不要为普通多步任务调用create_goal除非用户明确要求目标支撑的工作。从第 5、6 步可以看出create_goal与get_goal是成对出现的状态管理原语get_goal负责读取当前目标状态以避免重复或冲突create_goal负责在通过质量门槛后落地目标。整个流程把“先查后建”作为铁律。目标质量门槛Goal Quality Bar在调用create_goal之前目标必须能回答五个问题完成后具体有什么事实成立什么证据能证明它什么量化或二元阈值定义成功哪些范围边界重要什么情况应该让 Agent停下来询问SKILL.md 用两组正反示例把好目标与弱目标区分得极其清晰。好目标示例可直接套用模板Reduce checkout API p95 latency below 250 ms for the documented slow path by making the smallest safe server-side change, then verify withnpm run test:checkoutand the existing local latency benchmark showing p95 under 250 ms across 3 consecutive runs.将结账 API 的 p95 延迟在文档记载的慢路径上降到 250 ms 以下采用最小安全服务端改动然后通过npm run test:checkout与现有本地延迟基准验证 p95 连续 3 次运行低于 250 ms。Resolve the open review comments on PR 123 that request code changes, update only the affected auth files and tests, and verify with the targeted auth test command plusgh pr view 123showing no unresolved change-request threads.解决 PR 123 上要求改代码的未处理评审评论只更新受影响的 auth 文件和测试并用定向 auth 测试命令加gh pr view 123验证无未解决的 change-request 线程。弱目标示例必须拒绝或重写Make checkout faster.Keep investigating the PR comments.对比可见好目标同时包含结果、证据、阈值、范围与停止条件弱目标只有意图没有可验证的事实。这正是质量门槛的判据所在。量化启发式按工作类型选择度量方式不同工作类型需要不同的成功定义SKILL.md 给出了六类启发式Bug成功 先复现再修复尽可能提供“先失败后通过”的验证器测试点名精确命令与必须通过的判定条件性能点名指标、目标阈值、测量方法、运行次数质量类工作定义可观察的验收条杠如审查过的示例、lint/typecheck/test 全过、或用户批准的工件研究类工作定义研究必须支撑的决策、范围内涉及的来源或系统、以及证据标准运维类工作定义健康状态、监控窗口、故障阈值、回滚或升级触发条件。这六类启发式覆盖了 Agent 日常任务的主要形态可以当作“成功定义速查表”使用接到任务先归类再按对应维度补全目标。澄清问题的使用纪律澄清不是越多越好。SKILL.md 明确仅当一次合理的重写有可能导致 Agent 追错目标pursuing the wrong outcome时才提问且问题要短小、围绕缺失的验证器或范围边界。三个可直接使用的问题模板What metric should define success here: latency, cost, accuracy, or user-visible behavior?这里的成功指标是什么延迟、成本、准确率还是用户可见行为Which environment should I verify against: local, staging, or production?应针对哪个环境验证本地、预发还是生产What is the minimum evidence you want before I mark this goal complete?在我把目标标记为完成前你要求的最低证据是什么若用户无法给出指标则提出最诚实的二元验证器并请求确认——例如“这条命令通过/失败”这类二值判定而不是放任目标停留在不可验证状态。技能边界与仓库中的安装使用方式define-goal属于 curated 技能目录skills/.curated目录内只包含 SKILL.md、agents/openai.yaml 与LICENSE.txt三个文件结构极其精简这本身也印证了技能“只做目标定义、不产出额外工件”的边界设计。按照仓库 README.md 的说明curated 技能可在 Codex 内通过$skill-installer按名称安装$skill-installer define-goal安装后重启 Codex 即可生效。实际使用时最直接的触发方式是让用户在会话中表达“把这个意图转成具体、可衡量的目标”类请求或直接引用技能默认提示见 agents/openai.yaml 的default_prompt。请注意本仓库已标记为 deprecated当前 Codex 技能与插件示例请参考官方 OpenAI Plugins 仓库与 Build plugins 指南详见 README.md 顶部说明。小结把“做事”变成“做成可验证的事”define-goal的核心贡献是把目标定义从一句随意的口头承诺升级为一条包含结果、证据、阈值、范围与停止条件的可执行契约。它的六步工作流、五问质量门槛、六类量化启发式和三条澄清问题模板共同构成一套完整的目标工程方法论。结合get_goal先查状态与create_goal通过门槛后创建的调用纪律Agent 得以在长任务中保持诚实、可验证、不跑偏——这正是本技能希望每一个使用 Codex 目标工具的人获得的能力。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Define Goal：用 Codex 目标工具将模糊意图打磨成可量化、可验证的执行目标
Define Goal用 Codex 目标工具将模糊意图打磨成可量化、可验证的执行目标【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本指南深入解析 Codex Skills 仓库中define-goal技能的完整用法如何在开始工作前把用户一句模糊的意图如“让结账更快”“再调查一下 PR 评论”塑造成 Agent 可以诚实执行、可量化验证的具体目标并正确调用create_goal/get_goal目标工具。读完本文你将掌握一套从目标确认、目标重述、量化增强、质量把关到工具调用的完整工作流可直接复用于 Codex 会话中的目标驱动开发。技能定位与触发边界define-goal是 Codex Skills Catalogskills中 curated 类技能之一其本体位于 skills/.curated/define-goal/SKILL.md配套的界面声明位于 agents/openai.yaml。技能的定位非常克制它只负责目标定义与目标工具创建绝不越界去管理持久化快照、决策日志、台账或长时间运行的任务产物。这一点在 SKILL.md 的 Overview 与 frontmatter 中反复强调description明确列出触发场景用户请求$define-goal、要求创建或设置目标、请求使用 goal 工具、希望明确成功标准、或想把模糊意图变成量化结果时才激活本技能。技能明确声明本技能不创建中间规划产物、不创建持久快照、不创建台账、不创建决策日志、不创建恢复resume文件。配套的 agents/openai.yaml 提供了面向界面的描述display_name: Define Goal、short_description: Shape clear measurable goals其default_prompt为interface: display_name: Define Goal short_description: Shape clear measurable goals default_prompt: Use $define-goal to turn this intention into a concrete, measurable goal before starting work.这意味着在实际会话中用户既可以直接键入$define-goal触发技能也可以在表达“把这个意图转成具体可衡量的目标”时由 Agent 自动路由到本技能。核心哲学只有一个把用户意图塑造成 Agent 能诚实追求的目标——优先可衡量的结果、明确的证据和受限的范围而不是活动描述。六步工作流从意图到已创建的目标SKILL.md 给出了完整的目标定义工作流共六个步骤。每一步都解决一个具体问题下面逐一展开并结合底层原理说明。第 1 步确认目标定义是否真的必要不要对任何请求都强行创建目标。技能给出的判定规则应当使用本技能用户请求$define-goal、要求创建或设置目标、请求使用 goal 工具、或希望把意图转化为清晰目标。不应使用本技能用户只是要求普通的实现工作。此时应直接执行工作而不是强迫创建目标。这一“防滥用”闸门是整套工作流的第一道质量防线——目标工具是用于需要可验证成果的工作而非例行多步任务。第 2 步用具体术语重述目标一个可用的目标必须点名以下要素完成后将成立的具体结果the specific outcome that will be true涉及的主要工件系统、仓库、环境或用户可见行为如何验证完成completion verification范围内包含什么in scope当歧义会影响到结果时范围外不包含什么out of scope停止条件何时应停下询问用户而不是继续硬磨stop condition for asking the user instead of grinding。重述目标的价值在于把“用户脑海中的期望”翻译成“Agent 可检查的事实”让后续的量化与验证有锚点。第 3 步在领域允许时量化目标量化不是堆数字而是选择能代表真实成功的数字而不是装饰性精度。SKILL.md 给出了四类可量化的维度通过/失败验证器精确的测试、检查、CI 任务、评估eval、命令或验收标准质量阈值延迟、错误率、成本、准确率、召回率、精确率、覆盖率、flake 率、打包体积、内存、可用性、完成率或人工审查标准工件约束文件路径、受影响模块、允许的命令、输出格式、目标环境、截止日期或最大爆炸半径maximum blast radius证据计数复现失败的次数、成功重跑次数、审查过的示例数、迁移记录数、已处理的评论数、已验证用例数。这四类维度直接对应 Codex 目标工具goal tool中目标字符串的写法习惯——把验证证据写进目标本身目标才具备可判定性。第 4 步在设置目标前修复弱目标遇到含糊目标时按以下优先级处理当本地上下文使重写是安全的时直接把含糊目标改写成可衡量的目标当缺失的细节会改变预期结果或验证方式时提出一个简明澄清问题拒绝纯活动型目标例如“make progress”推进一下、“keep investigating”继续调查、“improve things”改善一些东西、“work on X”做一下 X除非它们被锐化成可验证的结果。第 5 步创建目标前检查当前目标状态这是与 goal 工具交互的关键一步调用链为调用get_goal检查当前激活目标若没有激活目标且目标满足质量标准 → 调用create_goal若存在激活目标且仍匹配用户意图→ 继续使用现有目标而不是创建重复目标若存在激活目标但与新请求冲突→ 询问用户是完成当前目标还是将其标记为完成如果已完成或开启一个独立的、由目标支撑的新会话线程goal-backed thread。这一步骤确保目标系统始终只有一个明确的执行方向避免多目标互相覆盖或重复创建。第 6 步仅当目标通过质量门槛后才创建create_goal的调用规范非常明确使用单一、简明的目标字符串把验证证据包含在目标本身中当范围约束会限制工作时把范围边界包含进来仅在用户明确要求时才包含 token 预算不要为普通多步任务调用create_goal除非用户明确要求目标支撑的工作。从第 5、6 步可以看出create_goal与get_goal是成对出现的状态管理原语get_goal负责读取当前目标状态以避免重复或冲突create_goal负责在通过质量门槛后落地目标。整个流程把“先查后建”作为铁律。目标质量门槛Goal Quality Bar在调用create_goal之前目标必须能回答五个问题完成后具体有什么事实成立什么证据能证明它什么量化或二元阈值定义成功哪些范围边界重要什么情况应该让 Agent停下来询问SKILL.md 用两组正反示例把好目标与弱目标区分得极其清晰。好目标示例可直接套用模板Reduce checkout API p95 latency below 250 ms for the documented slow path by making the smallest safe server-side change, then verify withnpm run test:checkoutand the existing local latency benchmark showing p95 under 250 ms across 3 consecutive runs.将结账 API 的 p95 延迟在文档记载的慢路径上降到 250 ms 以下采用最小安全服务端改动然后通过npm run test:checkout与现有本地延迟基准验证 p95 连续 3 次运行低于 250 ms。Resolve the open review comments on PR 123 that request code changes, update only the affected auth files and tests, and verify with the targeted auth test command plusgh pr view 123showing no unresolved change-request threads.解决 PR 123 上要求改代码的未处理评审评论只更新受影响的 auth 文件和测试并用定向 auth 测试命令加gh pr view 123验证无未解决的 change-request 线程。弱目标示例必须拒绝或重写Make checkout faster.Keep investigating the PR comments.对比可见好目标同时包含结果、证据、阈值、范围与停止条件弱目标只有意图没有可验证的事实。这正是质量门槛的判据所在。量化启发式按工作类型选择度量方式不同工作类型需要不同的成功定义SKILL.md 给出了六类启发式Bug成功 先复现再修复尽可能提供“先失败后通过”的验证器测试点名精确命令与必须通过的判定条件性能点名指标、目标阈值、测量方法、运行次数质量类工作定义可观察的验收条杠如审查过的示例、lint/typecheck/test 全过、或用户批准的工件研究类工作定义研究必须支撑的决策、范围内涉及的来源或系统、以及证据标准运维类工作定义健康状态、监控窗口、故障阈值、回滚或升级触发条件。这六类启发式覆盖了 Agent 日常任务的主要形态可以当作“成功定义速查表”使用接到任务先归类再按对应维度补全目标。澄清问题的使用纪律澄清不是越多越好。SKILL.md 明确仅当一次合理的重写有可能导致 Agent 追错目标pursuing the wrong outcome时才提问且问题要短小、围绕缺失的验证器或范围边界。三个可直接使用的问题模板What metric should define success here: latency, cost, accuracy, or user-visible behavior?这里的成功指标是什么延迟、成本、准确率还是用户可见行为Which environment should I verify against: local, staging, or production?应针对哪个环境验证本地、预发还是生产What is the minimum evidence you want before I mark this goal complete?在我把目标标记为完成前你要求的最低证据是什么若用户无法给出指标则提出最诚实的二元验证器并请求确认——例如“这条命令通过/失败”这类二值判定而不是放任目标停留在不可验证状态。技能边界与仓库中的安装使用方式define-goal属于 curated 技能目录skills/.curated目录内只包含 SKILL.md、agents/openai.yaml 与LICENSE.txt三个文件结构极其精简这本身也印证了技能“只做目标定义、不产出额外工件”的边界设计。按照仓库 README.md 的说明curated 技能可在 Codex 内通过$skill-installer按名称安装$skill-installer define-goal安装后重启 Codex 即可生效。实际使用时最直接的触发方式是让用户在会话中表达“把这个意图转成具体、可衡量的目标”类请求或直接引用技能默认提示见 agents/openai.yaml 的default_prompt。请注意本仓库已标记为 deprecated当前 Codex 技能与插件示例请参考官方 OpenAI Plugins 仓库与 Build plugins 指南详见 README.md 顶部说明。小结把“做事”变成“做成可验证的事”define-goal的核心贡献是把目标定义从一句随意的口头承诺升级为一条包含结果、证据、阈值、范围与停止条件的可执行契约。它的六步工作流、五问质量门槛、六类量化启发式和三条澄清问题模板共同构成一套完整的目标工程方法论。结合get_goal先查状态与create_goal通过门槛后创建的调用纪律Agent 得以在长任务中保持诚实、可验证、不跑偏——这正是本技能希望每一个使用 Codex 目标工具的人获得的能力。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考