行内建议与 PR 文本补全
区分建议、接受和验证，理解预测编辑与上下文不足的影响。
行内建议可能补全当前行、生成新代码，也可能预测其他位置的修改，包括插入、替换和删除。建议只在用户明确接受后应用，可以全部接受、部分接受、拒绝或继续输入忽略。
生成依据
IDE 会利用光标周围代码及打开文件等上下文，形成模型输入，再把预测的改动显示在编辑器中。注释中描述算法或设计要求，可以影响生成方向，但不能保证实现正确。
不同语言的效果取决于训练数据的数量和多样性；熟悉常见语言不代表同样理解较少见语言、特殊框架或项目整体架构。
接受前后分别检查
接受前确认改动位置与范围，尤其是预测到其他位置的删除和替换。接受后检查编译、测试、接口约束和项目风格；建议看似合理时，也可能不符合调用方假设。
自动生成的测试可能没有覆盖全部情形，建议还可能包含安全问题或延续训练数据中的偏差。整体设计是否合适，需要结合项目约束评审，不能只看局部补全结果。
PR 文本补全的区别
GitHub.com 的 PR 描述补全在暂停输入时预测后续文字，可按 Tab 接受或继续输入忽略。依据包含 PR 标题、已有描述、commit 标题、部分 diff，以及最近查看的 PR / issue 标题。
它使用通用模型的提示流程；IDE 代码建议使用针对该任务调整的模型。PR 文本补全主要支持英语，大 PR 的部分内容可能无法放入请求，造成遗漏或上下文不准。生成的文字还可能复述 PR 中的不当内容。
发布前把补全文字与实际变更核对，不把“生成了一段解释”当作“已审查全部 diff”。
过滤与评测
内容和代码过滤用于减少不当或不安全输出；公共代码匹配可以依设置阻止匹配或附上仓库和许可证信息，见公共代码引用。这些检查不代替安全测试与来源核对。
官方通过离线测试和在线受控评估观察正确性、上下文相关性、接受率、展示率、编辑质量、延迟与资源使用。接受率反映用户行为，不单独证明生成代码正确或适用于你的项目。