企业官网建设流程全解析

摘要

同一个两文件 Python Bug，模糊指令和结构化指令走出了不同的执行路径。本文用一次可复现实测拆解输入、输出、推理和修改范围的差异，并给出一份可直接复制的 Codex 任务模板。实验每组只运行一次，数据不代表固定节省比例。

正文

先给结果

很多人优化 AI Coding Token 的第一步，是把提示词写短。但一次代码任务的消耗还包括项目指令、历史对话、文件内容、终端输出、工具结果、模型回复和失败返工。

我们用同一个 Python Bug 做了单次 A/B：

本次结构化任务的输入少 20.1%，输出少 52.8%，推理输出少 76.2%。更重要的是，它只修改了允许修改的slugify.py；模糊任务还补了测试文件。

这不是“四段式一定节省 20%”的证明。每组只运行了 1 次，缓存输入也不完全相同。它只能说明：在这次小项目里，把范围和验收写清楚后，Codex 的执行路径更集中。

实验环境

• Codex CLI：0.149.0-alpha.4.1
• 登录方式：ChatGPT 订阅
• 模型：gpt-5.6-sol
• 推理强度：low
• 项目：slugify.py与test_slugify.py
• 初始状态：3 项测试中 2 项失败
• 复现命令：

python3-munittest-v

上面的命令在本次自建项目中已实际执行。模型和版本只用于说明实验环境，不构成通用推荐。

A 组为什么多走了一步

A 组指令只有一句：

这个项目有问题，帮我检查并修好。完成后简要说明结果。

Codex 需要先判断项目里有哪些文件、问题如何复现、应该修改实现还是测试。它先查看项目结构和 Git 状态，再读取文件、运行测试，最后还新增了两项边界测试。

补测试本身有质量价值，不能直接称为浪费。但它超出了本次“修复现有失败、保持最小范围”的实验目标，也带来了更多修改和输出。

B 组怎样限定执行路径

B 组使用四个字段：

目标：修复 slugify.py 中导致现有测试失败的缺陷。 上下文：运行 python3 -m unittest -v 可以复现； 相关文件只有 slugify.py 和 test_slugify.py。 约束：只修改 slugify.py，不重构或新增依赖，保持改动最小。 验收：重新运行 python3 -m unittest -v； 最终只需简要报告修改点和测试结果。

它比 A 组提示词长，却减少了模型需要自行确认的问题。B 组直接复现、读取两个指定文件、修改实现并重跑测试，最终 3/3 通过。

七个最实用的优化点

1. 写清实际结果和期望结果，而不只说“有问题”。
2. 已知相关文件时先限定范围，证据不足再扩大。
3. 提供已执行过或可执行的复现命令。
4. 长日志先给关键片段，再按需读取完整文件。
5. 独立目标拆成独立任务，避免旧上下文串线。
6. 简单任务不必默认使用最高推理强度。
7. 最终输出只保留修改、验证和未解决风险。

Codex 当前配置参考提供model_reasoning_effort和model_verbosity。支持档位取决于模型，不能把某个设置写成所有环境都适用。Codex Configuration Reference

长任务怎么处理

仍在同一目标、旧决策依然有效时，可以继续当前任务。目标已经独立、旧日志大量失效时，适合新开任务，并只交接完成状态、关键决策和下一步验收。

上下文压缩适合长任务的里程碑，但它是上下文管理，不会取消已经发生的处理。关键测试结果、风险和下一步目标仍需保留。Codex Prompting Guide

不能为了省 Token 跳过什么

• 复现步骤；
• 修改前后的测试；
• 权限和修改边界；
• 生产或数据迁移风险；
• 没有运行的检查及原因；
• 涉及不可逆操作时的人工确认。

如果省掉一次测试，最后因为回归重新排查，总消耗可能更高。

任务前模板

目标：最终要完成什么？ 现状：实际结果和期望结果是什么？ 复现：运行什么命令？关键错误是什么？ 范围：先读哪些文件？何时可以扩大？ 约束：哪些文件能改？能否新增依赖？ 验收：必须运行哪些测试或构建？ 输出：最终需要哪些结果，是否简要？

下次不要先删提示词里的字。先用这份模板写清目标、范围、复现和验收，再观察 Codex 是否减少了探索、越界修改和返工。