我一开始用 AI 辅助干活的时候有个特别深的挫败感明明上周已经跟它交代过我写文档的习惯、代码风格、汇报方式今天新建一个会话它又全忘光了。每次都要重新把“我是谁、我想要什么风格、结论放前面、别给我列一堆废话”这些话说一遍说多了我自己都烦。后来我做了个叫 Agent-Skills 的小项目核心就一句话把“工作方式”固化成一组 AI 可以按需加载的技能包让模型在开工前先读取对应的“工作记忆”它才终于像个跟了我一段时间的助手而不是一个每次都在重新面试的新人。这个项目适合谁适合所有重度使用大模型写代码、写分析、写方案的人尤其是那些想把个人经验沉淀成团队可复用模板的开发者。下面是我自己的实现笔记偏实操从设计思路、技能结构、代码实现到踩坑记录都有你可以直接照着搭一个最小可用版本。1. 这项工程在解决什么AI 为什么总记不住你的习惯1.1 每一次对话都是“失忆”的重新面试大模型本身没有跨会话的记忆这是架构决定的。每次对话结束上下文窗口里的内容就被清空了下次新建会话模型对你的了解就是零。这个问题在浅层使用中不明显比如偶尔让它写个文案、翻译一段话不需要什么个性化但一旦你进入高频工作流比如每天让它辅助写周报、做代码评审、拆需求问题就非常刺眼了。我举个例子。我每周写技术周报以前每次都要在提示词里重新强调按项目维度归类、每条事项写“动作结果”、阻塞问题单独列出来、总字数控制在 500 字以内。这些话每写一次就要占掉几百个 token而且每次写出来的效果还不稳定——有时候它记得把结论放前面有时候又洋洋洒洒写一大段背景。本质原因是“工作方式”没有被结构化只是临时躺在提示词里随用随丢。Agent-Skills 解决的就是这个问题把散落在提示词里的“做事偏好”抽出来变成一个有结构、有版本、可以被动态加载的技能文件。AI 在启动任务前先加载对应技能表现就会稳定很多。1.2 提示词、RAG、微调和 Agent-Skills 的定位差异很多人会问这不就是写个提示词模板吗跟知识库 RAG 有什么区别是不是微调才能根治我把这几个方案的定位理一下。普通提示词模板解决的是“一次性表达需求”你写一段话模型照着执行缺点是每次都要重新写、难以复用、没有逻辑分支。RAG 解决的是“给模型提供外部知识”比如把公司文档库接进来让模型回答问题时能引用资料它管的是“知道什么”跟“怎么做”是两回事。微调则更重它是去改模型的权重让模型本身的行为发生偏移成本高、周期长而且只为了解决“输出风格”这种问题性价比很低。Agent-Skills 走的是中间路线不动模型权重也不做大规模知识检索而是把“行为规范”做成模块化的技能描述在运行时动态注入提示词。它管的是“怎么干活”比提示词模板更系统比 RAG 更贴近行为控制比微调更轻量。用“系统”这个词可能更准确它是一套管理行为描述的基础设施不是单次输入的提示词。1.3 Agent-Skills 想达到的效果我做完这个小项目之后给自己定的目标非常简单让 AI 在接到常见任务时表现得像“我远程带过一阵子的实习生”而不是“一个什么都不知道但能力很强的陌生人”。拆成可衡量的标准大概有三条。第一同一类任务连续多次执行输出质量波动不能大比如周报每一次都能按模板格式输出。第二用户对输出的修正请求能通过修改技能文件固化下来下次直接生效不需要重新教一遍。第三不同技能之间可以组合比如“需求分析技能”和“代码设计技能”可以串成一条完整的工作流而不是每次都要单独触发。如果你也在被“每次都要重新交代背景”折磨那这个项目的基本方向就是对的先把工作方式拆成技能再让 AI 按需加载最后在实战中持续迭代技能库。2. 核心设计把“工作方式”变成一组可加载的技能包2.1 技能单元一份描述不是一堆要求而是一份“操作契约”刚开始我犯过一个错误把技能描述写成了“我希望你……”“请记得……”这种愿望清单。结果模型经常选择性忽略因为这种描述太松散没有约束力。后来我换了个思路把每个技能当成一份“操作契约”也就是明确写出什么情况下该启用、进来时要接收什么输入、按什么步骤处理、最终输出成什么样、哪些事情绝对不要做。拿“技术周报生成”这个技能举例一份好的技能描述长这样它有明确的触发条件比如“用户要求写周报、做周总结、汇报本周进展”它有明确的输入项比如“本周完成事项、阻塞问题、下周计划”它有步骤约束比如“先问用户补齐缺失信息再按项目维度归并事项每条写成动作结果”它还有禁则比如“不要用‘赋能’‘抓手’这类空词不要编造未发生的事项”。这种契约式描述的好处是模型每次执行时有一条清晰的“行为路径”不是自由发挥而是按照步骤走。自由发挥对创作类任务有价值但对工作流任务是灾难稳定性才是第一位。2.2 技能包的组织形态与技能清单一个技能包本质上就是一个文件我习惯用 JSON因为它既方便程序读取也方便人工维护。文件里除了技能主体还要有id、version、trigger这些元信息元信息不是摆设后面做技能管理和版本对比时全靠它们。{ id: weekly-report, name: 技术周报生成, version: 1.3.0, trigger: 用户要求生成周报、写周总结、汇报本周工作, input: [本周完成事项, 阻塞问题, 下周计划], steps: [ 先检查输入是否齐全缺失则向用户追问, 按项目维度归并本周完成事项, 每条事项写成“动作 结果”格式尽量带上具体数字, 阻塞问题用一句话说明现状和需要谁支持, 输出 Markdown 格式周报总字数控制在 500 字以内 ], constraints: { tone: 平实、不吹嘘, style: 少形容词多用事实和数字, forbidden: [ 不要使用“赋能”“抓手”“闭环”等空泛词汇, 不要编造未发生的事项, 不要把本周问题和下周计划混在一起写 ] }, output_template: ## 本周完成\n...\n## 阻塞问题\n...\n## 下周计划\n... }技能清单则是一个总索引记录当前用户有哪些技能、每个技能对应的文件路径、加载优先级。优先级这个字段特别重要。假设用户同时导入了“周报生成”和“文档格式化”两个技能它们都对输出风格有要求如果优先级不清模型就会困惑不知道听谁的最后输出一个四不像。我会在清单里给每个技能标注是否默认加载、是否按需加载避免无冲突。2.3 加载策略不是把所有技能都塞进上下文这是我在设计时反复斟酌的一个点到底把多少技能塞进系统提示词里才合适一开始我很天真觉得技能越多越好把自己常用的十几个技能全塞进去。结果上下文被占掉一大半不仅浪费 token模型还容易出现“记忆混乱”——它同时记住好几套规则遇到任务时不知道该执行哪套。后来我悟了技能的加载要分层。第一层是全局默认技能只放那些在几乎所有任务中都要遵守的底线规则比如“所有输出都用中文”、“代码要附注释”、“复杂问题先给结论再给推理”。这类技能数量必须控制在 3 个以内。第二层是按需加载技能也就是真正的工作流技能比如“技术周报生成”、“代码评审”、“需求拆解”只有在对应任务触发时才注入。第三层是参考型资源比如输出模板、代码规范文档这些不需要常驻上下文需要时再读取。这样做的好处很明显上下文窗口里的内容永远是“够用就好”不会因为技能太多而拥堵模型也能更专注地执行当前任务。3. 实操落地从零搭一个让 AI 记住工作方式的最小系统3.1 技术选型与系统组成我的目标是用最少的代码跑通闭环不想一开始就引入重框架。系统组成其实很简单一个支持函数调用的大模型 API、一个技能加载器用来读取技能文件并注入提示词、一个简单的任务分发逻辑。这里多说一句选型思路。技能加载器不需要杂技术就是读写文件、拼接字符串。任务分发逻辑才是关键它要判断当前用户的输入命中了哪些技能再把对应技能注入上下文。模型我选的是市面上主流的支持工具调用的大模型因为 Agent 任务里经常要调用外部工具比如查数据库、执行脚本支持函数调用能省很多事。整体架构用一个生活化类比来说技能文件是“菜谱”技能加载器是“找菜谱的人”任务分发逻辑是“厨师长接到客人点菜后把对应菜谱递给厨师”。客人不需要每次重新描述这道菜怎么做厨师长也不用临场想一切按既有流程走。3.2 定义第一个技能以“技术周报生成”为例第一次做技能包我强烈建议从一个你自己每周都会做的重复任务开始因为频率高你才能最快感受到效果差异。我自己第一个定的就是“技术周报生成”。定义过程分四步。第一步把这个任务在你这边的标准流程写下来不用管格式先写“我平时是怎么做的”先把这一周做的事列出来按项目归一下类看看哪些是进展、哪些是阻塞最后挑重点写成 500 字左右。第二步把“我平时的偏好”补进去我喜欢每条事项带数字比如“性能优化完成接口响应时间从 800ms 降到 200ms”不喜欢空话套话阻塞问题必须写清楚需要谁配合。第三步把“我绝对不要的”也写进去不要编造没做过的事不要把所有事项平均用力写要有主次。第四步把它们整理成上面那种 JSON 结构。这个过程中最重要的不是格式而是把你自己平时“默认知道”的东西显性化。你觉得自己知道怎么写周报但 AI 不知道它只有看到你写出来的规则才能照着执行。3.3 实现技能加载器技能加载器的实现不复杂我用 Python 写了一个约 80 行的最小版本核心就两个函数一个是“根据用户输入匹配技能 ID”一个是“把匹配到的技能注入系统提示词”。import json from pathlib import Path SKILL_DIR Path(./skills) def load_skill(skill_id: str) - dict: skill_path SKILL_DIR / f{skill_id}.json if not skill_path.exists(): return {} with open(skill_path, r, encodingutf-8) as f: return json.load(f) def match_skills(user_input: str) - list[str]: matched [] for skill_file in SKILL_DIR.glob(*.json): with open(skill_file, r, encodingutf-8) as f: skill json.load(f) trigger skill.get(trigger, ) if any(keyword in user_input for keyword in trigger.split(、)): matched.append(skill[id]) return matched def build_system_prompt(user_input: str) - str: base 你是一个经验丰富的工程效率助手请严格按照给定的技能描述执行任务。 skills match_skills(user_input) for skill_id in skills: skill load_skill(skill_id) if not skill: continue base f\n\n[技能{skill[name]}]\n base 触发条件 skill[trigger] \n base 执行步骤 → .join(skill[steps]) \n base 输出约束 json.dumps(skill[constraints], ensure_asciiFalse) \n base 输出模板 skill[output_template] \n return base实际调用大模型时只需要把build_system_prompt(user_input)的返回值作为系统提示词把用户输入作为用户消息。就这么简单一个能“记住工作方式”的最小系统就跑起来了。我特意没把加载器写成复杂的插件系统因为早期最重要的是让你看清楚核心链路技能文件 → 匹配 → 注入。等这个链路跑顺了再考虑加缓存、加线程、加 Web 界面都不迟。3.4 跑通一次带技能的任务系统搭好之后我做了一次完整测试。输入是“帮我把这周的工作整理成周报这周完成了用户登录模块的重构和订单查询接口的优化订单查询接口从 800ms 降到 200ms另外支付回调有点问题下周计划做数据监控。”如果没有技能包模型估计会洋洋洒洒写一段“本周工作总结”很可能还带个“首先、其次、最后”。但这次系统先匹配到了weekly-report技能把执行步骤、约束、模板全部注入上下文模型的输出就完全变了样它先按项目维度把两件事分开每条都用了“动作结果”结构阻塞问题单独列出来写清现状还自动把支付回调问题定位成“需要后端和支付渠道确认”输出格式跟模板完全对齐。这一步跑通的时候我最大的感受是AI 的输出终于从“像一篇文章”变成了“像一个懂你工作习惯的人写的文档”。这不是模型变聪明了而是技能包把“你的工作方式”完整传递给了模型。4. 技能包的持续进化更新、版本管理与团队复用4.1 技能包的版本管理思路技能包不是写一次就定型了它会随着你的工作方式一起进化。比如你换了新的周报模板、改了代码规范、新增了需求评审流程技能包都要跟着改。既然技能包是文本文件那最好的管理方式就是把它们放进 Git 仓库里这绝对是我最推荐的做法。版本管理的具体操作很简单每个技能 JSON 里维护一个version字段每次修改就升一个版本技能包的目录结构按用户或者按团队组织比如skills/me/weekly-report.json、skills/team/code-review.json每次改动提交清晰的 commit message说明“这次改了哪条规则、为什么要改”。有人可能会觉得管理几个 JSON 文件不必要用 Git。但我的真实体会是当你手上有 20 多个技能文件迭代了两三个月之后你会非常需要知道“上周周报输出格式突然不对是不是我改了技能文件里的模板字段”。Git 能让你秒查这个问题没有版本管理就只能靠回忆。4.2 根据反馈修正技能从“AI 不听”到“听得懂”技能包跑起来之后你会发现一个常态模型不是每次都会严格执行。这时候第一反应不该是“模型真蠢”而是“技能描述可能没写到位”。我归纳过三类最常见的执行偏差。第一类是“工具性描述缺失”你只说了“要写结论”但没说“结论放在第一行还是第二段”模型就自由发挥了。第二类是“边界不清晰”你说“不要写废话”但模型不知道对你来说什么是废话你得具体到“不要出现‘总之’‘综上所述’这类词”。第三类是“步骤之间缺衔接”你说完“第一步做什么、第二步做什么”但没说“第二步需要用到第一步的什么输出”模型会卡在中间不知道怎么办。我修技能的时候会做一件事把一次失败输出和一次理想输出放在一起对比找出差异点然后把差异点反推成一条新的规则。循环几次之后技能描述就会越来越紧贴你的真实需求。我强烈建议给技能加一个“禁止列表”。不要小看这招实测下来正面要求模型“要写清楚”“要简洁”效果很模糊但反面约束“不要出现某个词”“不要超过 500 字”“不要在结论前加背景描述”效果立竿见影。人类注意力机制对“不要做什么”往往比“要做什么”更敏感模型在这个场景下也有类似表现。4.3 技能包分享与团队复用当技能包的个人闭环跑顺之后我马上想到一个问题这套东西能不能让团队一起用答案是能但要做两个改造。第一去个人化。你自己的技能描述里肯定带了很多私人偏好比如“我在周报里喜欢用某个词”。团队共享时这些要去掉改成团队通用的规范。第二建立共享技能仓库团队每个人都可以提交新技能或修改现有技能但合并前要经过评审就像代码评审一样。我会在仓库里放一个README.md说明技能命名规范、字段含义、提交流程让新人也能快速上手。团队化之后最大的价值是沉淀。以前团队的工作方式散落在每个人的脑子里新人进来全靠老人带现在新人只需要把团队技能包导入自己的 AgentAI 就能在干活时自动遵守团队规范老人也能少讲很多重复的注意事项。5. 常见问题与避坑实录5.1 技能之间打架怎么排查多技能同时加载时最先遇到的一定是规则冲突。有个很典型的场景你同时导入了“周报生成”和“文档格式化”两个技能一个要求“标题用三级结构”另一个要求“所有文档尽量用一句话总结”模型就会困惑。我的排查套路分三步。第一步开启调试模式把最终拼进系统提示词的完整文本打印出来看看到底有哪些技能被注入。第二步检查技能清单里的优先级字段确保业务级技能比如周报优先于通用级技能比如格式化。第三步直接修改低优先级技能的描述在开头加一句“如果与其他技能冲突以更具体的技能为准”。这个问题最好的处理方式是提前预防定义技能时尽量让技能之间职责边界清晰加载时设置默认不加载通用技能只有特定任务命中时才加载。5.2 技能描述写得太抽象导致 AI 自由发挥我最早写技能的时候特别喜欢用“要逻辑清晰”“要重点突出”这种话。后来发现这跟没写一样因为模型不知道对你来说什么叫“重点突出”。你以为它会抓项目进展结果它抓的是你工作强度。解决方法是把抽象要求翻译成具体规则。把“要重点突出”翻译成“标题下方第一句话必须是最重要的事实”把“要逻辑清晰”翻译成“每个自然段只写一个事项段与段之间不要重叠”把“要简洁”翻译成“每条 30 字以内超过就拆成两条”。具体到可检查的规则模型才会照着做。这条经验最初来自一次让我很崩溃的测试我让模型“用专业语气写一份故障说明”它给我写了一段像论文摘要一样的东西措辞很严谨但没有一个有效信息。后来我把它改成“第一句写故障现象第二句写影响范围第三句写根因后续补时间线”输出立刻就能直接发出去。所以每次写技能描述的时候我都会问自己一个问题这条规则新来的实习生能看懂吗如果看不懂就再拆细。5.3 上下文超限如何瘦身技能多了上下文必然膨胀。我有一次把全部技能都设置成默认加载开源项目跑起来直接提示上下文超限最后模型干脆罢工了。瘦身原则我在前面讲过再展开一点技能文件里最占空间的部分通常是“详细示例”和“长输出模板”这两类内容不需要每次加载。我会把示例和模板单独拆成资源文件技能文件里只保留“按照模板文件 xx.md 输出”的索引。这样上下文开销能减少一半以上。另外可以给技能文件的steps字段设置数量上限这个字段越多响应越快但更占空间如果步骤超过 5 条可以把后面几条合并成“按既有流程处理”或者拆成子技能。尽量把每个技能控制在 600 字以内的描述量这算是我的经验红线。5.4 什么时候该放弃技能包改用代码控制技能包不是万能的。如果某个任务的执行过程中包含大量确定性逻辑比如必须查数据库、必须调用固定接口、必须做数据清洗那就应该直接用代码控制而不是让模型照技能描述自由发挥。我的判断标准很简单如果这个任务“给一个初级工程师做他会问 10 个问题”那就该上代码因为你需要的可能不是“学会工作方式”而是一个确定的结果。技能包最适合的是那种“执行路径稳定但输出内容灵活”的任务比如写周报、做需求分析、生成方案初稿。一旦任务变成“必须有精确的数据结果”就把它从技能包里摘出来写成工具函数交给模型调用。这个边界分清楚之后你的 Agent 会稳定很多你会少生很多气在后面测试的时候以上这些坑我基本上都踩过一遍尤其是“技能描述写得太抽象”那一次真的是浪费了我整整一个下午。但反过来正是这些坑让我把技能描述打磨成了现在的样子现在的规则越来越少但每一条都能被精确执行。我个人在实际操作中最大的体会是Agent-Skills 本质上不是一个技术项目而是一个“自我认知项目”。你得先清楚自己平时到底是怎么干活的才能把这些方法教给 AI。所以一开始不用急先挑一个高频任务跑起来再慢慢往技能库里沉淀几周之后你就会明显感觉到和 AI 的配合从“每次重新面试”变成了“老搭档干活”。最后再分享一个小技巧给每个技能写一个“失败示例”就是把你曾经觉得特别差的模型输出放进去旁边标注“这就是错误示范不要这样写”。实测下来这比任何抽象要求都管用AI 看完立刻就能避开最常见的坑。这个方法免费送给你不用谢。