理解旧项目
让它先画出目录、模块依赖、启动入口、风险点,再决定要不要动手改。
最有价值的不是写一个函数,而是替你吃掉那些重复、耗时、需要上下文切换的工程工作。
让它先画出目录、模块依赖、启动入口、风险点,再决定要不要动手改。
直接交给它定位异常链路、修改受影响文件,并补最小回归测试。
让它从回归风险、边界条件、测试缺口和行为变化四个角度看代码。
把一个需求拆成多步执行,边改边验证,最后输出可读的改动摘要。
如果你只想马上开始,本页最重要的就是这四步。先跑通,再慢慢提升协作质量。
Codex CLI 是最直接的入口,适合在项目根目录里协作。
npm install -g @openai/codex
推荐直接用 ChatGPT 账号登录,免手动拷贝 API Key。切换账号时可先退出。
codex --login codex logout
第一次不要上来就改代码。先让它讲清楚项目结构、运行方式和关键风险。
codex
读代码用 Suggest,批量改文件用 Auto Edit,长任务才考虑 Full Auto。
codex --auto-edit codex --full-auto /mode
不要把所有任务都交给全自动。模式选得对,质量和安全性会高很多。
默认模式。它可以读文件、提出修改和命令建议,但需要你确认后才执行。
它可以自动写文件,但执行命令前仍会征求你同意,适合中等规模改动。
它会在受限沙箱里自动读写并运行命令,适合长链路任务,但前提是边界要清楚。
除了终端,你还可以在 IDE、桌面应用或云端任务里使用同一套协作方式。
真正影响结果的不是模型名字,而是约束条件。文件范围、目标行为、验证方式,三样缺一不可。
先不要改代码。阅读这个仓库后,告诉我: 1)启动方式; 2)关键目录; 3)核心数据流; 4)最值得优先关注的风险点。
实现“批量导出”功能,只改 export 模块及直接相关测试。 保持现有接口不变,完成后运行测试并说明改动点。
定位登录接口 500 的根因。 先复现,再修复,再补一个回归测试。 不要顺手重构无关代码。
以代码审查的方式检查这次改动,重点看: 行为回归、空指针/边界条件、并发风险、测试缺口。 先列问题,再给建议。
程序员最省时间的用法,不是让它“从零写完整系统”,而是把你正在做的真实工作交给它分担。
这些规则看起来朴素,但决定了你是得到一个靠谱搭档,还是得到一台失控的代码生成器。
给出文件范围、非目标项和验收标准。没有边界的“帮我优化一下”,通常只会制造额外 diff。
对于陌生仓库,第一轮永远先做分析。你要先确认它理解的是不是同一个系统。
要求它跑测试、复现问题、解释结果。能自动验证的任务,优先使用可验证的提示词。
Codex CLI 官方对 Windows 的支持仍偏实验性质,复杂项目通常更适合在 WSL 或类 Unix 环境中使用。