第一次用 Codex 写项目，跟着这 5 步走 同样让 Codex 加一个按钮

CODEX教程第五期：第一次用Codex写项目。

同样让Codex加一个按钮loading，有人十分钟做完，有人折腾整个下午还得回滚？差的就是5步顺序。

·第一次让Codex改东西，先挑对任务。不要选重构整个系统这种大活，也不要选支付权限、删数据，这类一旦出错影响很大的任务。更合适的任务是：风险低、范围小、能验证，而且真的会出目前项目里。列如给设置页的保存按钮加loading状态，避免用户重复提交。

如果你的项目没有设置页，也可以换成任意一个保存提交、搜索按钮，思路是一样的。这个任务不复杂，但很适合作为练习。它会碰到组件状态、按钮禁用、请求开始和结束，也会提醒你检查成功和失败两种情况，同时一般不会改到太多地方。你练的不是让Codex写几行代码，而是完整走一遍定位、计划、修改、验证、审查。

→第一步，先定位，不要直接改。可以这样问：这一步的目的是让Codex先把现场说清楚，它应该告知你相关文件在哪里、按钮在哪个组件里、请求函数在哪里、目前有没有loading状态。如果它只做概念解释，没有给出文件路径和函数名，就继续追问。

→第二步，让它给最小方案。这里最关键的是最小修改，你不是让它重新设计设置页，也不是让它把接口调用那一套重新改一遍，只是围绕重复提交这个问题做一个小修。合理方案一般会包括：增加或复用loading状态。提交开始时设为true，请求结束后恢复为false。按钮disabled绑定loading，按钮文案在保存和保存中之间切换。如果项目里已经有状态管理或请求状态，就优先复用现有逻辑。

→第三步，确认方案后再让它改。这时才让Codex动手，你要观察它有没有跑偏：有没有顺手格式化整份文件，有没有把接口调用那一套也改了，有没有引入不必要的新依赖。一个按钮loading最后变成全局请求流程重构，那就不是小任务了。

·第四步，让它验证。真实项目里不是每次都有完整测试，验证可以分三层：能跑自动测试就跑自动测试，没有测试就跑lint或typecheck。这些都没有就写清楚手动验证步骤，这个任务的手动验证可以这样写。

·第五步，改完后做一次review。这一步很重大，由于成功的时候没问题不代表失败的时候也没问题。保存成功后来loading会恢复，那保存失败呢？接口报错呢？页面被关闭或组件被卸载呢？如果只在成功后把loading设回false，失败时没恢复，用户就会看到按钮一直卡在保存中。

所以这个任务真正要验收的不只是按钮文案变了，至少要检查六件事：点击后是否立即进入loading，loading时是否禁止重复提交，成功后状态是否恢复，失败后状态是否恢复，原有错误提示是否保留，原有校验，埋点、跳转有没有被影响。可以让Codex按清单自查。

最后一句要保留：如果没有证据就说没有证据，它能避免Codex用很肯定的话瞎回复。

这一期真正要记住的不是怎么给按钮加loading，而是用Codex做任务的顺序：先定位、再给方案、确认后修改，改完验证，最后检查风险。后来不管你让它改文案、修bug，还是补一个小功能，都可以按这个顺序来。这样任务不会一上来就变成大改，改完也知道该怎么验收。

这期先到这，你还想让我继续展开哪个点，丢到评论区，我下一期接着讲。