让Codex实现功能前先规定范围：输入、输出与完成条件示例

Codex功能请求的完成标准

步骤1	定义用户行动
步骤2	决定输入范围
步骤3	决定输出格式
步骤4	记录修改边界
步骤5	验证正常、边界与失败情况

这是整理阅读顺序的说明图，并非实际程序画面或测量结果。

向Codex请求“给我的应用添加下载功能”，虽然传达了目标，但要下载什么数据、采用什么格式以及修改到哪里，仍未确定。这些空白越多，看到结果后需要再次修改的部分就越多。与其一味编写冗长指令，不如具体规定输入、输出与完成条件，这有助于委托工作。

本文用简单CSV导出功能作为虚构示例，说明整理请求范围的方法，并非修改实际项目或运行程序的记录。示例文件名与画面名称仅用于说明，应根据自己的代码结构与需求修改使用。

1. 用用户行动表述工作目标

与其写“实现导出”，不如写“让用户能在列表画面中将当前查询结果下载为CSV文件”。说明结果使用者与行动后，实现目的会更明确。先说明用户需要做什么，而不是先指定内部代码结构；如果已有确定结构，可以补充相关文件与原行为。

OpenAI官方提示词指南建议根据需要提供目标、上下文、输出与边界；Codex请求则应包含所需行为、相关代码或复现步骤、重要约束与验证方法。本文请求格式是将这些原则应用于CSV示例，并不是必须包含固定咒语或特定关键词的格式。

规定目标时，也用一句话说明为什么需要该功能。例如，“运营负责人希望在另一张表中审查查询结果”，就能显示列名与日期格式为什么重要。但如果只提供理由，遗漏结果格式，仍然没有审查标准。应同时规定目的与实际输出条件。

2. 先规定输入范围

CSV功能输入应决定是全部数据、当前筛选结果，还是画面显示的一页。这三者结果差异很大。用文字规定用户所理解的“查询结果”范围，并写明是否反映排序与筛选。画面只显示20条，却是否下载1,000条，最好不要让Codex自行推测。

假设虚构需求为“反映当前所选搜索条件的全部结果，保持当前排序”。如果数据按页加载，仅复制画面中的数组可能不够。还需要确认相关数据请求与分页处理方式，因此可以要求Codex调查原查询路径并提出修改范围。

也应写明输入例外。结果为空时，是创建空文件、只创建列标题，还是显示提示，需要决定。如果只导出选中项目，也需要规定选中数量为0时的行为。提前记录这些条件，可以减少开发后再次询问“这种情况会怎样”。

需求项目	虚构示例	不明确时产生的问题
目标数据	符合筛选条件的全部结果	混淆单页与全部结果
顺序	保持当前所选排序	画面与文件顺序不同
列	名称、状态与创建日期	包含不必要的内部识别信息
空结果	显示提示，不创建文件	空文件看起来像错误
时间点	导出请求时的查询条件	筛选改变过程中结果混杂

3. 输出格式应具体到读者能够检查

规定输出文件名、字符编码、列名与顺序、日期格式及空值表示。CSV可能包含逗号、引号或换行的值，因此不能假定简单拼接字符串就能正确保存所有值。说明用什么程序打开文件，可以建立确认兼容性的标准。

虚构输出条件可以写成“首行为韩文列名，日期为YYYY-MM-DD，缺失值留空，保留含逗号、引号或换行的值”。这些条件能够验证。如果没有必须使用特定库的约束，委托它调查现有项目方式与依赖政策后选择实现，是自然的做法。

文件中看起来像数字的标识符应谨慎处理。需要规定要求，避免“0012”这样的编码被转为数字后丢失前导0。打开CSV的程序自动解释也可能影响结果，因此应区分文件原字符串与程序显示结果。实际标识符保留方法，应根据所用程序与格式决定。

4. 分别记录修改与保留的部分

修改范围应规定为功能所需部分，例如相关画面、数据处理与导出函数。需保留的内容，应具体写明原查询行为、画面设计整体结构、其他文件格式和访问权限等。仅写“保留原功能”，可能无法充分传达哪些行为重要。

虚构请求写“保留列表搜索、排序与分页行为，只增加CSV按钮及必要导出处理”，就建立了审查修改的标准。如果需要影响性能或权限的服务器修改，可以要求确认修改理由与范围。现有文件存在，与它满足现有要求，是不同事实，因此应调查实际代码上下文。

共同工作的项目，应说明已在修改的文件与负责范围。要求Codex确认当前工作状态，只修改必要部分，避免回退其他人的修改。委托一项功能，并不意味着必须同时进行无关清理、整体格式修改或依赖更新。

5. 将完成条件分为正常、边界与失败案例

正常案例是按预期处理的输入。边界案例是接近范围边缘的情况，例如空结果、单个项目、大型结果集合或包含特殊字符的值。失败案例则是数据请求失败或文件生成失败等。比大量编写测试更重要的是选择用户功能实际可能损坏的条件。

CSV示例可以确认“筛选结果与文件行一致”“保留含逗号与换行的名称”“空结果显示规定提示”“原列表搜索保持正常”。这四项可通过查看结果或相关测试确认。不能仅凭创建了测试文件，就断定所有条件已经确认。

还应检查环境是否可执行。要求Codex确认测试命令与必要依赖，报告实际执行的命令和结果。因环境限制而无法执行的验证，应标为未执行。区分只读代码后的推论、实际测试与实际画面确认，可以了解结果可信范围。

验证类型	虚构输入	完成判断
正常	多个普通文字项目	列与行符合要求
边界	空结果与单个项目	预先规定的提示与输出
特殊值	逗号、引号、换行与前导0	值不丢失，行不被错误拆分
失败	查询请求失败	显示明确状态提示，而非令人混淆的文件
回归	原搜索、排序与分页	确认原行为保持不变

6. 可以修改后直接使用的请求示例

用于说明的请求如下：“请在列表画面添加CSV导出。将当前筛选的全部结果按当前排序导出。列为名称、状态与创建日期；空结果只显示提示。保留含逗号、引号或换行的值，以及标识符的前导0。保留原搜索与分页。先确认相关代码，完成必要修改与验证，再告诉我实际确认结果。”

实际项目中，应补充相关画面或文件路径、使用的数据结构，以及已规定的测试命令。没有必要编造不知道的路径，可以委托调查，例如“请找到相关路径，说明结构后修改”。要求简短报告修改理由、关键文件、验证结果和剩余限制，更便于审查输出。

请求后出现新条件时，应说明它是否与已有条件共同保持。“文件名加入日期”的追加要求，并不替代之前规定的列、空结果与特殊值保留条件。反过来，如果改变要求，应明确哪些条件不再适用。小修改越多，越应把最终标准整理在一处。

7. 收到结果时的确认事项

确认修改说明是否与所需行为对应。如果实现声称导出全部数据，可以查看是否实际处理超过一页的结果，以及在哪里保留排序条件。没有必要理解全部内部代码，但每项要求都应关联确认位置与验证结果。

在修改前后，以相同条件比较重要示例会有帮助。打开虚构CSV，确认行数、列顺序并阅读特殊值。使用实际数据验证时，应选择资料，避免把不能公开的信息放入测试文件。审查结束后，区分请求完成条件中已满足与剩余项目，再决定下一次修改。

好的请求不是比谁写得长。输入范围、结果形式、需要保留的行为与检查案例彼此关联，就更容易委托工作并审查结果。核心是为Codex调查实际项目留出空间，同时具体规定读者所需结果。

官方资料与确认范围

• OpenAI：向Codex编写提示词
• OpenAI：Codex云端

资料确认日期：2026年10月5日。本文由AI查阅官方资料后编写。文中虚构案例与计算示例，并非实际用户记录或实验结果。服务条件、菜单及公开资料可能变化，必要条件请查阅当前官方指南。