超越“聊天”：用技能与规范工程构建智能
还记得我们曾经把所有CSS和JavaScript都塞进一个index.html文件的日子吗？如今的"超级提示词"正是如此：一个难以管理的庞然大物。
几周前，在编排Vibrisse Agent（我的本地AI代理）时，我正好撞上了这堵墙。我试图通过向一个500行的系统提示词添加指令来稳定一个复杂任务。规则加得越多，模型就越容易忘记之前的规则。
行业向我们兜售了超级提示词的神话。那些著名的"50个终极提示词"或大段咒语般的文本，在技术上是死胡同。创意写作无法在生产环境中规模化。
作为一名Web开发者，我的信念很简单：要构建可靠的应用程序，我们必须停止"对机器说话"，转而开始配置它。这就是从提示词工程到上下文工程的转变。
上下文工程：类型化与结构化
使用LLM的第一个错误是将指令（逻辑）和上下文（数据）混入非结构化的文本流中。这在认知上相当于意大利面条式代码。
解决方案？严格的关注点分离。一个非常有效的技术（由Anthropic记录，但适用于任何模型，包括本地SLM）是XML标签化。
这是"脏"方法（经典聊天）：
你是一名安全专家。分析这段认证代码，要严格，不要写摘要，检查XSS和SQLi漏洞。代码如下：function login() { ... }这是"工程化"方法：
<role>应用安全专家</role>
<instructions>
1. 分析<context>中提供的代码。
2. 识别漏洞（重点：XSS、SQLi）。
3. 不要生成介绍性摘要。
</instructions>
<context>
function login() { ... }
</context>通过标签对语言进行类型化，创建了清晰的边界。模型确切知道指令在哪里，数据在哪里。
示例的力量（少样本提示）
即使有清晰的指令，AI在输出格式或语气上仍可能偏离。这时，通过示例进行管理就派上了用场。
给AI一个预期行为的具体例子（好例子）与要避免的行为（坏例子），通常比添加15行理论指令更强大且更节省token。
只需在XML结构中添加一个示例部分：
<examples>
<example>
<input>对Button.tsx组件的审查</input>
<good_output>第42行：缺少用于无障碍的`aria-label`属性。</good_output>
<bad_output>这个组件写得非常好，干得漂亮。不过，无障碍性可以改进。</bad_output>
<reasoning>好例子精确且可操作。坏例子冗长且主观。</reasoning>
</example>
</examples>这种"好与坏+解释"的模式充当了行为安全护栏。这在边缘AI中尤为关键。如果你直接在浏览器中运行一个小的3B参数模型（例如，我们的演示程序Vans使用window.ai和@mlc-ai/web-llm），模型的推理能力会降低。提供XML少样本示例是唯一可靠的方法，可以在不撑爆上下文窗口的情况下强制确定性：
// 通过window.ai进行边缘AI调用的示例
const response = await window.ai.createTextSession().prompt(`
<instructions>根据WCAG标准分析此组件的无障碍性。</instructions>
<examples>...</examples>
<context>${domNode.outerHTML}</context>
`);工匠提示：将你的提示词视为配置文件。如果你的整体上下文超过200行，那就不再是提示词，而是庞然大物。是时候拆解它了。
程序性记忆："技能"
这就是技能概念发挥作用的地方。正如IBM团队所阐述的，我们必须区分语义记忆（事实，通常通过RAG管理）和程序性记忆（如何做）。
把LLM想象成一名飞行员。飞行员天生知道如何飞行（推理能力）。但在起飞前，他们需要针对其飞机的特定检查清单（技能），以免坠机。你不会把波音747的手册交给塞斯纳飞行员。
与其将所有代理能力加载到一个提示词中，不如将每种能力封装成一个技能。现代技能不再只是一个简单的文本文件；它是一个可版本化的"插件"。它通常采用文件夹形式，包含一个主指令文件（SKILL.md及其Front Matter，这是由agentskills.io推动的标准），但也可能包含业务脚本和参考示例。
以下是技能核心SKILL.md文件的典型结构：
---
name: obsidian-researcher
description: 触发此技能以在用户的Obsidian库中搜索信息。
tools:
- mcp_obsidian_search
- mcp_obsidian_read_note
---
# 指令
1. 使用`mcp_obsidian_search`工具进行用户查询。
2. 如果某个文件看起来相关，使用`mcp_obsidian_read_note`读取它。
3. 综合找到的笔记，不要编造事实（使用引号）。注意Front Matter中的tools键。这是规范工程中最强大的概念之一：工具范围限定。
与其让你的AI代理全局访问50个工具（这会增加攻击面并稀释模型的注意力），不如将其武器库限制在此特定任务严格必要的范围内。技能成为通往外部MCP服务器、本地Python脚本或简单URL的安全入口点。
这种渐进式披露方法（仅在严格必要时向模型揭示信息）在本地AI中至关重要。当你自己在硬件上运行Llama 3或Gemma时，每个token都很重要。仅加载与上下文相关的程序性"大脑"可以节省VRAM、加速推理并大幅减少幻觉。
一个好的技能是你能够交给人类实习生的一步一步的操作规程。如果人类不理解，AI就会产生幻觉。
编排与全局上下文
虽然技能充当按需的程序性记忆，但代理仍然需要身份和全局规则。这时结构文件就派上了用场：
- AGENTS.md：定义代理的身份、语气和范围。这是根上下文。
- DESIGN.md：将你的绝对标准固化下来。例如，与其在每个技能中重复"编写无障碍代码"，你的DESIGN.md规定了适用于所有地方的A11Y规则或性能约束（例如60fps）。
然后，代理成为指挥者。面对请求时，它结合自己的AGENTS.md、DESIGN.md，然后动态选择正确的SKILL.md（将其加载到活动上下文中），并执行它，通常通过模型上下文协议（MCP）调用外部工具。
但这种完全基于文件的架构的最大优势在于治理。
更新AI的行为不再是聊天历史中模糊的对话。它是一个Pull Request。你可以对AI规程的两个版本运行git diff。对于工程团队来说，这是安全性和可维护性的终极论据。这正是我们在项目中管理复杂行为而不失控所采用的方法。
工程师循环：约束与评估
如果我们声称AI行为是代码，就必须贯彻工程流程。要完成这个循环，还缺少两个支柱：
1. 结构化输出（JSON Schema）与函数模型
技能必须像API一样运作。如果AI礼貌地回复"这是您的结果：{ ... }"，就会破坏你的管道。在本地AI中，仅靠提示词是不够的。你必须通过Outlines、XGrammar或Ollama的原生JSON模式约束SLM的生成过程，从数学上保证输出符合你的schema。智能体不再生成自由文本，而是产生确定性数据。
此外，行业正朝着使用函数模型（如FunctionGemma或Hermes系列）的方向发展。这些模型经过专门训练，不进行对话，而是解析参数、调用工具并返回有效的JSON。这是逻辑上的演进：语言模型变成了一个简单的API执行引擎。
例如，在我们的叙事RPG引擎GemMaster中，我们不是使用理论上的动作schema，而是通过以下方式强制模型以游戏期望的严格格式生成NPC：
# GemMaster：强制NPC创建的严格JSON响应
schema = {
"type": "array",
"items": {
"type": "object",
"properties": {
"name": { "type": "string" },
"class": { "type": "string" },
"background": { "type": "string" }
},
"required": ["name", "class", "background"]
}
}
response = generate(
model="google/gemma-2-9b-it", # 精确模型以捕获索引
prompt=skill_context,
format=schema # 采样器拒绝任何超出schema的token
)2. 系统化评估（Evals）
你不会仅凭"直觉"来批准一个技能的Pull Request。评估智能体已成为一门独立的学科（LLMOps）。行为修改在合并前必须严格通过回归测试。像promptfoo这样的工具允许你针对测试数据集运行智能体，并评估（断言）新技能是否在边缘案例上出现回归。
正是这种严谨性，将"魔法般"的原型开发与工业级生产部署区分开来。
结论与TL;DR
我们作为Web开发者的职业正在演变。我们将编写更少的孤立函数，而更多地架构行为。
总结如下：
- 停止使用"巨型提示词"（你的全能index.html）。使用XML标签对你的提示词进行类型化。
- 使用少样本提示来设定语气。
- 将你的业务逻辑分解为技能（围绕SKILL.md组织的文件夹），并配备严格限定范围的工具。
- 使用AGENTS.md和DESIGN.md管理全局上下文。
- 约束输出（JSON Schema）并测试你的行为（Evals）！
本地AI结合严格的架构，使我们能够完全控制业务逻辑：零API成本，无数据泄露到云端，绝对的自主权。云端AI仍然出色，但对于可预测性至关重要的关键业务工作流，执行控制优先。
软件工程中没有魔法。只有结构。
你呢，你是如何版本化管理智能体行为的？是仍然困在维护巨型提示词的噩梦中，还是已经开始向技能编排过渡？
自豪地开发于加拿大魁北克省博斯 🇨🇦。对沉浸式Web工程与本地AI自主权的结合感兴趣？通过Vibrisse Studio联系我们吧！
