软件工程

“优化一下这个页面”或者“修复登录问题”足以开启讨论，却不足以定义一次可靠的工程交付。Codex 可以主动探索仓库，但它无法从代码中推断产品取舍、风险偏好和真正的验收标准。高质量提示词的作用不是规定每一行实现，而是给代理一个清晰的问题边界，以及证明任务已经完成的方法。 用四个部分定义任务 一个稳定的起点是 Goal、Context、Constraints 和 Done when 四段式结构： Goal 描述要改变的用户行为或系统结果，而不是指定某个函数必须怎样改； Context 指向相关目录、错误信息、复现步骤、设计稿或已有实现； Constraints 固定不能破坏的接口、依赖、安全边界和改动范围； Done when 列出测试、构建、页面行为或性能指标等可验证结果。 例如，要求 Codex 给 Hugo 博客增加文章，可以这样写： Goal: 新增三篇可直接发布的中文文章，并让它们出现在首页和分类页。 Context: 站点配置在 hugo.toml，文章放在 content/posts，public 已被 Git 跟踪。 Constraints: 不要修改 PaperMod 子模块；沿用 TOML Front Matter；保留现有改动。 Done when: hugo --minify 成功，文章页、RSS、标签页和站点地图都包含新 URL。 这份提示没有替 Codex 决定具体模板实现，却明确了探索范围和交付证据。代理仍可以从仓库中发现真实结构，而不是被一份可能过时的文件清单绑住。 复杂任务先规划 当需求涉及多个模块、存在兼容风险，或者验收标准尚不清楚时，先进入规划阶段。支持的 Codex 界面可以使用 /plan；也可以直接要求它先阅读仓库、提出问题并给出实施方案，在确认前不要编辑文件。 规划的核心不是生成一份很长的待办清单，而是消除会改变实现方向的未知项。目录位置、依赖版本和现有测试属于可发现事实，应先从仓库查证；发布策略、兼容范围和产品优先级属于偏好，才需要向人提问。一份可执行计划还应说明数据如何流动、失败时如何表现、哪些接口保持不变，以及每个风险如何验证。 小而明确的改动则不必为了形式强行规划。修正文案、调整单个配置值等任务，在边界和验证都清楚时可以直接执行。判断依据是错误决策的代价，而不是文件数量。 让执行过程保持可审查 开始实现后，可以要求 Codex 遵循一个简单闭环： 读取入口、相邻实现、测试和工作区状态，确认没有覆盖他人改动； 先复现问题或建立基线，再选择最小的行为改动； 按仓库现有模式实现，并补充与风险相称的测试； 运行最小相关检查，再扩大到构建、类型检查或集成测试； 审阅最终差异，报告命令、结果和仍未覆盖的风险。 这里的“最小”不是追求最少行数，而是避免顺手重构无关模块。上下文不足时，代理应该继续查找；只有无法从环境得到、且答案会实质改变方案的问题，才需要暂停询问。 权限同样属于任务设计。Codex 在沙箱内运行本地命令，越过文件或网络边界时会遵循审批策略。不要为了省一次确认就授予整台机器的宽泛权限。更好的做法是保持工作区干净，给出准确命令，并只批准当前任务确实需要的能力。 ...