Codex首个请求这样写：编码提示词实用示例

摘要： “让此输入得到此结果”比“自行做好”更容易建立工作标准。首个请求应同时包含要解决的问题与确认方法。

1. 请求前确定完成后的场景

委托编码前，用一句话写明用户应在什么界面做什么。“改进搜索”是方向；“没有搜索结果时显示提示，而不是空白页面”是可确认行为。有后者，修改代码后即可比较结果。

OpenAI的Codex提示词指南也强调所需行为、相关代码或复现步骤、保留条件与验证方法。本文章示例是将这些原则应用于假想博客搜索功能的自编示例。应关注会改变结果的信息，而不是形式化填满所有项目。

2. 简短传递四种信息

问题： 写明不便之处与发生时机。 位置： 告知相关界面或文件。 条件： 指定不可改变的功能。 验证： 写明确认什么就算完成。这四点通常足够开始小任务。

只说“手机搜索有问题”，难以判断是输入栏大小、搜索速度还是结果显示。应记录观察，例如“手机宽度下搜索按钮换行，与输入栏重叠”。不确定原因时，无需断定“这是CSS问题”。区分症状与原因猜测，能保留调查空间。

3. 可复制修改的首个请求示例

블로그 검색 화면에서 결과가 0개일 때 안내가 없습니다.
검색어가 입력되어 있고 결과가 없으면
'검색 결과가 없습니다. 다른 검색어를 입력해 보세요.'를 보여 주세요.
검색어가 비어 있으면 기존 화면을 유지해 주세요.
대상은 src/search 폴더이며, API 응답 형식은 바꾸지 마세요.
기존 테스트 방식에 맞춰 필요한 검증을 수행해 주세요.
완료 후 변경 파일, 확인한 동작, 실행 명령과 결과를 알려 주세요.
직접 확인하지 못한 사항은 별도로 표시해 주세요.

示例重点不是提示文字长度，而是区分空搜索词与0条搜索结果。遗漏条件，可能首次打开页面就显示“没有结果”。加入一两个边界案例，可更准确传达意图。

4. 后续请求只传递观察差异

首个结果不符预期时，应说明差异，而非重新粘贴整个请求。例如“搜索中也会短暂显示无结果提示，请在加载中隐藏，仅在响应结束后显示”，能明确下一修改标准。

如果自己修改了文件，也宜告知。“提示文字已由我修改，请保留文字，只调整显示条件”，应以当前状态请求。实际文件优先于先前对话设定。修改后还需确认是否因浏览器缓存或运行服务器状态而看到旧界面。

5. 工作偏离时的检查清单

• 范围扩大了吗？ 请求解释搜索界面之外的修改文件为何必要。
• 混淆执行与建议了吗？ 要求分开实际执行命令与执行方法指南。
• 环境受阻了吗？ 确认是必要工具、无法访问路径，还是失败安装阶段。
• 成功标准模糊吗？ 具体规定正常搜索、0条结果与加载中等比较案例。

权限问题导致命令无法执行时，不应立即认为代码错误。反之，命令执行也不意味着所需行为已验证。回答应说明检查了哪些案例、还剩什么。结果难判断时，可要求将各变更对应到原请求解决的条件。

6. 用表格整理搜索界面状态后请求

界面功能只说明正常结果，会遗漏重要状态。搜索页面初次打开、仅输入、等待响应、没有结果与服务器失败，各自不同。添加“没有搜索结果”的小任务，也需要划分状态，减少搜索中错误提示。下表是假想博客要求，应按真实产品政策修改。

状态	显示内容	应避免的结果
搜索前	既有提示界面	一开始显示无结果
请求中	既有加载显示	空结果提示提前出现
成功、有结果	搜索结果列表	混合旧结果与新结果
成功、0条结果	无结果提示	显示得像发生错误
请求失败	失败提示与重试方法	误认为正常空结果

制作表格后，只需决定标准不明确的格子。例如搜索词仅空白时是否不请求、是否保留旧结果。每次输入自动搜索，与点击按钮才请求，也不同。已有方式时，写明保持即可。用户视角状态表无需预先指定实现代码，也能准确传达行为。

7. 小任务与大任务采用不同请求结构

适合直接实现的小请求

검색 결과 없음 안내를 구현해 주세요.
완료된 응답이 성공이고 결과 배열이 비었을 때만 표시합니다.
요청 중·요청 실패·아직 검색하지 않은 상태에서는 표시하지 않습니다.
기존 로딩과 오류 안내, API 형식, 검색 실행 시점은 유지하세요.
프로젝트의 기존 스타일과 테스트 도구를 사용하세요.
새 라이브러리 추가가 필요한지 먼저 현재 코드에서 판단하세요.
변경 내용과 상태별 검증 근거를 정리해 주세요.

该请求分开所需行为与保留条件。只强调“不要使用新库”，可能在现有代码无法实现时勉强执行。宜让其判断当前结构是否可行，并说明避免不必要依赖的原因。先写产品重要结果，而不必指定全部实现选择。

存在选择的任务先调查

검색어 자동 완성 기능을 추가하려고 합니다.
현재 검색 실행 방식, 데이터 크기, 관련 화면 구조를 조사해 주세요.
클라이언트 검색과 서버 검색 중 현재 프로젝트에 맞는 선택지를 비교하세요.
선택지마다 수정 범위, 필요한 데이터, 검증 방법을 설명하세요.
사용자 입력 전송 방식이나 API 변경이 필요한 결정은 분명히 표시하세요.
아직 구현하지 말고 현재 자료로 판단할 수 없는 조건을 남겨 주세요.

自动补全等设计可能不同的任务，未了解数据位置与大小就实现，后续可能扩大范围。先审查选项、确定方向，再请求实现。反之，一行文字修改无需冗长设计文档。可按“尚未决定的条件有多少”，而不只按难度，决定是否设置调查阶段。

8. 结果错误时的四种后续请求

首个结果不符预期时，应发送观察差异而非不满表达。同时写明界面、输入与操作顺序，更容易复现。例如“不能用”无法区分保存与消息问题；“点击搜索后立即出现无结果提示，响应到达后变成列表”，则提供了调查显示条件的线索。

표시 조건 보완:
검색 버튼을 누른 직후 빈 결과 문구가 먼저 나타납니다.
요청 중에는 기존 로딩만 보이도록 표시 조건을 조정하세요.
이미 바뀐 안내 문구와 정상 결과 목록은 유지하세요.

범위 보완:
검색 화면 수정 외에 공통 레이아웃도 바뀌었습니다.
공통 변경이 이번 요구사항에 필요한 이유를 설명하세요.
필요하지 않은 변경만 분리해 되돌리는 방안을 제시하세요.
다른 사람이 만든 변경은 보존하세요.

검증 보완:
테스트 통과라고 보고했지만 실행 명령이 없습니다.
실제로 실행한 명령과 결과를 알려 주세요.
실행하지 않았다면 미실행으로 정정하고 가능한 검증을 수행하세요.

현재 파일 보완:
안내 문구는 제가 방금 수정했습니다.
현재 파일의 문구를 기준으로 표시 조건만 보완하세요.
이전 답변의 문구로 덮어쓰지 마세요.

每个后续请求关注一种差异。文字、状态、设计与格式同时重做，会难以追踪前次修改哪里出错。可先解决行为，再单独处理文字与界面。要求还原时，应区分仅无关修改，而不是还原整个文件，以保留当前工作。

9. 阅读实际完成报告，决定下一行动

良好报告应连接要求与依据。只有“修改三个文件”的清单，无法判断搜索前状态是否保留。应请求总结各状态对应哪些代码与验证。复制下方格式，可方便区分已做与未做工作。

결과를 다음 표 형식으로 정리해 주세요.
요구사항 | 대응 파일 또는 로직 | 실제 확인한 근거 | 남은 확인
검색 전 화면 유지
요청 중 빈 결과 문구 숨김
성공 응답의 결과 0개 안내
요청 실패 시 기존 오류 안내 유지
정상 검색 결과 유지
검증 명령은 실제 실행한 것만 적고, 실패와 미실행을 구분하세요.

实际命令失败时，应根据日志首个原因决定下一请求。“找不到命令”是环境或工具问题；“预期文字与实际文字不同”可能是行为或测试预期问题。不能都作为同一“测试失败”处理。难以阅读代码差异时，可要求用简单句子与输入示例说明各条件变更。

界面功能可能同时需要自动验证与直接使用检查。人工确认可打开页面，查看搜索前状态，依次输入有结果与无结果搜索词。请求失败宜通过项目测试或开发模拟响应确认。无需将任意修改真实服务网络或生产数据作为基本流程。

最后，仅将本任务新确认的事实传递给下一请求。相关位置与验证命令已明确，就无需重述冗长背景。也不要把每次任务条件都变成永久规则。多个任务重复的约定放AGENTS.md，特定功能要求放对应请求或记录，可使提示词更简洁。

10. 常见问题

提示词必须很长吗？ 比长度更重要的是影响结果的信息。小修改可从几句话开始，后续补充必要背景。

需要指定全部文件吗？ 先告知已知相关位置。不知道准确文件，可提供界面名称与复现步骤，并请求调查。

每次都先获取计划吗？ 范围大或存在设计选择时，计划有帮助。简单文字修改无需冗长计划，但始终宜明确需要说明还是实际修改。

官方来源与确认日期： OpenAI官方文档：提示词。2026年10月3日确认。示例路径与命令应按自己的项目调整。