Nest 目录结构优化

问题从哪来

人类习惯按业务模块或历史习惯堆目录，LLM Agent 却要靠 glob、grep 和有限的上下文窗口找文件。目录层级过深、命名不可搜索、动态产物和源码混在一起时，Agent 要么漏文件，要么把 Token 烧在无关路径上；CLAUDE.md 若在一个文件里塞满全仓说明，还会拖垮提示缓存前缀。

Nest 做什么

Nest 专注 LLM 导航拓扑 与 缓存友好的文件放置，在改结构之前会先跑 AUDIT，并遵守几条硬约束：不动既有构建/CI/测试路径（围绕它们重组）；尊重仓库已有约定；变更前后估算上下文成本。

典型工作流包括：

• AUDIT：按 reference/audit-checklist.md 给结构、命名、.claudeignore 等打分，定位导航痛点
• DESIGN：用 reference/layout-patterns.md 等模板设计「逐级可导航」的目录——每一层在不加载子树的情况下也能决策往哪走
• IMPLEMENT / VERIFY：落地命名与分片策略，并复测 Token 与可发现性

核心规则摘要：

• 稳定内容优先：配置、规则、模式类静态文件排在日志、生成物等动态内容之前
• 为 grep 命名：文件名与目录名要能被常见搜索模式命中（细节见 reference/naming-guide.md）
• 单文件 Token 预算：单文件上下文建议不超过约 300 行，过大则通过 @import 分片（密度问题可交给 Hone）
• .claudeignore 是一等公民：与根目录 CLAUDE.md 同级审计，排除构建产物、vendor 与生成代码，避免 Claude Code 在大型仓库里子目录搜索超时

与 Grove、Hone、Sigil 有明确分工：通用结构约定 → Grove；CLAUDE.md 密度与配置校验 → Hone；技能文件落位 → Sigil；应用架构 → Atlas。

适用边界

Nest 解决的是「Agent 怎么在仓库里找东西、怎么让上下文前缀稳定」，不是替代应用分层设计或自动生成业务技能。若你只需通用仓库骨架或纯配置审计，应路由到对应伙伴技能；monorepo 级联可参考 reference/monorepo-topology.md。