聊聊如何高效利用聊天AI进行编程实践

作者 | Enrico Piccinin

译者 | 马可薇

开发者的新工作流程

自2021年夏季GitHub Copilot首次推出预览版以来，编程助手工具迎来了爆发式增长。起初，这些工具主要被视为增强型代码补全工具，而后，Cursor、Windsurf等产品迅速转变为Agent交互模式：通过自然语言指令，助手可以自主完成修改代码、运行终端命令等操作。

最近，GitHub Copilot在其聊天功能中引入了“Agent模式”，用户可以让Agent代为执行各种任务。这一新功能再次证明了Agent领域的快速发展。然而，这种“Agent模式”与GitHub平台（如github.com网站或GitHub CLI）上可用的“编程Agent”并不相同，后者能够独立处理GitHub issues等任务。

在本文中，我们将探讨Agent如何改变软件开发的面貌以及开发者的工作流程将如何演变。为了直观地展示这一新型工作流程，我们将利用GitHub Copilot中的“Agent模式”来构建一个能够搜索维基百科文章并将结果以列表形式展示的简单Angular应用，暂时称之为“维基页面搜索应用”。

应用构建目标

我们将首先进行“一键式”构建，只需向Agent发送一个提示，然后再进行更明确的构建。

一键式构建应用

“维基页面搜索应用”的设计十分简单，功能和用途可以通过简短的提示来概括。虽然Angular的技术细节并不是说明Agent如何影响开发者工作流程的关键，但开发者仍需掌握必要的技术细节，并在编写任务提示时提供相关信息。

我们向GitHub Copilot Agent提出的完整应用构建提示如下：

生成一个Angular应用，该应用能够查询Wikipedia API以获取与搜索词匹配的文章，并将结果以列表形式展示。该应用应包含一个搜索栏，用户可以在其中输入搜索词。当用户点击搜索按钮时，应用应调用Wikipedia API并以列表格式显示结果。列表中的每个项目都应包含文章标题和简要描述。应用还应妥善处理错误情况，在未找到结果或API调用出错时显示相应的提示信息。使用Angular Material作为UI组件，并确保应用具有响应式设计，能够在桌面和移动设备上良好运行。应用应采用模块化结构，将搜索栏和结果列表作为独立组件。遵循Angular开发最佳实践，包括使用服务处理API调用，以及使用Observables处理异步数据。

选择大模型引擎至关重要

GitHub Copilot的“Agent模式”允许用户选择所使用的LLM（大语言模型）。我们的实验表明，LLM引擎的选择至关重要，必须强调这一观点，以避免将LLM视为普通商品的误解——这些模型之间的差异绝非仅仅是技术爱好者的闲聊话题。实际上，GitHub Copilot通过下拉菜单让开发者简单选择模型的设计，反而可能加深这种误解。不同的LLM具有差异化且持续演进的能力，这将直接影响开发成本和输出结果。

为验证这一点，我们使用了两个不同模型来测试相同的提示：Anthropic的“Claude Sonnet 4”和OpenAI的“o4-mini（预览版）”。尽管这两个模型都被视为强大，但其特性和能力截然不同。“Claude Sonnet 4”拥有超过1500亿参数，经过专门针对编码任务的微调；而“o4-mini（预览版）”则是仅有80亿参数的小型模型，旨在作为通用型AI。因此，二者的输出结果存在显著差异，这并不令人意外——这种多样性正是当前LLM领域的本质特征，我们必须重视这一点。

使用o4-mini（预览版）的测试结果

在使用OpenAI的“o4-mini（预览版）”模型时，GitHub Copilot agent未能成功构建可运行的功能；初始生成的代码存在多处错误，导致无法通过编译。

接着我们与Agent进行了多轮调试对话，尝试修正这些错误。经过多次迭代，测试被迫终止：一方面是错误不断出现，更为重要的是，即便我们具备Angular开发经验，仍然难以理解Agent解决方案的设计思路，其代码逻辑也显得相当晦涩。对此感兴趣的读者可以查看本次实验生成的代码。

使用Claude Sonnet 4的测试结果

Claude Sonnet 4的表现截然不同。首轮生成的代码能够正常运行，无需任何迭代或手动干预。这个解决方案设计得干净利落，采用了模块化结构，项目文件夹层次分明。

我们甚至要求它生成架构图，该Agent不仅输出了精美的Mermaid图表，还附带了设计关键要素的详细说明。对此感兴趣的读者可以查看本次实验生成的代码。

部分Claude Sonnet 4生成的数据流图

关于“掌控力”的缺失

尽管通过 Claude Sonnet 4 驱动的编程代理生成了高效的解决方案和详尽的文档，我仍然深感“掌握能力的不足”。为了确保架构图的准确性，我必须逐行检查代码，并与生成的图表和文档进行核对。换句话说，若想真正理解代理的输出，我们需要对代码进行反向解析，以确保所有文档的真实可靠。

这一过程并非多余。开发者最终仍需对 AI 所生成的代码承担责任，因此验证过程显得尤为关键，它帮助我们深入理解代理代码的实现机制。

这一情形与团队协作绘制架构图或撰写文档有相似之处，核心的区别在于信任机制。在团队合作中，我们会逐渐对某些成员建立信任，通常他们的产出会被直接采纳。然而，对于存在幻觉问题的代理以及 LLM（即使是最先进的模型也难以避免），盲目信任的风险极大。因此，我们必须对 AI 的所有输出进行仔细审查。

引导式策略

采用架构师的思维

为了掌握开发的主导权，我们可以尝试另一种方法：首先设计解决方案的整体结构，然后制定实施计划，将任务拆分为多个小步骤。换句话说，这与传统的应用架构师的工作方式相似。只有在实施计划准备妥当后，我们才会要求代理逐步执行每个环节以构建应用。对于感兴趣的读者，可以查看本案例的解决方案设计与实施计划。

明确代理的最佳实践

作为合格的架构师，我们需要清晰地定义代理应遵循的最佳实践。这些最佳实践可能涉及命名规范、代码风格、设计模式以及使用的工具等。

GitHub Copilot 提供了一种方便的方式来定义这些最佳实践，通过“指令文件”将这些规范自动嵌入每条发送给代理的消息中。我们甚至能够借助像 ChatGPT 这样的标准聊天机器人，通过生成式 AI 帮助我们制定全面的最佳实践清单。

在这个案例中，我们要求代理编写详尽的测试用例，确保所有视图具备无障碍访问，并使用 JSDoc 标准为最复杂的代码段提供清晰的注释。这些指令的效果非常显著。感兴趣的读者可以查看我们在此次实践中使用的详细指令。

团队层面分享并践行最佳实践

将最佳实践定义在指令文件中还带来了有趣的附加效果：这些规范可以作为项目交付物的一部分。因此，定义好的最佳实践可以在项目代码库中进行版本控制，并在所有开发者之间共享。只要团队成员利用代理进行协作，这一机制便有助于在整个项目的贡献者中贯彻集中定义的最佳实践。

构建应用

在确定了实施计划和最佳实践后，便可开始应用构建。我们按以下步骤进行：

• 将构建计划的每个步骤转换为发送给代理的提示。

• 在代理执行每条提示后检查其工作成果，只要确保每个步骤简单且变更不大，代理生成的代码就容易理解和验证。

• 我们还可以与代理进行对话，要求其对当前步骤的实现进行解释或修改。

• 在对当前步骤的结果满意后，我们提交变更以建立一致性节点，然后再继续下一步。

通过这样逐步构建应用，我们能够始终掌控整体的开发过程。

与代理的工作流程

这种开发方式能够创造出高质量的应用程序，因为受我们“指令”文件控制的代理通常会遵循最佳实践。根据我们的实际经验：

• 代理编写了全面的测试套件，涵盖了多个边界场景。

• 代理在每个 HTML 模板中都考虑了无障碍访问支持，这类工作我们往往需要耗费大量时间才能完成。

• 代理使用 JSDoc 标准为代码中最重要的部分添加了清晰的注释。

综上所述，我们仅用四个步骤便构建出了可运行的应用程序，整个过程仅使用了四个提示词，并且每次调用“Claude Sonnet 4”时都能在一次尝试内获得预期的结果。

维基搜索应用

感兴趣的读者可以查看每一步的具体描述、使用的提示，以及每一步中生成的代码。

模型选择的重要性

正如我们之前所强调的，选择合适的模型至关重要。我们尝试使用相同的引导方法和相似的提示序列来测试其他 LLM。当我们使用 GPT-4.1 时，代理生成的应用基本上可以直接运行（唯一的问题是一些导入路径错误），但质量稍有欠缺。例如，应用未能遵循 Material Design 规范（指令中有明确要求），也没有处理“回车键”事件。此外，无障碍访问功能在首次生成时也未实现。

速度并非唯一考量

通过这种引导式方法，我们仅用四条提示就创建出一个功能完善的应用，内含全面的测试套件和众多高质量特性。整个过程最多只需几个小时，甚至可能更短。与传统开发方式相比，这样的速度令人惊叹——毕竟在传统模式下，开发者在编写代码前还需查阅大量技术细节，例如维基百科的 API 文档或最新的 Angular 最佳实践指南。

优化开发流程：Agent与人机协作的未来

显然，有人可能会认为我们能够更迅速地完成任务——通过单一的提示要求 Agent 创建整个应用程序。然而，核心在于我们宁愿牺牲部分效率，以换取真正符合我们需求的解决方案。换句话说，尽管用单条提示生成完整应用的速度可能更快（某些 Agent 确实能做到这一点），但我们的目标并不仅仅是“制作一个应用”，而是要实现“符合设计理念、便于理解和维护”的产品。毕竟，最终我们需要对其进行长期的维护和迭代。虽然设计应用架构和实施方案确实需要一定的时间，但这能够确保最终成果是可控的，易于管理和维护。即便如此，这一过程依然比传统的手动编码方式快得多。

结论

Agent 可以成为开发者手中的一项强大工具，尤其是在高效的 LLM 驱动下。它们能够加快开发流程，完成一些我们容易忽视的任务（例如测试），并且能够严格遵循我们设定的规范和最佳实践。然而，这种强大的能力也伴随着失控的风险——我们可能会获得能够运行但难以理解的解决方案，甚至可能因过于依赖而放松了监管。值得注意的是，生成式 AI 有时会产生“幻觉”，这是一种重大隐患。假设 AI 永远不会出错，仅仅依赖一个我们无法理解的解决方案，就已经存在风险。

为了在充分发挥 Agent 效能的同时保持对其的控制，我们可以采用人机协作的工作流程：由经验丰富的人类架构师负责设计和规划阶段，明确解决方案及其实施路径，而编码的具体工作则交由高效且优质的 Agent 来完成。

我们必须承认，实验设计非常简单。我们也意识到，从零开始开发新应用与维护一个复杂且通常混乱的代码库是截然不同的挑战。然而，实验结果依旧令人振奋，它清晰地指引出一条与 Agent 协同工作的优化路径——这种方式能够同时提升效率和质量。

经验的重要性

若想掌控 Agent 的工作成果，经验显得尤为关键。经验使我们能够设计出出色的解决方案，规划有效的实施方案，并具备判断 AI 生成内容的能力。在这个 Agent 承担主要编码工作的时代，我们应如何积累这样的经验？这是一个更为深刻的问题，也适用于许多涉及生成式 AI 工具的智力活动。这个问题的答案或许尚待探讨，但无论如何，这超出了本文的讨论范围。

技术细节

在 VSCode 中使用 GitHub Copilot Agent

在本节中，我们将讨论如何在 VSCode 中访问 Agent 功能。

GitHub Copilot Agent 已经集成在 GitHub Copilot 的聊天界面中。通过该界面，用户可以选择 Agent 模式以及其背后使用的 LLM 引擎。

在 VSCode 中的 GitHub Copilot Agent

通过聊天界面，我们可以让 Agent 为我们完成任务，例如构建前面提到的“维基搜索应用”。

方案设计与实施

在这种基于 Agent 的工作流程中，我们首先需要设计解决方案，然后列出实现所需的任务（即确定实施方案），这是任何优秀架构师在开始编写代码前必做的工作。

“维基搜索应用”的设计方案

在实施方案中，我们采用自下而上的开发方式：首先构建连接外部系统的服务层，然后在此基础上开发视图层。为了简化实现，此应用将直接处理状态管理。

以下是我们构建“维基搜索应用”的计划：

• 创建 WikiService 服务类，添加搜索方法作为 API 接口，用于获取维基百科文章数据

• 开发 WikiCard 展示组件，以卡片形式呈现单篇维基百科文章。该组件将被 WikiList 组件调用，用于构建文章网格布局

• 实现 WikiListComponent 主组件来管理全部文章列表，直接集成搜索框和搜索按钮，将搜索按钮的点击事件与 WikiService 搜索 API 绑定，以 WikiCardComponents 网格形式展示搜索结果

• 应用初始化配置，设置 WikiList 作为应用启动时的默认加载页面

实施方案的步骤与相关提示

以下是逐步实施方案（包含各阶段代码库状态链接及对应提示）：

1. 创建 WikiService 服务

创建 WikiService 并为其添加一个方法，作为根据给定搜索词获取维基百科文章的 API。使用维基百科提供的最新 API。同时为此 API 添加测试，测试中不要使用 mock，而要使用真实 API。

第一步提示执行后的代码状态

2. 开发 WikiCard 组件

创建 WikiCard 组件，这是一个在列表中以卡片形式显示单篇维基百科文章的组件。维基百科文章是由 WikipediaSearchResult 接口描述的对象，其将被 WikiList 组件用来构建检索到的文章网格。

第二步提示执行后的代码状态

3. 创建 WikiListComponent

构建功能强大的 WikiList 组件

首先，WikiList 组件旨在以卡片的形式展示维基百科文章的列表。这个组件将与 WikiCard 组件配合，负责呈现列表中的每一篇文章。

此外，WikiList 还设有搜索框，用户可以通过输入关键词来查找特定文章。组件中还包含一个按钮，用户点击后能够从维基百科 API 获取相关的文章信息。这个按钮的事件将触发 WikiService 以获取所需的文章数据。

接下来的步骤是将 WikiList 设置为应用启动时的默认页面。这意味着在应用打开时，用户将直接看到这个组件。

在构建过程中，我们需要遵循一些明确的指令和最佳实践，以确保代码的质量和可维护性。这些指导原则如下：

- 应用 Angular v19 的特性和语法- 尽量使用独立的组件和服务提供者- 启用 TypeScript 严格模式以及 Angular 严格模板- 按功能模块化代码，分别存放于`src/app/components`、`src/app/pages`和`src/app/services`文件夹- 使用 Angular CLI 创建组件、服务和模块- 遵循 RxJS 的最佳实践，尽量避免手动管理订阅，模板中应使用`async`管道- 利用 Angular Forms（不论是响应式还是模板驱动）来处理用户输入- 若需设计系统，推荐使用 Angular Material 作为用户界面组件库- 针对所有组件、服务和管道，编写单元测试，使用 Jasmine 和 TestBed- 文件、类和选择器的命名需清晰且具描述性- 遵循 Angular 和 TypeScript 的风格指南进行格式化和命名- 用 JSDoc 注释对公共 API 和复杂逻辑进行说明- 避免在模板中包含逻辑，保持其声明性和简单性- 不使用内联模板或样式，使用外部文件来维护- 对服务和配置使用依赖注入机制- 优先使用 Observables 处理异步操作，而非 Promises- 保持组件小巧并专注，必要时将逻辑提取至服务中- 使用环境文件进行配置管理- 通过 Angular 内置的路由和守卫实现导航和访问控制- 确保所有用户界面组件的可访问性 (a11y)- 采用 ESLint 和 Prettier 工具确保代码质量和格式化- 使用"npx ng .."命令运行 Angular CLI，以保证版本的正确性- 在代码文件末尾标注"code generated by AI"- 测试时始终使用"npx ng test --browsers=ChromeHeadless --watch=false --code-coverage=false"命令

我们从指令中可以看到，明确的规范对于代码质量控制是至关重要的。比如，要求为每个组件、服务和管道编写单元测试的指令得到了严格执行。此外，确保所有用户界面组件具备可访问性的要求也得到了遵循。

更进一步地，针对命令行的指令，例如“测试时始终使用 npx ng test…”也被准确落实。这些例子充分表明，团队能够严格遵循既定的指令，从而保持项目的一致性和高质量。

最后，谈到元提示技术（meta-prompting），由于指令内容常常依赖于项目的类型，我们可以采取更为务实的方法：首先要求 LLM 根据项目类型（如 React 前端应用或 Go 应用）生成初步的指令模板，然后再依据具体需求进行个性化调整。这种“通过提示生成提示”的策略，可以有效构建出符合项目特性的基础框架。

原文链接：

https://www.infoq.com/articles/effective-practices-ai-chat-based-coding/

声明：本文为 InfoQ 翻译，未经许可禁止转载。

今日好文推荐