文献里提到的prompt是啥意思

和大家分享一个单词叫做 prompt 啊，这个单词呢， p m p t 啊， prompt prompt 啊，词性非常多啊，像我们的这个啊，名词词性叫做提示，我说 here is a prompt 啊，这块有个小提示，动词词性呢，就是我们的这个督促敦促啊，让某人快点做什么事情啊，老师经常督促我们要快点写作业啊， 或者是我的妈妈经常督促我，要我快点写作业。 my mom always prompts， me prompts me to do， my homework。 这个呢，就是 prompt 动词词性督促敦促啊！ promp 还有形容词，词性表示的是这个迅速的，敏捷的啊，反应很快的啊，相当于啊，我说这个 he always， he can always give a prompt reply。 他 经常会给一个很迅速的，很敏捷的这种回复啊，这就是 prompt 这个单词啊， 当然了，它的副词性呢，是 promptly， 也是副词词性的，迅速的，敏捷的啊。啊，我说他做他的家庭作业非常迅速啊！ he can promptly do his homework。 他 可以迅速地做完他的家庭作业， 这个就是我们的 prompt。 在 背诵的时候呢， prompt p r o m p t。 也非常好背啊，就是一个闭音节的形式啊。 prompt 是 一个闭音节的单词，只有一个元字母啊，后边都是辅音啊，它闭音节的话，字母 o 就 读 o， 其他辅音不变啊。 prompt 这单词，当我们读出来的时候， prompt prompt p r o m p t。 当我们读出来的那一刻，其实这单词就已经背起来了，这种方式呢，就是我们的音阶音标背单词方式，大家可以啊，小稍微的使用一下，对我们背单词呢会有大有益处啊，在使用的时候呢也是啊，一定要把它放在语境当中， prompt 这单词理解的时候呢才会更好一些。 今天呢就跟大家分享在这啊，那栗子老师的这个，最近这个课程呢，一直在不断的更新，就是我们的这个音标的部分，音标加色拼读，现在目前更新到我们的五十级，五十一级那会持续更新，大家感兴趣的话可以留言啊，来咨询一下，拜拜。

这条视频给大家讲一下 front engineer， 就是 提示词工程 front 到底该怎么写？刚好我最近研究了挺多 ai 提示词大神怎么写 cloud 最佳实践的那个官方文档，包括 gemini 最佳实践官方文档，它们这些顶级大模型公司出了这个教程，今天我一条视频给大家汇总一下。我先说一下这条视频适合什么样的人看。首先你有使用大模型的需求， 就是你至少是一个已经在跟 ai 对 话的人。第二个就是你的需求至少要是有一点点难度的啊，比如说问大模型明天天气怎么样的这种 用户的话也不需要看了啊。我这条视频的核心在于工程化和稳定性，教你把 ai 变成一个保质保量，能完成你工作的固定员工。如果你有以下几种需求的话，那么这个视频对你来说非常好。第一，当你需要批量化且质量稳定的产出， 比如你要写五十篇小红书文案，比如你要写十篇日报周报。第二，当你眼高手低时，你只有矮。第二，但是你没有动手能力，你只知道自己想要一个什么样的结果，但中间这个过程你不会干。 比如说你想写一个 python 脚本，但你不懂 python 语言。比如说你想写一份商业分析报告，但是你不是分析师。第三，就是你的任务太复杂， ai 每次完成你的任务都固头不固定，让 ai 做一件很长，然后逻辑很绕的事情。比如说帮我提取这段视频的文稿，提炼里面的观点，再结合我的痛点产出一篇文章，还要翻译成英文， 就是他中间要做的事情很多，那么你把一串指令丢给 ai， 他 可能会丢掉其中一两步，或者说给你一个很水的答案。第四就是当你对味道很挑剔时，比如说你想让 ai 模仿 macintosh 的 翻译墙，或者 macintosh 的 ppt 样式，你不知道怎么描述清楚的。 ok， 那 么我们正式开始。其实网上很多教程太卷了，一会让你学结构化，一会让你学 markdown 各种语法，但其实随着 cloud 啊 jpg 这种模型它的更新迭代，它本身模型非常牛的时候，其实逻辑没必要那么复杂， 首先是我自己写提示词的步骤和思路。首先第一步呢，就是把你脑子里的东西先倒出来，不管你要做分析也好，写文案也好，还是什么复杂的各种 idea 需求也好，我会先把脑子里的所有的想法，你对这件事情所有的知道的来龙去脉，背景啊，结果， 过程要怎么样，你想达成什么样的目标，一股脑的告诉他，用大白话也好，穷尽你能写出所有的对这件事情的描述，甚至说你在网上看到几篇风格很不错的文章，全部丢给 ai。 现在 ai 的 上下文很长，你完全不用担心输入框限制了他。到完之后你跟他说这样一段 prank， 我是 这个领域的小白，但我想要达到专家级的效果。 这些是我的原始想法和参考素材，请你先不要生成内容，先消化这些信息，告诉我你理解了没有，让 ai 去读你的心，去读你的想法。 当你把这些素材投喂给他的时候，你再反过来问他，基于你刚刚学到的这些素材，如果我要完成这个任务，你需要我补充哪些背景、哪些信息，或者利用你自身的知识，帮我把这些大白话翻译成结构清晰、逻辑严密的 system prompt。 这时候你会发现 ai 自己写出来的提示词 里面充满了专业的术语、行话和深层逻辑。这是你自己在家闭门造车，手搓 prompt 手搓不出来的。让 ai 自己给自己写 prompt。 好， 我们到了第三步，拿到了 ai 自己写好的 system prompt 或者提示词之后，不要直接用， 我们先彩排再开机。第三阶段，我会对他说，基于你刚刚这个 prompt， 请你立刻生成三组用户输入到模型输出的模拟案例给我看，检查一下，这时候 ai 只是在模仿你的字面意思，还是说已经读懂了你的神韵？ 如果你看案例的时候你觉得不对劲，你不需要去改那一大串复杂的 system pond， 直接用人话反馈给他。比如说第二个案例，逻辑太生硬了，没有人味，像 ai 写的，我想要那种犀利中带点幽默的，请你调整一下 pond， 直到它生成的案例完全符合你自己的审美，这个 system pond 才算定稿。 以上是我写 point 一个基本的流程，然后下面我再补充一下我从 gemini cloud 的 最佳实践手册里面学到的几个调优的原则。第一个就是别说客套话，直接说需求。如果你对模型的要求很高，千万不要丢给他模糊的指令，一定要给他明确目标。 比如说你扔给他一段图片，说写个分析，那肯定不如说创建一个包含交互功能的分析仪表盘，越全越好。第二点就是举例子比讲道理有用。这个技巧叫做少量样本提示，也叫 few shot one shot。 如果你想模仿特定的文风，你在那里描述，不如直接丢个原版的例子给他，你跟他说，就照着这个味写，你的例子越好， 他的产出就越稳。如果说你是那种需要处理复杂任务的用户，比如说先提取啊这个视频的文案，再分析这个视频的文案，再结合我的痛点生成文案，再把这个文案翻译成某某语言。 你的任务里面包含了多个子任务，那你可以试试提示词练。简单来说就是不要贪图一口吃个胖子，把你的大任务拆成好几个小任务， 上一步的输出变成下一步的输入。举个例子，你拆解完任务之后，你先写一个 point a， 是 用于提取药物，然后它输出了 output a， 那 你再写一个 point b， 基于 output a 写大纲，输出 output b， 你 再写一个 point c， 是 基于 output b 扩写成整篇文章。 这个就是牺牲速度换精确度的策略。你可以精准地调控每一个 point， 每一个子任务里面的细节。 这个是一个用来构建稳定 ai 工作流的思路。其实 a 正的思路就跟这个差不多。下一条原则呢，是多模态融合，现在的 prompt 不 再仅限于文字了。呃，图片、视频、音频，一切的模态都是平等的输入， 特别是对于 jimmy 三用户来说啊，他对于长视频的理解现在特别到位。还有就是允许不确定性。为了减少 ai 的 幻觉，我们可以明确地授权给 ai 说，你可以说你不知道， 比如说，请基于某某数据分析趋势，如果我给的数据不足以支持输出结论的话，请直说，不要编造，我可以给你补充更详细的数据。 最后一个技巧就是让他先想后说，如果遇到复杂的任务，可以要求 ai 在 输出结果之前先列一个提纲或者一步步推理。你可以直接给一个 point 说，在回答之前，先一步步拆解你的思路， 增加 ai 思考的步骤。这件事情非常重要，它可以大大的减少你 ai 胡说八道的几率。 ok， prompt 怎么写？如果你听到这里，学到这里，你已经很厉害了， 不要再纠结那些复杂的结构。好的 prompt 一定不是写出来的，而是聊出来的，是测出来的。所以说你要做的就是把话说明白，然后给他足够的例子。把你重复性的、繁复的工作丢给 ai， 咱们只需要把控方向，检查它的产出即可。

题，诗词到底是啥？怎么写？我们可以看看伍恩达教授是怎么说的。我把伍恩达教授的这本书用 notebook lm 这个工具生成了一个思维导图，我们来看看伍恩达教授所理解的 prompt 到底是什么。 那么它这本书包含了五个部分，我们今天就只讲核心原则是什么。我们首先我们需要去编辑具体的指令，给到 lm 就是 大模型，我们需要在我们的指令中使用分割符， 然后我们的指令需要结构化去给大模型进行输入。我们还需要去检查我们是否有一些前置或假设条件，并没有包含在我们的请求里。 最好的话我们能给出一些少量本提示，就是例子，大模型就跟人一样，对于未知的事情举几个例子或许明白的更快。那么第二个原则就是我们需要给模型时间思考， 那么就是说我们要去指定完成任务的步骤，第一步要做什么？第三步要做什么？那么我推荐大家在下结论之前找到一个自己的解法， 这样的话就可以有目的性的指挥大模型，给出我们想要的结果。对于后面几个部分，我们可以展开看看，如果大家需要的话可以在后台私信我，我把这个提示词指南发给大家，点个关注就可以了。

只需要粘贴复制，就可以将非推理类大模型的准确率从百分之二十一点三三提高到百分之九十七点三三。这个出自谷歌论文的神奇技巧，简单到不敢相信。这个技巧呢，就是把你的提示词原封不动重复一遍，不用加定语，不用写复杂逻辑，直接 ctrl c 加 ctrl v 就 能让 ai 回答，准确率显著的提升。 谷歌实验中呢，用了七款主流的非推理模型，实测七十组，对比中赢了四十七次，平了二十三次，一次都没输，所有模型效果都有提升，还不赶紧试试吧！我是斌哥，关注我，带你走进学术的 ai 世界！

每天一个 ai 新词汇，今天要学习的是 prompt。 prompt 本质上就像你在日常时间里给他人或自己下达的精准行动指令。比如早上八点你给家人留的便签，八点半出门前帮我把冰箱里的牛奶热两分钟，装到我的白色保温杯里， 温度控制在四十度左右，不烫口。这就是一条优质 prompt， 它明确了时间节点、执行动作细节标准，对方能精准完成你想要的结果。 反之，如果你只写帮我热牛奶，就像一条模糊的 prompt， 没有时间、细节和标准，最终很可能出现热过头、 装错容器、温度不符等偏离预期的情况。日常里，中午十二点给外卖的备注，下午三点给保洁的打扫要求晚上睡前给自己定的次日带万。本质都是 prompt。 你 把需求、边界、预期说的越具体，最终的结果就越贴合你的心意。

大家好，我是 map， 今天用 spring ai， 阿里巴巴 front 杠 yampro 这个模块和大家聊聊怎么把 front 工程化，而不是在代码里到处拼制图串。先说整体的一个结构，这是一个很简单的 spring boot 应用，入口是 front yampro application， 但它监听的端口是 幺零零七。核心的主要有两个控制器，一个是 role control， 另外一个是 staff control。 那 对应的两类典型的场景，一种是角色化的系统体式词和塞文档争前回答的 staff prompt， 那它底层大模型统一是通过 spring ai 的 try to client 进行调用的模型提供方式 decimal， 它 api 器是通过我们的 application 点弯网路里面的 api 器，从环境变量里面去注入的。我们先看 row ctrl， 它对外暴露的是， 呃斜杠，以 apple 斜杠 ai， 然后斜杠 ro 这个接口背后做的事情也很简单，第一步，他把用户传进来的 message 分 成一个 usual message， 也就是这次对话里你问了什么。第二步，他用 system prompt templar 加载 task 下的 这个文件，这个模板文件模板里有类似像 name 和 voice， 就 这个，它里面有 name 和 voice 的 这样的站位符。那系统当代码里边，它是通过一个 map of 把这个名字和说话的风格填进去，生成一条 system 的 一个 message。 那 第三步就是把 user message 和 system message 换进一个 list， 组装成一个 prompt， 交给 track prompt 去进行流式输出。 那你可以把它理解为是一个工程化的角色卡的实现，角色定义是放在 system message 里面，它这边会写，哎，你是一个很有用的 ai 助手， 那这个是第一个呃关于角色的提示词，我们再看 stuff control， 那 stuff control 提供的这个 complete completion 的 这个方法，那这个控制控制器示范的是另一种常见的模式，就是给大模型塞上下文，它的构造函数里面同样是拿到这个呃 track grant， 然后通过 at view， 通过 atb 五注入两个资源，一个是呃多可下面的一个维基百科的一个文档， 我们可以把这个文档当做是一个知识文档，一个是 qa 杠 prompt， 这个可以当做是问答的模板，我们看一下 qa prompt， 它里面很简单，就是有一个上下文， 如果上下文有传的话，它就是记这个上下文，做一个提示词啊，输给大模型，如果上下文没传的话，就直接回答用的问题， 然后真正调用的时候，真正调用的时候，呃这个方法首先会通过这个 q a prompt 构造出一个 prompt template， 然后准备一个 map 的 地线，把 question 这段设置成用户传进来的消息，那如果这个这个变频参数为处的话，就把上下文填成这个 呃，上面加载这个资源，这个是知识文档，这就等于告诉 呃，这就等于告诉 point tempet 把诊断的文档塞进这个提示词里，否则上下文它就是有控制论说只能靠模型自带的知识回答。那最后一行就是正常的一个呃模型的一个 调用，那这个就是一个完整的模板加问题，再加可选的上下文的一个调用念， 那这个模块其实有一个很值得我们去学习的，就是 prompt 的 外字化，如不论是 system 干 message 还是这个 qa 干 prompt 啊？通过都是通过 resource 来加载和模板引擎渲染的， 那这样的话可以在不改代码的情况下来试这个 front 版本，这也是我们做这个 front 公存非常重要的写作方式，但这个项目它其实是比较简单的。 好了，那么我们以上就是我们今天的所有内容，感谢大家观看，我们下期再见。

ai 圈子里每天都在冒新名词， l l m token， context prompts tool、 m c p agents agent， skill。 这些词你可能都听说过，但是我问大家，你真的能准确地说出其中每一个概念的确切含义吗？ 这期视频我们不整那些虚头巴脑的商业概念，我们就从最底层的工程视角出发，一个一个地把这些概念拆开、揉碎，讲清楚。看完这期视频，相信你对 ai 的 理解绝对会上升一个台阶。我们先从最底层的东西开始，一层一层地往上搭，最底层的就是 l l m， 全称是 large language model， 翻译成中文就是大语言模型，简称大模型。 基本上现在所有的大模型都是基于 transformer 这套架构训练出来的。这个架构看起来很复杂，不过不用担心，这张图你现在看不懂是完全正常的。我们今天呢，也不打算研究它，你只需要知道，大模型的底层引擎就是它。 transformer 架构最早其实是由 google 团队在二零一七年的时候提出来的，对应的论文名是叫做 attention is all you need。 很 有戏剧性的是，虽然 google 发明了火种，但真正把它点燃并且引爆全世界的却是 open ai。 大家应该都记得，二零二二年底， gpd 三点五横空出世，它应该算是第一个真正达到可用级别的大模型了，相信当时用过的人都能感受到它的强大。 但这还没完，仅仅几个月之后，在二零二三年的三月份， gbt 四发布，它呢，是直接把 ai 的 能力天花板拉到了一个新的高度。可以说 gbt 系列就是我们今天 ai 浪潮的绝对鼻祖了， 甚至时至今日， gbt 家族依然非常强大，比如现在的 gbt 五点四就是业界的标杆之一。不过如今的 ai 赛道早已经不再是 openai 的 独角戏了， 像 cloud、 gemini 等优秀的后起之秀，都在各自擅长的领域与它同台竞技。好，前面我们说了大模型的大致由来，那大模型到底是怎么工作的呢？ 其实非常的朴素，它本质上呢就是一个文字接龙游戏。我们来看一个具体的例子， 假设你向大模型提问马克的视频怎么样？模型接收到这句话之后，经过内部的一通预算，它会预测下一个概率最高的词，比如特别关键点来了， 模型吐出特别这个词之后，他并不会停下来，他会把这个刚吐出来的特别这个词抓回来，追加到你刚才的那个输入的后面，然后他拿着这个新的输入再去预测下一个字，比如说是的，接着他再把的塞回去，然后再预测下一个词，比如说是棒， 然后呢，他会把棒这个字也塞回到输入里面，这个时候大模型会发现他要说的话已经全部说完了，此时他就会输出一个特殊的结束标识符，整个回答到这里就算是彻底结束了。这样我们就拿到了大模型的完整回答，特别的棒， 这是大模型最底层的生成原理了。理解了这一点，你就明白了为什么大模型要一个词一个词的输出答案，因为他就是这么运作的。 好，我们刚才说了，用户提交问题给大模型之后，大模型每次都会突出一个词，但其实这是为了方便你理解而简化的一个列录。 现实情况是这样的，大模型本质上是一个庞大的数学函数，里面跑的全是矩阵计算，它接收的呢是数字，输出的也是数字，压根就不认识人类写的文字。所以呢，在人类和大模型之间，必须有一个中间人来做翻译， 这个中间人呢，就叫做 tokenizer， 他 负责的是编码和解码两件事情，编码就是把文字变成数字，解码反过来是把数字还原成文字，还是？拿刚才的那个例子来说，用户提问马克的视频怎么样？ 这句话呢，会先交给 tokenizer 处理，它要把这些文字转换成数字，这个呢就是编码环节在发挥作用了。我们来把编码的过程拆开来，仔细看一下，搞清楚它究竟是怎么把文字变成数字的。这个过程分两步走， 第一步，切分它，把用户的问题接过来，把它拆成一个一个最小的片段，这些片段呢就叫做 token。 我们这里呢，一共是切出了四个 token。 第二步，映射，由于模型只认数字， tokenizer 呢就会把每一个 token 对 应到一个数字上去， 这个数字呢就叫做 token id。 token id 和 token 是 一对一绑定的， token 是 文字， token id 是 数字，这两个呢，其实本质上是一个意思，只不过是换了种表达方式而已。 经过了这两步，原来的一句话就变成了一串 token id 组成的列表，然后 tokenizer 会把这串列表送进模型，模型在内部一顿预算，最终吐出了一个 token id。 这个时候 tokenizer 再次出场，把这个 token id 翻译回 token， 这个呢就是解码环节的工作了。 解码只有一步，那就是映射方向呢，是跟编码反过来把数字转换成文字。要注意的是，解码环节是不需要切分的，因为模型每次只会给出一个头肯，并没有什么好切分的。 解码完成后，我们就拿到了大模型输出的第一个头肯，特别如果模型的话还没有说完，就继续吐第二个，第三个头肯。后面的流程呢，其实都是一样的，这里就不再重复了。 所以你看到了吗？ token 才是大模型处理文本的最基本单元。大模型一个 token， 一个 token 的 接收输入，然后再一个 token， 一个 token 的 输出。结果。现在我们回头看刚才的那个例子，马克的视频怎么样？它呢，是被切分成了四个 token。 马克的视频和怎么样， 你有没有注意到这里每个 token 好 像都正好对应一个词啊，所以你可能会想， token 就是 词对吧？但其实不一定， token 和词呢，并不是一对一的关系，刚才那个例子只是恰好而已。我们换几个例子你就明白了。 比如我的频道呢，是叫做马克的技术工作坊。如果按照词的标准来划分的话，那应该是有四个 token， 分 别是叫做马克的技术和工作坊。 那真的是这样吗？ openai 提供了一个把文本转换为 token 的 页面，我们不妨去试一下。首先粘贴上我们要切分的文本，也就是马克的技术工作坊。你看，他把我的频道名转换成了五个 token， 其中每个颜色代表一个 token， 这里还能看到对应的 token id， 这里要注意了， openai 把工作访拆成了两个 to 肯，工作和访分别代表一个 to 肯，这跟我们预想的不一样，在我们的预想中，工作访应该是一个词，那它应该正好对应一个 token 才对。不过呢，实际上它会被拆成两个 token。 当然，你也可能会说，工作坊是不是也不能算作一个词啊？好，那我们再看一个更明显的例子，程序员，这总算是一个完整的词了吧。但在 tokenizer 里面，它被切成了两个 token， 程序和元。 这个呢，是中文的情况，那英文呢？一个英文单词对应一个 token 吗？对于常见单词，确实是这样的，比如 hello 是 一个 token， going 也是一个 token。 不 过这个呢，也不是铁律，比如 helpful 这个单词就被拆成了两个 token， help 和否。甚至在某些情况下，一个字母会被切分成多个 token 来用。比如对勾这个字母就需要三个 token 来表示它。 不过这三个 token 没有对应的显示字母，所以在这里面显示的就是问号了。这种情况下，看 token id 可能还更直观一些， 你看，确实是三个。所以我们总结下，词和 token 并没有什么明确的一对一的关系。你可以把 token 理解成模型，自己学会的一套文本切分规则，切出来的每一块就是它一次能够处理的最小单位。 平均来讲，一个 token 大 概是等于零点七五个英文单词，或者是一点五到两个汉字。比如四十万个 token， 大 概呢就是六十到八十万个汉字，或者是三十万个英文单词。如果你对 token 的 切分原理感兴趣，想详细了解一下 token 到底是怎么生成出来的，可以看一下我的这个视频， 它详细讲述了如何使用 bpe 算法来训练和使用 tokenizer。 好，我们刚才讲了 token， 知道了它是大模型处理文本的基本单位。下面我们来看一件你可能一直觉得理所当然，但其实很值得想一想的事情。 我们平时和大模型聊天，他好像能记住之前说的话，比如你开头告诉他我叫马克，他跟你回复了以后，你再问他我叫什么，他还是能够回答的出来。但问题是，大模型本质上只是一个数学函数，你给他输入，他就给你输出，他并不像人一样真的有记忆。 那他是怎么记住之前的聊天内容的呢？答案就是，我们每次给大模型发送消息的时候，并不只会发我们的问题，背后的程序会自动把你之前的整段对话历史找出来一起发过去。 这样的话呢，有了用户问题，有了对话历史，模型每次看到的就是完整的对话内容了，所以他才能够知道之前发生了些什么。 这就引出了 context 这个概念。中文呢，是叫做上下文，它代表大模型每次处理任务时所接收到的信息。总和我们刚才聊到用户问题和对话历史，都是大模型所接收到的消息，所以呢，它们都是 context 的 一部分。 除了它们之外， context 里面还有很多其他的内容，比如大模型正在输出的每一个 token 也会被追加进来。 除此之外呢，这里面还会有工具列表、 system prompt 等信息，这些概念呢，我们后面会一个一个的讲到，你暂且不用关心， 现在你只需要记住一件事情， context 呢，就是大模型每次处理任务时所接收到的信息总和。从某种程度上，我们也可以把它看成是大模型的一个临时记忆体。 理解了 context， 下一个问题就自然而然的出来了，这个 context 能有多大？它能塞多少 token 呢？这个呢，就引出了 context window 这个概念，翻译过来呢，就叫做上下文窗口，它呢就代表了 context 能够容纳的最大的 token 数量。 举个例子， context window 为一万，就代表模型最多能够处理一万个 token， 不 过一万的 context window 算是很小的了。目前主流的大模型都有着非常大的 context window， 比如说 gpt 五点四的 context window 是 一百零五万。 jamaican 三点一 pro 的 context window 是 一百万， cloud opus 四点六的 context window 是 一百万。我们之前说过，一个 token 大 概是等于一点五个汉字， 那么一百万个 token 呢，差不多就是一百五十万个汉字了，那整个哈利波特全集的内容都能装下，算是很大的了。 好，相信大家对 context 已经有一个初步的了解了，下面我来问大家一个问题，假如你有一个上千页的公司产品手册，你希望大模型根据这个产品手册来回答用户的各种疑问，那这要怎么实现呢？你要把这个手册的全部内容跟着用户问题一起扔给大模型吗？ 这其实不是一个很好的解决方案，因为这个产品手册太长了，即使模型的 context window 不 被承包，你的成本也无法控制， 那这该怎么办呢？这就需要一个叫做 rag 的 技术了，它可以从产品手册中抽取用户问题最为匹配的几个片段，然后只把这几个片段发给大模型，让大模型只根据这几个片段来回答用户的问题，这样大模型接到的就不是一整本书了，可能只是几段话， 这样就不受 context window 大 小限制了，成本也会低很多。如果你对 rec 技术感兴趣，想深入了解下它的实现原理的话，欢迎看一下我的这个视频。 prompt 中文为提示词，它是大模型接收的具体问题或指令。比如你去向大模型提需求，帮我写一首诗，这句话呢，就是 prompt， 对，不要把 prompt 想成特别复杂高端的东西，它只不过就是给大模型的一个问题或者是指令而已。接到了这个输入之后，大模型才会开始运转，然后呢，才会给你一个对应答案。但这里面会有个问题，如果你只是简单地说帮我写一首诗， 大模型可能会给你写古诗，就像屏幕上给你展示的这样，但也可能给你写现代诗，甚至可能来一首打油诗。 为什么呢？因为你的 prompt 太模糊了，它不知道你具体想要什么。所以 prompt 怎么写，直接决定了大模型的输出质量。一个好的 prompt 应该是清晰的、具体的、明确的。比如，你可以这样写， 请帮我写一首五言绝句，主题是秋天的落叶，风格要背亮一点。这样一来，大模型就清楚多了，它生成的内容也就更符合你的预期。 这就是为什么有个专门的领域叫做 prompt engineering， 也就是提诗词工程，说白了就是研究怎么把话说清楚，让大模型更精准的理解你的意图。当然，这个领域虽然曾经比较火，但现在还在提它的人其实寥寥无几。一方面是因为门槛太低，本质上就是把话说清楚嘛。 另一方面呢，是大模型的能力越来越强了，即使提示词含糊不清，大模型也能大致猜出你的意图来，这种情况下，也就不需要在提示词上花太多功夫了。好到这里， prompt 基本概念应该是搞清楚了，但是事情还没有完。 你有没有想过一个问题，有些时候，我们不仅要告诉大模型他要处理的具体任务，还要告诉他人设和做事规则，也就是告诉大模型他是谁，他应该按照什么规则做事。 所以呢，这就引出了两种不同的 prompt， 说明具体任务的是 user。 prompt， 中文为用户提示词，它是用户自己输入的。说明人设和做事规则的是 system prompt， 中文为系统提示词，它是开发者在后台配置的。 让我们来用一个具体的例子解释这两个概念。假设你要做一个数学辅导机器人，你希望它不要直接告诉学生答案，而是要引导学生思考。 这时候呢，你就需要两种 prompt。 第一种呢是 system prompt， 你 在后台这样设置，你是一个耐心的数学老师，当学生问你数学问题的时候，不要直接给出答案，而是要一步一步引导学生思考，帮助他们理解题思路。 注意，这段话是你作为开发者在后台设置的，用户根本看不到，但他会一直影响大模型的行为。然后学生在对话框里输入三加五等于几， 这就是第二种 user prompt， 用户在对话框里直接输入的问题。大模型看到这两个 prompt 之后，他会这样想，我的角色是数学老师，我要引导学生思考，不能直接说答案。好，那我就这样回答。 我们可以这样想，你手里有三个苹果，然后又拿了五个，现在一共有多少个呢？你可以数一数看。看到了吗？如果没有 system prompt， 大 模型可能就直接说八了， 但因为有了 system prompt 的 约束，他知道自己要扮演一个引导式的老师，所以回答就完全不一样了。相信你现在可以理解 user prompt 和 system prompt 的 区别了， 有了他们的配合，大模型既能守住规矩，又能够完成你的具体需求。好， prompt 呢，我们就讲到这里了，我们再来看下一个概念 tool。 我们先来谈一下大模型的一个弱点，他无法感知外界环境。我来举个例子，假设你问大模型今天上海的天气怎么样，他可能会说，抱歉，我无法获取实时天气信息，我的知识库截止到某年某月无法提供当前的天气数据。 为什么呢？因为大模型只是个文字接龙游戏，他的能力是根据训练数据来预测下一个词，但他真的没有办法去查天气预报网站，拿到实时的天气数据。 这该怎么办呢？这就需要 to 了。 to 翻译成中文就是工具，工具这个词不太好理解，我们再换一个词，函数，对，没错， to 本质上呢就是一个函数，你给它输入，它就给你输出。 比如一个天气查询工具，它的输入呢，可能会包含两个参数，分别是城市和日期，传入后它内部一同操作。比如说它可能会去调用气象局的接口，但不管怎么样，最后它都会给你一个输出，告诉你对应的天气信息。 有了它，大模型就可以回答天气相关的问题了。让我们来看一下从用户提问到大模型回答的完整流程。整个流程所涉及到的角色呢，是包括用户、大模型、天气查询工具，还有平台。你可能会问平台是什么？你可以把平台理解为一个传话筒， 因为用户、大模型、天气查询工具这三个角色没有办法直接对话，所以呢，我们就需要平台这个角色来做传递信息的工作。它本质上呢就是一段代码，用来负责上传下达。 你可能还有点懵，没事，现在不明白也没有关系，你看完流程就懂了。在流程一开始的时候，用户的问题会首先发给平台， 平台会把用户的问题转发给大模型。不过发给大模型的可不止有用户问题，还有目前可用的工具列表，比如说是天气查询工具、计算器工具等等。 大模型收到这个问题之后，他会自己分析，用户想知道天气，而我没有实时的天气数据，但是这里面有一个天气查询工具可以用。好，那我就调用这个工具。注意，大模型无法自己调用工具，它唯一的能力就是输出文本， 如果他想调用某个工具的话，他就只能借助平台的力量，所以此时大模型会生成一个调用天气查询工具的指令，大概就是这样子的， 这个指令标识了要用的工具名称和对应的参数，他呢会发到平台那边去。平台接收到这个指令之后，就会真的调用这个工具，其实也就是调用了工具背后所对应的一个函数。调用结束之后，平台会拿到对应的天气信息，大概呢是这个样子的， 在平台拿到了工具的调用结果之后，他就会把这个信息返回给大模型，大模型拿到这个结果后，会把它整理成一句人话输出给平台，比如说是什么今天上海的天气不错，晴天温度在十五度到二十五度之间， 呃，诸如此类的。然后呢，平台会继而把这句话转发给用户，这样用户就可以看到结果了。可以看到在这个过程中，每个角色都有着自己的职责。其中大模型的职责呢，是有两个，第一个是选择工具，具体来说就是选择需要调用的工具，并生成对应的工具参数。 第二个是汇总总结，也就是在拿到工具的执行结果之后，模型需要对工具的结果做一个汇总总结。 工具的职责呢则是完成查询天气这个动作。而剩下的一个角色，平台，他负责处理的就是串联整个流程了，比如告诉模型哪些工具可用根据模型的工具调用指令来调用工具等等。 所以呢，大家要分清楚每个角色在干什么。有人可能会以为调用工具的是模型，尤其是初学者很容易就会这么想，但是模型能做的呢，仅仅是输出一段文本，告诉平台他想要调用哪个工具。调用工具这个事情最终还是要用平台来完成。 所以最后总结一下， tool 的 本质呢，就是给大模型提供一套它可以调用的外部能力，让大模型能够感知和影响外部环境。好 tool 的 概念呢，就到这里了，我们来讲下一个概念， m c p。 刚才我们讲了使用工具的全流程，但这里面有个工程上的大问题，看这两部分，第一平台要把工具列表传给模型， 第二还要能调用工具。要做到这些，我们首先就得把工具接入到平台里面，这样平台才知道可用工具列表，以及每个工具的用途参数和调用方法等等。那问题来了，这套接入的规范每个平台都不一样， 如果你用的是叉 gpt， 你 得按照 openai 的 规范肌肉工具写一套肌肉代码。如果你用的是 cloud， 你 得按照 antropic 的 规范再写一套肌肉代码。如果你用的是 gemini， 你 得按照 google 的 规范再写一套。 看出问题了吗？同一个工具你要写三遍。因为每个平台的接入标准都不一样，所以呢， ai 圈子里就有人想，能不能搞一个统一的标准呢？让所有的平台都遵循这个标准，这样工具的开发者只需要写一次代码，就可以在所有的平台上使用了。 这个呢，就是 m c p 的 由来了， m c p 就是 这个统一的接入规范。 m c p 的 全称呢，是叫做模型上下文协议。 这个名字起的有点学术不太好理解，你就把它理解成一套统一的工具肌肉标准就好了。有了 m c p 之后，工具的开发者只需要按照 m c p 的 规范开发一次工具，这个工具就可以被所有支持 m c p 的 平台使用。这就像是所有的手机都用 type c 接口一样，有了统一的标准，大家都会方便很多， 那这个就是 m c p 的 由来和作用了。如果你想更深入的了解 m c p 协议的内容的话，可以看下我之前出过的 m c p 终极指南系列，分三期，从实用到原理，把 m c p 协议扒了个底朝天。相信看完之后呢，你会对 m c p 有 一个非常全面的理解。 好，现在我们知道了，大模型能借助工具感知外部世界，而工具又可以使用 m c p 这种方式来统一介入。按理说，有了这两个东西，大模型应该很强了吧，但实际上还差一点东西，比如啊，我们来尝试让大模型解决一个更有难度的问题， 今天我这里的天气怎么样？帮我查一下附近有没有卖雨伞的店。然后呢，我们假设有这些工具可用， 首先是定位工具，他负责查询用户所在地区的经纬度，然后是天气工具，他呢，是用来根据经纬度查询天气信息。还有店铺工具，他呢，是通过经纬度来查询附近的店铺。 相信有些同学已经看出来了，要解决这个问题，我们需要调用多次工具。从大模型的视角来看，整个过程应该是这样的， 首先大模型思考用户问天气，那要拿到天气信息的话，肯定是要知道用户的当前位置的，正好这里有个定位工具，我来申请调用下。 之后呢，大模型就发出了工具调用指令，让平台去调用这个定位工具，获取用户所处位置的经纬度， 然后平台就返回了工具，结果精度是负七十四度，纬度是四十度。模型再次思考好，拿到了位置，下一步我就需要查询这个位置的天气了，我来看看， 嗯，有一个天气工具可以用，那就调用它。大模型再一次向平台发出了指令，调用天气。工具参数是精度负七十四度，纬度四十度。平台调用工具之后返回，结果有雨，模型再次思考， 发现下雨了，根据用户的要求，如果是下雨，我还需要帮他找雨伞垫。这里有一个店铺工具，我来调用一下， 然后大模型就向平台发出了工具调用指令，调用店铺工具搜索雨伞。平台返回结果附近一百米有家全家的便利店卖伞。大模型综合了所有信息，心想目标已经全部达成，我可以给用户最终答案了。在大模型给出了最终答案之后，整个回答就算是全部结束了， 看到了吗？这不再是一个简单的工具调用流程了，在这个步骤中，大模型需要一步一步思考当前的情况，并决定下一步该做什么。从某种程度上来说，大模型已经有了一定的自主规划能力， 我们称这种能够自主规划、自主调用工具直至完成用户任务的系统为 agent。 目前市面上有很多 agent 产品，比较流行的是包括 cloud code、 codex、 gemini、 c l i 等等，它们所使用的 agent 构建模式呢，也是五花八门，比较经典的有 react， plan and execute 等等。 如果你对构建模式这个词比较陌生，甚至根本就没有听说过的话，强烈建议去看一下我的这期视频，里面不仅详细拆解了每种构建模式的运行流程，甚至还抛弃了所有现成的 a 帧框架，直接手写了一个简化版的 cloud code。 相信看完之后你就会彻底明白 a 帧到底是如何实现的。 我们现在知道 agent 能够自主规划调用工具，持续工作直到完成任务了。听起来已经很厉害了对吧？但在实际的高频使用中，你马上就会遇到一个新的痛点。 举个例子，假设你希望大模型成为你的出门小助手，每次出门前帮你扫一眼天气，并提醒你带东西。你肯定有一套自己的出门习惯，比如下雨带伞、光照墙戴帽子，空气差戴口罩，风大穿防风外套。无论如何呢，手机必带。 不仅如此，你可能还是个强迫症，希望他的回答不要太啰嗦。比如先来一句总结，然后呢，再列出带原因的物品清单。 在没有额外设定的情况下，假定你只问一句，我马上要出门，该带些什么呢？ agent 呢？虽然会查天气，但他不知道你的这些私人规则和格式要求，大概率呢，会给你一堆废话。他不能按照你的出门习惯来判断要带的东西，最终的输出格式也无法满足你的要求，毕竟他都不知道嘛。 为了拿到让你满意的结果，你每次提问的时候呢，就不得不带上一大串尾巴，把你的所有的规则，所有的格式要求，甚至视例全部都复制粘贴到 prompts 里面发给他。试想一下，每次出门都要敲这么一大长串要求，是不是太反人类了？ 别担心，这个时候呢，就该 agent skill 登场了。 agent skill 本质上就是你提前写好塞给 agent 的 一份说明文档，比如刚才的那个出门的场景，我们就可以写成这样的一个 agent skill， 可以看出它本质上呢就是一个 markdown 文档，它的整体结构可以分成两部分，上面的这一部分呢是叫做原数据层，它相当于这本说明文档的封面，告诉 agent 这个技能叫什么，是负责做什么事情的。这一部分呢，至少要有两个属性，分别是 name 和 description。 name 呢，代表这个 agent skill 的 名字。比如我们的 agent skill 名称是叫做 go out checklist， 也就是出门清单的英文。剩下的 description 呢，就是描述了。然后下面的这一段，从目标开始 到这个说明文档的结束，这一大片都叫做指令层。这一层的格式不作具体要求，只要能把事情向 agent 说明白就行，格式自己来定。比如我这里就写了要完成的目标、执行步骤、判断规则、输出格式以及事例。 比如你看我们在执行步骤里面就告诉 agent 需要先调用定位工具获取经纬度，然后呢再调用天气工具获取天气信息。 拿到天气信息之后呢，需要根据天气的数据结果，按照下方的判断规则整理出门所需要携带的物品。判断规则呢，就写在这里面。 最后呢是需要严格按照下方的输出格式向用户输出最终的结果，输出格式呢，我们就写在这里，一共是需要输出两段话 在指定层的，最后我们还给了他一个视例，在这个视例里面，我们假定用户的问题呢，是这个样子的，我马上要出门，帮我看看今天要带什么东西，然后工具的返回呢？我们假设是这样子的， 定位工具返回，假设这样，天气工具返回，假设是这样，在这种情况下， agent 就 必须输出这样的一份结果，这个就是我们所需要的 agent skill 的 整体结构了。 定义好之后，我们需要把它存到硬盘里面指定的地方。拿 cloud code 举例，你需要找到用户目录下面的点 cloud skills 文件夹， 然后接下来的存放操作呢，有两个规定，大家千万不要搞错。第一，我们需要在这个目录下面新建一个文件夹，而且文件夹的名字必须与 agent skill 的 名字相同，我们的 agent skill 叫做 go out checklist， 所以 我们的文件夹也必须叫这个名字。 第二，点，进入到这个文件夹里面之后，我们需要新建一个文件，把刚才的内容全部贴进来。重点来了，这个文件名必须叫做 skill 点 md， 其中 skill 是 大写，这个呢是 agent skill 的 硬性规范，算是个街头爱好，如果你随便起别的名字，系统是绝对不会认的。好，我们把它全部给粘贴进来，然后保存退出。 存好之后呢，我们这个 agent skill 就 算是创建完成了，然后我们来随便找一个空的文件夹 启动 cloud code， 在 启动的过程中， cloud code 就 会发现 skills 文件夹里面多了一个叫做 go or checklist 的 agent skill， 它呢就会去提取对应的 skill 的 md 文件里面的原数据，也就是名称和描述。 下面的指令层暂时先不读，因为指令层的内容有可能会比较大，所以呢， cloud code 只会在用户问题与 agent skill 的 名称和描述相关的时候，才会去读取对应的指令层。 另外顺便提一下，这个 agent skill 明确要求需要定位和天气这两个工具，我已经提前把它们做成 m c p 工具导入到 cloud code 里面了，运行这个杠 m c p 就 可以验证。 这个 location 呢就是定位工具，下面的那个 weather 呢就是天气工具。这两个工具的返回结果都是我编的，到时候你就会看出来了，主要呢是为了演示整个流程好。言归正传，下面呢，我们输入问题， 我要出门了，告诉我要带什么提交，可以看到 cloud code 开始工作了，让我们稍微等待一下。 他首先是发现这个问题与 goall checklist 的 这个 agent skill 相关，因此呢，就读取了这个 agent skill 的 完整内容。这里主要读取的就是里面的指令层，毕竟原数据层已经在 cloud code 启动的时候加载过了。在读取到了 agent skill 的 完整内容之后， cloud code 就 开始按照 agent skill 的 要求做事了， 它首先是请求调用定位工具，我们同意，然后呢，它再调用天气工具，我们还是同意。 最后拿到了所有需要的信息之后， cloud code 就 会把答案整理成 agent skill 中所需要的格式给到我们。没错， agent skill 的 基本功能呢，就是这么简单，它就是一个文档，一个给 agent 看的说明文档。 当然 agent skill 呢，还有很多高级的功能，比如说是运行代码、引用资源等等，它的间接式批漏机制呢，也是一大特色，可以节省很多的 token。 如果你对此感兴趣，希望深入了解一下的话，欢迎看一下我的这个视频，一次把 agent skill 的 使用和原理全部都说明白。 好到这里，我们把所有的概念都讲完了，让我们回顾一下这个体系。 lldm 代表大模型，它是所有 ai 技术的核心。 token 是 大模型处理数据的最基本单元。 context 是 大模型每次处理任务时接收到的信息总和，你可以把它看作是大模型的临时记忆体，里面装着历史记录、系统规则以及当前的输入等等，这些数据的基本单位都是 token。 而 context window 呢，则是代表大模型， context 最多能够存储的 token 量。 prompt 是 用户或系统当前给大模型下达的具体指令或者是问题，它分为 user prompt 和 system prompt 两大类。 user prompt 代表用户给模型的输入，而 system prompt 则是开发者在后台配置的大模型人设和做事规则。 tool 是 大模型用来感知和影响外部环境的函数。 mcp 呢，则是统一了工具接入格式的标准协议。有了 mcp 之后，开发者就只需要按照一个标准来做工具就可以了，不需要为每个大模型厂商都做一遍。 agent 是 能自主规划，自主调用工具，持续运作直至解决用户问题的一个程序。 agent skill 呢，是给 agent 看的一个说明文档，主要就是用来规定做事步骤和规则的， 大致呢就是这个样子的了。理解了这些概念，你就能看懂 ai 圈子里面的各种新产品新技术了，无论是 cloud code codex、 co work 还是 open claw， 它们本质上都是在这个框架下运作的。好，这期视频呢，到这里就结束了，如果对你有帮助，别忘了点赞关注。我是马克，用最通俗的语言讲最硬核的技术，我们下期再见。拜拜。

大家好，今天我想和大家分享一下使用 prompt 的 一些心得，特别是如何让 ai 更准确地理解你的需求。这个视频主要面向的是那些想和 ai 对 话，希望 ai 帮助完成任务，但却发现生成的答案和期望不符的朋友们。如果你目前连什么是 prompt 都不清楚， 那这段视频可能不太适合你。不过没关系，今天的视频会帮你快速了解，接下来就进入正文吧。 首先 prompt 就是 提示词，我们可以通过这条公式理解 prompt 等于角色加任务加约束加输出格式。说到角色，它其实很容易理解，角色就是你让 ai 扮演的身份，比如你可以让 ai 扮演 ai 专家、编剧、设计师等， 明确角色能帮助 ai 更好地理解你想要的风格和领域。然后是任务，任务就是你希望 ai 完成的工作，比如写一篇文章，生成一张图片，或者编写一段代码。接下来是约束条件， 这就是你希望 ai 在 执行任务时必须遵守的限制，比如字数要求、语气风格或者时间限制等等。最后是输出格式，有时候你可能希望 ai 输出特定的格式，比如 markdown 格式、代码块或者表格，这些格式要求也是必须提前指明的。 举个例子，我让 ai 帮我写了一篇关于健康饮食的文章，下面是 ai 生成的第一版，内容 稍微模糊了一些，接下来我给他添加了更加精准的提示词， 你可以看到优化后的提示词让 ai 生成的内容更具有操作性。比如在第一版中， ai 建议每日摄入十二种食物，每周达到二十五种以上，这对很多人来说是比较难做到的。但在优化后的第二版中， ai 给出了具体的建议，吃麻辣烫时主动要求加一份玉米或红薯，外卖时单点一份凉拌黄瓜等等。 通过这个对比，我们就能明显看到，精准的 prompt 能帮助 ai 生成更加实用可操作的内容，只要给出更明确的提示， ai 的 输出就会更符合我们的需求。希望通过这个例子，大家可以直观地感受到使用 prompt 前后的差别，给 ai 明确的指引能够帮助它更好地为我们提供有效的解决方案。

这是一个实用价值非常高的 prompt 技能包，它可以把我们随手写的模糊的阶段的、深度研究的需求快速转化为结构清晰的、可以直接丢给 ai 的 深度研究工具的高质量的提字词。 本质上它是一个 dvd 需求，然后转化为专业级的 prompt 的 转换器的 skill， 让我们输入很随意它就能够输出非常专业的就是这些提字词的一个技能，有需要的可以关注试一下。

有看不下去文献，或者一看文献就走神的朋友们，有这样的情况请大家跟我学。首先你先想自己是一个博主，然后今天你的拍摄任务是教网友们如何用 ai 看懂文献，就像我这样。然后呢，你把手机架在这边上，你现在把你不想看的那篇文献，或者看了一半的文献上传给任何一个 ai 的 prompt， 非常简单，我是一个智障， 用智障能看懂的方式给我讲到这篇文献，然后你就会发现他讲的每一句话都非常的生动易懂。 完之后，你就对着镜头给大家复述一遍你刚看到的内容。这篇文章研究科学问题是什么，用了什么方法，什么结论，什么 conclusion， 你 都对着镜头把它 说一遍。一般这样之后，我就会开始好奇这篇文章每一段具体的都讲的是什么，所以我就会请我的第二个 problem 就是， 好，现在我想认真读这篇文献，你每一段都带我解读一下。由于他仍然觉得我是一个智障，所以他会非常认真非常细致的给我解释每一个小点。比方说你看他这个中文结束就是一句 一句一句的来，这样我基本上已经掌握了这篇文献所有的内容，我会再回去看一遍英文的文献，然后本来要花一天时间看的一篇文献，二十分钟就看完了，且我觉得我掌握了大部分的文献内容，听懂了请复述一遍。

大家好，欢迎来到大模型基础的第六期，上期我们聊了 ai 的 幻觉，教大家如何避开 ai 一 本正经胡说八道的坑。那今天我们就来聊一聊能让 ai 听话输出高质量内容的核心。 prompt， 也就是我们常说的提示词，到底是什么？其实一句话就能讲明白。 prompt 就是 你给大模型下达的指令，你在对话框里输入的每一句话， 每一个要求，本质上都是 prompt。 而这个指令写得好不好，有一个最核心的影响，它直接决定了 ai 输出的内容的质量。很多人吐槽 ai 不好用，输出的内容不对位，其实大概率不是模型不好，而是你的 prompt 没写对。 那这个行业里面有一个黄金法则，叫做 g a g o， 翻译过来就是垃圾进垃圾出。举个最常见的例子，你只跟 ai 说帮我写个文案，它大概率会给你一篇平平无奇，没办法直接用的内容。 但是如果你给他说清楚文案的用途、目标、受众、风格、调性，甚至是具体的字数要求，他就能精精准给到你想要的内容。你的输入指令质量直接决定了 ai 的 输出质量。 还有一个很形象的说法，写 plumb 就 像用人话在编程，以前我们让电脑干活得学复杂的代码语言， 现在有了大模型，你不用懂编程，只要用日常的说的大白话，把你的要求、规则、目标说清楚，就能让 ai 帮你完成任务。 这就是大家常说的自然语言编程。而 plm 就是 你写给 ai 的 人话代码，一句话总结说就是， plm 越好， ai 越懂你， plm 写的越清晰， 结果越好用，它不是什么高深技术，而是一种和 ai 沟通的表达能力。写的好，工作学习提效。写的不好，那我们就要返工。 以后你用 ai， 不 妨多花几秒钟思考一下，把这个要求写清楚。很多朋友会问，那到底怎么才能写好 plunk？ 别着急，下期我们就来拆解写好提示词的核心技巧，手把手教你写出高质量的 plunk。 那 今天的内容就到这里，咱们下一期聊一聊如何写出高质量的 plunk， 下期我们再见！

很多人以为 skills 不 就是一堆 prompt 的 收藏夹吗？这个理解很常见，但是恰恰这就是 agent 不 稳定的起点。 在 agent 体系里， skill 本质是一个可附用的任务模块，它不只是描述怎么做，还会定义事情必须怎么执行。一个真正的 skill 通常包括指定告诉模型要做什么，脚本负责实时执行和输出的结构。 promote 啊，其实只是对外的接口， promote 可以 告诉模型怎么想，但是啊， skill 是 强制执行的流程，哪些步骤必须跑脚本，哪些结果不合格要重来，哪些情况失败了要返回， 关键不在写没写，而在能不能保证发生。所以当你把 skill 当成 promote 的 集合，那系统的稳定性就只能靠运气了。当执行和失败的处理都被写进 skill 啊， a 阵才可以变得可控。 所以更准确的说法是，啊， skill 用 prompt 做接口。但 skill 啊本身是工程模块儿，把它当系统啊才能藏可靠。