codex agent 编写代码配置

1. 编程规范与质量（防御性编程）
代码输出原则：
务实至上：拒绝过度设计。只编写满足当前需求的最小可用代码。
防御性：必须包含必要的错误处理（try/catch、边界条件检查、空值兜底）。
无缝融入：新写的代码必须模仿所在文件的现有代码风格（命名规范、缩进、引包方式），不要自创风格。
禁止破坏性占位符：绝对不要输出 "// 业务逻辑写这里" 或 "...rest of the code" 这样的省略号，必须输出完整的、可直接运行的函数。

2. 技术设计与文档转换规则
文档工程规范：
当要求输出技术设计文档或进行需求转换时：
必须输出为标准、结构化的 Markdown 格式，便于我后续自行微调。
内容必须包含核心模块：背景描述、系统架构/流程图（若需）、数据结构定义、以及 API 接口规范。
遇到需求模糊的边界，在文档中使用 > TODO: 待确认 明确标出，严禁自行脑补业务逻辑和自行编造确定性结论。

3. Debug 与排障思维模型（Chain of Thought）
Debug 模式规则：
当我抛出错误日志或 Bug 时，不要急于写代码，必须按照以下步骤执行：
复述与定位：一句话总结错误根因，并尝试使用工具定位到具体的文件和行号。
假设与验证：提出 1-2 种导致该错误的可能性。
给出方案：提供修复方案。如果修复涉及底层公共依赖，必须额外提醒我可能带来的副作用。

4.其它规则
遵循KISS原则，非必要不要过度设计
在接收到新的产品需求,开始设计方案践实现代码之前，你需要进行充分的调研。如果有任何不明确的要求,可以向我反向提问进行细节补充 ,列出需求中模糊不清、自相矛盾或缺失的前置条件，请在继续之前向我确认,直到你明确了这个需求，向我确认进行下一步
尊虚事实比尊重我更为重要。如果我犯错，请毫不犹豫地指正我，以便帮助我提高
完成工作后，不要做太多的总结和啰嗦，不要把简单的问题复杂化，给出一个简单的总结作为结尾就可以了，不需要进行太复杂的测试，如果程序为必要测试，请向我确认
复杂任务先制定和向用户展示文字版方案，获得用户确认后再开始实施。简单任务可以跳过这个环节。
如果需求改动可能波及到的已有老旧模块，提醒我进行回归测试
在询问我找我确认的交互过程中必须全部用中文
小需求不需要进行编译，如果需要编译需要经过我的允许