- 需求背景 (Is your feature request related to a problem? Please describe.)
目前 LimCode 已经支持了非常棒的上下文变量机制（如静态的 {{$ENVIRONMENT}} 和动态的 {{$WORKSPACE_FILES}}）。但在实际开发中，我们经常需要让 AI 严格遵守当前项目的特定规范（例如：“必须使用 Vue3 Setup 语法”、“UI 组件必须从 @/components 引入”、“禁止使用 any”等）。
如果每次都在对话中强调，不仅繁琐，而且作为动态上下文会破坏大模型（如 Claude 3.5 / GPT-4o）的 Prompt Caching（提示词缓存），导致响应变慢且 API 成本增加。
- 期望的功能 (Describe the solution you’d like)
希望 LimCode 能引入类似 Cursor 的 .cursorrules 或 Claude Cowork 的 CLAUDE.md 机制：
插件在初始化对话时，自动检测当前工作区根目录是否存在 .limcoderules（或 limcode.md）文件。
如果存在，将其内容作为静态变量（例如定义为 {{$PROJECT_RULES}}），直接注入到发送给 AI 的 System Prompt（系统提示词） 中。
3. 为什么建议作为“静态变量”注入？ (Why this approach?)
最高遵循权重：System Prompt 是大模型的“宪法”，放在这里的项目规范能确保 AI 在整个对话周期内严格遵守，不会遗忘。
极致的性能与成本优化：因为项目规范文件通常几天才修改一次，属于静态内容。将其放在 System Prompt 头部，可以完美触发 API 厂商的 Prompt Caching 机制，实现多轮对话的秒级响应，并大幅节省 Token 消耗。
保持历史记录整洁：不需要在每次 User Message 中动态追加，不会污染对话历史。
4. 替代方案 (Describe alternatives you’ve considered)
目前只能通过修改全局的系统提示词来实现，但这会导致切换不同项目时，规则互相冲突（比如 A 项目用 React，B 项目用 Vue），无法做到“项目级 (Project-level)”的隔离。
目前 LimCode 已经支持了非常棒的上下文变量机制（如静态的 {{$ENVIRONMENT}} 和动态的 {{$WORKSPACE_FILES}}）。但在实际开发中，我们经常需要让 AI 严格遵守当前项目的特定规范（例如：“必须使用 Vue3 Setup 语法”、“UI 组件必须从 @/components 引入”、“禁止使用 any”等）。
如果每次都在对话中强调，不仅繁琐，而且作为动态上下文会破坏大模型（如 Claude 3.5 / GPT-4o）的 Prompt Caching（提示词缓存），导致响应变慢且 API 成本增加。
希望 LimCode 能引入类似 Cursor 的 .cursorrules 或 Claude Cowork 的 CLAUDE.md 机制：
插件在初始化对话时，自动检测当前工作区根目录是否存在 .limcoderules（或 limcode.md）文件。
如果存在，将其内容作为静态变量（例如定义为 {{$PROJECT_RULES}}），直接注入到发送给 AI 的 System Prompt（系统提示词） 中。
3. 为什么建议作为“静态变量”注入？ (Why this approach?)
最高遵循权重：System Prompt 是大模型的“宪法”，放在这里的项目规范能确保 AI 在整个对话周期内严格遵守，不会遗忘。
极致的性能与成本优化：因为项目规范文件通常几天才修改一次，属于静态内容。将其放在 System Prompt 头部，可以完美触发 API 厂商的 Prompt Caching 机制，实现多轮对话的秒级响应，并大幅节省 Token 消耗。
保持历史记录整洁：不需要在每次 User Message 中动态追加，不会污染对话历史。
4. 替代方案 (Describe alternatives you’ve considered)
目前只能通过修改全局的系统提示词来实现，但这会导致切换不同项目时，规则互相冲突（比如 A 项目用 React，B 项目用 Vue），无法做到“项目级 (Project-level)”的隔离。