为什么“自动生成 AI 技能”会是下一个开发痛点过去一年里AI 编程助手和 Agent 工具层出不穷但绝大多数团队在使用时都会卡在同一个地方模型能力很强可它不懂你团队内部的流程、规则和专有知识。你问它怎么处理这条数据它按通用逻辑回答你让它按公司的 SOP 执行任务它一脸茫然。于是大家开始写提示词模板、做 RAG 知识库、甚至给 Agent 配各种插件绕来绕去最后发现最花时间的不再是模型调优而是“把专家脑子里的经验搬到 AI 里”这件事本身。COLLEAGUE.SKILL 这个概念正好切中这个环节。它的核心思路可以概括为一句话不要手工编写技能而是通过专家知识蒸馏自动生成可复用的 AI 技能。所谓技能Skill是指一种结构化的、可以被 AI 代理调用的能力包——里面有任务描述、执行步骤、规则、工具调用方式、甚至验证方法。而知识蒸馏在这里不是指大模型蒸馏成小模型而是指把人类专家解决问题的方式、判断标准、经验规则系统性地提取出来转成 AI 能理解和执行的形式。这篇文章要回答几个问题COLLEAGUE.SKILL 到底解决什么场景下的什么问题它和“写提示词”“做 RAG”“微调模型”有什么区别如果我们要自己搭建一个类似的技能自动生成管道需要哪些组件、怎么写代码、怎么验证效果、有哪些坑读完你可以得到一套可落地的工程思路而不是停留在概念层面。1. 这篇文章真正要解决的问题1.1 AI 应用落地的瓶颈知识迁移而非模型能力很多开发团队在接入大模型之后都会经历一个阶段模型调用没问题Prompt 也能写但业务效果始终不稳定。原因往往出在一个被低估的环节——专家的隐性知识没有被结构化地迁移给 AI。举个例子。你让 AI 帮你做一份技术方案评审通用模型会给出一个四平八稳的框架背景、目标、方案、风险、计划。但一个资深架构师评审时会先看什么他会先确认约束条件翻历史决策记录检查方案是否与现有技术栈冲突评估延期风险甚至观察提出方案的人在组织里的角色。这些“不说出来但每次都会做”的步骤就是隐性知识。传统的做法是找几个专家开会把他们的经验写成 Prompt。问题在于专家的经验是情境化的同一个专家在不同场景下的判断可能完全不同写进 Prompt 就成了僵化的规则。而 COLLEGE.SKILL 这类思路强调的是从专家解决真实任务的过程数据中蒸馏出技能的结构而不是让专家事后回忆和总结。1.2 为什么选择知识蒸馏而不是微调或 RAG你可能会有疑问为什么不直接微调模型为什么不把专家文档扔进向量数据库做 RAG它们解决的问题不同。微调适合改变模型的行为模式和知识边界但成本高、周期长而且每次业务规则变更都要重新训练不适合快速迭代的场景。RAG适合补充事实性知识比如规章制度、产品文档但它在“复杂任务执行”上很弱。RAG 检索回来的是资料不是执行步骤。它无法告诉你“先做 A再根据 A 的结果判断是否走 B 分支最后用 C 规则校验”。技能Skill填补的正是这个空档它把任务流程、判断条件、工具调用、校验规则打包成一个可执行的单元。模型还是那个模型但技能让模型知道“遇到这类任务时应该按什么路径走”。所以 COLLEAGUE.SKILL 的定位很明确构建一个“技能工厂”输入是专家任务过程数据输出是可运行、可复用、可治理的 AI 技能包。它在 RAG 和微调之间承担了“流程知识”的载体角色。1.3 这篇文章适合谁正在做 Agent 应用、AI 工作流但觉得技能质量不稳定、扩展困难的开发者。在团队里负责提示词管理和 AI 工具配置想找一个更系统化替代方案的人。对知识蒸馏感兴趣但不想只看“大模型压成小模型”这一种方向想看看蒸馏思想在工程侧怎么用的读者。2. 基础概念与核心原理2.1 什么是 AI Skill技能先明确“技能”这个词。在 AI Agent 的语境里技能不是一段写死的 Prompt而是一个完整的可复用能力单元通常包含这几个要素要素说明示例触发条件什么情况下该被调用消息中包含“检查代码规范”任务描述技能要达成的目标对指定代码执行规范审查执行步骤完成任务的流程读取代码 → 对照规范库 → 生成报告判断规则分支条件和决策依据文件变更量 200 行时进入深度审查工具调用需要的外部工具或 API调用静态分析工具、访问规范文件验证标准如何判断输出正确遗漏问题数、误报率阈值回滚策略失败时怎么办降级为模版生成记录失败原因传统做法是人工编写这些字段。而 COLLEAGE.SKILL 的思路是从专家的实际任务执行记录中自动提炼出这些结构。2.2 知识蒸馏在技能生成场景中的含义传统深度学习里的知识蒸馏是指用一个“教师模型”的输出logits 或中间层特征来指导“学生模型”训练让小模型逼近大模型的效果。但在 COLLEAGE.SKILL 场景下教师不是模型而是人类专家学生不是模型而是技能包。这个视角的转变很有意思。人类专家在解决真实任务时会产生多种数据痕迹对话记录专家与助手、用户的问答过程。操作日志专家在系统里的点击、输入、工具调用序列。评审记录专家对结果的修改、批注、打回重做。决策文档专家留下的方案对比和取舍说明。这些数据是杂乱的、非结构化的但它们包含了专家如何一步步解决问题的路径。知识蒸馏的目标就是从这些路径中提取出稳定的、可重复的任务模式形成技能的结构化描述。2.3 蒸馏的三个层次在实际工程中我把技能蒸馏拆成三个层次任务级蒸馏识别专家在解决什么任务任务有哪些类型边界在哪。比如从客服对话记录中聚类出“退款咨询”“技术故障排查”“投诉升级”等任务类别。流程级蒸馏对每一类任务提取标准的执行流程。专家不是每次步骤都一模一样因此要做序列对齐、去噪、合并相似步骤最后得到“常态流程”和“分支流程”。规则级蒸馏提取判断条件和经验规则。比如“当用户情绪标记为高时先安抚再处理问题”“当错误码在特定范围时优先检查配置而非代码”。这一层最难因为规则往往没有显式写出来需要从结果对比中反推。这是 COLLEGE.SKILL 从概念走向工程实现时必须走过的三层。3. 环境准备与前置条件动手实现之前先列一下环境和技术栈。以下是我建议的一套基础组合版本号不做硬性绑定以你实际使用的为准。3.1 推荐技术栈组件用途建议Python 3.10主要开发语言版本请以当前稳定版为准Pandas日志数据处理用于专家行为数据的清洗和聚合Scikit-learn文本聚类用于任务类型识别OpenAI SDK 或兼容 SDK调用大模型生成结构化技能根据你的模型服务商调整jsonschema技能包校验确保生成的技能符合 SchemaGit技能包版本管理所有产物入库3.2 需要准备的数据这是最容易被低估的部分。技能蒸馏的效果上限取决于专家过程数据的质量和覆盖度。建议至少准备以下三类数据之一专家对话记录最好有时间戳、角色标记、工具调用记录下来。操作行为日志如内部系统里的操作流水。如果没有可以通过插桩方式记录一段时间。专家改稿记录AI 或人写的初稿 vs 专家修改后的最终稿前后对比能提取大量规则。如果数据还没有不要急着写代码先花时间设计“专家做事的记录机制”。没有过程中的数据蒸馏无从谈起。3.3 目录结构建议skill-factory/ ├── data/ # 原始专家行为数据 │ ├── raw/ # 原始日志 │ └── processed/ # 清洗后的中间数据 ├── distillation/ # 蒸馏算法模块 │ ├── task_cluster.py # 任务聚类 │ ├── workflow_extract.py # 流程提取 │ └── rule_mining.py # 规则挖掘 ├── skill_schema/ # 技能包结构定义 │ └── skill_schema.json # JSON Schema ├── generated_skills/ # 生成的技能包输出 ├── tests/ # 验证脚本 └── main.py # 管道入口4. 核心流程拆解整个技能生成管道可以拆成五个阶段。每个阶段都有对应的关键技术点和容易踩的坑。4.1 阶段一数据采集与预处理输入是各种形态的专家行为数据第一步是统一成结构化格式。我的建议是所有事件统一成“行为事件”模型{ event_id: evt_001, timestamp: 2025-01-15T10:23:11Z, actor: expert_zhang, task_id: task_0032, action_type: tool_call, action_name: code_review.submit, input: {file_path: src/main.py, ruleset: team_java}, output: {result: pass, comment: 缺少空指针保护}, context: {session_id: sess_88} }这一步要解决的现实问题是原始日志格式五花八门。需要写清洗脚本做字段映射、时间对齐、会话切分。4.2 阶段二任务识别与聚类不是所有专家行为都属于同一个任务需要先切分任务边界。切分的常用方法是基于时间间隔和会话上下文连续操作间隔超过 30 分钟视为新任务。操作对象发生根本性变化如从代码文件切到数据库表也可能是新任务。切分完成后用文本聚类如 TF-IDF KMeans或向量化 HDBSCAN对任务描述做聚类得到任务类型清单。这一步的产出物是任务类型字典例如{ task_types: [ {id: T001, name: 代码规范审查, sample_count: 342}, {id: T002, name: 数据库索引优化, sample_count: 156} ] }4.3 阶段三流程提取对每个任务类型需要从大量行为序列中提取“代表性流程”。这里推荐一个实用的方法状态转移频率矩阵。把专家的每个操作看作一个状态统计从操作 A 转移到操作 B 的频率保留高频路径剪掉低频噪音就能得到主干流程。举例读取代码 → 提取依赖 → 核对规范库 → 生成报告 → 如果问题数0发送整改通知这个阶段要注意噪音操作问题。专家可能会频繁切换窗口、查看无关资料这些操作在频率矩阵中会表现为低权重的边需要设置阈值过滤。4.4 阶段四规则挖掘规则挖掘是最有价值也最困难的一环。推荐两种实用方法对比反推收集专家初稿和最终稿的差异构建差异数据集。比如专家把“保留两位小数”改成“保留三位小数并在特殊场景下使用科学计数法”这条 diff 背后就对应一条规则。特征关联分析把任务输入特征和专家决策结果做特征相关性分析如决策树、关联规则挖掘找出强相关特征。比如“当交易金额 10 万时专家总是会追加人工复核流程”这就是一条可表达为 if-then 的规则。规则挖掘的产出是一组候选规则通常需要人工审核后并入技能包。这里不要追求全自动人机协同审核规则才是工程上稳妥的做法。4.5 阶段五技能包组装与发布最后把任务描述、流程、规则、验证标准组装成标准化的技能包文件。技能包采用类 YAML 或 JSON 格式纳入 Git 管理带上版本号。这个阶段的核心是定义一套稳定的 Schema保证技能包可以被 Agent 运行时解析和执行。5. 完整示例与代码实现下面用 Python 实现一个最小可运行的技能蒸馏管道。示例以“代码规范审查专家”为场景输入一批专家操作日志输出一个结构化技能包。5.1 定义技能包 Schema文件路径skill_factory/skill_schema/skill_schema.json{ $schema: http://json-schema.org/draft-07/schema#, type: object, required: [skill_id, version, name, description, trigger, workflow, rules, validation], properties: { skill_id: {type: string}, version: {type: string}, name: {type: string}, description: {type: string}, trigger: { type: object, properties: { keywords: {type: array, items: {type: string}}, intent: {type: string} } }, workflow: { type: array, items: { type: object, properties: { step_id: {type: string}, action: {type: string}, next: {type: [string, null]}, branch: { type: array, items: { type: object, properties: { condition: {type: string}, then: {type: string} } } } } } }, rules: { type: array, items: { type: object, properties: { id: {type: string}, description: {type: string}, condition: {type: string}, action: {type: string} } } }, validation: { type: array, items: { type: object, properties: { check: {type: string}, pass_condition: {type: string} } } } } }5.2 实现任务聚类文件路径skill_factory/distillation/task_cluster.py# -*- coding: utf-8 -*- 任务聚类模块 功能将专家行为日志按任务类型分组 输入统一格式的行为事件列表 输出任务类型标注结果 from typing import List, Dict import pandas as pd from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.cluster import KMeans def load_events(file_path: str) - pd.DataFrame: 加载行为事件日志 df pd.read_json(file_path, linesTrue) return df def build_task_descriptions(df: pd.DataFrame) - pd.DataFrame: 构建任务描述文本 这里简化为将同一 task_id 下的 action_name 拼接成一段文本 grouped df.groupby(task_id).agg({ action_name: lambda x: .join(x), actor: first, event_id: count }).reset_index() grouped.columns [task_id, description, actor, event_count] return grouped def cluster_tasks(descriptions: pd.DataFrame, n_clusters: int 5) - pd.DataFrame: 对任务描述做文本聚类 n_clusters 需要根据实际任务规模调整 vectorizer TfidfVectorizer(max_features500, stop_wordsenglish) X vectorizer.fit_transform(descriptions[description].tolist()) model KMeans(n_clustersn_clusters, random_state42, n_init10) labels model.fit_predict(X) descriptions[cluster] labels return descriptions def generate_task_types(df: pd.DataFrame, n_clusters: int 5) - Dict: 主流程加载数据 - 构建描述 - 聚类 - 生成任务类型字典 events load_events(df) desc_df build_task_descriptions(events) clustered cluster_tasks(desc_df, n_clustersn_clusters) task_types {} for cluster_id in sorted(clustered[cluster].unique()): subset clustered[clustered[cluster] cluster_id] # 简化处理取该聚类中出现频次最高的 action 作为任务名候选 top_actions ( events[events[task_id].isin(subset[task_id])] .groupby(action_name).size() .sort_values(ascendingFalse) ) top_action top_actions.index[0] if len(top_actions) 0 else fcluster_{cluster_id} task_types[fT{cluster_id:03d}] { name: top_action, task_ids: subset[task_id].tolist(), sample_count: len(subset) } return task_types5.3 实现流程提取文件路径skill_factory/distillation/workflow_extract.py# -*- coding: utf-8 -*- 流程提取模块 功能从同一任务类型的操作序列中提取主干流程 使用状态转移频率矩阵保留高频路径 from typing import List, Dict, Tuple from collections import defaultdict import pandas as pd def extract_workflow(events: pd.DataFrame, task_ids: List[str], min_transition_ratio: float 0.3) - List[Dict]: 根据任务 ID 列表提取主干流程 min_transition_ratio转移保留阈值低于该频率的路径会被剪枝 filtered events[events[task_id].isin(task_ids)].sort_values([task_id, timestamp]) # 按 task_id 聚合转移路径 transitions defaultdict(int) for _, group in filtered.groupby(task_id): actions group[action_name].tolist() for i in range(len(actions) - 1): transitions[(actions[i], actions[i 1])] 1 # 计算归一化转移概率 incoming_count defaultdict(int) for (src, dst), cnt in transitions.items(): incoming_count[src] cnt workflow [] added_edges set() for (src, dst), cnt in sorted(transitions.items(), keylambda x: -x[1]): if cnt / incoming_count[src] min_transition_ratio: continue if dst in added_edges: continue workflow.append({ step_id: fstep_{len(workflow) 1:02d}, action: src, next: dst }) added_edges.add(src) # 收尾补上最后一步 if workflow: workflow.append({ step_id: fstep_{len(workflow) 1:02d}, action: workflow[-1][next], next: None }) return workflow这一步的简化处理可能带来重复步骤问题生产环境可以换成基于图算法的路径合并比如先构造有向图再做拓扑排序和路径压缩。5.4 实现规则挖掘文件路径skill_factory/distillation/rule_mining.py# -*- coding: utf-8 -*- 规则挖掘模块 功能从输入特征与专家行为的对比数据中提取 if-then 规则 使用决策树模型提取可解释规则 from typing import List, Dict import pandas as pd from sklearn.tree import DecisionTreeClassifier, export_text def extract_rules(feature_df: pd.DataFrame, label_column: str expert_action, max_depth: int 3) - List[Dict]: feature_df: 包含特征列和专家决策标签列 示例特征文件变更行数、风险等级、是否涉及核心模块 feature_cols [c for c in feature_df.columns if c ! label_column] X feature_df[feature_cols] y feature_df[label_column] clf DecisionTreeClassifier(max_depthmax_depth, random_state42) clf.fit(X, y) # 提取规则路径 rules_text export_text(clf, feature_namesfeature_cols) print(决策树规则路径) print(rules_text) # 简化版默认认为每条叶子路径对应一条规则 # 生产环境建议用遍历树节点的方式生成结构化规则 rules [] n_features X.shape[1] def traverse(node, conditions): if node 0: # 叶子节点不继续 return if clf.tree_.feature[node] ! -2 and clf.tree_.feature[node] ! -1: feat feature_cols[clf.tree_.feature[node]] threshold clf.tree_.threshold[node] new_cond_left conditions [f{feat} {threshold:.2f}] new_cond_right conditions [f{feat} {threshold:.2f}] traverse(clf.tree_.children_left[node], new_cond_left) traverse(clf.tree_.children_right[node], new_cond_right) else: if len(conditions) 0: class_label clf.tree_.value[node].argmax() rules.append({ id: fR{len(rules) 1:04d}, description: AND .join(conditions), condition: AND .join(conditions), action: foutput_class_{class_label} }) traverse(0, []) return rules注意决策树规则的可读性有限特征列需要提前做分箱和命名。更复杂的场景下可以改用 LLM 辅助从专家对话文本里抽取规则但建议先跑通决策树基线。5.5 技能包组装与校验文件路径skill_factory/main.py# -*- coding: utf-8 -*- 技能蒸馏管道总入口 import json import uuid from datetime import datetime from distillation.task_cluster import generate_task_types from distillation.workflow_extract import extract_workflow from distillation.rule_mining import extract_rules import pandas as pd def build_skill_package(task_id: str, task_info: dict, workflow: list, rules: list, validation: list) - dict: 组装技能包 return { skill_id: fskill_{task_id.lower()}, version: 0.1.0, name: task_info[name], description: f自动生成的技能包来源于任务类型 {task_id}, trigger: { keywords: [task_info[name]], intent: task_info[name] }, workflow: workflow, rules: rules, validation: validation, generated_at: datetime.utcnow().isoformat() Z } def validate_skill(skill: dict, schema_path: str skill_schema/skill_schema.json): 校验技能包格式 import jsonschema with open(schema_path, r, encodingutf-8) as f: schema json.load(f) jsonschema.validate(instanceskill, schemaschema) print(技能包格式校验通过) if __name__ __main__: # 1. 加载行为日志 events_df pd.read_json(data/raw/expert_actions.jsonl, linesTrue) # 2. 任务聚类 task_types generate_task_types(events_df, n_clusters3) print(任务类型识别完成, list(task_types.keys())) # 3. 对每个任务提取技能包 for tid, info in task_types.items(): workflow extract_workflow(events_df, info[task_ids], min_transition_ratio0.2) # 规则挖掘这里用示例数据演示 demo_feature pd.DataFrame({ file_change_lines: [10, 50, 300, 800, 20], risk_level: [1, 2, 3, 4, 1], expert_action: [review, review, deep_review, deep_review, pass] }) rules extract_rules(demo_feature) validation [{check: 生成报告完整性, pass_condition: 包含问题列表和行号}] skill_pkg build_skill_package(tid, info, workflow, rules, validation) validate_skill(skill_pkg) out_path fgenerated_skills/{tid}_skill.json with open(out_path, w, encodingutf-8) as f: json.dump(skill_pkg, f, ensure_asciiFalse, indent2) print(f技能包已生成{out_path})6. 运行结果与效果验证6.1 运行方式cd skill_factory python main.py6.2 预期输出正常运行时你会看到类似下面的输出任务类型识别完成 [T000, T001, T002] 决策树规则路径 |--- risk_level 2.50 | |--- file_change_lines 30.00 | | |--- class: pass | |--- file_change_lines 30.00 | | |--- class: review |--- risk_level 2.50 | |--- class: deep_review 技能包格式校验通过 技能包已生成generated_skills/T000_skill.json打开generated_skills/T000_skill.json你会看到结构化的技能包包含workflow数组和rules数组。这就是从专家行为数据中蒸馏出来的“可执行经验”。6.3 如何判断蒸馏质量技能包生成不代表蒸馏成功还要验证两个维度流程覆盖度拿一个未参与蒸馏的专家任务记录作为测试数据把它的操作序列和生成的 workflow 做比对看有多少节点能被 workflow 覆盖。覆盖度低于 70% 说明流程提取不足需要调整转移频率阈值或补充数据。规则准确率抽一批历史任务用规则自动决定“该走哪个流程分支”和专家实际选择做对比计算准确率。6.4 失败排查第一步如果不成功优先检查输入数据质量。最常见的失败不是算法问题而是数据切分问题任务边界切错了后面全错。建议在数据预处理阶段多花时间把会话切分和时间戳校准做扎实。7. 常见问题与排查思路问题现象可能原因排查方式解决方案聚类结果全是噪音没有有效任务类型任务描述文本质量差action_name 过于粗糙打印聚类中心样本人工查看补充更细粒度的 action 命名或加入外部任务描述字段提取出的流程断成多段连不起来转移频率阈值设得太高中低频路径被剪掉打印转移矩阵观察被剪枝的路径比例调低 min_transition_ratio或改用图连通分量算法做路径补全规则挖出来的全是“无意义规则”特征设计不区分度决策树过拟合查看规则长度和叶子节点样本数增加特征、限制 max_depth或做特征筛选之后再做规则挖掘技能包在 Agent 运行时无法解析生成的 JSON 不符合 Schema 要求用 jsonschema 校验定位具体字段修复字段类型注意 workflow 中 next 不能指向不存在的 step_id生成的技能在其他团队复用效果差专家的操作习惯带有个人色彩技能过拟合对比多个专家的行为数据算一致性指标用多个专家数据联合蒸馏设置最小支持度过滤个人化行为这些问题是实践中最高频的几类。核心原则是蒸馏不是越自动化越好要控制评估环节的介入程度。8. 最佳实践与工程建议8.1 从“单专家”到“多专家”的数据策略单个专家的行为数据会带入大量个人习惯直接蒸馏容易得到偏置很大的技能。建议至少使用 3 到 5 位同岗位专家的数据并做一个简单的行为一致性分析如果某条操作路径只在一个人身上出现应该标记为“个人偏好”而不是“标准流程”在生成技能包时降低权重或剔除。8.2 技能包的生命周期管理自动生成的技能包不会一次成形要把它当作代码来管理每个技能包单独一个 Git 仓库或目录。版本号遵循语义化版本规范每次新增规则或修改流程都要升版本。技能包上线前要有评审记录。评审通过后才允许 Agent 运行时引用。定期用最新的专家数据重跑蒸馏管道把新技能与旧技能做 diff 后决定是否发布。8.3 人机协同的规则审核规则的生成可以自动化但审核建议保留人工环节。我的做法是把规则挖掘结果输出为“候选规则表”每一条规则附带支持样本数、证据片段让专家快速确认或否决。这样既降低评审成本又保证了规则的可靠性。8.4 安全与授权边界技能包一旦被 Agent 调用就等同于让 AI 执行专家的部分职责。需要特别注意技能包中涉及的操作权限必须最小化不允许跨权限调用。技能包的修改和发布需要有审批链路防止恶意或误操作。涉及生产环境变更、数据删除类任务时技能包内必须内置“人工确认”步骤不允许全自动执行。运行时记录技能调用日志用于事后审计和失败追踪。8.5 与现有 AI 工具链的衔接生成的技能包最终要落到具体的 Agent 运行时。常见的衔接方式作为提示词模板库技能包的 workflow 和 rules 序列化成 Prompt 片段由 Agent 在会话中动态拼接。作为工具调用配置在支持 Function Calling 的框架中每个 workflow 节点映射为一个工具函数。作为编排引擎配置接入专门的 Agent 编排框架技能包直接作为可执行 DAG 导入。无论哪种方式技能包的核心价值都在于它把“零散的经验”变成了“可管理的资产”。9. 总结与后续学习方向COLLEAGUE.SKILL 让我看到的关键转变是AI 技能不再依赖人工编写 Prompt而是可以从专家的真实行为数据中自动蒸馏出来。这个思路的价值在于它把“知识迁移”从主观总结变成了数据驱动的工程过程。对团队而言这意味着积累 AI 技能的方式从“请专家写文档”变成了“记录专家的做事过程然后自动提炼”。本文覆盖了一条从数据采集、任务聚类、流程提取、规则挖掘到技能包组装的最小实现路径所用的技术并不复杂核心都在于数据质量控制和流程设计。如果你准备在团队里落地建议先找一个边界清晰、行为数据容易采集的场景比如代码审查、客服处理、运维巡检做试点先把管道跑通再慢慢扩展到更复杂的任务。往深处走有几个方向值得继续研究技能包之间的依赖编排、跨团队技能共享与标准化、以及蒸馏出的规则在模型微调中的应用。这些话题大概率是未来一年 AI 工程化的热门方向。建议收藏这篇文章作为实践起点动手搭一个最小管道比读十篇概念文章更有用。
自动刷课答题脚本 可接入api进行答题)
