力成文学:合理安排时间,就等于节约时间。——培根

HVE Core:把 GitHub Copilot 从“会写代码”升级成“能带团队干活”的提示工程框架

你可能见过两种 Copilot 使用方式:

  1. 随手问一句:帮我写个函数、改个 bug、加个测试。
  2. 认真做一件事:改 12 个文件、跨 3 个服务、还要符合团队约定与安全规范。

第一种 Copilot 往往表现惊艳;第二种就容易出现熟悉的翻车:代码看起来很对、甚至能编译,但细节不对齐项目约定,最后“越帮越忙”。

microsoft/hve-core 这套仓库想做的事很明确:把 Copilot 的“聪明”变成可重复、可验证、可团队化的工程生产力——��的不是玄学,而是一套“约束 + 工件 + 工作流”的体系。

仓库 description 说得很直接:它是一套 Hypervelocity Engineering 组件集合(instructions、prompts、agents、skills),用于让项目开局更顺,或把现有项目升级到能“更好地用 Copilot”。

1
2
3
description: Hypervelocity Engineering prompt library for GitHub Copilot with constraint-based AI workflows and validated artifacts
...
Hypervelocity Engineering (HVE) Core is an enterprise-ready prompt engineering framework for GitHub Copilot. Constraint-based AI workflows, validated artifacts, and structured methodologies that scale from solo developers to large teams.

1. HVE Core 到底是什么:不是“提示词合集”,是一套可落地的 Copilot 定制框架

在文档索引里,它给自己的定义更“工程味”:

  • 面向团队规模落地的 GitHub Copilot 提示工程框架

  • 提供 specialized agents、可复用 prompts、instruction sets

  • 带有校验流水线(validation pipeline),用 JSON schema 强制约束工件结构

  • 把 AI 相关内容分成明确的 artifact ��型,并用边界来防止“越界发挥/跑偏”

    1
    HVE Core is a prompt engineering framework for GitHub Copilot designed for team-scale adoption. It provides specialized agents, reusable prompts, instruction sets, and a validation pipeline with JSON schema enforcement. The framework separates AI concerns into distinct artifact types with clear boundaries, preventing runaway behavior through constraint-based design.

如果用一句更贴近体验的话来说:
HVE Core 不负责“让 Copilot 更会写”,它负责让 Copilot 更少瞎写、更像团队的一员。


2. HVE Core 的核心性格:约束式工作流(Constraint-based)+ 产出工件(Artifacts)而不是只聊天

HVE Core 很强调一个结果:AI 的价值不应该只停留在对话里,而应该落在“可保存、可交接、可复用”的产物上。

比如 Getting Started 的教程里,第一件事就让你和 memory agent 说句话,然后它会在你的 workspace 里创建一个真实文件(memories/ 下面),而且后续别的 agent 会读它。

1
2
3
4
5
6
1. Open GitHub Copilot Chat (`Ctrl+Alt+I`).
2. Select the **memory** agent from the agent picker.
3. Type this prompt:
> Remember that I am a [your role] and I'm learning HVE Core for the first time.
...
4. The agent responds and creates a file in your workspace under `memories/`.

这种设计非常“像项目同事”:不只是回答问题,而是留下证据与上下文,让协作和复盘变得容易。


3. 让复杂任务不再“凭感觉写”:RPI 工作流(Research → Plan → Implement → Review)

HVE Core 在 README 和 RPI 文档里反复强调:复杂任务失败的根源之一,是 AI 分不清“调查”和“实现”。

于是它给出了一个明确的结构:RPI(Research / Plan / Implement / Review)。文档把它描述成一种“类型转换管线”:

Uncertainty → Knowledge → Strategy → Working Code → Validated Code

1
2
3
The RPI (Research, Plan, Implement, Review) workflow transforms complex coding tasks into validated solutions through four structured phases. Think of it as a type transformation pipeline:

> Uncertainty → Knowledge → Strategy → Working Code → Validated Code

3.1 RPI 为什么有效?它把“胡编”变成“查证”

在 “Why the RPI Workflow Works” 里,它讲得很直白:
没有约束时,AI 会优先产出“看起来合理”的东西;而 RPI 的关键是限制 AI 在某个阶段不能做某些事,让它的优化目标从“ plausible code ”变成 “ verified truth ”。

1
2
3
4
AI coding assistants are brilliant at simple tasks...
The issue is that "plausible" and "correct" aren't the same thing.
...
The solution isn't teaching AI to be smarter. It's preventing AI from doing certain things at certain times.

3.2 四个阶段四种分工:让 AI 也“只做自己该做的事”

RPI 的四个阶段对应不同 agent,每个阶段都有产出物和边界。比如 Task Planner 会输出固定结构的 planning artifacts:

1
2
3
4
5
6
7
8
Task Planner creates two files:

```text
.copilot-tracking/
├── plans/
│ └── {{YYYY-MM-DD}}-<topic>-plan.instructions.md
└── details/
└── {{YYYY-MM-DD}}-<topic>-details.md
1
2
3
4
5
6
Task Reviewer 则会输出 review log:  
```markdown name=docs/rpi/task-reviewer.md url=https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/docs/rpi/task-reviewer.md#L31-L48
Task Reviewer creates a review log at:

```text
.copilot-tracking/reviews/{{YYYY-MM-DD}}-<topic>-review.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
这套结构的好处在于:你不会把“相信 AI”当成流程的一部分;你把“证据与审计”变成流程的一部分。

---

## 4. HVE Core 包含什么:Agents / Prompts / Instructions / Skills + 校验体系 + 插件生态

从架构文档看,HVE Core 把自己的组成讲得非常系统:

- Extension(VS Code 扩展):把这些工件接进 Copilot 体验里
- Scripts(PowerShell 自动化):lint / security / plugin generation
- Documentation:角色指南、架构说明、贡献指南
- GitHub 资产(.github):工作流、指令、prompt、agents、skills
- MCP 配置(.vscode/mcp.json):模型上下文协议相关
- Plugins(plugins/):从 collection manifests 生成的 Copilot CLI 插件输出
```markdown name=docs/architecture/README.md url=https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/docs/architecture/README.md#L10-L44
HVE Core provides a Copilot customization framework ...
...
| Scripts | `scripts/` | PowerShell automation for linting, security validation, and plugin generation |
| Plugins | `plugins/` | Generated Copilot CLI plugin output from collection manifests |

4.1 生成插件不是手工活:一条命令跑完整流水线

Build system 文档里明确写了 plugin generation pipeline,并给出命令:

1
2
3
4
Run the full pipeline with a single command:

```bash
npm run plugin:generate
1
2
3
4
并且强调:`plugins/` 下的文件是生成物,不要直接改。  
```markdown name=docs/customization/build-system.md url=https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/docs/customization/build-system.md#L26-L33
Files under `plugins/` are generated output. Do not edit them directly.
Changes made to plugin files are overwritten on the next generation run.

4.2 “验证”不是一句口号:schema 直接卡住工件格式

同一篇文档里还讲了 schema validation system:frontmatter 用 JSON schema 验证,映射规则在仓库里有专门的 mapping。

1
2
3
4
YAML frontmatter in markdown files is validated against JSON schemas stored in
`scripts/linting/schemas/`.
...
The `scripts/linting/schemas/schema-mapping.json` file defines the glob-to-schema mapping.

这就是 HVE Core 的气质:把“约束”写进系统,而不是写进团队 wiki。


5. 安装与上手:30 秒把它放进你的 Copilot 里

README 里的 Quick Start 把流程压得很短:

  1. 安装:VS Code 扩展(Marketplace)或 Copilot CLI plugin(文档里也有)

  2. 验证:打开 Copilot Chat,agent picker 里能看到 task-researcher / task-planner / rpi-agent

  3. 试用:选择 memory agent,说一句“记住我在探索 HVE Core”,它就会在 workspace 产出 memory 文件

    1
    ### 2. Verify

Open GitHub Copilot Chat (Ctrl+Alt+I) and check that HVE Core agents appear in the agent picker. Look for task-researcher, task-planner, and rpi-agent.

3. Try It

Select the memory agent and type:

Remember that I’m exploring HVE Core for the first time.

1
2
3
4
5
6
如果你更偏 CLI 插件路线,仓库里也给了实际可用的安装命令示例,比如 GitHub Backlog Management 插件:  
```markdown name=plugins/github/README.md url=https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/plugins/github/README.md#L1-L12
## Install

```bash
copilot plugin install github@hve-core
1
2
3
4
5
6
Azure DevOps 集成插件也是同样风格:  
```markdown name=plugins/ado/README.md url=https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/plugins/ado/README.md#L7-L13
## Install

```bash
copilot plugin install ado@hve-core
1
2
3
4
5
6
7
8
9
10
11
12
---

## 6. 给你一段“能直接抄走的”体验脚本:从聊天到工件,从工件到流程

这一段不是编故事,而是把仓库文档里散落的动作串成一条更顺的路。

### 6.1 第一次见面:让 memory 记住你的角色

打开 Copilot Chat → 选 memory agent → 输入(按教程):

```text
Remember that I am a software engineer and I'm learning HVE Core for the first time.

你会看到 workspace 里出现 memories/ 下的文件(文档明确说明会生成)。

6.2 进入 RPI:让复杂任务“先查证,再动手”

文档强调一个关键规则:阶段之间要 /clear,让不同 agent 的约束不互相污染。

1
2
3
🔴 **Always use `/clear` or start a new chat between phases.**
...
Task Researcher → /clear → Task Planner → /clear → Task Implementor → /clear → Task Reviewer

你可以把它当成“团队交接”的标准动作:
研究交给研究的人,计划交给计划的人,实现交给实现的人,验收交给验收的人。


7. 工程化的背面:脚本、lint、安全检查,一样不少

如果你打算把 HVE Core 当作团队资产(而不是个人工具),scripts/ 目录就是它的“纪律系统”:

  • linting:Markdown frontmatter 校验、链接检查、YAML lint、PSScriptAnalyzer

  • security:依赖 pinning、SHA staleness、供应链安全

  • plugins:生成与校验 Copilot CLI 插件
    (来源:scripts 目录说明)

    1
    2
    3
    4
    5
    6
    This directory contains PowerShell scripts for automating linting, validation, and security checks ...
    ...
    | `Validate-MarkdownFrontmatter.ps1` | Validate YAML frontmatter in markdown files |
    ...
    | `Test-DependencyPinning.ps1` | Validate dependency pinning compliance |
    | `Test-SHAStaleness.ps1` | Check for outdated SHA pins |

安全脚本甚至直接给出使用方式,比如依赖 pinning 检查:

1
2
3
4
5
6
7
8
9
```powershell
# Scan all workflows with table output
./scripts/security/Test-DependencyPinning.ps1 -Recursive

# Export SARIF results
./scripts/security/Test-DependencyPinning.ps1 -Format sarif -OutputPath logs/pinning.sarif

# Fail CI when unpinned dependencies exist
./scripts/security/Test-DependencyPinning.ps1 -FailOnUnpinned -Recursive

这部分很像一个可靠的“合规同事”:不参与创作,但永远在确保你交付的东西能长期运行。

---

## 8. 入口链接(直接开逛)

- 仓库:https://github.com/microsoft/hve-core  
- 文档站:https://microsoft.github.io/hve-core/  
- README(本文引用版本):https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/README.md  
- 文档索引:https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/docs/README.md  
- RPI 工作流:https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/docs/rpi/README.md  
- 为什么 RPI 有效:https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/docs/rpi/why-rpi.md  
- Build System / 插件生成与校验:https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/docs/customization/build-system.md  
- GitHub 插件示例:https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/plugins/github/README.md  
- ADO 插件示例:https://github.com/microsoft/hve-core/blob/d2060d644d83e213bfd2fa5e7373f8103727592b/plugins/ado/README.md