第一次使用不建议直接给出大而模糊的需求。选择一个可验证的小项目任务，更容易看清 App 的工作方式。
打开 Codex App 并完成 ChatGPT 登录后，第一件事不是让它修改代码，而是选择一个范围明确、可以备份的小项目。练习仓库、项目副本或不含敏感资料的模块都适合作为起点。避免直接选择包含生产配置、客户数据、密钥文件或大量无关产物的目录；项目范围越干净，越容易判断任务是否按预期工作。
选择项目后先做只读任务。例如：“用三段话说明这个项目的主要模块；列出你判断为入口的文件；不修改任何文件。”这个任务能够同时验证客户端能访问正确目录、结果能被展示、你也能看懂它引用的文件。若结果指向了错误项目或大量无关内容，应先退出并重新选择目录，而不是继续追加更复杂的要求。
在 Codex App 中写任务时，建议按背景、范围、限制、验收四要素组织。背景让它知道问题是什么；范围限定目录或模块；限制明确哪些内容不能动、哪些行为需要确认；验收说明你希望获得计划、文件清单、改动说明还是测试建议。这样写出的任务不一定更长，却能显著降低结果偏离的问题。
例如排查登录报错时，可以写：“用户在密码正确时偶发失败。只检查 src/auth 与相关测试，不执行外部操作，不修改文件。请列出可能的异常路径、每条路径的依据，以及我应补充的验证信息。”结果如果包含不确定项，应先补充信息或缩小范围，而不是要求它猜测业务规则。
第一轮完成代码理解，第二轮完成问题定位，第三轮才讨论最小修改和测试。每轮都查看是否引用正确文件、是否保留了不确定性、是否提出了可验证的下一步。允许修改前，要求它先列出影响文件、修改理由与可能回归；修改后，人工查看差异，并在本地运行与该改动相关的检查或测试。
这种节奏在看似简单的任务中同样重要。比如“整理 README”也应先确认读者、范围和不能改变的事实；“补一个测试”也应先确认当前行为和验收条件。Codex App 的价值来自任务、项目和审查连续可见，而不是取代用户对业务和提交质量的判断。
把旧 CLI 命令、API Key 或终端配置当作 App 的必经步骤，是最常见的误区。本站的 Windows 客户端路径是启动 App、登录 ChatGPT、选择项目、发起任务。另一个误区是第一次就授予过大范围或要求全部自动完成；当结果难以审查时，应该把任务拆小，而不是反复要求“更智能一点”。
第三个误区是只看文字结论不看依据。对代码理解、问题定位或改动建议，都应追问它看了哪些文件、基于什么判断、哪些条件仍待确认。能回答这些问题的任务，才更容易被团队复核和复用。
已经能稳定完成首次任务，可进入任务模板页复制常见的代码理解、审查和测试准备结构；工作步骤已重复出现时再学习 Skills 与自动化；遇到权限提示时查看设置与安全页；产品名称或登录入口有疑问时查看关系页。若尚未下载 Codex App Windows 客户端，请先在下载页核对当前分发文件再开始。
完成一次任务后，保留原始描述、项目范围、输出中真正有用的部分和最终验证结果。下一次遇到类似问题时，不要简单复制全部文字，而是保留背景、限制和验收结构，替换为新的目录与问题。这样任务模板会随着项目经验变得更准确，而不是变成与当前代码无关的长提示词。
例如第一次排查认证问题后，可以记录“只读分析先行、先列调用链、先指出缺失日志、修改前必须给出影响文件”的规则。以后排查支付、缓存或通知问题时仍可沿用这个节奏。它能让 Codex App 的每次结果更容易审查，也能让开发者更快发现任务边界是否需要调整。
若结果与本地事实不一致，优先修正项目选择和任务描述，而不是把所有结论都归为工具错误。检查是否漏选依赖目录、是否混入旧分支文件、是否没有说明业务限制；补齐后再创建新的只读任务。通过这种小范围复盘，使用者可以逐渐建立可靠的项目工作区习惯。
这些验证结果也应成为下一次任务的明确前提。
首次练习的成果不在于一次完成多少工作，而在于知道怎样让任务可验证、可停止、可交接。
打开一个可备份的小项目。
写清目标、范围和不允许修改的部分。
查看改动后再在本地验证。
适合正在处理本页标题所述问题的 Codex App 用户。
可按页面底部的相关入口继续完成下载、安装或使用。
按你的当前问题继续阅读，避免在安装、账号和项目设置之间来回跳转。
