想看看大家的codex的agent.md

根AGENTS.md简单点就好了吧，模型够聪明了

项目级的可以写多点，目前搭配trellis spec，约束不到的才会写入项目级的AGENTS.md

当然根这个AGENTS.md也没啥用，写不写都一样

# AGENTS.md



## Communication



- Use Simplified Chinese unless requested otherwise.



## Environment



- Use PowerShell 7 on Windows 11 as the default shell.



## Code Style



- Use Simplified Chinese for necessary code comments.

能复制给我吗佬，文字识图差点意思

只写项目相关的，而且都是有问题才追加，每个项目的 agent 都不一样。

trellis 感觉有些东西约束不住的样子，工作流我不让他干git操作，依赖操作，感觉他不听我的，反而skill更有效一些就很迷

项目级基本就是项目指引和常犯的错误指南

全局共享的没啥

就一条，禁止递归删除，并且所有删除先进垃圾桶

trellis本身也是一大堆skills，有些skills（比如trellis-before-dev之类的）会明确去读写spec。

但是某些环节触发不到trellis的skills，所以大概就没法遵守spec，我会额外写到AGENTS.md里。

佬系统级的agents.md 写的这么简单嘛。参考学习一下

通用开发规范 (General Development Guidelines)

• 始终使用中文回复。


• 开发前必须充分理解用户需求，存在疑问或歧义时必须先向用户确认，禁止自行假设或擅自决策。


• 明确需求后，先输出实现方案，包括：
  
  
  
  • 实现思路
  
  
  • 开发步骤
  
  
  • 预计修改/新增的文件
  
  
  • 可能影响的模块
    
    未经用户确认，不得开始编码。
  
  
  
  

代码设计原则 (Code Principles)

• 优先保证代码简洁、清晰、易维护，避免过度设计。


• 遵循简单实用原则，不引入不必要的复杂度。


• 控制圈复杂度：
  
  
  
  • 函数保持小而清晰。
  
  
  • 提高代码复用率。
  
  
  • 避免重复代码。
  
  
  
  


• 注重模块设计，合理使用设计模式，但禁止为了设计模式而设计。


• 数据库表设计时：
  
  
  
  • 不添加外键。
  
  
  • 表结构设计字段需要添加中文注释。
  
  
  • 枚举字段，数据库存数字，再代码中通过枚举做中文映射。
  
  
  • 不主动添加索引。
  
  
  
  

修改代码规范 (Change Guidelines)

• 修改或分析代码前，先完整了解相关代码上下文，不能只看局部代码。


• 修改时遵循最小改动原则：
  
  
  
  • 优先局部修改。
  
  
  • 避免影响无关模块。
  
  
  • 保持现有架构稳定。
  
  
  
  


• 修改完成后：
  
  
  
  • 自查代码质量。
  
  
  • 假设至少 10 个测试 Case。
  
  
  • 给出每个 Case 的输入和预期结果。
  
  
  
  

解释与沟通规范 (Communication Guidelines)

• 解释代码时使用简单易懂的语言，避免堆砌专业术语。


• 解释实现方案时必须说明：
  
  
  
  • 实现原理。
  
  
  • 执行步骤。
  
  
  • 关键设计考虑。
  
  
  
  


• 流程、架构、调用关系等内容优先使用 Mermaid 图辅助说明。


• Mermaid 图必须：
  
  
  
  • 自检语法正确。
  
  
  • 确保可以正常渲染。
  
  
  • 兼容暗黑主题，保证文字和连线清晰可见。
  
  
  
  

Bug 修复流程 (Bug Fix Workflow)

当被要求修复 Bug 时，必须按照以下流程执行：

1. 理解问题 (Understand)

• 阅读 Bug 描述和相关代码。


• 用自己的话复述对问题的理解。


• 明确复现条件和影响范围。

2. 分析原因 (Analyze)

• 至少提出两种可能的根本原因。


• 说明每种原因的验证方式。

3. 制定方案 (Plan)

• 给出验证计划。


• 提供推荐修复方案。


• 说明预计修改文件和影响范围。

4. 请求确认 (Confirm)

• 在修改代码前，必须等待用户确认方案。

5. 执行修复 (Execute)

• 按确认方案实施修改。


• 遵循最小改动原则。

6. 代码审查 (Review)

• 检查修改是否引入新问题。


• 检查兼容性、异常场景和潜在风险。

7. 结果说明 (Explain)

• 说明修改了什么。


• 说明为什么这样修改。


• 给出测试 Case 和预期结果。

这种通用的规则，总感觉是不是有点画蛇添足，不知道大家会不会也有这种想法

感觉现在agent对于工程化的项目都挺支持的，感觉再写这些就有点画蛇添足了，对于已有项目用途可能不是很大，对于新项目能起到约束的效果，不至于让AI幻觉和过度设计。

我感觉用好一点的模型，太多束缚反而不是很好，我就束缚了代码风格 测试风格 以及版本约束 还有一个是子agent的模型用哪个

java之父的都来了，比卡帕西还有排面