5 篇文章带有标签 “prompt”

WorkBuddy Prompt 模板文件

本文件研究了 /Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked/resources/templates 目录下的全部 *.tpl 模板(12个文件),每个文件作为独立章节,原文(含 Jinja 占位符与 XML 标签)原样保留在代码块中。 基于你提供的 WorkBuddy Prompt 模板文件,以下是其整体架构与各模板关系的思维导图(Mermaid 格式):

mindmap
  root((WorkBuddy Prompt 模板))
    分类与概览
      共12个模板
      分类:模式提醒 / 系统提醒 / 身份上下文 / 主Prompt
      主Prompt分4个场景:Ask·编码 / Ask·通用 / Craft·编码 / Craft·设计 / 专家·编码 / 专家·通用 / 通用Craft
    模式提醒片段
      ask-mode-reminder
        Ask模式硬性规则:只读·不编辑·不运行命令
        建议切换至Craft
      craft-mode-reminder
        Craft模式能力激活:可自由编辑与创建文件
        直接执行任务
    系统提醒片段
      system-reminder
        占位标签
        运行时由系统注入提醒
    身份上下文模板
      user-context-expert-identity
        专家模式身份注入
        含BOOTSTRAP.md / USER.md
        聚焦产品身份与语气占位
      user-context-identity
        通用身份注入
        含SOUL.md / IDENTITY.md / USER.md
        用户自定义指令与语气风格覆盖
    主Prompt·Ask模式
      workbuddy-ask-prompt
        纯对话场景
        只读工具·不可编辑
        可视化工具(read_me / show_widget)
        MCP配置引导
      workbuddy-ask-coding-prompt
        Ask + 编码场景
        与ask-prompt同源
        强调代码库上下文与只读分析
    主Prompt·Craft模式
      workbuddy-prompt
        通用Craft默认主提示
        能力总览·Agent循环·结果呈现
        自动化任务与技能管理
      workbuddy-craft-coding-prompt
        Craft + 编码场景
        Agent循环·任务管理工具
        技能积累与反思(SkillManage)
        自动化(automation_update)
        可视化与多模态生成
      workbuddy-craft-design-prompt
        Craft + 设计场景
        智能设计助手角色
        画布三段式回复格式
        文生UI·截图验证
        目标节点优先原则
    主Prompt·专家模式
      workbuddy-expert-prompt
        专家模式通用(AGENTIC)
        角色覆盖·产物概览
        松弛自然沟通风格
        多模态生成与技能积累
      workbuddy-expert-coding-prompt
        专家 + 编码场景
        与expert-prompt同源
        聚焦编码任务与产物交付

该图清晰呈现了:

  • 4 大类模板(模式提醒、系统提醒、身份上下文、主 Prompt)
  • 7 种主 Prompt 场景(Ask 通用、Ask 编码、Craft 通用、Craft 编码、Craft 设计、专家通用、专家编码)
  • 各模板的核心定位与关键约束(只读/可编辑、身份注入、可视化、自动化、技能管理等)

模板概览

拆解 WorkBuddy:系统提示词如何拼装,模型清单如何定义

研究对象是 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

Model Context Protocol (MCP) 的核心概念和能力

Introduction简介

Model Context Protocol (MCP) 入门

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

为什么选择 MCP?

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

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

一般架构

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

flowchart LR
    subgraph "您的计算机"
        Host["带有 MCP 客户端的主机<br>(Claude、IDE、工具)"]
        S1["MCP 服务器 A"]
        S2["MCP 服务器 B"]
        S3["MCP 服务器 C"]
        Host <-->|"MCP 协议"| S1
        Host <-->|"MCP 协议"| S2
        Host <-->|"MCP 协议"| S3
        S1 <--> D1[("本地<br>数据源 A")]
        S2 <--> D2[("本地<br>数据源 B")]
    end
    subgraph "互联网"
        S3 <-->|"Web APIs"| D3[("远程<br>服务 C")]
    end
  • MCP 主机:希望通过 MCP 访问数据的程序,如 Claude Desktop、IDE 或 AI 工具
  • MCP 客户端:维护与服务器 1:1 连接的协议客户端
  • MCP 服务器:轻量级程序,每个程序通过标准化的模型上下文协议公开特定的功能
  • 本地数据源:您的计算机的文件、数据库和服务,MCP 服务器可以安全地访问
  • 远程服务:通过互联网(例如,通过 API)可用的外部系统,MCP 服务器可以连接到

Core architecture(核心架构)

了解 MCP 如何连接客户端、服务器和 LLM

continue: config.yaml Reference

config.yaml Reference

简介

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

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

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

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

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

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

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

使用块

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

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