第一次用 Codex 做什么？五个能看见结果的小练习

刚接触编程代理，最难的往往不是找不到功能，而是不知道该把什么任务交给它，也不知道怎样判断它做得对不对。把第一项任务缩到能观察、能核对的小范围，比直接要求“优化整个项目”更容易建立可用的工作方式。

下面五项是练习设计，适合在副本、测试项目或虚构数据上完成。每项都给出交付物和检查方法；它们不是已完成的客户案例，也不包含效果保证。你可以按自己当前的问题选择一项，不必一次做完。

一、给陌生项目画一张入口地图

先要求只读检查：项目从哪里启动、主要页面怎样进入、数据在哪个模块读取。交付物是一份带文件依据的简短说明。验收时沿着一条真实调用路径核对，观察文件之间是否真的存在引用或调用关系，不能只看命名是否像入口。

这个练习不需要修改代码。它训练的是把理解建立在项目事实之上。若入口不明确，就记录缺少的运行配置或启动条件，避免用常见框架习惯替代实际证据。

在练习仓库准备几处有限变更，请 Codex 检查可能的错误、回归条件和缺失测试。交付物应指出文件位置、触发步骤、影响以及还没覆盖的范围。官方 CLI 提供改动审查工作流，具体入口以当前文档和安装版本为准。

验收时挑一条发现重新复现。如果工具只给出“代码可以更优雅”之类意见，却无法说明用户会怎样受影响，这还不是清楚的缺陷报告。没有发现问题时，同样应该写明审查范围。

制作一个包含长标题和两个操作按钮的测试页面，要求在390像素手机宽度与1280像素桌面宽度检查。允许按钮合理换行，文字不被遮挡，整页不横向撑宽。交付物包括最小改动和两种宽度下的实际画面。

这项练习特别适合训练视觉验收：语法检查通过只能证明一部分代码条件，不能证明排版已经符合要求。还要展开可能影响布局的区域，检查长文字、空内容与按钮状态。

准备一份虚构表格，明确重复按什么字段判定、空白怎样处理、大小写是否等同。让工具只输出核查报告，不直接覆盖原文件。报告至少包含总数据行数、疑似重复分组与对应行号。

自己提前准备一小组已知答案，再比对输出。文件能打开不代表判重正确；如果重复规则没有先约定，不同结果也不能直接归因于模型表现。等小样本符合规则，再评估更大文件。

在测试系统模拟一个常见失败，例如网络暂不可用。要求页面交代发生了什么、用户下一步能做什么，并保留供技术人员定位的日志。公开界面不显示密钥、内部凭证或不必要的技术细节。

验收时分别测试正常操作、失败操作和恢复后的重试。按钮不能反复提交相同请求，提示也不能把“正在处理”说成“已经完成”。这能帮助你建立从用户操作到真实状态的检查习惯。