Task frame
You stop asking Codex to “help somehow” and start handing it a concrete unit of work.
Module 03.2
Codex context and prompting
Give Codex the right task shape
before you expect the right output.
Most disappointing Codex results start earlier than the output. They start with a weak task frame. This lesson teaches the core prompt structure: goal, context, constraints, and done-when, plus when to ask for a plan instead of immediate edits.
模块 03.2
Codex 上下文与提问
先把任务形状说对，
再期待 Codex 给你对的输出。
大多数让人失望的 Codex 结果，并不是从输出那一刻才出错，而是从任务框架就已经错了。 这个子模块训练的是核心提示词结构：目标、上下文、限制条件、完成标准，以及何时先要求计划而不是直接改代码。
Outcomes
What changes when you start prompting well
Context packing
You include files, constraints, examples, and repo facts that actually alter the answer instead of dumping everything you know.
Escalation judgment
You know when to ask for a short plan first, when to ask for implementation directly, and when the task is still too vague.
学习结果
当你开始会提问后，会发生什么变化
任务框架
你不再让 Codex “随便帮一下”，而是给它一个明确的工作单元。
上下文打包
你会只提供真正能改变答案的文件、限制条件、例子和仓库事实，而不是把所有信息一股脑塞进去。
升级判断
你知道什么时候先要一个短计划，什么时候直接实现，什么时候说明任务本身还太模糊。
Workflow
The five-part Codex task frame
Goal
What exactly should Codex produce or change, and why does it matter?
Context
Which files, examples, docs, or constraints give the task its real shape?
Constraints
What must not change, what style to follow, and what risks to avoid?
Done-when
What observable output, diff, test, or behavior proves the task is complete?
Mode
Should Codex plan first, implement directly, or explore before making changes?
工作流程
Codex 任务框架的五个部分
目标
Codex 到底应该产出什么或改什么，为什么这件事重要？
上下文
哪些文件、例子、文档或限制，真正决定了任务的形状？
限制条件
什么不能改、该遵循什么风格、要避免哪些风险？
完成标准
什么样的输出、diff、测试或行为，能够证明任务真的完成？
工作模式
应该先计划、直接实现，还是先探索再改动？
Prompt templates
Prompt shapes you can reuse immediately
Small implementation prompt
Goal: Add optimistic loading to the save button in SettingsPanel. Context: - Relevant files: src/components/SettingsPanel.tsx, src/hooks/useSettings.ts - Existing pattern: follow the loading treatment used in ProfilePanel. Constraints: - Do not change API shapes. - Keep styling consistent with the current design system. Done when: - The button shows a loading state during save. - Existing tests still pass, and add tests if needed.
Use when the task has moving parts
Before making changes, inspect the relevant files and give me: 1. A short implementation plan. 2. Key risks or unknowns. 3. The verification steps you intend to run. Then wait for confirmation before editing.
提示词模板
可以立刻复用的提示词形状
小型实现提示词
目标：给 SettingsPanel 的保存按钮增加 optimistic loading。 上下文： - 相关文件：src/components/SettingsPanel.tsx, src/hooks/useSettings.ts - 现有模式：参考 ProfilePanel 的 loading 处理方式。 限制条件： - 不要修改 API 形状。 - 样式保持和当前设计系统一致。 完成标准： - 保存期间按钮显示 loading 状态。 - 现有测试继续通过，必要时补测试。
当任务包含多个变量时使用
在做任何改动前，先检查相关文件，并告诉我： 1. 一个简短实现计划。 2. 关键风险或未知点。 3. 你准备运行哪些验证步骤。 得到确认后再开始编辑。
Practice
Deliberate drills for stronger prompts
Drill 1: rewrite weak asks
- Write three vague prompts from your own work.
- Rewrite each using goal, context, constraints, and done-when.
- Compare which version produces a cleaner plan.
Drill 2: context pruning
- Start with too much context.
- Remove anything that does not change the task.
- Notice how signal improves when the prompt gets sharper.
Drill 3: plan or execute?
- Choose three tasks from your repo.
- Decide which needs a plan first and which can go straight to implementation.
- Explain your decision in one sentence each.
练习
用刻意练习强化提示词能力
练习 1：重写差请求
- 从你自己的工作里写三个模糊提示词。
- 用目标、上下文、限制条件和完成标准把它们重写。
- 比较哪一个版本能得到更干净的计划。
练习 2：修剪上下文
- 先故意给过多上下文。
- 删掉所有不会改变任务的内容。
- 观察提示词变锋利后，信号如何提升。
练习 3：先计划还是直接执行？
- 从你的仓库里选三个任务。
- 判断哪个应先要计划，哪个可以直接实现。
- 分别用一句话解释你的判断。
Giving context without a decision
Dumping files, logs, and tickets is not the same as telling Codex what job those materials should support.
Over-specifying the wrong layer
Do not micromanage implementation details before you are sure the task frame itself is correct.
给了很多上下文，却没有做任务判断
把文件、日志和 ticket 全丢进去，不等于你已经告诉 Codex 这些材料到底要服务什么工作。
在错误层级上过度规定
在你还没确认任务框架是否正确之前，不要先对实现细节进行过度微操。