• Elon_Susk

    佬们觉得这个md是越简单越好呢,还是越详细越好,大家有把卡帕西相关的写到自己的md里吗?

    想看看大家都是怎么写的,讨论一下最佳实践~~~

    主楼
  • Linus_Torvalds

    根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.

    #1
  • xiangfeng

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

    #2
  • Brantfang

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

    #3
  • maoxuan_chen

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

    #4
  • Carlos

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

    全局共享的没啥

    图片

    #5
  • 摇摆熊

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

    #6
  • Linus_Torvalds

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

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

    #7
  • Elon_Susk

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

    #8
  • smartxiong3084

    通用开发规范 (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 和预期结果。

    #9
  • Elon_Susk

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

    #10
  • 栗子

    图片

    图片

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

    #11
  • tuheii

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

    #12
  • Elon_Susk

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

    #13

发表回复

登录后回复