如何使用智能体基元和上下文工程构建可靠的AI工作流

许多开发者从简单的提示词开始探索AI。也许您也是这样开始的：打开GitHub Copilot，用自然语言提问，然后期待可用的输出。这种方法适用于简单的修复和代码建议，但随着需求变得复杂或工作更加协作，您需要更可靠的策略。

本指南将介绍一个三部分框架，将这种临时性的AI实验转变为可重复且可靠的工程实践。其核心是两个概念：智能体基元（可重用、可配置的构建块，使AI智能体能够系统化工作）和上下文工程（确保AI智能体始终关注正确信息）。熟悉这些概念后，您将能够构建不仅能够独立编码，而且能够可靠、可预测且一致地执行的AI系统。

AI原生开发框架

Markdown提示工程 + 智能体基元 + 上下文工程 = 可靠性

无论您是AI原生开发的新手，还是希望为智能体工作流带来更深层次的可靠性，本指南都将为您提供构建、扩展和共享随着每次使用而学习和改进的智能系统所需的基础。

亲自尝试：使用GitHub Copilot CLI构建和运行智能体工作流

直接从终端让智能体基元变得生动起来。新的GitHub Copilot CLI允许您在本地运行、调试和自动化AI工作流——无需设置脚本，不会丢失上下文。它通过GitHub MCP直接连接到您的仓库、拉取请求和问题，为智能体提供与IDE中相同的上下文。

什么是智能体基元？

下面的三层框架将临时AI实验转变为可靠、可重复的过程。它通过结合Markdown的结构；智能体基元的力量（为AI智能体提供清晰指令和能力的简单构建块）；以及智能上下文管理（使智能体始终获得正确信息，而不仅仅是更多信息）来实现这一点。

第1层：使用Markdown进行更战略性的提示工程

我们之前写过提示工程的重要性。但您需要知道的是：提示越清晰、越精确、上下文越丰富，结果就越好、越准确。这就是Markdown的用武之地。通过Markdown的结构（标题、列表和链接），您可以自然地引导AI的推理，使输出更加可预测和一致。

为了为提示工程提供坚实的基础，请尝试以下以Markdown为指导的技术：

• 上下文加载：查看现有模式。在这种情况下，链接成为上下文注入点，从文件或网站拉取相关信息。
• 结构化思考：使用标题和项目符号为AI创建清晰的推理路径。
• 角色激活：使用诸如“您是[此角色]的专家”之类的短语。这会触发专业知识领域，并聚焦AI的响应。
• 工具集成：使用MCP tool tool-name。这使您的AI智能体能够在MCP服务器上以受控、可重复和可预测的方式运行代码。
• 精确语言：通过具体指令消除歧义。
• 验证门：“停止并获取用户批准”。确保在关键决策点始终有人类监督。

例如，不要说“查找并修复错误”，而是使用以下内容：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

您是一位专业的调试专家，专门调试复杂的编程问题。

您特别擅长调试这个项目，其架构和特性可以参考[架构文档](./docs/architecture.md)。

请遵循以下步骤：

1. 查看[错误日志](./logs/error.log)并确定根本原因。

2. 使用`azmcp-monitor-log-query` MCP工具从Azure检索基础设施日志。

3. 找到根本原因后，思考3个具有权衡的潜在解决方案

4. 向用户展示您的根本原因分析和建议的解决方案（含权衡），并在继续修复之前寻求验证 - 不要更改任何文件。

一旦您熟悉了结构化提示，您很快就会意识到为每个任务手动制作完美提示是不可持续的。（谁有时间？）这就是第二步的用武之地：将您的提示工程见解转化为可重用、可配置的系统。

第2层：智能体基元：部署您的新提示工程技术

现在是时候更系统地实施您所有的新策略，而不是临时提示。这些可配置的工具将帮助您做到这一点。

核心智能体基元

在AI原生开发中，核心智能体基元指的是一个简单、可重用的文件或模块，为智能体提供特定的能力或规则。

以下是一些例子：

• 指令文件：通过具有目标范围的模块化.instructions.md文件部署结构化指导。在GitHub，我们提供自定义指令，为Copilot提供仓库特定的指导和偏好。
• 聊天模式：通过具有MCP工具边界的.chatmode.md文件部署基于角色的专业知识，防止安全漏洞和跨域干扰。例如，专业许可防止架构师构建，工程师规划。
• 智能体工作流：通过具有内置验证的.prompt.md文件部署可重用的提示。
• 规范文件：通过.spec.md文件创建可立即实施的蓝图，确保可重复的结果，无论工作是由人还是AI完成。
• 智能体记忆文件：通过.memory.md文件跨会话保存知识。
• 上下文助手文件：通过.context.md文件优化信息检索。

使用核心智能体基元如何改变提示及其结果

• 技术：使用Markdown提示工程，您的提示可以是：“实现安全的用户认证系统”
• 基元：您将选择后端开发聊天模式 → 通过applyTo: "auth/**"自动触发security.instructions.md → 从先前认证模式和API安全标准加载上下文 → 使用结构化模板生成user-auth.spec.md → 使用验证门执行implement-from-spec.prompt.md工作流。
• 结果：开发者驱动的知识积累，您在.memory.md中捕获实施失败，在.instructions.md中记录成功模式，并在.prompt.md文件中改进工作流——通过您的迭代改进创建复合智能。

这种转变可能看起来很复杂，但请注意模式：从一个临时请求变成了一个具有清晰交接点、自动上下文加载和内置验证的系统化工作流。

当您使用这些文件和模块时，您可以不断调整和改进AI智能体在每一步的工作方式。每次迭代，您都使智能体更加可靠和一致。这不仅仅是随机的试错——您正在遵循一个结构化的、可重复的方法，帮助您在每次使用AI时获得更好、更可预测的结果。

原生VS Code支持：虽然VS Code原生支持.instructions.md、.prompt.md和.chatmode.md文件，但此框架通过.spec.md、.memory.md和.context.md模式更进一步，解锁了AI驱动软件开发的更多令人兴奋的可能性。

随着提示结构化和智能体基元设置完成，您可能会遇到一个新的挑战：即使是最好的提示和基元，在面对无关上下文或竞争有限的AI注意力时也可能失败。第三层，我们接下来将讨论，通过战略上下文管理来解决这个问题。

第3层：上下文工程：帮助AI智能体专注于重要事项

就像人一样，LLMs具有有限的内存（上下文窗口），有时可能会健忘。如果您能战略性地给予它们上下文，您可以帮助它们专注于相关内容，并使它们能够更快地开始工作。这有助于它们保留宝贵的上下文窗口空间，并提高其可靠性和有效性。

以下是一些确保它们获得正确上下文的技术——这被称为上下文工程：

• 会话分割：为不同的开发阶段和任务使用不同的智能体会话。例如，一个会话用于规划，一个用于实施，一个用于测试。如果智能体有新鲜的上下文，它将有更好的专注力。对于复杂任务，拥有新鲜的上下文窗口总是更好的。
• 模块化和自定义规则及指令：通过目标.instructions.md文件使用applyTo YAML前置语法仅应用相关指令。这为实际工作保留上下文空间，并减少不相关的建议。
• 记忆驱动开发：通过.memory.md文件利用智能体记忆，跨会话和时间维护项目知识和决策。
• 上下文优化：战略性地使用.context.md上下文助手文件，加速信息检索并减少认知负荷。
• 认知焦点优化：使用.chatmode.md文件中的聊天模式，将AI的注意力保持在相关领域，防止跨域干扰。更少的上下文污染意味着更一致和准确的输出。

智能体工作流：完整系统在行动

既然您理解了所有三层，您可以看到它们如何结合成智能体工作流——完整的、系统化的过程，其中所有智能体基元协同工作，理解您的提示，并仅使用它们需要的上下文。

这些智能体工作流可以实现为.prompt.md文件，将多个智能体基元协调成过程，设计为无论是在本地IDE、终端还是CI管道中执行都能工作。

需要回顾吗？

• Markdown提示工程为可预测的AI交互提供了结构基础。
• 智能体基元是您可配置的工具，用于扩展和系统化这些技术。
• 上下文工程在内存限制内优化AI认知性能。
• Markdown中的智能体工作流应用提示和上下文工程，利用智能体基元实现完整、可靠的智能体过程。
• 此框架创建复合智能，随着您继续迭代而改进。

工具化：如何扩展智能体基元

既然您理解了三层框架，并且智能体基元本质上是使用自然语言编写的可执行软件，问题是：如何将这些Markdown文件扩展到您个人的开发工作流之外？

自然语言作为代码

答案反映了每个编程生态系统的演变。就像JavaScript从浏览器脚本演变为使用Node.js运行时、包管理器和部署工具一样，智能体基元需要类似的基础设施才能充分发挥其潜力。

这不仅仅是一个比喻：这些.prompt.md和.instructions.md文件代表了一种真正的新型软件开发形式，需要适当的工具化基础设施。

我们的意思是：将您的智能体基元视为真实的软件片段，只是用自然语言而不是代码编写。它们具有所有相同的品质：您可以将复杂任务分解为较小的部分（模块化），在多个地方使用相同的指令（可重用性），依赖其他工具或文件（依赖性），不断改进和更新它们（演化），并在团队之间共享它们（分发）。

也就是说，您的自然语言程序将需要与任何其他软件相同的基础设施支持。

智能体CLI运行时

大多数开发者首先在VS Code中使用GitHub Copilot创建和运行智能体基元，这对于交互式开发、调试和改进日常工作流是理想的。然而，当您想要超越编辑器——自动化工作流、调度它们或将它们集成到更大的系统中时——您需要像Copilot CLI这样的智能体CLI运行时。

这些运行时允许您从命令行执行智能体基元，并利用高级模型能力。这种转变解锁了自动化、扩展和无缝集成到生产环境中，将您的自然语言程序从个人工具转变为强大的、可共享的解决方案。

内循环与外循环

• 内循环（VS Code和GitHub Copilot）：交互式开发、测试和工作流改进
• 外循环（智能体CLI运行时）：可重复执行、CI/CD集成和生产部署

智能体CLI运行时将您的智能体基元从IDE绑定的文件转变为独立可执行的工作流，在任何环境中一致运行。它们提供命令行执行、CI/CD集成、环境一致性以及对MCP服务器的原生支持，将您的开发工作连接到生产现实。

TL;DR：使用内循环进行快速、交互式工作，使用外循环进行可靠、可重复的自动化和部署。

运行时管理

虽然VS Code和GitHub Copilot处理个体开发，但一些团队可能希望额外的基础设施来共享、版本控制和产品化其智能体基元。管理多个智能体CLI运行时可能很快变得复杂，具有不同的安装程序、配置要求和兼容性矩阵。

APM（智能体包管理器）通过提供统一的运行时管理和包分发来解决这个问题。APM处理复杂性，同时保留您现有的VS Code工作流，而不是手动安装和配置每个供应商CLI。

以下是运行时管理在实践中如何工作：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 一次性安装APM
curl -sSL https://raw.githubusercontent.com/danielmeppiel/apm/main/install.sh | sh

# 可选：设置您的GitHub PAT以使用GitHub Copilot CLI
export GITHUB_COPILOT_PAT=your_token_here

# APM为您管理运行时安装
apm runtime setup copilot          # 安装GitHub Copilot CLI
apm runtime setup codex            # 安装OpenAI Codex CLI

# 安装MCP依赖（如npm install）
apm install

# 将智能体基元文件编译为Agents.md文件
apm compile

# 针对您选择的运行时运行工作流
# 这将触发'copilot -p security-review.prompt.md'命令
# 检查本指南稍后的示例apm.yml文件
apm run copilot-sec-review --param pr_id=123

如您所见，您的日常开发在VS Code中保持完全相同，APM自动安装和配置运行时，您的工作流无论安装哪个运行时都能运行，并且相同的apm run命令在所有运行时上一致工作。

分发和打包

当您想要与团队共享或将它们部署到生产环境时——当您开始需要诸如包管理、依赖解析、版本控制和分发机制之类的东西时——智能体基元与传统软件的相似性变得最为明显。

挑战在于：您已经在VS Code中构建了强大的智能体基元，您的团队想要使用它们，但分发Markdown文件并确保跨不同环境的一致MCP依赖变得繁琐。您需要相当于npm的自然语言程序。

APM提供了这个缺失的层。它不取代您的VS Code工作流——它通过创建智能体基元的可分发包（包括依赖、配置和运行时兼容性）来扩展它，团队可以共享，就像npm包一样。

实践中的包管理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 初始化新的APM项目（如npm init）
apm init security-review-workflow

# 本地开发并测试您的工作流
cd security-review-workflow 
apm compile && apm install
apm run copilot-sec-review --param pr_id=123

# 打包分发（未来：apm publish）
# 与团队共享apm.yml和智能体基元文件
# 团队成员可以安装并使用您的基元
git clone your-workflow-repo
cd your-workflow-repo && apm compile && apm install
apm run copilot-sec-review --param pr_id=456

好处迅速复合：您可以将测试过的工作流作为版本化包分发，包括依赖；自动解析和安装所需的MCP服务器；跟踪工作流演进并在更新中保持兼容性；基于（并贡献）社区的共享库；并确保每个人运行相同的东西。

项目配置

以下apm.yml配置文件作为智能体基元的package.json等效物，定义脚本、依赖和输入参数：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# apm.yml - 项目配置（如package.json）
name: security-review-workflow
version: 1.2.0
description: 具有GitHub集成的全面安全审查过程

scripts:
  copilot-sec-review: "copilot --log-level all --log-dir copilot-logs --allow-all-tools -p security-review.prompt.md"
  codex-sec-review: "codex security-review.prompt.md"
  copilot-debug: "copilot --log-level all --log-dir copilot-logs --allow-all-tools -p security-review.prompt.md"
  
dependencies:
  mcp:
    - ghcr.io/github/github-mcp-server

有了这个，您的智能体基元现在可以作为具有管理依赖的可分发软件打包。

生产部署

工具化生态系统的最后一部分实现了持续AI：打包的智能体基元现在可以在您每天使用的相同CI/CD管道中自动运行，将您精心开发的工作流带入生产环境。

使用APM GitHub Action，并基于上述安全审查工作流包示例，以下是相同的APM项目如何通过多运行时灵活性部署到生产环境：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# .github/workflows/security-review.yml
name: AI安全审查管道
on: 
  pull_request:
    types: [opened, synchronize]

jobs:
  security-analysis:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        # 映射到apm.yml脚本
        script: [copilot-sec-review, codex-sec-review, copilot-debug]  
    permissions:
      models: read
      pull-requests: write
      contents: read
    
    steps:
    - uses: actions/checkout@v4
    
    - name: 运行安全审查 (${{ matrix.script }})
      uses: danielmeppiel/action-apm-cli@v1
      with:
        script: ${{ matrix.script }}
        parameters: |
          {
            "pr_id": "${{ github.event.pull_request.number }}"
          }
      env:
        GITHUB_COPILOT_PAT: ${{ secrets.COPILOT_CLI_PAT }}

关键连接：matrix.script值（copilot-sec-review、codex-sec-review、copilot-debug）精确对应于上面apm.yml配置中定义的脚本。APM自动安装MCP依赖（ghcr.io/github/github-mcp-server）并将输入参数（pr_id）传递给您的security-review.prompt.md工作流。

这之所以重要是因为：

• 自动化：您的AI工作流现在自行运行，无需任何人手动触发它们。
• 可靠性：它们以与传统代码部署相同的一致性和可重复性运行。
• 灵活性：您可以根据需要运行不同版本或类型的分析（映射到不同的脚本）。
• 集成：这些工作流成为您组织标准CI/CD管道的一部分，就像常规软件质量检查一样。

这种设置最终意味着您的智能体基元不再只是本地实验——它们是完全自动化的工具，您可以依赖作为软件交付过程的一部分，在CI/CD中根据需要运行，所有依赖和参数都为您管理。

生态系统演变

这种进展遵循每个成功编程生态系统的相同可预测模式。理解这种模式有助于您看到AI原生开发的方向，并战略性地定位您的工作。

演变发生在四个阶段：

1. 原始代码 → 智能体基元（.prompt.md、.instructions.md文件）
2. 运行时环境 → 智能体CLI运行时
3. 包管理 → APM（分发和编排层）
4. 繁荣的生态系统 → 共享库、工具和社区包

就像npm通过解决包分发问题实现了JavaScript的爆炸性增长一样，APM通过提供使共享和扩展自然语言程序实用的缺失基础设施层，使智能体基元生态系统得以繁荣。

这种转变是深刻的：从编辑器中的单个Markdown文件开始，变成了具有适当工具化、分发和生产部署能力的系统化软件开发实践。

关键要点

• 智能体基元是软件：您的.prompt.md和.instructions.md文件代表了可执行的自然语言程序，值得专业的工具化基础设施。
• 运行时多样性实现规模：智能体CLI运行时提供了将开发连接到生产的执行环境。
• 包管理至关重要：APM提供了使智能体基元真正可移植和可共享的npm等效层。
• 今天即可投入生产：此工具化堆栈使AI工作流能够在CI/CD管道中以企业级可靠性自动化运行。
• 生态系统增长模式：包管理基础设施为共享工作流、工具和社区库的繁荣生态系统创建了基础。

如何开始构建您的第一个智能体基元

现在是时候构建您的第一个智能体基元了。以下是计划：

1. 从指令开始：编写清晰的指令，准确告诉AI您希望它做什么以及它应该如何行为。
2. 添加聊天模式：设置特殊规则（聊天模式）为AI创建安全边界，确保它以您希望的方式交互并避免不需要的行为。
3. 构建可重用提示：为您经常执行的任务创建提示模板，这样您就不必每次都从头开始。这些模板帮助AI快速且一致地处理常见工作。
4. 创建规范模板：制作模板，帮助您规划希望AI实现的目标，然后将这些计划转化为AI可以遵循的可操作步骤。

指令架构

指令构成了可靠AI行为的基础：它们是在不干扰您即时上下文的情况下指导智能体的规则。与其在每个对话中重复相同的指导，指令将您团队的知识直接嵌入到AI的推理过程中。

关键洞察是模块化：不是一个大而全的指令文件应用于所有地方，您可以创建目标文件，仅在处理特定技术或文件类型时激活。这种上下文工程方法使您的AI保持专注，您的指导保持相关。

快速操作：

• 在.github文件夹中创建通用的copilot-instructions.md文件，用于仓库的通用规则。
• 在.github/instructions/文件夹中按领域（前端、后端、测试、文档、规范…）创建模块化的.instructions.md文件。
• 使用applyTo: "**/*.{js,ts...}"模式进行选择性应用。

工具和文件：

1
2
3
4
5
6

.github/
├── copilot-instructions.md          # 全局仓库规则
└── instructions/
    ├── frontend.instructions.md     # applyTo: "**/*.{jsx,tsx,css}"
    ├── backend.instructions.md      # applyTo: "**/*.{py,go,java}"
    └── testing.instructions.md      # applyTo: "**/test/**"

示例： 在frontend.instructions.md中使用Markdown提示工程的指令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

---
applyTo: "**/*.{ts,tsx}"
description: "具有上下文工程的TypeScript开发指南"
---
# TypeScript开发指南

## 上下文加载
在开始之前查看[项目约定](../docs/conventions.md)和[类型定义](../types/index.ts)。

## 确定性要求
- 使用严格的TypeScript配置
- 为React组件实现错误边界
- 一致地应用ESLint TypeScript规则

## 结构化输出
生成代码包含：
- [ ] 所有公共API的JSDoc注释
- [ ] `__tests__/`目录中的单元测试
- [ ] 适当索引文件中的类型导出

检查点：指令是上下文高效且无冲突的。

聊天模式配置

有了指令架构，您仍然需要一种方法来强制执行域边界，防止AI智能体超越其专业知识。聊天模式通过创建类似于现实世界许可的专业边界来解决这个问题。例如，您希望您的架构师规划桥梁而不是自己建造它。

以下是设置这些边界的方法：

• 使用MCP工具边界定义特定领域的自定义聊天模式。
• 封装每个模式的技术栈知识和指南。
• 为您的聊天模式定义最合适的LLM模型。
• 配置安全的MCP工具访问，防止跨域安全漏洞。

通过MCP工具边界实现安全：每个聊天模式仅接收其领域所需的特定MCP工具。给予每个聊天模式仅需要的工具，保持AI工作流安全、有组织且专业分离——就像现实世界的角色和权限一样。

工具和文件：

1
2
3
4
5
6

.github/
└── chatmodes/
    ├── architect.chatmode.md             # 规划专家 - 设计，不能执行
    ├── frontend-engineer.chatmode.md     # UI专家 - 构建接口，无后端访问
    ├── backend-engineer.chatmode.md      # API专家 - 构建服务，无UI修改
    └── technical-writer.chatmode.md      # 文档专家 - 编写文档，不能运行代码

示例： 使用backend-engineer.chatmode.md创建MCP工具边界：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

---
description: '专注于安全的后端开发专家'
tools: ['changes', 'codebase', 'editFiles', 'runCommands', 'runTasks', 
        'search', 'problems', 'testFailure', 'terminalLastCommand']
model: Claude Sonnet 4
---
您是一位专注于安全API开发、数据库设计和服务器端架构的后端开发专家。您优先考虑安全优先的设计模式和全面的测试策略。

## 领域专业知识
- RESTful API设计和实现
- 数据库模式设计和优化
- 认证和授权系统
- 服务器安全和性能优化

您通过阅读所有[后端文档](../../docs/backend)掌握了这个项目的后端。

## 工具边界
- **可以**：修改后端代码、运行服务器命令、执行测试
- **不可以**：修改客户端资源

您还可以创建安全和专业边界，包括：

• 架构师模式：仅允许访问研究工具，因此它们不能执行破坏性命令或修改生产代码。
• 前端工程师模式：仅允许访问UI开发工具，因此它们不能访问数据库或后端服务。
• 后端工程师模式：仅允许访问API和数据库工具，因此它们不能修改用户界面或前端资源。
• 技术写手模式：仅允许访问文档工具，因此它们不能运行代码、部署或访问敏感系统。

检查点：每个模式都有清晰的边界和工具限制。

智能体工作流

智能体工作流可以实现为可重用的.prompt.md文件，将所有基元编排成系统化的、可重复的端到端过程。这些可以在本地执行或委托给独立的智能体。以下是开始的方法：

• 为完整的开发过程创建.prompt.md文件。
• 内置强制性人工审查。
• 设计工作流，既用于本地执行，也用于独立委托。

工具和文件：

1
2
3
4

.github/prompts/
├── code-review.prompt.md           # 带有验证检查点
├── feature-spec.prompt.md          # 规范优先方法
└── async-implementation.prompt.md  # GitHub编码智能体委托

示例： 使用feature-spec.prompt.md的完整智能体工作流：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

---
mode: agent
model: gpt-4
tools: ['file-search', 'semantic-search', 'github']
description: '带有验证门的特性实现工作流'
---
# 从规范实现特性

## 上下文加载阶段
1. 查看[项目规范](${specFile})
2. 分析[现有代码库模式](./src/patterns/)
3. 检查[API文档](./docs/api.md)

## 确定性执行
使用语义搜索查找类似实现
使用文件搜索定位测试模式：`**/*.test.{js,ts}`

## 结构化输出要求
创建实现包含：
- [ ] 在适当模块中的特性代码
- [ ] 全面的单元测试（>90%覆盖率）
- [ ] API端点的集成测试
- [ ] 文档更新

## 人工验证门
**停止**：在继续代码生成之前审查实现计划。
确认：架构对齐、测试策略和破坏性变更影响。

检查点：如您所见，这些提示包括明确的验证门。

规范模板

在规划（想出需要构建什么）和实施（实际构建它）之间常常存在差距。如果没有清晰、一致的方式来记录需求，事情可能会在传递中丢失，导致错误、误解或遗漏步骤。这就是规范模板的用武之地。这些模板确保人和AI智能体都能接受一个概念（如新特性或API）并可靠地实施它。

这些模板帮助您完成以下任务：

• 标准化过程：您为每个特性、API端点或组件创建新规范。
• 提供实施蓝图：这些规范包括开发者（或AI智能体）开始构建所需知道的一切：问题、方法、所需组件、验证标准和交接清单。
• 使交接具有确定性：通过遵循标准，从规划到实施的过渡清晰且可预测。

工具和文件： Spec-kit是一个简洁的工具，完全实现了规范驱动的智能体编码方法。它允许您轻松开始创建规范（spec.md）、实施计划（plan.md）并将其拆分为实际任务（tasks.md），供开发者或编码智能体处理。

检查点：规范在委托之前被拆分为可立即实施的任务。

准备好了吗？以下是快速入门清单

您现在有了系统化AI开发的完整基础。下面的清单贯穿实施序列，逐步构建以创建完整的智能体工作流。

概念基础

• 理解Markdown提示工程原则（语义结构、精确性和工具）。
• 掌握上下文工程基础（上下文窗口优化和会话策略）。

实施步骤

1. 使用基本项目指南创建.github/copilot-instructions.md（上下文工程：全局规则）。
2. 使用applyTo模式设置特定领域的.instructions.md文件（上下文工程：选择性加载）。
3. 为您的技术栈领域配置聊天模式（上下文工程：域边界）。
4. 创建您的第一个.prompt.md智能体工作流。
5. 为特性规范构建您的第一个.spec.md模板（您可以使用spec-kit完成此操作）。
6. 使用会话分割练习规范驱动的方法：先规划，拆分为任务，最后实施。

带走这个

使用AI智能体不应该是不可预测的。通过正确的规划和工具，这些智能体可以迅速成为您工作流和过程中可靠的一部分——不仅提高您自己的生产力，也提高团队的生产力。

准备好进入多智能体协调委托的下一阶段了吗？尝试GitHub Copilot CLI开始吧 >