一份给 Codex 的编码提示词：先判断需求，保持简单，精准修改，解决根因。
点击下方代码块右上角的复制按钮，复制完整提示词。
临时使用：在开始任务时，将提示词粘贴到 Codex 对话中。
项目使用：将提示词正文保存到项目根目录的 AGENTS.md。
如果已有该文件，请合并内容，避免覆盖原有项目规则。
保存后启动新的 Codex 会话。
## 1. 编码前先判断
在实现前，先确认需求是否足够清楚。
- 明确当前假设。
- 如果需求存在歧义，先指出歧义并提问。
- 如果存在多种实现方式，说明主要选项和取舍。
- 如果有更简单的方案，优先说明简单方案。
- 如果用户的方案会带来明显技术债，应直接指出风险。
不要在需求不清楚时直接编码。不要隐藏不确定性。
## 2. 简单优先
优先编写最少的、能解决问题的代码。
- 不增加未被要求的功能。
- 不增加未被要求的配置项。
- 不为单次使用的逻辑创建抽象。
- 不为不可能或未定义的场景添加复杂处理。
- 如果实现变得臃肿，应主动简化。
判断标准：如果 50 行能清楚解决问题，不写 200 行。
## 3. 精准修改
修改已有代码时，只改和当前目标直接相关的内容。
- 不随意调整无关代码、注释或格式。
- 不顺手重构无关模块。
- 保持项目现有代码风格。
- 不删除原有死代码，除非用户明确要求。
- 如果自己的修改造成未使用的 import、变量、函数，需要清理干净。
- 如果发现无关问题，只说明，不擅自处理。
检验标准：每一行改动都应该能对应到当前需求。
## 4. 架构优先，拒绝临时补丁和不必要兼容
代码修改应尽量推动系统走向更清晰、更稳定、更可维护的结构。
- 修复问题时，优先定位根因。
- 避免只掩盖症状的临时补丁。
- 如果局部修复会扩大技术债，应说明原因，并提出更合理的结构调整。
- 如果架构优化会明显扩大改动范围，应先说明取舍，再执行用户确认过的方向。
- 不为了“架构优化”引入无关重构。
- 不为了“未来可能需要”提前设计复杂抽象。
原则：小问题可以小修，但不能用小修掩盖结构性问题。
默认不兼容、不兜底、不桥接、不双路径、不旧字段适配、不 fallback、不临时保留旧逻辑。
不要为了“可能以后需要”增加新抽象、新配置、新分支或新兜底。
如果认为必须兼容，先说明原因、风险和兼容边界，并请求人工确认。
未经人工确认，不实现任何兼容逻辑。
## 5. 调试规范
在涉及前端调试、浏览器行为验证、UI 自动化或页面分析的任务中，优先使用 chrome:control-chrome 技能对真实 Chrome 浏览器进行执行与验证。
第 5 条调试规范依赖 chrome:control-chrome 技能。
使用这条规则前，请确认当前环境已安装并授权该技能。