4 篇文章带有标签 “prompt”

研究对象是 WorkBuddy 桌面客户端的安装包——更准确地说，是它解包后的 resources/ 与 cli/ 两个目录。我们想知道两件事：

（1）对话时「我」到底由什么拼成？ （2）「我」能调用哪些模型、这些模型又从哪来？

答案出人意料地干净：它们分别落在两套声明式配置文件里——提示词模板库与产品配置文件。你此刻正在阅读的「我」，本质上就是这两套文件在运行时的一次实例化。

0. 为什么值得写

平时我们用 AI 助手，关注的是「它能不能帮我干活」。但如果你想知道「它是怎么被造出来的」，安装包本身就是最好的教材：没有编译混淆、没有黑盒，所有「性格」「能力边界」「可用武器」都白纸黑字写在那里。

这次我们顺着两条主线往下挖：

• 主线 A —— 大脑（提示词模板）：resources/templates/ 下的 19 个文件（约 2400 行），决定了「我是谁、能做什么、如何行动」。
• 主线 B —— 武器库（模型配置）：cli/product*.json 下的 5 个文件，声明了「我能调用哪些模型、怎么路由、怎么计费」。

一、主线 A：提示词模板体系（"我"的大脑）

1.1 三层结构

resources/templates 不是一堆散落的提示词，而是一套以「角色」为主轴、以「模式」为运行时约束的模板工程体系，基于 Jinja2 风格语法（{{ var }} 占位符 + {% if

一、目录总览

resources/templates/ 共包含 15 个模板文件，组织为 4 个功能层级 + 1 个风格库：

Introduction简介

Model Context Protocol (MCP) 入门

MCP 是一个开放协议，用于标准化应用程序向 LLM 提供上下文的方式。可以将 MCP 视为 AI 应用程序的 USB-C 端口。正如 USB-C 提供了一种将设备连接到各种外围设备和配件的标准化方式一样，MCP 提供了一种将 AI 模型连接到不同数据源和工具的标准化方式。

为什么选择 MCP？

MCP 帮助您在 LLM 之上构建代理和复杂的工作流程。LLM 经常需要与数据和工具集成，而 MCP 提供了：

• 越来越多的预构建集成，您的 LLM 可以直接插入
• 在 LLM 提供商和供应商之间切换的灵活性
• 在您的基础设施中保护数据的最佳实践

一般架构

MCP 的核心遵循客户端-服务器架构，其中主机应用程序可以连接到多个服务器：

config.yaml Reference

简介

Continue hub 助手使用 config.yaml 规范定义。本地助手也可以通过放置在全局 .continue 文件夹中的 YAML 文件 config.yaml 进行配置（Mac 上为 ~/.continue，Windows 上为 %USERPROFILE%\.continue）

:::info Config YAML 替代了 config.json。查看迁移指南。 :::

一个助手由以下部分组成：

1. 顶级属性，用于指定助手的 name、version 和 config.yaml 的 schema
2. 块列表，这些是可组合的编码助手构建块数组，可供助手使用，如模型、文档和上下文提供者。

块是编码助手的一个独立构建块，例如一个模型或一个文档来源。在 config.yaml 语法中，块包含与助手相同的顶级属性（name、version 和 schema），但在其所属的块类型下只有一个项目。

可以在 Continue hub 上找到块和助手的示例。

助手可以显式定义块（参见下面的属性），也可以导入和配置现有的 hub 块。

使用块

Hub 块和助手通过格式为 owner-slug/block-or-assistant-slug 的标识符识别，所有者可以是用户或组织。

可以通过在块类型下添加 uses 子句将块导入到助手中。