样稿 V1 · 待审核 · 资料核对2026-10-31一句话答案把“要交付什么、依据什么、有哪些边界、怎样算完成”说清楚再要求 Codex 对照原材料核验。对办公和运营任务而言这比只写“专业一点、详细一点”更容易检查结果是否合用。图 1AI 生成的概念封面不是软件界面。为什么一句“帮我写周报”还不够周报可能给部门负责人看也可能给客户看可能只汇总进度也可能要分析问题。如果任务只写“帮我写一份专业周报”读者、材料范围和完成标准都留空了。最终文笔再顺也不容易判断它是否完成了你的任务。这里所说的“提示词”就是你交给 Codex 的任务说明。OpenAI 的使用建议强调目标、上下文、限制和完成条件提示文档也建议提供与任务有关的材料与预期结果。S1OpenAI《Best practices》S2OpenAI《Prompting》。本文把这些建议转成办公人员容易使用的四个问题。它是任务检查框架不是必须照抄的固定语法也不能保证每次输出都正确。四个要素分别解决什么问题要素需要写清楚的内容运营周报示例目标交付物是什么给谁使用给项目负责人一份工作进展摘要材料读哪个文件采用哪些记录只用指定周记中的 N1—N4限制哪些内容不能擅自改变或补写原件不改缺失日期和负责人写待确认验收怎样检查是否完成按三类输出每条标来源编号复核数量与状态图 2写作框架示意依据 S1、S2 整理。如果任务很小不必每次写四个标题。“只读这份名单列出重复编号和对应记录号先不改原件”已经包含了材料、目标、限制和检查线索。需要做多步工作时再展开说明。一个可以直接照做的周报案例先准备一份文本文件并让 Codex 能够读取它可以在已经打开的项目中使用该文件也可以通过当前入口支持的附件方式提供。若文件尚未被成功读取就先处理访问问题不能假定它已经看过内容。本例使用专为教程编写的合成周记所有人物与事项均为演示用途。材料包含四条记录记录原材料中的关键事实N112 份产品资料已归档其中 2 份缺少版本日期N2审核 5 篇稿件3 篇通过2 篇退回补充来源N3报名表已建立上线时间待确认负责人未填写N4检查 4 张统计表发现 1 处口径不一致尚未修正这些数据只来自本地合成文件不是业务业绩也不是官方产品测试结果。[E1本次合成材料与演示记录2026-10-31。]可以把下面这段任务说明交给 Codex并替换成自己的文件名目标把“运营周记_合成示例.txt”整理成一份给项目负责人的工作进展摘要。 材料只依据该文件的 N1—N4 四条记录。 限制原文件不改动。不要补写材料没有提供的上线日期或负责人未确定的信息写“待确认”。“审核通过”不能改写成“已发布”。 验收按“已完成、待处理、待确认”三部分输出不超过350字。每条附原记录编号。完成后逐项核对涉及的数量和状态并说明缺失信息。图 3任务描述对照示意没有进行两种提示词的效果对比实验。本次输出为什么可以逐条核对本次由 Codex 实际读取上述文件后形成的摘要如下保留了来源编号已完成 • 12份产品资料已归档。[N1] • 已审核5篇稿件其中3篇通过。[N2] • 活动报名表已建立。[N3] • 已检查4张统计表。[N4] 待处理 • 2份资料缺少版本日期待补负责人林同学。[N1] • 2篇稿件退回补充来源负责人陈同学。[N2] • 1处统计口径不一致尚未修正负责人林同学。[N4] 待确认 • 活动上线时间及负责人待确认。[N3] 核对5篇审核稿件3篇通过2篇退回。审核通过未表述为已发布。缺失信息为2份资料的版本日期、活动上线时间及负责人。[N1、N2、N3]复核时应回到原文件检查而不是只看摘要末尾是否写了“已检查”。本次核对了四项数量与原文一致完成状态没有升级N3 的缺失信息仍为待确认原始文件前后的 SHA-256 一致。SHA-256 可以理解为文件的内容指纹用于检查文件是否改变不能证明摘要语义一定正确。[E1]图 4根据本次输出与核验记录绘制合成案例不是 Codex 界面截图。这一次示例说明来源编号和明确的检查条件可以让复核有据可查。它没有测量节省时间、对比其他写法的成功率也不能代表所有周报任务的表现。结果不合适怎样继续改追加要求时指出具体差异比笼统地说“重写得更好”更便于执行。例如“保留当前事实和编号把每条压缩为一句待处理事项后保留负责人没有依据的上线日期继续写待确认。”如果发现数字错误应指出对应记录“N2 是 5 篇不是 6 篇。请回到 N2 核对并检查正文其他位置是否重复了这个错误。”不要仅让它换一种表达因为问题出在事实。对开发者也可以沿用同一框架把“材料”换成相关文件和报错把“验收”换成可以观察的结果或必要测试。这是框架迁移建议本文没有执行代码修改实验。常见问题提示词越长越好吗不必追求长度。把影响结果的信息写全删掉与任务无关的背景。四个要素中已经由当前上下文明确的部分无需反复铺陈。加上“你是专家”就够了吗角色描述可以帮助确定语气但不能代替文件范围、数据口径和验收条件。能让 Codex 自己检查自己吗可以把自查写进任务但关键数量、日期和状态仍应回到来源核对。对本例532 是检查点“通过”是否被写成“发布”是另一个检查点。哪些要求适合以后一直使用例如“保留输入文件、缺失信息写待确认、输出附来源编号”可整理成项目说明。一次性的截止时间或本次选定的文件继续写在当次任务里。依据与复核边界论点编号论点依据与能证明的范围P1任务需要明确目标、材料、边界和完成条件S1、S2官方使用建议不支持“照此写必然正确”P2本例的摘要保留了数量、状态和来源编号E1原材料、实际输出及逐条复核仅限这次合成案例P3本例没有改动原文件E1输出前后文件指纹一致不证明语义无误P4按差异追加要求更便于核对本文方法建议没有给出效率提升或成功率数据官方资料查阅日期2026-10-31。E1 包含《运营周记_合成示例.txt》《本次演示提示词.txt》《本次输出_工作进展摘要.txt》《演示核验.json》。完整文件及对应关系随审核包保留。 
长河君 · 2026/11/2 19:10:51 · 阅读 1.2k Codex 提示词怎么写？办公与运营任务的 4 要素与可复制模板
样稿 V1 · 待审核 · 资料核对2026-10-31一句话答案把“要交付什么、依据什么、有哪些边界、怎样算完成”说清楚再要求 Codex 对照原材料核验。对办公和运营任务而言这比只写“专业一点、详细一点”更容易检查结果是否合用。图 1AI 生成的概念封面不是软件界面。为什么一句“帮我写周报”还不够周报可能给部门负责人看也可能给客户看可能只汇总进度也可能要分析问题。如果任务只写“帮我写一份专业周报”读者、材料范围和完成标准都留空了。最终文笔再顺也不容易判断它是否完成了你的任务。这里所说的“提示词”就是你交给 Codex 的任务说明。OpenAI 的使用建议强调目标、上下文、限制和完成条件提示文档也建议提供与任务有关的材料与预期结果。S1OpenAI《Best practices》S2OpenAI《Prompting》。本文把这些建议转成办公人员容易使用的四个问题。它是任务检查框架不是必须照抄的固定语法也不能保证每次输出都正确。四个要素分别解决什么问题要素需要写清楚的内容运营周报示例目标交付物是什么给谁使用给项目负责人一份工作进展摘要材料读哪个文件采用哪些记录只用指定周记中的 N1—N4限制哪些内容不能擅自改变或补写原件不改缺失日期和负责人写待确认验收怎样检查是否完成按三类输出每条标来源编号复核数量与状态图 2写作框架示意依据 S1、S2 整理。如果任务很小不必每次写四个标题。“只读这份名单列出重复编号和对应记录号先不改原件”已经包含了材料、目标、限制和检查线索。需要做多步工作时再展开说明。一个可以直接照做的周报案例先准备一份文本文件并让 Codex 能够读取它可以在已经打开的项目中使用该文件也可以通过当前入口支持的附件方式提供。若文件尚未被成功读取就先处理访问问题不能假定它已经看过内容。本例使用专为教程编写的合成周记所有人物与事项均为演示用途。材料包含四条记录记录原材料中的关键事实N112 份产品资料已归档其中 2 份缺少版本日期N2审核 5 篇稿件3 篇通过2 篇退回补充来源N3报名表已建立上线时间待确认负责人未填写N4检查 4 张统计表发现 1 处口径不一致尚未修正这些数据只来自本地合成文件不是业务业绩也不是官方产品测试结果。[E1本次合成材料与演示记录2026-10-31。]可以把下面这段任务说明交给 Codex并替换成自己的文件名目标把“运营周记_合成示例.txt”整理成一份给项目负责人的工作进展摘要。 材料只依据该文件的 N1—N4 四条记录。 限制原文件不改动。不要补写材料没有提供的上线日期或负责人未确定的信息写“待确认”。“审核通过”不能改写成“已发布”。 验收按“已完成、待处理、待确认”三部分输出不超过350字。每条附原记录编号。完成后逐项核对涉及的数量和状态并说明缺失信息。图 3任务描述对照示意没有进行两种提示词的效果对比实验。本次输出为什么可以逐条核对本次由 Codex 实际读取上述文件后形成的摘要如下保留了来源编号已完成 • 12份产品资料已归档。[N1] • 已审核5篇稿件其中3篇通过。[N2] • 活动报名表已建立。[N3] • 已检查4张统计表。[N4] 待处理 • 2份资料缺少版本日期待补负责人林同学。[N1] • 2篇稿件退回补充来源负责人陈同学。[N2] • 1处统计口径不一致尚未修正负责人林同学。[N4] 待确认 • 活动上线时间及负责人待确认。[N3] 核对5篇审核稿件3篇通过2篇退回。审核通过未表述为已发布。缺失信息为2份资料的版本日期、活动上线时间及负责人。[N1、N2、N3]复核时应回到原文件检查而不是只看摘要末尾是否写了“已检查”。本次核对了四项数量与原文一致完成状态没有升级N3 的缺失信息仍为待确认原始文件前后的 SHA-256 一致。SHA-256 可以理解为文件的内容指纹用于检查文件是否改变不能证明摘要语义一定正确。[E1]图 4根据本次输出与核验记录绘制合成案例不是 Codex 界面截图。这一次示例说明来源编号和明确的检查条件可以让复核有据可查。它没有测量节省时间、对比其他写法的成功率也不能代表所有周报任务的表现。结果不合适怎样继续改追加要求时指出具体差异比笼统地说“重写得更好”更便于执行。例如“保留当前事实和编号把每条压缩为一句待处理事项后保留负责人没有依据的上线日期继续写待确认。”如果发现数字错误应指出对应记录“N2 是 5 篇不是 6 篇。请回到 N2 核对并检查正文其他位置是否重复了这个错误。”不要仅让它换一种表达因为问题出在事实。对开发者也可以沿用同一框架把“材料”换成相关文件和报错把“验收”换成可以观察的结果或必要测试。这是框架迁移建议本文没有执行代码修改实验。常见问题提示词越长越好吗不必追求长度。把影响结果的信息写全删掉与任务无关的背景。四个要素中已经由当前上下文明确的部分无需反复铺陈。加上“你是专家”就够了吗角色描述可以帮助确定语气但不能代替文件范围、数据口径和验收条件。能让 Codex 自己检查自己吗可以把自查写进任务但关键数量、日期和状态仍应回到来源核对。对本例532 是检查点“通过”是否被写成“发布”是另一个检查点。哪些要求适合以后一直使用例如“保留输入文件、缺失信息写待确认、输出附来源编号”可整理成项目说明。一次性的截止时间或本次选定的文件继续写在当次任务里。依据与复核边界论点编号论点依据与能证明的范围P1任务需要明确目标、材料、边界和完成条件S1、S2官方使用建议不支持“照此写必然正确”P2本例的摘要保留了数量、状态和来源编号E1原材料、实际输出及逐条复核仅限这次合成案例P3本例没有改动原文件E1输出前后文件指纹一致不证明语义无误P4按差异追加要求更便于核对本文方法建议没有给出效率提升或成功率数据官方资料查阅日期2026-10-31。E1 包含《运营周记_合成示例.txt》《本次演示提示词.txt》《本次输出_工作进展摘要.txt》《演示核验.json》。完整文件及对应关系随审核包保留。