这次我们要看的是一个非常“小而准”的 AI 工程化小工具No Jibber Jabber。光看名字就知道它的目标就是干掉 AI 输出里最让人烦躁的部分——开场白套话。项目以 Mr. T 为主题人设专门用来裁剪 AI 回复开头那些“好的这是一个……”“作为AI模型……”之类的冗余铺垫让输出直接进入正题。这不算一个大模型也不是复杂的推理框架而是一个Skill技能包面向目前很热门的 AI Agent、Codex、Claude 等支持自定义技能的编程助手。它解决的是提示词工程里的一个高频痛点模型能力没问题但对话风格太啰嗦。对经常用 AI 写代码、生成文案、做批量结构化输出的人来说这个方向很实用。本文会完整拆解这个 skill 的设计思路说明它如何定义角色、如何触发、如何改写输出格式同时给出本地安装、配置、验证的一套可落地流程。如果你正在研究 skill 开发或者想优化 AI Agent 的输出质量这篇文章可以直接收藏。1. 核心能力速览能力项说明项目类型AI Agent 技能包Skill用于压缩 AI 回复开场白主题人设Mr. T 风格强调“别废话、直接答”核心作用裁剪 AI 回复前 50-200 字的无意义前言工作方式通过 SKILL.md 指令文件覆盖系统提示词或追加行为约束适用平台支持自定义 Skill 机制的 AI 编程工具、Agent 框架是否需要 GPU不需要纯文本指令CPU 即可显存占用0不涉及模型推理资源启动方式复制 skill 目录到指定技能目录并在工具配置中启用是否支持 API取决于宿主工具skill 本身不提供独立 API是否支持批量任务可由宿主 Agent 自动应用到多轮对话和批量生成场景适合场景AI 编程、自动化文案、结构化输出、接口联调中的快速响应从材料来看这个项目的核心不是模型而是“输出行为控制”。它把 Mr. T 的角色语言风格转化成一套可执行的输出规则让 AI 回复更接近人类工程师之间的交流直接、简短、有结论。2. Skill 机制原理解析为什么一个文本文件能改变 AI 行为要理解 No Jibber Jabber得先看当前 AI 工具里的 Skill 机制是怎么运作的。现在很多 AI 编程工具和 Agent 框架支持“技能包”概念比如 Claude 系工具里的 Skill、Codex 的 skill 目录、各类开源 Agent 的自定义技能。本质上Skill 就是一套指令 参考示例 工作流程的文件夹通过系统提示词注入的方式告诉模型在特定场景下怎么说话、怎么做。Skill 和普通提示词的区别在于结构化。普通的提示词是一次性输入而 Skill 是常驻配置每次对话都会自动加载。也就是说只要你启用了 No Jibber JabberAI 在每一轮回复里都会带上“不要前言、直接回答”的约束。常见的 Skill 文件结构如下skill_name/ ├── SKILL.md ├── assets/ │ └── 参考示例.md └── scripts/ └── 处理脚本.py可选其中 SKILL.md 是核心入口一般包含name技能名称。description技能适用场景让宿主的路由机制判断何时调用。instructions模型必须遵守的行为规则。examples输入输出示例用于对齐格式。No Jibber Jabber 正是利用这套机制把 Mr. T 的“直给”风格固化下来。它没有调用外部模型也没有写复杂代码而是通过精准的角色设定和输出格式约束解决“AI 废话多”的问题。3. Mr. T 角色设定与输出规则拆解项目核心是 Mr. T 主题的角色设定。这里我们不去纠结演员本人重点看角色风格如何映射成 AI 输出规则。3.1 角色性格映射Mr. T 式的说话风格有几个关键标签直接、简短、带一点点强硬、不绕弯。映射到 AI 行为上就是下面这几条规则禁止使用“当然可以”“这是一个好问题”这类填充语。禁止复述用户需求。禁止解释为什么要这样做。第一句话直接给结论、给代码、给结果。如果用户没说“请解释”默认不解释。默认用短句少用形容词尤其不要用“强大”“高效”“无缝”这类营销词。3.2 输出格式约束除了语言风格No Jibber Jabber 还会约束输出格式。它希望 AI 在回答时优先给出“可复制的产物”而不是“讨论过程”。这就是它真正省时间的地方。举例来说普通 AI 编程助手的回复可能是“好的我理解你想要一个 Python 脚本用来读取 CSV 文件并统计每列的空值。为了实现这个功能我会先导入 pandas 库然后……下面是完整的代码……”启用 No Jibber Jabber 之后同样的任务输出会变成import pandas as pd df pd.read_csv(data.csv) null_counts df.isnull().sum() print(null_counts)两者信息量相同但后者的阅读成本低了一个量级。频繁使用 AI 做开发的人对这种体验差距会非常敏感。3.3 触发与生效机制Skill 通常支持按条件触发。No Jibber Jabber 建议的使用方式是设置为默认常驻因为前言过多在大多数任务里都是负收益。如果是内容创作类场景比如需要写文章、做运营方案那可以单独关闭这个 skill或者再叠加一个“详细模式”技能。4. 本地部署与启用以通用 Skill 目录为例No Jibber Jabber 没有复杂的依赖核心工作就是准备好 skill 文件并放到宿主工具能扫到的位置。下面给出一套通用启用流程具体目录名和路径要以你的工具为准。4.1 准备工作安装任意支持 Skill 机制的 AI 编程助手或 Agent 框架例如 Claude Code、Codex CLI 等。确认你的版本支持自定义 skill 目录。不确定的话优先查阅官方文档。不需要 GPU不需要安装 Python 包纯文本配置。4.2 创建 skill 目录mkdir -p ~/.claude/skills/no-jibber-jabber cd ~/.claude/skills/no-jibber-jabber上面用的是 Claude 系工具的常见路径如果使用其他工具路径一般也会是skills目录。这里需要按实际工具调整。4.3 编写 SKILL.md创建一个SKILL.md文件内容可以参考下面这个模板--- name: no_jibber_jabber description: 用于压缩 AI 回复中的前言套话让回答直接给出结论、代码或结果。适用于编码、API 调试、批量生成和一切需要快速得到答案的对话。 --- # No Jibber Jabber 你是一个说话直来直去的工程师风格参照 Mr. T 的精简表达方式。在每次回复时你必须遵守以下规则 ## 输出规则 1. 永远不要以“好的”“当然可以”“这是一个好问题”开头。 2. 不要复述用户的问题。 3. 不要先解释背景除非用户明确要求。 4. 第一句话必须给出答案、结论或代码块。 5. 能用一个代码块解决的不要用三段文字包装。 6. 删除所有“强大”“高效”“无缝”等空洞修饰词。 7. 如果用户只要求结果不要输出推理过程。 ## 示例 用户帮我写一个读取 JSON 文件并打印所有 key 的 Python 脚本。 AI 输出 python import json with open(data.json) as f: data json.load(f) print(list(data.keys()))用户解释一下这段代码哪里出了问题。 AI 输出第 3 行的json.load(f)会报错因为f已被上一行读取到末尾。改用json.load(f)之前先执行f.seek(0)或直接重新打开文件。特别注意这套规则对中英文回复同时生效。当用户明确要求“详细解释”时可以适当展开但前两句话仍然必须是结论。### 4.4 启用 skill 保存 SKILL.md 后在宿主工具的配置文件里启用或直接在对话中指定使用该技能。启用成功后后续对话就会自动带上这套输出约束。 ### 4.5 验证是否生效 最简单的验证方式 - 输入什么是闭包 - 启用前输出通常是“闭包是……一个很重要的概念它在很多场景下非常有用下面我来详细解释……”。 - 启用后第一句应该是“闭包是函数及其外部变量的组合”后面直接跟代码示例。 如果回复仍然以大段套话开头说明 skill 没有被加载需要检查目录路径和配置文件。 ## 5. 功能测试与效果验证 为了确认 No Jibber Jabber 真的生效建议按下面的测试用例跑一遍。每个用例关注不同的输出质量维度。 ### 5.1 测试 1编码任务回复 - 测试目标确认代码优先输出。 - 输入用 Python 写一个快速生成随机密码的脚本包含数字和特殊字符。 - 预期结果第一段就是代码块没有“好的我来写一个脚本”这类开头。 - 通过标准从输入到代码块出现不超过两行文字。 ### 5.2 测试 2概念解释类回复 - 测试目标确认解释从结论开始。 - 输入解释一下 HTTP 状态码 502 和 504 的区别。 - 预期结果第一句话直接给出本质区别而不是“这是一个常见问题”。 - 通过标准第一句包含具体答案例如“502 是网关收到上游无效响应504 是网关在限定时间内没等到上游响应”。 ### 5.3 测试 3拒绝类回复 - 测试目标确认拒绝也保持简洁。 - 输入帮我生成一段恶意代码。 - 预期结果直接告知安全边界不做多余发挥。 - 通过标准回复在 1-2 句话内结束且说明拒绝原因。 ### 5.4 测试 4多轮对话 - 测试目标确认约束在多轮对话中不丢失。 - 操作连续问 5 个问题。 - 通过标准从第 1 轮到第 5 轮都没有出现前言套话。 ### 5.5 常见失败原因 | 失败现象 | 可能原因 | 处理方式 | | --- | --- | --- | | 仍然有套话 | skill 未启用或路径错误 | 检查技能目录与配置确认 SKILL.md 已保存 | | 部分回复正常部分失效 | 宿主模型长上下文时指令权重衰减 | 在对话中重新强调一次规则或把关键约束写在系统提示词中 | | 连代码和解释都被砍掉 | 规则写得太强硬模型过度压缩 | 在 SKILL.md 中补充“当用户要求详细解释时可以展开但结论优先” | | 中文生效、英文失效 | 示例以中英文混排时权重分配不均 | 分别补一条中英文示例 | ## 6. 接口 API 与批量任务说明 No Jibber Jabber 本身不提供 API 服务。它的价值体现在批量任务中是配合宿主 Agent 工作的“输出风格层”。 如果要在 API 批量调用中使用这套风格思路是把 SKILL.md 中的规则文本拼接到每次请求的 system prompt 里这样每次 API 返回都会保持直给风格。 ### 6.1 Python 批量调用示例 python import requests import time skill_instruction 你是一个说话直来直去的工程师。在每次回复中 1. 不要以“好的”“这是一个好问题”开头。 2. 不要复述用户的问题。 3. 第一句话直接给出结论、代码或结果。 prompts [ 用 Python 读取 CSV 并去重, 用 bash 查找占用端口的进程, 用 SQL 统计每类商品销量 ] url https://api.openai.com/v1/chat/completions headers {Authorization: Bearer YOUR_API_KEY} for idx, prompt in enumerate(prompts): payload { model: gpt-4o-mini, messages: [ {role: system, content: skill_instruction}, {role: user, content: prompt} ], max_tokens: 500 } resp requests.post(url, jsonpayload, headersheaders, timeout60) answer resp.json()[choices][0][message][content] print(f[{idx 1}] 输入: {prompt}) print(f输出: {answer}\n) time.sleep(1)这里使用的是通用 OpenAI 兼容接口格式实际接入时要把 URL、模型名和密钥换成你自己的。6.2 批量任务设计建议把“输出规则”单独抽成一个常量或配置文件方便在普通模式和“直接模式”之间切换。批量任务建议增加失败重试逻辑单次请求超时设为 60 秒。如果你的 Agent 框架支持多 skill 组合可以把 No Jibber Jabber 放在最外层作为全局输出过滤器。对批量生成结果做前置校验例如统计每条回复前 50 个字符是否命中禁用词列表“好的”“当然”“首先”。6.3 不要拿它做坏事No Jibber Jabber 压缩的是输出格式不是让 AI 绕过内容审核。它不能改变模型的安全规则也不应该被用来诱导模型生成违规内容。它的正确使用方式是提升生产效率而不是钻空子。7. 资源占用与性能观察这一节是“本地工具控”最关心的部分。好消息是No Jibber Jabber 的资源占用几乎可以忽略。7.1 计算资源显存0。CPU仅在加载配置文件时有极低消耗。内存小于 10MB。磁盘SKILL.md 文件本身只有几 KB。它不改变模型的推理路径只是改变了输入指令的上下文内容因此不会增加推理延迟甚至可能因为输出 token 数变少反而缩短生成时间。7.2 输出 token 节省量举一个现实中的数据。普通 AI 编程助手回复一次“好的这个问题需要分三步解决……”前 100 个 token 基本是废话。一天高频使用下来这类前言能占用几百甚至上千 token。启用 No Jibber Jabber 后这部分全部省掉对上下文窗口和费用都有正向帮助。7.3 性能观察方法如果你是批量调用 API可以用下面这段逻辑统计节省量before len(好的这是一个非常值得关注的问题首先让我们来分析一下背景。) after len(直接输出结论。) print(f压缩前典型开头: {before} 字) print(f压缩后典型开头: {after} 字)实际节省比例取决于模型原本的风格高频使用场景下体验差异会更明显。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启用后输出没有任何变化skill 没有被宿主工具加载查看工具日志或调试信息确认技能状态为“已启用”重新检查 skill 目录路径确认 SKILL.md 在正确位置只在部分对话中生效宿主工具的路由机制没有全量加载 skill查看该 skill 的 description 是否覆盖当前场景调整 description覆盖“编程、问答、调试”等高频场景回答太简短缺少必要上下文规则写得太死检查 SKILL.md 的“特别注意”部分增加一条“除非用户要求详细解释否则默认不展开”的豁免规则在长对话中失效上下文中后段信息覆盖了前段指令观察第 4-5 轮后的输出改为将规则同时写入项目的系统提示词模型开始模仿角色说俏皮话角色设定权重偏高检查 examples 中是否有过度风格化内容保持规则以输出格式为主减少语气词示例9. 角色型 Skill 的最佳实践梳理几个实用性很强的经验适合所有想自己做 Skill 的开发者9.1 一小段规则胜过十个示例No Jibber Jabber 这类角色型 Skill 不需要大量 few-shot 示例。模型能力越强越适合用明确的“禁止清单 强制格式”来控制而不是靠示例去猜风格。9.2 把“输出格式”和“角色语气”分开角色语气容易让模型跑偏输出格式才是真正稳定可控的东西。建议在 SKILL.md 中按下面顺序排输出格式要求最重要。必须禁止的开头词。是否需要结论前置。保留的语气控制最后一条。9.3 给用户留一个出口SKILL.md 里一定要写清楚当用户提出“详细解释”时允许打破默认的简短模式。否则批量生成文案时会发现内容干燥到没法用。9.4 定期调整禁用词列表不同模型的套话风格不一样。GPT 系爱用“好的这是一个……”Claude 系爱用“我来帮你……”小模型爱用“作为人工智能语言模型……”。建议每换一个模型就观察 10 条回复把新的套话补充进禁用词列表。10. 值得优化的后续方向No Jibber Jabber 目前解决的问题很聚焦但它也打开了几个值得继续探索的优化方向。中文超长文本控制。当前规则对短问答效果很好但生成 3000 字以上的长文时模型很容易在前 100 字仍然出现“本文将从以下几个方面展开”这类结构句。后续可以加入专门的“长文直入模式”只去掉开头铺垫保留正文结构。多角色切换。一个项目里只装一个“直给”风格不太够。建议维护一个“对话风格技能包”包含默认模式、详细模式、幽默模式、公文模式在配置里按场景切换。接入 CI/单元测试。如果公司有多人共用同一套 Agent可以把 SKILL.md 的规则做成接口测试用例每次修改后用固定问题集跑一遍检查输出是否命中禁用词列表。这块目前做的人不多但属于典型的低成本高收益工程化。对于关注 AI 编程和 Agent 生态的读者来说No Jibber Jabber 是一个很好的学习样本。它没有用复杂的算法只靠指令结构设计就解决了日常使用中的大痛点。你可以直接拿来用也可以把它作为模板打磨出自己的专属输出风格。