这两年看 AI 文章，最容易被一串英文缩写劝退：

MoE、KV Cache、Prefill / Decode、RLVR、RAG、MCP、Agents、Sandbox、Worktree、Hooks……

对不是专门做大语言模型（large language model）研发、但又想加入相关行业、或者了解相关行业进展的同学来说，简直是学不完根本学不完……新概念层出不穷。

其实大多数“黑话”都在讲一件朴素的事：

怎么让 AI 更聪明、更快、更会接工具，还不至于乱来。

本文按照中文互联网上的常见讨论热度讲解 LLM 领域一些容易引人疑惑的概念。每个概念都尽量补充核心原理、工程实现流程、伪代码和实践建议，帮助你建立初步理解，从“听懂”进阶到“能用”，至少构建一个直觉上的使用思路。

（毕竟更会调 prompt，告诉 AI 你要做什么，怎么不算是能用呢.jpg）

Ready? 那我们先从较为常见的概念开始。

---

1. Agents：不是聊天机器人，是会干活的流程执行者

核心原理

Agent 可以理解为：

LLM + 工具 + 规划 / 执行循环。

它不只是聊天，而是能按照目标分解任务、调用工具、观察结果、继续行动。

常见场景包括：

• 写代码（典型的就是 Trae、Codex 这类智能编程助手）；
• 查资料写研报（例如 ChatGPT 的深度研究）；
• 操作浏览器；（听说有些新的爬虫技术通过这种方法绕开了反爬机制）
• 分析数据；
• 生成演示文稿；（“豆包，我人在飞机上，你给我整个PPT”）
• 自动处理工单（一些功能较为定制化的 Agent）。

工程实现

核心循环：

def run_agent(goal, llm, max_steps=8):
    observation = None
    steps = []

    for _ in range(max_steps):
        # 模型根据目标、当前观察和历史步骤决定下一步
        decision = llm.decide(
            goal=goal,
            observation=observation,
            history=steps
        )

        if decision.type == "finish":
            # 如果模型判断任务已完成，就返回最终答案
            return decision.answer

        # 否则调用指定工具，并把工具返回作为新的观察
        observation = call_tool(
            decision.tool_name,
            decision.args
        )

        # 记录本轮决策和结果，方便后续继续规划
        steps.append((decision, observation))

    # 达到步数上限时，基于已有进展给出可审计的部分结果
    return llm.answer_with_partial_progress(goal, steps)

工具定义：

工具通常使用以下形式描述：

• 函数签名；
• JSON Schema；
• OpenAPI 规范；
• MCP tool 描述。

实践建议

多 Agent 协作：

复杂任务可以拆给不同角色：

• 规划 Agent；
• 检索 Agent；
• 编码 Agent；
• 测试 Agent；
• 审核 Agent。

但多 Agent 不一定更好。任务简单时，一个设计良好的单 Agent 往往更稳定（毕竟打工人都知道有些任务搞个小团队做还不如自己做了效率高）。

---

2. RAG：让 AI 先翻书，再回答

核心原理

RAG 是 Retrieval-Augmented Generation，即检索增强生成。

它的基本思路是：

先从外部知识库检索相关文档，再把检索结果拼接到上下文中，让模型基于资料回答。

RAG 主要解决模型“不知道私有知识”或“知识过期”的问题。

工程实现

典型管道：

1. 文档清洗。
2. 文档分块，chunk size 通常按任务设计。
3. 将文本块转成向量。
4. 写入向量库或混合检索系统。
5. 根据用户问题召回 top-k 片段。
6. 对召回结果进行重排、去重和截断。
7. 将证据片段放进 prompt。
8. 让 LLM 基于证据生成答案。

RAG 伪代码：

def rag(query, retriever, reranker, llm, k=20):
    # 先从知识库里召回一批可能相关的片段
    chunks = retriever.search(query, k=k)

    # 再用重排模型把真正相关的片段排到前面
    ranked_chunks = reranker.rank(query, chunks)

    # 只取最相关的少量片段，避免上下文过长
    context = "\n\n".join(ranked_chunks[:5])

    # 把资料和问题一起放进提示词，并要求模型基于资料回答
    prompt = f"""
			请只基于资料回答问题。如果资料不足，请明确说明无法判断。

			资料：
			{context}

			问题：
			{query}

			回答：
			"""

    # 让大模型基于检索到的证据生成最终回答
    return llm.generate(prompt)

实践建议

• RAG 的难点通常不在“把向量库接上”，而在分块、召回、重排和引用。
• 对企业知识库，要重视权限控制、数据更新和来源追踪。
• 模型回答时应明确区分“资料中有写”和“根据资料推断”。

---

3. MCP：AI 工具世界的通用接口

核心原理

MCP 是 Model Context Protocol，即模型上下文协议。

它是一套标准协议，让 AI 应用可以用统一方式连接外部资源，例如：

• 数据库；
• API；
• 本地文件；
• 业务系统；
• 搜索服务；
• 开发工具。

你可以把它理解成：

AI 应用连接工具和数据源的通用接口。

MCP Server 通常会暴露三类能力：

• tools：可调用动作；
• resources：可读取资源；
• prompts：可复用提示模板。

一个简单例子：在 Codex 里连接 Notion 这类笔记软件。配置 MCP Server，然后让 Codex 调用这些外部工具，让AI帮助我们把今天的项目和代码进展总结写入笔记软件。当然现在Codex的“插件”已经把 有关Notion的Skills、Apps、MCP servers 打包成了一个可复用工作流。事实上，大部分常用工具，在成熟的Agent助手中都有打包好的MCP工作流。

也有大佬会自己开发一些MCP工作流，比如基于 Model Context Protocol (MCP) 的小红书服务端实现，能实现让你的 AI 助手直接访问小红书数据。广告机器人大加强。

工程实现

协议基础：

• 消息格式基于 JSON-RPC。
• 常见传输方式包括 stdio 和 Streamable HTTP。
• 具体 SDK API 会随版本变化，写示例代码时要以官方 SDK 文档为准。

Server 伪代码：

# 创建一个名为 CRM 的 MCP Server
server = MCPServer("CRM")


@server.tool()
def get_customer(customer_id: str) -> dict:
    # tool 表示模型可以主动调用的动作
    return crm_db.query_customer(customer_id)


@server.resource("customer://{customer_id}")
def customer_resource(customer_id: str) -> str:
    # resource 表示模型或客户端可以读取的结构化资源
    return crm_db.render_customer_profile(customer_id)


# 启动服务，等待客户端通过 MCP 协议调用
server.run()

Client 调用：

AI 应用读取 MCP Server 暴露的 tools / resources / prompts，把用户需求转换成标准化请求，再把返回结果交给模型继续生成答案或执行下一步。

实践建议

• MCP 解决的是“工具接入标准化”问题，不直接解决权限、安全和数据质量问题。
• 企业内部使用 MCP 时，要额外设计鉴权、审计和敏感数据过滤。
• 工具描述要清晰，否则模型会误用工具。

---

4. MoE：不是一个大脑，是一群专家轮班

核心原理

MoE 是 Mixture of Experts，即混合专家模型。

普通模型像一个全科医生，什么病都自己看。MoE 更像医院分诊台：代码问题叫代码专家，数学问题叫数学专家，翻译问题叫语言专家。

不过真实 MoE 里的“专家”是训练中学出来的子网络，不一定天然对应代码、数学、翻译这些人类标签。

更准确地说，MoE 的重点不是“专家一定很像人类分工”，而是模型里有多个专家子网络，并用路由器决定怎么组合它们。

工程实现

**核心思想：**路由 / 门控（routing / gating）。

如果是稀疏 MoE，还会进一步使用条件计算（conditional computation）：不同 token 只激活不同专家，从而扩大总参数量，同时控制实际计算量。

MoE 层通常包含多个专家网络和一个路由器。对每个 token，路由器会决定把它送到哪些专家那里计算。

简化流程：

1. 输入 token 表示 x 经过路由器，得到每个专家的分数。
2. 如果是稠密 MoE，可以让所有专家都参与，只是权重不同。
3. 如果是稀疏 MoE，只保留分数最高的 top-k 个专家，通常 k = 1 或 k = 2。
4. 将参与计算的专家输出按路由权重加权求和。
5. 尤其在稀疏 MoE 里，训练时还会加入负载均衡约束，避免所有 token 都挤到少数几个专家那里。

MoE 层伪代码：

def moe_layer(x, experts, router, k=2, sparse=True):
    # 路由器先给当前 token 计算每个专家的匹配分数
    scores = router(x)              # [n_experts]
    # 把分数转成概率，方便后面按权重加权
    probs = softmax(scores)

    if sparse:
        # 稀疏 MoE：只选择概率最高的 k 个专家，避免所有专家都参与计算
        selected_idx = top_k(probs, k)
        # 重新归一化被选中专家的概率，让权重之和为 1
        selected_probs = normalize(probs[selected_idx])
    else:
        # 稠密 MoE：所有专家都参与，只是每个专家的权重不同
        selected_idx = range(len(experts))
        selected_probs = probs

    y = 0
    for idx, weight in zip(selected_idx, selected_probs):
        # 参与计算的专家处理同一个输入，最后按路由权重合并结果
        y += weight * experts[idx](x)

    return y

实践建议

这里还要分清几个容易混在一起的说法：

• 稠密模型（Dense model）：每个 token 基本都会经过同一套参数，所有层都照常计算。
• 稠密 MoE（Dense MoE）：也有多个专家和路由权重，但每次可能让所有或大部分专家都参与，再把输出加权混合。
• 稀疏 MoE（Sparse MoE）：每次只激活少数几个专家，常见是 top-1 或 top-2。

现在大模型语境里说 MoE，很多时候默认指 稀疏 MoE。

稀疏 MoE 的重点是：

不是每次让所有专家上班，而是只叫其中一小部分。

所以你会看到：

“这个模型总参数很大，但 active parameters 不高。”

换句话说就是：公司很大，但每个项目不是全员出动。

---

5. LoRA / QLoRA：不给大脑换血，只加小插件

核心原理

LoRA 是一种更省显存、更省算力的微调方法。

普通微调像把整个模型都拿出来改，成本很高。

LoRA 的做法更像：

原模型先不动，只在旁边加一个很小的“插件”。

这个小插件通常叫 adapter。

LoRA 到底省在哪里：

可以把模型中的某一层想成一个大零件。

全量微调会直接改这个大零件。

LoRA 不直接改它，而是在旁边加一条小分支：

• 原模型输出一份结果；
• LoRA 小插件输出一份修正；
• 最终结果 = 原模型结果 + 插件修正。

所以 LoRA 的核心可以理解成：

不重做整个模型，只学习一小份“怎么修正原模型”的参数。

“Low-Rank / 低秩”可以先粗略理解为：这个插件本身很小，不是完整复制一套大参数，所以训练起来便宜很多。

QLoRA 是什么：

QLoRA 可以理解成“更省显存版 LoRA”。

它做了两件事：

1. 先用 4-bit 等低精度方式加载基座模型，减少显存占用；
2. 再像 LoRA 一样，只训练小 adapter。

工程实现

LoRA 核心伪代码：

def lora_layer(x):
    base_output = frozen_model_layer(x)  # 原模型这一层不训练
    small_fix = lora_adapter(x)          # 只训练这个小插件

    return base_output + small_fix

训练时也可以简单理解成：

freeze(base_model)              # 冻结大模型
adapter = add_lora(base_model)  # 加一个小插件

train_only(adapter)             # 只训练小插件
save(adapter)                   # 最后主要保存小插件

QLoRA 伪代码：

base_model = load_model(bits=4)  # 低精度加载大模型，省显存
freeze(base_model)               # 冻结大模型

adapter = add_lora(base_model)   # 加 LoRA 小插件
train_only(adapter)              # 只训练小插件

实践建议

训练时，主要更新 adapter，而不是更新整个大模型。训练结束后，也可以只保存 adapter。这样一个基座模型就可以搭配很多不同 adapter，比如：

• 医疗领域 adapter；
• 法律领域 adapter；
• 固定输出格式 adapter；
• 某个客户专用 adapter。

所以：

• LoRA：大模型不动，只训练小插件；
• QLoRA：大模型先压缩加载，再只训练小插件。

简单来说就是：

LoRA 省的是训练参数，QLoRA 进一步省的是显存。

这里的 Q，就是 Quantized / Quantization 的意思。QLoRA 之所以更省显存，关键就在于它先把基座模型“量化”加载；所以下一节就顺着讲讲 Quantization：模型到底是怎么被“压缩”的。

---

6. Quantization：给模型打压缩包

核心原理

Quantization，即量化，广义上指用更低精度的数值格式表示模型中的权重、激活或 KV Cache。

常见说法里会混用两类概念：

• 位宽：8-bit、4-bit；
• 数值格式：INT8、INT4、FP8、NF4 等。

其中 INT8 / INT4 属于低精度整数表示；FP8 是低精度浮点格式，也常被放在广义量化或低精度推理里一起讨论。

好处是节省显存、提高吞吐；代价是可能略微降低精度，且加速效果取决于硬件和推理框架是否真正支持对应低精度计算。

工程实现

常见算法：

• GPTQ：一种面向大语言模型的后训练权重量化方法，使用近似二阶信息降低量化误差。
• AWQ：Activation-aware Weight Quantization，通过激活统计识别重要通道，并用缩放方式保护显著权重。
• KV Cache 量化：用更低精度存储 attention 的历史 Key / Value，降低长上下文推理的显存占用。

GPTQ 和 AWQ 通常属于 weight-only PTQ，也就是后训练的权重量化；它们主要压缩权重，不等价于完整的权重 + 激活联合量化方案。

简单 per-tensor 对称整数量化伪代码：

def symmetric_quantize(w, bits=8):
    # bits 决定对称整数量化能表示的最大范围
    # signed int8 本身是 -128 到 127，但对称量化常用 -127 到 127
    qmax = 2 ** (bits - 1) - 1
    # 全零权重没有缩放必要，直接返回全零整数权重
    max_abs = max(abs(w.min()), abs(w.max()))
    if max_abs == 0:
        return zeros_like(w), 1.0

    # scale 负责把浮点权重缩放到整数范围内
    scale = max_abs / qmax

    # 先除以 scale，再四舍五入成整数
    w_q = round(w / scale)
    # 防止少数极端值超过可表示范围
    w_q = clamp(w_q, -qmax, qmax)

    # 推理时需要同时保存量化后的整数和缩放系数
    return w_q, scale

反量化伪代码：

def dequantize(w_q, scale):
    # 用保存下来的 scale 把整数近似还原成浮点数
    return w_q * scale

实践建议

• 4-bit 权重量化常见，但不代表所有场景都适合 4-bit。
• “模型变小”不一定等于“实际更快”；是否更快还取决于 kernel、batch size、GPU 架构和内存带宽。
• 对关键层或关键模块可保留更高精度。

---

7. Long Context 与 上下文压缩：上下文窗口越来越大，但不是万能

核心原理

长上下文（Long Context） 指模型一次能处理的 token 数越来越多。

现在很多模型都在强调长上下文能力，从几十万 token 到百万级 token 的宣传都能看到。但上下文越长，不代表效果一定越好。

常见问题是：

材料塞得越多，模型越可能忽略中间信息、抓错重点，或者被无关信息干扰。

很多朋友跟大语言模型聊天工作时都会发现，新开个窗口比在原来的窗口接着问，AI表现得更聪明。情感陪伴类这种需要记忆构建的除外

工程实现

关键技术：

• 位置编码扩展，例如 RoPE 缩放、NTK-aware 插值等。
• 稀疏注意力或滑动窗口注意力，降低超长序列计算压力。
• 检索 + 重排：先召回相关片段，再重排、裁剪后送入模型。
• 上下文压缩：把长材料压缩成结构化摘要、证据片段或任务相关视图。

多文档 QA 中的上下文压缩伪代码：

多文档 QA 是 Multi-Document Question Answering 的缩写，即”多文档问答“。

模型需要同时阅读多个文档，然后基于这些文档的内容来回答用户的问题。

def compress_context(long_docs, query, max_chunks=30):
    # 先把长文档切成较小片段，方便检索和排序
    chunks = split_into_chunks(long_docs, chunk_size=512)

    # 第一阶段：粗召回
    recalled = [
        # BM25 先快速估算每个片段和问题的相关性
        (chunk, bm25_score(query, chunk))
        for chunk in chunks
    ]

    # 只保留粗召回分数最高的一批片段，减少后续重排成本
    top_chunks = sorted(recalled, key=lambda x: -x[1])[:max_chunks]

    # 第二阶段：重排
    reranked = cross_encoder_rerank(query, [c for c, _ in top_chunks])

    # 第三阶段：只保留最相关的片段
    selected_chunks = reranked[:10]

    # 把最终片段拼成模型可以直接阅读的上下文
    return "\n\n".join(selected_chunks)

实践建议

• 不要把所有材料无脑塞进上下文。
• 对长文档应先切块、去重、排序、压缩。
• 关键事实尽量放在更靠近问题的位置。

---

8. 上下文工程（Context Engineering）：别只会写 Prompt，要会布置现场

核心原理

上下文工程 通常指系统性地设计模型看到的所有信息，也是最近工程界快速流行起来的说法。近两年有论文开始使用这个词，但定义仍在发散。

很多应用效果不好，不是模型差，而是上下文乱。

上下文通常包括：

• 系统提示词；
• 工具描述；
• 少量样本；
• 检索片段；
• 输出格式约束；
• 对话记忆；
• 安全边界。

工程实现

组成：

模块	作用
系统消息	定义角色、安全边界、输出风格
工具定义	用 JSON Schema 描述函数调用
检索片段	去重、排序、按相关性插入
对话记忆	滑动窗口 + 摘要
输出约束	指定格式、字段、禁止事项

上下文模板示例：

## 系统

你是客服助手，只回答产品相关问题。不要编造信息。

## 可用工具

[
  {
    "name": "query_order",
    "parameters": {
      "order_id": "string"
    }
  }
]

## 记忆摘要

用户最近咨询的是退款进度。

实践建议

• Prompt 只是 Context Engineering 的一部分。
• 工具说明要短、准、可执行。
• 检索结果要排序、去重、裁剪。
• 记忆要摘要化，避免把整段历史无脑塞回上下文。
• 格式约束最好用 schema 或模板固化。

---

9. KV Cache：AI 写回答时的草稿本

核心原理

LLM 是一个 token 一个 token 往外生成的。

如果每生成一个 token，都从头读一遍所有输入和已经生成的 token，就会非常慢。

KV Cache 的作用是：把每一层自注意力中，历史 token 计算得到的 Key / Value 张量缓存起来。

工程实现

常见数据结构：

不同框架的维度顺序不同，但大体会为每一层缓存类似下面的张量：

[batch, num_heads, seq_len, head_dim]

也可以理解为：

每一层都有一份 past_key_values

增量推理过程：

1. Prefill 阶段：处理完整输入 prompt，生成初始 KV Cache。
2. Decode 阶段：每生成一个新 token，只计算这个新 token 的注意力状态，并把新的 Key / Value 追加到 cache 中。

KV Cache 增量推理伪代码：

# cache 用来保存历史 Key / Value，第一次请求时还没有缓存
cache = None
# 第一次输入是完整 prompt，后续只输入新生成的 token
cur_token = prompt_tokens

# 第一次前向：处理完整 prompt
logits, cache = model.forward(cur_token, past_kv=cache)

for _ in range(max_new_tokens):
    # 根据当前输出分布采样下一个 token
    next_token = sample(logits)

    # 遇到结束符就停止生成
    if next_token == eos_token:
        break

    # 后续前向：只输入最新 token，并复用历史 cache
    logits, cache = model.forward(next_token, past_kv=cache)

实践建议

• 长上下文和长输出会显著增加 KV Cache 显存占用。
• PagedAttention 这类方法会像操作系统分页一样管理 KV Cache，减少碎片和浪费。
• 也可以结合 KV Cache 量化、压缩或前缀缓存，降低显存压力。

---

10. 沙盒（Sandbox）：让 AI 在安全实验室里操作

核心原理

沙盒/沙箱 是一个隔离环境。

AI 可以在其中执行命令、读写文件、运行代码；在正确配置隔离策略时，沙盒会尽量限制这些操作影响主机或生产系统。

工程实现

技术选择：

技术	特点
Docker 容器	常见、易用，可限制 CPU / 内存 / 网络
Firecracker 微虚拟机	隔离更强，适合安全要求更高的场景
受限进程	轻量，但隔离强度较弱

安全策略：

• 限制 CPU；
• 限制内存；
• 限制网络；
• 使用只读根文件系统；
• 设置命令白名单或权限策略；
• 禁止危险命令，例如 rm -rf、sudo；
• 对文件读写范围做隔离。

创建沙箱伪代码：

import docker

# 连接本机 Docker 服务
client = docker.from_env()

# 启动一个受限容器，作为隔离的代码执行环境
sandbox = client.containers.run(
    "python:3.11-slim",
    command="sleep 3600",
    detach=True,
    # 禁用网络，避免沙盒代码访问外部服务
    network_disabled=True,
    # 限制内存，防止代码耗尽主机资源
    mem_limit="512m",
    # 限制 CPU 和进程数量，避免 fork bomb 或高负载任务拖垮主机
    nano_cpus=1_000_000_000,
    pids_limit=128,
    # 根文件系统只读，减少对环境的破坏面
    read_only=True,
    # 给程序一个可写的临时目录，否则很多 Python 程序会无法运行
    tmpfs={"/tmp": "rw,noexec,nosuid,size=64m"},
    # 使用非 root 用户运行，降低容器逃逸或误操作的风险
    user="1000:1000",
    # 只读挂载待执行脚本目录，真实系统应使用任务级临时目录
    volumes={
        "/host/sandbox/job-123": {
            "bind": "/workspace",
            "mode": "ro"
        }
    },
    working_dir="/workspace"
)

# 在沙盒里执行脚本，并拿回执行结果
exec_result = sandbox.exec_run("python script.py")

实践建议

• 沙盒不是绝对安全，仍然要做权限、网络和资源限制。
• 对不可信代码，优先使用更强隔离方案。
• 避免挂载 Docker socket、开启 privileged 模式，或把敏感目录暴露给容器。
• 对企业系统，沙盒操作要有日志、审计和回滚机制。

---

11. 钩子（Hooks）：在关键节点自动把关

核心原理

钩子 是在 Agent 执行关键步骤前后触发的回调函数。

企业级 Agent 的典型用法：

场景	Hook 作用
日志审计	记录每次 tool_call 的输入输出
权限控制	拦截敏感操作（如删库、发邮件）
成本控制	统计 token 用量，超限中断
缓存	相同 query 直接返回缓存结果
重试策略	失败后自动换用备用工具

工程实现

钩子类型：

Hook	触发时机
PreToolUse	工具调用前
PostToolUse	工具调用后
PreStep	单步执行前
PostStep	单步执行后

安全检查钩子示例：

下面代码只演示思路。真实系统不能只靠字符串匹配拦截危险命令，更应该使用命令白名单、结构化解析、权限隔离和沙盒执行。

def dangerous_command_hook(tool_name, args):
    # 在 shell 命令真正执行前检查危险操作
    if tool_name == "shell" and "rm -rf" in args["command"]:
        raise PermissionError("禁止删除操作")

    # 没有命中风险规则时，允许原参数继续执行
    return args


# 把安全检查注册到工具调用前的钩子上
agent.register_hook("pre_tool_use", dangerous_command_hook)

测试钩子示例：

def test_hook(tool_name, output):
    # 文件编辑失败时主动告警，方便人工介入排查
    if tool_name == "edit_file" and "error" in output:
        send_alert("Agent 修改文件失败")

主流 Agent 框架中的 Hook：

• LangChain / LangGraph：在 Tool Call 前后插入逻辑，如记录日志、修改参数，处理工具执行失败。
• RAG 系统：文档加载后做数据清洗、隐私脱敏；检索结果返回前做安全过滤、内容审核。
• ReAct / Tool Use 流程：LLM 生成 Action 前检查/修改 prompt，Action 执行后处理返回结果、决定是否重试。

实践建议

• Hooks 不要写得太重，否则会拖慢 Agent。
• 安全类 hook 应该尽量规则化、可审计。

---

12. Skills：万事皆可沉淀为SOP

核心原理

一个 Skill 是封装好的一组知识、提示、脚本和约定。有些Skills，可能只是一个简单的markdown格式文档，却能给模型解决实际问题的能力带来从金丹期提升到元婴期的飞升。

广义的Skills通常用于把重复工作、能力沉淀固化下来，例如：

• 生成周报；
• 整理会议纪要；
• 分析 CSV；
• 创建演示文稿；
• 检查代码规范；
• 设计相同风格的前端样式；
• 调用特定脚本处理文件。

当然，随着大语言模型不断融入打工人的生活，也有天才提炼了“同事-skill”、“前任-skill”等

不同平台对 Skill 的定义不完全相同。这里把它作为一种工程抽象来讲：把稳定流程沉淀成可复用的说明、模板和脚本。

工程实现

目录结构示例：

skill-weekly-report/
  SKILL.md
  templates/report_template.md
  examples/good_report.md
  scripts/format.py

SKILL.md 内容示例：

---
trigger: "整理周报|生成周报"
steps:
  1. 提取本周完成事项
  2. 按模板填充：进展、风险、下周计划
  3. 调用 scripts/format.py 校验格式
output: 固定 Markdown 表格
---

运行时机制：

系统根据任务意图加载对应 Skill，把其中的说明、模板或脚本作为执行依据。必要时可以运行脚本，产出更稳定的结果。

实践建议

• Skill 适合沉淀稳定流程，不适合描述一次性灵感。
• 好的 Skill 应该包含触发条件、步骤、输入输出格式和失败处理。
• 能脚本化的检查尽量脚本化，不要全靠模型自由发挥。

---

碎碎念

其实对于大语言模型，我一直觉得它的灵魂是建立在概率学上的。

或许万事万物皆有下一步行向何处的概率，LLM只是在语言空间中不断选择最符合统计规律的延续路径。不过这种“路径选择”并不只是简单的概率最大化，还受到对齐机制与采样策略的共同影响。

大部分针对LLM的工具和优化，一个重要的目的就是提升更优 action / continuation 被采样到的概率。实现这种提升的思路非常多样，可以是优化表征、优化边界、优化推理路径。

其中推理路径相关的很多优化方法，即使你没有计算机或算法相关的基础知识，只要你会说话（有语言理解的能力），就能够实现。Skills就是这样一种非常典型的存在，很多Skills的开源贡献者，之前甚至都没有接触过github。

或许这就是为什么LLM出现后，相关的工程概念会井喷，为什么偏偏是大语言模型有这样的能量。

当然，一旦涉及模型本身的表征优化或决策边界修正，依然需要硬核的算法和算力基础。这便是一些更硬核的算法工具存在的原因。

本期“黑话”总结就到这里，下一期将针对推理、训练与检索方面的一些进阶概念进行总结说明，包含Prefill、RLVR、Thinking Budget等你可能见过，但没有深思的硬核概念。