Codex 自动化开发流程新手检查清单

用 Codex 做开发任务时，最危险的不是它改得慢，而是你不知道它改了什么。新手需要一张固定清单，把每次任务都拆成需求、权限、文件、命令、验证和交付。这样即使用工具提速，也不会丢掉基本工程判断。

这份清单是草稿，适合和 Codex 自动化开发流程哪些步骤不能省、常见错误 和 /templates 搭配使用。

适合谁

适合准备让 Codex 处理小范围代码修改、静态页面、报错诊断、模板整理和轻量脚本的新手。你需要能看懂基本 diff，并愿意跑验证命令。

也适合已经开始接客户小单的人。清单可以帮你把“工具输出”变成“可交付结果”，而不是只把代码复制给客户。

不适合谁

不适合生产数据库、支付配置、账号权限、隐私数据、安全漏洞和大规模系统改造。这些任务需要更严格的授权和专业复核。

也不适合没有仓库、没有测试方式、没有验收标准的任务。不能验证的任务，不适合作为自动化开发交付。

具体步骤

1. 记录客户原始需求和你复述后的目标。
2. 标出敏感信息，先脱敏再让工具处理。
3. 运行或查看 git status，确认工作区状态。
4. 列出预计修改文件，避免无限扩散。
5. 执行前读相关脚本，例如 package scripts、测试命令和部署说明。
6. 修改后看 diff，删除无关改动。
7. 跑检查命令，并记录输出。
8. 写交付说明和未覆盖范围。

开始前清单

• 需求是否能用一句话复述？
• 客户是否提供了必要材料？
• 是否涉及账号、密钥、真实数据或生产环境？
• 工作区是否干净？
• 是否知道要改哪些文件？
• 是否知道验证命令？
• 是否准备了回退方式？
• 是否需要人工复核？

修改后清单

• diff 是否只包含本次任务相关内容？
• 是否跑过 lint、build、测试或内容检查？
• 是否有截图、日志或命令结果？
• 是否检查了配置文件和环境变量没有被误改？
• 是否保留了客户待确认项？
• 是否写清未覆盖范围？
• 是否没有把 draft 内容公开？

命令记录模板

修改前状态：
执行命令：
通过检查：
失败检查：
修复动作：
最终验证：
提交说明：

命令记录不需要很长，但要能让你下次回看时知道：当时为什么这么做，结果是否真的通过。

复核问题

交付前可以再问自己三遍：这次改动是否只服务于原需求？有没有把客户没要求的功能也改了？如果客户明天问“你怎么验证的”，我能否拿出命令、截图或文件记录？如果任何一个问题答不上来，就先不要提交或交付。

对于内容类自动化，还要额外检查草稿状态。生成内容不等于可以公开，draft、review、archived 必须继续隔离，不应该进入公开博客列表或 sitemap。

交付前复述

真正交付前，把结果用一段短话复述给自己听：这次任务的目标是什么，改了哪些文件，验证命令是什么，哪些范围没有覆盖，哪些事项还需要客户确认。如果这段话说不顺，通常说明任务边界还没有收紧，或者验证证据还不够。此时继续扩写功能只会制造更多不确定性。

复述时也要把发布状态放进去。对于内容草稿，必须确认它仍然是 draft、noindex、需要人工审核，并且没有出现在公开博客列表、sitemap 或导航入口里。对于代码任务，则要说明有没有触碰生产配置、账号权限、付款链路和客户隐私数据。清单的目的不是让流程变慢，而是让每一次提速都有刹车。

风险提醒

不要让工具替你决定是否能项目。它可以分析代码和生成建议，但无法替你承担客户沟通、授权确认和交付责任。

不要跳过人工复核。特别是涉及权限、付款、隐私、生产环境、平台规则和客户数据时，先暂停，不要让效率冲掉边界。

免责声明

本文仅供学习和流程检查参考，不构成安全、法律或平台合规建议。真实项目应按客户授权、项目规则和可验证结果处理。

CTA：用 /templates 保存检查记录；需要客户追问时先用 /tools/proposal-generator 起草，再按本文清单人工复核。