先看验证结果

演示项目的原实现只会替换半角空格，混合空白用例的实际输出是 codex\tfirst---task，而期望结果是 codex-first-task。

$ python3 -m unittest -v
test_collapses_mixed_whitespace ... FAIL
AssertionError: 'codex\tfirst---task' != 'codex-first-task'
FAILED (failures=1)
Exit status: 1

工作区中的最小修改只有一行：

-    return title.strip().lower().replace(" ", "-")
+    return "-".join(title.lower().split())

修复后重新运行同一条测试命令，1 个测试通过；git diff --check 无输出，两条命令的退出状态都是 0。

这些结果来自已保存的脱敏日志。取证开始时，修复已存在于未提交工作区；修复前代码来自 Git HEAD。因此，这里证明的是修复前后的可验证差异，不声称该修复是本次新写入的。

为什么一句“帮我修一下”不稳

它没有说明复现命令、期望输出、可改范围和完成标准。Codex 可能能自己查找，但“能查找”不等于用户已经授权它增加依赖、改测试、提交或发布。

OpenAI 官方 Prompting 文档建议，重要任务可按需提供 Goal、Context、Output 和 Boundaries；官方 Bug 示例还包含复现、约束和修复后验证。官方文档

本文把这些信息整理为中文四段式。这是写作方法，不是 OpenAI 官方命名的强制标准。

四段分别写什么

1. 背景与现状

写文件、现象、复现方式、实际输出和期望输出。尽量提供事实，不把自己的原因猜测写成确定结论。

2. 目标与交付物

描述完成后的状态，并说明要代码、文档、分析还是验证报告。

3. 约束与边界

写明可改文件、依赖要求、兼容性要求，以及是否允许提交、推送、发布和其他外部操作。

4. 验收与汇报

给出真正能运行的测试、构建或检查，并要求汇报命令、结果和未验证风险。

可直接执行的任务

背景与现状：
- 请先阅读 slugify.py 和 test_slugify.py，并说明对失败原因的理解。
- 在项目根目录运行 python3 -m unittest -v。
- 当前 test_collapses_mixed_whitespace 失败，期望结果是 codex-first-task。

目标与交付物：
- 修复 slugify_title，把连续空格、制表符等空白统一转换为一个连字符。
- 交付最小代码修改和验证结果。

约束与边界：
- 只修改解决问题所必需的文件。
- 不删除或放宽测试，不引入第三方依赖。
- 不执行提交、推送、发布或其他不可逆操作。

验收与汇报：
- 重新运行 python3 -m unittest -v。
- 运行 git diff --check。
- 汇报修改、命令结果、未运行检查和不确定性。

边界：通过一个测试不等于全面验证

当前只有一个回归用例。它证明连续空格和制表符能被折叠，但没有单独验证换行符、非 ASCII 空白和空字符串。如要扩大结论，需先新增并运行对应测试。

沙箱与审批也不等于任务边界。官方文档将前者定义为技术边界，后者定义为跨越边界时的许可机制。沙箱 审批与安全

总结

写 Codex 任务时，不必追求篇幅，先检查四件事：现状是否能复现，结果是否明确，修改是否有边界，完成是否有证据。

如果你还没有看过这个失败测试的完整实操过程，可以先读上一篇：《Codex 第一次实操：从一个失败测试开始修 Bug》。

复制上面的四段式，用它重写你当前的一个真实任务。