Codex Prompt 相关问题
输入“/”快速插入内容
Codex Prompt 相关问题
Codex Prompt 相关问题
用户771用户771用户9079用户9079用户9559用户95597月21日修改
1、Codex Prompt 怎么写？
Codex 的 Prompt 本质上是“任务说明”，而非“神秘咒语”。写 Prompt 的核心逻辑是减少 AI 的猜测，把任务讲清楚。一个高质量的 Prompt 通常包含以下四个核心要素，并可根据任务复杂程度采用不同的写作策略。
一、 高质量 Prompt 的四大核心要素
1.
目标（Goal）：明确“要做什么”
•
要求：具体、可交付，避免模糊的愿望（如“优化一下”）。
•
示例：“修复订单页在移动端 390px 宽度下，提交按钮遮挡描述文字的问题”或“将首页的‘提交’按钮文案改为‘立即下载’，并保持原样式不变”。
2.
上下文（Context）：提供“参考线索”
•
要求：提供任务相关的文件路径、报错信息、复现步骤、相关代码或设计稿，避免让 AI 在代码仓库中“大海捞针”。
•
示例：“问题出现在 /orders 页面，相关文件在 src/features/orders 目录，复现步骤为：1. 打开 /orders 2. 修改筛选条件 3. 点击提交 4. 观察按钮位置”。
3.
约束（Constraints）：明确“不能做什么”
•
要求：设定边界，防止 AI 过度发挥或引入意外改动，如限制修改范围、禁止新增依赖、保持接口不变等。
•
示例：“不要修改 API 返回结构”、“不要大范围重构，只做最小必要修改”、“保持现有 UI 样式，不要新增第三方依赖”。
4.
完成标准（Done When）：明确“怎么算完成”
•
要求：设定明确的验收条件，让 AI 能自我验证，避免“改完感觉差不多”就结束。
•
示例：“修复后重新验证复现步骤，并运行相关测试”、“刷新页面后设置仍然保留”、“检查 390px 和 1280px 宽度下按钮不遮挡正文”。
二、 不同场景的 Prompt 写作策略
1.
简单任务（直接执行）
•
适用场景：改文案、解释函数、小范围 Bug 修复。
•
写作策略：直接写清目标、上下文和约束，让 AI 直接执行。示例：“请解释 src/lib/billing 中 calculateInvoiceTotal 函数的逻辑，重点说明折扣和税费的合并计算方式，不要修改代码。”
2.
复杂任务（先规划后执行）
•
适用场景：跨模块重构、复杂功能开发、高风险修改。
•
写作策略：先让 AI 进入“计划模式”（Plan Mode），让其先阅读代码、评估影响、提出方案，确认方案后再让其执行。示例：“请先阅读 src/auth 和 src/permissions 目录，不要修改代码，列出将权限检查迁移到 middleware 层需要改动的文件及方案，确认后再开始修改。”
3.
模糊任务（先提问澄清）
•
适用场景：需求不清晰、方向未定。
•
写作策略：让 AI 先扮演“提问者”，通过提问帮你澄清需求，将模糊想法转化为具体任务。示例：“我想优化设置页的体验，但还没想清楚具体改哪里。请像产品一样问我 3 个关键问题，帮我梳理出可执行的开发任务。”
❤️
更多资料...
让 Codex 代码质量翻倍的 10 个高级 Prompt 模板
第一条 Prompt 怎么写：让 Codex 少猜一点
Codex 小白从 0 到 1：安装、设置、3 句 Prompt，跑通第一个练习项目
2、Codex 如何拆任务？
Codex 拆任务的核心在于将复杂任务分解为清晰、可控的小步骤，以下是一些常见的方法和思路：
1.
按阶段拆分
◦
适用场景：适用于大多数开发任务、bug修复、测试任务等，尤其是任务本身有明显的阶段性特征。
◦
示例：对于一个功能开发任务，可以拆分为“需求分析→设计→编码→测试→文档编写”等阶段，每个阶段作为一个子任务，明确每个阶段的目标、输入和输出。
2.
按模块拆分
◦
适用场景：适用于多模块联动的项目，如前后端分离的项目、大型代码库等。
◦
示例：对于一个包含前端、后端、数据库的项目，可以拆分为“前端页面开发→后端接口开发→数据库设计→前后端联调”等子任务，每个子任务专注于一个模块的实现。
3.
按职责拆分
◦
适用场景：适用于同一个需求中包含多种不同工作类型的情况，如分析、实现、验证、文档等。
◦
示例：对于一个复杂需求，可以拆分为“需求分析→功能实现→测试验证→文档编写”等子任务，每个子任务由不同的角色或工具负责。
4.
按风险拆分
◦
适用场景：适用于涉及高风险的操作，如支付、权限、数据迁移等。
◦
示例：对于一个涉及数据迁移的任务，可以拆分为“数据备份→数据迁移→数据验证→回滚方案”等子任务，将高风险的操作单独拆分出来，降低风险。
5.
按文件边界拆分
◦
适用场景：适用于明确知道会改哪些文件的任务，如大型代码库、需要控制改动范围的任务等。
◦
示例：对于一个需要修改多个文件的任务，可以拆分为“修改配置文件→修改接口文件→修改业务实现文件→修改测试文件”等子任务，每个子任务专注于一个文件的修改。