CodeBuddy 面对大型项目的 AI 问答能力，建立在它能理解整个代码仓库的结构与文件关系之上，这与单文件对话有本质差别：它回答「支付模块在哪里校验签名」这类问题时，会跨目录检索代码再给出位置与逻辑。用好它的关键，是把提问粒度、上下文范围和确认方式建立在一套适合仓库级操作的节奏上，下面按接入顺序展开。
仓库级问答与普通对话的差别
普通对话只能看到你贴进去的代码片段，仓库级问答能检索整个项目的文件、引用关系与命名约定。差别体现在三类问题上：定位类，「某个功能在哪实现」它能给出文件路径与函数名；关系类，「这个接口改了会影响哪些调用方」它能顺着引用链梳理；规范类，「项目里错误处理统一用哪种写法」它能基于现有代码归纳。动手前先问它项目里有没有类似功能的现成实现，能复用就不新写，这是仓库级问答最实用的用法之一。但它的检索不是全知的，超大规模仓库里的边缘文件、动态生成的代码，仍可能覆盖不到，重要结论要回到文件原文核对。
首次接入的索引与配置准备
大项目接入先做两件准备：确认索引范围，把构建产物、依赖目录、生成代码排除在索引外，减少噪音；补齐项目说明，README 与模块说明文档写得越清楚，问答质量越高。索引完成后先做几个校准提问：问一个你非常熟悉的模块，看它的定位与描述是否准确，这决定了你对它后续回答的信任基线，校准答案与预期不符时，先怀疑索引范围，再怀疑能力。仓库更新频繁的团队，留意索引的刷新机制，以官方文档说明为准，陈旧索引会给出过时的位置信息，误导比不答更糟。
提问粒度从模块到函数的收放
粒度决定回答质量。问题太大——「这个项目是做什么的」——答案空泛；太细——直接问某个循环为什么这么写——又缺上下文。合适的做法是分层收放：先问模块层面的结构与职责，再指定文件问关键逻辑，最后下钻到函数问实现细节。每一层都让它在回答里附上涉及的文件路径，方便你跳转核对，这个要求写进常用提问模板里，每次都带上。跨模块的问题点明两端：「从 A 模块的入口到 B 服务的数据流」，比「讲讲数据流」得到的答案精准得多，范围约束本身就是提示词。
跨文件改动的确认方式
大项目里最危险的是改动牵一发动全身。让 CodeBuddy 评估改动前，先问影响面：「修改这个函数签名，仓库里有哪些调用点需要同步调整」，让它列出清单；再让它生成改动方案时保持最小变更原则，明确要求不动无关文件。它产出的跨文件修改要逐文件核对差异，重点看引用是否遗漏、类型是否兼容。多人协作的项目，改完跑一遍仓库自带的测试再提评审，AI 问答加速的是理解，改动正确性仍靠测试与评审兜底。
CodeBuddy 能读懂整个仓库吗？
- 仓库太大，索引会不会很慢或漏文件？：大仓库首轮索引需要时间，通过配置排除无关目录可以明显提速，覆盖范围以官方说明与实际校准提问的结果为准。
- 它能记住整个会话里问过的所有文件吗？：会话内已涉及的文件会保留在上下文，但长会话仍可能淡化，重要结论让它当场复述确认。
- 私有仓库的代码安全怎么考虑？：代码处理与存储方式以官方隐私说明为准，团队接入前先确认合规要求，敏感仓库按组织的安全规定执行。
