让 AI 生成代码并不等于任务已经完成。开发者还需要确认它改了哪些文件、命令是否执行成功，以及网页实际运行起来是否符合预期。GitHub Copilot app 面向的正是这类检查流程：它将代码差异（diff）、终端和浏览器预览放在同一工作环境中，减少开发者在多个窗口之间来回切换。

本文适合第一次接触 GitHub Copilot app、但已经有基本项目开发经验的读者。你将看到一条完整路径：先让 Copilot 处理一个范围明确的任务，再审查代码改动，随后运行项目并通过浏览器检查结果。

GitHub Copilot app 是什么

GitHub Copilot app 是用于与 GitHub Copilot 协作完成编码任务的应用界面。这里的 Copilot agent，可以理解为能够围绕一个开发目标执行多步操作的 AI 工作流：它可能生成或修改项目文件，并返回相应的代码结果。

与只在代码编辑器中查看补全内容不同，GitHub Copilot app 关注的是“改动—运行—验证”这一整段过程：

• diff：对比修改前后的文件内容，确认 AI 到底改了什么。
• 终端：安装依赖、启动开发服务器、运行测试或执行其他项目命令。
• 浏览器预览：打开正在运行的网页应用，检查页面和主要交互是否正常。

这三部分并不是彼此独立的功能。diff 用来审查改动，终端负责让项目运行起来，浏览器则帮助验证改动产生的实际效果。

开始前的准备

首先需要一个具备相应 GitHub Copilot 使用权限的 GitHub 账号，并按照官方说明安装当前可用的 Copilot app。应用支持的平台、账号要求、订阅层级和地区可用性可能随产品阶段变化；如果找不到某个入口，应先核对官方文档和账号状态。

还应准备一个可以运行的项目目录，并最好在开始前通过 Git 等版本控制工具保存基线。这样做的目的，是在审查 diff 时更容易判断哪些变化来自本次任务，也方便在结果不符合预期时恢复。

同时，先确认项目使用的语言、框架和包管理工具。不同项目的安装、启动和测试命令并不相同，不能把某个项目的命令直接套用到另一个项目上。涉及数据库、认证、支付或用户数据时，建议使用专门的测试环境，不要让 AI 生成或执行的命令接触生产凭据。

第一步：提交范围明确的编码任务

在 Copilot app 中打开项目后，先提出一个边界清晰的任务。例如，说明要修改哪个页面、增加什么行为，以及不应影响哪些部分。任务越明确，后续 diff 越容易审查；“重构整个项目”这类范围过大的要求，则会增加判断改动是否合理的难度。

提交任务后，不要只根据 Copilot 的文字说明判断结果。应把它当作一次待审查的代码变更，先检查文件和内容，再决定是否继续运行。

第二步：查看 diff，确认 AI 修改了什么

diff 是修改前后文件的对比视图。新增内容、删除内容和被修改的行会以不同方式标识，因此你可以从结果倒推 Copilot 实际执行了哪些变化。

1. 打开应用提供的变更或 diff 视图。
2. 先浏览变更文件列表，确认修改是否集中在任务相关的目录和文件中。
3. 逐个查看关键代码，重点关注配置文件、依赖声明、数据处理、权限逻辑以及删除操作。
4. 根据审查结果保留、调整或撤销不符合预期的改动。

审查 diff 的目的不是逐字符寻找错误，而是回答几个基本问题：改动是否覆盖了任务目标？有没有修改无关文件？是否新增了不必要的依赖？有没有把敏感信息写入代码或配置？

即使 diff 看起来合理，也不能说明代码一定正确。它只展示了文件层面的变化，无法替代运行测试和实际打开页面。因此，确认改动范围后，再进入终端步骤。

第三步：在终端中运行项目

终端是通过文本命令操作项目的界面。此处的任务是把代码从“文件中的改动”变成“可以运行和验证的程序”：通常包括安装依赖、启动开发服务器，以及根据项目情况运行测试。

具体命令应以项目的说明文件和已有脚本为准。以常见的 Node.js 项目为例，可能会看到以下命令：

npm install
npm run dev
npm test

npm install 通常用于安装项目依赖，npm run dev 可能用于启动开发服务器，npm test 则可能运行测试。但这些命令是否存在、具体做什么，取决于项目的配置；执行前应先查看项目文档或脚本定义，不要在不了解作用时直接运行 Copilot 建议的命令。

启动成功后，终端通常会显示本地访问地址和端口。保留终端输出，因为后续浏览器无法打开、页面加载失败或接口报错时，终端日志往往是判断原因的重要线索。

第四步：打开浏览器预览，检查实际结果

当开发服务器已经运行起来后，可以使用 Copilot app 提供的浏览器预览入口打开本地网页。预览的价值在于验证最终用户看到的结果，而不仅是检查代码是否写入文件。

建议依次检查：

• 页面能否加载，是否出现空白页或明显报错；
• 本次任务涉及的按钮、表单、导航和主要交互是否能够工作；
• 页面显示的数据是否符合预期；
• 终端中是否出现异常信息，浏览器端是否报告脚本或网络错误。

如果应用支持将 diff、终端和浏览器并排显示，就可以一边查看代码改动和命令输出，一边观察页面变化。这种布局的重点不是同时打开更多面板，而是缩短“发现问题—定位改动—再次验证”的路径。

浏览器预览无法打开时，先确认开发服务器仍在运行，并检查终端显示的地址和端口是否正确。如果页面显示旧内容，可以尝试重新加载预览，确认热更新是否生效，必要时停止服务器后重新启动。

发现问题后，回到 diff 重新检查

如果页面表现不符合预期，不要只在浏览器中反复刷新。应按照下面的顺序排查：

1. 先查看终端和浏览器错误信息，判断问题发生在启动、构建、接口还是页面交互环节。
2. 回到 diff，定位与该问题相关的文件和代码。
3. 确认依赖、环境变量和本地服务是否已正确准备。
4. 修正代码后，再次查看新的 diff，并重新运行项目和浏览器预览。

每轮修正都重新审查 diff，可以避免为了修复一个页面问题而引入无关改动。对涉及数据写入、权限或外部服务的功能，还应在测试环境中进行更有针对性的验证，不能仅凭页面能够打开就判断功能安全可靠。

常见问题

• 命令执行失败：阅读完整错误信息，确认运行时、依赖、环境变量和当前目录是否正确，不要为了绕过错误而盲目修改配置。
• 预览打不开：检查开发服务器是否仍在运行、端口是否被占用，以及应用绑定的地址是否允许预览环境访问。
• 页面只有部分功能异常：结合浏览器错误和终端日志，重点检查本次 diff 涉及的接口、事件处理和数据格式。
• 改动范围过大：按文件回看 diff，撤销与任务无关的变化，并利用版本控制中保存的基线恢复项目。
• 找不到终端或浏览器面板：相关入口可能受应用版本、操作系统或功能开放状态影响。此时也可以使用系统终端、编辑器和普通浏览器完成同样的流程，只是需要手动切换窗口。

不要把预览当成完整测试

浏览器预览只能发现一部分界面和交互问题，不能替代代码审查、自动化测试、安全检查或正式环境验证。尤其是认证、支付、数据库写入和用户数据处理等场景，即使页面表现正常，也仍需要针对权限、异常输入和数据边界进行测试。

GitHub Copilot app 的实际入口、支持平台以及 diff、终端和浏览器面板的组合方式，可能随产品版本和可用范围变化。使用前应核对官方文档；发布教程时，也应确认文中的界面名称、命令和预览流程与目标版本一致。

对于初次使用者，最重要的不是让 Copilot 一次生成大量代码，而是形成可重复的检查闭环：明确任务 → 查看 diff → 运行项目 → 浏览器验证 → 根据错误继续修正。这样才能把 AI 生成的代码纳入正常的开发流程，而不是把它当作无需审查的最终答案。

原始来源： https://github.blog/ai-and-ml/github-copilot/github-copilot-app-for-beginners-using-the-diff-terminal-and-browser/