在日常使用 CodeBuddy 的过程中，开发者最容易陷入以下几个误区。提前了解并主动规避，能让 AI 辅助真正提效，而非制造额外麻烦。
误区一：看到虚影就按 Tab，不做审查
行内补全虽然方便，但 AI 可能基于不完整上下文生成"看似合理"的代码，例如调用并不存在的内部方法、使用已废弃的 API，或遗漏空值判断。
建议：养成"先读再按"的习惯，特别是涉及权限校验、金额计算、并发逻辑时，务必确认生成的代码符合当前项目实际。
误区二：提示词笼统，期待 AI 读心
输入"优化这段代码"或"这里有问题"却不说明优化目标（性能、可读性还是兼容性），往往得到泛泛而谈的结果。
建议：参照 4.2 节的描述公式，明确输入输出、约束条件和预期效果。例如："将这段同步遍历重构为异步并行处理，要求保留原有错误日志输出格式"。
误区三：忽视上下文引用，默认 AI 知道全貌
直接在对话框问"这个报错怎么解决"却不贴代码，或以为 AI 自动掌握整个项目结构，实际上它默认只看到当前片段。
建议：善用 3.4 节的 @文件、@目录 和 @终端 主动提供上下文；排查报错时，先 @终端 引用输出，再追问原因。
误区四：在对话中泄露敏感信息
将包含数据库密码、API Key、内网地址或用户隐私数据的代码直接粘贴到侧边栏提问。
建议：提问前先做脱敏处理，用 <YOUR_API_KEY> 等占位符替代真实密钥；企业用户应确认管理员是否关闭了代码改进计划上传开关（见 2.3.3）。
误区五：所有任务都调用"深度模型"
无论单行补全还是简单注释生成，都选择最重的模型，导致响应延迟、打断编码流。
建议：回归 2.3.2 的模型选型策略，日常编码和快速补全用极速/均衡模型，仅在复杂架构设计或跨文件重构时切换到深度模型。
误区六：把 AI 当作通用搜索引擎
向它询问"如何学习 Python"或"React 和 Vue 哪个好"这类过于宽泛的问题，得不到比专业文档更有价值的回答。
建议：将提问聚焦在具体代码任务上，例如"用 Python 实现一个支持超时的重试装饰器"，让工具发挥生成与重构优势。
误区七：生成即结束，不跑测试直接提交
AI 生成的单元测试可能覆盖不到边界条件，转换后的代码可能在新语言环境下存在隐式类型问题。
建议：无论生成的是测试用例、重构代码还是语言转换结果，都必须经过本地运行验证，确认通过后再进入代码审查或合并流程。
误区八：一个会话聊到底，上下文混乱
在同一会话中先讨论了 A 项目的接口设计，又插入了 B 项目的 Bug 排查，导致后续补全和回答被无关历史干扰。
建议：切换项目或主题时，及时新建会话；对于需要长期保持上下文的专项重构，可单独固定一个会话跟进。