今天给大家分享一个我在 codex 中常用的一个 agents.md 文件，这是日积月累进行精简出来的，非常适合在vibe coding。内容如下：
# Bugfix & Development Rules (必须遵守) 开始任何开发或修复前，先用一句话确认将严格按本文件执行。 ## A) 通用开发规则 ## A0) 需求对齐 - 开始编码前，先给出：目标、范围、不做什么（Out of Scope）。 - 若需求不清晰，先列出假设；高风险假设需先确认再实现。 ## A1) 方案先行 - 先给最小可行方案（MVP），再实现；避免未经说明的“大改架构”。 - 涉及多种实现路径时，先说明取舍与影响。 ## A2) 改动约束 - 单次任务只解决一个主要问题，避免功能、重构、修复混在一起。 - 默认最小改动；非必要不新增抽象层。 - 禁止顺手修改无关代码（命名、格式、目录整理等）。 ## A3) 文件规模控制 - 单次开发默认不超过 5 个文件；超出需先说明必要性并征得确认。 - 单次 bugfix 默认不超过 3 个文件；超出需先说明必要性并征得确认。 ## A4) 兼容性与迁移 - 涉及 API/数据结构/配置项变更时，必须说明兼容性影响。 - 若存在破坏性变更，必须提供迁移或回滚方案。 ## A5) 测试与验证 - 新功能或行为变更必须补充对应测试（单测/集成测试至少其一）。 - 修复 bug 优先先写失败用例，再修复并验证通过。 - 无法运行测试时，必须说明原因、风险和替代验证方式。 ## A6) 性能与安全底线 - 涉及数据库、循环、并发、I/O 的改动，需简要说明性能影响。 - 所有外部输入必须做校验；涉及权限的改动必须说明鉴权逻辑。 - 禁止在代码中写入明文密钥、令牌或敏感信息。 ## A7) 文档同步 - 变更影响使用方式时，必须同步更新 README/API 文档/注释。 - 新增配置项时，写明默认值、作用和示例。 ## A8) 输出格式（开发任务） 每次开发任务必须按以下结构回复： 1. 需求理解（含范围/不做什么） 2. 实现方案（含取舍） 3. 修改点（文件列表） 4. 测试与验证结果 5. 风险、影响面与回滚方案 ## A9) 禁止静默跳步 - 任一步无法完成（如需求不清、测试不可用、环境缺失）时，必须停止并说明阻塞。 - 未说明阻塞前，不得跳过关键步骤直接提交“看起来可用”的改动。 ## A10) 临时测试清理规则 - AI 为定位/验证问题临时创建的测试文件（如 `tmp_*`、`debug_*`、`repro_*`）在任务结束前必须删除。 - 仅保留“长期回归价值”的正式测试；无回归价值的临时测试禁止提交到仓库。 - 提交前必须在回复中明确：新增了哪些测试、删除了哪些临时测试、最终保留哪些测试及理由。 - 若无法删除临时测试（例如仍用于稳定复现），必须说明原因并征得确认后再保留。 ## B) Bugfix 规则 ## B0) 禁止拍脑袋 - 不允许在未复现问题前直接改代码。 - 不允许一次性大改；优先最小可行修复。 ## B1) 先复现 - 先给出复现步骤、输入、期望结果、实际结果。 - 若无法复现，明确说明“未复现”，并先补日志/测试，不直接猜改。 ## B2) 证据驱动定位 - 必须给出根因证据（日志、调用链、断言、测试失败点）。 - 至少给出 1 个“为什么是这里”的依据。 ## B3) 改动约束 - 只改和根因直接相关的文件。 - 不做顺手重构，不改无关代码风格。 - 变更保持最小化、可回滚。 ## B4) 测试优先 - 先新增/更新一个会失败的测试来锁定问题（能做就做）。 - 修复后必须跑相关测试并汇报结果。 - 无法运行测试时，明确说明原因与替代验证方式。 ## B5) 输出格式（Bugfix） 每次修 bug 必须按以下结构回复： 1. 复现情况 2. 根因与证据 3. 修改点（文件列表） 4. 验证结果 5. 风险与后续建议 ## B6) Bugfix 后测试资产收口 - 修复完成并验证通过后，必须清理本次排障产生的临时测试与脚本。 - 输出中必须包含“测试清理结果”：已删除文件列表 / 保留文件列表。
还没有评论，来说两句吧...