请问HN：你们是如何为基于Markdown的AI编码助手构建上下文的？
我最近从在浏览器中使用大型语言模型（LLMs）转向在VS Code中使用本地代理工作流程（Gemini代码助手）。我可以批准或拒绝更改，这很好，但在上下文管理方面遇到了瓶颈。最初，我将整个代码库作为上下文提供给非代理版本的Gemini代码助手，它的表现很好。
我了解到代理模式“更好”，因此为了使代理与我项目的架构保持一致，我手动构建了7个密集的Markdown文件，作为项目的系统指令。我需要Gemini在我们实现功能时更新这些文件。
这些文件包括：gemini.md（指示Gemini读取其他md文件并处理更新）、project_overview.md、architecture.md、features.md、database.md、api.md、security.md。
每个文件的字数在500到1500之间，所以我担心这是否是正确的做法。目前似乎没有关于上下文文件最佳实践的共识。我看到对简约、精简指令和密集、全项目规格的论据都有很强的支持。老实说，LLM的正确使用和提示模式似乎就像看星座运势，每个人都凭直觉判断，而最常被引用的真相来源是确认偏误。
你在工作流程中是如何使用.md上下文文件的？
查看原文
I’ve recently transitioned from using LLMs in-browser to a local agentic workflow in VS Code (Gemini Code Assist). I can approve/disapprove changes which is nice, but I’ve hit a wall regarding context management. Initially, I provided all the whole repo as context to the non-agentic version of Gemini code assist and it performed well.<p>I read the agentic mode is "better" so to keep the agent aligned with my project's architecture, I’ve manually built 7 dense Markdown files that serve as the system instructions for the project. I require Gemini to update these files as we implement features.<p>gemini.md (instructs gemini to read the other md files and handle updating) project_overview.md, architecture.md, features.md, database.md, api.md, security.md<p>Each file is between 500–1,500 words so I’m concerned if f this is the right way to go. There seems to be no consensus on context file best practices. I’m seeing strong arguments for both minimalist, lean instructions and dense, project-wide specs. Honestly, the proper usage/prompting patterns of LLM's seems to be comparable to reading horoscopes, everyone goes by gut-feeling with the most cited source of truth being the confirmation bias.<p>How are you using .md context files in your workflow?