有关完整文档索引，请参阅 llms.txt。此页也提供 Markdown 格式版本。

Tabnine 提示词指南

为代码项目定义提示策略

每个项目都会根据优先事项需要不同的策略。有效的提示始于结构化思维。

在 Tabnine 中，你不仅是在向文本模型发出提示，而是在与一个拥有代码库、打开文件以及自定义命令访问权限的 Agent（智能体）交互。

一个好的提示不仅描述你想要什么，还指导 Agent 如何在你的项目中运行：它能查看什么、应遵循什么规则、以及什么内容应保持原样。

A. 指定关键要素

在设计提示时，请明确以下方面：

任务：你试图达成什么目标？什么是“目标状态”？结果应该是什么？ 示例：“对这个代码应用提取方法重构。”

上下文：你正在处理的源材料是什么，Agent 应该在哪里查找（打开的文件、特定路径、远程仓库）？ 示例：“@related_class”或“参见 utils/helpers.py 中的实现。”

约束：必须遵守哪些边界或条件？ 示例：“保持当前行为。保留函数签名。” 注意：最好避免否定式提示。上述示例的否定版本是“不要改变行为。保留函数签名。”

流程：指令是什么，或者 Agent 应如何一步步接近工作？ 示例：“首先识别重复的逻辑，然后建议可复用的方法。”

验证：哪些信号表明提示成功？ 示例：“重构后的代码应通过所有现有测试。”

格式：输出应该如何结构化？ 示例：“以包含 method_name、start_line 和 new_code 的 JSON 对象形式响应。”

（再）迭代计划：如果第一次输出不完美，下一步是什么？请像指导初级工程师一样对待这一点：告诉 Agent 在应用重大更改之前何时暂停、提问或请求批准。 示例：“生成重构后，询问：‘你想将此应用于其他类吗？’”

请求反馈（可选）： 示例：“如果此方法看起来有缺陷，请解释原因并提出替代方案。”

模板示例

当使用 Tabnine 作为代码库上的 Agent 时，请明确范围权限：

范围：“只修改此文件和 /tests/user/ 中的测试文件。” 权限：“不要创建新服务；只修改现有方法。” 安全检查：“在提出更改之前，总结你当前对行为的理解。”

为什么这有效

提示策略使 LLM 与你的开发思维保持一致。与其盲目尝试寻找正确的措辞，不如为模型定义一条明确的操作路径——从而带来更好、更快且更可预测的完成结果。

最后更新于 5 个月前 这有帮助吗？