AI系统Skill化重构：从基础功能到智能能力的演进路径

2026-05-11阅读 0热度 0

skill

在AI系统设计实践中，一个普遍存在的认知偏差是将复杂的业务场景简化为单纯的模型调用问题。真正的挑战，往往潜藏在数据与模型之间那片尚未被清晰定义的灰色地带。本文将以AI作业批阅这一具体场景为例，深入探讨如何通过构建“能力层”来赋予系统处理复杂场景的智能。

当系统完成这样的架构设计后，数据API将超越其原始的数据供给角色，AI也不再是孤立的模型调用点。在两者之间，将生长出一个具备真正业务价值的中间层：一个可组合、可调度、可自主演化的能力层。

真正的价值创造，不在于实现一个AI功能，而在于将其沉淀为可供他人复用的标准化能力。

一、起点：一个看似简单的问题

项目的初始目标非常聚焦：借助AI技术实现作业批阅自动化，核心诉求是释放教师时间、提升批阅一致性，并生成更具个性化、更贴近真人教师风格的反馈。

利用 AI 实现作业批阅，我们希望借此节省老师的时间，提升批阅质量，让反馈更“像老师”。

第一版实现采用了最常见的模式，即直接集成一个AI批阅接口：

def generate_feedback(answer: str, question: str) -> str:
    prompt = f"""
    请批改学生作业：
    题目：{question}
    学生答案：{answer}
    请给出评价和建议：
    """
    return llm.generate(prompt)

上线后暴露的问题也极具代表性：反馈内容“正确但无用”，流于表面，缺乏针对性；完全忽略了学生的个体学习轨迹和历史错误模式，导致反馈割裂，无法形成连贯的教学体验。

问题的根源在哪里？我们并不缺乏数据——历史作业记录、错题本、知识点图谱，这些数据都存在。但核心矛盾在于，这些数据仅仅是被“存储”着，从未被有效地整合进AI批阅的推理决策链路中。

二、识别“龙虾场景”：复杂度的觉醒

在持续的优化迭代中，我们逐渐认识到，AI批阅绝非一个“单点调用模型”即可解决的简单问题。它是一个典型的复杂业务场景。

我们在内部将其定义为“龙虾场景”：

定义：一个由多个数据源、多个处理步骤、多个决策点组成的高价值场景，难以通过单次模型调用完成。

这类场景通常具备三个核心特征：多跳（Multi-step），意味着无法一次调用完成；多源（Multi-source），需要依赖多个数据系统；以及高价值（High-impact），其结果直接影响核心业务体验。

三、拆解“龙虾场景”：从 Prompt 工程到数据编排

那么，AI批阅的完整工作流究竟是什么？当我们对整个链路进行彻底拆解后，真相变得清晰：

1. 拉取学生历史数据
2. 识别与当前题目相关的数据
3. 提取错误模式 / 学习趋势
4. 压缩为模型可接受的上下文
5. 构建带“教学意图”的 Prompt
6. 调用模型生成反馈

这里发生了一个关键的范式转变：这不再是一个“Prompt优化问题”，而是一个彻头彻尾的“数据处理 + 推理编排问题”。

复盘初版代码，那是一个典型的“大泥球”架构：

def generate_feedback(student_id, question, answer):
    # 逻辑耦合：数据获取、过滤、压缩、Prompt 混在一起
    history = db.get_history(student_id)
    relevant = [h for h in history if h["kp"] in question]
    history_text = "\n".join([h["content"] for h in relevant[:10]])
    prompt = f"""
    历史表现：{history_text}
    当前题目：{question}
    学生答案：{answer}
    请评价：
    """
    return llm.generate(prompt)

这种架构直接导致了三大工程顽疾：逻辑高度耦合，任何一段代码都无法被复用；完全不可扩展，换个场景（比如学情分析）就得全部重写；调试如同噩梦，出了问题很难定位，究竟是数据过滤有问题，还是Prompt构建有毛病。

四、关键转折：能力拆解与 Skill 化

于是，我们做了一个“反直觉”的决定：禁止再写任何“大函数”，必须将整个流程拆解成最小能力单元，我们称之为“Skill”。

Skill的设计原则非常明确：不是简单地封装函数，而是定义清晰的能力边界。 每一个Skill都必须满足：输入明确（不隐式依赖上下文）、输出稳定（结构化）、无副作用（可被安全复用）。

来看几个核心Skill的设计示例：

1. 数据检索

class GetStudentHistorySkill(Skill):
    def __call__(self, student_id: str, question_type: str):
        return db.query("SELECT ...") # 获取纯净数据

2. 相关性过滤

class FilterRelevantRecordsSkill(Skill):
    def __call__(self, records, question):
        # 实战经验：规则过滤 + 结构化标签远比 Embedding 稳定
        kp_set = extract_kp(question)
        return [r for r in records if r["knowledge_point"] in kp_set]

3. 上下文压缩

这是效果提升最显著的一环。关键点在于：不要把原始数据直接扔给模型，要先把它“变成知识”。

class SummarizeHistorySkill(Skill):
    def __call__(self, records):
        # 利用 LLM 将长文本压缩为高密度的“学生画像”
        prompt = "总结学生历史表现，重点：高频错误、进步趋势..."
        return self.llm.generate(prompt)

4. 意图构建

class BuildPromptSkill(Skill):
    def __call__(self, question, answer, history_summary):
        # 注入教学意图
        return f"你是一位经验丰富的老师...结合历史表现{history_summary}...评价{answer}"

五、Skill 升级：从“代码封装”到“Agent 可理解”

Skill化设计完成后，我们遇到了新问题：Skill虽然拆出来了，但只有工程师能看懂，对于AI Agent来说，它们依然是不可感知的黑盒。

函数代码对人很清晰，对Agent却毫无意义。解决方案是：为每一个Skill引入一份结构化的描述文件（例如 skill.md），实现“代码 + 描述”的双结构。

# skill.md
name: filter_relevant_records
description: |
  从学生历史记录中筛选与当前题目相关的记录，
  基于知识点匹配进行过滤
inputs:
  - name: records
    type: List[Record]
    description: 学生历史记录列表
  - name: question
    type: String
    description: 当前题目内容
dependencies:
  - get_student_history

为什么这份描述文件如此关键？很简单：没有它，Skill只是冰冷的代码，必须由人来编写流程，Agent无法参与；有了它，Agent就能根据描述理解能力边界，根据输入定义自动补全参数，甚至根据依赖关系自动构建调用链。

这里有几个实战中踩过的坑：描述写得太技术化（要写给模型看，不是写给同事看）；Skill粒度过大（导致Agent无法拆解，其他流程也无法复用）；以及忽略了依赖声明（导致Agent不知道正确的调用顺序）。

六、Skill Flow：让系统“跑起来”

当Skill被标准化后，我们并没有把流程写死，而是增加了一层编排逻辑：

def run_pipeline(ctx):
    # 1. 获取
    ctx["history"] = GetStudentHistorySkill()(ctx["student_id"])
    # 2. 过滤
    ctx["filtered"] = FilterRelevantRecordsSkill()(ctx["history"], ctx["question"])
    # 3. 压缩
    ctx["summary"] = SummarizeHistorySkill()(ctx["filtered"])
    # 4. 构建
    ctx["prompt"] = BuildPromptSkill()(ctx["question"], ctx["answer"], ctx["summary"])
    # 5. 生成
    return GenerateFeedbackSkill()(ctx["prompt"])

系统升级后，开始展现出真正的“演化能力”：新场景可以极速上线，从过去的“重写”变成了现在的“组合”（例如，学情分析可以复用70%的Skill，学习报告可以复用80%）；优化路径也变得异常清晰，调整过滤策略或压缩方式，每一步都可独立进行，不再是令人头疼的“玄学调参”；更重要的是，AI Agent可以自然地接入系统，它不再是空壳，而是能够基于Skill描述进行自主规划和调用。

七、落地经验总结

回顾整个“龙虾场景”的落地过程，可以提炼为一个四步法：

识别：寻找那些高价值、高复杂度、高频率的业务场景。
拆解：强制将流程拆解为数据获取、处理、压缩、意图构建、生成等明确步骤。
Skill化：确保每个Skill职责单一，输入输出明确。
Flow编排：初期可采用固定流程，后期逐步放开，引入动态决策。

最后，分享几条反常识的实战经验：不要一上来就迷恋向量检索，成本高且不稳定，很多时候“结构化数据 + 规则过滤”反而更可靠；上下文压缩的质量，往往比Prompt的花样更重要，80%的效果提升其实源于数据质量的优化；记住，Agent是“能力放大器”，而不是“起点”，没有扎实的Skill作为基础，Agent只是一个空壳。

结语

回过头看，这次探索的深层意义，其实不在于“优化了一个AI批阅功能”。我们真正在回答的，是一个更基础、也更关键的问题：

在 AI 时代，系统应该如何组织能力？

我们的答案是：用Skill作为最小能力单元，用Flow来组织复杂场景。

当你这样设计系统之后，数据API不再只是“提供数据”，AI也不再只是“调用模型”。它们之间，多了一层真正有价值的东西：可组合、可调度、可演化的能力层。

而这，或许才是复杂业务在AI时代真正的解法。