CLAUDE.md 和 AGENTS.md 为了是什么，做规划和限制模型不做什么。

以现在模型的能力 只做简单规范就行了，不用考虑太多，否则是负优化

同求想了解一下，我都是让ai自己总结一下，感觉其实很多东西都不是必要的内容，不知道咋精简一下

我更倾向于混合模式，高耦合低内聚同时多一些代码的硬性要求和踩坑的点

我都是放AI元认知的一些东西,当作内核思想来写

佬，真的“高耦合”、“低内聚”吗？反模式也不失为是一种模式 ^-^ ^-^

如果任务简单就直接写进去，如果项目很大就拆开到 docs 里。我习惯控制 AGENTS.md 在 200 行以内

直接从网上搬了一套现成的，慢慢用慢慢调吧

确实，希望写得万能通用一点，一般就得抽象，上升到“元级”！

什么“默认值工程”、“元认知”、“元思考”、“元管理”

还有希望AI意识到自己在项目中的常驻性和主观能动性，给方案时不要忽略自己的存在，把自己作为初始的内置变量代入进去，给出AI-Native的优化变体方案之类的 ^-^

感觉有些难为它了 ^-^

我来分享下我的经验吧.

首先明确一个概念, AI模型的调用本质上就是,我给输入一段提示词,她给输出一段回答.

而CLAUDE.md和AGENTS.md就是如何给AI输入一段优质的提示词,让她的输出更符合我的心意.

那么问题就来到了"什么是优质的提示词"即: Prompt Engineering?

究其本质,优质的提示词有效的完成了两个任务:

1. 设定目标


2. 提供约束

其中,设定目标包含了:

• 客观可量化的目标达成后的效果


• 现在的状态, 告诉AI, 我现在的项目已经有了些什么

而,提供约束就复杂了, 由此衍生出来,Context Engineering, Specification Engineering, Harness Engineering和最新的Loop Engineering.

这堆Engineering目标就一个: 有效约束LLM的思维边界和行为

所以, 编写AI提示词, 围绕上述结构编写, 基本不会出大问题.

最后, 复杂的提示词本质是为了弥补模型能力的不足,或者模型认知的缺陷. 所以新的强大的模型所需要的提示词是大幅减少的, 比如CC里的提示词随着版本更新,就减少了.

提示词最关键的是: 提示词是生长出来的

当模型遇到边界困难时, 找到限定边界的提示词补上去的. 不要一开始就长篇大论.

而且模型注意力是极度有限的宝贵资源, CLAUDE.md/AGENTS.md文件都最好不要超过300行,甚至极端的理论是不超过60行. 那几乎就是将这文件作为了索引目录. 其它约束和信息分别放置于独立的.md文档中.

以上, 没啥太多主题思想, 结构有点乱, 基本上想到啥写了啥, 最近我自己的经验, 希望对佬友们能起到抛砖引玉的作用.

还是看使用场景来决定吧。谈谈自己的主管感受：

（个人背景：不coding）主要以研究型任务为主，以主CLAUDE.md为例，内容数量从默认到2000多行到目前500行左右。引起这个变化，主要是伴随工具调用量的增加而改变的。

自己的体会是，工具越多，越要形成体系，既能提高精确性，又方便维护和优化。至于原因，我粗浅理解为语言表达天然的歧义和模型记忆机制的约束。

所以，目前我的CLAUDE.md主要是原则条款+router，尔后把具体执行层面的内容分配到相应的skills、rules、mcp、memory中（个性化需求写入项目级的CLAUDE.md中）。为了更好地践行这套理念，也增加了几个hooks来配合。

另外再说说官方推荐的“少于500”行的建议，有一定道理，但需要一整套完成的路由规则来适配，既不能舍本逐末，也不宜贪大求全。

总而言之，如何编写CLAUDE.md，本质上是如何与使用人的风格适配的问题。所以，需要一些时间来实践、沉淀。

祝您在不断的实践当中打磨出适合您的CLAUDE.md。

看项目的大小，如果就是一个很简单的单体项目，如果是纯前端或者是纯后端那种单体，就直接写一个完整的MD文件就行。如果涉及到那种复杂的微服务拆分、分布式架构，前后端都在一个仓库里面的，就可以采用那种路由索引。

对对，还有hook和memory没有提到，实在是一直裸用，懒于研究调试各种玄妙的搭配了！

关于memory机制，我现在是矛盾的：一方面我认为根据仿生学原理，memory机制是必要的；另一方面，CC现在有自动记忆功能，使用下来我感觉它在制造信息茧房，最后又把所有记忆文件删了。 ^-^

我也是很懒，基本上只做了几个和skills来限制，没有系统修改过Claude.md和Agents.md。主要有时候模型也不会遵循指令索性放弃调整