很多玩模拟选秀的人都容易陷入一个误区我练了足够多次为什么真正上场时还是手忙脚乱原因往往不在“练得不够”而在“练得不像”。你在公开的 mock draft 平台上选的是 ESPN 默认规则、默认名单、默认队友风格但轮到自己联盟实战时位置人数不同、计分规则不同、选秀签位不同甚至联盟里其他人的选人偏好也不同。平台练出来的“手感”和你真实要面对的选秀压力完全是两件事。Realer Mock Draft 这个项目名字看起来只是在发布一个模拟选秀工具但它真正值得开发者关注的点是标题里后半句话a skill file to base the mock on YOUR league。也就是说它不是又一个“基于全平台通用数据”的选秀模拟器而是一个把模拟选秀变成“基于你所在联盟自定义数据”的技能文件。这篇文章不依赖某个具体仓库的源码而是从这类 skill file 的设计思路讲起。你可以先理解它要解决的问题再动手做一个属于自己联盟模拟选秀技能。读完你会明白模拟选秀真正值钱的地方不在 AI 挑选算法有多聪明而在它有没有读懂你这一个联盟。1. Realer Mock Draft 要解决的真实问题先还原一个选秀场景。假设你所在的 fantasy league 采用的是 0.5 PPR 计分10 支球队每支队伍要求首发 1 名四分卫、2 名跑卫、3 名外接手、1 名近端锋、1 个 FLEX、1 名踢球手和 1 个防守组。你手里握有第 4 顺位。真正决定你赛季基调的几乎就是前 6 轮决策。于是你决定认真准备打开常规的模拟选秀网站开始一轮一轮地练习。但问题很快就暴露出来。那些平台上的模拟选秀默认使用的是它们自己的标准联盟模型也许计分规则是 1 PPR也许外接手只要 2 人也许踢球手根本不算在模拟范围内。你练到第二轮发现平台预测比你更早抢走跑卫是因为它的联盟模型里跑卫权重更高你的联盟则允许多一个外接手 slot这让外接手的边际价值明显变高。按平台的逻辑练习你练出的只是“通用策略”不是“你所在联盟的策略”。Realer Mock Draft 正是在这个问题上做文章。它把“你所在联盟”的数据——球队数量、轮次、位置设置、计分方式、你的签位——作为一个前置输入让模拟选秀引擎不再拍脑袋按默认值推算。从公开信息看它采用的是“一个技能文件”的形态也就是说输入自定义数据后AI 或模拟引擎可以在当前联盟上下文里完成推演。这意味着它的核心价值不在“随机生成一组可供参考的选秀名单”而在于每一次模拟都带着你联盟的约束条件。约束越真实练习越接近实战。什么人最需要关注这类实现简单说有三类自己管理或参与一个固定 fantasy 联盟、想提高实战选秀质量的玩家对 Agent Skill、提示词工程、可复用的技能文件感兴趣的 AI 开发者想做“个性化决策辅助”类产品的技术人因为它的思路完全可以平移到其他垂直领域。这里的思路本质是把“公共知识”和“私有上下文”分离。选秀方法论是公共知识可以写进提示词或文档但你联盟的特定规则、当前可选球员池、你自己的持股状态则是私有上下文必须由用户提供。如果这个边界没分清楚AI 给出的模拟就只是泛泛而谈。2. skill file 到底是个什么东西要理解 Realer Mock Draft 为什么用 skill file 这个形式得先理解 skill file 在 AI 开发里的定位。2025 年以来随着以 Claude Skills 为代表的能力开放技能文件逐渐成了 AI Agent 应用里一个很常见的概念。它本质上是一个目录集合里面至少有一个用 Markdown 写成的说明文件比如 SKILL.md用来告诉 AI 这个技能什么时候该被调用、需要什么输入、应该按什么步骤执行任务。目录里还会附带该技能运行所需的参考数据、脚本模板或资源文件。很多人第一次听到 skill file会以为它只是又一个“提示词模板”。这个理解不够准确。提示词模板解决的是“某一次对话应该怎么回答”skill file 解决的是“某一类任务应该如何稳定地完成”。差别在于提示词模板只能影响上下文里的措辞skill file 则把任务相关的知识、流程、校验脚本和样本数据打包在一起让 Agent 在需要时按需加载。可以借用日常生活中的“菜谱包”来理解。普通提示词就像你告诉朋友“帮我做一道红烧肉”对方能不能做出来取决于他当时的记忆和发挥。skill file 则像你递过去一个密封好的料理包里面有标准菜谱、配好的调料包和处理步骤。只要打开的人识字、能按步骤操作出品就会稳定很多。skill file 也不是平台专属的东西。虽然不同工具对技能文件格式有自己的约定但通用结构通常包括skill 名称与描述用于让 Agent 判断什么时候触发主指令文件包含分步骤的操作方法资源文件夹用来放数据模板、样本、图片等脚本文件夹必要时放可执行的校验或处理工具。从实现角度来看skill file 的出现解决了一个很实际的工程问题系统提示词或主提示词不能无限膨胀。如果你在一个长期任务里把所有领域知识都写进系统提示词总会有冲突和注意力稀释。技能文件按需加载任务用不到的时候不占用上下文一旦检测到用户需求匹配再把相关知识和步骤提取出来使用。所以 Realer Mock Draft 把项目定位成“a skill file”本身就是一个合理的技术选择。它的优势不是聊天式临时发挥而是标准化你的联盟数据准备好之后每次运行都使用同一套流程生成结果更可复现也更容易调整规则。3. “基于你联盟”模拟选秀的三段式设计如果我们想自己实现一个能“基于你的联盟”出结果的 mock draft 技能不需要一开始就做成一个完整平台。拆开看它可以被简化成三段式流程。第一段是“解析联盟上下文”。系统需要知道你联盟的球队数量、选秀轮次、各位置人数、计分规则、你的轮次和签位以及当前已经选入球队的球员名单。这一部分本质上是一份结构化的联盟设置数据最好独立成文件不要埋在自然语言描述中。第二段是“加载当前可选球员池”。模拟选秀不是凭空生成球员。它需要知道当前可供挑选的范围哪些球员已经被选走哪些还没被选每个球员的位置、预期得分数据、伤病信息等。这部分是整个模拟的现实基础。如果球员池数据不完整后续所有推荐都没有意义。第三段是“执行选秀决策”。根据联盟规则和当前需求在每一轮判断哪个位置最缺人、哪个可用球员价值最高然后用规则去约束它不能选已经离队的球员不能超出阵容上限不能忽略你还没有满足的位置需求。这个三段式流程的关键是把规则和数据解耦。传统模拟选秀的做法是把规则固化在平台内部用户能设置的内容很少。而这类 skill file 的灵活之处在于规则层面可以写在技能说明里数据层面由用户自己替换技能本体的代码和提示词不需要改动就能适配不同联盟。换句话说传统模拟器是“引擎决定规则用户只能选参数”skill file 方案则是“引擎提供方法论规则和数据全部由用户输入决定”。后者更透明也更适合个人把数据控制在本地。再把“通用模拟”和“Realer Mock Draft 式的联盟模拟”放到一起对比差异会更明显。对比维度通用模拟选秀基于联盟数据的 skill file 模拟规则来源平台内置默认规则你提供的联盟设置文件球员池范围平台维护的全量球员池你指定或导入的当前可用球员池选秀状态每次从零开始或按默认进度可读取你已经选中的球员模拟后续轮次结果针对性练通用策略练你所在联盟的真实约束可维护性规则由平台控制规则和数据文件可控可版本化管理有一句话可以概括模拟选秀工具的 AI 能力并不稀缺稀缺的是对“你的联盟”的上下文理解。谁把上下文处理得越细谁的结果就越接近实战。4. 环境准备与前置条件动手做一个 mock draft skill 并不需要很复杂的运行环境。你只需要三样东西一个支持技能文件机制的 AI 客户端或开发框架、一个存放项目文件的目录、一份你想用来练习的联盟数据。先说 AI 运行环境。这里并不限定某一个具体产品因为不同平台的技能文件规范更新较快且命名方式还有差异。更稳妥的做法是先查阅你使用的平台文档确认它支持哪种技能目录结构是直接用文件夹路径还是需要把说明文件放到特定名称的目录中。若没有平台环境也可以用通用 Markdown 文件先编写内容等有兼容环境时再导入。再说项目目录。建议为这个 Skill 单独建一个文件夹并用 Git 管理。选秀数据会随赛季变化每次调整规则或更新球员池后你需要能看清改动内容也需要能随时回滚。目录设计本身不需要复杂但建议从一开始就保持清晰my-mock-draft-skill/ ├── SKILL.md ├── assets/ │ ├── league_settings.example.json │ └── player_pool.example.csv ├── scripts/ │ ├── validate_data.py │ └── recommend_pick.py └── README.md其中 SKILL.md 是技能主说明assets 放联盟设置和球员池的样例scripts 放可选校验脚本README 记录数据来源和更新方式。最后说数据来源。需要特别提醒一下合规性不要绕过平台规则抓取私有数据。你的首要数据来源应是自己有权访问的联盟导出文件或者是你自己手动维护的最小测试集。为了练习技能开发一开始不需要真实完整数据只准备 5 到 6 条球员记录的小样例就能跑通流程。环境准备阶段不需要担心版本细节因为真正的技能内容是一份 Markdown 说明加几份结构化数据。这类文件几乎不依赖特定运行版本迁移成本很低。你当然可以用纯文本编辑器完成所有工作但如果希望后续运行脚本验证数据建议安装 Python 3.9 或以上版本并准备一个 CSV/JSON 预览工具。5. 编写 SKILL.md一个最小可用的说明骨架现在进入正题怎么把“基于我的联盟生成 mock draft”这个意图写进一个技能文件先理解 SKILL.md 的基本机制。绝大多数 Agent 在判断是否加载某个技能时会先读取说明文件开头的一段结构化信息特别是 name 和 description。description 写得好不好直接决定用户提出需求时该技能是否会被正确触发。一个常见的写法是在 Markdown 文件开头用 YAML frontmatter 声明元信息正文则用分步骤 Markdown 指令描述执行过程。参考案例如下--- name: realer-mock-draft description: 基于用户提供的联盟设置文件和球员池文件生成符合该联盟规则的模拟选秀建议。当用户提到 mock draft、模拟选秀、选秀练习并且希望按自己的 fantasy 联盟规则进行时使用。 --- # Realer Mock Draft Skill 目标根据用户所在联盟的规则、当前选秀进度和可用球员池提供下一轮推荐及完整模拟轮次结果。 ## 执行流程 1. 获取联盟设置文件。 - 若用户没有提供先要求用户上传。 - 字段缺失时列出缺失字段并停止不要猜测默认值。 2. 获取球员池文件。 - 确认球员池中每条记录包含球员 ID、姓名、位置、团队、状态与预期得分。 - 若文件为空或格式错误提示用户重新上传。 3. 确定当前选秀状态。 - 询问用户当前已经选到的球员编号或在数据文件中读取已选状态。 - 根据联盟设置中的轮次、签位和已选名单判断接下来轮到谁。 4. 执行决策。 - 按位置需求缺口与球员预期价值排序。 - 过滤已被挑选、状态异常或不符合位置限制的球员。 - 给出推荐球员并说明推荐理由。 ## 输出格式 对每一轮输出 - 本轮应选球员姓名 - 位置 - 推荐理由 - 如果该轮设置了稍后选择可额外给出 2 个备选球员 ## 注意事项 - 不要编造球员数据。 - 如果联盟规则里没有明确支持某一计分方式不要自行假设。 - 用户没有授权时不读取或上传联盟外部私有数据。这个骨架看起来简单却已经能够解决很多问题。它明确告诉 Agent输入必须由用户提供录入时先校验没有数据就停下不猜测决策过程中要结合位置需求和当前状态。这三条规则是 mock draft 模拟结果真实性的保底。SKILL.md 的 description 还有一个值得琢磨的地方不要写得太宽泛也不要写得太窄。太宽泛会导致 AI 在用户问“帮我推荐一个球员”这种普通问答时也触发技能太窄则用户说了“练练选秀”它可能反应不过来。更合适的写法是把“mock draft、模拟选秀、选秀练习、用自己的联盟规则”这几个语义点都放进描述里。编写这个文件时还有另一个很容易踩的坑试图在 SKILL.md 里把所有选秀经验和策略都写进去。技能文件不是知识库它的核心是流程和边界。通用球员价值策略更适合放在 resources 或 assets 文档里由技能在需要时查看。一旦主指令过长Agent 反而容易忽略关键步骤。6. 联盟数据结构让 Skill 认识你的真实规则如果说 SKILL.md 是技能的“大脑”那联盟设置文件和球员池文件就是技能的“眼睛”。没有这两份数据技能再好也无法针对你的联盟给出结果。先看联盟设置文件。它应该用 JSON 这类结构清晰、容易校验的格式描述。你不必把所有数据塞进一个字段而是拆成几个有意义的模块。下面是一个简化的样例字段含义可以直接对应到实际联盟中{ league_name: Weekend Warriors, draft_type: snake, teams: 10, rounds: 15, your_pick: 4, roster: { QB: 1, RB: 2, WR: 3, TE: 1, FLEX: 1, K: 1, DEF: 1, BENCH: 5 }, scoring: { pass_td: 4, pass_yd_per_point: 25, interception: -2, rush_td: 6, reception_point: 1 } }这份 JSON 描述了 10 支球队、蛇形选秀、15 轮你的签位是第 4 顺位。roster 对象规定每个位置需要选多少人scoring 对象则描述计分方式。这些看似琐碎的字段恰恰决定了选秀策略的差异。如果脱离这样的数据AI 只能使用平台默认规则可能跑卫权重较大、外接手只选两个。但在上述联盟设置里外接手有 3 个首发位加上 FLEX 可以灵活调配意味着外接手的整体需求变高前几轮出现外接手扎堆抢选也是合理的。没有结构化的规则AI 就不可能理解这种差异。再看球员池文件。推荐使用 CSV 格式因为便于人工查看也便于 Python 的 csv 模块读取。为了让技能能判断“这人还能不能选”球员池的每条记录最好包含唯一的 player_id、状态字段和预估值player_id,name,team,position,projection,status p01,Patrick Mahomes,KC,QB,312.5,active p02,Christian McCaffrey,SF,RB,248.3,active p03,Jalen Hurts,PHI,QB,301.2,active p04,Justin Jefferson,MIN,WR,235.8,active p05,Bijan Robinson,ATL,RB,212.4,active p06,Amon-Ra St. Brown,DET,WR,220.1,active这份文件只需要六行数据就能跑通最小流程。核心是让技能理解球员池不是无限大的每个球员有位置已经被选走的球员不应当出现在下一轮推荐里。因此数据文件天然就是技能决策的基础约束。位置需求、计分规则、已被选球员共同构成了一个可以计算的决策空间。在设计这些资产文件时建议把示例文件和真实数据分开存放。SKILL.md 里只引用 assets 目录下的样例文件用户真实数据则放在另一个独立目录比如个人配置或临时输入。这样可以避免不小心把真实联盟数据提交到公共仓库。真实数据可能包含联盟成员信息即使只是名称也会带来不必要的隐私风险。应当通过规范来隔离样例与真实数据。7. 规则串接写一个可独立运行的推荐脚本有了结构化的联盟设置和球员池下一步是把这些数据和规则串起来。对于多数支持 skill file 的 Agent它可以直接按照 SKILL.md 里的指令做推理。但从工程角度更建议再准备一个可独立运行的脚本用来验证数据正确性和模拟决策结果。下面这个 Python 脚本是一个最小示例它会读取 JSON 和 CSV通过计算“位置需求缺口”和“最高预期分”从当前可用球员里找出一名推荐球员。这个脚本不依赖任何第三方库运行 Python 3 即可。# 文件路径my-mock-draft-skill/scripts/recommend_pick.py import csv import json import sys from collections import defaultdict def load_settings(path): with open(path, r, encodingutf-8) as f: return json.load(f) def load_players(path): players [] with open(path, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: row[projection] float(row[projection]) players.append(row) return players def compute_position_deficit(settings, selected_ids): needed dict(settings[roster]) filled defaultdict(int) for player_id in selected_ids: position selected_ids[player_id] if position in needed: filled[position] 1 deficit {} for position, limit in needed.items(): if position BENCH: continue deficit[position] max(0, limit - filled.get(position, 0)) return deficit def recommend(settings, players, selected_players): selected_ids {p[player_id]: p[position] for p in selected_players} selected_set set(selected_ids.keys()) deficit compute_position_deficit(settings, selected_ids) available [p for p in players if p[player_id] not in selected_set] available [p for p in available if p.get(status, active) active] # 过滤掉已经没有空位的非 BENCH 位置 eligible [] for p in available: pos p[position] if deficit.get(pos, 0) 0: eligible.append(p) elif pos FLEX: eligible.append(p) if not eligible: return None # 简单策略选同期预期分最高的可用球员同分时优先补最缺的位置 eligible.sort(keylambda x: (-x[projection], -deficit.get(x[position], 0))) return eligible[0] if __name__ __main__: if len(sys.argv) 3: print(用法: python recommend_pick.py league_settings.json player_pool.csv) sys.exit(1) settings load_settings(sys.argv[1]) players load_players(sys.argv[2]) selected [] pick recommend(settings, players, selected) if pick: print(推荐选择:, pick[name], 位置:, pick[position], 预期分:, pick[projection]) else: print(没有找到可推荐的球员请检查阵容设置或球员池状态)这个脚本只做了一个非常粗略的策略判断按照 roster.json 里每个位置的需求数过滤早已填满的位置再从剩余可用球员中选择最高预期分者。实际选秀当然更复杂包括蛇形顺位、轮次策略、同联盟对手的位置需求等但这个脚本的价值在于把数据约束变成了一段可测试、可运行的逻辑。在与 Agent 配合时脚本的运行结果可以作为“规则参考”之一。Agent 能够在这个结果上进一步解释可能的备选方案。如果设置文件和球员池数据质量不高脚本输出的逻辑错误也会更快暴露出来。推荐脚本使用命令行参数而不是硬编码路径。这样技能在调用脚本时可以动态传入用户当前导入的数据文件。脚本本身不存储用户数据也不会在运行后留下敏感信息。这种设计很容易被集成进各类技能框架。运行如下命令即可验证python scripts/recommend_pick.py assets/league_settings.example.json assets/player_pool.example.csv预期输出内容大致如下推荐选择: Christian McCaffrey 位置: RB 预期分: 248.3注意输出会根据球员池中可用数据不同而变化。这里不是为了告诉你谁是最佳球员而是确认脚本已经正确读取了 JSON 和 CSV并且在“未选择任何球员时”给出了最合理的初始推荐。8. 运行验证与效果评估编写好 SKILL.md、数据结构文件和推荐脚本后不能只看脚本能跑还需要验证这个技能在真实 Agent 环境里是否可用。一个简单的运行方式是直接在支持技能的 AI 客户端里新建对话然后发送类似下面的指令:请使用 realer-mock-draft 技能。这是我的联盟设置文件和球员池文件我已经选过第 1 轮第 4 顺位的一个球员。请你基于我的联盟规则模拟第 2 轮我的选择。这里需要观察几个关键点。第一Agent 是否真的触发了技能。如果它没有按 SKILL.md 的流程执行而是直接凭常识回答说明 description 里的触发词设置不够准确或者当前平台还需要通过特定方式主动调用技能目录。这时应先检查技能文件是否被正确放置、元信息格式是否符合平台规范。第二Agent 是否先校验了数据。好的流程应要求用户补充缺失字段而不是假设该位置有两个外接手或默认计分为 PPR。如果生成结果前没有确认联盟中“外接手 3 人、0.5 PPR”等规则输出很可能偏回通用方案。第三结果是否有可解释性。推荐某位球员时应当能给出“为什么是这个人”的简短解释是位置缺口更大还是预期分最高又或是你联盟里某个位置已经非常缺人。没有理由的选秀推荐价值会大打折扣。验证失败时的排查顺序也很重要。首先检查数据文件本身是否完整也就是跑一遍上面的 Python 脚本确认 CSV 和 JSON 能被正确解析。若脚本成功而 Agent 回答仍偏离规则大概率是 SKILL.md 里的执行步骤描述不够清晰需要拆成更细的命令步骤。若脚本本身就报错则优先检查 CSV 字段名是否与代码读取的字段名一致比如是 projection 还是 projected_points。输出结果的评估也应当引入“回归用例”。比如准备一个固定联盟设置、固定球员池和固定已选名单的最小测试样例记录技能输出的推荐结果。以后每当你修改 SKILL.md 或调整脚本时都跑一遍这个回归测试观察输出是否仍然符合预期。这样做能有效避免“改了规则描述结果 AI 又偷偷变回默认思路”的问题。9. 常见问题与排查思路实际使用这类技能文件时问题往往不是出在选秀策略上而是出在文件、规则和触发机制上。下面按问题现象整理了一份排查表可以直接对照处理。问题现象可能原因排查方式解决方案用户提到模拟选秀技能没有被触发SKILL.md 的 description 中没有覆盖用户说法查看技能说明中的触发关键词补充“mock draft、模拟选秀、选秀练习、按联盟规则选人”等表达AI 不读取我上传的 JSON 或 CSV 文件文件路径或字段名与代码不一致优先运行推荐脚本观察是否能解析校验 CSV 表头和 JSON 字段名统一 league_settings 与 player_pool 的命名推荐结果总是违背联盟位置限制roster 字段或预算结构写错手动查看 roster 配置检查阵容各位置人数确保位置缩写与球员池数据一致例如 RB/WR/TEAgent 开始自行编造球员数据SKILL.md 没有强调禁止编造检查输出是否包含未出现在球员池中的球员在技能说明中增加“只基于 player_pool.csv 中的球员做推荐”后续轮次的已选状态丢失推荐重复Agent 没有保留选秀状态记录在一次会话中要求它先导出已选清单再进行下一轮用结构化字段保存已选 player_id在 SKILL.md 流程中明确第 3 步读取状态数据更新后结果没有变化示例文件被固化在缓存或上下文里检查 Agent 是否仍引用旧的 assets 数据每次运行前重新读取最新文件必要时使用独立脚本校验文件更新时间技能文件加了太多策略知识输出反而不稳定SKILL.md 过载干扰核心流程回顾技能文件内容是否聚焦操作步骤把策略资料移到独立资源文件主文件中只保留流程、边界和输出格式这里想特别强调两个最容易踩的坑。第一个坑是“球员池过滤逻辑不严谨”。如果只推荐前锋位置球员而没有过滤已经被选走的人Agent 就会一本正经地推荐一个“刚刚才被别人选走”的球员。必须在技能流程中明确要求在推荐前先列出已选球员编号并排除。第二个坑是“把示例数据当真实数据”。assets 目录里的示例文件只用来演示格式。如果你真实联盟更新了球员名单但技能仍读取 assets 下的样例 CSV那结果就会严重失真。因此需要在 SKILL.md 中设计清晰的输入约定示例数据仅用于演示格式用户在对话中提交的联盟数据才是本次模拟依据。10. 最佳实践与工程建议当你已经能跑通一个最小 mock draft 技能下一步是用工程化思维把它变成可以长期维护的小系统。这里分享几条实践建议。第一条将“规则声明”与“策略推理”分开。SKILL.md 的工作是检查规则、确认输入、按步骤推进球员价值排名、选秀策略分析这类参数化知识可以放在独立资源文件里。你可以在资源文件里写清楚联盟的计分特点、哪个位置不易补强但不要让主流程文件变得臃肿。第二条为每一次模拟建立一个“会话快照”。真实比赛中的选秀是逐轮进行的你可能今天选了前 3 轮明天再继续。技能应该支持记录当前轮次、剩余签位、你已经拥有的球员清单。不要依赖聊天记录来恢复状态更稳妥的做法是让技能读入一个 state 文件每次选秀结束时更新该文件。例如state 文件可以这样记录{ current_round: 3, current_pick: 32, my_team: [ {round: 1, player_id: p02}, {round: 2, player_id: p04} ] }这样的状态文件结构清晰也方便脚本读取。第三条最小权限隐私原则。Skill 能访问的数据范围应当被严格控制。只需要球员的 ID、姓名、位置、预期分和状态就不要让技能读取联盟成员手机号、邮箱等不相关信息。默认情况下不要把含有个人数据的真实联盟文件提交到公开仓库。第四条建立最小数据集回归测试。无论你怎么调整技能说明都要保持一份可以公开的联盟设置样例和球员池样例。每次修改后跑一次推荐脚本对照输出是否符合预期。这套回归机制能让后续改动风险显著下降。第五条如实标注数据来源和更新时间。球员预期分来源于哪份公开榜单联盟设置文件是哪一天导出的这类信息可以写在 README 里而不是依赖使用者记忆。特别是赛季中球员伤病不断过期的球员状态会让模拟结论完全不可用。第六条平台或技能格式升级时先确定兼容方式。技能文件并不是纯粹的自然语言文件它依赖所在平台的 schema。如果平台结构升级例如要求在 frontmatter 中增加新的字段可以先在一个临时目录里迁移测试确认无误后再替换正式版本。11. 写在最后Realer Mock Draft 这个项目给我们展示了一个很有代表性的方向AI 工具要真正进入决策场景不能只提供通用能力还要能消费用户自己的上下文。技能文件的价值正在于它给了开发者一种低成本的私有化能力扩展方式——你不用造一个完整平台只需要写清楚流程、设计好数据接口再让 AI 按规则执行就能得到一个相当贴近个人场景的助手。如果你自己就有一个 fantasy 联盟并且想试试这类方案第一步并不需要先写代码而是先把你联盟的规则整理成一份 JSON。球队数量、位置结构、计分方式、你的签位这些信息你都很熟悉把它们从记忆中搬到文件里只是很小的成本。一旦有了这份文件后面的事情就是把 SKILL.md 写好、让 AI 认认真真执行。任何模拟都不能百分百还原实战但至少下一次真正选秀时面对第 4 顺位你不会再拿一套“默认联盟参数”练出来的手感去应对自己那个处处是特例的联盟了。