企业官网建设流程全解析

如果你最近在关注 Claude Code、Codex、Cursor 这类 Agent 编程工具，大概率会频繁看到同一个词：Skill。

热搜里“skill怎么用”“如何编写skill”“agent skill 和mcp有什么区别”这些词条几乎把 Agent 生态的焦虑写在了脸上——大家手里有了好用的模型，却不知道怎么把自己的工作方法装进去。而grill-me就是这波 Skill 讨论里非常有意思的一个例子。

这个名字直译过来是“拷问我”。它不是帮你写代码，不是帮你读文档，而是让 AI 反过来不停地质疑你的观点、拆解你的方案、攻击你的逻辑漏洞。我第一次看到这个思路时愣了一下：我们习惯了 AI 当“应声虫”，突然有一个 Skill 是专门让 AI 当“反对派”的，这背后其实藏着一个很重要的判断——Agent 时代最有价值的能力，不是让 AI 更顺从，而是让 AI 更会审视。

这篇文章不打算只停留在介绍/grill-me是什么。我会拆解它的工作原理，解释 Agent Skill 和 Prompt、MCP 的本质区别，然后带着你从零写一个受/grill-me启发的 Skill，做完能直接装进 Claude Code、Codex 或 Cursor 里用。读完你不仅能看懂 Skill 是怎么运作的，还能自己造出一个带个人风格的 Skill。

1. 先搞清楚/grill-me到底解决了什么问题

1.1 一个反直觉的现象：用户开始要求 AI “别顺着我”

过去一年，AI 编程助手的核心卖点几乎都是“听你的话”。你说要什么，它就给你什么。你让它改代码，它就改；你让它写方案，它就写。这种“顺从”让 AI 工具的上手门槛变得极低，但也带来一个副作用：AI 的批判能力被默认关掉了。

你带着一个有漏洞的方案去问 AI，它大概率会顺着你的思路往下推，甚至在五层推理之后帮你把漏洞圆回来。表面上看是“理解力强”，实际是因为它没有立场，也没有判断力。

/grill-me这类 Skill 的出现，说明用户的需求正在发生变化：我不需要你认同我，我需要你挑战我。

1.2 grill-me 的工作方式推测

从命名和社区讨论来看，/grill-me的核心逻辑可以概括成三步：

1. 用户抛出一个观点、方案或结论。
2. AI 扮演一个严格的审视者，从不同角度向用户提问。
3. 用户回答后，AI 再根据回答继续追问，直到把逻辑漏洞、隐含假设、数据缺口全部暴露出来。

它本质上是一个“对抗式反馈机制”。和普通问答的区别在于，它不追求“给出正确答案”，而追求“逼你重新思考”。

这个能力放到技术场景里非常实用。比如：

• 你写完一个系统设计方案，想让 AI 帮你找漏洞，而不是帮你润色。
• 你准备在群里发一个技术判断，想让 AI 先帮你把“会被别人质疑的点”列出来。
• 你做了一个技术选型，想让 AI 扮演“反方辩手”，把另一种方案的优点全部摆出来。

这些场景的共同点是：你要的不是效率，是盲区扫描。

1.3 一个明确的判断

/grill-me之所以能火，不是因为它功能多复杂，而是它踩中了一个真实的痛点：大模型时代，AI 的“顺从”正在变成一种信息污染。你问它“这个方案行不行”，它很少说“不行”；你问它“这两个框架哪个好”，它容易给出一个平衡但无用的答案。Skill 的出现，本质上是在给模型装上“人设开关”和“流程开关”。

对开发者来说，真正值得学的不是/grill-me本身，而是它背后的设计思路：把一种抽象的批判能力，拆解成模型能执行的、可重复的流程。这才是 Agent Skill 的核心价值。

2. Agent Skill 是什么：和 Prompt、MCP 的本质区别

要理解 Skill，必须先把它放进 Agent 技术栈里看清楚位置。

2.1 从 Prompt 到 Skill：从“一次性话术”到“可复用流程”

最早的 AI 编程助手，大家用的是 Prompt。你把一段精心设计的话术贴在对话窗口里，让模型按照你的要求来回答。Prompt 的问题在于：

• 每次都要复制粘贴，容易出错。
• 不同场景要维护很多段话术，散落在各处。
• 话术只能影响对话，不能绑定工具、脚本或外部数据。

Skill 做的第一件事，就是把 Prompt 从“对话窗里的临时话术”升级成“文件系统里的正式资产”。一个 Skill 通常是一个目录，里面有一个SKILL.md文件，甚至还可以附带脚本、模板、参考文档。模型在对话时如果能感知到 Skill 的存在，就会自动加载里面的内容来指导行为。

这个变化的意义是结构性的：Prompt 是“你说一次”，Skill 是“你写一次，模型以后每次都照着做”。

2.2 MCP 和 Skill 到底有什么区别

热搜里大部分人的困惑集中在“agent skill 和 mcp有什么区别”。这个问题必须解释清楚，因为它们是两个完全不同的层次。

通俗理解：MCP 解决的是“能力接入”问题，让模型能安全地调用外部工具；Skill 解决的是“行为编排”问题，让模型知道拿到这些能力后应该按什么流程干活。

一个 Skill 内部完全可以通过 MCP 去调用外部工具。Skill 负责“怎么干”，MCP 负责“用什么干”。两者不冲突，是互补关系。

2.3 Skill 和 Plugin / Tool 的边界

再对比两个容易混淆的概念：

• Plugin / Tool：通常指一个具体的、可被模型调用的函数或 API，比如“搜索网页”“执行 Python 代码”“读取文件”。
• Skill：是一个完整的工作流，它可能包含多个步骤，每一步可以决定是否调用某个 Tool，也可以不使用任何 Tool 纯靠指令完成。

换句话说，Tool 是 Skill 流程中的一个环节，Skill 是包含多个环节的“行动剧本”。

2.4 为什么 Skill 是 Agent 时代的“个人方法论容器”

Skill 最有吸引力的地方在于，它把“一个人的工作方式”从脑子里搬到了文件里。一个资深工程师写代码时，天然会先看需求边界、再设计接口、再写实现、再补测试、最后自查。这套流程以前只能靠人肉记忆，现在可以写成一个 Skill，让 AI 在每次任务中自动执行。

这样带来的好处：

• 可复用：一次写好，处处使用。
• 可分享：团队里一个人写好了，其他人可以直接安装。
• 可版本化：Skill 就是普通文件，可以放进 Git 里管理。
• 可测试：用固定输入验证输出，质量可控。

/grill-me之所以能在社区扩散，就是因为它被封装成了 Skill 的形态，别人可以安装、修改、再创作。如果它只是一段聊天窗口里的 Prompt，流传度和可演进性会差很多。

3. 受/grill-me启发，设计一个自己的 Skill

理解了 Skill 的本质后，我们开始动手。这一节先讲设计思路，下一节给完整代码。

3.1 确定目标：做一个“方案挑战者” Skill

/grill-me解决的是“AI 反驳人类观点”的问题。我不想简单复制它，而是想做一个更贴合技术场景的变体，名字暂定为plan-challenger。

它的使用场景是：

• 你写了一个技术方案、重构计划、排期安排。
• 你把方案贴给 AI。
• 这个 Skill 不会夸你写得好，而是执行一套严格的“找茬流程”，输出一份带风险编号的评审意见。

和/grill-me的不同在于：

• /grill-me是对话式的，它通过连续提问逼你思考。
• plan-challenger是一个完整的审查工作流，它直接输出结构化报告，更接近代码评审里的“反方评论”。

3.2 设计核心流程

把“挑战一个方案”这件事拆解成模型能执行的步骤，我设计了六个阶段：

1. 理解目标：先概括方案要解决的问题，确认没有理解偏。
2. 识别假设：列出方案依赖的所有隐含假设，并标记哪些是未经证实的。
3. 攻击最大风险：找出如果出错会让整个方案失败的最关键风险。
4. 忽视的选项：指出方案没有考虑的替代路径。
5. 改进建议：针对每个风险给出具体改进方向。
6. 输出报告：按固定格式输出。

这个流程表面上是六个步骤，但关键设计在于顺序：先理解、再识别、再攻击、再补充、再改进。如果一上来就让 AI“找漏洞”，它容易为了找而找，输出一堆泛泛的“可能存在问题”。按顺序走，模型的输出质量明显更稳。

3.3 给 Skill 加一个辅助脚本

Skill 不一定只能靠提示词，它也可以带脚本。plan-challenger会附带一个 Python 脚本checklist.py，用来对方案文本做一些简单检查，比如：

• 是否包含明确的验收标准。
• 是否提到回滚方案。
• 是否注明依赖的假设。

脚本的检查结果会作为报告的一部分输出。这样做的好处是让 Skill 的产出不完全依赖模型发挥，而是有了一些确定性检查。

当然，脚本只是辅助。模型的推理仍然是核心。

4. 完整代码实现：目录结构、SKILL.md 与辅助脚本

下面进入实操。本文的示例以 Claude Code 的 Skill 目录结构为例，原因是它最通用。Codex 和 Cursor 的安装路径会在第 5 节说明。

4.1 创建目录结构

# 在 Claude Code 项目中，Skill 放在 .claude/skills 下 mkdir -p .claude/skills/plan-challenger/scripts

如果你不在 Claude Code 项目里，也可以单独建一个目录。但为了方便测试，建议放在一个真实项目的工作区里。

最终的目录结构：

.claude/skills/plan-challenger/ ├── SKILL.md └── scripts/ └── checklist.py

4.2 编写 SKILL.md 主文件

文件路径：

.claude/skills/plan-challenger/SKILL.md

--- name: plan-challenger description: 对用户提供的技术方案、设计文档或排期计划进行严格审查，输出结构化风险报告。当用户粘贴方案并希望得到批判性反馈、找漏洞或评审意见时使用。 --- # Plan Challenger 你是一个严格的方案评审专家。你的任务是挑战用户的方案，而不是讨好用户。 不要为了让用户开心而降低质疑标准。 ## 执行流程 ### 第 1 步：理解方案目标 用 2-3 句话复述方案要解决的核心问题、主要路径和预期结果。 如果方案信息不足，列出需要补充的信息，然后继续后续步骤。 ### 第 2 步：识别隐含假设 列出方案中所有隐含假设，包括但不限于： - 对用户需求的假设 - 对技术环境的假设 - 对数据质量的假设 - 对协作方行为的假设 对每个假设，标注：`已证实`、`未证实`、`存疑`。 ### 第 3 步：攻击最大风险 找到那个“一旦出错，整个方案就会失败”的风险点。 要求： - 只选 1 个最关键风险，不要平均用力。 - 说明为什么它是致命风险，而不只是小问题。 - 给出这个风险发生的概率判断依据。 ### 第 4 步：列出被忽视的选项 思考方案中可能被忽视的替代路径，重点检查： - 是否可以直接购买现成方案而不是自研。 - 是否可以用更简单的架构替代。 - 是否可以直接复用已有系统。 - 是否应该先做一个更小的实验再决定。 ### 第 5 步：给出改进建议 对第 2、3、4 步发现的问题，分别给出具体建议。 建议必须满足： - 可执行，不能只说“需要加强”。 - 注明优先级：`必须`、`应当`、`可以`。 - 如果可能，给出代码级别、配置级别或流程级别的改动方向。 ### 第 6 步：输出结构化报告 按以下格式输出最终报告： ```markdown # 方案挑战报告 ## 一、方案目标复述 （此处写方案目标复述） ## 二、风险清单 | 风险编号 | 风险描述 | 严重程度 | 发生概率 | 优先级 | | --- | --- | --- | --- | --- | ## 三、致命风险分析 （此处写最致命风险的详细分析） ## 四、被忽视的选项 （此处写被忽视的替代路径） ## 五、改进建议 | 建议编号 | 关联问题 | 建议内容 | 优先级 | | --- | --- | --- | --- | ## 六、最终判断 用一句话回答：这个方案在当前信息下，是否值得继续推进？ 答案三选一：`值得推进`、`需要修改后推进`、`不建议推进`。

注意

1. 如果用户没有粘贴完整方案，请先引导用户提供方案，而不是自己编造。
2. 所有质疑必须基于方案文本，不能凭空猜测。
3. 当用户要求你“委婉一点”时，仍然要保持严格，但可以调整表达语气。
4. 输出报告时不要省略风险编号。

### 4.3 编写辅助检查脚本 文件路径： ```text .claude/skills/plan-challenger/scripts/checklist.py

#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ plan-challenger 辅助检查脚本 对方案文本执行基础可靠性检查，输出结构性结论。 """ import re import sys def check_plan(plan_text: str) -> dict: checks = {} # 检查是否包含验收标准 has_acceptance = bool( re.search(r"验收标准|完成标准|Definition of Done|done标准", plan_text) ) checks["验收标准"] = "通过" if has_acceptance else "未提及" # 检查是否包含回滚方案 has_rollback = bool( re.search(r"回滚|rollback|恢复方案|还原", plan_text) ) checks["回滚方案"] = "通过" if has_rollback else "未提及" # 检查是否包含明确的依赖假设 has_assumptions = bool( re.search(r"假设|依赖|prerequisite|前提", plan_text) ) checks["依赖假设"] = "通过" if has_assumptions else "未提及" # 检查是否包含时间节点 has_deadline = bool( re.search(r"时间节点|里程碑|milestone|排期|DDL", plan_text) ) checks["时间节点"] = "通过" if has_deadline else "未提及" # 检查是否包含风险说明 has_risk = bool( re.search(r"风险|risk|不确定性|可能失败", plan_text) ) checks["风险说明"] = "通过" if has_risk else "未提及" return checks def main() -> None: # 支持从文件读取方案文本 if len(sys.argv) > 1: file_path = sys.argv[1] with open(file_path, "r", encoding="utf-8") as f: plan_text = f.read() else: # 否则从标准输入读取 plan_text = sys.stdin.read() results = check_plan(plan_text) print("=== Plan Checklist 检查结果 ===") print(f"{'检查项':<12}{'结果':<8}") print("-" * 30) for item, status in results.items(): print(f"{item:<12}{status:<8}") print("-" * 30) failed_items = [k for k, v in results.items() if v != "通过"] if failed_items: print(f"待关注项：{', '.join(failed_items)}") print("建议：在方案中补充上述缺失内容，并重新提交审查。") else: print("基础检查全部通过。") sys.exit(0) if __name__ == "__main__": main()

4.4 脚本关键逻辑解释

脚本做的事情很简单：用正则表达式检查方案文本中是否包含几个关键要素。

这么设计的原因是，模型对“结构完整性”的判断有时会过于宽松，比如方案里只写了“回滚”两个字，模型可能会认为你已经考虑了回滚。脚本的检查更机械，它只关注“有没有出现这个词”，不判断“这个词用得好不好”。

这个设计体现了 Skill 的一个重要实践：确定性检查交给脚本，开放性判断交给模型。两者结合，比纯靠模型发挥更可靠。

4.5 运行与验证

单独测试脚本：

# 给脚本传一个测试文件 python3 .claude/skills/plan-challenger/scripts/checklist.py plan.txt

也可以从管道输入：

cat plan.txt | python3 .claude/skills/plan-challenger/scripts/checklist.py

预期输出示例：

=== Plan Checklist 检查结果 === 检查项 结果 ------------------------------ 验收标准 未提及 回滚方案 未提及 依赖假设 通过 时间节点 通过 风险说明 未提及 ------------------------------ 待关注项：验收标准, 回滚方案, 风险说明 建议：在方案中补充上述缺失内容，并重新提交审查。

5. 安装与接入：Claude Code、Codex、Cursor 通用思路

不同 Agent 工具的 Skill 目录略有区别，但核心逻辑一致：把 Skill 目录放到工具能识别的位置，然后在SKILL.md里写清触发条件。

5.1 Claude Code 中的安装

在项目根目录执行：

mkdir -p .claude/skills cp -r plan-challenger .claude/skills/

重启 Claude Code 后，输入一个方案，模型应当能识别到plan-challenger并自动按流程执行。

触发方式有两种：

• 自动触发：当用户粘贴方案并表达“请评审/请找漏洞/请挑战”的意图时，模型根据description自动决定是否加载。
• 手动触发：在对话中明确要求使用plan-challengerskill。

5.2 Codex 中的安装

Codex 的 Skill 目录通常放在：

~/.codex/skills/

安装命令：

mkdir -p ~/.codex/skills cp -r plan-challenger ~/.codex/skills/

不同版本的 Codex 对 Skill 的支持程度不同，如果你的版本还不支持自动加载，可以手动把SKILL.md内容作为系统指令添加到对话中。以官方文档为准。

5.3 Cursor 中的安装

Cursor 的规则目录通常支持把 Skill 作为规则文件导入。常见路径是项目下的：

.cursor/rules/

可以把SKILL.md复制一份到该目录下，并补充描述信息。注意 Cursor 的规则文件命名和 Claude Code 的 Skill 规格可能不完全一致，需要按 Cursor 的文档调整格式。

5.4 一个通用安装建议

如果你在多个工具之间切换，建议把 Skill 目录放到一个独立的 Git 仓库里统一管理：

mkdir -p ~/my-agent-skills cp -r plan-challenger ~/my-agent-skills/ cd ~/my-agent-skills git init git add . git commit -m "feat: add plan-challenger skill"

这样不管是 Claude Code、Codex，还是以后的工具，都可以通过 git clone 快速安装。

6. 运行效果与验证方式

6.1 准备一份测试方案

创建一个测试文件demo_plan.md：

# 订单系统重构方案 1. 将现有单体订单服务拆分为订单、支付、库存三个微服务。 2. 计划使用 Kafka 作为服务间异步消息中间件。 3. 重构期间保持旧的单体服务继续运行，双写三个月后切换。 4. 团队共 6 人，预计耗时 2 个月。

6.2 在 Claude Code 中运行

向 Claude Code 对话窗口输入：

请使用 plan-challenger skill 审查下面这个重构方案：

然后粘贴demo_plan.md的内容。

预期的SKILL.md执行流程会输出一份方案挑战报告，其中“致命风险分析”可能指向：

• 双写三个月的数据一致性校验方案缺失。
• Kafka 引入后，事务性消息与本地事务的一致性问题没有设计。
• 6 人团队同时维护新旧两套系统的资源分配假设过于乐观。

6.3 如何判断 Skill 生效了

判断标准不是“AI 有没有输出报告”，而是以下几点：

1. 报告是否包含风险编号？如果没有编号，说明它没有按SKILL.md的格式执行。
2. 是否出现了“方案目标复述”这个固定章节？如果有，说明流程被正确触发。
3. 最终判断是否明确给出“值得推进/需要修改后推进/不建议推进”？如果含糊其辞，说明流程被 AI 自行简化了。
4. 脚本检查结果有没有被纳入输出？虽然模型不一定会主动调用脚本，但你可以手动要求它执行脚本并整合结果。

如果以上任意一点不满足，首先检查SKILL.md的description是否写得太模糊，导致模型没有识别到触发条件。

6.4 脚本与模型的配合验证

单独运行脚本：

python3 .claude/skills/plan-challenger/scripts/checklist.py demo_plan.md

预期能看到“验收标准”“回滚方案”“风险说明”未通过。这个结果和模型输出的报告可以互相印证。

7. 常见问题与排查方法

8. 最佳实践与工程建议

8.1 Skill 的命名规范与目录组织

Skill 的命名推荐使用kebab-case，例如plan-challenger、code-reviewer、sql-optimizer。不要使用中文名或带空格的目录名，因为工具解析时可能出错。

每个 Skill 目录内部建议统一结构：

skill-name/ ├── SKILL.md ├── scripts/ │ └── helper.py └── templates/ └── output_template.md

把模板和脚本分离，便于维护。

8.2 description 要写“触发条件”，不要写功能列表

这是很多人第一次写 Skill 时最容易踩的坑。description字段的作用是让模型判断“什么时候该用这个 Skill”，而不是“这个 Skill 很厉害”。

错误示例：

description: 这是一个强大的方案审查工具，能帮助你发现风险。

正确示例：

description: 当用户粘贴技术方案、设计文档或排期计划，并希望获得批判性反馈、风险审查或找漏洞时使用。

判断标准很简单：把这个description当作模型识别的信号，如果它描述的是“用户输入什么样的文本时该触发”，就是对的；如果它描述的是“我能做什么”，就太模糊了。

8.3 步骤要原子化，一次只做一件事

在SKILL.md中，步骤设计要遵循“原子化”原则：

• 不要写“全面分析方案的优缺点”，而应该拆成“先列优点，再列风险，再列被忽视的选项”。
• 每一步的输出应该可以被后续步骤引用。
• 如果步骤超过 10 步，建议检查是否有冗余。

原子化的意义在于，模型在长推理中容易丢失目标。步骤越细，模型的输出越稳定。

8.4 把关键决策点写进格式约束

不要只告诉模型“要严格审查”，而要说清“输出报告必须包含风险编号”。这个区别体现在SKILL.md的“注意”部分，也体现在最终的格式模板里。

如果某个输出项对你很重要，比如“必须给出最终判断”，就要在模板中强制出现，并且说明不允许省略。

8.5 先个人使用，再团队推广

Skill 的迭代过程和代码演进很像：

1. 先在自己项目里试用，观察哪些步骤有效、哪些是废话。
2. 根据实际输出反推修改SKILL.md。
3. 稳定后再提交到团队共享仓库。
4. 在团队中运行时，收集反馈并补充典型场景。

不要一上来就做一套“面向所有场景”的大而全 Skill。小步快跑，一个 Skill 只解决一个问题。

8.6 安全与合规边界

编写 Skill 时要注意：

• 不要在 Skill 模板中写入敏感信息，比如数据库密码、内部域名、私有 API Key。
• 如果 Skill 会调用外部脚本，必须在脚本中做输入校验，避免把用户的恶意文本直接拼进系统命令。
• 在公共仓库分享 Skill 前，检查是否泄露了团队内部约定或代码细节。
• 生产环境使用 Skill 自动执行操作前，先在本地环境中验证，并确保有回滚手段。

8.7 怎么把日常操作沉淀成 Skill

一个很实用的问题：怎么把 Cursor 里的操作过程变成一个 Skill？这也是社区里常见的需求。通用步骤是：

1. 把你手工执行的操作流程记录下来，按顺序写成一个 checklist。
2. 把 checklist 转成SKILL.md，把需要用户输入的部分抽象成变量。
3. 设定触发条件：什么情况下该自动执行这个流程。
4. 用一个最小样例测试，调整指令。
5. 完成后再考虑是否添加辅助脚本。

关键在于：你沉淀的不是“操作步骤”，而是“判断规则”。模型不缺执行能力，缺的是“什么情况下做什么决定”的规则。

8.8 Skill 与 MCP 的配合模式

一个成熟的 Agent 工作流，往往是 Skill 和 MCP 配合使用：

• Skill 负责流程编排，定义“先干什么、后干什么”。
• MCP 负责提供能力，比如搜索、查询数据库、执行命令。

如果你的 Skill 需要读取外部数据，建议通过 MCP 暴露工具接口，而不是在 Skill 里直接写死路径。这样 Skill 更通用，MCP 也更可复用。

9. 总结与后续学习方向

这篇文章从一个反直觉的现象开始：现在的用户开始要求 AI “别顺着我”。/grill-me之所以受欢迎，说明“对抗式反馈”已经变成了 Agent 生态里真实存在的需求。而 Skill 这个概念，正是把这种抽象的批判能力变成可复用、可版本化、可传播的文件资产的关键。

随后我们动手写了一个plan-challengerSkill，完整覆盖了目录结构、SKILL.md编写、辅助脚本、安装接入、运行验证和排错路径。这个 Skill 不一定是最完美的，但它演示了 Skill 开发的核心方法论：

• 把抽象能力拆成有序步骤。
• 用格式模板约束模型输出。
• 用脚本做确定性检查。
• 用描述字段设置触发条件。

如果你接下来想继续深入，方向有几个：

1. 试着给plan-challenger接入 MCP 工具，让它能自动读取代码库并检查方案与代码现状是否一致。
2. 把 Skill 提交到 Git 仓库，用版本管理跟踪迭代过程。
3. 写一个针对你自己团队的“周报审查 Skill”或“代码提交信息规范 Skill”，体会“个人方法论容器”这个定位。
4. 研究一下不同工具（Claude Code、Codex、Cursor）的 Skill 加载机制差异，你会发现它们的实现思路各不相同，但核心逻辑都是“文件 + 描述 + 流程指令”。

最后提醒一点：Skill 的价值不在数量，而在质量。与其收集一百个别人的 Skill，不如花一个下午写一个真正贴合自己工作方式的 Skill。从一个小场景开始，让它跑通，再慢慢加步骤、加脚本、加模板。当你把一个重复做了很多遍的工作流程，成功“教”给了 AI，你会明显感受到 Agent 从“玩具”变为“队友”的临界点在哪里。