004 结构化提问方法
掌握 RGC 提问公式，让 Codex 每次都准确理解你的意图，输出高质量结果。
学习目标
完成本课程后，你将能够：
一、RGC 提问公式
Codex 是一个 AI 智能体，它的输出质量**直接取决于你的提问质量**。RGC 是一个简单但高效的提问框架：
R — Role（角色）：为 Codex 设定专家身份
G — Goal（目标）：清晰描述要做什么
C — Constraints（约束）：限定范围、技术栈、规范
F — Format（格式）：指定输出格式完整示例对比
**❌ 差提问（无结构）：**
帮我写个登录功能Codex 不知道：用什么框架？什么语言？要不要验证？错误处理？这让输出不可控。
**✅ 好提问（RGC 方法）：**
【角色】你是一名资深 React + TypeScript 全栈工程师
【目标】为 Next.js 14 项目创建登录表单组件
【约束】
- 使用 React Hook Form + Zod 做表单验证
- 邮箱格式验证，密码至少 8 位
- 处理加载状态和 API 错误
- 符合项目已有的 Tailwind CSS 设计风格
- 组件放在 src/components/auth/LoginForm.tsx
【格式】
- 输出完整文件代码，包含 import
- 导出为 default export 的函数组件
- 使用 JSDoc 注释二、RGC 每个维度的用法
R — 角色设定
角色设定影响 Codex 的代码风格、注释质量和技术决策。
| 角色 | 适用场景 |
|---|---|
| "资深全栈工程师" | 架构设计、全栈功能开发 |
| "React 组件专家" | 前端组件开发，关注可复用性 |
| "DevOps 工程师" | CI/CD 配置、Docker、部署脚本 |
| "安全审计专家" | 代码安全审查、漏洞修复 |
| "性能优化专家" | 识别性能瓶颈、优化渲染/查询 |
G — 目标描述
目标要具体、可验证。对比：
| 模糊目标 | 具体目标 |
|---|---|
| "优化代码" | "将 ProductList 组件从 200 行重构为 <100 行，提取 3 个子组件" |
| "修复 bug" | "修复购物车商品数量不减反增的问题，错误出现在 CartContext.tsx 第 47 行" |
| "加测试" | "为 checkout.ts 的 calculateTotal 函数写 6 个测试用例，覆盖空购物车、折扣叠加、税率计算" |
C — 约束条件
约束让 Codex 不会"自由发挥"。常用约束：
# 技术约束
- 使用 TypeScript 严格模式
- 不引入新的第三方依赖
- 兼容 Node.js 18+
# 风格约束
- 使用 async/await，不用 .then()
- 变量命名用 camelCase
- 单个函数不超过 50 行
# 范围约束
- 只修改 src/services/ 目录
- 不要改动已有测试文件F — 格式要求
明确输出格式，避免 Codex 给出你不想要的形式：
- "只输出代码，不要解释" vs "先解释思路，再输出代码"
- "输出完整的 diff patch 格式" vs "直接输出修改后的文件"
- "用 markdown 表格对比方案优劣"
三、@file 引用技巧
Codex 支持 `@file` 语法直接引用项目中的文件，让 Codex 精确读取上下文。
基本用法
> /review @src/app/api/users/route.ts 检查这个文件的安全问题
> /test 参考 @src/utils/formatDate.ts 的实现风格，为 @src/utils/formatPrice.ts 写测试
> /refactor 参考 @src/components/ui/Button.tsx 的组件模式，重构 @src/components/ui/Input.tsx多文件引用
> /code 为 @src/types/user.ts 中的 User 类型，创建 CRUD API 路由
参考 @src/app/api/products/route.ts 的路由模式
> /debug 当调用 @src/lib/api.ts 的 fetchUser() 时出现错误
错误信息来自 @logs/error.log 第 15-30 行引用策略建议
| 场景 | 引用什么 |
|---|---|
| 写新功能 | 引用类型定义文件 + 类似功能文件 |
| 重构 | 引用原文件 + 项目中风格参考文件 |
| 调试 | 引用报错文件 + 日志文件 |
| 写测试 | 引用被测文件 + 已有测试示例 |
| 写文档 | 引用完整模块目录 |
四、多轮对话技巧
Codex 是对话式智能体，**不要期望一次完成复杂任务**。学会分轮迭代。
四轮迭代模式
第一轮：对齐理解
"我想给购物车添加优惠券功能，先不写代码，帮我梳理需要改哪些文件"
第二轮：分步实现
"好的，先实现第一步：在 hooks/useCart.ts 中添加 applyCoupon 方法"
第三轮：补充完善
"在表单上加上优惠券输入框，连接到刚才的方法"
"处理优惠券过期和已使用的错误状态"
第四轮：测试验证
"/test 为优惠券相关逻辑写测试"
"/review 审查这次变更的整体质量"上下文策略
Codex 会记住对话历史，不需要每次都重新描述背景。
- 同一任务的子步骤在同一个会话中完成
- 不同任务用新会话或明确说"开始一个新任务"
- 当上下文变得混乱时，重新打开 Codex 开始新会话
五、常见提问错误
| 错误类型 | 坏例子 | 改进 |
|---|---|---|
| 太模糊 | "改进代码" | "将 utils.ts 中重复的数组去重逻辑提取为独立函数" |
| 无技术栈 | "写个 API" | "用 Express + TypeScript 写一个 REST API" |
| 无错误处理 | "调用 API 获取数据" | "调用 API 获取数据，处理网络超时、4xx 和 5xx 错误" |
| 一次太多 | "同时写登录、注册、找回密码、OAuth" | 拆分成 4 个独立任务，逐步完成 |
| 角色缺失 | "帮我审查" | "你作为安全审计专家，审查这个文件中潜在的注入漏洞" |
六、本课总结
**核心要点：**
- RGC 公式：Role（角色）+ Goal（目标）+ Constraints（约束）+ Format（格式）
- `@file` 引用让 Codex 准确读取上下文，避免猜测
- 复杂任务分 4 轮迭代：对齐理解、分步实现、补充完善、测试验证
- 提问质量直接决定输出质量——花 1 分钟写好提问，省 10 分钟修代码
**下一步：** 下一课将深入学习 codex.yaml 的项目管理能力，掌握项目级配置和团队标准统一。