做AI Bot开发的朋友应该都清楚真正决定一个Bot好不好用的不是工作流画得多复杂也不是插件接得多花哨而是它有没有一套定义清晰、边界明确、输出稳定的技能层。在Coze生态里这套东西就叫Skill。Skill说白了就是你给模型注入的专业能力它可以是纯Prompt驱动的单步技能也可以是Prompt配合插件、工作流组合出来的复合能力而这个Skill写得行不行90%取决于Prompt的设计水平。很遗憾绝大部分人搭Bot时根本没有Skill概念只会把需求一股脑塞进系统提示词里结果就是简单任务还行稍微复杂点就开始胡编乱造、输出结构不稳定、参数传错位置最后只能靠加一大堆规则去补救越补越乱。所以这篇内容想把Skill的Prompt撰写这件事彻底讲透从标准模板、参数设计、实操落地到技能包部署一条线走完。适合正在用Coze做Bot开发、想提升Bot稳定性的读者也适合那些从GPTs或其他Agent平台迁移过来、想快速建立Skill工程化习惯的人。1. 先想清楚再动手Skill Prompt的整体设计思路1.1 先搞清楚Coze Skill到底是个什么层很多人会把Skill和Plugin、Workflow混在一起这是第一步就该纠正的概念。Plugin解决的是模型够不到的外部能力比如查天气、读网页、调数据库Workflow解决的是确定性流程编排它要求每步都走固定逻辑而Skill解决的是模型内部能力的定向激活。一个更直白的类比Plugin像是给机器人装上手和脚Workflow像是给它画好动线Skill则像是给它定义职业素养——会做菜的厨师技能、会做报表的财务技能Skill决定了它在什么场景下按什么标准去思考和产出。这意味着Skill的载体必然是一段高度结构化的Prompt它可以引用Plugin也可以不引用。在设计技能包时你要先回答三个问题这个技能负责什么任务任务的输入是什么形态任务的输出长什么样如果没有回答清楚这三件事后续所有的Prompt填写都是打补丁。我见过很多人一上来就打开编辑器写提示词写到一半发现逻辑不通又回头改参数改完参数又发现输出格式不对整个下午都在原地打转。先回答上面三个问题大概率能避开这种内耗。这就像写代码之前先画接口表面看多花了一点时间实际上省掉的返工时间远大于这点投入。1.2 Skill Prompt和普通Prompt的差异工程化是分水岭普通对话Prompt是给人看的目标是让模型理解意图Skill Prompt是给系统用的目标是让模型在不同上下文下稳定执行同一套逻辑。差异具体表现在三个方面。第一参数化。Skill Prompt不写死具体输入而是通过变量占位符接收外部传入值比如总结技能要接收原文翻译技能要接收目标语言这些变量必须有明确的命名规范。第二结构化。Skill Prompt内部要分层角色层、任务层、约束层、输出层层级之间彼此独立每一层只回答一个问题这样模型才不会被庞杂信息带偏。第三容错性。因为Skill会被反复调用它必须能应对空输入、异常输入、边界情况所以需要在Prompt里预留兜底策略比如遇到无法处理的内容时要明确拒绝而不是硬编。这三条差异决定了Skill Prompt的撰写不能凭感觉必须落地到模板上。倒不是说每个Prompt都要一模一样而是骨架要统一、逻辑要闭环具体内容可以根据技能类型替换。举个例子内容审核技能和代码生成技能角色定义差了十万八千里但它们都需要回答我是谁、要做什么、不能做什么、产成什么这四件事骨架完全一致。1.3 模板化的真正价值可复用、可测试、可部署我见过不少开发者自己手写Skill Prompt写的时候很爽但过两个星期再回来看完全看不懂自己当初的设定逻辑。模板化至少解决三个痛点。一个是可复用。一套模板可以快速派生多个技能比如文章摘要技能和合同翻译技能只是角色、任务、输出格式不同骨架完全一样复制粘贴改参数就能用。一个是可测试。模板固定了变量位测试时只要换变量值就能跑回归不会因为Prompt风格差异导致测试结果不可比。还有一个是可部署。Coze的Skill最终会以技能包的形式发布技能包里的Prompt、参数、插件关联都需要按固定目录组织模板化和这个部署模型天然契合。所以这篇文章的主体思路就是先给你一套通用的Skill Prompt模板再手把手拆解每个字段怎么写最后用一套脚本方式把技能包批量生成出来。整条链路打通之后你就不再是写Prompt而是在工程化地生产技能。这一步思维转变借着Coze这类平台的能力哪怕只有一两个Bot的小团队也能做到。2. 四段式模板逐段拆解从角色定义到输出规范2.1 一套能用的Skill Prompt模板长什么样先把骨架摆出来。我常用的通用模板是四段式它适用于大多数任务型技能包括内容生成、信息抽取、数据处理、文本转换、问答决策等。角色定义段你是这个技能的掌控者你的身份是XXX你负责YYY你的专业背景决定了你处理问题时优先考虑ZZZ。任务描述段你的核心任务是完成以下动作第一步……第二步……第三步……。任务目标是……。请注意如果输入缺少关键信息你应该主动向调用方索要而不是擅自假设。入库约束段在处理过程中你必须遵守以下规则1. 禁止……2. 必须……3. 当遇到……情况时直接返回固定错误信息……。所有规则优先级从高到低依次为……输出规范段最终输出必须严格遵循以下格式字段1……字段2……。输出语言为……。如果任务失败输出格式统一调整为……这个模板不是拍脑袋来的每个部分都对应一个真实的工程诉求。角色定义解决的是立场稳定性任务描述解决的是流程可执行性约束段解决的是边界可控性输出规范解决的是结果可解析性。四段合并之后模型能同时回答我是谁、要做什么、不能做什么、产成什么四件事这就是一个稳定技能的最小完备集。提示在Coze中Skill Prompt会作为系统提示词注入因此不要使用帮我请你这类协商式措辞改用你是你必须输出如下这种命令式结构模型对命令式指令的跟随度更高。2.2 角色、任务、约束、输出逐段打磨要点先讲角色段。角色的定义不能太宽泛比如你是文本处理专家这种几乎没作用因为任何语言模型天然就是文本处理专家。好的角色定义要满足三个点有细分领域标签、有任务倾向描述、有工作原则提示。举个例子你做一个会议纪要技能不要写你是会议纪要助手要写你是企业运营团队的项目文档专员你擅长从冗长的会议录音转写稿中提取决策、待办事项和风险点你的工作原则是只依据原文信息不做猜测性补充。这样模型在后续生成时就会自动把信息抽取的优先级放在决策和待办上。再讲任务段。任务段最忌讳写成一个笼统的句子比如把这段文本总结一下模型的执行方差会非常大。正确的做法是把任务拆成步骤用编号写明执行顺序步骤数一般控制在3到8步。步骤之间要有逻辑递进不要并列堆砌。比如会议纪要技能的任务段可以写成第一步识别发言人与时间线第二步提取会议决策事项第三步梳理待办负责人与截止时间第四步将结果按指定模板输出。任务段的表述也要注意动作词多用提取识别生成校准这种可观测动作少用了解理解这种不可观测动词。约束段是很多人的薄弱环节但恰恰是它决定了技能的专业度。约束段要覆盖四类风险禁止性约束不能做什么、强制性约束必须做什么、边界性约束什么情况是任务失败、兜底性约束失败时怎么反馈。每一条约束都应该是一个可验证的布尔条件而不是模糊的感受。比如不要编造原文中不存在的内容这算一条合格约束而尽量保证准确这种就不合格。约束和任务会有重叠但它们的侧重点不同任务描述定义正向主流程约束描述定义负向边界和兜底分支。输出规范段直接决定技能能不能被下游解析。如果技能输出是要给工作流或另一个Skill消费的那就必须用机器可解析的格式比如JSON或严格的表格结构。如果是给人看的也要给出版式要求比如标题使用三级结构每条待办前加方括号等。输出规范里还建议加一条失败统一格式这样在技能出错时下游也能识别。这四段之间不是松散的堆砌它们是互相咬合的。角色段的工作原则要在约束段里得到呼应任务段的步骤要在输出规范段里有所映射。如果角色说了只依据原文信息但输出规范允许补充背景知识那这两段就直接打架了模型会困惑于到底听谁的。2.3 参数设计与变量管理别把值写死在Prompt里写Skill Prompt和写普通Prompt最大的思维转变就是所有可能变化的输入都要参数化。参数设计的核心原则是显式声明、默认值兜底、命名具象、敏感度分级。显式声明指的是在Prompt中明确用占位符标识输入变量我习惯用{{参数名}}这种格式并且每个参数都要在参数表里登记包括参数名、类型、是否必填、默认值、输入示例。命名具象指的是参数名要能自解释比如用article_content而不是text用target_language而不是lang这样后期维护和跨Skill复用都会舒服很多。默认值兜底是一个容易被忽视的点。很多参数在大多数场景下是可选的比如输出语言总结长度上限你必须在参数表里设好默认值并在Prompt的约束段注明当调用方未传入该参数时使用默认值XX。这样做的好处是技能始终有确定的行为不会因为缺参数就随机发挥。敏感度分级针对的是技能部署时的权限问题。如果技能包要给别人使用参数设计时就要区分哪些参数允许调用方自定义哪些参数是内部固定的。比如底层Prompt里的判断逻辑、错误码定义就应该写死在技能包里不要暴露成可配置参数而调用方需要控制的只有入参和少量出参选项。把不可变的东西暴露成可变参数是技能包后期被玩坏的最大原因。我早期做过一个技能把输出语言和错误提示文案都设置成了可配置参数结果被调用方改得千奇百怪最后各环境输出的错误提示都不一样排查起来非常痛苦。从那以后我就养成了一个习惯每加一个参数都要先问自己调用方真的需要碰这个东西吗如果答案是不确定那就默认写死。3. 从模板到技能包完整落地实操与自动化生成3.1 从零到一构建文章摘要技能的六个步骤讲完理论下面用一个完整案例把所有环节串起来。我以文章摘要技能包为例这套流程完全可以复制到你自己的场景。第一步定义能力边界。摘要技能的输入是文章原始文本输出是三句话摘要加三个关键词同时要求摘要长度不超过200字。能力边界想清楚后参数表也就出来了input_text必填String、max_length可选Int默认200、language可选String默认中文。第二步按四段式模板填Prompt。角色定义为资深编辑与信息提炼专家擅长在噪声信息中快速定位核心观点工作原则是不改变原文含义、不添加外部知识。任务描述写成三步先通读全文识别主旨句再筛选支撑论据不超过3个最后组织成摘要并提取关键词。约束段写明不得生成原文没有的观点若原文无效输入长度少于50字直接返回错误码ERR_EMPTY_INPUT摘要必须为自然段不得使用列表。输出规范定义JSON结构{summary: ..., keywords: [..., ...]}。第三步在Coze控制台新建Skill把上面的Prompt填入系统指令面板然后维护参数表。这个动作看似简单但很多人随手就填完了我建议你在提交前做一次干跑验证不接任何插件直接用几个典型输入测试输出看看四段式是否真的被执行了。第四步按需关联插件。摘要技能一般不需要额外插件但如果输入源是URL而不是纯文本就需要加一个网页抓取插件并把插件输出映射到input_text参数上。关联插件的原则是技能只依赖最小必要能力能不加就不加因为每加一个插件就多一个失败点。第五步准备测试用例。至少准备两个正例、一个边界例、一个空输入例、一个异常格式例跑完后把结果和预期对比记录成一份调试日志。第六步生成技能包目录并按规范命名确认manifest和params.json都完整后导入Coze做端到端验证。这六步走完一个技能才真正算落地了。3.2 技能包目录结构与部署配置细节在Coze里一个可部署的Skill包并不是只有一段Prompt它还要携带元信息。我习惯把技能包整理成如下目录结构skill_article_summary/ ├── SKILL.md ├── params.json ├── prompts/ │ ├── main.txt │ └── fallback.txt ├── examples/ │ ├── example_input_1.txt │ └── example_input_2.txt └── manifest.jsonSKILL.md是技能包的说明文档用来描述技能用途、适用场景、输入输出约定prompts/main.txt是主Prompt就是前面写的四段式正文params.json对应参数表声明每个参数的类型、默认值、校验规则examples目录放测试用例这一步非常推荐你养成习惯因为技能升级时没有测试用例就没法做回归manifest.json是部署清单里面声明技能名、版本号、主Prompt路径、参数文件路径、依赖插件列表。当你在Coze中导入技能包时平台会先读manifest确认元信息再把prompts/main.txt注入模型上下文同时在运行时把params.json声明的外部参数映射成Prompt里的占位符。理解这个机制后你就明白为什么参数表必须和Prompt里的{{占位符}}一一对应也明白为什么不能把参数配置文件删掉一旦占位符找不到对应的参数声明技能包导入就会校验失败。注意技能包版本号一定要在每次修改后递增并在manifest里保留changelog字段。我在实际开发中吃过一次亏因为版本号没改线上Bot缓存了旧技能查了半天才发现是新包没生效。3.3 一键批量生成可部署技能包的自动化方案既然模板和参数表都固定了批量生成技能包就成了一个工程问题。这里提供一个轻量级方案用Python写一个模板渲染脚本把Prompt模板文件读进来替换掉变量位再自动生成manifest和params.json最后输出一个标准的技能包目录。原理很简单核心就是两次替换。第一次是模板变量替换把SKILL模板里的{{role}}、{{task}}、{{constraints}}、{{output_spec}}替换为具体的技能定义第二次是参数映射替换把运行时占位符{{input_text}}、{{max_length}}等和params.json做一次交叉校验确保没有未注册的占位符。Python脚本可以用jinja2作为模板引擎也可以直接用字符串Template关键是逻辑要清晰。下面是一个简化示例展示核心骨架import json from pathlib import Path from string import Template def build_skill_pack(cfg: dict) - None: prompt_tpl Template(Path(prompt_template.txt).read_text(encodingutf-8)) main_prompt prompt_tpl.substitute( rolecfg[role], taskcfg[task], constraintscfg[constraints], output_speccfg[output_spec], ) out_dir Path(cfg[name]) (out_dir / prompts).mkdir(parentsTrue, exist_okTrue) (out_dir / prompts / main.txt).write_text(main_prompt, encodingutf-8) (out_dir / params.json).write_text( json.dumps(cfg[params], ensure_asciiFalse, indent2), encodingutf-8 ) (out_dir / manifest.json).write_text( json.dumps({name: cfg[name], version: cfg[version], main_prompt: prompts/main.txt}, ensure_asciiFalse, indent2), encodingutf-8, )整套流程跑通后你就能在一个配置文件里维护几十个技能的差异点然后一条命令批量产出所有技能包。对我来说这是从手艺人模式切换到流水线模式的关键一步。特别是当团队里多人协作维护技能库时只需要让大家各改各的配置区块生成脚本统一处理就避免了合代码时Prompt互相覆盖的尴尬。4. 踩坑记录与排查技巧把Skill从能用调到好用4.1 我在部署Skill时反复踩过的5个坑坑一Prompt过长导致上下文污染。我早期写过一份特别详尽的Skill Prompt洋洋洒洒两千多字看起来面面俱到实际上模型执行时被大量无关细节干扰输出的摘要反而丢掉了重点。后来把Prompt压缩到500字以内只保留角色、任务、约束、输出四段性能立刻稳定了。这里给一个经验值单技能Prompt控制在300到800字之间超过800字就要考虑把一部分逻辑改成工作流。坑二参数名不一致导致注入失败。有一次我在Prompt里写了{{source_text}}但在params.json里注册的参数名是{{text_content}}运行的时候模型完全没有接收到外部传入的文章内容。这个问题表面看是手滑根本原因是缺少自动化校验。从那以后我每次部署前都会跑一遍脚本把Prompt里所有{{占位符}}提取出来和params.json做并集比较多一个少一个都能立刻发现。坑三插件与Skill职责不清晰。我之前做过一个数据整理技能既想让它做数据清洗又想让它顺势调用数据库插件写入结果结果技能本身复杂了插件又多了一个整体调试成本飙升。后来我把清洗和写入拆成两个技能各自只做一件事再用工作流串联稳定性好了很多。职责边界的事越早划清楚成本越低。坑四只测正例不测反例。很多人在测试Skill时只喂几个典型输入看到输出不错就发布。结果技能上线后遇到空输入、超长输入、恶意输入时行为完全不可控。正确做法是每个技能至少准备5个测试用例2个正例、1个边界例、1个空输入例、1个异常格式例并且把这5个用例存进examples目录方便后续回归。坑五版本管理混乱。技能包改了十几版之后目录里堆满了skill_v1、skill_v2_final、skill_v3_真正最终版这种命名几乎没法追溯谁改了哪个参数。建议从一开始就用manifest里的版本号管理每次改动必须更新版本号和changelog目录只保留最新版旧版全部走版本控制系统存档。4.2 快速排查定位问题的四步法如果你发现某个Skill上线后输出不对不要急着改Prompt先按顺序走一遍排查流程。第一步查输入。在Coze的调试记录里确认外部参数是否真的传进来了参数名是否和Prompt里的占位符匹配。很多输出不对其实是输入没到这一步能排除掉至少三成的案例。第二步查Prompt静态结构。把主Prompt完整拉出来检查四段是否齐全约束段是否覆盖了当前失败场景角色段会不会和任务段矛盾。我有一个习惯每次排查都把Prompt里每个{{占位符}}高亮出来人工确认一遍它们的上下文位置很多时候参数其实传对了但占位符被写进了约束段导致模型根本没有把它当作输入变量。第三步做最小复现。构造一个最简单的输入只触发当前失败的路径把Skill的输出和工作流后续节点的预期对齐。最小复现的价值在于它能帮你区分是Skill本身的问题还是工作流串联的问题这两个问题的修法完全不同。第四步回归对比。把当前版本和上一个可用版本的输出放在一起对比通常是某个约束条件或者参数默认值在改动的过程中被误删了。这四步走完90%的Skill问题都能锁定在具体某一层剩下10%属于模型偶发表现重试或者小幅调整Prompt即可。4.3 把Skill Prompt从能用调到好用的进阶思路基础模板能保证技能稳定但离好用还有一段距离我把调优经验总结成四点。第一加入少样本示例。如果输出规范对格式要求高光写JSON结构描述还不够模型偶尔会在字段命名上自由发挥。此时在Prompt末尾附加一个参考示例给一组真实的输入和期望输出模型的格式遵守度会立竿见影。示例要选中等难度的太简单学不到规律太难会挤占上下文。第二设置主动拒绝策略。专业技能必须敢于说不。比如你做的是法律咨询技能遇到非法律问题就应该明确拒绝并引导用户回到正轨而不是硬着头皮回答。在约束段里写好当任务超出能力边界时直接返回固定提示语并将is_out_of_scope字段置为true这种策略能让技能在开放环境中长期保持信誉。第三输出后处理。有些技能的输出需要再走一步机器校验比如解析JSON、校验字段类型、检查枚举值范围。我通常会在技能外层包一层轻量后处理逻辑如果模型输出不合法不是重新跑模型成本高且不稳定而是基于模型部分有效内容做修正或者触发fallback提示。记住模型输出是概率性的后处理才是确定性的兜底。第四控制技能复用粒度。一个技能只解决一类问题不要搞成瑞士军刀。我在项目里见到最典型的问题就是把文本总结和情感分析塞进同一个技能结果模型一会输出摘要一会输出情感标签格式总是打架。拆开之后每个技能都专注复用率高调试也简单。我个人在实际操作中还有一个体会写Skill Prompt不要追求一次性完美先按模板搭一个能用版本跑通之后再看实际表现逐步调优。大部分人在第一步就卡住了因为总想着把所有边界情况都提前想到结果反而迟迟交付不了。先用模板把骨架立起来再用测试用例把血肉填起来这才是技能包从模板到落地的最短路径。