StreamSparkAI

概览/核心摘要 (Executive Summary)

本视频详细介绍了通过“3S原则”——简单 (Simple)、具体 (Specific) 和简短 (Short)——来优化与 GitHub Copilot 交互的提示工程技巧。核心目标是帮助用户更有效地与 AI 协作，以获取最佳代码生成结果。

简单 (Simple)原则强调将复杂问题分解为小而简单的步骤，逐一提示 Copilot 完成。这样做可以显著减少 Copilot 生成大量代码时可能出现的错误和“幻觉”（即 AI 编造的不准确内容），例如引用不存在的文件或未安装的库。通过小步快跑，开发者能更快地检查和验证代码。发言人建议，在提示中直接使用“简单”一词，有助于减少 AI 输出的冗余。同时，确保相关文件在编辑器中打开，为 Copilot 提供上下文至关重要，有时甚至能让 Copilot 主动预测下一步操作。

具体 (Specific)原则指出，当需要 Copilot 提供更复杂或引导性的答案时（例如在不熟悉某项技术如 Swagger 集成时），提示必须足够具体。模糊的提问会导致泛泛的回答。为提升具体性，应主动为 Copilot 提供上下文，例如通过编辑器中打开的文件、选中的代码块，或利用 Copilot 的 workspace 代理（被描述为项目专家）来分析整个项目。发言人还提及了 file、editor、selection 及终端相关的变量，以精确指向信息源。

简短 (Short)原则建议用户在与 Copilot 沟通时，无需遵循完整的人类语言规范。可以省略复杂的语法、完整的句子，甚至不必担心拼写错误，因为 Copilot 能理解直接、简洁的指令，从而更快地获得结果。

视频最后强调，这三个原则应结合使用，通过迭代的方式（如使用内联聊天逐步构建复杂的 CSS 布局）来达成目标，而非试图通过一个冗长的提示一次性解决所有问题。掌握并实践“3S原则”是提升提示工程能力和开发效率的关键。

引言

Speaker 1 开篇点明，无论是称之为“提示工程 (Prompt engineering)”、“提示制作 (prompt crafting)”还是“提示 (prompting)”，其核心在于“如何有效地与 AI（如 GitHub Copilot）协作以获得最佳结果 (how to effectively collaborate with an AI to get the best results, like GitHub Copilot)”。视频旨在介绍一种名为“3S原则”的提示工程方法。

Prompt Engineering 的“3S原则”

“3S原则”指的是：简单 (Simple)、具体 (Specific) 和简短 (Short)。

简单 (Simple)

• 核心观点: “尝试用你的提示解决尽可能简单的问题 (try to solve as simple a problem as possible with your prompts)”。
• 问题阐述:
  • 当用户试图让 Copilot 一次性完成复杂任务（例如，创建一个返回天气数据并使用 Swagger 的 API）时，Copilot 虽然会尝试执行，但由于代码量大，更容易产生错误和所谓的“幻觉 (hallucinations)”——即 Copilot 在不确定答案时编造的内容。
  • 具体表现可能包括：Copilot “使用不存在的文件，我们没有安装的库等等 (uses files that don't exist, libraries that we don't have installed, and on and on)”。
  • 处理这类代码非常棘手，因为开发者会陷入“修复错误，而不是编写代码 (fixing errors, not writing code)”的境地。
• 建议与实践:
  • 将复杂的解决方案分解为多个简单的步骤，并让 Copilot 逐一执行。
  • 这样做的好处是“需要检查准确性的代码更少，你可以更快地前进 (less code that you have to check for accuracy, and you can just move that much faster)”。
  • 示例: 先创建一个简单的服务器，然后再为天气数据添加路由文件。
  • 发言人发现，在提示中直接使用“简单 (simple)”这个词，有助于“减少 AI 的冗余输出，并更频繁地让我得到我所需要的 (cut down on the verbosity from the AI and gets me just what I need more of the time)”。
• 与 Copilot 交互的技巧:
  • 当使用 GitHub Copilot 的代码补全功能（视频中称为“幽灵文本 (ghost text)”）时，务必“将相关文件作为标签页打开 (have related files open as tabs)”。否则，“Copilot 看不到那些文件，可能会给你错误的答案 (Copilot can't see those files and it may give you bad answers)”。
  • 当 Copilot 拥有足够的上下文信息后，它甚至能预测用户的下一步操作，此时“最好的提示是你不需要写的那个提示 (the best prompt is the one that you don't have to write)”。
• 例外情况:
  • 有时确实需要 Copilot 提供更复杂的答案，尤其是在用户“不太确定如何做某事，需要 Copilot 的一些指导 (not 100% sure how to do something and you need some guidance from Copilot)”时。
  • 例如，如果用户完全不知道如何开始集成 Swagger（一种 API 文档工具），就无法提出简单的问题，而需要一个更开放式的提问。

具体 (Specific)

• 核心观点: “你要求得越多，你就需要越具体 (the more you ask for, the more specific you need to be)”。这紧随“简单”原则中提到的例外情况。
• 问题阐述:
  • 如果就如何集成 Swagger 提出一个“开放式问题 (open ended question)”，得到的也会是“开放式的答案 (open ended answer)”。
  • Copilot 甚至可能不知道用户希望使用哪种编程语言。
• Copilot 获取上下文的方式:
  • Copilot 会“尝试智能地为你提取上下文 (tries to intelligently pull in context for you)”。
  • 这通常指“编辑器区域，即你在编辑器中能看到的代码，但并非文件中的所有代码 (the editor area, which is the code you can see in the editor, but not all the code in the file)”。
  • 它也知道“你选择的代码 (the code that you have selected)”，发言人建议养成选择代码的习惯，以便 Copilot 明确知道讨论对象。
• 建议与实践:
  • 为了“减少 Copilot 需要猜测的量 (reduce the amount of guessing that Copilot has to do)”，最佳做法是“提供具体的上下文 (provide the specific context)”。
  • 使用 workspace 代理: 可以“使用 Copilot 中的 workspace 代理让它查看我们的项目，并以此作为答案的基础 (use the workspace agent in Copilot to have it look at our project and use that as the basis for this answer)”。发言人称：“Copilot 中的代理就像特定主题的专家。在这种情况下，workspace 代理是你项目的专家 (Sor agents [原文如此，可能指 So agents 或 Our agents] and Copilot are like experts on certain subjects. In this case, the workspace agent is an expert on your project)”。
  • 指向特定文件: 可以通过“将 Copilot 直接指向文件 (pointing Copilot directly at files)”来增加具体性。例如，使用 file 变量创建一个与数据中 JSON 结构相匹配的接口。
  • 其他上下文变量:
    • editor: 包含编辑器空间中所有可见代码。
    • selection: 包含选中的代码。
    • terminal last command 和 selection: 包含来自终端的信息。
• 强调: “始终使用具体的提示，并始终为 Copilot 提供具体的上下文 (always use specific prompts and always provide specific context to Copilot)”。

简短 (Short)

• 核心观点: 与 Copilot 交流时，无需像与人类对话那样措辞。
• 建议与实践:
  • “你不需要像和人说话那样组织问题 (you don't need to phrase questions as if you were talking to a human)”。
  • “你不需要正确的语法 (You don't need proper grammar)”。
  • “你甚至不需要完整的句子 (You don't even need complete sentences)”。
  • “你不必正确拼写事物 (You don't have to spell things correctly)”。
  • 可以“安全地省略几乎所有这些，并更快地获得相同的答案 (safely emit almost all of that and get the same answer faster)”。
  • 目标是“少打字，因为拼写错误无关紧要 (Type less, because typos don't matter)”。

综合运用“3S原则”

• 观点: 尽管分别介绍了这三个原则，但在实际应用中，它们会“一起使用以获得最佳结果 (use them together to get the best results)”。
• 示例 (创建特定 CSS 布局):
  • 目标: 创建一个包含固定头部、固定底部以及中间内容可滚动的 CSS 布局。
  • 低效方法: 编写一个“相当冗长的提示 (pretty lengthy prompt)”试图一次性完成。发言人认为这“对于开发者生产力来说有点倒退 (a bit of a step backwards for developer productivity)”，因为开发者追求的是快捷操作，而不是“输入你大脑中的所有东西 (type everything that's in your brain)”。
  • 高效方法 (运用3S原则并迭代):
    1. 首先，要求一个“固定的头部 (fixed header)”。
    2. 然后，要求一个“固定的底部 (fixed footer)”。
    3. 接着，要求一个“在两者之间滚动的主体 (body that scrolls in between)”。
    4. 这个过程体现了简单 (Simple)、具体 (Specific) 和简短 (Short)。
    5. 通过“这里的内联聊天 (inline chat here) 来逐步迭代我们想要的答案，而不是试图一次性完成 (iterate our way to the answer that we wanted, instead of trying to do it all in one shot)”。

结论

• 核心总结：“你所要记住的就是三个 S：简单 (Simple)、具体 (Specific) 和简短 (Short)。你就掌握了提示工程的核心原则 (all you have to remember are the three s's simple, specific and short. And you've nailed the core principles of prompt engineering)”。
• 持续学习与实践: “随着你编写更多的提示，你会逐渐弄清楚哪些提示能让你获得最佳结果，并使你最具生产力 (as you write more prompts, you'll just start to figure out what prompts get you the best results and make you the most productive)”。
• 视频最后鼓励观众查看更多关于 GitHub Copilot 的视频，并祝愿大家“智能编码愉快 (happy smart coding)”。