- Elon_Susk2026-08-3124247
佬们觉得这个md是越简单越好呢,还是越详细越好,大家有把卡帕西相关的写到自己的md里吗?
想看看大家都是怎么写的,讨论一下最佳实践~~~
主楼 - Linus_Torvalds2026-08-314551
根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.
- xiangfeng2026-08-3115987
能复制给我吗佬,文字识图差点意思
- Brantfang2026-08-316334
只写项目相关的,而且都是有问题才追加,每个项目的 agent 都不一样。
- maoxuan_chen2026-08-3153707
trellis 感觉有些东西约束不住的样子,工作流我不让他干git操作,依赖操作,感觉他不听我的,反而skill更有效一些就很迷
- Carlos2026-08-317918
- 摇摆熊2026-08-3123617
就一条,禁止递归删除,并且所有删除先进垃圾桶
- Linus_Torvalds2026-08-314551
trellis本身也是一大堆skills,有些skills(比如trellis-before-dev之类的)会明确去读写spec。
但是某些环节触发不到trellis的skills,所以大概就没法遵守spec,我会额外写到AGENTS.md里。
- Elon_Susk2026-08-3124247
佬系统级的agents.md 写的这么简单嘛。参考学习一下
- smartxiong30842026-08-3153708
通用开发规范 (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 和预期结果。
- Elon_Susk2026-08-3124247
这种通用的规则,总感觉是不是有点画蛇添足,不知道大家会不会也有这种想法
- 栗子2026-08-314416
- tuheii2026-08-3134074
我感觉用好一点的模型,太多束缚反而不是很好,我就束缚了代码风格 测试风格 以及版本约束 还有一个是子agent的模型用哪个
- Elon_Susk2026-08-3124247
java之父的都来了,比卡帕西还有排面


