企业官网建设流程全解析

前段时间在整理个人 AI 工作流时，我发现一个很有意思的现象：同样一份需求文档，直接让 AI 评审，它往往会给出“整体不错、略有风险”这类礼貌性结论；但换一种方式，让它以挑剔面试官的口吻连续追问，很多隐藏问题立刻暴露出来。这个思路来自社区里流行的一种交互方式——/grill-me，简单说就是让 AI 反复“拷问”你的方案、代码或想法，直到漏洞被翻出来为止。更关键的是，这种能力可以被固化成独立的 skill，让 Claude Code、Codex、Cursor 等 agent 工具随时加载，而不是每次手写一长串提示词。

本文就围绕“如何写一个 /grill-me 风格的 skill”展开，从前置概念、目录结构、SKILL.md 编写、安装调用到进阶设计完整拆解。无论你是刚接触 agent skill 的新手，还是想沉淀团队内部规范的老手，都可以按本文思路落地一个自己的质询型 skill。

1. 背景：为什么需要一个“拷问式”的 skill

先聊一个常见场景。你负责一个后端模块的改造，自认为方案已经完整：缓存策略、降级开关、分表键、日志埋点都考虑到了。把方案发给 AI 助手做 code review，结果它只是重复了你的设计，最后补一句“注意做好监控和回滚”。这份 review 不能说错，但没有产生增量价值。

问题出在哪？AI 的默认输出风格偏向“配合”，它倾向于顺着用户的表达继续，而不是主动挑战。当你用开放式提问，比如“这个方案有什么问题”，它很难做出足够尖锐的分析。但如果换一种交互方式，AI 被设定成“必须连续追问、逐条质疑、不允许带过任何假设”，结论会完全不同。

/grill-me正是这种交互方式的代表。它模拟的是一群不同背景的评审专家围着你提问：有人关注数据一致性，有人关心异常恢复，有人在意接口兼容性，有人专门找边界条件。一轮轮追问之后，AI 再把所有质询点和你的回应汇总成一份“压力测试报告”。这种机制非常适合以下场景：

• 代码 review 前自查：先让 AI 找你方案里的漏洞，再提交给同事。
• 需求评审：把 PRD 丢给 skill，让它模拟运营、后端、测试、安全等角色反复追问。
• 技术选型论证：写清楚备选方案，让 skill 不断挑战你的选择标准。
• 面试模拟：把简历和岗位要求交给 skill，让它出题并追问。
• 创业想法验证：在写 BP 之前，先让 AI 帮你把商业模式漏洞列出来。

这类能力如果用普通提示词，每次都要复制粘贴一大段角色设定、追问规则、输出格式，很容易漏掉细节，不同会话的表现也不稳定。把它封装成 skill 之后，就能在多个项目中复用，团队成员也能共享同一套质询逻辑。

2. skill 的核心概念与工作原理

2.1 什么是 agent skill

技能（skill）可以通俗地理解成一个“可复用的能力包”。它通常是一个目录，里面有描述文件、示例、参考规范，甚至包含可执行脚本，用来告诉 AI 在什么场景下应该怎么表现。

以 Claude Code 为例，它支持从~/.claude/skills/或项目.claude/skills/目录加载 skill。每个 skill 目录下都有一个SKILL.md，包含 YAML 格式的元信息（name、description）和具体的指令正文。当用户提问触发 description 里描述的场景时，模型会读取对应 SKILL.md 并遵循其中的流程工作。

Codex、Cursor 的机制与此类似，只是目录名称、加载方式存在差异。核心思想一致：把特定领域的专业做法写进 Markdown 文档，让模型在需要时自动参照执行。

2.2 agent skill 与 MCP 的区别

很多刚开始接触的人会把 skill 和 MCP 搞混，这里简单做一个区分：

• MCP（Model Context Protocol）是一种协议，用来让 AI 调用外部工具和数据源，比如查询数据库、调用内部 API、读写文件系统。它解决的是“AI 如何获取外部能力”。
• skill 是写在本地或项目内的一组指令和示例，它不一定要调用外部服务，纯粹靠提示词工程就能定义 AI 的工作方式。它解决的是“AI 如何按照专业流程输出”。

换句话说，MCP 是给 AI 接上“手和眼睛”，skill 是给 AI 戴上“工作手册”。两者可以配合使用：skill 中描述了工作流程，流程里如果需要查数据或调接口，再通过 MCP 工具实现。对于/grill-me这种偏思考类的能力，通常只需要 skill，不需要额外的 MCP 工具。

2.3 /grill-me 的启发：把“质疑”变成可复用流程

/grill-me的核心价值不是“怼人”，而是把一套高质量追问策略沉淀成固定流程。把它固化到 skill 中之后，每次使用都会稳定输出几个环节：

第一轮：澄清方案背景，拆解目标与约束 第二轮：分角色质询，覆盖技术、业务、风险、边界 第三轮：逐个漏洞追问，不允许含糊跳过 第四轮：输出压力测试报告，包含风险等级与改进建议

这个流程听起来简单，但要用自然语言写清楚，让模型每次都能稳定执行，需要在 SKILL.md 里写足够具体的行为约束，而不是只写一句“请质疑我的方案”。下面我们进入实战环节。

3. 环境准备与目录规划

3.1 工具说明

本文的示例以通用 Markdown 格式为主，不绑定某个特定客户端。你可以根据实际情况选择：

• Claude Code：适合已有 Claude 账号、习惯命令行操作的开发者。
• Codex：适合使用 OpenAI 系工具链的开发者。
• Cursor：适合在 IDE 中直接使用 AI 辅助的开发者。
• 其他支持 skill 或 rule 的 agent 工具：思路一致，路径和加载方式按官方文档调整。

由于不同版本的加载路径和规则解析存在差异，这里不写死某个唯一路径。你需要以当前安装版本的官方文档为准，我们只演示核心思路。

3.2 skill 目录结构

一个典型的 skill 目录长这样：

grill-me/ ├── SKILL.md ├── examples/ │ ├── input-plan.md │ └── output-report.md └── scripts/ └── save_report.py

• SKILL.md：核心描述文件，定义触发条件与质询流程。
• examples/：示例输入和输出，帮助模型理解预期效果。
• scripts/：可选辅助脚本，比如把质询记录保存为 Markdown 报告。

如果没有脚本需求，只保留SKILL.md也可以工作，目录越简单越容易维护。

4. 完整实战：制作一个 grill-me 风格 skill

这一节逐步实现一个可以直接使用的 skill。我们的目标很简单：用户提供一份方案、代码或想法，skill 负责以“评审团”模式进行多轮质询，最后输出一份结构化压力测试报告。

4.1 创建目录与 SKILL.md

首先创建目录：

mkdir -p ~/.claude/skills/grill-me/examples

如果你的工具是 Codex，可以换成：

mkdir -p ~/.codex/skills/grill-me/examples

然后创建核心文件SKILL.md：

--- name: grill-me description: 对用户提出的方案、代码、PRD、技术选型或想法进行高强度质询。当用户需要评估、评审、找漏洞、压力测试时使用。触发词包括“grill me”、“帮我挑毛病”、“压力测试这个方案”、“评审一下”、“帮我找漏洞”等。 --- # Grill Me Skill 你是一个由多位专家组成的评审团。你需要对用户提交的材料进行多轮质询，帮助用户发现被忽略的风险、逻辑漏洞和边界问题。 ## 工作流程 ### 第一轮：理解与拆解 先向用户确认以下信息，如果用户已提供足够内容，可以直接开始： 1. 这份材料的核心目标是什么？ 2. 成功标准是什么？ 3. 有哪些显性约束（时间、成本、技术栈、团队资源）？ 4. 需要重点评审的维度是什么（代码、架构、业务逻辑、性能、安全）？ 如果用户没有说明，可以默认按综合方案处理。 ### 第二轮：分角色质询 依次扮演以下角色，每个角色至少提出 3 个问题： - 资深后端工程师：关注数据一致性、事务边界、接口幂等性、异常处理、依赖兼容性。 - 架构师：关注扩展性、模块边界、部署方式、演进路径、过度设计。 - 测试工程师：关注边界条件、异常路径、并发场景、脏数据、回归风险。 - 安全工程师：关注权限校验、输入过滤、敏感信息、依赖漏洞、越权风险。 - 业务/产品负责人：关注需求合理性、用户体验、埋点是否完整、是否解决真实问题。 每个问题要具体，避免“你考虑过安全性吗”这种泛泛而谈，更好的问法是“如果用户通过某个未校验的接口直接修改他人订单，会发生什么”。每一次质询之后，等待用户回答或确认，再继续下一个问题，不要一次性全部输出。 ### 第三轮：深度追问 针对第二轮用户回答中暴露的风险点进行至少 3 轮追加提问。追问规则： - 如果用户说“已经考虑过 X”，继续追问“有没有边界情况会导致 X 失效”。 - 如果用户说“后续再优化”，继续追问“不优化会对当前目标产生什么影响”。 - 如果用户说“团队约定就是这样”，继续追问“这个约定是否有文档，新人如何知道”。 ### 第四轮：输出压力测试报告 当用户说“结束”或“出报告”时，按以下格式输出： ```markdown # 压力测试报告 ## 材料概述 （用 3-5 句话概括原始方案） ## 质询过程摘要 （列出最有价值的 8-10 个问题与结论） ## 发现的问题清单 | 风险等级 | 问题描述 | 影响范围 | 建议动作 | | --- | --- | --- | --- | | 高 | ... | ... | ... | | 中 | ... | ... | ... | | 低 | ... | ... | ... | ## 关键结论 （用 3 个要点总结，避免套话）

行为约束

• 必须保持挑剔、直接、具体的语气，但不要人身攻击。
• 每个问题都要落到具体场景，不要让用户做填空题。
• 禁止在质询阶段就给出解决方案，先聚焦发现问题。
• 如果用户在某一轮回答“不知道”“没想过”，把这个点标记为高风险项并继续追问。

这里把核心逻辑都放在 SKILL.md 里：角色分工、质询节奏、输出格式、行为约束。模型会根据这份说明来“表演”评审团。 ### 4.2 编写示例文件 为了让模型更清楚“输入到输出”的完整形态，建议在 `examples/` 下放两个示例文件。这是很多 skill 工程中容易被忽略的细节。 `examples/input-plan.md`： ```markdown # 用户提交的评审材料示例 ## 方案名称 用户登录模块缓存改造 ## 背景 目前登录态校验每次都查数据库，高峰期数据库压力大，希望通过 Redis 缓存 token 降低数据库 QPS。 ## 设计方案 1. 用户登录成功后生成 token，写入 Redis，TTL 为 2 小时。 2. 网关层统一校验 token，命中缓存则放行，未命中则回源数据库。 3. 用户登出时删除 Redis 中的 token。 ## 期望评审重点 高并发场景下的正确性、缓存一致性、安全隐患。

examples/output-report.md：

# 压力测试报告 ## 材料概述 该方案通过 Redis 缓存登录 token 来降低数据库压力，核心流程包括登录写入、网关校验、登出删除。 ## 质询过程摘要 1. 如果 Redis 集群重启，所有 token 失效，用户是否需要重新登录？ 2. 如果某用户 token 被主动作废，但旧 token 仍在 Redis 中缓存期内，如何感知？ 3. TTL 2 小时期间，用户权限变更，是否允许旧 token 继续访问？ ## 发现的问题清单 | 风险等级 | 问题描述 | 影响范围 | 建议动作 | | --- | --- | --- | --- | | 高 | token 续期逻辑缺失，缓存过期后所有用户强制重新登录 | 全部在线用户 | 设计滑动续期策略 | | 中 | 权限变更无法实时同步到已缓存 token | 权限变更用户 | 增加版本号机制 | | 低 | 登录状态与 Redis 强耦合，Redis 故障时登录校验不可用 | 全局 | 设计降级开关 | ## 关键结论 1. 方案整体可行，但需要补充 token 续期与主动失效机制。 2. 权限变更场景需要引入 token 版本号。 3. Redis 故障时需要有降级路径。

这两个文件本身也是很好的模板，后续实际使用时可以直接参考。

4.3 增加可选脚本：保存对话报告

纯 Markdown 的 skill 已经可以工作，但如果希望每次质询结束后自动保存一份报告到本地，可以用一个小脚本增强体验。下面是一个不依赖任何第三方库的 Python 脚本：

#!/usr/bin/env python3 # 文件路径：grill-me/scripts/save_report.py """ 用法： python save_report.py --title "登录模块评审" --output ./report.md 从 stdin 读取报告内容，也可以直接把报告写入指定文件。 """ import argparse import sys from datetime import datetime from pathlib import Path def main() -> None: parser = argparse.ArgumentParser(description="Save grill-me report to local file") parser.add_argument("--title", required=True, help="Report title") parser.add_argument("--output", default="./report.md", help="Output path") args = parser.parse_args() content = sys.stdin.read() if not content.strip(): print("No report content received, skip saving.") return output_path = Path(args.output) output_path.parent.mkdir(parents=True, exist_ok=True) now = datetime.now().strftime("%Y-%m-%d %H:%M:%S") report = f"# {args.title}\n\n> 生成时间：{now}\n\n{content}\n" output_path.write_text(report, encoding="utf-8") print(f"Report saved to {output_path.resolve()}") if __name__ == "__main__": main()

使用时，可以让模型在生成报告的同时调用该脚本，把最终报告写入本地文件。实际使用方式取决于你的 agent 工具是否支持自定义命令，如果不支持，可以忽略这个脚本，不影响 skill 本身的质询能力。

4.4 安装到 Claude Code

把整个grill-me目录放到 skill 路径后，重新启动 Claude Code。输入：

帮我 grilling 一下这个登录缓存方案，重点看高并发和一致性。

或者直接输入：

/grill-me

Claude Code 会读取SKILL.md中的 description，当它判断当前请求匹配“评审、找漏洞、压力测试”场景时，就会自动遵循质询流程。

也可以使用/skills命令查看当前已加载的 skill 列表，确认grill-me是否被正确识别。

4.5 安装到 Codex

Codex 的 skill 目录通常位于~/.codex/skills/，同样把grill-me目录复制过去：

cp -r grill-me ~/.codex/skills/

然后启动 Codex，输入一段触发描述，例如：

请 grill 一下我这段转账接口实现，关注并发和幂等性。

如果版本支持自动技能发现，它会读取 skill 并按流程执行。如果不支持自动发现，也可以在提示词里直接写明“请参考 grill-me skill 的流程”，让模型主动读取对应文件。

4.6 在 Cursor 中使用

Cursor 的规则机制与 Claude Code 略有不同，它更偏向“项目级规则文件”。你可以把 4.1 节编写的SKILL.md内容复制到项目根目录的.cursor/rules/grill-me.mdc中，也可以写成AGENTS.md让 Cursor 自动读取。

这一步的核心是让规则文件与项目绑定。对于每个人的全局工具，不同客户端加载方式不同，本文不强行给出统一标准，建议以官方文档为准。

4.7 运行与验证

写完之后，建议用一个简单的“测试方案”验证 skill 是否生效，而不是直接把核心项目材料丢进去。比如先让 AI 评审下面这段“改进方案”：

为了提升查询性能，我打算在订单表上直接增加 10 个冗余字段，并在写入时同步更新。

如果 skill 正常加载，AI 应该问你：冗余字段的一致性由谁保证？同步更新失败的补偿机制是什么？这 10 个字段的查询需求是否真的需要冗余？而不是直接回答“这个方案很好”。

如果它只是一本正经地夸你，说明 SKILL.md 没有被正确加载，需要检查目录路径、文件命名或 description 是否触发。

5. 进阶设计：让 skill 适配更多场景

5.1 支持自定义提问风格

不同场景下，质询风格差异很大。评审技术方案需要冷静、直接；模拟用户访谈则需要更温和的探索式提问。可以在 SKILL.md 中增加一个“风格开关”，让用户通过一个变量控制模式。

## 风格配置 如果用户提到“严格模式”，所有质询必须更加简短直接，不允许使用缓冲语。 如果用户提到“温和模式”，每个问题前先确认用户的思路逻辑，再指出可能的盲区。 如果用户提到“角色扮演”，默认使用面试官/天使投资人/安全红队等角色。

这样同一个 skill 能覆盖更多场景，而不需要拆成多个文件。

5.2 输出结构化报告

默认输出表格已经足够。如果希望进 CI/CD 流程，可以让 skill 额外输出 JSON 格式的风险清单，方便后续程序解析。修改 SKILL.md 的输出部分：

当用户要求 JSON 输出时，按以下结构返回： { "issues": [ { "severity": "high", "title": "问题简述", "impact": "影响范围", "suggestion": "改进建议" } ] }

这种设计可以让 skill 从“聊天助手”变成一个可集成的质量检查工具。

5.3 与其他 skill 组合

一个 skill 不必覆盖所有能力。grill-me负责发现问题和输出报告，另一类 skill 可以负责生成修复建议、补充测试用例、或者按规范改写代码。在实际项目中，可以让 agent 先调用grill-me得到风险清单，再调用“代码生成 skill”针对高风险项自动修复。

组合方式不用写得很复杂，关键是让每个 skill 职责单一，描述清晰，方便 agent 在合适的时机自动选择。

6. 常见问题与排查思路

在实际使用 skill 的过程中，最常遇到的问题就是“模型根本不按 skill 来”。下面整理几个典型问题和排查方向：

排查顺序建议为：目录路径 → 文件命名 → description 描述 → 进程是否重启 → 是否有多个同名 skill 优先级冲突。

7. 最佳实践与工程建议

这一节把编写和使用 skill 的经验总结成可执行的规范。

7.1 命名与目录规范

• skill 名称统一使用小写字母和连字符，例如grill-me，避免空格和中文。
• 目录名与 skill 名称保持一致。
• 每个 skill 目录下必须有SKILL.md，这是大多数工具的默认加载入口。
• 不要在一个 skill 中塞入过多主题，保持职责单一。

7.2 描述信息要面向“触发”

description是模型决定是否加载 skill 的关键依据。不要写“评估方案”，而要写“当用户需要评审、找漏洞、压力测试、grill me 时使用”。触发场景越具体，自动命中率越高。

7.3 指令要可验证

一份好的 SKILL.md 不能只写“请专业地提问”，而要写明：

• 具体步骤顺序。
• 每个步骤产出什么。
• 禁止做什么。
• 如何判断用户是否满意。

这样模型在跑完一个流程后，自己和用户都能判断是否“完成了任务”。

7.4 版本管理与共享

建议把 skill 目录纳入 Git 管理，并在 SKILL.md 中加入 version 字段：

name: grill-me version: 0.2.0 description: ...

方便团队协作时追踪改动。如果你在公司内部推广，可以建一个私有仓库统一管理 skill，成员通过拉取代码的方式同步，避免每个人维护一份漂移的规则文档。

7.5 安全与边界

• 不要要求 skill 自动修改生产环境配置。
• 如果 skill 需要调用脚本，务必检查脚本内容，只保留必要的最小操作。
• 对于涉及敏感信息的材料，建议在提交前脱敏，避免把密钥、客户数据直接写入对话。
• 如果 skill 用于代码评审，它给出的是建议，不是最终结论，最终变更仍需要人工确认并经过测试环境验证。

8. 总结与学习路线

本文从/grill-me的交互方式出发，完整演示了一个质询型 skill 的创建过程。你学会了：

• 理解 agent skill 的基本概念，以及它和 MCP 工具的边界。
• 设计一个“评审团”式质询流程，并把流程固化成 SKILL.md。
• 通过示例文件和辅助脚本增强 skill 的稳定性。
• 将 skill 安装到 Claude Code、Codex、Cursor 等工具中。

下一步可以从两个方向继续深入：

第一，把本文的grill-me改造成适合自己团队业务的版本，补充行业特有的风险清单。比如电商项目可以增加“库存超卖”“支付幂等”等专项检查，金融项目可以增加“资金安全”“审计日志”等维度。

第二，研究其他类型的 skill，比如代码规范检查、数据库评审、UI 设计规范等，逐步建立自己的 skill 库。当你积累的技能足够多时，agent 就不再只是问答工具，而更像一个携带团队方法论的数字员工。

如果你在编写或安装过程中遇到了其他问题，也可以对照第 6 节的排查思路逐项检查。无论你最终选择哪种客户端，核心逻辑是一致的：把专家的思考过程写清楚，让模型可复现。