基于聊天的 AI 编程高效实践

开发者新工作流

自 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 应用（参见 VSCode 中启用 GitHub Copilot Agent 的方法），暂称其为“维基页面搜索应用”。 

构建的应用目标

我们先尝试“一键式”构建，只向 Agent 发送一个 prompt，随后再用更具指向性的方式进行构建。

一键式构建应用

“维基页面搜索应用”非常简单，功能和用途可以通过这段简短的 prompt 来描述。需要注意的是，Angular 的技术细节虽然对说明 Agent 如何影响开发者的工作流程来说并非必要，但我们还是要清楚，即使是利用 Agent 进行开发，开发者仍需自身掌握关键技术细节，并能在编写任务 prompt 时提供这些消息。

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

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

大模型引擎的选择很重要

GitHub Copilot 的“Agent 模式”允许用户选择要使用的 LLM（大语言模型）。我们的实验表明，LLM 引擎的选择非常重要，这一观点必须要重点强调，以免陷入将 LLM 视为普通商品的误区——这些模型之间的差异绝非只是技术宅们茶余饭后的谈资。但在某种程度上，GitHub Copilot 让开发者能简单地通过下拉菜单选择模型的设计，反而可能强化了这种误解。实际上，不同 LLM 具有差异化且持续演进的能力，这将直接影响开发成本和产出结果。

为验证这一点，我们用两个不同模型测试了相同的 prompt：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 驱动的编程 Agent 产出了可运行的优质解决方案和精美的文档，我还是强烈感受到了“掌控力的缺失”。例如，为确保生成的架构图准确无误，我必须逐行核对代码，并与图表和文档进行交叉验证。本质上来说，要真正理解 Agent 的工作成果，我们不得不对代码进行逆向工程，验证所有生成文档的准确性。

然而，这一步绝非是可有可无的。因为开发者最终仍需为 AI 生成的代码负责，这种验证工作恰恰至关重要；它能帮助我们深度理解 Agent 代码的实现逻辑。

这种情况或许与同事协助绘制架构图或编写文档类似，核心差异在于信任机制。在团队协作中，我们会逐步建立对特定成员的信任，其产出通常会被直接采纳。但对于存在幻觉问题的 Agent 和 LLM（即使是最先进的模型仍无法避免这点），盲目信任风险极大。因此，我们必须审慎核查 AI 的所有产出。

引导式策略

采用架构师的思维

为了掌握开发主导权，我们可以尝试另一种方法：首先设计要构建的解决方案结构，然后制定实施计划，将任务分解为多个小步骤。换句话说，就是像传统应用架构师那样工作。只有当实施计划准备就绪后，我们才会要求 Agent 逐步执行每个步骤来构建应用。感兴趣的读者可以查看此案例的解决方案设计和实施计划。

定义 Agent 应遵循的最佳实践

作为合格的架构师，我们必须明确定义 Agent 需遵循的最佳实践。这些最佳实践可以包括命名约定、代码风格、设计模式和要使用的工具等。

GitHub Copilot 通过“指令文件”提供了一种便捷的方式来定义这些最佳实践，这些规范会自动嵌入发送给 Agent 的每条消息中。我们甚至可以使用 ChatGPT 这样的标准聊天机器人，通过生成式 AI 来帮助我们制定完善的最佳实践清单。

在这个案例中，我们指示 Agent 编写全面的测试用例，在所有视图中实现无障碍访问，并使用 JSDoc 标准为最复杂的代码段编写清晰的注释。这些指令都取得了非常好的效果。感兴趣的读者可以查看我们在这次实践中使用的详细指令。

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

将最佳实践定义在指令文件中还能带来有趣的副作用：它们可以被视为项目交付物的一部分。因此，这些定义好的最佳实践可以在项目代码库中进行版本控制，并在所有开发者之间共享。只要团队成员使用 Agent 进行协助工作，这个机制就有助于在整个项目的所有贡献者中强制执行集中定义的最佳实践。

构建应用

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

• 将构建计划的每个步骤转化为发送给 Agent 的 prompt。

• 在每次 Agent 执行 prompt 后都要检查其工作成果，只要能确保每个步骤都足够简单且改动不大，Agent 生成的代码就很容易理解和验证。

• 我们还可以与 Agent 展开对话，要求其对当前步骤的实现进行说明或修改。

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

这样一步一步地构建应用，我们始终能对整体的开发过程有掌控力。 

与 Agent 的工作流程

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

• Agent 编写了很全面的测试套件，覆盖了大量边界场景。

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

• Agent 使用 JSDoc 标准为代码中最关键的部分添加了清晰的注释。

总结来说，我们仅用四个步骤就构建出可运行的应用程序，全程只使用了四个提示词，而且每次调用“Claude Sonnet 4”作为 LLM 时都能在一次尝试内就取得了预期的结果。

维基搜索应用

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

正确的模型选择

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

速度固然重要，但也并非全部

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

当然，有人可能会说我们其实可以更快——直接用单条 prompt 要求 Agent 构建整个应用。但关键在于，我们选择牺牲了部分速度，但得到了真正符合预期的解决方案。换句话说，虽然用单条 prompt 生成完整应用可能会更快（某些 Agent 也确实具备这种能力），但我们的目标不仅是“做出一个应用”，而是做出“符合我们设计理念、便于理解维护”的应用，毕竟最终我们需要长期维护并迭代它。设计应用架构和制定实现方案确实需要时间，但这能确保最终成果完全受控、易于管理维护。即便如此，整个过程仍比传统手工编码方式快得多。

结论

Agent 可以成为开发者手中极其强大的工具，尤其是在高效 LLM 的驱动下。它们能加速开发流程，完成我们易遗漏的任务（比如测试），并且严格遵循我们设定的规范和最佳实践。但这种强大能力也伴随着失控的风险——我们可能会得到能运行但却难以理解的解决方案，甚至可能因过度信任而放松监管。要知道，生成式 AI 有时会产生“幻觉”，这是重大隐患。就算假设 AI 永远不会出错，依赖一个我们无法理解的解决方案本身就是危险的。

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

必须承认，我们的实验设计极为简单。我们也清楚，从零开发新应用与维护现有复杂（且通常会非常混乱）的代码库是截然不同的挑战。但实验结果依然令人振奋，它清晰地指明了一条与 Agent 协同工作的优化路径——这种工作方式能同时带来效率与质量的提升。

经验是关键

如果我们想要掌控 Agent 的工作成果，那么经验至关重要。经验使我们能够设计出优秀的解决方案，规划有效的实施方案，并具备判断 AI 生成内容的能力。在这个由 Agent 承担主要编码工作的时代，我们该如何积累这种经验？这是一个更深层次的问题，同样适用于这个拥有生成式 AI 工具时代下的诸多人类智力活动。这个问题的答案或许仍有待探索，但无论如何，这已超出了本文的讨论范围。

技术细节

在 VSCode 中使用 GitHub Copilot agent

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

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

VSCode 中的 GitHub Copilot Agent

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

方案设计和实施

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

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

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

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

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

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

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

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

实现方案的步骤和相关 prompt

以下是分步骤实现方案（包含各阶段代码库状态链接及对应 prompt）：

1. 创建 WikiService 服务

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

第一步 prompt 执行后的代码状态

2. 开发 WikiCard 组件

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

第二步 prompt 执行后的代码状态

3. 创建 WikiListComponent

创建WikiList组件，这是一个以卡片形式显示维基百科文章列表的组件。其将使用WikiCard组件来显示列表中的每篇文章。该组件有一个搜索字段，允许用户通过搜索词搜索文章。组件还有一个按钮，允许用户从维基百科API获取文章。按钮的点击事件应该调用WikiService来获取文章。

第三步 prompt 执行后的代码状态

4. 将 WikiList 配置为起始页

将WikiList添加为应用启动时加载的页面

第四步prompt执行后的代码状态

指令，最佳实践，以及上下文

以下是我们定义并在整个实验中要求 Agent 使用的指令：

你是一位拥有丰富 Angular v19 经验的专家级 Angular 开发者。在生成代码时，请遵循以下编码标准和最佳实践：

- 使用Angular v19特性和语法- 尽可能使用独立组件和函数提供者- 使用TypeScript严格模式并启用Angular严格模板- 按功能组织代码，使用`src/app/components`、`src/app/pages`和`src/app/services`文件夹- 使用Angular CLI生成组件、服务和模块- 遵循RxJS最佳实践：尽可能避免手动管理订阅；在模板中使用`async`管道- 使用Angular Forms（响应式或模板驱动）处理用户输入- 如果需要设计系统，使用Angular Material作为UI组件- 使用Jasmine和TestBed为所有组件、服务和管道编写单元测试- 为文件、类和选择器使用清晰、描述性的名称- 遵循Angular和TypeScript风格指南进行格式化和命名- 使用JSDoc注释记录公共API和复杂逻辑- 避免在模板中包含逻辑；保持模板声明式且简单- 不要使用内联模板或样式；使用外部文件- 对服务和配置使用依赖注入- 对于异步操作，优先使用Observables而非Promises- 保持组件专注且小巧；在适当时将逻辑提取到服务中- 使用environment文件进行配置- 使用Angular内置路由和守卫进行导航和访问控制- 确保所有UI组件都具备可访问性(a11y)- 使用ESLint和Prettier保证代码质量和格式化- 使用"npx ng .."运行Angular CLI命令以确保使用正确的版本- 在代码文件末尾写上"code generated by AI"- 运行测试时始终使用命令"npx ng test --browsers=ChromeHeadless --watch=false --code-coverage=false"

遵循 Anthropic 等机构近期发布的提示工程最佳实践，指令应以角色定义为起点，而这些指令本质上类似于多数 LLM API 中的“系统提示”。通过观察下列指令，我们发现多项规范已切实转化为 Agent 生成的代码：

• 当指令中要求“为所有组件、服务和管道编写单元测试”时，Agent 严格执行了该要求。

• “确保所有 UI 组件都具备可访问性（a11y）”的指令有被遵循（至少在 Claude Sonnet 4 为 LLM 的情况下如此）。

• “使用 JSDoc 注释记录公共 API 和复杂逻辑”的指令也如实体现在了代码中。

甚至针对 bash 命令的指令（如“测试时始终使用 npx ng test...”）也被 Agent 精准执行。

这些事实表明：Agent 会严格遵循我们给出的指令，因此精确定义规范对实施质量管控至关重要。我们应当将此类指令视为核心的项目交付物，确保全体开发者共用同一套标准，从而维持质量体系的一致性。

最后再说一下元提示技术（meta-prompting）。由于指令内容高度依赖项目类型，我们可采用比较务实的方案：先要求 LLM 根据项目类型（如 React 前端应用或 Go 应用）生成初始指令模板，再基于具体需求进行个性化定制。这种“通过 prompt 生成 prompt”的元提示策略，能高效构建出符合项目特性的基础框架。

原文链接：

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