当开发工作从单个函数扩展到整个代码库时，人工逐文件翻阅的成本会急剧上升。CodeBuddy 的项目级能力让你能在对话中直接引用目录甚至全库上下文，一次性完成结构梳理、批量改造与问题排查，避免在几十个文件之间来回切换。
3.5.1 项目结构快速梳理
接手陌生项目或久未维护的存量代码时，最耗时的是理清模块边界与调用关系。
- 操作方式：在侧边栏对话中绑定项目根目录（例如输入
@src或@项目根目录），然后直接提问："请梳理当前项目的主要模块划分及核心入口文件" 或 "数据层、业务层、控制层分别是如何组织的？" - 输出内容：CodeBuddy 会基于文件树和关键代码（如
package.json、go.mod、pom.xml等）给出项目架构的文字描述，指出核心配置文件、公共工具库、路由定义位置等关键节点。 - 实用技巧：若项目庞大，可先聚焦单个子目录（如
@server/api）进行微观梳理，再逐步拼接整体认知。也可直接问 "找出所有与支付相关的文件"，快速定位业务模块。
3.5.2 跨文件批量代码修改
需求变更或技术升级往往涉及多个文件的联动调整，例如统一替换废弃 API、批量补充错误处理、或调整接口参数。
- 操作方式：在对话中描述改造需求，并引用需要改动的目录（如
@src/services）。例如："将src/services目录下所有文件中对oldRequest的调用替换为newHttpClient，并保持错误处理逻辑一致。" - 执行流程：CodeBuddy 会分析目录内相关文件，生成批量修改方案或逐文件的 diff 预览。你可以审查每一处的变动，选择全部应用或仅采纳部分文件。
- 风险控制：建议在执行前确保当前代码已提交 Git。若修改涉及面较广，先在子目录小范围验证，确认风格与逻辑无误后，再推广到全库。
3.5.3 全库代码问题统一排查
在代码审查或技术债治理阶段，需要对全库进行模式化扫描，人工检查容易遗漏。
- 操作方式：使用
@目录绑定较大范围（如项目根目录），发起排查指令。例如："扫描全库是否存在硬编码的密钥或密码"、"找出所有 try-catch 为空捕获的异常处理"、"检查有哪些地方使用了已标记废弃的 API"。 - 结果呈现：工具会列出问题所在的文件路径、行号、风险等级及修复建议。对于重复代码块、过长函数等代码异味，也能给出识别结果。
- 注意事项：
- 大型项目上下文可能超出模型处理长度，建议按业务模块（如
@module-a、@module-b）分批次排查。 - AI 扫描结果可能存在误报（如把示例数据当作硬编码密钥）或漏报，结果应作为人工审查的优先线索，而非最终质检报告。
衔接提示：项目级操作高度依赖第 3.4 节介绍的智能上下文引用（
@文件、@目录）。在发起批量修改或全库排查前，准确引用目标范围是获得高质量结果的前提。