提示词技巧
掌握高效的提示词编写策略，让你与 Codex 的交互事半功倍。本章从基础到高级逐步展开。
提示词结构
最佳模式
[角色] + [任务] + [上下文] + [约束] + [格式]示例：
作为有 10 年经验的后端工程师（角色），
将这个函数改为异步实现（任务），
当前版本会阻塞事件循环，当并发量高时导致延迟（上下文），
不要改变函数签名，保持向后兼容（约束），
输出修改后的代码和变更说明（格式）。关键要素
| 要素 | 作用 | 示例 |
|---|---|---|
| 角色 | 设定 AI 的专业背景 | "作为安全专家..." |
| 任务 | 明确要做什么 | "重构这个类" |
| 上下文 | 提供背景信息 | "当前实现存在内存泄漏..." |
| 约束 | 限定边界条件 | "不改动公共 API..." |
| 格式 | 指定输出形式 | "先列出变更清单，再实施..." |
上下文管理策略
短对话 vs 长对话
| 场景 | 推荐方式 |
|---|---|
| 简单修改（1-2 个文件） | 直接描述，无需额外上下文 |
| 中等工作（3-10 个文件） | 提供项目结构和关键文件引用 |
| 复杂重构（10+ 文件） | 分步骤执行，每步聚焦一个子任务 |
有效利用 "@" 引用
Codex 支持 @path/to/file 语法直接引用文件。合理使用可以减少上下文冗余：
# ✅ 引用关键文件代替完整粘贴
> @src/utils/auth.ts 中的 token 刷新逻辑有问题，
# ❌ 粘贴大量代码到提示词中
> function refreshToken() { ... 50 行代码 ... }控制上下文窗口
上下文窗口是有限资源。以下策略帮助你高效利用：
- 只引用必要的文件 — 不要一次性 @ 整个目录
- 用摘要替代全文 — "这个文件实现了用户认证流程，核心函数是 validateToken"
- 及时结束不需要的会话 — 超长对话质量会下降
- 使用
--continue恢复会话时 — 先总结当前进展
完整上下文模板
markdown
## 目标
想要实现什么
## 约束
- 技术栈：Next.js 14, TypeScript 5
- 性能要求：首屏加载 < 2s
- 浏览器支持：现代浏览器
## 当前状态
[描述现有代码或 Link 到仓库]
## 已尝试的方案
[说明之前做了什么，为什么不行]思维链提示
让 Codex 逐步思考：
> 在实现这个功能前，请：
> 1. 列出三种可行方案
> 2. 对比优劣
> 3. 选择最合适的方案
> 4. 逐步实现适用场景
| 场景 | 技巧 | 效果 |
|---|---|---|
| 架构决策 | 要求多个方案对比 | 避免盲目接受第一个方案 |
| 复杂调试 | 要求逐步推理 | 更容易定位根因 |
| Bug 修复 | 要求先分析原因 | 避免治标不治本 |
| 代码审查 | 要求逐项检查清单 | 确保不遗漏 |
少样本示例
给出参考示例，让 Codex 跟随相同的模式：
参考这个模式实现类似的工具函数：
// 已有示例
function formatDate(date: Date): string {
return new Intl.DateTimeFormat('zh-CN').format(date)
}
// 需要实现的函数
function formatTime(date: Date): string {
// 请按 formatDate 的模式实现
}负面指令
告诉 Codex 不要做什么，避免常见错误：
> 重构这个组件：
> - 不要使用 any 类型
> - 不要改变公共 API
> - 不要引入新的外部依赖
> - 不要修改测试文件常用模板
Bug 修复模板
发现 Bug：[描述]
复现步骤：1. ... 2. ... 3. ...
期望行为：[描述]
实际行为：[描述]
相关文件：@path/to/file.ts功能实现模板
功能：[名称]
用户故事：作为[角色]，我想要[功能]，以便[价值]
验收标准：
- [ ] 条件 1
- [ ] 条件 2
- [ ] 边界情况处理
技术约束：[语言/框架/性能要求]审查请求模板
请审查 @src/components/UserProfile.tsx：
1. 专注安全性（XSS、注入）
2. 关注性能（不必要的重新渲染）
3. 检查错误处理是否完整
4. 提出具体的改进建议学习探索模板
解释 @src/lib/cache.ts 中的实现：
- 这个缓存策略叫什么？
- 它的优缺点是什么？
- 在什么场景下不适合使用？
- 给出替代方案的简要对比高级技巧
1. 系统级指令
通过 AGENTS.md 设定全局提示词，确保 Codex 始终遵循：
markdown
## 项目约定
- 始终使用 TypeScript strict 模式
- 不使用 var，优先 const
- 所有用户输入必须经过 sanitize2. 元提示（Prompting about Prompting）
让 Codex 帮你优化提示词：
> 我要让 Codex 帮我重构一个 React 类组件为 Hooks。
> 该如何描述这个任务才能获得最佳结果？3. 工作流引导
对于多步骤任务，先让 Codex 列出计划再执行：
> 先不要写代码。请列出将这个项目从 JavaScript 迁移到
> TypeScript 的完整步骤，包括风险评估。
> 我确认后再开始实施。4. "开发者模式"提示
在需要 Codex 做出架构级决策时使用：
> 你是这个项目的高级技术负责人。请评估以下技术决策：
> - 当前方案的优势和风险
> - 替代方案的权衡
> - 你的最终推荐及理由
>
> 不要只说"这取决于具体需求"——给出明确的建议和理由。5. 结果验证指令
在提示词中要求 Codex 自我验证：
> 实现这个 API 端点，然后：
> 1. 写出你应该考虑的边界情况
> 2. 为每个边界情况编写测试
> 3. 运行确认测试通过提示范例对照
❌ 模糊提示 → 不理想结果
> 优化代码问题：不知道优化什么（性能？可读性？内存？），不知道约束条件。
✅ 具体提示 → 精准结果
> 优化 parseConfig() 函数的性能（当前 O(n²)），
> 数据量 10 万条时目标 < 100ms，
> 不改变函数签名和输出格式，
> 完成后运行 benchmark 验证。问题：明确目标、约束、验证方式。
下一步
- 任务规划 — 如何将提示词与计划模式结合
- 代码开发 — 在真实开发场景中应用这些技巧
- AGENTS.md 项目配置 — 用持久化指令减少重复提示