codex提示词学习
了解项目
请阅读当前项目结构，不要修改任何代码
告诉我：
1 这个项目是做什么的
2 使用了那些技术栈
3 入口文件在哪里
4 启动，构建和测试命令是什么
5 如果我要新增一个功能，应该从哪里开始
理解完成后如果模型可以查看是否理解准确了
提示词：
你刚才对项目的理解，有哪些地方是不确定的
请列出来，并说明你还需要查看那些文件
code最佳实践
一共四步：指定范围，指定状态，指定验收标准，随时中断
指定范围：针对大项目，不要让codex在项目里胡乱寻找，要将具体要改动的文件或者功能部分告诉他，在app或者ide里可以通过@指定文件
在cli里可以写：
请只阅读src/pages/login 和src/hooks/userAuth相关文件
帮我判断登录跳转逻辑是否存在时序问题
指定状态：
明确告诉agent，现在是只读还是可以修改
如：先不要修改，只输出分析/ 可以修改代码，但是修改前给我计划/ 请按照计划直接修改，完成后运行相关测试
指定验收标准：
如：
完成后请确保：
1 npm run lint可以通过
2 相关测试可以通过
3 不引入新依赖
4 不修改无关文件
5 最后总结修改内容，验证结果和剩余风险
随时中断：
在ai执行的过程中，点击暂停按钮，然后告诉他：
暂停刚才的方向，你现在的理解有问题
正确目标是xxx，请基于当前diff重新评估，不要继续扩大修改范围
提示词/指令越明确/具体越好，避免模型自己猜测：
请阅读src/pages/dashboard相关文件
我觉得这个页面有三个问题：
1 首屏信息太散
2 移动端布局容易挤压
3 接口失败时没有明显反馈
先不要修改代码，请输出你的修改计划，告诉我修改那些文件，以及为什么这样修改
codex多模态能力：
如果前端页面布局不合理，最好的办法就是将其截图然后放到目录下然后说
这个是当前页面的截图
请结合截图和代码，判断布局问题可能出现在哪里
先不要修改代码，只输出原因和修改方案
版本管理：
codex改代码前必须查看git状态，通过git指令或者可视化工具来进行版本管理：
请检查当前git状态：
告诉我哪些未提交修改
不要修改任何文件
注意：每次让codex进行修改后让其总结一下diff，保证自己能够掌握基础的进度
请总结这次修改：
1 改了那些文件
2 每个文件改了什么
3 为什么要这样改
4 是否还有风险
5 建议我如何验证
上下文管理
随着对话轮次的增加，上下文窗口变得越来越重，ai就会变得越来越笨重
保证上下文窗口的干净很重要，尽量保证每个对话只完成一类任务（这个线程只修bug，另一个线程只做组件重构）
请总结这个任务。
包括：
1 目标是什么
2 最终改了什么
3 已验证什么
4 还有什么风险
5 后续继续做应该从哪里开始
长期记忆
claude code里是claude.md而codex里面就是agents.md;可以理解为给agent的项目说明书
codex会读取文件并将其中的规则作为长期上下文
全局层面：存放用户的个人偏好
项目根目录：存放项目规范（技术栈，启动命令，测试命令，代码风格，目录约定）
子目录里：存放模块对应的规则（目录是老代码，不要重构公共接口；模块里的所有请求必须走统一封装）
在项目根目录存放agent.md
# Project Instructions
- 默认使用中文回答。
- 修改代码前，先说明计划。
- 不要主动引入新依赖，除非明确说明原因。
- 不要重构无关文件。
- 前端组件需要考虑 loading、empty、error 状态。
- 涉及用户输入时，需要考虑校验和错误提示。
- 修改完成后，优先运行 npm run lint 和相关测试。
- 如果测试无法运行，需要说明原因和剩余风险。
长期记忆的作用：将工作流程标准化，将团队的代码规范，分支规范，测试规范和目录约定都写进去
skill:结构化的指令和资源集合
一套做事的方法，告诉codex遇到某类任务时，应该按照什么流程，检查什么风险，用什么标准输出
写作 skill。
把你的文章结构、语气、禁用词、案例组织方式都写进去。
以后你让 Codex 写稿子，它就不需要每次重新适应你的风格
把这些东西写成 skill，就变成了可以复用的工作流
可以使用codex创建skill如：
请帮我创建一个前端代码审查skill
他需要在review时重点检查：
1. 是否破坏现有组件规定
2. 是否引入不必要的破坏
3.是否有响应状态混乱
4.是否有遗漏loading，empty，error状态
5.是否有移动端适配问题
6，是否补充必要测试
skill与plugin的区别：
skill更像是方法，plugin更像是一个工具箱（mcp服务）
重点：能力越大，边界越重要，插件并不是越多越好，权限并非给的越多越好，涉及到公司仓库，邮件，聊天记录，文档权限的时候要注意数据边界
自动化
给codex一个任务，再给他一个时间规则，让其自己周期性的执行（定时任务）如
每天早上九点，检查当前项目过去24小时的提交记录
输出：
1，主要改动
2，涉及模块
3，潜在风险
4，今天需要我关注的地方
不要修改代码
每天晚上总结：
每天晚上 6 点，总结今天当前项目的 git diff。
告诉我：
1. 改了哪些文件
2. 每个文件大概改了什么
3. 有没有明显风险
4. 明天继续做应该从哪里开始
codex适合执行：重复，明确，有固定判断标准，先让agent从只读任务开始，先汇报进度，不进行任何修改然后再慢慢扩大权限。
完整的工程实践：
第一步拆解需求：
我想做一个番茄钟应用
请先帮我拆需求，不要写代码
输出：
1，核心功能
2，可选功能
3，第一版的最小可用范围
4，可能的边界情况
5，推荐的实现顺序
第二步，让codex读项目
请阅读当前项目结构
判断番茄钟功能应该放在那些目录下
先不要修改代码，
只输出文件计划，包括要新增那些文件，修改那些文件，以及原因
第三步：让codex小步实现第一版
按照刚才的计划实现第一版
要求：
1，完成25分钟工作计时和五分钟休息计时
2，支持开始，暂停，重置
3，支持工作和休息状态
4，UI简洁，不要做复杂动画
5，不要引入新依赖
完成后运行项目检查是报错
上述并没有完成很多复杂任务，只是在完成之前一版的最关键核心功能，然后画面简洁
第四步：让其自己检查自己
请review这次改动
重点检查：
1，计数器是否正确
2，组件卸载后是否可能继续 setstate
3，开始和暂停状态是否混乱
4，重置逻辑是否正确
5，移动端布局是否会溢出
6，有咩有不必要的复杂代码
先输出review结果，不要修改
第五步：让codex进行修改
请根据刚才review里确认的问题进行修复。
只修改和这些问题相关的代码
不要做额外的重构。
完成后再次总结diff。
第六步：沉淀经验
请总结这次实现番茄钟功能的过程。
包括：
1，最终的文件结构
2，核心思路实现
3，遇到的问题
4，后序如果要加历史记录和通知提醒，应该从哪里开始
5，那些规则可以写进AGENTS.md里
常用codex指令模板：
读项目：
请先阅读当前项目，不要修改任何代码。
帮我总结：
1. 项目是做什么的
2. 技术栈是什么
3. 目录结构如何组织
4. 启动、构建、测试命令是什么
5. 新增一个页面应该从哪里开始
6. 当前项目有哪些明显维护风险
修bug：
我遇到了一个 bug：XXX。
请先阅读相关代码，不要修改。
输出：
1. 可能原因
2. 涉及文件
3. 你需要进一步确认的信息
4. 修复计划
执行修改模板：
请按刚才确认的计划修改代码。
要求：
1. 修改范围只限于 XXX
2. 不要引入新依赖
3. 不要重构无关代码
4. 完成后运行相关测试
5. 最后总结修改内容和风险
review模板：
请 review 当前 git diff。
重点关注：
1. 是否破坏现有功能
2. 是否有边界情况遗漏
3. 是否有错误处理缺失
4. 是否有类型问题
5. 是否有安全风险
6. 是否需要补测试
只输出问题，不要修改代码。
任务收尾模板：
请总结这个任务。
包括：
1. 目标是什么
2. 最终改了什么
3. 已验证什么
4. 还有什么风险
5. 后续继续做应该从哪里开始
核心逻辑：
先读，再计划，再执行，再验证，在总结。
代码管理：
git init
git add .
git commit -m "initial commit"
浙公网安备 33010602011771号