在实际使用大模型辅助编程时最容易出现的问题不是模型不聪明而是它不知道你希望它以什么身份、按什么流程、审查哪些内容。许多团队开始把这类固定套路封装成 Skill而一个叫 /grill-me 的 Skill 就提供了一种很有意思的范式让 AI 像一位不留情面的评审一样对项目进行拷问。这篇文章会从 Skill 的基础概念讲起拆解 /grill-me 这类“拷问式”技能的核心设计再带读者从零编写一个可用的 GrillReviewer Skill并落地到 Claude Code、Codex、Cursor 等支持自定义指令的 AI 编程工具中。1. 先理解 Skill 是什么以及它解决什么问题1.1 一个 Skill 就是一张可复用的“任务剧本”用一句通俗话来说Skill 是给 AI 准备的一份“任务剧本”。平时我们在大模型对话框里写一大段提示词要求 AI 扮演角色、按步骤处理问题、输出指定格式这段提示词是一次性的。Skill 则把这段提示词、配套规则、参考文档甚至辅助脚本打包到一个固定目录中让 AI 可以在需要时自动加载并执行。从技术定义来看Skill 是一套结构化指令集通常由一个入口文件、若干资源文件和可选工具脚本组成。入口文件包含技能的元信息、触发条件、任务流程和输出格式资源文件提供领域规则、代码规范、示例文本脚本负责读取本地文件、调用外部命令或生成中间结果。放在当前 AI 编程工具的场景里一个 Skill 可以理解成一个“可复用的专家插件”。你不需要每次重复解释“请帮我审查代码关注性能、安全、可维护性用表格输出”只要写一个 Skill然后在对话中触发它AI 就会按预设思路执行。对个人开发者和团队来说这种能力能显著减少重复提示词也更容易统一团队的 AI 使用规范。1.2 Skill 和普通 Prompt 的核心差异很多人会问Skill 不就是一段更长的 Prompt 吗这个理解不完全错但会忽略 Skill 的几个关键价值。普通 Prompt 是运行在对话上下文里的临时文本。它的最大问题是不可复用、不可组合、不可版本化。你上周写的一段“代码审查 Prompt”这周可能就找不到了团队里其他人不知道你的审查重点是什么换了模型或工具同一段 Prompt 可能失效。Skill 则把任务流程和工具能力绑定在一起。常见实现中Skill 目录里除了指令文本还可以放参考代码规范文件需要 AI 在审查时逐条核对的项目清单用于扫描文件目录的脚本用于生成结构化报告的模板。这意味着 Skill 不只是“更长的 Prompt”而是一个有目录结构、有资源依赖、能被版本管理的最小任务单元。它让人类和 AI 的协作方式从“临场对话”变成“按剧本执行”。1.3 Skill 的常见工作机制入口、指令、工具、资源在不同工具中Skill 的实现细节可能略有差异但大致遵循同样的工作机制。入口文件通常叫 SKILL.md 或 skill.md。它的作用是让 AI 知道自己该何时使用这个技能、按什么流程执行、最后输出什么。入口文件开头一般包含元信息例如技能名称、描述、适用场景然后是具体的操作指令。指令部分是真正驱动 AI 行为的内容。里面会写清楚用户输入需要如何解析要检查哪些目录或文件从哪个维度展开分析使用什么语气和写作风格最终报告的结构是什么。资源文件和脚本用于补充外部知识或完成 AI 本身不方便做的事情。例如 AI 可以直接读取项目里被用户指定的文件但如果要统计整个代码库的文件数量和类型写一个 Python 脚本会更稳定高效。Skill 可以把脚本路径告诉 AI让 AI 运行脚本并分析输出。1.4 什么场景适合把任务封装成 Skill并不是所有任务都适合做成 Skill。需要重复执行、流程相对固定、有明确输出格式的任务才适合封装。常见场景包括场景为什么适合代码审查审查维度固定输出标准明确需求澄清需要反复追问边界、异常、验收标准架构评审需要按可用性、扩展性、安全性等维度评估测试用例生成输入输出规则清晰可按模板批量生成接口文档检查有固定字段、格式和规范要求反过来如果任务高度依赖临时灵感和上下文比如头脑风暴、闲聊式讨论就不适合用 Skill 约束。Skill 的“剧本感”既是优点也是局限它适合稳定流程不适合完全开放的探索。注意Skill 的价值在于“把不确定的 AI 对话变成相对可控的执行流程”但不要指望它替代人类判断。最终的责任人和决策者仍然是人。2. 从 /grill-me 拆解一个“拷问式” Skill 的核心设计2.1 grill-me 的意图让 AI 主动质疑grill 在英文里有“盘问、拷问”的意思。结合这类 Skill 的命名来看/grill-me 想解决的核心问题是普通 AI 对话太容易顺着用户思路走遇到问题常常给出“看起来很合理”的答案缺少主动挑战和质疑。这种 Skill 的用法通常是让 AI 对某个代码库、方案或需求做一次“对抗式”检查。它不满足于“代码能跑、需求能实现”而是追问边界条件是什么异常情况怎么处理有没有隐藏依赖线上如果出现故障能否快速定位性能瓶颈在哪里安全漏洞会不会被利用这也是它值得学习的原因。把“让 AI 质疑”变成可执行流程实际上是在建立一种代码评审文化先找问题再谈优点。2.2 功能拆解输入、流程、输出要写一个受 /grill-me 启发的 Skill需要先拆清楚它的输入、流程和输出。输入方面常见的输入元素有目标路径要审查的代码目录、文件或文档审查重点用户关心的维度比如安全、性能、可维护性、测试覆盖参考规范团队内部规范或外部标准约束条件时间预算、上下文预算、需要忽略的目录。流程方面可以设计成固定阶段收集项目基本信息扫描目录结构和关键文件按维度逐项审查收集问题现象、原因和严重级别生成结构化报告。输出方面为了让结果可用最好统一成 Markdown 报告包含问题清单、风险等级、修复建议、优先级排序。2.3 设计一个 GrillReviewer 技能的目标基于前面的分析这篇文章要实现的 GrillReviewer Skill 可以定义为一套“通用代码与方案质询工具”。它在触发以后会对用户指定的目录或文件进行扫描从需求完整性、代码结构、性能、安全、异常处理、可测试性、可观测性等维度提出质疑对每个问题给出严重级别、证据位置和解决建议最后生成一份适合复制到 commit message、需求文档或排期计划中的报告。它不是一次性使用的提示词而是可以安装到个人开发机或团队项目中的真实技能包。后续无论是做 Code Review 还是设计评审都可以直接调用。2.4 边界Skill 不该做什么写 Skill 时最容易犯的错误是“想把所有能力都塞进去”。受 /grill-me 启发的 Skill 也应当注意边界。它不应该擅自修改代码。评审角色和开发角色要分离AI 可以先发现问题是否修复由开发者决定。它不应该无限扫描超大仓库。现实项目中一次性扫描几十万行代码会消耗大量上下文Skill 设计要有范围限制默认只审查用户指定目录或最近变更的文件。它也不应该输出没有依据的判断。AI 给出的每个问题最好都能追溯到具体文件、函数或配置项。注意拷问式 Skill 的重点是“帮人发现问题”不是“替人做决定”。所有结论都要能被复核、被反驳、被调整。3. 动手编写一个可用的 Skill 目录结构与代码这一部分开始进入实现。为了让例子足够通用我会先设计一套不绑定特定工具的 Skill 目录结构再分别说明如何安装到常见 AI 编程工具中。示例代码用于说明思路实际项目要结合自己的包名、目录和工具版本调整。3.1 目录结构设计一个 Skill 可以包含入口文件、规则文件、脚本和模板。推荐目录结构如下grill-reviewer/ ├── SKILL.md ├── assets/ │ ├── review_rules.md │ └── report_template.md └── scripts/ └── collect_files.py每个文件的作用SKILL.md技能入口包含元信息、触发条件和执行指令assets/review_rules.md审查规则清单AI 会逐条参考assets/report_template.md最终报告模板scripts/collect_files.py扫描目录输出文件树和文件类型统计减少 AI 的目录读取负担。这个结构的好处是指令、规则、脚本分离后续想调整审查维度时只需要修改 review_rules.md不需要改大段 prompt。3.2 编写 SKILL.md 入口文件SKILL.md 是 AI 最先读取的文件它的质量决定了这个技能是否能被正确触发和执行。下面是一个参考实现--- name: grill-reviewer description: 对项目代码、设计方案或需求文档进行系统性质询生成问题清单、风险等级和修复建议。 when_to_use: 当用户希望审查代码、评审方案、分析需求边界或让 AI 主动寻找项目问题时使用。 ---具体指令写在 YAML 分隔线之后你是一位严格的内部评审专家正在对用户指定的项目进行“拷问式审查”。不要只表扬优点要主动寻找问题、风险、遗漏和矛盾点。 执行流程 1. 判断用户输入。如果用户给出路径按照路径分析如果没有给出路径询问需要审查的范围。 2. 如果存在 scripts/collect_files.py先运行脚本收集文件树和统计信息。 3. 读取 assets/review_rules.md并逐条检查项目中是否存在对应问题。 4. 对每个发现输出 - 问题描述要具体包含文件路径或函数名 - 为什么这是问题解释影响 - 严重级别严重 / 中等 / 建议 - 修复建议给出可操作方案 5. 最终按 assets/report_template.md 生成报告。 输出要求 - 使用中文输出 - 问题按严重级别排序 - 如果某个维度没有问题必须明确写“未发现明显问题” - 不允许凭空捏造不存在的问题 - 不确定的内容要在报告中标注“需人工确认”。这里的关键设计点有三个。第一它声明了“不要只表扬优点”这就把普通助手模式切换成评审模式。第二它让 AI 先读规则文件确保每次输出都有统一依据。第三它要求每个问题都带上路径或函数名避免空泛结论。3.3 制定审查规则文件assets/review_rules.md 是 GrillReviewer 的内核。它决定了 AI 会从哪些角度提问。下面是一个可扩展的规则示例# GrillReviewer 审查规则 ## 需求完整性 - 是否有未定义的输入边界 - 是否存在空值、超长值、特殊字符未处理 - 需求中是否遗漏异常分支或失败回退路径 ## 代码结构 - 模块依赖是否清晰 - 是否存在循环依赖或隐式全局状态 - 函数是否过长、职责是否单一 - 命名是否准确表达意图 ## 性能 - 是否存在明显不必要的重复计算 - 是否在循环中执行了数据库查询、HTTP 请求或 IO 操作 - 大数据量情况下内存占用是否会失控 - 缓存策略是否合理缓存失效是否明确 ## 安全性 - 是否存在 SQL 注入、命令注入、路径穿越风险 - 敏感信息是否被写入日志或响应体 - 文件和接口是否有越权访问风险 - 依赖组件版本是否存在已知漏洞 ## 异常处理 - 是否捕获了异常但悄悄吞掉错误 - 外部服务调用是否设置了超时和重试 - 失败时用户是否能得到明确反馈 - 事务回滚和补偿机制是否存在 ## 可测试性 - 核心逻辑是否容易被单测覆盖 - 是否依赖难以 mock 的外部资源 - 是否存在硬编码配置导致测试环境难以切换 ## 可观测性 - 核心流程是否有日志记录 - 是否有指标监控和链路跟踪 - 错误是否带有足够的上下文信息这个文件不是让 AI 机械地照读而是作为“审查清单”使用。AI 在分析项目时应该结合项目语言和框架判断这些规则如何落地。在实际项目中团队可以把自己的代码规范、安全基线、性能红线补充到规则文件里。3.4 设计报告模板报告模板决定了最终输出的可读性。这里设计一个简洁的结构# 项目审查报告{目标路径} 审查时间{当前时间} 审查范围{文件数量、目录、语言} ## 问题总览 | 严重级别 | 数量 | | --- | --- | | 严重 | {N} | | 中等 | {N} | | 建议 | {N} | ## 问题明细 ### 严重 - 问题{问题描述} - 位置{文件路径和关键代码位置} - 依据{对应规则或代码逻辑} - 修复建议{可执行方案} ### 中等 格式同上 ### 建议 格式同上 ## 未发现问题的维度 列出检查过且没有发现明显问题的维度方便读者判断审查覆盖情况。 ## 需人工确认 列出现有信息无法确定、需要开发者确认的疑点。有了这个模板输出不会变成自由发挥而是可比较、可追踪的结构化报告。后面接入 CI 或自动生成总结时也更容易做文本解析。3.5 编写辅助脚本 collect_files.pyAI 直接遍历项目目录可能很慢而且容易迷失在大量文件中。写一个小脚本扫描文件树可以显著提升效率。下面这个 Python 脚本会输出项目文件树、文件类型统计和总文件数#!/usr/bin/env python3 import os import sys from collections import Counter def main(): root sys.argv[1] if len(sys.argv) 1 else . exclude_dirs {.git, node_modules, venv, .venv, __pycache__, .idea, .vscode, dist, build, .next, .cache} file_counter Counter() total_files 0 lines [# Project File Tree\n] for dirpath, dirnames, filenames in os.walk(root): dirnames[:] [d for d in dirnames if d not in exclude_dirs] level dirpath.replace(root, ).count(os.sep) indent * level folder os.path.basename(dirpath) or root lines.append(f{indent}{folder}/) sub_indent * (level 1) for filename in sorted(filenames): lines.append(f{sub_indent}{filename}) ext os.path.splitext(filename)[1].lower() or (no-ext) file_counter[ext] 1 total_files 1 lines.append() lines.append(f## Statistics: total {total_files} files\n) lines.append(| Extension | Count |) lines.append(| --- | --- |) for ext, count in file_counter.most_common(): lines.append(f| {ext} | {count} |) output \n.join(lines) print(output) if __name__ __main__: main()脚本输出会包含相对文件树和扩展名统计。AI 拿到这些数据后可以更快判断应该优先读哪些目录而不是盲目扫描全仓库。实际使用中可以根据需要增加“最近 N 天修改的文件”过滤、按语言筛选、忽略指定目录等功能。执行脚本检查python3 scripts/collect_files.py ./src如果脚本有语法错误或没有权限AI 应该报告错误而不是假装已经执行成功。3.6 安装到常见 AI 编程工具中不同工具对 Skill 的安装路径和命名要求不同。下面给出通用参考实际安装前需要对照所用工具的文档确认。Claude Code 中个人级 skill 通常放在~/.claude/skills/项目级 skill 放在.claude/skills/下每个技能一个子目录子目录中需要包含 SKILL.md。安装命令实质是把 grill-reviewer 目录复制到对应 skills 目录cp -r grill-reviewer ~/.claude/skills/Codex 类工具中技能文件可能放在~/.codex/skills/或项目的.codex/目录下。具体目录名和加载方式取决于版本建议先查看版本说明。Cursor 中可以通过自定义 slash command 实现类似效果。把 SKILL.md 内容转换成指令绑定到/grill这样的快捷命令中再把 assets 和 scripts 作为相对路径引用。由于每个工具都在快速更新这里不写成绝对步骤。核心思路是一样的找到工具加载 skill 的目录把技能文件夹放进去然后在对话中触发。触发方式可能是/skill-name也可能是skill-name需要看工具支持情况。注意如果你的工具不支持 SKILL.md 标准结构可以把入口文件内容复制到自定义指令中这不影响学习效果。4. 使用方法和运行验证4.1 在对话中触发 Skill安装完成后在支持的 AI 编程工具中进入对话直接输入技能名。假设技能名为 grill-reviewer可以这样触发/grill-reviewer ./src或者使用 grill-reviewer 审查当前项目的 src 目录。如果 AI 正确识别了技能它会按照 SKILL.md 中定义的流程走先运行 collect_files.py 收集目录信息再读取审查规则最后输出报告。4.2 传入目标路径或问题调用 Skill 时可以传入不同参数/grill-reviewer ./src审查 src 目录/grill-reviewer ./README.md审查单个文档/grill-reviewer ./后端服务重点看安全和性能指定审查重点/grill-reviewer ./services/auth忽略测试文件指定过滤条件。在 SKILL.md 的指令中可以要求 AI 在缺少参数时主动询问用户而不是默认扫描整个仓库。这样可以避免误读大目录也节省 token。4.3 预期输出示例一次成功执行后AI 会输出类似下面的报告结构# 项目审查报告./samples/ecommerce 审查时间2025-01-10 14:30 审查文件数42 ## 问题总览 | 严重级别 | 数量 | | --- | --- | | 严重 | 3 | | 中等 | 7 | | 建议 | 5 | ## 严重问题 - 问题用户输入未编码直接拼入 SQL 查询 - 位置samples/ecommerce/order.py:102 - 依据使用 f-string 拼接查询条件存在 SQL 注入风险 - 修复建议改用参数化查询禁止拼接 SQL ## 需人工确认 - 支付回调中的验签逻辑未在本次审查范围内需要补充上下文后再确认。4.4 验证 Skill 是否生效很多人把 Skill 放进目录后发现 AI 没有按照预期执行。验证逻辑应该按下面顺序来确认 Skill 目录被工具扫描到。可以查看工具的配置、日志或运行状态确认触发方式正确。是输入/skill-name还是skill-name确认技能描述能匹配当前对话。技能描述写的是“审查代码”用户却问“写一首诗”AI 可能不会触发确认 SKILL.md 格式没有错误。YAML 元信息如果解析失败技能可能被跳过确认辅助脚本路径正确。建议在技能指令中写明脚本相对路径。4.5 参数调优扫描范围、过滤规则和上下文消耗在实际项目中审查一个大型仓库很容易耗尽上下文。可以给 Skill 增加几个可调参数参数作用建议值max_depth控制目录扫描深度2 到 4 层exclude_dirs排除会产生噪音的目录node_modules、dist、.gitfile_extensions限制文件类型按项目语言设置max_files最大文件数量100 到 300超过则询问用户这些参数可以在 SKILL.md 指令里定义也可以放在配置文件中。关键是让 AI 在超限时停下来询问用户而不是硬着头皮继续扫描。5. Skill 与 MCP、Agent 的区别和配合方式5.1 为什么总有人把 Skill 和 MCP 混淆在相关热词中经常能看到“agent skill 和 mcp 有什么区别”这个问题。原因是这两个概念都出现在 AI Agent 生态里而且都能让 AI 调用外部资源容易混淆。Skill 是一种指令和资源的静态打包解决的是“AI 该怎么做事”的问题。MCPModel Context Protocol是一种开放协议解决的是“AI 如何连接外部工具和数据源”的问题。一个 Skill 可以定义“先读取代码再调用安全扫描工具最后生成报告”但具体怎么连接安全扫描工具可以通过 MCP Server 提供统一接口。简单说Skill 是“流程剧本”MCP 是“工具接口”。它们不在同一条线上而是可以配合使用。5.2 Skill 是“剧本”MCP 是“工具箱”用项目开发的类比来理解Skill 像项目里的流程文档写着“需求评审要经过哪些阶段、由谁检查、输出什么”MCP 像项目里的一组 API让不同系统之间能够安全地交换数据Agent 更像执行者它读取流程文档调用 API完成具体任务。在 GrillReviewer 的例子中Skill 规定了审查步骤和报告格式。如果团队有一个代码搜索工具、一个依赖漏洞扫描服务、一个数据库查询网关这些都可以通过 MCP Server 暴露给 Agent。Skill 告诉 Agent 什么时候去调用这些服务MCP 则负责把调用请求转换成服务端能理解的消息格式。5.3 实际项目中如何配合假设要做一个更强大的代码审查系统可以把 GrillReviewer 拆成两层Skill 层定义审查流程、规则、报告模板MCP Server 层提供读取 Git 变更、查询漏洞库、搜索代码片段、调用测试平台等能力。SKILL.md 中可以用类似下面的方式描述工具调用步骤 3如果 MCP 服务已连接调用 get_git_changes 获取本次变更文件列表然后只审查变更范围内的代码。 步骤 4调用 check_dependency_vulnerabilities 检查依赖锁文件中的组件版本判断是否存在已知风险。这样做的好处是同一个 Skill 在不同环境中可以连接不同的 MCP Server。本地开发时连接本地 Git 服务CI 中连接安全扫描服务流程本身不用重写。5.4 选型建议到底只写 Skill还是连接 MCP取决于任务复杂度。维度SkillSkill MCP成本低只需写 prompt 和少量脚本较高需要开发和维护服务端适用场景固定流程、本地文件、单机任务需要实时数据、跨系统调用、多工具协作维护难度简单需要考虑协议、鉴权、服务稳定性推荐人群个人开发者、小团队平台团队、企业级 AI 工具链对大多数个人项目来说先写 Skill 就够了。等到确实需要 AI 实时查询数据库、调用 CI 系统、连接公司内部文档时再引入 MCP 层避免一开始就把架构做复杂。6. 常见问题排查Skill 在开发和安装过程中会遇到不少问题。下面按从现象到原因到解决方式的顺序整理。6.1 Skill 没有被触发现象输入/grill-reviewer ./src后AI 仍然像普通对话一样回答没有执行技能流程。可能原因技能目录没被扫描到技能描述与用户输入不匹配触发符号错误SKILL.md 元信息解析失败。检查方式确认目录位置是否正确查看工具是否加载了该技能尝试在技能描述中增加关键词比如“审查、评审、问题、方案分析”。解决方式重新复制技能目录确认 SKILL.md 编码为 UTF-8检查 YAML 格式。如果工具支持在配置中手动添加技能目录。6.2 中文或特殊字符导致乱码现象AI 读取规则文件或报告时出现乱码或者脚本输出中文路径显示异常。可能原因文件编码不是 UTF-8终端或工具默认编码不匹配Python 脚本输出时未指定编码。检查方式用编辑器打开文件确认编码命令行执行file SKILL.md查看编码。解决方式所有 skill 文件统一使用 UTF-8 编码Python 脚本可以通过环境变量PYTHONUTF81或代码中指定输出编码。注意不要依赖记事本默认编码尽量使用支持显示编码格式的编辑器。6.3 辅助脚本权限不足或路径错误现象AI 说“无法运行 collect_files.py”或提示没有权限、文件不存在。可能原因脚本没有执行权限指令中的相对路径不是从 Skill 根目录解析的当前系统缺少 Python 环境。检查方式ls -l scripts/collect_files.py python3 scripts/collect_files.py ./src解决方式给脚本加上执行权限或者改用python3 scripts/collect_files.py的方式调用。在 SKILL.md 的指令中尽量使用从技能根目录开始的相对路径并明确调用方式。6.4 上下文过长审查后报告被截断现象AI 扫描了很多文件还没开始输出完整报告上下文窗口就满了。可能原因扫描范围过大规则文件太长AI 在审查过程中把大文件原文读入上下文。解决方式增加 max_files 限制让 AI 优先读摘要和关键文件要求 AI 分段输出报告先输出问总览再逐项输出明细在规则中明确“不要一次性读取超过 10 个大文件”。6.5 Skill 目录命名和格式不兼容现象不同工具之间复制 Skill 后失效。可能原因每个工具对 Skill 目录、SKILL.md 格式和元信息字段的要求不同。解决方式不要把某种工具的特殊配置当成通用规则。迁移到新工具时先阅读该工具的 skill 或自定义指令文档把元信息字段和目录结构调整到兼容格式。6.6 报告内容空泛、没有证据现象AI 输出了很多“建议优化代码质量”“注意安全性”之类的大话但没有任何具体位置。可能原因SKILL.md 中没有强制要求带文件路径和函数名规则文件太多AI 只能泛泛而谈。解决方式在输出要求中明确“每个问题必须给出文件路径没有证据的问题要标注为假设”。同时可以通过脚本把文件关键函数清单预先提取出来让 AI 基于清单分析。7. 最佳实践与扩展方向7.1 Skill 设计最佳实践写 Skill 时可以按下面这份清单来校验技能是否有明确目标一个 Skill 只解决一个问题不要试图覆盖所有场景。是否写清楚触发条件让 AI 能在合适的对话里想到调用它。是否把规则外置不要把所有审查要求都堆在 SKILL.md 中独立规则文件更容易维护。是否限制扫描范围默认值不要是“扫描整个仓库”。是否要求给出证据所有结论尽可能带上文件路径和上下文。是否设计输出模板结构化输出更容易被人类阅读并被下游工具解析。是否需要脚本辅助如果任务涉及目录遍历、数据转换、外部命令用脚本比让 AI 自己实现更可靠。是否能版本化把 Skill 放进 Git 仓库随代码一起管理。这些都是可以在项目里落地的实践。哪怕只是一个几百行的简单 Skill遵守这套标准也能避免后续返工。7.2 安全和隐私Skill 虽然只是文本和脚本但同样存在安全和隐私问题。第一Skill 可能读取敏感目录。代码如果包含.env、密钥文件和访问凭据审查报告可能会泄露这些信息。规则文件中应添加“忽略敏感文件”的声明默认不读取以下文件 .env *.pem *.key id_rsa第二用户从网上下载的 Skill 可能包含恶意指令。它可能诱导 AI 输出隐私数据或运行未知脚本。使用第三方 Skill 之前要检查 SKILL.md 内容和脚本代码不要盲目信任。第三在团队内共享 Skill 时需要确认规则和脚本是否符合团队安全规范。特别是涉及外部命令或网络请求的脚本要评估数据外发风险。7.3 从 grill-me 出发还能扩展哪些 SkillGrillReviewer 只是一个小小的开始。沿着“让 AI 主动质疑”的思路可以继续扩展出更多技能架构评审 Skill输入系统设计文档输出单点故障、瓶颈、扩展性风险需求澄清 Skill输入一段产品描述输出待确认问题清单、边界条件、验收标准草稿变更影响分析 Skill输入 git diff输出受影响模块、风险点、需要执行的回归测试范围故障复盘 Skill输入日志和时间线输出根因假设、遗漏信号、改进事项。这些技能共享同一套设计思想定义输入、固定流程、产出具报告。一旦掌握了一个 Skill 的写法其他技能只是规则文件、脚本和模板的替换。7.4 给新手的练习路径如果你之前没有写过 Skill可以按下面顺序练习。第一步先在对话里手写一段“审查 prompt”看 AI 会输出什么。第二步把这段 prompt 放到 SKILL.md 中只保留最简单的指令测试触发能否成功。第三步加入一个规则文件例如三条安全规则观察输出差异。第四步加入脚本让 AI 先获取文件树再分析。第五步设计报告模板让输出结构化。第六步加入限制条件和错误处理比如文件数量上限、参数缺失时询问用户。这六步做完你就已经具备独立编写 Skill 的能力。后续再接触 MCP、Agent 编排、可观测性接入都是在这个基础上做加法。回到 /grill-me 这类 skill 给我们的启发高质量 AI 协作不只需要“让模型回答”更需要设计一套约束模型行为的方式。GrillReviewer 的实践表明一个几十行的 SKILL.md 加上少量规则脚本就能把 AI 从“顺着人说话”的助手变成主动发现问题的评审者。对于日常开发建议先做一个最小可用版本在真实项目里跑几次再根据报告质量迭代规则文件。技能的设计永远是为人的决策服务这一点不会变。 从零编写GrillReviewer Skill：让AI成为主动质疑的代码审查专家
在实际使用大模型辅助编程时最容易出现的问题不是模型不聪明而是它不知道你希望它以什么身份、按什么流程、审查哪些内容。许多团队开始把这类固定套路封装成 Skill而一个叫 /grill-me 的 Skill 就提供了一种很有意思的范式让 AI 像一位不留情面的评审一样对项目进行拷问。这篇文章会从 Skill 的基础概念讲起拆解 /grill-me 这类“拷问式”技能的核心设计再带读者从零编写一个可用的 GrillReviewer Skill并落地到 Claude Code、Codex、Cursor 等支持自定义指令的 AI 编程工具中。1. 先理解 Skill 是什么以及它解决什么问题1.1 一个 Skill 就是一张可复用的“任务剧本”用一句通俗话来说Skill 是给 AI 准备的一份“任务剧本”。平时我们在大模型对话框里写一大段提示词要求 AI 扮演角色、按步骤处理问题、输出指定格式这段提示词是一次性的。Skill 则把这段提示词、配套规则、参考文档甚至辅助脚本打包到一个固定目录中让 AI 可以在需要时自动加载并执行。从技术定义来看Skill 是一套结构化指令集通常由一个入口文件、若干资源文件和可选工具脚本组成。入口文件包含技能的元信息、触发条件、任务流程和输出格式资源文件提供领域规则、代码规范、示例文本脚本负责读取本地文件、调用外部命令或生成中间结果。放在当前 AI 编程工具的场景里一个 Skill 可以理解成一个“可复用的专家插件”。你不需要每次重复解释“请帮我审查代码关注性能、安全、可维护性用表格输出”只要写一个 Skill然后在对话中触发它AI 就会按预设思路执行。对个人开发者和团队来说这种能力能显著减少重复提示词也更容易统一团队的 AI 使用规范。1.2 Skill 和普通 Prompt 的核心差异很多人会问Skill 不就是一段更长的 Prompt 吗这个理解不完全错但会忽略 Skill 的几个关键价值。普通 Prompt 是运行在对话上下文里的临时文本。它的最大问题是不可复用、不可组合、不可版本化。你上周写的一段“代码审查 Prompt”这周可能就找不到了团队里其他人不知道你的审查重点是什么换了模型或工具同一段 Prompt 可能失效。Skill 则把任务流程和工具能力绑定在一起。常见实现中Skill 目录里除了指令文本还可以放参考代码规范文件需要 AI 在审查时逐条核对的项目清单用于扫描文件目录的脚本用于生成结构化报告的模板。这意味着 Skill 不只是“更长的 Prompt”而是一个有目录结构、有资源依赖、能被版本管理的最小任务单元。它让人类和 AI 的协作方式从“临场对话”变成“按剧本执行”。1.3 Skill 的常见工作机制入口、指令、工具、资源在不同工具中Skill 的实现细节可能略有差异但大致遵循同样的工作机制。入口文件通常叫 SKILL.md 或 skill.md。它的作用是让 AI 知道自己该何时使用这个技能、按什么流程执行、最后输出什么。入口文件开头一般包含元信息例如技能名称、描述、适用场景然后是具体的操作指令。指令部分是真正驱动 AI 行为的内容。里面会写清楚用户输入需要如何解析要检查哪些目录或文件从哪个维度展开分析使用什么语气和写作风格最终报告的结构是什么。资源文件和脚本用于补充外部知识或完成 AI 本身不方便做的事情。例如 AI 可以直接读取项目里被用户指定的文件但如果要统计整个代码库的文件数量和类型写一个 Python 脚本会更稳定高效。Skill 可以把脚本路径告诉 AI让 AI 运行脚本并分析输出。1.4 什么场景适合把任务封装成 Skill并不是所有任务都适合做成 Skill。需要重复执行、流程相对固定、有明确输出格式的任务才适合封装。常见场景包括场景为什么适合代码审查审查维度固定输出标准明确需求澄清需要反复追问边界、异常、验收标准架构评审需要按可用性、扩展性、安全性等维度评估测试用例生成输入输出规则清晰可按模板批量生成接口文档检查有固定字段、格式和规范要求反过来如果任务高度依赖临时灵感和上下文比如头脑风暴、闲聊式讨论就不适合用 Skill 约束。Skill 的“剧本感”既是优点也是局限它适合稳定流程不适合完全开放的探索。注意Skill 的价值在于“把不确定的 AI 对话变成相对可控的执行流程”但不要指望它替代人类判断。最终的责任人和决策者仍然是人。2. 从 /grill-me 拆解一个“拷问式” Skill 的核心设计2.1 grill-me 的意图让 AI 主动质疑grill 在英文里有“盘问、拷问”的意思。结合这类 Skill 的命名来看/grill-me 想解决的核心问题是普通 AI 对话太容易顺着用户思路走遇到问题常常给出“看起来很合理”的答案缺少主动挑战和质疑。这种 Skill 的用法通常是让 AI 对某个代码库、方案或需求做一次“对抗式”检查。它不满足于“代码能跑、需求能实现”而是追问边界条件是什么异常情况怎么处理有没有隐藏依赖线上如果出现故障能否快速定位性能瓶颈在哪里安全漏洞会不会被利用这也是它值得学习的原因。把“让 AI 质疑”变成可执行流程实际上是在建立一种代码评审文化先找问题再谈优点。2.2 功能拆解输入、流程、输出要写一个受 /grill-me 启发的 Skill需要先拆清楚它的输入、流程和输出。输入方面常见的输入元素有目标路径要审查的代码目录、文件或文档审查重点用户关心的维度比如安全、性能、可维护性、测试覆盖参考规范团队内部规范或外部标准约束条件时间预算、上下文预算、需要忽略的目录。流程方面可以设计成固定阶段收集项目基本信息扫描目录结构和关键文件按维度逐项审查收集问题现象、原因和严重级别生成结构化报告。输出方面为了让结果可用最好统一成 Markdown 报告包含问题清单、风险等级、修复建议、优先级排序。2.3 设计一个 GrillReviewer 技能的目标基于前面的分析这篇文章要实现的 GrillReviewer Skill 可以定义为一套“通用代码与方案质询工具”。它在触发以后会对用户指定的目录或文件进行扫描从需求完整性、代码结构、性能、安全、异常处理、可测试性、可观测性等维度提出质疑对每个问题给出严重级别、证据位置和解决建议最后生成一份适合复制到 commit message、需求文档或排期计划中的报告。它不是一次性使用的提示词而是可以安装到个人开发机或团队项目中的真实技能包。后续无论是做 Code Review 还是设计评审都可以直接调用。2.4 边界Skill 不该做什么写 Skill 时最容易犯的错误是“想把所有能力都塞进去”。受 /grill-me 启发的 Skill 也应当注意边界。它不应该擅自修改代码。评审角色和开发角色要分离AI 可以先发现问题是否修复由开发者决定。它不应该无限扫描超大仓库。现实项目中一次性扫描几十万行代码会消耗大量上下文Skill 设计要有范围限制默认只审查用户指定目录或最近变更的文件。它也不应该输出没有依据的判断。AI 给出的每个问题最好都能追溯到具体文件、函数或配置项。注意拷问式 Skill 的重点是“帮人发现问题”不是“替人做决定”。所有结论都要能被复核、被反驳、被调整。3. 动手编写一个可用的 Skill 目录结构与代码这一部分开始进入实现。为了让例子足够通用我会先设计一套不绑定特定工具的 Skill 目录结构再分别说明如何安装到常见 AI 编程工具中。示例代码用于说明思路实际项目要结合自己的包名、目录和工具版本调整。3.1 目录结构设计一个 Skill 可以包含入口文件、规则文件、脚本和模板。推荐目录结构如下grill-reviewer/ ├── SKILL.md ├── assets/ │ ├── review_rules.md │ └── report_template.md └── scripts/ └── collect_files.py每个文件的作用SKILL.md技能入口包含元信息、触发条件和执行指令assets/review_rules.md审查规则清单AI 会逐条参考assets/report_template.md最终报告模板scripts/collect_files.py扫描目录输出文件树和文件类型统计减少 AI 的目录读取负担。这个结构的好处是指令、规则、脚本分离后续想调整审查维度时只需要修改 review_rules.md不需要改大段 prompt。3.2 编写 SKILL.md 入口文件SKILL.md 是 AI 最先读取的文件它的质量决定了这个技能是否能被正确触发和执行。下面是一个参考实现--- name: grill-reviewer description: 对项目代码、设计方案或需求文档进行系统性质询生成问题清单、风险等级和修复建议。 when_to_use: 当用户希望审查代码、评审方案、分析需求边界或让 AI 主动寻找项目问题时使用。 ---具体指令写在 YAML 分隔线之后你是一位严格的内部评审专家正在对用户指定的项目进行“拷问式审查”。不要只表扬优点要主动寻找问题、风险、遗漏和矛盾点。 执行流程 1. 判断用户输入。如果用户给出路径按照路径分析如果没有给出路径询问需要审查的范围。 2. 如果存在 scripts/collect_files.py先运行脚本收集文件树和统计信息。 3. 读取 assets/review_rules.md并逐条检查项目中是否存在对应问题。 4. 对每个发现输出 - 问题描述要具体包含文件路径或函数名 - 为什么这是问题解释影响 - 严重级别严重 / 中等 / 建议 - 修复建议给出可操作方案 5. 最终按 assets/report_template.md 生成报告。 输出要求 - 使用中文输出 - 问题按严重级别排序 - 如果某个维度没有问题必须明确写“未发现明显问题” - 不允许凭空捏造不存在的问题 - 不确定的内容要在报告中标注“需人工确认”。这里的关键设计点有三个。第一它声明了“不要只表扬优点”这就把普通助手模式切换成评审模式。第二它让 AI 先读规则文件确保每次输出都有统一依据。第三它要求每个问题都带上路径或函数名避免空泛结论。3.3 制定审查规则文件assets/review_rules.md 是 GrillReviewer 的内核。它决定了 AI 会从哪些角度提问。下面是一个可扩展的规则示例# GrillReviewer 审查规则 ## 需求完整性 - 是否有未定义的输入边界 - 是否存在空值、超长值、特殊字符未处理 - 需求中是否遗漏异常分支或失败回退路径 ## 代码结构 - 模块依赖是否清晰 - 是否存在循环依赖或隐式全局状态 - 函数是否过长、职责是否单一 - 命名是否准确表达意图 ## 性能 - 是否存在明显不必要的重复计算 - 是否在循环中执行了数据库查询、HTTP 请求或 IO 操作 - 大数据量情况下内存占用是否会失控 - 缓存策略是否合理缓存失效是否明确 ## 安全性 - 是否存在 SQL 注入、命令注入、路径穿越风险 - 敏感信息是否被写入日志或响应体 - 文件和接口是否有越权访问风险 - 依赖组件版本是否存在已知漏洞 ## 异常处理 - 是否捕获了异常但悄悄吞掉错误 - 外部服务调用是否设置了超时和重试 - 失败时用户是否能得到明确反馈 - 事务回滚和补偿机制是否存在 ## 可测试性 - 核心逻辑是否容易被单测覆盖 - 是否依赖难以 mock 的外部资源 - 是否存在硬编码配置导致测试环境难以切换 ## 可观测性 - 核心流程是否有日志记录 - 是否有指标监控和链路跟踪 - 错误是否带有足够的上下文信息这个文件不是让 AI 机械地照读而是作为“审查清单”使用。AI 在分析项目时应该结合项目语言和框架判断这些规则如何落地。在实际项目中团队可以把自己的代码规范、安全基线、性能红线补充到规则文件里。3.4 设计报告模板报告模板决定了最终输出的可读性。这里设计一个简洁的结构# 项目审查报告{目标路径} 审查时间{当前时间} 审查范围{文件数量、目录、语言} ## 问题总览 | 严重级别 | 数量 | | --- | --- | | 严重 | {N} | | 中等 | {N} | | 建议 | {N} | ## 问题明细 ### 严重 - 问题{问题描述} - 位置{文件路径和关键代码位置} - 依据{对应规则或代码逻辑} - 修复建议{可执行方案} ### 中等 格式同上 ### 建议 格式同上 ## 未发现问题的维度 列出检查过且没有发现明显问题的维度方便读者判断审查覆盖情况。 ## 需人工确认 列出现有信息无法确定、需要开发者确认的疑点。有了这个模板输出不会变成自由发挥而是可比较、可追踪的结构化报告。后面接入 CI 或自动生成总结时也更容易做文本解析。3.5 编写辅助脚本 collect_files.pyAI 直接遍历项目目录可能很慢而且容易迷失在大量文件中。写一个小脚本扫描文件树可以显著提升效率。下面这个 Python 脚本会输出项目文件树、文件类型统计和总文件数#!/usr/bin/env python3 import os import sys from collections import Counter def main(): root sys.argv[1] if len(sys.argv) 1 else . exclude_dirs {.git, node_modules, venv, .venv, __pycache__, .idea, .vscode, dist, build, .next, .cache} file_counter Counter() total_files 0 lines [# Project File Tree\n] for dirpath, dirnames, filenames in os.walk(root): dirnames[:] [d for d in dirnames if d not in exclude_dirs] level dirpath.replace(root, ).count(os.sep) indent * level folder os.path.basename(dirpath) or root lines.append(f{indent}{folder}/) sub_indent * (level 1) for filename in sorted(filenames): lines.append(f{sub_indent}{filename}) ext os.path.splitext(filename)[1].lower() or (no-ext) file_counter[ext] 1 total_files 1 lines.append() lines.append(f## Statistics: total {total_files} files\n) lines.append(| Extension | Count |) lines.append(| --- | --- |) for ext, count in file_counter.most_common(): lines.append(f| {ext} | {count} |) output \n.join(lines) print(output) if __name__ __main__: main()脚本输出会包含相对文件树和扩展名统计。AI 拿到这些数据后可以更快判断应该优先读哪些目录而不是盲目扫描全仓库。实际使用中可以根据需要增加“最近 N 天修改的文件”过滤、按语言筛选、忽略指定目录等功能。执行脚本检查python3 scripts/collect_files.py ./src如果脚本有语法错误或没有权限AI 应该报告错误而不是假装已经执行成功。3.6 安装到常见 AI 编程工具中不同工具对 Skill 的安装路径和命名要求不同。下面给出通用参考实际安装前需要对照所用工具的文档确认。Claude Code 中个人级 skill 通常放在~/.claude/skills/项目级 skill 放在.claude/skills/下每个技能一个子目录子目录中需要包含 SKILL.md。安装命令实质是把 grill-reviewer 目录复制到对应 skills 目录cp -r grill-reviewer ~/.claude/skills/Codex 类工具中技能文件可能放在~/.codex/skills/或项目的.codex/目录下。具体目录名和加载方式取决于版本建议先查看版本说明。Cursor 中可以通过自定义 slash command 实现类似效果。把 SKILL.md 内容转换成指令绑定到/grill这样的快捷命令中再把 assets 和 scripts 作为相对路径引用。由于每个工具都在快速更新这里不写成绝对步骤。核心思路是一样的找到工具加载 skill 的目录把技能文件夹放进去然后在对话中触发。触发方式可能是/skill-name也可能是skill-name需要看工具支持情况。注意如果你的工具不支持 SKILL.md 标准结构可以把入口文件内容复制到自定义指令中这不影响学习效果。4. 使用方法和运行验证4.1 在对话中触发 Skill安装完成后在支持的 AI 编程工具中进入对话直接输入技能名。假设技能名为 grill-reviewer可以这样触发/grill-reviewer ./src或者使用 grill-reviewer 审查当前项目的 src 目录。如果 AI 正确识别了技能它会按照 SKILL.md 中定义的流程走先运行 collect_files.py 收集目录信息再读取审查规则最后输出报告。4.2 传入目标路径或问题调用 Skill 时可以传入不同参数/grill-reviewer ./src审查 src 目录/grill-reviewer ./README.md审查单个文档/grill-reviewer ./后端服务重点看安全和性能指定审查重点/grill-reviewer ./services/auth忽略测试文件指定过滤条件。在 SKILL.md 的指令中可以要求 AI 在缺少参数时主动询问用户而不是默认扫描整个仓库。这样可以避免误读大目录也节省 token。4.3 预期输出示例一次成功执行后AI 会输出类似下面的报告结构# 项目审查报告./samples/ecommerce 审查时间2025-01-10 14:30 审查文件数42 ## 问题总览 | 严重级别 | 数量 | | --- | --- | | 严重 | 3 | | 中等 | 7 | | 建议 | 5 | ## 严重问题 - 问题用户输入未编码直接拼入 SQL 查询 - 位置samples/ecommerce/order.py:102 - 依据使用 f-string 拼接查询条件存在 SQL 注入风险 - 修复建议改用参数化查询禁止拼接 SQL ## 需人工确认 - 支付回调中的验签逻辑未在本次审查范围内需要补充上下文后再确认。4.4 验证 Skill 是否生效很多人把 Skill 放进目录后发现 AI 没有按照预期执行。验证逻辑应该按下面顺序来确认 Skill 目录被工具扫描到。可以查看工具的配置、日志或运行状态确认触发方式正确。是输入/skill-name还是skill-name确认技能描述能匹配当前对话。技能描述写的是“审查代码”用户却问“写一首诗”AI 可能不会触发确认 SKILL.md 格式没有错误。YAML 元信息如果解析失败技能可能被跳过确认辅助脚本路径正确。建议在技能指令中写明脚本相对路径。4.5 参数调优扫描范围、过滤规则和上下文消耗在实际项目中审查一个大型仓库很容易耗尽上下文。可以给 Skill 增加几个可调参数参数作用建议值max_depth控制目录扫描深度2 到 4 层exclude_dirs排除会产生噪音的目录node_modules、dist、.gitfile_extensions限制文件类型按项目语言设置max_files最大文件数量100 到 300超过则询问用户这些参数可以在 SKILL.md 指令里定义也可以放在配置文件中。关键是让 AI 在超限时停下来询问用户而不是硬着头皮继续扫描。5. Skill 与 MCP、Agent 的区别和配合方式5.1 为什么总有人把 Skill 和 MCP 混淆在相关热词中经常能看到“agent skill 和 mcp 有什么区别”这个问题。原因是这两个概念都出现在 AI Agent 生态里而且都能让 AI 调用外部资源容易混淆。Skill 是一种指令和资源的静态打包解决的是“AI 该怎么做事”的问题。MCPModel Context Protocol是一种开放协议解决的是“AI 如何连接外部工具和数据源”的问题。一个 Skill 可以定义“先读取代码再调用安全扫描工具最后生成报告”但具体怎么连接安全扫描工具可以通过 MCP Server 提供统一接口。简单说Skill 是“流程剧本”MCP 是“工具接口”。它们不在同一条线上而是可以配合使用。5.2 Skill 是“剧本”MCP 是“工具箱”用项目开发的类比来理解Skill 像项目里的流程文档写着“需求评审要经过哪些阶段、由谁检查、输出什么”MCP 像项目里的一组 API让不同系统之间能够安全地交换数据Agent 更像执行者它读取流程文档调用 API完成具体任务。在 GrillReviewer 的例子中Skill 规定了审查步骤和报告格式。如果团队有一个代码搜索工具、一个依赖漏洞扫描服务、一个数据库查询网关这些都可以通过 MCP Server 暴露给 Agent。Skill 告诉 Agent 什么时候去调用这些服务MCP 则负责把调用请求转换成服务端能理解的消息格式。5.3 实际项目中如何配合假设要做一个更强大的代码审查系统可以把 GrillReviewer 拆成两层Skill 层定义审查流程、规则、报告模板MCP Server 层提供读取 Git 变更、查询漏洞库、搜索代码片段、调用测试平台等能力。SKILL.md 中可以用类似下面的方式描述工具调用步骤 3如果 MCP 服务已连接调用 get_git_changes 获取本次变更文件列表然后只审查变更范围内的代码。 步骤 4调用 check_dependency_vulnerabilities 检查依赖锁文件中的组件版本判断是否存在已知风险。这样做的好处是同一个 Skill 在不同环境中可以连接不同的 MCP Server。本地开发时连接本地 Git 服务CI 中连接安全扫描服务流程本身不用重写。5.4 选型建议到底只写 Skill还是连接 MCP取决于任务复杂度。维度SkillSkill MCP成本低只需写 prompt 和少量脚本较高需要开发和维护服务端适用场景固定流程、本地文件、单机任务需要实时数据、跨系统调用、多工具协作维护难度简单需要考虑协议、鉴权、服务稳定性推荐人群个人开发者、小团队平台团队、企业级 AI 工具链对大多数个人项目来说先写 Skill 就够了。等到确实需要 AI 实时查询数据库、调用 CI 系统、连接公司内部文档时再引入 MCP 层避免一开始就把架构做复杂。6. 常见问题排查Skill 在开发和安装过程中会遇到不少问题。下面按从现象到原因到解决方式的顺序整理。6.1 Skill 没有被触发现象输入/grill-reviewer ./src后AI 仍然像普通对话一样回答没有执行技能流程。可能原因技能目录没被扫描到技能描述与用户输入不匹配触发符号错误SKILL.md 元信息解析失败。检查方式确认目录位置是否正确查看工具是否加载了该技能尝试在技能描述中增加关键词比如“审查、评审、问题、方案分析”。解决方式重新复制技能目录确认 SKILL.md 编码为 UTF-8检查 YAML 格式。如果工具支持在配置中手动添加技能目录。6.2 中文或特殊字符导致乱码现象AI 读取规则文件或报告时出现乱码或者脚本输出中文路径显示异常。可能原因文件编码不是 UTF-8终端或工具默认编码不匹配Python 脚本输出时未指定编码。检查方式用编辑器打开文件确认编码命令行执行file SKILL.md查看编码。解决方式所有 skill 文件统一使用 UTF-8 编码Python 脚本可以通过环境变量PYTHONUTF81或代码中指定输出编码。注意不要依赖记事本默认编码尽量使用支持显示编码格式的编辑器。6.3 辅助脚本权限不足或路径错误现象AI 说“无法运行 collect_files.py”或提示没有权限、文件不存在。可能原因脚本没有执行权限指令中的相对路径不是从 Skill 根目录解析的当前系统缺少 Python 环境。检查方式ls -l scripts/collect_files.py python3 scripts/collect_files.py ./src解决方式给脚本加上执行权限或者改用python3 scripts/collect_files.py的方式调用。在 SKILL.md 的指令中尽量使用从技能根目录开始的相对路径并明确调用方式。6.4 上下文过长审查后报告被截断现象AI 扫描了很多文件还没开始输出完整报告上下文窗口就满了。可能原因扫描范围过大规则文件太长AI 在审查过程中把大文件原文读入上下文。解决方式增加 max_files 限制让 AI 优先读摘要和关键文件要求 AI 分段输出报告先输出问总览再逐项输出明细在规则中明确“不要一次性读取超过 10 个大文件”。6.5 Skill 目录命名和格式不兼容现象不同工具之间复制 Skill 后失效。可能原因每个工具对 Skill 目录、SKILL.md 格式和元信息字段的要求不同。解决方式不要把某种工具的特殊配置当成通用规则。迁移到新工具时先阅读该工具的 skill 或自定义指令文档把元信息字段和目录结构调整到兼容格式。6.6 报告内容空泛、没有证据现象AI 输出了很多“建议优化代码质量”“注意安全性”之类的大话但没有任何具体位置。可能原因SKILL.md 中没有强制要求带文件路径和函数名规则文件太多AI 只能泛泛而谈。解决方式在输出要求中明确“每个问题必须给出文件路径没有证据的问题要标注为假设”。同时可以通过脚本把文件关键函数清单预先提取出来让 AI 基于清单分析。7. 最佳实践与扩展方向7.1 Skill 设计最佳实践写 Skill 时可以按下面这份清单来校验技能是否有明确目标一个 Skill 只解决一个问题不要试图覆盖所有场景。是否写清楚触发条件让 AI 能在合适的对话里想到调用它。是否把规则外置不要把所有审查要求都堆在 SKILL.md 中独立规则文件更容易维护。是否限制扫描范围默认值不要是“扫描整个仓库”。是否要求给出证据所有结论尽可能带上文件路径和上下文。是否设计输出模板结构化输出更容易被人类阅读并被下游工具解析。是否需要脚本辅助如果任务涉及目录遍历、数据转换、外部命令用脚本比让 AI 自己实现更可靠。是否能版本化把 Skill 放进 Git 仓库随代码一起管理。这些都是可以在项目里落地的实践。哪怕只是一个几百行的简单 Skill遵守这套标准也能避免后续返工。7.2 安全和隐私Skill 虽然只是文本和脚本但同样存在安全和隐私问题。第一Skill 可能读取敏感目录。代码如果包含.env、密钥文件和访问凭据审查报告可能会泄露这些信息。规则文件中应添加“忽略敏感文件”的声明默认不读取以下文件 .env *.pem *.key id_rsa第二用户从网上下载的 Skill 可能包含恶意指令。它可能诱导 AI 输出隐私数据或运行未知脚本。使用第三方 Skill 之前要检查 SKILL.md 内容和脚本代码不要盲目信任。第三在团队内共享 Skill 时需要确认规则和脚本是否符合团队安全规范。特别是涉及外部命令或网络请求的脚本要评估数据外发风险。7.3 从 grill-me 出发还能扩展哪些 SkillGrillReviewer 只是一个小小的开始。沿着“让 AI 主动质疑”的思路可以继续扩展出更多技能架构评审 Skill输入系统设计文档输出单点故障、瓶颈、扩展性风险需求澄清 Skill输入一段产品描述输出待确认问题清单、边界条件、验收标准草稿变更影响分析 Skill输入 git diff输出受影响模块、风险点、需要执行的回归测试范围故障复盘 Skill输入日志和时间线输出根因假设、遗漏信号、改进事项。这些技能共享同一套设计思想定义输入、固定流程、产出具报告。一旦掌握了一个 Skill 的写法其他技能只是规则文件、脚本和模板的替换。7.4 给新手的练习路径如果你之前没有写过 Skill可以按下面顺序练习。第一步先在对话里手写一段“审查 prompt”看 AI 会输出什么。第二步把这段 prompt 放到 SKILL.md 中只保留最简单的指令测试触发能否成功。第三步加入一个规则文件例如三条安全规则观察输出差异。第四步加入脚本让 AI 先获取文件树再分析。第五步设计报告模板让输出结构化。第六步加入限制条件和错误处理比如文件数量上限、参数缺失时询问用户。这六步做完你就已经具备独立编写 Skill 的能力。后续再接触 MCP、Agent 编排、可观测性接入都是在这个基础上做加法。回到 /grill-me 这类 skill 给我们的启发高质量 AI 协作不只需要“让模型回答”更需要设计一套约束模型行为的方式。GrillReviewer 的实践表明一个几十行的 SKILL.md 加上少量规则脚本就能把 AI 从“顺着人说话”的助手变成主动发现问题的评审者。对于日常开发建议先做一个最小可用版本在真实项目里跑几次再根据报告质量迭代规则文件。技能的设计永远是为人的决策服务这一点不会变。