教程列表
按当前目录继续浏览
按钮文案错了别全站搜改：先让 Codex 圈出最小修复边界
线上小 bug 最容易被低估。一个按钮文案错了、一个状态标签展示不对、一个空状态提示漏了标点，看起来都像三分钟能改完的事。真正麻烦的是：同类组件很多，文案来源不止一处，状态枚举被多个页面复用，设计系统里还有通用按钮和业务按钮两套封装。你如果让 Codex 直接“把这个按钮改成已提交”，它可能搜到...
本地能跑线上翻车前，让 Codex 先查清配置和环境变量
很多“本地正常，线上翻车”的问题，并不是业务逻辑写错，而是改动前没有查清环境差异。你在本地看到功能开关是开的，预发环境却读了另一套默认值；你在开发环境调用的是 mock 服务，生产环境调用的是真实外部接口；你以为缺少环境变量会启动失败，结果代码里悄悄给了一个宽松默认值；你以为配置来自 `.env...
别急着改支付和权限：先让 Codex 问完高风险开工问题
有些需求看起来只有一两行代码，实际却不应该让 Codex 直接开改。比如“订单取消后自动退款”“管理员可以代用户重置权限”“删除项目时顺便清理关联数据”。这些句子很短，但它们碰到的是钱、权限和不可恢复数据。这里的主要风险不是 AI 会不会写语法，而是它可能在事实不完整时给出一个看似合理的实现：漏...
大功能别一口气开改：让 Codex 拆成可逐步合并的小改动
中型功能最危险的地方，常常不是代码量大，而是它会把很多层同时搅在一起。一个看起来简单的需求，落到工程里可能横跨数据库字段、数据迁移、后端接口、权限判断、前端页面、灰度开关、监控告警和回滚策略。你如果把整件事交给 Codex，说“帮我实现这个功能”，它可能真的开始写代码，而且写得很快。但这种快有时...
改表单字段前，让 Codex 从 UI 到数据库追完整数据流
前端工程师改表单字段，最容易低估的不是页面本身，而是字段离开页面之后发生了什么。一个看起来很小的需求，例如“把联系人备注改成客户偏好说明”“新增一个可选的跟进时间”“把收货地址里的楼层字段拆出来”，往往不只是改一个 input、一个 label、一个校验规则。字段可能先被表单库收集，再经过前端 ...
给接口加返回字段，先让 Codex 把旧客户端护住
给接口响应加字段，看起来是后端工作里最安全的一类改动。新增字段不影响旧字段，旧客户端不读它，新页面可以直接用它。很多团队会把这类需求当成“顺手加一下”：DTO 里多一个属性，序列化结果里多一段 JSON，OpenAPI 文档补一下，然后发版。
给列表加一个字段前，让 Codex 先找清它从哪来
线上后台里有一种改动特别容易被轻视：列表多展示一个字段。产品说“订单列表加一列发票状态”，你打开页面，看到表格组件，心里觉得也就多一个 column。真正动手后才发现，字段不只在 UI 上出现一次。接口响应里可能已经有 `invoice_status`，前端类型里却没有；API client 可...
共享工作区里让 Codex 改代码：先护住别人的改动
多人共用一个分支、一个本地工作区，或者一个远程开发环境时，最危险的不是 Codex 写错一行代码，而是它把不属于自己的改动也“整理”了。你只是让它修一个表单校验，它看到旁边文件有格式不一致，就顺手格式化；你只是让它补一个接口字段，它发现测试失败，就把别人正在改的测试快照更新掉；你让它“恢复到能跑...
构建失败别只看最后一行：让 Codex 找到第一处有效错误
构建失败最容易误导人的地方，是它常常把真正的错误埋在中间，最后只留下一句很大的失败结论。你看到终端底部写着 `ELIFECYCLE Command failed with exit code 1`、`Error: Process completed with exit code 1`、`Buil...
函数太长先别急着拆：先让 Codex 锁住现有行为
最让人犹豫的重构，往往不是你看不懂代码，而是你看懂之后更不敢动。一个函数三百行，里面混着参数归一、权限判断、金额计算、状态转换、兼容旧数据、日志上报和错误提示。你知道它应该被拆开，也知道继续堆下去会越来越难维护。可问题是：现有测试很薄，历史 bug 又不少，函数里还有几段看起来怪但可能是线上补丁...
接手陌生仓库，第一小时让 Codex 帮你找到路
这篇文章教你在接手一个没有交接文档的陌生仓库时，如何用 Codex 做第一小时的项目导航。你会让 Codex 先只读仓库，识别技术栈、启动入口、关键目录、最近改动和测试方式，再产出一份可以人工核对的“项目入口地图”和“首日检查清单”。
老板只说列表更好用时，先让 Codex 问出验收标准
临时需求最容易让开发者难受的地方，不是它短，而是它短到没有边界。老板在群里说一句“把客户列表做得更好用”，产品还没来得及补说明，销售同事已经开始催上线。你打开页面，能想到很多可能的改法：加搜索、加筛选、调整列宽、固定表头、支持批量操作、优化加载速度、把最近跟进时间放到前面、给重点客户加标记。每一...
前端页面一启动就红屏：让 Codex 先抓第一条有效错误
前端红屏最让人烦的地方，不是它报错了，而是它一次性把很多东西都扔到你脸上：浏览器页面上有一大段红色堆栈，终端里同时刷出编译警告、框架提示、热更新信息，控制台还夹着旧的网络失败、React Strict Mode 的重复调用、source map 找不到、某个第三方 SDK 初始化失败。你明明只想...
线上接口偶发 500，怎样让 Codex 帮你串起请求、日志和代码
线上接口偶发 500，最折磨人的地方往往不是“报错”本身，而是材料分散：报警里只有接口路径，用户反馈里只有时间点，日志里夹着几十条相邻请求，本地又复现不出来。后端工程师真正要做的，不是立刻让 AI 猜答案，而是先把请求样例、时间窗口、日志片段、异常堆栈和处理函数放到同一张排查图里。
新逻辑别直接全量：让 Codex 先把风险改动藏到开关后面
很多风险改动不适合跟着代码发布一起全量生效。比如你要把订单推荐从旧规则切到新算法，把客服工单分配从固定队列改成动态评分，把会员页的权益计算换成新服务，或者把一个接口从同步处理改成异步任务。代码可以先合并，行为不一定要立刻打开。更稳的方式，是先把新逻辑接到功能开关后面，只让少量用户、租户、角色或内...
新增一个配置开关时，先让 Codex 别把所有环境一起改了
新增一个配置开关，看起来只是多加一行变量，实际很容易把所有环境一起带偏。开发环境为了调试希望默认打开，测试环境希望稳定覆盖，生产环境必须默认关闭；但项目里可能同时存在 `config/default.ts`、`config/test.ts`、`.env.example`、部署平台变量、容器启动参...
业务限制没人说清时，让 Codex 从代码里挖出规则和影响范围
很多系统里的业务规则并不在需求文档里，而是散在代码的判断条件、接口参数、权限中间件、测试用例、数据库字段默认值和前端提示文案里。产品问一句“为什么试用团队最多只能建 3 个项目”，工程师打开文档找不到说明，搜 `3` 又会搜出一堆分页大小、重试次数和 UI 间距。真正的限制可能藏在 `canCr...
页面报错时，让 Codex 帮你画出路由、组件和接口对应表
这篇文章解决一个很具体的问题：线上某个页面报错了，你只知道页面 URL、浏览器里看到的接口失败、仓库大概在哪里，但不知道这个页面对应哪个前端路由、哪个组件、哪个接口封装、哪个后端处理函数，也不知道本地应该跑哪条启动命令。
README 和脚本说法不一致时，先让 Codex 建一份事实清单
多年项目里最麻烦的不是“没有文档”，而是“文档、脚本、CI、部署记录和人的记忆都各说各话”。README 说部署要跑 `npm run deploy:prod`，仓库里却只有 `pnpm release`；老同事说要先手工同步配置，CI 里又显示部署前会自动生成配置；最近一次上线记录写着“临时绕...
Codex 本地环境排查：把跑不起来变成可定位问题
本地环境跑不起来时，不要只贴一句报错。用 Codex 整理系统信息、启动步骤、依赖版本、报错片段和最近改动，把问题从“玄学”变成可定位的排查表。
Codex 表单工具：把收集需求变成字段、校验和导出规则
表单不是把问题堆上去，而是围绕后续处理设计字段、校验、提示和导出。用 Codex 做表单工具前，先写清收集目的、字段规则、异常处理和人工复核。
Codex 测试补齐：从用户路径倒推出该补哪些测试
补测试不是为了追数字，而是为了保护关键用户路径。用 Codex 把页面操作、业务规则、边界条件和历史问题整理成测试缺口计划，先补最能挡住返工的测试。
Codex 代码库审计：把项目风险整理成一张维护地图
代码库审计不是让 AI 随便挑毛病，而是让 Codex 从结构、依赖、入口、配置、测试和高风险文件出发，整理一张普通负责人也能看懂的维护地图。
Codex 代码注释整理：删掉噪音，留下真正能帮维护的说明
注释不是越多越好。用 Codex 区分过时注释、重复注释、解释业务规则的注释和提醒风险的注释，把代码说明整理成维护者真的愿意看的样子。
Codex 发布检查：上线前把风险逐项摆到桌面上
发布前最怕靠感觉说“应该没问题”。用 Codex 对照改动范围、测试结果、页面截图、数据影响、回滚方式和通知对象，生成一份上线前发布检查表。
Codex 非技术验收：不用看代码也能判断交付能不能用
非技术负责人不需要读懂每行代码，也不能完全放弃验收。用 Codex 把需求、用户路径、截图、样例数据和风险边界整理成验收清单，让业务方能判断交付是否可用。
Codex 辅助无代码自动化原型：把重复表格任务变成一个可运行小工具
非技术同事也可以先把重复表格任务说清楚，再让 Codex 做一个可运行原型。教程从输入表格、处理规则、输出样例和验收清单开始，不把原型误当成完整系统。
Codex 回滚预案：上线前先想好怎么退回去
回滚不是出事后临时想办法，而是上线前就准备好的安全出口。用 Codex 把可回滚范围、触发条件、操作步骤、负责人和用户通知整理成预案。
Codex 任务拆分：把大需求拆成小步执行板
让 Codex 做复杂任务时，最怕一口气改太多。用任务拆分板把目标拆成材料准备、只读分析、小步修改、检查验证和复盘记录，让团队看得见进度，也守得住风险。
Codex 日志分析：从一堆记录里找出可验证线索
日志分析不是把日志全贴给 AI 求答案，而是先整理时间范围、用户动作、错误类型和已知改动。用 Codex 把日志线索转成排查假设和人工验证清单。
Codex 数据脚本：先验规则，再处理真实数据
让 Codex 写数据脚本时，最重要的不是代码多快生成，而是处理规则、备份、样例、异常和抽查都说清。用一份数据脚本验证表，避免把错误批量放大。
Codex 文档同步：让代码、页面和说明保持同一口径
代码改了，文档没改，是很多团队后续混乱的起点。用 Codex 对照改动、页面文案、README、帮助说明和内部 SOP，生成一份文档同步清单。
Codex 文件处理：把批量文件任务变成安全流水线
批量改文件、整理附件、转换格式时，最怕一次操作覆盖原件。用 Codex 先设计文件处理流水线：备份、筛选、命名、转换、抽查和回退都要写清楚。
Codex 小工具原型：用低风险样例跑通第一版
小工具原型不是直接做完整系统，而是用一组脱敏样例跑通输入、处理和输出。用 Codex 做第一版时，先控制范围、写清样例、验收结果，再决定是否继续扩展。
Codex 需求澄清：把一句想法变成可执行任务说明
很多 Codex 任务失败，不是工具不会做，而是人没有把目标、边界、材料和验收说清。用一份需求澄清简报，让普通同事也能把一句想法整理成可执行、可检查、可交接的任务说明。
Codex 页面改版：先定信息结构，再动页面样式
页面改版不能只说好看一点。用 Codex 先整理用户目标、现有问题、信息层级、模块去留和验收标准，再让它小步修改页面，避免视觉变化掩盖业务问题。