一、Codex 能做什么，不能做什么
Codex 擅长：
- 根据注释或函数名补全实现；
- 把重复代码抽成函数；
- 为已有代码补测试；
- 解释陌生代码；
- 根据报错定位问题；
- 生成正则、SQL、脚本和配置文件；
- 做小范围重构。
Codex 不擅长：
- 理解模糊的业务目标；
- 保证代码绝对正确；
- 了解你公司的内部规范；
- 处理复杂权限和合规问题；
- 替代架构设计和技术决策。
一句话：Codex 是高效的“初级工程师 + 搜索引擎 + 代码生成器”，但最终责任仍在人。
二、实战前的准备
在让 Codex 写代码前，先准备好三件事：
- 干净的分支
不要在主干上直接实验。新建分支，方便回滚。 - 可运行的测试
没有测试，AI 改完你无法判断对错。哪怕只有一个冒烟测试，也比没有强。 - 清晰的上下文
相关文件、接口定义、错误日志、输入输出示例，都要给它。上下文越完整，结果越靠谱。
一个实用的提示词模板：
目标：用 Python 实现一个批量重命名文件的函数。
上下文：项目使用 pathlib，已有测试框架 pytest。
约束：不依赖第三方库，支持 dry-run，避免覆盖已有文件。
输出：函数代码 + pytest 测试。
验收标准：能处理 IMG_001.jpg -> photo_001.jpg，且 dry-run 不实际改名。
三、核心工作流：小步、测试、审查
推荐循环：
拆任务 → 给上下文 → 生成代码 → 人工审查 → 跑测试 → 提交 → 下一步
不要一次让 Codex 写 500 行。每次只改一个函数、一个文件、一个明确问题。小步提交，出错容易定位。
实战案例：批量重命名脚本。
需求：把 IMG_001.jpg 重命名为 photo_001.jpg，支持预览，避免覆盖。
可以让 Codex 生成类似代码：
from pathlib import Path
import re
def rename(folder, pattern, repl, dry_run=True):
for p in Path(folder).glob("*"):
new = re.sub(pattern, repl, p.name)
if new != p.name:
if dry_run:
print(f"{p.name} -> {new}")
else:
p.rename(p.with_name(new))
然后让它补测试：
def test_dry_run(tmp_path, capsys):
(tmp_path / "IMG_001.jpg").write_text("x")
rename(tmp_path, r"IMG_(\d+)", r"photo_\1", dry_run=True)
assert "IMG_001.jpg -> photo_001.jpg" in capsys.readouterr().out
这段代码很短，但已经能体现 Codex 实战的关键：先给约束，再生成，再测试，最后人工检查边界情况。
四、如何写出高质量的 Codex 提示词
差提示词：
帮我写个重命名脚本。
好提示词：
用 Python 写一个批量重命名函数。使用 pathlib，支持正则替换，默认 dry-run。如果目标文件已存在，跳过并打印警告。不要使用第三方库。附上 pytest 测试，覆盖正常重命名、dry-run 和文件冲突三种情况。
好提示词通常包含：
- 语言和框架；
- 输入输出；
- 边界条件；
- 错误处理；
- 依赖限制；
- 测试要求；
- 验收标准。
如果 Codex 第一次结果不理想，不要重写整个提示词。只改一个变量，比如“增加文件冲突处理”，然后重新生成。这样你能知道是哪句话影响了结果。
五、调试与重构实战
遇到报错时，不要只贴一句“报错了”。把完整堆栈、相关代码、输入数据、期望结果一起给它。
例如：
这是报错堆栈和相关函数。请先解释原因，再给出最小修复方案。
不要重写整个文件，只改必要的几行。
重构时，可以让 Codex 先分析再动手：
请先指出这个函数的三个问题：可读性、边界条件、性能。
然后给出重构后的版本，并说明为什么更安全。
但记住：AI 的重构建议不一定符合团队规范。命名、分层、依赖注入方式，仍要由人决定。
六、测试与质量门禁
Codex 生成代码后，必须过质量门禁：
- 单元测试是否通过；
- 是否覆盖边界条件；
- 是否有安全漏洞；
- 是否引入新依赖；
- 是否符合代码风格；
- 是否有许可证风险。
建议在 CI 中加入：
- lint；
- 单元测试；
- 类型检查；
- SAST 静态扫描；
- SCA 依赖扫描。
Codex 可以帮你写测试，但你不能让 Codex 自己判断“测试通过了”。必须真实运行。
七、安全与合规
AI 生成代码的安全风险不容忽视：
- 可能硬编码密钥；
- 可能使用过时或有漏洞的库；
- 可能生成不安全的 SQL、命令拼接；
- 可能复制受版权保护的代码；
- 可能泄露敏感上下文。
实战原则：
- 不要把密钥、用户数据、内部文档直接贴给外部 AI。
- 生成代码必须经过安全审查。
- 关键路径必须人工复核。
- 依赖库要检查许可证和漏洞。
- 提交前用密钥扫描工具检查。
八、团队协作建议
如果团队要用 Codex，建议统一规范：
- 统一提示词模板；
- 统一代码风格和审查清单；
- 禁止直接提交 AI 生成代码；
- 要求每个 PR 说明哪些部分由 AI 生成；
- 建立内部知识库，沉淀好用的提示词和反面案例；
- 定期复盘 AI 引入的缺陷。
Codex 不是个人玩具，而是团队流程的一部分。用得好，能提升交付速度；用不好，会制造更多技术债。
九、局限与最佳实践
Codex 的局限：
- 会幻觉，编造不存在的 API；
- 上下文窗口有限，长项目容易丢失细节；
- 对业务规则理解不足；
- 可能过度设计或过度简化；
- 无法为最终结果负责。
最佳实践：
- 小步提交，频繁测试。
- 先写测试，再让 AI 写实现。
- 给足上下文，但不要泄露敏感信息。
- 让 AI 解释代码，而不是盲信代码。
- 关键模块必须人工审查。
- 把 AI 当副驾驶，而不是自动驾驶。
结语
Codex 实战的核心，不是“让 AI 写更多代码”，而是“让工程流程更高效”。它能帮你写函数、补测试、查报错、做重构，但定义问题、拆解任务、审查结果和承担责任，仍然是人的工作。
真正高效的用法是：
明确目标 → 拆小任务 → 给足上下文 → 生成代码 → 人工审查 → 跑通测试 → 小步提交 → 持续迭代
工具会不断进化，但工程判断力不会过时。Codex 是放大器，不是替代品。
