从去年开始我花了大量时间在各类AI编码客户端上折腾提示词和规则配置。Cursor、GitHub Copilot、Claude Code、Continue都用过一圈最后我发现一个尴尬的事实写提示词的时间比写代码还多而且换个项目、换个客户端之前积累的规则基本要重写。这就是我做reverse-skill这个项目的初衷——一个面向AI编码客户端的逆向工程技能路由包。先说清楚它是什么。reverse-skill 不是某个客户端的插件也不是某个模型而是一套结构化的技能管理方案通过逆向分析AI编码客户端的规则加载机制、上下文组织方式和技能触发规律把可复用的技能封装成标准的目录与文件再用路由规则把正确的技能在正确的场景下自动分发到模型面前。简单说就是对“提示词”做一次工程化整理。它能解决三个非常实际的问题第一让规则和技能可以在不同项目、不同客户端之间复用不再每次从零开始第二通过路由机制按需加载技能减少无效 tokens 消耗第三把团队的编码规范和工程经验沉淀成标准化的技能包新成员直接继承不需要口口相传。适合对AI编码效率有追求的个人开发者、团队技术负责人以及想在AI工程化方向上探索的同行。1. 先搞清楚AI编码客户端怎么组织上下文再谈技能路由1.1 我为什么会对提示词产生“管理焦虑”很多人对提示词的理解还停留在“写一段话扔给AI”的阶段。但当你真的把AI编码客户端当成日常生产力工具每天要处理十几个任务要让它在代码审查、测试生成、接口设计、重构建议等不同角色之间切换时零散的提示词很快就会失控。我遇到过几个非常典型的场景。第一个场景是规则互相打架我在项目配置里写了“所有回复用中文”但某个技能文件又写了“保持英文变量命名和英文注释”模型在两套指令之间摇摆输出风格一天一个样。第二个场景是规则失效但不知道原因明明在C端配置了规则换到D端就完全不生效排查了半天才发现是目录命名不对。第三个场景是上下文被稀释为了让模型记住各种规范我把几十条规则全部常驻附加结果每次对话都要消耗大量 tokens而且真正关键的规则反而被淹没在长文本里。这些问题本质上不是模型能力不够而是我自己的规则管理方式太原始。我开始意识到AI编码客户端的技能调用机制是有一套规律的如果能先“逆向”摸清楚这套规律再用工程化的方式组织技能很多问题其实可以提前规避。reverse-skill 就是在这样的背景下开始做的。1.2 AI编码客户端的技能加载机制拆开看其实很朴素我把主流的AI编码客户端过了一遍之后发现它们的技能加载机制大同小异本质上就是一个“上下文组装器 模型调用器”。客户端接收用户输入后会把项目信息、目录结构、文件内容、用户配置的规则文件拼装到一起再发给底层模型。规则文件的作用就是在模型接到任务之前预先告诉它“你该怎么处理这些任务”。但不同客户端在这个“拼装”过程中有几个关键差异附加时机不同。有些客户端的规则是常驻的不分场景全量附加有些是条件触发当用户输入里出现某些关键词时才加载对应规则还有些支持斜杠命令手动唤起。附加时机决定了技能路由包的设计思路不能假设规则永远在场必须允许“按需加载”。文件格式不同。有的客户端要求规则文件必须放在特定目录、使用特定扩展名比如.mdc、SKILL.md有的则支持任意 Markdown 文件扫描。格式不匹配规则就直接被忽略不会报错只会让你困惑。优先级策略不同。当多个规则同时命中一个任务时客户端怎么决定谁优先有些是后定义的覆盖先定义的有些是特定目录的权重更高有些则完全交给模型自己“理解”。优先级机制决定了路由包的合并规则必须显式设计不能依赖运气。理解这些差异之后我就把“逆向工程”的重点放在了一个朴素的方向上不猜、不看内部实现而是通过可观察的行为反推规则。做法也很简单给客户端配置一个“回声规则”让模型每次回答前先复述自己收到的规则文件清单和优先级顺序就能直观看到各个客户端在具体任务中到底加载了什么内容。这个技巧在排查问题时尤其管用后面会详细讲。1.3 主流客户端规则加载方式对照我自己常用的几款客户端的规则加载方式整理成一张表方便大家对比客户端规则文件位置常见格式主要附加方式我的使用结论Cursor.cursor/rules.mdc全局/文件夹级常驻支持手动指定适合放项目级公共规范但要注意目录层级限制GitHub Copilot仓库.github/copilot-instructions.md或用户级配置.md始终附加到请求上下文适合放团队统一约定不适合放大量技能细节Claude Code.claude/skillsSKILL.md条件触发关键词匹配后加载和路由包思路最接近适合做技能单元Continueconfig.json规则块结构化配置手动指定或按规则块触发灵活性最高适合进阶折腾这张表不是官方文档的复述是我实际使用中通过回声验证得出的观察结果。不同版本、不同配置方式可能会变化所以我的建议是接手一个新客户端别急着写几十条规则先花一上午做一轮“回声测试”搞懂它的加载机制再决定技能包怎么放。这一步省下的时间远大于前期投入。2. 路由包的整体设计与核心逻辑2.1 路由包的三大组成技能库、路由规则、公共上下文reverse-skill 在结构上把提示词拆成三层技能库负责具体执行路由规则负责分发决策公共上下文负责提供底层的项目信息。这有点像后端开发中的三层架构控制器接收请求服务层处理业务逻辑数据层提供数据。把这种分层思路用在提示词管理上规则之间的耦合会大幅降低。技能库是最底层里面每一个技能都是一个独立目录包含描述文件、示例、模板。路由规则是中间层它的职责是判断“当前用户输入应该触发哪个技能”。公共上下文是最底层存放项目技术栈、代码规范、架构约束等所有技能都需要的基础信息。这三层各司其职互不干扰后续维护时改一个技能的细节不需要动路由规则换一个项目只需要替换公共上下文。2.2 触发词设计的核心从“关键词匹配”升级为“意图匹配”技能路由包最容易做错的地方就是把路由规则写成机械的关键词匹配表。比如“用户提到‘测试’就加载测试技能”“提到‘重构’就加载重构技能”。这种写法在小规模场景下能用但一旦技能数量变多就会频繁踩到两个坑一是同义词覆盖不全用户说“帮我把这函数拆小一点”规则里没有“拆分”这个关键词路由就漏判了二是关键词误伤用户说“这个测试写得不好”结果因为包含“测试”两个字模型误触发了测试生成技能实际上用户想表达的是代码审查需求。我后来把触发条件统一改成“意图描述 参考关键词”的组合写法。规则的含义从“出现某个词就执行”变成“如果用户意图属于这类任务就加载对应技能以下关键词可作为参考信号”。意图描述交给模型去理解关键词只是辅助信号不直接作为硬性条件。这种方式实测下来路由命中率比纯关键词匹配高很多。2.3 优先级与冲突合并多技能同时命中时怎么办一个真实的任务描述经常会同时命中多个技能。比如“新写的这个接口有问题帮我先审查再补个测试”这里既有 api-design 的需求又有 code-review 的需求还有 test-generation 的需求。如果路由规则不做优先级设计模型就会随机选一个或者全部混着执行输出质量很难保证。我的处理方式是给每个技能声明一个“执行阶段”。code-review 和 refactor 属于分析类适合先执行test-generation 和 api-design 属于产出类适合后执行。在路由规则里我会明确写出合并策略当多个技能同时命中时先做高优先级技能的分析再做低优先级技能的产出如果两个技能都是产出类就按用户请求的动词顺序执行。这个策略比单纯列一堆“哪个优先”清晰得多模型的响应也更稳定。3. 核心实操技能路由包的目录结构与文件写法3.1 目录结构怎么设计才不会乱一个合理的目录结构是技能路由包可持续维护的基础。我目前的reverse-skill项目目录长这样reverse-skill/ ├── skills/ │ ├── code-review/ │ │ ├── skill.md │ │ └── examples/review-good.md │ ├── test-generation/ │ │ ├── skill.md │ │ └── templates/unittest.tpl │ ├── api-design/ │ │ ├── skill.md │ │ └── checks/openapi-cases.md │ └── refactor/ │ ├── skill.md │ └── rules/safe-rename.md ├── routers/ │ ├── default.md │ ├── python-project.md │ └── frontend-project.md ├── context/ │ ├── stack.md │ ├── conventions.md │ └── architecture.md └── README.md这个结构遵循几个原则。技能目录只保留和该技能强相关的内容示例和模板都收在技能目录内部不污染其他目录。路由文件按项目类型或场景划分default.md 作为兜底只在没有更具体匹配时使用。公共上下文全部集中在 context 目录由路由规则统一决定是否附加。这样分完之后新技能加入时只需要新增一个目录路由文件做一次登记不需要改动其他任何东西。3.2 路由规则文件具体怎么写以default.md为例它解决的是“没有识别到具体项目类型时如何提供最稳妥的默认行为”。我通常这样写# 默认路由规则 当用户输入未匹配到更具体的项目类型时按以下顺序加载技能 1. 若任务涉及查看或修改代码加载 code-review 2. 若任务涉及新功能开发、接口设计加载 api-design 3. 若用户明确要求写测试加载 test-generation 4. 若用户提到重构、优化、清理加载 refactor 合并策略分析类技能code-review、refactor优先执行产出类技能api-design、test-generation后执行。若同为产出类按用户请求顺序执行。路由文件不长但有几处细节需要注意。每条路由的描述要覆盖“意图 常见场景 参考信号词”但信号词只是辅助核心还是让模型判断意图。“合并策略”部分必须写明确否则模型遇到多技能命中时容易自由发挥。最后每个技能后面可以追加“特殊要求”字段比如 code-review 必须输出风险等级这类细节可以放在路由里等于是给技能调用做一次参数化。3.3 技能文件的编写重点把“身份”换成“行为”技能文件是整套路由包里价值密度最高的部分也是最容易写废的地方。我早期写技能文件喜欢用“你是一个资深Python工程师”这种身份描述后来发现效果并不理想。模型收到这种身份描述后只会给你一种“他懂很多”的态度但无法转化为具体的行动。真正的技能文件应该聚焦在行为约束上。举个例子同样是代码审查技能我早期写的是“请仔细审查代码注意代码质量、性能、安全问题”。这种写法几乎等于没写。现在我会写成“先定位本次改动范围标注新增函数和修改函数检查类型注解是否完整禁止使用 Any 作为函数参数每个问题必须给出风险等级和修改示例输出格式固定为问题描述、风险等级、修改建议、示例代码”。把身份换成行为模型输出的质量立刻不一样。写技能文件时我还会带上一个真实示例。示例文件的价值不只是给模型参考格式更重要的是标记“输出风格的期望值”。模型是少样本学习者给一个高质量的正例比在描述里反复强调“必须专业”有效得多。4. 从零搭建一个Python项目的完整实操记录4.1 第一步给项目做画像动手写路由包之前我会花10分钟梳理项目画像。画像就是给项目贴标签技术栈、团队习惯、当前阶段、高风险模块。没有画像路由规则就无从谈起。举个例子我最近在搭的一个内部工具项目画像是这样的技术栈是 Python FastAPI走异步路线团队强制类型注解测试覆盖率底线是 80%当前处于新功能开发期接口变动频繁高风险模块集中在支付回调、任务队列和第三方API对接。这个画像决定了路由规则的优先级开发期的核心痛点是接口稳定性和单测覆盖所以路由里 api-design 和 test-generation 的优先级要高于 code-review。画像信息不全也没关系先给个初版后续通过技能输出反馈不断修正。关键是这个动作要做因为它是所有路由决策依据的锚点。4.2 第二步编写项目级路由规则有了画像项目级路由规则就能写得更具体。python-project.md我通常会写成下面这样# Python项目路由 适用条件检测到 pyproject.toml 或 setup.py或用户输入与 Python 强相关。 加载顺序 1. 始终加载 context/stack.md、context/conventions.md 2. 用户输入涉及“写接口”“加个接口”“路由”“新增接口文档”优先加载 api-design 3. 用户输入涉及“测一下”“写测试”“补单测”“加个用例”优先加载 test-generation 4. 用户输入涉及“帮我看看这段代码”“这里有问题”加载 code-review 5. 用户输入涉及“怎么改”“拆一下”“重构”“优化”加载 refactor 6. 高风险模块支付、队列、第三方对接出现时必须叠加 code-review 合并策略优先级1 2 3介于中间的任务以用户请求的动词最靠前的那个为准。这个规则文件里我特意加了一条“高风险模块叠加”。为什么因为项目的支付回调曾经出过线上事故我希望 AI 每次只要碰到相关文件就直接审查不管用户有没有明确要求。这就是画像如何反馈到路由规则的典型案例。4.3 第三步对接AI编码客户端的三种方式路由包文件准备好之后怎么和具体客户端对接我一般有三种方式方式A把整个目录放进项目根目录利用客户端自带的目录扫描能力自动加载。适合团队协作规则随仓库走所有成员拿到同一套配置。方式B把公共上下文和路由规则放在客户端全局配置里技能文件仍然留在项目仓库。适合个人日常使用项目里不引入杂七杂八的配置文件。方式C用斜杠命令或快捷键手动触发技能文件。适合低频但高要求的场景比如重要代码审查、接口方案评审之前主动唤起特定技能。这三种方式可以混搭。我的习惯是公共上下文放全局路由规则随仓库走高风险场景手动唤起专项技能。这样的组合既保证了日常的自动化又给重要节点留了手动干预的口子。4.4 第四步三轮验证法确认路由生效路由包配置完成之后我从来不会直接开始写业务代码而是先做三轮验证。第一轮是回声验证让模型复述当前加载的规则文件有哪些、优先级如何确认路由文件真的被读取了。第二步是场景验证输入三个典型的任务描述比如“帮我把这个函数拆小一点”“新加一个订单查询接口”“给这个模块补测试”看输出是否命中了预期的技能。第三轮是边界验证故意输入一个模糊请求比如“你看着办”看模型在没有明确路由的情况下默认行为是否合理。这三轮验证看起来很笨但效果极好。它能提前发现八成以上的路由不生效问题而且整个过程只需要十几分钟。很多抱怨“规则没用”的人其实缺的就是这个验证环节。5. 可直接抄作业的技能模板5.1 code-review代码审查技能模板技能文件的核心是行为约束加输出格式。下面是我在 reverse-skill 里长期使用的模板骨架# 技能代码审查 ## 执行步骤 1. 定位本次改动范围列出新增文件和修改文件 2. 新增函数优先检查边界条件、输入校验、异常处理 3. 修改函数优先检查调用方是否兼容、返回值是否变化 4. 全局扫描类型注解是否完整、是否存在硬编码、是否有明显的并发隐患 ## 输出格式 每个问题用四段式输出 - 问题描述说明具体问题和触发场景 - 风险等级高/中/低 - 修改建议给出可落地的改法 - 示例代码贴出推荐写法 ## 兜底规则 如果本次检查的代码非常简短且无明显问题也要输出一句“未发现高等级风险”不要只给一个“没问题”的结论。这里的兜底规则也值得提一下。模型在找不到问题时经常用“没问题”三个字敷衍。我用这个规则强制它至少给出一个结论性的陈述避免不可验证的空白输出。5.2 test-generation测试生成技能模板测试生成技能容易走两个极端一是生成的测试用例只有 happy path不覆盖边界二是乱写 mock把真实行为都屏蔽了测试形同虚设。我的模板里对这两点做了明确约束# 技能测试生成 ## 输入要求 - 需要测试的函数或模块路径 - 该模块涉及的外部依赖数据库、缓存、第三方API ## 执行步骤 1. 分析函数的分支结构列出正常输入、边界输入、非法输入三类场景 2. 优先使用真实依赖只在真实依赖不可用时才使用 mock 3. 测试方法命名采用 test_函数名_场景 的格式让每个用例的意图清晰可读 4. 断言必须包含期望值和期望行为禁止只断言不报错 ## 输出要求 - 给出完整的测试代码可直接放到测试目录运行 - 如有需要 mock 的地方在代码注释里写明原因 - 总用例数不少于 5 个且必须包含至少一个边界用例我后来发现把“mock 必须写明原因”写进模板能显著减少无脑 mock。模型在解释动机的过程中往往会重新思考 mock 是否真的必要效果意外地好。5.3 api-design接口设计技能模板接口设计技能是我在快速迭代项目里用得最多的技能之一。它要解决的核心问题是接口方案不仅要有路径和参数还要考虑错误码、兼容性、幂等性和文档。# 技能接口设计 ## 设计前必读 - 从 context/stack.md 获取当前后端框架约束 - 从 context/architecture.md 获取现有接口风格约定 ## 执行步骤 1. 明确接口的调用方和核心使用场景 2. 设计 RESTful 路径和 HTTP 方法路径尽量名词复数不使用动词 3. 定义请求参数类型、是否必填、默认值、校验规则 4. 定义响应结构成功响应和错误响应分开设计 5. 检查幂等性对于创建、支付类接口必须给出幂等键方案 6. 输出 OpenAPI 风格的简版接口文档 ## 输出格式 接口路径、方法、请求参数表、响应结构、错误码表、调用示例六项缺一不可。模板里的“幂等性检查”是从支付回调事故中沉淀下来的硬性要求。这种教训型规则比任何通用性的“注意安全”表述都更管用。6. 踩坑实录技能路由包常见问题排查速查6.1 规则文件被直接忽略的典型原因规则不生效多数时候不是模型的问题而是配置文件根本没被加载。我遇到过的原因大致有这几种目录名或扩展名不符合客户端要求比如 Cursor 要求.mdc文件塞一个.md进去就直接忽略技能目录里带了空格或特殊字符客户端的路径解析出问题文件体积过大超过客户端的单文件扫描上限。排查这类问题最快的办法就是“回声验证”。让模型先复述加载到的规则文件清单一眼就能看出哪些文件没被读进去。如果模型复述的清单里没有你的规则文件问题基本就锁定在加载环节往下核对目录、扩展名、文件大小就够了。6.2 路由规则冲突导致行为飘忽路由规则冲突的典型表现是同一个任务多问几次模型的行为每次都不一样。一会执行代码审查一会又去改代码输出风格也来回跳。原因是多个技能文件里存在互相矛盾的要求模型在冲突指令之间摇摆。解决办法有两个层次。第一是在路由层明确优先级写清楚“多技能同时命中时以谁为主”第二是在技能文件内部避免互相矛盾比如不要在 code-review 里写“所有输出用中文”又在 test-generation 里写“测试注释用英文”这种冲突要提前在技能模板里消除。我的经验是矛盾类问题在规则设计阶段发现和修复的成本最低越到后面越难改。6.3 技能输出和没配置前没区别配置技能包之后如果发现模型输出和以前没有本质区别问题通常出在技能文件描述太抽象。这是最普遍的问题也最难自己察觉。解决方法是把技能描述从“身份型”改成“行为型”。不要写“你是资深Python专家”要写“检查类型注解是否完整禁用 Any 作为函数参数”。不要写“注意代码质量”要写“对每个问题给出风险等级和修改示例”。行为型描述会给模型明确的执行路径输出质量立刻会有改观。6.4 跨客户端效果不一致怎么办同一套技能包在客户端A表现良好换到客户端B就失效这是我复现率最高的场景之一。根源在于各客户端的加载机制和上下文组织方式不同。有的客户端会把目录全部塞进上下文有的只加载根目录下特定文件。跨客户端使用前一定要重新走一遍回声验证确认哪些文件实际被加载。如果发现目标客户端不支持目录递归加载就把关键规则合并到一个顶层文件里。不要指望一套物理文件结构适配所有客户端合理的做法是准备一份底层模板再按客户端特性做适配。6.5 排查项汇总表现象优先检查项再检查项兜底做法规则完全不生效目录名/扩展名是否符合客户端要求文件是否在扫描路径内回声验证确认加载清单输出风格漂移技能文件是否存在矛盾指令路由优先级是否明确统一合并策略技能输出泛泛是否用了抽象身份描述是否有明确的输出格式约束全部改成行为描述跨客户端失效客户端是否支持目录递归规则文件格式是否兼容关键规则合并到单文件7. 安全与合规边界做逆向要守住哪条线技能路由包的构建过程中我们确实会对AI编码客户端做“逆向分析”但这个逆向和破解、攻击完全是两回事。我给自己划的边界非常清楚可以观察客户端如何组织上下文、分析官方文档和配置文件、通过自身输入输出实验反推触发规律、参考开源社区的插件和规则实现但不可以破解或绕过客户端的付费限制、逆向专有API做未授权调用、获取非公开的内部协议或模型配置。这个边界不是空话。一个效率工具项目能不能持续维护很大程度上取决于它的安全性。如果代码走的是灰色路径一旦被人盯上项目随时可能下架之前的积累全部白费。反过来如果一开始就抱着合法合规的思路做虽然慢一点但每一步都是可积累的。从长期价值来看合规路线才是效率工具的最优解。在项目实践上我也定了几条红线只在公开文档描述的范围内操作客户端配置只用自己本身有权访问的数据和项目做分析技能包中不包含任何绕过鉴权、篡改请求、抓取私有接口的内容。只要守住这几点这个方向的技术探索完全可以放心推进。8. 技能路由包还能怎么扩展这一节算是我的个人建议给想深入这个方向的同行一些参考。第一个扩展方向是跨团队共享。我一开始做 reverse-skill 是为了自己用后来整理成内部仓库同事克隆到各自项目里只需要改一下 context/stack.md就能适配各自的技术栈。这比每个人各自维护一套提示词要高效得多团队层面的提示词资产也能沉淀下来。第二个方向是在CI流程里加一道轻量校验。我在公司内部搭过一个小脚本推送代码时自动提取路由包里的 code-review 技能描述作为提示词输入给独立的模型API对 PR 做前置审查。效果当然比不了正式评审但能把低级问题拦在提交之前算是投资产出比很高的自动化防线。第三个方向是建立反馈回路的持续迭代。我每个月会收集一次路由包误判案例比如模型明明加载了 refactor 技能却给出了不合适的建议分析原因后调整技能文件里的约束条件。坚持两个月之后技能的命中率提升非常明显。这套方法论本质上就是把“和AI打交道”从凭感觉变成按套路观察、假设、配置、验证、迭代和写代码的工程流程没什么两样。对于想把AI编码能力真正沉淀到团队资产里的开发者这个方向值得试一试。 AI编码客户端提示词管理：技能路由包的逆向工程与实践
从去年开始我花了大量时间在各类AI编码客户端上折腾提示词和规则配置。Cursor、GitHub Copilot、Claude Code、Continue都用过一圈最后我发现一个尴尬的事实写提示词的时间比写代码还多而且换个项目、换个客户端之前积累的规则基本要重写。这就是我做reverse-skill这个项目的初衷——一个面向AI编码客户端的逆向工程技能路由包。先说清楚它是什么。reverse-skill 不是某个客户端的插件也不是某个模型而是一套结构化的技能管理方案通过逆向分析AI编码客户端的规则加载机制、上下文组织方式和技能触发规律把可复用的技能封装成标准的目录与文件再用路由规则把正确的技能在正确的场景下自动分发到模型面前。简单说就是对“提示词”做一次工程化整理。它能解决三个非常实际的问题第一让规则和技能可以在不同项目、不同客户端之间复用不再每次从零开始第二通过路由机制按需加载技能减少无效 tokens 消耗第三把团队的编码规范和工程经验沉淀成标准化的技能包新成员直接继承不需要口口相传。适合对AI编码效率有追求的个人开发者、团队技术负责人以及想在AI工程化方向上探索的同行。1. 先搞清楚AI编码客户端怎么组织上下文再谈技能路由1.1 我为什么会对提示词产生“管理焦虑”很多人对提示词的理解还停留在“写一段话扔给AI”的阶段。但当你真的把AI编码客户端当成日常生产力工具每天要处理十几个任务要让它在代码审查、测试生成、接口设计、重构建议等不同角色之间切换时零散的提示词很快就会失控。我遇到过几个非常典型的场景。第一个场景是规则互相打架我在项目配置里写了“所有回复用中文”但某个技能文件又写了“保持英文变量命名和英文注释”模型在两套指令之间摇摆输出风格一天一个样。第二个场景是规则失效但不知道原因明明在C端配置了规则换到D端就完全不生效排查了半天才发现是目录命名不对。第三个场景是上下文被稀释为了让模型记住各种规范我把几十条规则全部常驻附加结果每次对话都要消耗大量 tokens而且真正关键的规则反而被淹没在长文本里。这些问题本质上不是模型能力不够而是我自己的规则管理方式太原始。我开始意识到AI编码客户端的技能调用机制是有一套规律的如果能先“逆向”摸清楚这套规律再用工程化的方式组织技能很多问题其实可以提前规避。reverse-skill 就是在这样的背景下开始做的。1.2 AI编码客户端的技能加载机制拆开看其实很朴素我把主流的AI编码客户端过了一遍之后发现它们的技能加载机制大同小异本质上就是一个“上下文组装器 模型调用器”。客户端接收用户输入后会把项目信息、目录结构、文件内容、用户配置的规则文件拼装到一起再发给底层模型。规则文件的作用就是在模型接到任务之前预先告诉它“你该怎么处理这些任务”。但不同客户端在这个“拼装”过程中有几个关键差异附加时机不同。有些客户端的规则是常驻的不分场景全量附加有些是条件触发当用户输入里出现某些关键词时才加载对应规则还有些支持斜杠命令手动唤起。附加时机决定了技能路由包的设计思路不能假设规则永远在场必须允许“按需加载”。文件格式不同。有的客户端要求规则文件必须放在特定目录、使用特定扩展名比如.mdc、SKILL.md有的则支持任意 Markdown 文件扫描。格式不匹配规则就直接被忽略不会报错只会让你困惑。优先级策略不同。当多个规则同时命中一个任务时客户端怎么决定谁优先有些是后定义的覆盖先定义的有些是特定目录的权重更高有些则完全交给模型自己“理解”。优先级机制决定了路由包的合并规则必须显式设计不能依赖运气。理解这些差异之后我就把“逆向工程”的重点放在了一个朴素的方向上不猜、不看内部实现而是通过可观察的行为反推规则。做法也很简单给客户端配置一个“回声规则”让模型每次回答前先复述自己收到的规则文件清单和优先级顺序就能直观看到各个客户端在具体任务中到底加载了什么内容。这个技巧在排查问题时尤其管用后面会详细讲。1.3 主流客户端规则加载方式对照我自己常用的几款客户端的规则加载方式整理成一张表方便大家对比客户端规则文件位置常见格式主要附加方式我的使用结论Cursor.cursor/rules.mdc全局/文件夹级常驻支持手动指定适合放项目级公共规范但要注意目录层级限制GitHub Copilot仓库.github/copilot-instructions.md或用户级配置.md始终附加到请求上下文适合放团队统一约定不适合放大量技能细节Claude Code.claude/skillsSKILL.md条件触发关键词匹配后加载和路由包思路最接近适合做技能单元Continueconfig.json规则块结构化配置手动指定或按规则块触发灵活性最高适合进阶折腾这张表不是官方文档的复述是我实际使用中通过回声验证得出的观察结果。不同版本、不同配置方式可能会变化所以我的建议是接手一个新客户端别急着写几十条规则先花一上午做一轮“回声测试”搞懂它的加载机制再决定技能包怎么放。这一步省下的时间远大于前期投入。2. 路由包的整体设计与核心逻辑2.1 路由包的三大组成技能库、路由规则、公共上下文reverse-skill 在结构上把提示词拆成三层技能库负责具体执行路由规则负责分发决策公共上下文负责提供底层的项目信息。这有点像后端开发中的三层架构控制器接收请求服务层处理业务逻辑数据层提供数据。把这种分层思路用在提示词管理上规则之间的耦合会大幅降低。技能库是最底层里面每一个技能都是一个独立目录包含描述文件、示例、模板。路由规则是中间层它的职责是判断“当前用户输入应该触发哪个技能”。公共上下文是最底层存放项目技术栈、代码规范、架构约束等所有技能都需要的基础信息。这三层各司其职互不干扰后续维护时改一个技能的细节不需要动路由规则换一个项目只需要替换公共上下文。2.2 触发词设计的核心从“关键词匹配”升级为“意图匹配”技能路由包最容易做错的地方就是把路由规则写成机械的关键词匹配表。比如“用户提到‘测试’就加载测试技能”“提到‘重构’就加载重构技能”。这种写法在小规模场景下能用但一旦技能数量变多就会频繁踩到两个坑一是同义词覆盖不全用户说“帮我把这函数拆小一点”规则里没有“拆分”这个关键词路由就漏判了二是关键词误伤用户说“这个测试写得不好”结果因为包含“测试”两个字模型误触发了测试生成技能实际上用户想表达的是代码审查需求。我后来把触发条件统一改成“意图描述 参考关键词”的组合写法。规则的含义从“出现某个词就执行”变成“如果用户意图属于这类任务就加载对应技能以下关键词可作为参考信号”。意图描述交给模型去理解关键词只是辅助信号不直接作为硬性条件。这种方式实测下来路由命中率比纯关键词匹配高很多。2.3 优先级与冲突合并多技能同时命中时怎么办一个真实的任务描述经常会同时命中多个技能。比如“新写的这个接口有问题帮我先审查再补个测试”这里既有 api-design 的需求又有 code-review 的需求还有 test-generation 的需求。如果路由规则不做优先级设计模型就会随机选一个或者全部混着执行输出质量很难保证。我的处理方式是给每个技能声明一个“执行阶段”。code-review 和 refactor 属于分析类适合先执行test-generation 和 api-design 属于产出类适合后执行。在路由规则里我会明确写出合并策略当多个技能同时命中时先做高优先级技能的分析再做低优先级技能的产出如果两个技能都是产出类就按用户请求的动词顺序执行。这个策略比单纯列一堆“哪个优先”清晰得多模型的响应也更稳定。3. 核心实操技能路由包的目录结构与文件写法3.1 目录结构怎么设计才不会乱一个合理的目录结构是技能路由包可持续维护的基础。我目前的reverse-skill项目目录长这样reverse-skill/ ├── skills/ │ ├── code-review/ │ │ ├── skill.md │ │ └── examples/review-good.md │ ├── test-generation/ │ │ ├── skill.md │ │ └── templates/unittest.tpl │ ├── api-design/ │ │ ├── skill.md │ │ └── checks/openapi-cases.md │ └── refactor/ │ ├── skill.md │ └── rules/safe-rename.md ├── routers/ │ ├── default.md │ ├── python-project.md │ └── frontend-project.md ├── context/ │ ├── stack.md │ ├── conventions.md │ └── architecture.md └── README.md这个结构遵循几个原则。技能目录只保留和该技能强相关的内容示例和模板都收在技能目录内部不污染其他目录。路由文件按项目类型或场景划分default.md 作为兜底只在没有更具体匹配时使用。公共上下文全部集中在 context 目录由路由规则统一决定是否附加。这样分完之后新技能加入时只需要新增一个目录路由文件做一次登记不需要改动其他任何东西。3.2 路由规则文件具体怎么写以default.md为例它解决的是“没有识别到具体项目类型时如何提供最稳妥的默认行为”。我通常这样写# 默认路由规则 当用户输入未匹配到更具体的项目类型时按以下顺序加载技能 1. 若任务涉及查看或修改代码加载 code-review 2. 若任务涉及新功能开发、接口设计加载 api-design 3. 若用户明确要求写测试加载 test-generation 4. 若用户提到重构、优化、清理加载 refactor 合并策略分析类技能code-review、refactor优先执行产出类技能api-design、test-generation后执行。若同为产出类按用户请求顺序执行。路由文件不长但有几处细节需要注意。每条路由的描述要覆盖“意图 常见场景 参考信号词”但信号词只是辅助核心还是让模型判断意图。“合并策略”部分必须写明确否则模型遇到多技能命中时容易自由发挥。最后每个技能后面可以追加“特殊要求”字段比如 code-review 必须输出风险等级这类细节可以放在路由里等于是给技能调用做一次参数化。3.3 技能文件的编写重点把“身份”换成“行为”技能文件是整套路由包里价值密度最高的部分也是最容易写废的地方。我早期写技能文件喜欢用“你是一个资深Python工程师”这种身份描述后来发现效果并不理想。模型收到这种身份描述后只会给你一种“他懂很多”的态度但无法转化为具体的行动。真正的技能文件应该聚焦在行为约束上。举个例子同样是代码审查技能我早期写的是“请仔细审查代码注意代码质量、性能、安全问题”。这种写法几乎等于没写。现在我会写成“先定位本次改动范围标注新增函数和修改函数检查类型注解是否完整禁止使用 Any 作为函数参数每个问题必须给出风险等级和修改示例输出格式固定为问题描述、风险等级、修改建议、示例代码”。把身份换成行为模型输出的质量立刻不一样。写技能文件时我还会带上一个真实示例。示例文件的价值不只是给模型参考格式更重要的是标记“输出风格的期望值”。模型是少样本学习者给一个高质量的正例比在描述里反复强调“必须专业”有效得多。4. 从零搭建一个Python项目的完整实操记录4.1 第一步给项目做画像动手写路由包之前我会花10分钟梳理项目画像。画像就是给项目贴标签技术栈、团队习惯、当前阶段、高风险模块。没有画像路由规则就无从谈起。举个例子我最近在搭的一个内部工具项目画像是这样的技术栈是 Python FastAPI走异步路线团队强制类型注解测试覆盖率底线是 80%当前处于新功能开发期接口变动频繁高风险模块集中在支付回调、任务队列和第三方API对接。这个画像决定了路由规则的优先级开发期的核心痛点是接口稳定性和单测覆盖所以路由里 api-design 和 test-generation 的优先级要高于 code-review。画像信息不全也没关系先给个初版后续通过技能输出反馈不断修正。关键是这个动作要做因为它是所有路由决策依据的锚点。4.2 第二步编写项目级路由规则有了画像项目级路由规则就能写得更具体。python-project.md我通常会写成下面这样# Python项目路由 适用条件检测到 pyproject.toml 或 setup.py或用户输入与 Python 强相关。 加载顺序 1. 始终加载 context/stack.md、context/conventions.md 2. 用户输入涉及“写接口”“加个接口”“路由”“新增接口文档”优先加载 api-design 3. 用户输入涉及“测一下”“写测试”“补单测”“加个用例”优先加载 test-generation 4. 用户输入涉及“帮我看看这段代码”“这里有问题”加载 code-review 5. 用户输入涉及“怎么改”“拆一下”“重构”“优化”加载 refactor 6. 高风险模块支付、队列、第三方对接出现时必须叠加 code-review 合并策略优先级1 2 3介于中间的任务以用户请求的动词最靠前的那个为准。这个规则文件里我特意加了一条“高风险模块叠加”。为什么因为项目的支付回调曾经出过线上事故我希望 AI 每次只要碰到相关文件就直接审查不管用户有没有明确要求。这就是画像如何反馈到路由规则的典型案例。4.3 第三步对接AI编码客户端的三种方式路由包文件准备好之后怎么和具体客户端对接我一般有三种方式方式A把整个目录放进项目根目录利用客户端自带的目录扫描能力自动加载。适合团队协作规则随仓库走所有成员拿到同一套配置。方式B把公共上下文和路由规则放在客户端全局配置里技能文件仍然留在项目仓库。适合个人日常使用项目里不引入杂七杂八的配置文件。方式C用斜杠命令或快捷键手动触发技能文件。适合低频但高要求的场景比如重要代码审查、接口方案评审之前主动唤起特定技能。这三种方式可以混搭。我的习惯是公共上下文放全局路由规则随仓库走高风险场景手动唤起专项技能。这样的组合既保证了日常的自动化又给重要节点留了手动干预的口子。4.4 第四步三轮验证法确认路由生效路由包配置完成之后我从来不会直接开始写业务代码而是先做三轮验证。第一轮是回声验证让模型复述当前加载的规则文件有哪些、优先级如何确认路由文件真的被读取了。第二步是场景验证输入三个典型的任务描述比如“帮我把这个函数拆小一点”“新加一个订单查询接口”“给这个模块补测试”看输出是否命中了预期的技能。第三轮是边界验证故意输入一个模糊请求比如“你看着办”看模型在没有明确路由的情况下默认行为是否合理。这三轮验证看起来很笨但效果极好。它能提前发现八成以上的路由不生效问题而且整个过程只需要十几分钟。很多抱怨“规则没用”的人其实缺的就是这个验证环节。5. 可直接抄作业的技能模板5.1 code-review代码审查技能模板技能文件的核心是行为约束加输出格式。下面是我在 reverse-skill 里长期使用的模板骨架# 技能代码审查 ## 执行步骤 1. 定位本次改动范围列出新增文件和修改文件 2. 新增函数优先检查边界条件、输入校验、异常处理 3. 修改函数优先检查调用方是否兼容、返回值是否变化 4. 全局扫描类型注解是否完整、是否存在硬编码、是否有明显的并发隐患 ## 输出格式 每个问题用四段式输出 - 问题描述说明具体问题和触发场景 - 风险等级高/中/低 - 修改建议给出可落地的改法 - 示例代码贴出推荐写法 ## 兜底规则 如果本次检查的代码非常简短且无明显问题也要输出一句“未发现高等级风险”不要只给一个“没问题”的结论。这里的兜底规则也值得提一下。模型在找不到问题时经常用“没问题”三个字敷衍。我用这个规则强制它至少给出一个结论性的陈述避免不可验证的空白输出。5.2 test-generation测试生成技能模板测试生成技能容易走两个极端一是生成的测试用例只有 happy path不覆盖边界二是乱写 mock把真实行为都屏蔽了测试形同虚设。我的模板里对这两点做了明确约束# 技能测试生成 ## 输入要求 - 需要测试的函数或模块路径 - 该模块涉及的外部依赖数据库、缓存、第三方API ## 执行步骤 1. 分析函数的分支结构列出正常输入、边界输入、非法输入三类场景 2. 优先使用真实依赖只在真实依赖不可用时才使用 mock 3. 测试方法命名采用 test_函数名_场景 的格式让每个用例的意图清晰可读 4. 断言必须包含期望值和期望行为禁止只断言不报错 ## 输出要求 - 给出完整的测试代码可直接放到测试目录运行 - 如有需要 mock 的地方在代码注释里写明原因 - 总用例数不少于 5 个且必须包含至少一个边界用例我后来发现把“mock 必须写明原因”写进模板能显著减少无脑 mock。模型在解释动机的过程中往往会重新思考 mock 是否真的必要效果意外地好。5.3 api-design接口设计技能模板接口设计技能是我在快速迭代项目里用得最多的技能之一。它要解决的核心问题是接口方案不仅要有路径和参数还要考虑错误码、兼容性、幂等性和文档。# 技能接口设计 ## 设计前必读 - 从 context/stack.md 获取当前后端框架约束 - 从 context/architecture.md 获取现有接口风格约定 ## 执行步骤 1. 明确接口的调用方和核心使用场景 2. 设计 RESTful 路径和 HTTP 方法路径尽量名词复数不使用动词 3. 定义请求参数类型、是否必填、默认值、校验规则 4. 定义响应结构成功响应和错误响应分开设计 5. 检查幂等性对于创建、支付类接口必须给出幂等键方案 6. 输出 OpenAPI 风格的简版接口文档 ## 输出格式 接口路径、方法、请求参数表、响应结构、错误码表、调用示例六项缺一不可。模板里的“幂等性检查”是从支付回调事故中沉淀下来的硬性要求。这种教训型规则比任何通用性的“注意安全”表述都更管用。6. 踩坑实录技能路由包常见问题排查速查6.1 规则文件被直接忽略的典型原因规则不生效多数时候不是模型的问题而是配置文件根本没被加载。我遇到过的原因大致有这几种目录名或扩展名不符合客户端要求比如 Cursor 要求.mdc文件塞一个.md进去就直接忽略技能目录里带了空格或特殊字符客户端的路径解析出问题文件体积过大超过客户端的单文件扫描上限。排查这类问题最快的办法就是“回声验证”。让模型先复述加载到的规则文件清单一眼就能看出哪些文件没被读进去。如果模型复述的清单里没有你的规则文件问题基本就锁定在加载环节往下核对目录、扩展名、文件大小就够了。6.2 路由规则冲突导致行为飘忽路由规则冲突的典型表现是同一个任务多问几次模型的行为每次都不一样。一会执行代码审查一会又去改代码输出风格也来回跳。原因是多个技能文件里存在互相矛盾的要求模型在冲突指令之间摇摆。解决办法有两个层次。第一是在路由层明确优先级写清楚“多技能同时命中时以谁为主”第二是在技能文件内部避免互相矛盾比如不要在 code-review 里写“所有输出用中文”又在 test-generation 里写“测试注释用英文”这种冲突要提前在技能模板里消除。我的经验是矛盾类问题在规则设计阶段发现和修复的成本最低越到后面越难改。6.3 技能输出和没配置前没区别配置技能包之后如果发现模型输出和以前没有本质区别问题通常出在技能文件描述太抽象。这是最普遍的问题也最难自己察觉。解决方法是把技能描述从“身份型”改成“行为型”。不要写“你是资深Python专家”要写“检查类型注解是否完整禁用 Any 作为函数参数”。不要写“注意代码质量”要写“对每个问题给出风险等级和修改示例”。行为型描述会给模型明确的执行路径输出质量立刻会有改观。6.4 跨客户端效果不一致怎么办同一套技能包在客户端A表现良好换到客户端B就失效这是我复现率最高的场景之一。根源在于各客户端的加载机制和上下文组织方式不同。有的客户端会把目录全部塞进上下文有的只加载根目录下特定文件。跨客户端使用前一定要重新走一遍回声验证确认哪些文件实际被加载。如果发现目标客户端不支持目录递归加载就把关键规则合并到一个顶层文件里。不要指望一套物理文件结构适配所有客户端合理的做法是准备一份底层模板再按客户端特性做适配。6.5 排查项汇总表现象优先检查项再检查项兜底做法规则完全不生效目录名/扩展名是否符合客户端要求文件是否在扫描路径内回声验证确认加载清单输出风格漂移技能文件是否存在矛盾指令路由优先级是否明确统一合并策略技能输出泛泛是否用了抽象身份描述是否有明确的输出格式约束全部改成行为描述跨客户端失效客户端是否支持目录递归规则文件格式是否兼容关键规则合并到单文件7. 安全与合规边界做逆向要守住哪条线技能路由包的构建过程中我们确实会对AI编码客户端做“逆向分析”但这个逆向和破解、攻击完全是两回事。我给自己划的边界非常清楚可以观察客户端如何组织上下文、分析官方文档和配置文件、通过自身输入输出实验反推触发规律、参考开源社区的插件和规则实现但不可以破解或绕过客户端的付费限制、逆向专有API做未授权调用、获取非公开的内部协议或模型配置。这个边界不是空话。一个效率工具项目能不能持续维护很大程度上取决于它的安全性。如果代码走的是灰色路径一旦被人盯上项目随时可能下架之前的积累全部白费。反过来如果一开始就抱着合法合规的思路做虽然慢一点但每一步都是可积累的。从长期价值来看合规路线才是效率工具的最优解。在项目实践上我也定了几条红线只在公开文档描述的范围内操作客户端配置只用自己本身有权访问的数据和项目做分析技能包中不包含任何绕过鉴权、篡改请求、抓取私有接口的内容。只要守住这几点这个方向的技术探索完全可以放心推进。8. 技能路由包还能怎么扩展这一节算是我的个人建议给想深入这个方向的同行一些参考。第一个扩展方向是跨团队共享。我一开始做 reverse-skill 是为了自己用后来整理成内部仓库同事克隆到各自项目里只需要改一下 context/stack.md就能适配各自的技术栈。这比每个人各自维护一套提示词要高效得多团队层面的提示词资产也能沉淀下来。第二个方向是在CI流程里加一道轻量校验。我在公司内部搭过一个小脚本推送代码时自动提取路由包里的 code-review 技能描述作为提示词输入给独立的模型API对 PR 做前置审查。效果当然比不了正式评审但能把低级问题拦在提交之前算是投资产出比很高的自动化防线。第三个方向是建立反馈回路的持续迭代。我每个月会收集一次路由包误判案例比如模型明明加载了 refactor 技能却给出了不合适的建议分析原因后调整技能文件里的约束条件。坚持两个月之后技能的命中率提升非常明显。这套方法论本质上就是把“和AI打交道”从凭感觉变成按套路观察、假设、配置、验证、迭代和写代码的工程流程没什么两样。对于想把AI编码能力真正沉淀到团队资产里的开发者这个方向值得试一试。