任务设计：写清结果、范围和验收证据

一个有用的任务先说明“完成后应该有什么变化”。小问题不必填写长表；涉及多个文件、外部资料或发布时，再补充会影响结果的信息。官方提示指南也强调按任务需要提供目标、上下文、输出和边界，而不是要求固定格式。

从结果倒推需要提供什么

信息	什么时候需要	示例
目标	总是先说明	让新手能从安装页找到第一个练习
上下文	结果依赖现有材料时	给出页面地址、文件路径、报错或复现步骤
范围	有不能改动的内容时	保留文章 URL，不动登录与付费流程
验收	需要判断是否可用时	构建成功，渲染后的链接能打开正确页面
交付	需要继续接手时	改动摘要、实际检查结果和未完成事项

文件名和命令应来自当前项目。不能把示例中的 pnpm test auth 当成每个仓库都能运行的命令；不知道验证方式时，先请 Codex 从项目说明和脚本中查找。

一个可直接改写的文档任务

模糊需求是“帮我优化新手教程”。把问题收敛成一次可验收的修改，可以这样描述：

请检查 content/start/06-first-task.md 的下一步入口。
目标：完成练习的读者能够找到任务设计教程和内容贡献案例。

先读项目约定和现有文章，检查入口是否已经存在；已有且正确就说明证据，
不要为了产生改动重复添加。若有错误，只修改本章所需的导航文字或链接，
保持文件名、文章主旨和其他内容不变。

按仓库约定运行 npm run lint 和 npm run build，检查生成内容差异，
并验证渲染页面中的目标地址。说明改动、实际检查结果和未完成事项。
本次不提交、不推送、不部署。

这里的路径和命令适用于本仓库。换到别的项目时，先查它的说明。内容已经符合目标时，“核对后无需修改”也是有用结果，不能把提交次数当作任务质量。

什么时候先规划

如果目标清楚、范围很小，可以直接执行并验收。跨模块重构或尚不清楚影响面时，先要求调查和方案。在桌面 Codex 中，官方当前提供 /plan 规划入口；是否可用以当前客户端为准。

先只读调查这次导航调整的影响面，不修改文件。
找出正文来源、页面渲染、生成数据和相关检查。
提出最小改动方案、每一步的验收证据，以及必须由我决定的问题。

确认方案后，把允许执行的范围说清楚。规划不是永久停在建议阶段；也不用给每个小改动强加一次额外审批。

把未知项留在任务里

资料缺失时，可以要求标注缺失信息及其影响。对事实更新，要求查当天原文并给出处；对错误修复，要求指出复现条件；对无法执行的检查，要求说明卡在哪一步。

把已确认事实和推测分开。不要编造不存在的命令、测试结果或用户反馈。
若某项验证无法运行，保留已完成成果，说明阻塞及可以继续完成的部分。

发送前快速检查

读者或协作者能否仅凭任务说明回答：要改变什么、材料在哪里、哪些边界重要、怎样证明做好了？如果能，就可以开始；后续发现新信息再补充，不必一次写出所有实施细节。

下一步：执行中怎样跟进与验收。想先做小练习，可回到第一个任务。