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

与 Agent 的工作流程

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

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

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

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

总结来说，我们仅用四个步骤就构建出可运行的应用程序，全程只使用了四个提示词，而且每次调用“Claude Sonnet 4”作为 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/

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

今日好文推荐