给 AI 的文档入口
先给模型一个合适的入口，再决定是否继续补充全量文本或单组件 Markdown。这样更省上下文，也更容易得到稳定回答。
/llms/llms.txt
轻量索引，适合让模型快速理解文档结构并决定下一步阅读路径。
/llms/llms-full.txt
完整聚合文本，适合整站总结、RAG 预处理或一次性建立全局上下文。
组件 .md 入口
针对单个组件提问时，优先给对应 Markdown 页面，减少模型读取无关内容。
1. 先给索引，不要一开始就塞完整文档。大多数问题只需要 llms.txt 加 1 到 2 个组件页。
2. 问题越具体，给的文档越应该窄。例如只问 Select 的远程搜索行为，就只补充对应组件 Markdown。
3. 做迁移、对比、全局总结时，再给 llms-full.txt，避免模型在小问题上消耗过多上下文。
4. 在提示词里明确约束回答来源，例如“仅根据提供的 SD Design Vue 文档链接回答”。
5. 如果你在做 RAG，优先把 llms-full.txt 用作基础切片，再用组件级 Markdown 做高精度补充召回。
### 推荐投喂顺序
1. 先提供 [/llms/llms.txt](/llms/llms.txt)，让模型知道站内结构。
2. 如果问题落到具体组件，再补充对应的 [/llms/components/button.md](/llms/components/button.md) 这类组件页。
3. 只有在需要全站理解时，才追加 [/llms/llms-full.txt](/llms/llms-full.txt)。
### RAG 与知识库建议
- 检索入口页时，把 llms.txt 当成目录索引，而不是最终答案正文。
- 建立组件知识切片时，优先按 components/[slug].md 维度存储，便于精准召回。
- 做高层综述、培训材料或新手引导时，再把 llms-full.txt 作为补充语料。
- 如果回答需要可追溯性，保留返回内容对应的原始文档 URL。
## 适合接入的场景
- IDE 内的 AI 编码助手
- 文档站内嵌聊天助手
- 企业内部组件库知识库
- RAG、搜索增强问答、自动代码生成辅助流程
---
## 固钉 Affix
Source: https://sd-design.js.org/components/affix/
LLM Markdown: https://sd-design.js.org/llms/components/affix.md
将页面元素钉在可视范围。当内容区域比较长，需要滚动页面时，固钉可以将内容固定在屏幕上。常用于侧边菜单和按钮组合。
### 基本用法
基本用法，不设置固定位置时，当页面滚动元素不可见时，元素固定在页面最顶部。
示例代码
文件: src/affix-basic.vue
```vue
preHash: `string` | | change | 链接发生改变时触发 | hash: `string` | ### `
{{ helperText }}
- This is the content
- This is the content
routes: `BreadcrumbRoute[]`
paths: `string[]` | 2.36.0 | | separator | 自定义分隔符 | - | | ### `