把任务说清楚，Codex 才能把事情做完整

一次有效的 Codex 协作，通常从一个可以检查的结果开始。“优化搜索功能”给出了方向，却没有说明问题出在哪里、哪些行为必须保留，以及怎样算完成。把这些信息补齐，往往比再加一段角色设定更有帮助。

OpenAI 的提示指南建议围绕目标、必要上下文、输出要求和关键边界组织请求。放到开发任务里，可以把它们转换成下面这套写法。[1]

先描述用户会看到的变化

不要只写“修改搜索组件”。更具体的目标是：搜索没有匹配结果时，页面显示关键词和清除筛选按钮；清除后恢复全部文章，浏览器地址栏中的查询参数也同步更新。

这段描述同时给出了触发条件、期望行为和恢复路径。Codex 可以据此寻找组件、路由和状态逻辑，而你也有了验收的依据。对一个复杂任务，先确定最小可交付的行为，再决定是否拆成多个阶段。

给线索，保留调查空间

提供相关页面、重现步骤、错误信息和最近改动。如果已经知道问题涉及哪个模块，就直接给出路径；如果只是怀疑，就写“可能相关”，避免把猜测变成前提。错误日志保留足够上下文，但应去掉令牌、密码和真实用户资料。

没有必要把整个项目文档粘进对话。更好的方式是说明哪份资料回答哪个问题：接口说明用于确认参数，设计稿用于确认空状态，现有测试用于确认兼容行为。

用完成标准替代模糊形容词

“更优雅”“更现代”“更高效”很难验收。把这些词换成可观察的要求：窄屏下没有横向滚动；键盘可以完成操作；已有链接仍然有效；失败时显示具体原因。性能改动还要明确测量对象和前后对照条件。

可以直接改写的任务说明

请改进文章搜索的空结果体验。

目标：
没有匹配文章时显示关键词，并提供“清除筛选”按钮。
清除后恢复全部文章，同时移除地址栏中的搜索参数。

上下文：
从现有搜索页面和路由实现开始查找，复用项目已有样式。

边界：
保留已有文章链接和分类行为，不引入新的运行时依赖。

验收：
检查中文关键词、无结果、清除筛选和手机布局。
完成后说明改动、验证结果，以及尚未验证的部分。

这段任务可以根据项目实际情况删减。关键是每个要求都影响最终结果。不要为了显得完整，加入一串与当前问题无关的约束。

第一轮之后，给具体反馈

如果实现方向偏了，指出可观察的问题：“清除后列表恢复了，但地址栏仍保留关键词。”这样的反馈能把下一轮工作限定在一个缺口上。若目标已经改变，则明确说出新的目标，以及旧要求中哪些仍然有效。

交付时，先看行为是否符合预期，再看改动范围和验证证据。一个清晰的任务说明，应该同时帮助 Codex 开始工作，也帮助你判断工作是否真的结束。