Codex 项目启动检查表：新手清单

用 Codex 做项目，不要从“请帮我改好”开始。更稳的第一步是填一张启动清单：目标是什么、证据在哪里、仓库状态如何、运行命令是什么、哪些内容不能碰、修改后怎么验证。

完整说明见 Codex 项目启动检查表怎么用。这篇是短清单版本，适合放进 Notion、表格、GitHub Issue 或项目前沟通记录。

适合谁

适合第一次用 Codex 阅读项目、修小 bug、整理 README、检查部署报错或做作品集练习的新手。你可以不熟悉全部代码，但要愿意先收集证据，再让 AI 辅助。

也适合项目前做项目诊断的人。客户项目不是练习场，启动前的清单越清楚，后续报价、修改、测试和交付越不容易失控。

不适合谁

不适合没有客户授权就连接私有仓库、读取密钥、修改部署配置或处理生产数据的人。也不适合把 Codex 输出直接当最终交付的人。

如果任务涉及账号登录、仓库授权、付费服务、客户凭据、生产环境、企业安全策略，先暂停，记录为待确认或明日待办。

风险提醒

清单不能替你保证结果，它只是让风险更早暴露。真正需要人判断的是：任务是否适合新手、目标是否可验证、客户是否给足材料、权限是否清楚、测试是否能覆盖关键路径。

如果你无法解释 Codex 改了什么，就不要交付。如果你没有运行任何验证命令，就不要告诉客户已经完成。如果你发现改动超出原范围，要先重新确认。

具体步骤

1. 目标

• 任务一句话：
• 成功标准：
• 不包含内容：
• 客户或自己最关心的页面：

目标必须能验证。不要只写“优化项目”。

2. 证据

• 报错日志：
• 截图：
• 页面路径：
• 失败命令：
• 客户原始描述：

证据越完整，Codex 越不容易乱猜。

3. 仓库状态

• 项目路径：
• 当前分支：
• git status 是否干净：
• 是否有用户未提交改动：
• 是否需要新分支：

如果工作区有别人改动，不要随意覆盖。

4. 运行命令

• 安装依赖：
• 启动项目：
• lint：
• test：
• build：
• 其他验证命令：

命令不确定就写“待确认”。不要编造。

5. 权限边界

• 不读 .env 明文：
• 不保存客户账号密码：
• 不修改支付、认证和生产配置：
• 不访问未授权私有仓库：
• 不接触真实用户数据：

这些边界要写在提示词里，也要写在交付记录里。

6. 给 Codex 的提示

请先阅读项目入口文件，说明你理解的任务和计划。
目标：
证据：
限制：
验证命令：
交付格式：

先让 Codex 解释计划，再让它改文件。这个顺序虽然慢一点，但更容易发现误解。

7. 修改后检查

• 看 git diff。
• 运行验证命令。
• 检查页面或日志。
• 记录失败项。
• 写清下一步和待确认事项。

不要只看 AI 的文字总结。

最低交付记录

最低交付记录包含：任务目标、修改文件、验证命令、验证结果、未解决问题、客户待确认事项。客户不一定要看所有技术细节，但你自己必须能复盘。

如果是练习项目，也建议这样写。作品集不只是最终截图，过程记录同样能证明你知道如何把问题拆小、验证和收尾。

常见启动错误

第一个错误是没有看仓库状态就改文件。如果工作区里已经有用户未提交改动，你的修改可能会和别人正在做的事混在一起。启动时先看 git status，不是为了形式，而是为了知道哪些文件已经不干净。

第二个错误是跳过 README 和配置文件。很多项目的启动方式、环境变量名称、构建命令和注意事项都写在文档里。Codex 可以帮你总结，但你要确认它总结的是当前项目，而不是通用经验。

第三个错误是把验证放到最后才想。正确做法是在动手前就写下验证命令。这样修改完成后，你不会只凭感觉判断结果，也更容易向客户解释这次交付经过了哪些检查。

CTA：下一步

复制这份清单，先填当前项目的目标、证据、命令和边界。需要模板时去 模板库，需要解释报错时用 报错解释器，需要估算诊断时间时用 报价计算器。

免责声明

本文是学习和流程整理，不构成法律、财务、安全或职业承诺。Codex 功能、权限、客户端和计划限制会变化，实际使用前需以官方说明、项目规范和客户授权为准。