第7章 用GitHub Copilot实现前后端分离的Web应用

第7章

用GitHub Copilot实现前后端分离的Web应用

无论是经验丰富的IT从业者，还是新入行的IT人员，都会遇到通过项目实践来学习不熟悉技术栈的挑战。以学习前后端分离的Web应用开发为例，在2024年6月

Anthropic公司推出编程能力出众的Claude Sonnet 3.5大模型之前，人们通常会采用1.2.1节中描述的传统方法：先通过书或视频学习基础知识，然后参照其中的示

例完成一个项目，最后把需求稍作修改后独立重写一遍。然而，当实际项目与学习材料中的示例存在较大差异时，学习者往往会感到无所适从。有了Claude系列大模

型之后，入门前后端分离的Web应用开发变得更加简单，只需使用自然语言向氛围编程工具描述项目需求，它就能生成可运行的实战代码，并详细解释其架构和实

现，让学习过程更加高效便捷。

通过本章学习，你将掌握如何使用中文对话让GitHub Copilot帮你开发一个名为 “Promptyoo-0”的前后端分离的Web应用。这是一个极简版的提示词优化工具，将

采用2025年主流的技术栈及其版本。

先来看一下Promptyoo-0的具体需求。

7.1 需求分析

不知道怎么高效地和AI聊天？Promptyoo-0能帮你。这是一个简单的应用，只要回答6个问题，就能得到高质量的提示词。把这些提示词复制到任何AI聊天工具里

用，就能获得更好的回答。

下面是要回答的6个问题。

・想让AI扮演什么角色？例如“提示词优化专家”。

・想让AI面向谁回答？例如“AI新手”。

・想和AI聊什么话题？例如“提示词优化”。

・想通过提问达到什么目标？例如“找到好用的提示词工具”。

・想让AI用什么形式回答？例如“工具名称和网址”。

这6个问题分别对应6个要素，即角色（role）、受众（audience）、领域（boundary）、目的（purpose）、输出（output）和顾虑（concern），下文将其

简称为RABPOC要素。

Promptyoo-0是一个演示氛围编程的简单工具。它能在本地计算机上运行（以便于演示），可以通过访问DeepSeek API获取优化后的提示词（需要在代码里的.env文

件中配置API密钥）。即使没有API密钥，它也能自己将6个问题的答案组合成提示词。不管你是AI新手还是老手，只要填写这些问题，系统都会用DeepSeek API生成

合适的提示词。

如果将RABPOC要素及其示例输入给Promptyoo-0，它可能会生成如下经DeepSeek API优化后的提示词：

请作为提示词优化专家，帮助AI初学者了解流行且可靠的提示词优化工具。提供一份专门用于提示词优化的知名工具清单，确保每个条目都包含工具名称及其官方网站链接。只收录在AI社区中经过验证且广受认

可的工具，以避免AI产生幻觉。如果不存在此类工具，请诚实告知，不要编造信息。

【避坑指南】使用简单的“一句话提示词”有何不好？

与简单地说“给我一份提示词优化工具清单”相比，使用包含RABPOC要素的完整提示词会让AI工具给出更符合需求的回答。可以做一个实验：先用你常用的AI聊天工

具，在新对话中输入包含完整的RABPOC要素的有关提示词优化工具推荐的提示词，观察AI聊天工具的回复。接着再开启新对话（不要在原对话中继续，因为AI聊天工

具会受之前提示词的影响），只用上面那句简单的一句话提示词，对比两次回复。

我的实验表明，使用简单提示词时，AI往往会推荐一些面向高级用户的工具，这与我作为AI初学者的需求并不相符。

为了提升用户体验，Promptyoo-0采用了流式响应技术。这样在Promptyoo-0生成优化后的提示词时，用户可以实时看到文字逐字显示，无须等待全部内容生成完毕。

提示

因篇幅所限，本章不实现提示词优化历史记录管理和多语言支持功能。感兴趣的读者可以自行实现。

【避坑指南】为什么不使用第2章介绍的扣子来开发Promptyoo-0？

供6个输入框供用户填写。而扣子AI应用开发平台主要专注于聊天应用，要在其中实现类似6个输入框的用户体验会非常困难（当然如果你有兴趣，可以阅读扣子的

文档自行尝试）。因此，本章选择使用更适合实现输入框功能的Web应用来开发。

在企业IT部门中，需求通常由产品经理或需求分析人员录入项目管理系统以跟踪进展。为了真实还原IT人员的工作场景，并在氛围编程工具中体验一下本书撰写时大

火的MCP（model context protocol，模型上下文协议）服务器（MCP服务器能让大模型访问外部工具，如Linear在线项目管理工具。Linear中管理的需求描述将用于

后续让氛围编程工具Copilot提供架构设计建议。这样做的好处是当Linear中的需求描述发生了变化，Copilot也能获取最新版的需求描述），我已将上述需求录入

Linear项目管理系统中的FSK-152这个issue（Linear项目管理工具的术语，用来定义工作项）中，如图7-1所示。

后文将演示如何通过Copilot中设置的Linear的MCP服务器来获取这些需求描述。

明确了需求，接下来看一下这个极简版的Web应用的软件架构该如何设计。

7.2 架构设计与Ask模式

软件架构设计就像建房子前要先画设计图一样重要。在开始编写代码之前，需要对整个软件系统做一个总体规划，这就是软件架构。这种规划涉及3个关键方面：首

先，要确定系统各个组件如何排列，就像规划房间的位置；其次，要设计这些组件之间如何协作，类似于规划房间之间的门和走廊；最后，要明确每个组件的具体职

责，就像决定每个房间的用途一样。

如果跳过架构设计这个重要步骤直接开始编码，很可能会遇到一系列问题：开发到半路可能发现整个设计思路有问题，不得不从头开始；随着项目推进，代码可能会

变得越来越混乱，难以维护；添加新功能会变得异常困难。这些问题都说明了前期架构设计的重要性。

7.2.1 前后端分离架构

在本项目中，我采用现代Web应用开发中常见的前端和后端分离的设计方式。这种设计很像一家餐厅：前端就像顾客看到的就餐区，后端则如同后厨。具体来说，前

端是用户可以看到和使用的界面（如网页），而后端则是在背后处理数据的部分，虽然用户看不到但至关重要。

这种分离设计带来诸多好处：开发团队可以更好地协作，就像厨师和服务员能同时工作；系统更容易改进，因为修改网页样式不会影响后台功能；能够支持多种设

备，同一个后端系统可以支持网页、手机等多种界面；让开发者各自专注于自己的领域；问题定位更加容易，能快速判断是前端还是后端的问题；同时也更加安全，

因为重要的数据处理都在后端完成。

【避坑指南】能否把所有功能都放在前端实现？都放在前端不是更简单吗？

如果把所有功能都集中在前端实现，就会遇到一个严重的问题。这就像一家餐厅想要没有厨房运营一样不切实际。首先在安全方面存在很大隐患：前端的代码是完全

公开的，任何人都可以查看和修改，这可能导致API密钥等敏感信息泄露，甚至让不法分子有机会篡改重要数据，如商品价格。

用户设备的性能水平。当多个用户同时使用系统时，很难保证数据的一致性。每次更新程序，都必须要求所有用户配合才能完成。更糟糕的是，核心功能很容易被竞

争对手复制。最后，这种架构也使得与支付系统等外部系统的安全对接变得异常困难。

7.2.2 用Ask模式获取架构建议

如果你不太熟悉Web应用开发的前后端技术栈，可以使用Copilot的Ask模式，通过编写提示词向其支持的大模型寻求建议。

GitHub Copilot的来历

在开始使用Copilot之前，不妨简单了解一下它的基本情况。

Copilot是一款“传统IDE中的AI插件”类型的强大的AI编程助手，可在Visual Studio Code、JetBrains或Xcode等IDE中安装使用。它是第一个被广泛使用的氛围

编程工具，可以帮助程序员自动写代码。这个由GitHub和OpenAI一起开发的工具，开创了氛围编程的新时代，也影响了后来很多类似的产品。

Copilot的主要目的是让编程变得更简单和快速。它可以自动补全代码、把人类语言转换成代码、生成新代码、解释代码含义，还能将某种编程语言的代码片段转换

成实现同样功能的另一种语言。

Copilot从2014年开始发展，最初是微软的Bing代码搜索工具。2021年6月微软在 Visual Studio Code编辑器中推出测试版，2022年6月开始收费，2023年底升级使

用了更强大的GPT-4大模型，2024年允许用户搭配不同的大模型，如GPT-4或Claude Sonnet 3.5。

从技术上看，Copilot一开始使用专门为编程设计的OpenAI Codex大模型。这个大模型通过学习大量的代码（包括159 GB的Python代码）来理解各种编程语言。后

来，Copilot升级到了更强大的GPT-4大模型，并让用户可以自己搭配想用的大模型。

不过，Copilot现在还有两个主要问题：一是关于版权的争议，因为它使用开源代码进行训练，可能有法律问题；二是安全问题，因为需要联网使用，可能会有代码

泄露的风险。

从2024年12月18日开始，Copilot推出了免费版。免费版每月可以使用2000次代码补全和50次对话，对编程需求不多的用户来说这已经够用了。这是GitHub第一次完

Copilot的CHAT界面是一项集成在Visual Studio Code中的智能对话功能，让开发者能通过自然语言理解代码、调试问题或编辑多个文件。它提供了以下3种模式。

提示

确保你使用了Visual Studio Code 1.99.3及以上版本和Copilot 1.303.0及以上版本（如果版本过低，可能看不到Agent模式）。如果两者尚未安装或版本较低，可

参考附录A.5和附录A.6进行安装或升级。

（1）Ask模式（Ask mode）。这种模式专门用于解答代码相关问题，包括代码解释、技术概念和设计思路等内容。它的最大优势是能快速获取技术建议，特别适合

用于学习和理解代码逻辑。Ask模式有一个重要特点：AI不会自动修改代码，这保证了代码的安全性。不过，这也带来了一定限制——修改代码时必须手动点击相应

按钮，无法实现AI自动修改。这种模式最适合以下3种场景：理解代码（如了解身份验证中间件的工作原理）、学习新技术（如探索目前主流的Web应用开发框

架），以及在AI修改代码前进行人工确认。

（2）Edit模式（Edit mode）。这种模式可以根据自然语言指令直接修改代码，并支持跨文件操作。它的优势在于能自动化实现代码变更（不过在变更生效前，系统

会提供代码对比视图及确认或回退按钮），例如重构代码或修复bug，从而提升开发效率。使用这种模式的前提是，你需要明确知道要修改哪些代码文件，并将它们

添加到上下文中。当你清楚地知道需要在哪里修改代码时，这种模式特别适合快速实现功能（如在用户管理模块中添加邮箱验证字段）或修复错误（如修正循环中的

空引用异常）。

（3）Agent模式（Agent mode）。这种模式能自主完成高层次开发任务，如搭建新功能或项目，并能调用工具链和迭代解决问题。它的优势是能减少人工干预，特别

适合处理复杂任务，还能自动处理依赖和错误。但由于其高度自主性，会消耗更多 token。这样当需求描述不够清晰或大模型产生幻觉时，它会更远地偏离正确方

向。这种模式适合从零开始实现功能（例如根据已有的前端应用创建配套的后端代码）或处理多步骤任务（如优化前端性能并生成报告）。

提示

24（以下简称Ubuntu）版本的最新版Visual Studio Code上安装的最新版Copilot 插件上可用，但Windows 10版本并不支持。

要在Copilot的Ask模式中编写的提示词如代码清单7-1所示。

代码清单7-1 listings/L7-1.md

你是资深的Web应用开发专家，我是Web开发新手。请你阅读 #get_issue FSK-152 中的需求描述，并为我推荐3种软件架构方案。要求这3种方案都是前后端分离的模式，且都包含2025年Web开发领域最流行的技

术栈（要求为每个技术栈分别附上2025年最主流的版本号），并详细对比这些方案的优缺点及其最佳应用场景。

注意，代码清单7-1中的#get_issue是Linear MCP服务器提供的工具，用于获取一条需求记录，而FSK-152是该需求的编号。将这两部分组合使用，就能通过在

Copilot中配置的Linear MCP服务器获取7.1节中存储在Linear项目管理系统中的需求描述（如图7-1所示），无须手动复制并粘贴。提交这段提示词后，Copilot会询

问是否执行get_issue工具，点击“Continue”按钮即可执行。（Linear MCP服务器的配置见附录A.7。如果你觉得配置过于烦琐，可以暂时忽略这里和后文提到的

MCP服务器相关工具，直接将需求描述复制并粘贴到提示词中即可。）

要想在Copilot里获取大模型对架构设计的建议，可以在Copilot的CHAT界面下的 Ask模式中输入代码清单7-1中的提示词询问，如图7-2所示。

图7-2 使用Ask模式询问大模型

进入Ask模式的具体步骤如下。

（1）创建项目目录。在终端运行以下命令，在个人目录下创建名为“mycopilot”的空目录，作为本章项目实战的根目录。

# 进入个人根目录

cd

# 新建项目目录

# 进入项目目录

cd my-copilot

# 在当前目录下初始化一个新的Git仓库

git init

# 复制配套代码根目录（名为book-vibe-coding）下的.gitignore文件到当前目录（命令最后那个点表示当前目录）

# 以便提交代码时忽略那些无须提交的代码（如系统自动下载的依赖库和包含API key这些保密信息的.env文件）

cp ../book-vibe-coding/.gitignore .

# 将.gitignore加入staged区域准备提交

git add .

# 提交代码，并附上提交消息

git commit -m "added .gitignore file"

# 查看刚刚进行的提交

git log --oneline

提示

由于氛围编程具有探索性特点，代码可能会出现运行错误。为了方便比较错误前后的代码状态，并在需要时能够回退到之前可正常运行的版本，需要安装Git版本控

制系统。下面的命令中包含与Git相关的操作。如果你尚未安装Git，可参考附录 A.8中的安装说明。

项目，不再赘述）。执行以下命令打开项目，注意末尾要加上点以表示当前目录：

code .

（3）进入CHAT界面。点击Copilot右上角的“Toggle Secondary Side Bar”按钮（鼠标指针悬停可见按钮名称）打开CHAT界面。也可以使用Chat快捷键（在macOS

系统上用“Ctrl+Cmd+I”，在Windows/Ubuntu系统上用“Ctrl+Alt+I”）或Toggle Secondary Side Bar快捷键（在macOS系统上用“Opt+Cmd+B”，在Windows/Ubuntu

系统上用“Ctrl+Alt+B”）。再次点击按钮或使用相同快捷键即可关闭CHAT界面。

（4）选择Ask模式：在Ask Copilot输入框下方“@”按钮右边，点击模式按钮切换至Ask模式。

（5）搭配大模型：点击“Ask”按钮右侧的大模型名称（默认是GPT-4o）按钮来切换搭配的大模型。确认搭配了Claude Sonnet 3.5（如果你订阅了Copilot的Pro，

可以选择Claude Sonnet 3.7，因为这一系列大模型编程能力出众）。

（6）输入提示词：将代码清单7-1中的完整提示词复制并粘贴到Ask Copilot输入框中。

（7）提交：在Ask Copilot输入框中按回车键提交提示词，Copilot随后会将提示词发给所搭配的大模型处理，片刻你就能看到大模型的回复。

【避坑指南】该选哪款大模型？

点击图7-2中的“Claude Sonnet 3.7”按钮后，Copilot至少会显示可选择的5种大模型（免费版），即Claude Sonnet 3.5、Gemini 2.0 Flash、GPT-4.1

(Preview)、GPT-4o和o3-mini，其中前4种大模型适合快速编程，而o3-mini更适合推理和规划任务。根据我的实践经验，在编程能力方面，Claude Sonnet 3.5（或

Claude Sonnet 3.7）的表现明显优于其他大模型。因此，除非特别说明，否则本章将默认使用Claude Sonnet 3.5（或Claude Sonnet 3.7）。

根据代码清单7-1中的提示词，Ask模式为我推荐了3种架构方案。由于AI能够详细解释当前流行的技术栈，因此在学习过程中选择架构时，可以优先考虑使用最热门

的方案（这些方案在AI训练数据中有丰富的资料），即使对这些技术不太熟悉也无妨（因为不懂可以问AI）。在推荐的3种架构方案中，我选择了方案一。

为了在后续与Copilot交流时能明确引用方案一（AI很容易健忘），并确保Copilot 基于该方案作答，我将方案一的内容保存到项目根目录下的rules目录中，文件名

制，只能通过手动方式来实现。代码库文件rule-architecture.md的内容如下：

## 方案一：React + Vite + TypeScript + Tailwind CSS（前端）& Node.js + Express + TypeScript （后端）

### 技术栈及主流版本（2025年预测）

• 前端：
• React 18.x
• Vite 5.x
• TypeScript 5.x
• Tailwind CSS 4.x - React Router v6.x - 后端：
• Node.js 20.x
• Express 5.x
• TypeScript 5.x
• Jest 30.x（测试）
• pino/winston（日志）

如果用C4模型架构图来可视化这个架构，得到的Promptyoo-0前后端分离架构图如图7-3所示。这张图有助于了解这个架构的核心组成部分（生成C4模型风格的架构

图的方法参见6.3.2节）。

图7-3展示了Promptyoo-0应用的请求发送过程，展现了从用户到DeepSeek API的完整路径。

在这个系统中，终端用户与AI驱动的Web应用Promptyoo-0交互。Web应用分为两个主要部分：前端使用React、TypeScript、Vite和Tailwind CSS技术栈，负责用户

界面与交互；后端采用Node.js和Express.js，处理请求并对接AI服务。此外，系统还依赖一个关键的外部组件DeepSeek API，它提供提示词优化服务。

整个请求流程简洁明了：用户通过浏览器与前端交互，前端将提示词通过HTTP POST请求发送至/api/optimize端点，后端则通过HTTP和OpenAI SDK与DeepSeek

API通信。这构成了从用户输入直至DeepSeek API收到待优化的提示词这样一个完整的请求链路。

7.2.3 自动生成提交消息

创建完rule-architecture.md文件后，需要提交这个文件，以便和之后不同目的的代码提交进行区分。

【避坑指南】为何要创建完一个文件就提交代码？等项目完成后一起提交不是更简单吗？

如果等到项目完成才提交代码，就无法发挥Git这类版本管理工具的优势了。假设你没有及时提交，而是继续创建和修改其他代码、文档或配置文件。突然代码运行

出错了，你向Copilot求助并获得了修复方案。但修复后又出现新的错误，不得不再次请教Copilot。经过多次反复，你终于失去耐心，想要回退到代码最后一次正

常运行的状态。但因为你之前没有提交代码，所以现在无法找到那个良好运行的版本。最终，你只能删除整个项目，从头开始——这就是典型的因小失大。

在这个环节中，我发现了Copilot的一个令人惊喜的功能：它不仅能自动补全代码，还能自动生成代码提交消息。使用这个功能非常简单，只需点击图7-4中左侧

从上往下数第3个图标（鼠标指针悬停在它上面会显示Source Control图标名，该图标右下角显示数字1，表示新创建的文件已被系统识别）。

然后点击左侧蓝色的“Commit”按钮右上方的生成提交消息的图标（鼠标指针悬停在这个图标上，会出现图标名“Generate Commit Message with

Copilot”）。稍等片刻，Copilot就会在左侧生成一条基于当前代码变更的提交消息。如果对生成的内容不满意，你可以在提交前随时编辑。确认提交消息后，点击

恼。

图7-4 Copilot能自动生成代码提交消息

【避坑指南】如何让提交消息更可读？

为了提高提交消息的可读性，便于通过Git查看近期代码变更，你可以采取两个措施：一是在完成每个原子化的代码变更后立即使用自动生成提交消息功能，这样一

来因为原子化的代码变更所完成的功能便于大模型提炼，所以生成的提交消息也会更易懂；二是在提交消息开头添加乔希·布切亚（Josh Buchea）提出的提交消息

类型，用于说明此次提交的主要目的。以下是几种常用的提交消息类型。

・feat：为用户实现的新功能。

・fix：为用户修复了bug。

・style：格式化代码等。

・refactor：重构生产代码，例如重命名变量。

・test：添加缺失的测试、重构测试。

・chore：做了一些配置更改。

图7-4展示的代码变更是创建一个手工模拟规则机制的规则文件。虽然按惯例可以用chore（因为规则可以视为一种配置）作为提交消息的前缀，但考虑到规则的重

要性，我选择直接使用rule作为前缀。

由于Copilot自动生成提交消息不仅便利，而且频繁的小批量代码提交有助于追踪代码变更，因此本书后续将在完成每个原子性小功能后默认提交一次代码，不再特

别说明。

明确了架构后，接下来就要进行任务拆解了。

7.3 任务拆解

在开始使用氛围编程方法之前，为什么要先拆解任务呢？难道不能像第6章那样 “单次对话即成功”地直接把已确定的需求描述和架构设计交给氛围编程工具，让

它一次性生成完整的可运行系统吗？

这确实是一个好问题。先拆解任务的原因在于本章与第6章中的实战目的不同。第6 章主要面向产品经理或正在融资的创业者，他们希望快速生成可运行的Web应用产

品原型，自然期望“单次对话即成功”，不愿中途遇到大量需要修复的运行错误。

而本章的目标读者主要是有IT经验的人或IT新人，他们的诉求是通过小步迭代的实战来学习不熟悉的技术栈，因此中途遇到运行错误反而是好事，能让他们从大模型

的修复方法中学到更多知识。

另外，拆解任务不仅有助于厘清思路和避免遗漏关键功能，还能让AI在有限的对话上下文中专注处理单个任务，从而产出更高质量的代码。

既然AI可以辅助编程，那也可以让AI来辅助进行任务拆解。我使用了以下提示词（注意，#file需要在开头手动输入并选择文件rule-architecture.md，否则不会

在提示词中加亮起效，如图7-2右上方提示词中#get_issue那样字体变为带颜色），先是咨询了Copilot Pro（搭配Claude Sonnet 3.7大模型），然后咨询了

式）我在下面的提示词中使用英文术语“vibe coding”，是因为大模型会根据提示词中的关键词在互联网中搜索，用英文关键词搜索会获得更丰富的内容。要让大

模型搜索这个2025年新出现的术语需要开启“Web搜索”模式）。

#file:rule-architecture.md 是本项目的架构描述，#get_issue FSK-152 是本项目的需求描述。请基于这两个材料，作为精通任务拆解和vibe coding程的开发者，请针对我这位Web开发新手，使用2025年Web

开发与vibe coding最佳实践来拆解任务，帮助我顺利完成这个应用的开发。请按照最佳实践推荐的顺序排列这些任务，并确保每个任务都足够小且可执行。

在分析了两个氛围编程工具的答复后，我发现它们主要依据传统的编程最佳实践，而没有采用氛围编程方法。以Claude为例，它在前端界面开发中提出了4个子任

务：创建核心组件、实现提示词表单组件、设计结果展示区域和实现响应式设计。

这种拆分方式显然没有考虑氛围编程的特点，因为使用氛围编程时，这些任务只需 “【用AI】根据界面文字描述直接生成前端代码”一步即可完成。尽管我为Claude

启用了“Web搜索”功能可以检索最新技术文章，但它对氛围编程的理解仍然很浅显，只停留在一些表面的建议上，如设计清晰的提示词、建立迭代反馈循环、确保

人类参与、采用组件化模块化设计以及注重用户体验等泛泛的内容。

这个结果并不令人意外，因为大模型的训练数据还没有涵盖氛围编程的相关内容。

于是，我决定亲自动手，列出使用氛围编程实现Promptyoo-0的任务拆解清单（其中的第7步“前端单元测试”和第8步“后端单元测试”在完成后发现单元测试维护

工作量太大，于是改为端到端测试，参见8.1节）。

（1）需求分析

【人工】描述需求

（2）架构设计与技术选型

【用AI】生成架构建议

【用AI】生成架构规则

【用AI】生成C4模型架构自然语言描述

【用AI】生成C4模型组件层架构图脚本

（3）任务拆解

【人工】在Linear里创建issue

【人工】拼凑用户界面

【用AI】为拼凑的界面生成文字描述

【人工】修改界面文字描述以满足需求

（5）生成React前端代码

【用AI】根据界面文字描述直接生成前端代码

【人工】在本地计算机运行前端应用

【用AI】协助我看懂前端代码

（6）生成Node.js后端代码

【用AI】修改前端代码以备好发给后端的提示词

【用AI】生成后端代码

【用AI】修复运行错误

【用AI】修复功能异常

【用AI】实现流式响应功能

（7）前端单元测试

【用AI】搭建前端测试框架

【用AI】让第一个前端单元测试运行通过

【用AI】验证前端单元测试的保护效果

【用AI】补充其他关键的前端单元测试

（8）后端单元测试

【用AI】搭建后端测试框架

【用AI】让第一个后端单元测试运行通过

【用AI】补充其他关键的后端单元测试

（9）代码评审

【用AI】可视化软件架构与代码对应关系

【用AI】评审并改进代码

上面这份拆解清单可以在本书配套代码中的ch07-copilot-feat/linear-issuetemplate. csv文件中找到——这是我从Linear中导出的需求列表，包含了所有拆

分好的任务，也可以用作Linear导入需求的模板。从拆解清单中的“【用AI】”标记可以看出，我在任务执行中大量运用了AI的协助。

接下来的内容将按照上述任务拆解逐步展开。先来看一下如何生成并修改用户界面文字描述。

7.4 用户界面与Vision

作为一本介绍氛围编程的书，本书将使用自然语言让AI来设计用户界面。首先，我会准备描述界面的提示词，然后利用bolt这样的氛围编程工具，将这些提示词转化

为前端原型代码。

【避坑指南】为何不用Copilot生成前端代码？

答案是可以用，但用户体验远不如bolt。我曾尝试在Copilot的Agent模式下用自然语言描述生成前端代码。然而，尽管提示词中明确要求“左右分屏”的界面，生成

的代码却显示为上下分屏，而且时钟图标异常巨大。即便请求修复3次，这些问题依然存在。我还在Ask模式下用/new尝试创建新的前端项目，但运行时却遇到了

“Build Error. Failed to compile. Next.js (14.2.28) is outdated (learn more)”［构建错误。编译失败。Next.js (14.2.28) 已过时（了解更多）］的错

误。改用bolt来生成前端代码后，每次都能完美完成任务。

7.4.1 拼凑用户界面

如何用文字描述Promptyoo-0的用户界面呢？当然，可以像第6章那样用Figma绘制线框图，或者直接用纸笔手绘，再让AI识别并用自然语言描述，但在本章中我想尝

试一种不同的方法。

词优化工具界面，选取合适的部分进行截屏，然后用PPT将这些截屏拼接起来。之后，让AI为我把这个拼接好的界面转换成文字描述。

有人可能会问：“这种拼接的界面中肯定有需要调整的文字和图像，难道还要去P 图吗？太麻烦了吧。”其实不用担心。我可以先让AI描述这个未经完善的界面，然

后只需修改AI生成的文字描述即可。这样做比修图更简单，也比在Figma中从头设计原型要省力得多。

在浏览并测试了AI推荐的几款提示词优化工具后，我相中了在线提示词优化工具 PromptPerfect的左侧边栏界面，又觉得在线提示词优化工具Prompt Hackers的

ChatGPT Prompt Optimizer的右侧提示词输入区也不错。虽然后者的提示词输入框数量不够，但我可以在后期添加。把这两者拼接起来，就是我想要的界面。我在

PPT中将这两个部分组合成了一个完整的用户界面，如图7-5所示。

7.4.2 为拼凑的界面生成文字描述

图7-5中左侧边栏中“Chat”部分的文字描述需要修改，右侧提示词输入区也需要调整，要将当前的3个输入框扩展为6个，并更新标题和说明文字。不过，正如前面

提到的，不必急于修改图片本身，先用Copilot生成这张图的文字描述，之后再进行必要的调整。

要让Copilot识别图7-5，可以使用Copilot的Vision功能。Vision功能允许在与大模型对话时加入图片内容。最简单的方法就是用鼠标将图7-5对应的文件（本书配

套代码中的ch07-copilot-feat/cobbled-ui.png文件）拖曳到Copilot右下方的提示词输入框，作为对话的上下文，如图7-6所示。

图7-6 Vision功能允许在与大模型对话时加入图片内容

添加图片后，在提示词输入框中输入代码清单7-2中的提示词，然后按回车键，让 Copilot生成这张图片的文字描述。

代码清单7-2 listings/L7-2.md

这是一个提示词优化系统的界面。请先描述整体布局（如左侧导航栏和右侧主要内容区），然后详细说明每个区域内的文字、按钮和输入框等具体元素。

当Copilot生成用户界面文字描述后，可以将这些描述保存到另一个文件（后缀可以是“.md”）中，并根据Promptyoo-0的需求修改文字内容。然后，在修改好的界

面描述前添加代码生成的要求，就可以将其发送给bolt来生成前端代码了。完整的提示词如代码清单7-3所示。

代码清单7-3 listings/L7-3.md

作为Web UI专家，请根据下面的Web应用开发架构设计中的前端框架和最佳实践，以及后续的界面描述，为AI提示词优化应用生成用户界面。下面是架构设计：

（略，见7.2.2节方案一）

下面是界面描述：

### Overall Layout

The interface follows a two-column layout:

1. **Left Sidebar**:

• Logo/Brand section with "Chat" text and subtitle - "New session" button with a pen icon
• "History" section with clock icon
• Two history items in Chinese characters

1. **Main Content Area (Right)**:

• Header with "Promptyoo" title
• Descriptive subtitle text
• Form sections for prompt optimization

### Detailed Components

#### Left Sidebar

• "Chat" in large text - Subtitle: "Optimize prompts to include RABPOC."
• Black in bold "New session" button with pen icon - History section with grey clock icon
• Two navigation items in Chinese
• “提示词优化要素”
• “免费AI工具推荐”

#### Main Content Area

1. **Header Section**:

• Title: "Promptyoo"
• Subtitle: "Want high-quality AI responses? I can help you optimize your prompts. Before

asking AI a question, simply provide brief answers to these 6 sub-questions that help generate high-quality prompts. Then, I'll ask DeepSeek to generate an excellent prompt based

on your answers. You can then copy this prompt to ask AI."

1. **Input Form**:

• **Role Section**: - Label: "R: What role you want AI to play?"
• Text input field with "Prompt Optimization Expert" as example
• **Audience Section**: - Label: "A: What Audience you want AI to generate content for?"
• Text input field with "AI tool beginners" as example
• **Boundary Section**: - Label: "B: What Boundary should AI focus on for this

discussion?"

• Text input field with "Prompt optimization" as example
• **Purpose Section**: - Label: "P: What Purpose you want AI to help you achieve?"
• Text input field with "find popular prompt optimization tools"

• **Output Section**: - Label: "O: What Output format you want AI to generate?"
• Text input field with "tool name (official website link)" as example
• **Concern Section**: - Label: "C: What Concern you have about this discussion with AI?"
• Text input field with "AI hallucinations (if not found, please be honest and don't make

up information)" as example

1. **Action Area**:

• Blue "Optimize prompt" button

1. **Output Section**:

• Gray background section - Label: "Optimized prompt"
• Helper text: "Your optimized prompt will be displayed here. Optimize your prompt now!"

从代码清单7-3可以看出，这段文字描述已将标题和内容更新为与Promptyoo-0应用相关的内容，并且把提示词输入框扩展到了6个。

【避坑指南】为什么代码清单7-3中的用户界面描述用英文而不用中文？

虽然你可以在提示词中要求AI用中文生成描述，但我觉得用英文更为便利。原因在于，让AI根据这段描述生成前端代码时，代码中的变量名一般还是使用英文，如

“角色”在代码中就得写作“role”。使用英文描述可以避免大模型在处理代码和界面时频繁切换中英文，从而减少因翻译不一致导致的错误，使整个开发流程更加

顺畅。

7.5 用bolt生成React前端代码

由于bolt在生成前端代码方面的优秀表现，我选择使用它来生成前端代码。将代码清单7-3中的提示词提交给bolt后，系统迅速生成了前端代码，并提供了实时预览

效果，如图7-7所示。

图7-7 预览bolt根据提示词所生成的前端代码

图7-7右侧的前端界面展示了Promptyoo-0应用的主要功能。

（1）核心功能：通过7.1节介绍的6个关键要素（RABPOC要素）帮助用户优化AI提问的提示词，从而获得更高质量的AI回答。

（2）操作流程：用户填写6个关键要素的简短答案后，系统自动生成优化后的提示词，用户可直接复制使用。

（3）界面模块：左侧边栏导航展示新会话按钮和历史记录（如“提示词优化要素”和“免费AI工具推荐”）；右侧提示词输入区引导用户逐步填写RABPOC要素；

右侧下方输出区实时显示优化后的提示词，支持一键复制。

（4）设计特点：采用简洁的分步交互，减轻用户认知负担；配备示例说明（如每个要素的“e.g.”提示），提高易用性。

（5）用途：适用于需要精确控制AI输出的场景（如工具推荐、学习辅导等），特别适合AI初学者使用。

码后，点击图7-7右上角的“Export”按钮并选择“Download”下载代码zip包。

（如果你以前没有通过浏览器下载并解压zip包到个人目录，可以参考附录A.9完成这些操作。）

下载完成后，检查浏览器保存zip包的位置（通常在个人目录的Downloads目录中），将zip包移动到之前创建的项目目录my-copilot下并解压，然后将解压后的

目录重命名为frontend，以表明这是前端代码。

最后运行下面的命令，用Visual Studio Code在my-copilot目录下（注意不是在 frontend目录下，因为之后还要让Copilot创建backend目录）打开项目，就可以开

始使用Copilot来修改前端代码或添加后端代码了：

cd ~/my-copilot

code .

在继续使用Visual Studio Code编写代码之前，需要在Visual Studio Code内置终端运行前端代码，以验证bolt生成的代码能否正常运行。（如果你还未在Visual

Studio Code内置终端运行过命令，可以参考附录A.10和7.5.1节完成在终端运行 npm命令。）

【避坑指南】为何像bolt这样的Web应用氛围编程工具所生成的代码要在本地运行？

因为7.1节中的需求描述已经明确要求Promptyoo-0 Web应用“在本地计算机运行”。虽然图7-7显示代码在bolt云平台上运行良好，但在本地环境中不一定如

此。这是因为bolt生成的前端代码依赖于特定版本的JavaScript库。这些代码在 bolt的云平台上运行正常，是因为这些代码已经过工程师测试。但是，本地环境可

能缺少这些特定版本的依赖库，从而导致运行问题。

我曾使用过另一款类似的Web应用氛围编程工具v0，也遇到了同样的情况。v0生成的代码在其云平台预览时运行正常，但下载到本地后却在运行npm install时出现

无法解析依赖树的错误。解决这类问题最有效的方法是将本地运行时的完整错误消息提供给Copilot，让它帮助修复。

7.5.1 在本地计算机运行前端

在本地计算机运行前端应用可以在Visual Studio Code内置终端中进行。打开 Visual Studio Code内置终端的方法是，在菜单栏选择“Terminal”，点击“New

Windows/Ubuntu系统上用“Ctrl+`”）。之后在内置终端里输入以下命令：

# 进入前端代码目录

cd frontend

# 安装依赖包以便启动开发环境

npm install

# 启动开发环境以便本地运行前端应用

npm run dev

如果在运行上面npm install命令时遇到错误且不知该如何让AI帮你处理，可以参考附录A.11获取解决方案。

运行npm run dev命令后，终端将显示与图7-8所示界面类似的界面。

按住快捷键（在macOS系统上用“Cmd”，在Windows/Ubuntu系统上用“Ctrl”），然后点击图7-8中方框标注的链接“http://localhost:5173/”，即可在浏览器中

看到图7-7右侧所示的前端界面。

图7-8 运行前端开发环境

对编程新手而言，在氛围编程工具出现前后看懂代码的重点有着显著差异。在AI出现之前，看懂代码重点聚焦于如何通过代码实现功能（how），以进行手工编程。

而在AI出现之后，由于AI能够快速生成高质量代码，看懂代码的重点转向了理解代码的设计理念（what）和优劣势（why），从而能在AI协助下高效地进行代码修改

和调整。

与第3章和第4章只处理单个代码文件的简单应用不同，第5章、第6章和本章都涉及多文件的Web应用。在看懂这类代码时，除了要理解单个文件内的函数调用，还需

要掌握跨文件的函数调用和配置关系。但最重要的仍然是理解为什么这样设计，这样才能让AI根据不断变化的需求有效地调整代码。

【避坑指南】为何一定要看懂代码后才能在AI的帮助下高效地调整代码？

一定要看懂代码后才能在AI的帮助下高效地调整代码主要有3个原因。

（1）更好地指导AI：只有先理解代码的整体设计和目的，才能给AI准确的指示。

如果不了解代码就让AI修改，可能会破坏原有的设计，导致后期维护变得困难。

（2）更聪明地使用AI：理解代码后，就知道哪些工作适合交给AI做，哪些需要自己处理。这样能让AI发挥最大作用。

（3）节省时间和成本：理解代码就能够准确定位问题所在的模块和函数，从而能更有针对性地指导AI进行修复。这样可以避免让AI阅读整个代码库，节省时间和

token消耗。

可以用Copilot的/explain功能来帮助看懂bolt生成的前端代码。

/explain是一种智能操作（smart action）。智能操作是Copilot的一项重要功能，允许用户通过简单的提示词缩略语（参见本节最后一个避坑指南中的解释）快

速获取AI辅助，而无须手动编写复杂的提示词。这些操作包括/explain（解释代码）、/tests（生成测试）、/doc（生成文档）和/fix（修复代码）等，所有这些

智能操作都可以在Visual Studio Code编辑器CHAT界面的Ask模式中便捷使用。通过智能操作，开发者能更高效地完成日常编程任务。

在Ask模式中提示词开头输入“/”，会显示一系列可用的智能操作（其他智能操作的用法可用查看Copilot官方指南中的Copilot Chat速查表），如图7-9所示。

图7-9 在Ask模式中提示词开头输入“/”会显示一系列可用的智能操作

在图7-9中，你会发现两个/explain操作。它们的区别在于右侧显示的聊天参与者（chat participant）：上面的@workspace是Copilot内置的代码分析专家，负责

提供当前项目的专业知识；下面的@terminal则专门处理终端命令相关的问题。智能操作通常与聊天参与者相关联，所以在输入/后，相应的聊天参与者会自动显

示。因为我要分析项目代码，所以选择@workspace。

【避坑指南】常用的聊天参与者类型有哪些？

Copilot提供以下几种主要的内置聊天参与者。

・@workspace：可以回答有关整个代码库的问题。Copilot 会根据问题内容智能检索相关文件和符号，并通过链接和代码示例提供答案。

・@terminal：可以回答有关终端命令和shell操作的问题。

・@github：可以回答有关代码仓库中的议题、拉取请求等内容。

・@vscode：可以回答Visual Studio Code相关的问题。

在Ask模式中提示词开头输入@即可看到所有可用的聊天参与者。

@workspace /explain 请从整体上分析 frontend 目录下的前端代码 #codebase。首先全面介绍所使用的技术栈、各自的版本号及其用途。然后详细列出前端的完整目录结构，并解释每个关键文件的作用，这

样在未来需要添加功能或修复问题时，我能快速定位到相关文件。重点说明需要手动修改的文件，对于工具自动生成和维护的文件只需简要说明。最后，列出在开发维护过程中最常需要修改的文件，作为重点关

注对象。其中的代码具体实现细节可以先不讨论。

注意代码清单7-4中第一句的特殊写法：#codebase的左右各有一个空格，如果没有这些空格，Copilot就无法将其标记为带颜色（如图7-2中右侧提示词中带颜色的

#get_issue），也就会把它视为普通提示词。这种写法有什么特别之处呢？

【避坑指南】如何让Copilot分析整个代码库相关文件？在Ask模式中编写提示词经常以什么作为开头？

虽然可以在提示词中直接说明“查看整个代码库相关文件”，但有一个更简便且精确的方法：使用#codebase。这是Copilot内置的聊天变量（chat variable），它

会自动为提示词添加“整个代码库相关文件”的上下文。比起手动输入长串文字，这种方式更加高效。

本书将Copilot内置的聊天变量、聊天参与者和智能操作统称为提示词缩略语。在 Copilot中的Ask模式中编写提示词时，一种常见的模式是先确定哪个聊天参与者和

智能操作最适合完成任务，并将它们写在提示词开头，即Copilot提示词的开头一般是“@聊天参与者 /智能操作”（注意，两个提示词缩略语之间要有空格），然

后补充相关的自然语言描述。

例如，代码清单7-4中的提示词旨在分析前端代码的整体情况，因此选择了聊天参与者@workspace和智能操作/explain作为开头。在提示词正文中，如果需要引用特

定上下文，则可以使用聊天变量，如上面提到的#codebase。

在Ask模式的提示词输入框中输入#时，你可以看到所有可用的聊天变量列表。（如果你在一行中文提示词中插入#却看不到聊天变量列表，可以先在提示词中那个插

入位置输入两个连续的空格，然后把光标移动到两个空格之间，再输入#，应该就能看到聊天变量列表。）（其他聊天变量的用法可用查看Copilot官方指南中的

Copilot Chat速查表。）

复制代码清单7-4中的提示词到Ask模式的输入框并按回车后，@workspace立即开始分析前端代码（相关代码可在本书配套代码中的ch07-copilot-feat/frontend-by-

bolt-only目录中找到），并提供详细结果（参见本书配套代码中的ch07-copilotfeat/prompts/ prompt-comprehend-frontend-code.md文件）。

由于frontend/src/App.tsx是决定前端界面呈现的根组件文件，需要重点分析它的结构和功能。

在分析这个文件之前，先执行npm和npx这两条代码格式化命令来优化阅读体验。这些命令会调整代码缩进，并将过长的代码行重新排版，使其能在一屏内完整显示，

避免需要水平滚动。因为已经安装了Git，所以现在可以方便地查看格式化后的效果了。要执行的命令如下：

# 按快捷键（在macOS系统上用“Cmd+`”，在Windows/Ubuntu系统上用“Ctrl+`”）打开Visual Studio Code内置终端

cd frontend

# 安装Prettier作为开发依赖，用于代码格式化

npm install --save-dev prettier

# 使用Prettier格式化src目录下的所有TypeScript和TypeScript React文件

npx prettier --write "src/**/*.{ts,tsx}"

执行完上述命令后，在Visual Studio Code中点击左侧从上往下数第3个图标（该图标右下角显示数字4，表示有4个文件变更），你可以看到右侧列出了自上次执行

git commit命令以来所有变更的文件。其中App.tsx和main.tsx这两个文件的变更是由代码格式化命令导致的。点击App.tsx文件，右侧会显示该文件的新旧版本对

比，如图7-10所示。

图7-10 运行代码格式化后的效果

从图7-10可以看出，右侧第44～47行重新排版了左侧过长的第39行，使其尽量能在一屏内显示（实际上并没有，但比之前好些了）。同样，右侧第60～64行也对左侧

第52～55行进行了重新排版，让内容能够在一屏内完整显示。

【避坑指南】如何提升代码阅读体验？

在每次执行git commit进行代码提交之前，都要运行一次代码格式化命令。这样能自动修复混乱的代码缩进和过长的代码行，让代码更整洁，提升代码阅读体验。

7.5.4 用Inline Chat的/doc为代码加注释

为了理解App.tsx代码文件的原理，可以使用Copilot的Inline Chat（内联聊天）

功能来添加和阅读代码注释。操作步骤如下：首先选中需要操作的代码，由于此时要为整个App.tsx文件添加注释，可以使用快捷键（在macOS系统上用“Cmd+A”，

在Windows/Ubuntu系统上用“Ctrl+A”）选中所有代码；然后使用Inline Chat快捷键（在macOS系统上用“Cmd+I”，在Windows/Ubuntu系统上用“Ctrl+I”）激活

内联聊天，最后输入“/”，这样就能列出AI所能执行的各种智能操作，如图7-11 所示。

图7-11 用快捷键“Cmd+I”或“Ctrl+I”进入Inline Chat

为了添加注释，选择/doc操作（可以看到Inline Chat输入框右侧显示默认搭配 GPT-4o大模型，经过我的试用，发现这个大模型编写文档的能力优于其他4个），

然后加入RABPOC要素风格的提示词，具体如下：

/doc 作为Web前端开发高手，请针对我选中的代码为新手写注释，要求新手读完后能理解这些代码的作用，以便将来需要修改代码时，知道去哪里修改。如果你看不懂，就实说，不要编造。

之后按回车，Copilot就会开始生成注释文档。点击“Accept”按钮接受修改后，代码注释就自动添加完成了。注释会包括组件结构、关键功能、修改方法及新手指

南。通过阅读这些注释，就可以更好地理解App.tsx的代码结构，以方便未来增加新功能或修复缺陷。

有一点需要注意，当你让大模型改动了代码后，相应的注释也需要更改，否则就有可能成为“指向错误方向的指路牌”。所以大量注释的添加其实是一把“双刃

剑”，要慎用。等你理解了注释后的代码，就可以把注释删掉，因为大模型通常能生成命名揭示意图的代码，所以代码本身就已经是很好的“注释”了。

7.5.5 用Inline Chat的/fix修复问题

查看图7-7右侧的用户界面时，你会发现左侧边栏History下显示了两个示例历史对

用。解决方案是将这两条示例历史对话在代码中注释掉——这样代码中仍保留着相关内容，但用户界面上就不会显示了。

要注释掉前端代码，步骤很简单：在App.tsx中使用Shift+方向键选中目标代码（选中<nav>标签内包含两条对话标题的所有内容），然后按Inline Chat快捷键，

输入/fix操作，并添加提示词“请注释掉所选代码”。按回车确认后，点击两次 “Accept”按钮（即分别确认添加注释的开头和结尾）即可完成操作。

前端代码的生成工作已经告一段落。接下来开始编写后端代码。

7.6 生成Node.js后端代码

根据图7-3中的架构图，前端会将提示词发送至后端，然后后端通过DeepSeek API 来优化这些提示词。因此，开发后端代码之前，需要先在前端准备好这些提示词。

为了方便查看提示词的准备状态，我计划添加以下功能：用户点击“Optimize prompt”按钮后，系统会在“Optimized prompt”区域下方显示准备发送给

DeepSeek API进行优化的提示词。

7.6.1 备好发给后端的提示词与Edit模式

在通过7.5.4节的注释理解了App.tsx代码后，我发现只需在App.tsx文件中修改代码就能完成后端提示词的准备工作。针对这种已明确需要修改哪些文件的场景，可

以在Copilot的CHAT界面中使用Edit模式（参见7.2.2节）。具体步骤如下。

（1）打开Copilot的CHAT界面。

（2）选择App.tsx作为上下文。点击Visual Studio Code左上角Explorer图标，在 my-copilot目录树中找到并打开frontend/src/App.tsx文件，使其成为当前文件

（current file）。该文件会自动添加到Visual Studio Code界面右下方的 Context中（显示为“App.tsx Current file”），作为与大模型对话的上下文。

【避坑指南】如何把多个文件加入上下文？

虽然当前文件会自动加入上下文，但同一时间只能有一个当前文件。如果想添加多个文件到上下文，可以在Explorer的目录树中找到目标文件，右键单击后选择

“Copilot”→“Add File to Chat”。重复这个步骤，直到添加完所有需要的文件。

式。

（4）输入提示词。将代码清单7-5中的提示词复制并粘贴到Ask Copilot输入框中。

代码清单7-5 listings/L7-5.md

请修改代码，让程序在点击“Optimize prompt”按钮后，在“Optimized prompt”下方显示以下内容（注：第一段为固定内容，随后的6行分别对应Web UI右侧6个输入框的标题及其初始内容，之后不要再增

加其他内容；另外，这些内容都要保存到一个变量里，以便我将来将其作为提示词去问AI）：

As a prompt engineering expert, please generate an English prompt based on the answers to the 6 questions below, targeting AI beginners. The prompt must incorporate the content from

all 6 answers to help formulate high-quality questions for AI. Please provide only the prompt itself, without any additional content.

What Role you want AI to play? Prompt Optimization Expert.

What Audience you want AI to generate content for? AI tool beginners.

What Boundary should AI focus on for this discussion? Prompt optimization.

What Purpose you want AI to help you achieve? find popular prompt optimization tools.

What Output format you want AI to generate? tool name (official website link).

What Concern you have about this discussion with AI? AI hallucinations (if not found, please be honest and don't make up information).

（5）提交。在Ask Copilot输入框中按回车键，提交提示词。Copilot随后会将提示词转发给所搭配的Claude大模型处理，片刻你就能看到大模型的回复。在屏幕下

方的蓝色悬浮工具栏中，可以使用上下箭头查看代码改动。确认改动无误后，点击 “Keep”按钮接受修改，如图7-12所示。

（6）运行并测试。在Visual Studio Code的内置终端里运行前端（相比在外部终端运行，使用Visual Studio Code内置终端的好处是出现错误时可以方便地将错误

消息提供给Copilot进行问题排查），以测试Copilot是否成功实现了“备好发给后端的提示词”的功能。

示词。至此，就可以开始编写后端代码了。

图7-12 在Edit模式下修改上下文中的文件的代码

7.6.2 生成后端代码与Agent模式

由于需要基于现有前端代码使用氛围编程让AI生成后端代码，这与7.2.2节中介绍的Agent模式在搭建新功能方面的优势不谋而合，因此下面使用Agent模式来生成后

端代码。具体步骤如下：

（1）申请DeepSeek API密钥：打开浏览器，在搜索引擎中搜索“DeepSeek API”，找到DeepSeek官方API文档。文档中提供了API密钥（API key）的申请链接

（通过该密钥，你可以按token使用量付费的方式调用DeepSeek大模型服务）（这个密钥通常保存在代码的.env配置文件中，与密码一样需要保密。为了防止泄密，

要在.gitignore文件中设置，确保.env文件不会被上传到GitHub等代码仓库），如图7-13所示。

图7-13 找到DeepSeek官方API文档

（2）充值。API密钥申请成功后，进行充值即可启用DeepSeek优化提示词的功能，以实现Promptyoo-0。使用量不大的话，充值50元能用好几个月。

（5）选择Agent模式，并搭配Claude Sonnet 3.5大模型。

（6）输入提示词。将代码清单7-6中的提示词复制并粘贴到Ask Copilot输入框中。值得注意的是，在Agent模式下输入“”时，仅会显示一个“clear”选项（打

开一个新的聊天对话，与后面将要介绍的New Chat快捷键等效），不同于Ask模式中可提供多种智能操作选项。

代码清单7-6 listings/L7-6.md

#file:rule-architecture.md是本项目的架构描述。作为Node.js专家，请参考该架构描述中的后端技术栈在 2025 年的最佳实践，在backend目录下创建一个Node.js后端应用。该后端需要支持frontend目录下

的React前端应用 #codebase 调用，并通过后端向DeepSeek API发送请求。调用DeepSeek API的Node.js 示例代码见后文。

同时，请修改前端代码实现以下功能：当用户点击“Optimize prompt”按钮时，前端将App.tsx文件中 template变量的内容通过Node.js后端发送给DeepSeek。发送前，需清空UI右侧最下方“Optimized

prompt”下的所有内容。收到DeepSeek回复后，将回复内容显示在“Optimized prompt”下方。

如果DeepSeek长时间未响应，则在“Optimized prompt”下方显示“DeepSeek 没有响应”。

请将DeepSeek API key（值为 sk-bxxx）保存在backend/.env文件中。以下是调用DeepSeek API的 Node.js示例代码：（略，见图7-13）

（7）提交并处理。在Agent模式下的聊天输入框中按回车键提交提示词。Copilot 将提示词发送给所搭配的Claude大模型处理。由于使用了Agent模式且提示词中包

含#codebase，Copilot开始自动阅读代码库中的相关源文件，并自动分步执行操作。首先，它创建“backend/src”目录，并提供“Continue”按钮供确认。点击

“Continue”按钮后，Copilot自动打开内置终端执行创建目录命令。接着它要进入backend目录并执行npm init -y命令（快速初始化一个新的Node.js项目，且接

受所有默认值以跳过交互式问答环节），同样提供“Continue”按钮供确认。整个过程就这样循环往复地进行。

在执行过程中，当Copilot检测到内置终端出现命令错误时，它会自动提供修复命令并等待你点击“Continue”按钮确认。修复完成后，它会通知成功并询问是否继

续。其间，它会创建.env文件来存储敏感的DeepSeek API密钥（因为项目根目录的.gitignore文件已设置忽略.env文件，所以密钥只会保存在本地，不会提交到

Git版本库导致泄密）。Copilot会列出所有修改过的文件供查看，并通过“Keep”

图7-14 在Agent模式中生成后端代码

更新.env文件中的DEEPSEEK_API_KEY为实际密钥后，我点击了“Keep”按钮和 “Continue”按钮。随后，Copilot开始生成前后端的集成代码。虽然有些代码对

我来说比较陌生，但我仍大致浏览了每处更新，并通过点击“Keep”按钮和 “Continue”按钮确认。

（8）运行并测试：代码生成完成后，Copilot指示我启动后端和前端应用进行测试。当我点击“Continue”按钮启动后端应用时，新打开的内置终端提示

server.ts文件第19行运行时报错：“src/server.ts:19:27 - error TS2769: No overload matches this call.”（src/ server.ts:19:27 - 错误 TS2769：没有

与此调用匹配的函数重载）。Copilot没有察觉到这个问题，转而让我在另一个内置终端启动前端应用。前端应用虽然成功启动，但当我访问前端服务器并点击前端

界面的“Optimize prompt”按钮时，页面果然显示错误提示：“Error: Failed to optimize prompt. Please try again.”（错误：优化提示词失败。请重

试）。

7.6.3 修复运行错误与@terminal

由于需要修复后端应用在内置终端中的运行错误，我需要使用@terminal这个聊天参与者。但因为Agent模式不支持这个聊天参与者，所以我切换回了Ask模式。

根据错误消息可以确定问题在server.ts文件中。为了让Copilot能够准确定位和修改出错的代码，我先在Copilot中打开了这个文件（若不打开，Copilot会提示需要

随后，我选中了终端中显示的错误消息，这样就可以用#terminalSelection聊天变量来引用这段内容。接着，我输入了代码清单7-7所示的提示词。

代码清单7-7 listings/L7-7.md

@terminal /explain 请解释后端运行错误 #terminalSelection Copilot给出了完整的解决方案，其中包含了修改server.ts文件的具体建议和相应的代码片段。当我点击代码

片段左上角的“Apply to”按钮时，Copilot直接定位到了需要修改的代码位置，并以对比形式清晰展示了修改内容，然后通过“Keep”按钮等待我确认修改，如图

7-15所示。

修改代码后，我在内置终端输入命令npx ts-node src/server.ts重新启动后端来验证修复效果，仍然报错。这次我不再从终端选择错误消息，而是直接向Copilot

输入了一个精简的提示词，如代码清单7-8所示。

代码清单7-8 listings/L7-8.md

@terminal /explain #terminalLastCommand

这个提示词只包含了聊天参与者@terminal、智能操作/explain（当输入/explain 时，Copilot会自动添加@terminal前缀）和聊天变量#terminalLastCommand（用于

引用终端中最后执行的出错命令）。这种简洁的方式让修复终端错误变得更加高效，避免了编写冗长的提示词和手动选择错误消息。

Copilot又发现了一些问题并给出了解决方案。我按照经典的氛围编程方式处理：

快速浏览它的解释，点击“Apply to”按钮应用更改，检查代码对比后点击 “Keep”按钮确认。这次重启后端时问题仍然存在。

按照相同的氛围编程处理运行错误的方法，我又与Copilot进行了两轮问答。终于，当我再次启动终端时，不再出现错误提示，而是显示出了令人欣慰的“Server

is running on port 3000”（服务器正在端口3000上运行）成功信息。

7.6.4 点按钮无反应与Ask模式下的/fix

我可能高兴得太早了。在另一个终端启动前端并通过链接访问页面后，我发现点击 “Optimize prompt”按钮毫无反应。看来还需要让Copilot帮忙解决这个问题。

由于后端运行错误已经修复完毕，我通过New Chat快捷键（在macOS/Windows/ Ubuntu系统上都用“Ctrl+L”）开启了一个全新的对话（这样可以避免受上一个对

话上下文的影响），然后选择Ask模式。

运行后端应用时使用终端有一个重要优势：可以通过终端查看详细的运行时日志，获取更丰富、更准确的错误消息，这比前端界面显示的简单错误提示要有用得多。

因此，在新的聊天对话中，我加入了与日志（log）相关的提示词来请求Copilot修复问题，如代码清单7-9所示。

代码清单7-9 listings/L7-9.md

终端里运行“npm run dev”来运行前端。我用浏览器访问前端，点击“Optimize prompt”按钮后，界面没有反应。请你查看 #codebase，并在后端server.ts代码里增加打印日志功能，以便在我点击

“Optimize prompt”按钮后，能在后端的终端里看到后端访问DeepSeek API的日志。

这个提示词结合了/fix操作（用于让@workspace这位聊天参与者修复问题）和 #codebase聊天变量。

修改成功！我按照Copilot提供的代码更新了server.ts文件并重新运行。点击 “Optimize prompt”按钮后，稍等片刻（因为需要等待DeepSeek API的响应，此

时可以在Visual Studio Code里切换到运行后端应用到内置终端里查看日志），页面上便显示出了DeepSeek优化后的提示词，如图7-16所示。

图7-16 成功获得了DeepSeek优化后的提示词

后端终端中也同时显示了相应的操作日志，如图7-17所示。

在前端界面看到DeepSeek API成功返回优化后的提示词，标志着Promptyoo-0的基本功能已经完成。

图7-17 后端终端中显示出日志

从上述修复问题的经历可以看出，影响使用氛围编程解决问题效率的因素主要有以下3点。

（1）软件开发知识的深度。例如，了解DeepSeek API密钥的安全性要求后，就能引导Copilot将其存储在.env文件中，并通过.gitignore文件排除.env，防止敏感

信息被纳入版本控制。同样，理解日志在调试过程中的重要性，也能恰当地指导 Copilot添加必要的日志功能。

（2）对氛围编程工具功能的掌握程度。例如，当了解到可以在Copilot内置终端运行程序，并善用聊天参与者、智能操作和聊天变量这些提示词缩略语来简化提示词

后，遇到终端运行错误时，就能够使用简洁的像@terminal /explain #terminalLastCommand这样的提示词来准确定位并解决问题。

为例，解决按钮无反应的提示词专注于这一个具体问题，保持了原子化的粒度。此外，提示词在要求“在后端server.ts代码里增加打印日志功能”之后，还明确说

明了目的：以便在我点击“Optimize prompt”按钮后，能在后端的终端里看到后端访问DeepSeek API的日志。这种明确目的的方式能够帮助Copilot更准确地解决

问题。

虽然Promptyoo-0已经实现了提示词优化功能，但目前优化后的提示词需要等待 DeepSeek API完整响应后才会一次性显示，这导致用户等待时间较长，体验不够理

想。那么，如何实现7.1节中提到的流式响应功能——从DeepSeek API获取一部分结果就立即显示，实现逐字显示的效果呢？

7.7 实现流式响应功能与Exclude Files

由于实现流式响应需要同时修改前后端代码，且我不确定具体需要修改哪些文件，我决定使用Copilot的Agent模式并结合使用聊天变量#codebase来帮我自动定位并

修改相应的文件。

这时我遇到了一个新问题。为了方便读者获取从bolt下载的前端代码，我将其保存在本书配套代码的ch07-copilot-feat/frontend-by-bolt-only目录中，这个目录

与frontend和backend目录并列。frontend目录中的代码是在frontend-by-boltonly的基础上逐步添加新功能而来。当我不做任何处理地在提示词中使用

#codebase时，它必然会包含frontend-by-bolt-only目录中的源代码。这些代码与 frontend目录中的代码重复，我不希望Copilot读取frontend-by-bolt-only目录下

的内容。那么该如何解决这个问题呢？（相信你在进行氛围编程时也会遇到类似情况，即不希望氛围编程工具读取和修改某些特定代码。）

查阅了Copilot的官方文档后，我找到了解决方案。在Visual Studio Code设置中屏蔽该目录即可。具体操作是：打开Visual Studio Code的“settings”，搜索

“files.exclude”。在出现的设置页面中，找到“Files: Exclude”和“Search:

Exclude”两项设置。分别点击这两个设置下的蓝色“Add Pattern”按钮，将 “frontend-by-bolt-only”添加进去。完成后，点击Visual Studio Code左侧边

栏上方的“EXPLORER”，就会发现frontend-by- bolt-only目录已从文件树中消失。

解决了这个问题后，我开始着手让Copilot实现流式响应功能。首先，我确认选中了Agent模式，并打开了ch07-copilot-feat/rules/rule-architecture.md文件

（这一步很重要，因为如果不打开该文件，在提示词中输入#file时的下拉菜单中将无法找到它）。然后，我输入了下面的提示词，并特别注意确保提示词中的

确识别了这些提示词缩略语。

#file:rule-architecture.md 是本项目的架构描述。请你基于这个架构描述，修改前后端代码 #codebase，使得点击“Optimize prompt”按钮后，DeepSeek API 返回的优化后提示词能以流式响应

（streaming response）的方式，逐字呈现在用户界面的“Optimized prompt”区域下方，同时在后端运行的终端中显示相应的流式响应日志。

按回车后，Copilot开始分析。它首先复述了我的需求，然后仔细阅读前后端代码，确定了需要修改的关键文件——后端的server.ts和前端的App.tsx。在阅读完

架构描述后，Copilot制定了清晰的实施计划：理解架构设计、改造后端支持流式响应、更新前端处理流式数据，最后优化UI实现逐字显示效果。随后它开始执行计

划，除了修改server.ts和App.tsx，还更新了tailwind.config.js文件，总共进行了13处改动。我通过上下箭头快速查看了这些修改。最后，Copilot建议执行cd

~/my-copilot/backend && npm start命令，并等待我点击“Continue”按钮确认。

我先通过点击“Keep”按钮保存了所有代码修改，然后点击“Continue”按钮执行命令。但这条命令执行时出现了下面的错误。

npm ERR! Missing script: "start"

我之前一直使用npm run dev来运行后端，但这次执行npm start时出错了。为了弄清楚这两个命令的区别，我切换到Ask模式，向Copilot提出了以下问题。

请解释“npm run dev”和“npm start”各自的特点、优势、劣势和适用场景。

我从Copilot那里得知，原来npm start命令用于运行优化后的编译代码，主要用于生产环境部署。而npm run dev命令则直接运行TypeScript代码且无须预编译，更

适合本地开发时实时查看代码变更。我运行npm start时报错，是因为我还没有正确配置这个命令。由于在本地开发环境运行已经能满足当前需求，因此暂时无须修

复这个错误。

我分别在两个Visual Studio Code内置终端中使用npm run dev启动前端和后端应用。当点击用户界面的“Optimize prompt”按钮后，优化后的提示词开始在界面

上流畅地逐字显示，同时后端终端也打印出了相应的日志——流式响应功能已经成功实现。

【避坑指南】在氛围编程时遇到AI提示的命令运行错误时，是否都需要修复？

Web应用阶段，使用npm run dev是合理的选择。但是，由于我没有明确告诉 Copilot当前处于开发阶段，它建议使用适用于生产环境的npm start命令。这个命

令在开发阶段并不合适。因此，当遇到AI建议的命令运行失败时，不要急于修复错误，而应该先理解该命令的用途，评估它是否适合当前场景，再决定是否需要修

复。

受限于篇幅，我暂不解决npm start命令的报错问题。有兴趣的读者可以尝试在Ask 模式中使用@terminal /explain #terminalLastCommand提示词来修复这个问题。

如果需要长期维护Promptyoo-0的代码，每次修改生产代码时，不仅要编写或更新相应的自动化测试，验证自动化测试的有效性（参见第8章），还需要对所有新生

成的代码（包括生产代码和测试代码）进行评审，以提高代码的可维护性。下面一起来体验如何使用Copilot进行代码评审。

7.8 用“Review and Comment”评审代码

对于需要长期维护的代码来说，代码评审是防止代码质量下降的关键措施。在开始评审之前，尤其是当你还不太熟悉React和Node.js而使用氛围编程开发Promptyoo-

0这样的Web应用时，可以参考6.7节先绘制一张软件架构图，明确各模块与源文件的对应关系。这样才能准确识别需要重点评审的代码。

使用Copilot评审backend/src/server.ts文件的代码非常简单：只需用快捷键（在 macOS系统上用“Cmd+A”，在Windows/Ubuntu系统上用“Ctrl+A”）选中该文件的

所有代码，点击鼠标右键，选择Copilot，然后选择“Review and Comment”选项即可。

令我惊讶的是，Copilot回复称“Reviewing your code did not provide any feedback”（评审代码后没有发现任何问题），这表示它没有任何反馈意见。它在

下方用小字说明，只会在非常确定时才提供反馈，以避免给用户带来不必要的干扰。这表明这段代码的质量很高，没有明显需要改进的地方。

于是我打开前端frontend/src/App.tsx文件，用快捷键选中该文件的全部代码，按照上述相同方法让Copilot评审。Copilot给出了9条改进建议，每条建议都包含简

明的改进理由，并提供了代码改动的对比视图。更便利的是，每条建议下方都有 “Apply”按钮，点击后即可在对应位置自动完成代码修改。

我选择了一个改进点，点击“Apply”按钮修改了代码，随即进行完整测试：运行相应的前端单元测试，并分别启动前后端应用进行手工端到端测试，以验证提示词

化结果的情况下，才能确认这次代码评审带来的变更没有影响原有功能。

Promptyoo-0极简版的提示词优化功能至此已经完成。不过，如果你想在此基础上继续使用氛围编程来实现更多功能（例如提示词优化历史管理和支持中文用户界面

的i18n国际化），你可能会陷入“进一步，退两步”的困境。这究竟是怎么回事？

又该如何避免呢？