大模型Skill入门基础教程（非常详细），收藏这一篇就够了！

我用 AI 差点让公司亏了一个项目。事情是这样的客户着急要一份软件需求的工时报价销售一个小时催了我三遍。我人都被催麻了差点想骂人。于是我让 AI 快速跑了两遍一次 157 人天一次 71 人天。差了一倍。后来我仔细看了下如果拿着 71 人天的结果去报价项目铁定亏。真的不禁后背发凉。这次我先安抚住客户和销售决定做一套 Skill 出来告别这种夺命连环催的状态。最后同样的需求每次跑出来的结果稳定、资源真实、格式统一而且只需要 10 分钟。今天我把这套方法论和完整源码开源出来见文末。一、五种常见的 Skill 设计模式在讲方法论之前我们先来了解下 Google 总结出的五种常见 Skill 设计模式。我在自己的实践中也验证了这几种模式的有效性这里结合我的理解做一个拆解。模式一知识注入型Tool Wrapper解决什么问题AI 的通用知识不够精准需要注入「只有你知道的」专业知识。核心思路把你的专业经验打包成 references 文件AI 在需要时自动加载按你的标准来做事。举个例子你让 AI 帮你写小红书文案但它写出来的风格总是不对要么太正式要么太浮夸。你可以把自己过去点赞量最高的 10 篇文案放进references/再在 SKILL.md 里写「模仿这些文案的风格」AI 就会照着你的调性来写。实际的 SKILL.md 长什么样●●●skills/writing-xhs-copy/SKILL.mdname: writing-xhs-copydescription: 按团队风格写小红书文案。当用户要求写小红书文案、种草笔记时激活。你是小红书文案助手。写文案前先加载 references/top-posts.md学习这些爆款文案的风格和结构。我们团队的文案规范AI 不知道的部分人设是「闺蜜分享」不是「专家推荐」禁用「强烈推荐」「必入」等营销词第一句必须是反问句或场景描写不能直接说产品名每篇控制在 300-500 字超过 500 字阅读完成率会断崖下跌图片说明统一用「p1:xxx p2:xxx」格式方便运营同事对图就是一个 Markdown 文件没有任何编程门槛。这是最简单的模式适合入门练手。模式二模板生成型Generator解决什么问题AI 每次生成的输出格式不一致结构飘忽不定。核心思路在 assets/ 里放一个输出模板让 AI 按模板结构往里填内容而不是自由发挥。举个例子你每天要写日报格式固定今日完成 / 明日计划 / 阻塞项。每次让 AI 写格式都不一样。那我们可以放一个日报模板进去让 AI 做填空题这样输出会稳定得多。同样的思路可以用在技术报告、项目周报、产品需求文档以及任何有固定格式要求的重复性产出。●●●skills/generating-daily-report/SKILL.mdname: generating-daily-reportdescription: 按团队格式生成每日工作日报。当用户说写日报、今日总结时激活。你是日报生成助手。严格按以下步骤执行加载 assets/report-template.md 获取日报模板询问用户今天做了什么明天计划做什么有没有阻塞项按模板格式填写注意以下团队要求每条必须带数据完成了3 个页面而不是若干页面阻塞项不超过 2 条多了拆到明日计划里语气用陈述句不要用我觉得可能等模糊表述输出完整日报不要遗漏模板中的任何章节注意模板越具体越好。别写 “请生成报告”而是给出每个章节的标题和填写要求。模式三审查打分型Reviewer解决什么问题你需要 AI 按照一套固定标准去检查、评估某个东西。核心思路把检查清单放在 references/ 里SKILL.md 定义审查流程加载清单 → 逐项检查 → 按严重程度分类 → 输出结构化报告。举个例子你写完一篇公众号文章想让 AI 帮你检查•标题是否有吸引力•开头 3 秒能不能抓住人•段落是不是太长•有没有错别字我们可以把这些检查项做成 checklist 放进去AI 就变成了你的私人编辑。这个模式最灵活的地方在于换一份 checklist就变成完全不同的审查工具。同样的骨架放代码规范进去就是代码审查放安全标准进去就是漏洞扫描。●●●skills/reviewing-articles/SKILL.mdname: reviewing-articlesdescription: 按团队标准审查公众号文章质量。当用户说帮我检查文章、文章审核时激活。你是公众号文章质量审查员。这个 Skill 只做检查不做改写。加载 references/review-checklist.md 获取检查清单通读用户提交的文章理解主题和受众逐项对照检查清单对每个问题标注严重程度必须修 / 建议修 / 供参考说明为什么是问题不要只说标题不好要说标题没有制造信息差用户没有点开的理由给出具体修改建议输出结构化报告先列必须修的再列建议修的最后给总分1-10关键要求 AI 不只说 “这里有问题”还要说 “为什么是问题” 和 “怎么改”。模式四反转采访型Inversion解决什么问题AI 总是在信息不足的情况下急着动手结果做出来的东西和你想要的偏差很大。核心思路翻转交互方向——不是你提需求 AI 马上执行而是 AI 先当采访者问清楚再动手。举个例子你说**「帮我规划一个日本旅行」**AI 二话不说就给你列了 7 天行程。但它不知道你只有 5 天假、预算有限、带着老人不能暴走、而且最想去的是温泉不是东京。如果 Skill 要求 AI 先问去几天预算多少同行人是谁有没有必去的地方问完再规划结果好几倍。●●●skills/planning-travel/SKILL.mdname: planning-traveldescription: 通过结构化提问收集需求后规划旅行行程。当用户说规划旅行、做攻略时激活。你是旅行规划师。在开始规划之前必须先完成信息采集。不要跳过任何问题不要在问题回答完之前给出行程方案。第一轮基本信息逐个问等用户回答去哪里出发时间和天数预算大概多少同行人是谁老人/小孩/朋友/独行第二轮偏好确认最想体验什么美食/文化/自然/购物有没有必去的地方有什么忌讳或限制不能爬山、怕冷、素食等第三轮输出方案所有问题回答完才执行加载 references/travel-tips.md 获取目的地踩坑经验旺季避坑、交通陷阱、本地人建议等。根据收集到的信息输出逐日行程包含交通、住宿建议和预算估算。看起来多了一轮对话实际上省了后面反复返工的时间。这个模式在实际使用中被严重低估了。大多数 Skill 失败的原因不是流程写得不好而是 AI 在信息不全的情况下就直接开始执行了。模式五流水线型Pipeline解决什么问题任务复杂、步骤多AI 容易跳步或遗漏关键环节。核心思路把任务拆成严格的阶段每个阶段有明确的输入、输出和检查点。上一步没通过验证不允许进入下一步。举个例子你用 AI 写公众号文章的完整流程先确定选题方向 → 列大纲让你确认 → 写初稿 → 自检标题吸引力、开头钩子、排版规范→ 生成终稿。如果你没确认大纲AI 不能开始写正文如果自检没通过不能输出终稿。每一步之间有明确的「关卡」。●●●skills/writing-wechat-articles/SKILL.mdname: writing-wechat-articlesdescription: 按流水线流程创作公众号文章。当用户说写一篇文章、帮我写公众号时激活。你是公众号写作流水线。严格按步骤执行不要跳步。第一步选题确认询问用户想写什么主题、目标读者是谁。输出 3 个选题方向供选择。→ 用户确认后才进入下一步。第二步大纲根据选题列出文章大纲标题 各段核心观点。→ 用户确认后才进入下一步。第三步写初稿按大纲写完整文章。加载 references/writing-style.md 遵循团队风格我们的号走「专业但不端着」路线禁用「赋能」「抓手」等黑话。第四步自检加载 references/quality-checklist.md逐项检查。检查不通过的自动修改通过后输出终稿。这是最重型的模式只在任务确实复杂时使用简单任务不要过度设计。怎么选一个简单的决策树你的核心需求选哪个模式AI 对某个工具/框架的用法不准知识注入型每次输出的格式不统一模板生成型需要按固定标准做检查审查打分型AI 总在信息不足时急着动手反转采访型任务步骤多且不能跳步流水线型最后一个重要提醒这五种模式不是互斥的它们完全可以组合。一个流水线型的 Skill 可以在第一步用反转模式收集需求在最后一步用审查模式做质量检查。记得设计 Skill 的时候先确定主模式再看是否需要在某个环节嵌入其他模式。二、进阶如何系统化地打磨一个 Skill我想说“能用”和“好用” 的 Skill 之间隔着一道巨大的鸿沟。很多人写完 Skill 之后的做法是跑一遍效果不好就凭直觉改几句描述、加几条约束再跑一遍……如此反复改了十几版也说不清楚到底是变好了还是变差了。问题出在哪没有参照物也没有衡量标准。下面我介绍一套「评测驱动」的打磨方法论。核心思路是不要猜 Skill 该写什么让失败告诉你该写什么。第一步建立基线发现问题在写任何 Skill 之前可以考虑先让 DeepSeek、Claude 直接做一遍你需要完成的任务。这一步的目的是为了发现问题就像医生开药之前先做体检你得先知道病在哪。重点观察三件事•AI 在哪些环节表现不稳定同样的输入结果时好时坏•哪些输入会让 AI 理解歧义、走偏方向•AI 有没有在不该主动的时候「自作聪明」把这些问题一条条记下来这就是你的 Skill 需要解决的真实缺口也是后面所有测试用例的来源。这里有一个简单的判断标准大家习惯叫它「五分钟测试」如果 DeepSeek 就能在 5 分钟内给出稳定的结果你大概率不需要为这件事写 Skill如果 5 分钟内搞不定、或者结果时好时坏那才是 Skill 真正的切入点。第二步定义验收标准这一步反直觉但非常关键。大多数人的做法是先写 Skill → 然后想怎么测试。但正确的顺序是反过来先定义「什么算做对了」再写 Skill 去达标。具体做法•根据第一步识别的问题设计 3-5 个具体的测试用例•每个用例有明确的「通过」和「失败」标准•优先覆盖 AI 最容易犯错的场景为什么要这么做因为没有测试约束的 Skill本质上是在放大 AI 行为的不确定性。你加的每一条规则如果不知道它在解决什么问题就可能会继续制造新的问题。第三步写最小版本的 Skill现在才开始写 Skill。但注意不要试图一次覆盖所有情况写能通过测试标准的 MVP 版本。重点做三件事1.写”什么时候不要用“把最开始发现的误触发场景写进去作为第一道防线。2.定义最短成功路径用最少的步骤描述核心流程确保最基本的输入能得到稳定的输出。3.保持单一职责一个 Skill 只解决一个明确的问题。这个阶段的 Skill 会很简陋但它是有针对性的。每一条规则都是在回应一个真实的失败案例而不是凭经验预判。第四步通过测试后再逐步扩展最短路径跑通了再一点点增加覆盖范围•补充更多边界场景的处理规则•明确输入输出的格式定义•加入关键的示例帮助 AI 对齐预期核心纪律每增加一条新规则都必须对应一个测试用例。没有测试支撑就加规则等于在 Skill 里埋盲区。同样重要的是知道什么时候该停。规则太多反而会让 AI 行为变得不可预测——它在多条指令之间纠结结果哪条都执行不好。如果你的 Skill 已经稳定通过所有测试就别再往里塞东西了。第五步给 Skill 加上记忆和验收标准当 Skill 的核心逻辑稳定之后补上两个让它从「能用」变成「好用」的东西记忆在 Skill 目录下放一个日志文件每次执行完追加记录下次执行前先读。这让 Skill 知道上次做了什么避免重复产出。哪怕只是一个简单的文本文件效果也天差地别。但注意不要把记忆文件写成流水账。长期记忆是有 token 上限的只记录反复出现的模式和真正重要的经验不要什么都往里塞。验收标准明确写出什么算成功、什么算失败。这不只是给你看的也是给 AI 看的。AI 可以用这些标准做自检在提交最终结果前先自查一遍。第六步上线后持续校准测试用例只能覆盖你已知的问题但是真实场景中一定会冒出新的情况。Skill 上线后重点观察这几个信号•AI 在你没预期的场景下误触发了这个 Skill→ 说明 description 需要收窄•AI 执行时漏掉了关键的参考文件→ 说明 SKILL.md 里的引用不够明确•AI 反复读同一段内容→ 说明那段内容可能应该放到更醒目的位置每发现一个新问题就回到第二步补一个测试用例再改 Skill。这是一个持续转动的闭环不是一次性工程。如果要在龙虾里使用 Skill一个建议这六步的打磨过程建议先在 Claude Code 里完成。Claude Code 的执行过程是透明的你能看见 AI 每一步读了什么文件、调了什么工具、在哪个环节卡住了。因为 OpenClaw 封装更深Skill 跑不好时你分不清是 Skill 的问题还是环境的问题。在 Claude Code 里调到满意再交给 OpenClaw 稳定运行。三、实战案例售前工时评估 Skill前面讲了方法论可能还是有点抽象。这里用我自己的一个真实案例把六步串一遍。场景其实开头已经介绍过了。这里给大家再感受下那种紧迫感PS1个小时内夺命三连催。这种场景不是第一次了。售前评估几乎永远是急活。客户催销售销售催你每次都是熬大夜熬出来的。流程每次都一样拆需求 → 匹配人 → 算工时 → 套模板。流程固定、输入不同、反复发生这就是 Skill 该干的事。所以这件事已经到了让我非做不可的地步了。第一步建立基线发现问题我没有一上来就写 Skill。先让扔给 Claude 测试一下把客户需求原文扔给它说「帮我出一份工时评估报告」。结果能出来但问题一堆我发现 Claude 需求分析太泛不了解我们的模块结构和技术栈分析全是正确的废话。而且它也不知道团队有谁、谁擅长什么给了一堆角色但是有些角色我们甚至没有。后来我尝试生成两次后发现每次格式都不一样无论是样式还是内容框架。最可怕的是两次的人天相差巨大几乎翻了一倍。第一次 157 人天第二次 71 人天。后来我基于 Skill 生成的版本和裸跑版本做了对比内部认真分析了一下。如果一不小心拿到第二次的人天项目得亏麻了。总结下来就是 6 个字有框架没质量。第二步定义验收标准把基线建立时暴露的四个问题翻译成验收标准1.需求分析必须关联项目真实模块不能出现通用废话2.人员配置必须输出真实姓名技能等级和负责模块对得上3.工时评估必须有代码层面的依据4.报告结构固定七章不多不少后面每改一版都用同一段需求跑一遍对着这四条逐项检查。不用复杂的测试框架手动过一遍就行但有了「通过/不通过」标准改起来就不是盲调了。当然这里也可以做一个自动检查报告的 Skill把这些验证标准写进去让 AI 自动运行。第三步MVP 版本 Skill第一版就是一个 SKILL.md●●●name: req-to-hours-estimatedescription: 基于需求输出工时评估报告。按固定四步流程执行需求分析 → 生成开发文档 → 匹配资源 → 输出报告。用于售前需求评估、项目报价等场景。需求转工时评估报告工作流程第一步需求分析基于用户提供的原始需求进行分析识别核心痛点挖掘潜在需求风险评估将需求拆分为用户故事格式作为[角色]我希望[行为]从而[目的]第二步生成开发文档基于需求分析结果输出结构化开发文档功能描述影响范围注意点/风险项待确认项验收标准第三步匹配资源配置根据开发文档给出资源配置建议前端开发人员及职责后端开发人员及职责测试人员及职责第四步工时评估与报告生成综合以上信息按报告模板输出工时评估报告。工时评估报告模板必须严格按照以下七章结构输出不多不少。# 售前工时评估报告 ## 一、需求概述 ### 1.1 需求背景 ### 1.2 核心痛点 ### 1.3 潜在需求 ### 1.4 风险提示 ## 二、功能范围 ### 2.1 用户故事拆解 ### 2.2 功能清单 ## 三、技术方案 ### 3.1 涉及模块 ### 3.2 技术栈 ### 3.3 影响范围 ## 四、资源配置 ### 4.1 前端开发 ### 4.2 后端开发 ### 4.3 测试人员 ## 五、工时评估 ### 5.1 工时明细 ### 5.2 工时说明 ## 六、待确认项 ## 七、报价建议它只做了两件事1锁死工作流程把评估拆成四步流水线需求分析 → 生成开发文档 → 匹配资源 → 输出报告。每步的输入输出写清楚严格按照预定的步骤执行。2定输出模板七章报告模板写死在 SKILL.md 里按模板填内容不允许 AI 自由发挥。验证标准第 4 条立刻通过。但前三条还是不行AI 依然在造数据。没关系最小版本的目标不是满分先完成再完美。第四步补充 AI 不知道的上下文骨架确定后该解决 AI 造数据的问题了。这时候我发现要补充的资料其实早就有了。员工能力矩阵、模块结构文档、踩坑规则库都是过去管理中沉淀下来的只是每次都想不起来要喂给 AI。PS主要还是太繁琐文件分散在各地搜索成本太高。1、内部知识注入解决「分析太泛」最开始测试时AI 的需求分析为什么只是浮于表面因为它只看到客户那段话不知道在我们系统里会牵动哪些模块、踩到哪些坑。那么接下来我给它灌输内部知识。但我没有把这些所有资料直接塞进主 Skill。“需求转开发文档”这个步骤未来一定会单独使用。不是每次都可能出现「评估工时」这个场景有时候内部的简单需求也需要变成结构化的开发任务。所以我把它抽成了独立的子 Skillreq-to-dev-doc主 Skill 调用它其他场景直接复用。写 Skill 时多想一步这个能力是只服务当前流程还是本身就有独立价值如果是后者拆出来未来你会感谢自己的。主 Skill●●●第二步生成开发文档调用 skill/req-to-dev-doc将需求转换成结构化开发文档包含用户故事功能描述影响范围注意点/风险项待确认项验收标准需求转开发文档 Skill:●●●name: req-to-dev-docdescription: 将简单需求描述转换为结构化开发文档适用于xxx平台的需求整理。当用户提供需求说明一句话或详细描述并希望生成开发文档、需求卡片、验收标准时使用此 skill。输出内容结合平台模块的业务规范和注意点减少研发返工。需求转开发文档工作流程读取references/module-structure.md判断最可能涉及的模块提取该模块的【模块依赖/变更风险/注意点长期边界】作为约束与风险来源读取references/impact\_rules.md先扫描 L0 必跑规则明确“命中哪些规则”必须显式输出规则编号再按第 1 步的模块检索 L1 规则补全“必查落点、回归对象、风险与待确认项”若模块不明确先按“通用能力”生成卡片并在【待确认项】列出需要确认的模块/入口不要阻塞输出按模板输出任务卡片重点把命中规则转成【影响范围/风险项/验收标准】里的具体“落点”和“回归清单”只写可执行内容不写背景长文若需求涉及模块不明确先询问用户确认模块范围再生成文档。输出模板每个需求输出一张卡片严格按以下结构…规则…我解读下这次优化我将两份关键文档放进req-to-dev-doc的 references 里1系统模块地图module-structure.md这份文档就像一张宝藏地图包含系统几十个模块的基础介绍、相关对象实体、各个模块之间的依赖关系、变更风险和红线。我挑了一个脱敏简化后且大家熟知的“定时任务”模块给大家看下●●●模块结构文档模板**格式约定** 每个模块按以下维度描述**实体** — 涉及的核心数据对象**核心功能** — 该模块做什么**依赖** — 与其他模块的关系★强依赖 / ○数据依赖 / △触发依赖**变更风险** — 改这个模块时容易踩的坑**红线** — 绝对不能违反的规则示例定时任务模块**实体** 定时任务 / Cron 表达式**核心功能**定时任务增删改查任务类名唯一性校验基于字典编码Cron 表达式配置与校验系统内置任务只读保护readonly0 不可修改**依赖** △系统日志 / 消息通知 ○权限管理**变更风险**修改任务类名 → 反射创建 Job 实例失败运行时才暴露修改 Cron 解析逻辑 → 所有已有定时任务的调度时间全部异常**红线**删除数据库中的任务记录前**必须**先停止调度器中对应的任务不得绕过QuartzJobService直接操作数据库任务表Job 类中不得执行耗时过长的操作会阻塞调度器线程池这份文档除了帮助 AI 快速建立业务认知之外也能有效地防止 AI 犯一些基本的错误。比如你改了A模块它会告诉你要同步检查B、C、D模块。并且会禁止你做一些内部总结提到的危险操作。这些事情交给 AI 是猜不出来的。2影响范围规则库impact_rules.md前面的模块地图解决了“需求落在哪里怎么避免犯错”而这份规则库则解决了”容易漏做什么怎么按照有效路径排查问题”团队踩坑沉淀的规则分三层•L0 是必查规则是内部过去提炼的所有模块都容易犯错的点。•L1 是模块级规则细化到每个业务模块。•L2 是历史典型事故案例可选仅起到辅助人和 AI 理解的作用保持精炼。●●●变更影响规则库写法**触发条件 → 必查落点**短、直接、可执行L0必跑规则拿到需求都过一遍| 编号 | 规则名称 | 触发条件 | 必查落点 ||------|---------|---------|---------|| L0-1 | 字段表现类 | 涉及精度/格式/校验/默认值/联动 | 编辑态 详情态 列表态 导入导出 || L0-2 | 通用接口类 | 改动落在通用CRUD/保存/校验链路 | 判定是否通用 → 列回归对象清单 || L0-3 | 状态流程类 | 涉及状态字段/审批/撤回驳回 | 业务状态↔流程状态同步 审计日志 || L0-4 | 历史兼容类 | 新增规则/旧数据可能不满足 | 代码兼容 迁移脚本 历史样本验证 || L0-5 | 配置项策略 | 出现阈值/开关/枚举等参数 | 不允许写死 → 明确谁维护、默认值 || … | 按团队经验持续补充 | | |L1模块规则按模块细化补全| 模块 | 触发条件 | 必查落点 ||------|---------|---------|| 通用能力 | 数字精度调整 | 列表/详情/编辑/筛选/导出 前后端一致 || 通用能力 | 枚举/字典调整 | 历史值兼容 筛选项 导入导出映射 || 工作流 | 审批规则调整 | 历史实例兼容 审批记录不可篡改 || 权限 | 按钮/字段权限调整 | 前端控制 后端兜底 导出权限一致 || … | 按业务模块持续补充 | |L2案例库事故沉淀反哺规则| 事故描述 | 命中规则 | 补救措施 ||---------|---------|---------|| 价格精度只改了编辑页列表未同步 | L0-1 | 补查所有展示入口 || 改了新增接口导致关联模块创建异常 | L0-2 | 通用接口必列回归清单 || 新规则上线历史数据无法编辑 | L0-4 | 补迁移脚本 历史样本回归 |有了这两份资料AI 不再泛泛地写“可能影响其他模块”。而是相对精确命中规则”命中 L0-7历史数据兼容、L1-9数据结构脚本“逐条列出必查项和回归清单。这样拆得越细后面估工时越准。备注这个规则库也不是一成不变的我还设计了一个 FAQ Skill 来反哺规则库这样团队运转中高频发生的问题和总结就会自动落到规则中形成高效闭环。小结一下这一步的本质就是用内部知识把模糊的客户需求翻译成精确的开发任务。2、补充「员工能力矩阵」解决「资源虚构」这次我把团队所有人的角色、技能等级整理成employee-data.md。考虑到匹配资源在未来也可能被复用所以单独封装了一个 Skill/dev-doc-match-resource。并且在主 Skill 中调用它。主 Skill●●●第三步匹配资源配置调用 Skill/dev-doc-match-resource基于开发文档和员工能力资源矩阵分析匹配资源配置前端开发人员及技能等级后端开发人员及技能等级测试人员及负责模块资源风险提示资源匹配 Skill●●●name: dev-doc-match-resourcedescription: 基于开发文档分析匹配当前开发方案的资源配置。结合能力资源矩阵文件employee-data.md根据开发文档中的模块、技术栈、复杂度等维度匹配合适的开发人员、测试人员及其能力等级输出资源配置建议。用于需求评估阶段的资源安排参考。开发文档资源配置匹配工作流程读取references/employee-data.md解析每位员工的角色、技能等级、负责的模块信息技能等级说明1-了解 | 2-熟悉 | 3-精通分析开发文档内容识别涉及的模块xxx 功能等识别所需技术栈Java、Python、Vue、MySQL、Redis、中间件等评估开发复杂度新增/修改、前端/后端、是否涉及集成匹配资源配置根据负责模块字段匹配主要开发/对接人员根据技术需求匹配技能等级合适的人员根据测试责任匹配测试负责人输出资源配置报告输出模板# 资源配置建议 ## 需求概述 - 涉及模块xxx - 技术栈xxx - 复杂度评估低/中/高 ## 人员配置 ### 产品设计 | 姓名 | 技能等级 | 擅长模块 | 负责内容 | 说明 | |------|---------|---------|---------|------| | xxx | 3 | xxx | xxx | xxx | ### 前端开发 | 姓名 | 技能等级 | 擅长模块 | 负责内容 | 说明 | |------|---------|---------|---------|------| | xxx | 3 | xxx | xxx | xxx | ### 后端开发 | 姓名 | 技能等级 | 擅长模块 | 负责内容 | 说明 | |------|---------|---------|---------|------| | xxx | 3 | xxx | xxx | xxx | ### 测试人员 | 姓名 | 负责模块 | 测试类型 | 说明 | |------|---------|---------|------| | xxx | xxx | xxx | xxx | ## 资源风险提示 - xxx ## 补充说明 - xxx配置规则优先匹配负责模块中明确的人员技能等级3为首选2为备选1需评估复杂度高、涉及核心模块需配置高技能等级人员涉及系统集成需确认相关经验参考资料references/employee-data.md部门员工能力数据包含角色、技能等级、负责模块等详细信息但第一版只写了角色和等级AI 匹配还是不够精准不知道谁熟悉哪个具体模块。于是迭代中我又补了一列**「业务领域」**精确到每个人熟悉的业务模块。补完后AI 输出的不再是**「高级开发 1 名QA 1 名」**。而是**「小明精通系统底层/导入中心负责核心引擎小李熟悉化工模块负责业务适配」。**验证标准第 2 条通过。如下是我整理的一份模板大家需要可以自取●●●团队员工能力数据最后更新2026-04-01建议每季度 review 一次技能等级1-了解 | 2-熟悉 | 3-精通等级校准1-了解学过/用过需要指导才能完成任务2-熟悉能独立完成常规任务遇到复杂问题需要查资料3-精通能独立解决复杂问题能指导他人能做技术方案业务领域等级1-接触过了解基本功能做过少量相关任务2-能独立处理能独立处理该领域常规需求3-深度掌握熟悉业务规则、历史坑点和跨模块影响业务领域范围请根据实际项目自定义系统底层基础设置/权限/系统管理工作流流程引擎/通知/定时任务业务模块A填写你的核心业务模块如订单/商品/库存业务模块B填写你的次要业务模块如报表/审批/合规通用功能导入导出/附件/搜索/工具类/组件库李明角色高级后端开发核心模块开发、带新人、技术攻坚业务领域系统底层(3), 业务模块A(3), 通用功能(3), 业务模块B(2)开发语言Java(3), Python(2), Vue(2), JavaScript(2)数据库/缓存PostgreSQL(3), MySQL(3), Redis(3)中间件RocketMQ(3), Quartz(3), Elasticsearch(2), Minio(1)系统集成OA(2)云原生/DevOpsDocker(3), Kubernetes(2), CI/CD(Jenkins/GitLab)(2)测试功能单元测试(2), 自动化测试(2)软技能需求分析(2), 技术调研(2), 方案评审(2), 培训(2)负责模块主要对接人[系统] 对象管理、模型管理、定时任务[业务模块A] 核心数据处理、数据导入平台[通用功能] 全局搜索、文件下载、在线编辑补充能力矩阵有两个重要的作用1.专业的事情交给专业的人来做降低项目风险。2.即使项目立刻开始管理者也能够基于资源分配情况从容编写计划为后期做好铺垫。3、基于项目代码扫描我认为这是非常关键的一次优化。和普通 AI 聊天工具最大的区别在于它是基于我的项目代码本身进行评估的。●●●结合当前项目相关代码进行工时评估**搜索相关代码**搜索涉及模块的代码文件识别 Entity、Service、Controller、Mapper 等层次分析现有代码复杂度和可复用性从而让 AI 搜索需求涉及的模块思考•哪些代码已经存在•哪些代码可以复用•需要新增的代码量多大「能复用多少」和「要增加多少」都写进报告这样工时终于有了更可靠的代码层面的依据。验证标准第 3 条通过。到这里四条验证标准全部通过。第五步加验收标准和脚本1、验收标准写进 SkillSKILL.md 末尾加了自检清单AI 输出前先自查结构、数据的一致性、风险是否预留了。如果自检不过就自动修改不用我再次指挥 AI 进行返工。●●●第五步输出自检报告生成后逐项检查以下内容发现问题立即修正后再输出给用户结构完整性七个章节需求概述、功能范围、技术方案、资源配置、工时评估、待确认项、报价建议是否齐全数据一致性工时明细表的合计行 各行之和报价建议中的工时数 工时明细表的合计数资源配置中的人员 工时明细表中涉及的角色技能等级调整系数是否已正确应用风险预留是否按复杂度等级计入了对应比例的风险预留2、加了 Word 生成脚本●●●输出格式说明前四步的分析流程始终执行输出格式仅影响最终呈现方式**默认输出**Markdown 格式报告直接在对话中展示**仅需 Word 文档**用户明确要求时跳过 Markdown 输出直接将各字段组装为data字典调用references/generate\_word\_report.py中的ReportGenerator().generate(datadata)生成文件依赖安装pip install python-docx基本上客户要 Word不是 Markdown。每次让 AI 转格式排版都不一样这种确定性任务不该让 AI 自由发挥。所以我让 AI 写了一个generate_word_report.py放 scripts/ 里AI 填数据脚本管排版从此每次都一样。第六步上线后持续校准后续又跑了几个需求发现新问题客户需求描述太简略时AI 会「脑补」过度生成客户没提的功能。补了一条约束「如果原始需求信息不足先列待确认项不要自行补全」下一步我打算把过去项目计划的信息收集一下。这样每个项目的预估工时和实际工时都有了再让 AI 进行「类比估算」基于历史项目计划数据推算结果将更加准确。最终效果对比维度没有 Skill有 Skill耗时半天到一天复杂的好几天10-15 分钟输出格式每次不一样七章固定直接生成 Word人员配置编造泛泛的岗位名按真实团队能力精准匹配工时评估拍脑袋代码扫描 技能系数交付质量大量人工返工AI 自检后输出微调即可回看整个过程完美对应六步打磨法●●●① 建立基线发现四个问题② 把问题翻译成四条验证标准③ 最小版本解决流程和格式④ 逐步补 references、拆子 Skill每次回应一个真实失败⑤ 加验收标准 脚本解决确定性输出⑥ 新场景暴露新问题回到②补标准继续循环没有一步到位每一次改动都是在回应一次失败。这就是「评测驱动」的核心不要猜该写什么先发现问题让它告诉你该写什么。整个过程中最值钱的不是流程不是模板。而是那些「只有我们团队知道」的经验和规则模块地图、踩坑规则库、员工能力矩阵。这恰恰印证了前面的原则提供 AI 不知道的上下文。对照五种设计模式这个 Skill 不是单一模式而是四种模式的组合体现在哪对应模式四步严格按顺序执行上一步没完成不进下一步流水线型主模式模块地图、规则库、能力矩阵作为 references 注入知识注入型七章报告模板写死AI 按模板填内容模板生成型AI 输出前按自检清单逐项检查不过不交审查打分型五种模式不是互斥的而是可以组合的。先用流水线定骨架在关键环节嵌入知识注入、模板生成和审查打分各司其职。这可能是我发现的最好用的 Skill 开发路径了。四、Skill 开源我将工时评估的完整 Skill 源码开源了。如果觉得有用记得帮我点个Star感谢●●●地址 https://github.com/jaylpp/pandajay-skills五、写在最后还记得开头那组数字吗157 vs 71。差距不是因为 AI 不行而是没人告诉它该怎么做。模块地图、踩坑规则、团队能力矩阵。这些 AI 永远猜不到的东西才是 Skill 真正值钱的部分。Skill 填的不是技术的坑是「理解」的坑。你教给 AI 的每一条规则都在缩小「它能做的」和「你想要的」之间的距离。总之这件事越早开始复利越大。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】