1. 为什么我劝你别再从零搭 AI 工作台先说结论过去大半年我前后帮三个团队、两个独立开发者朋友搭过所谓的“AI 创作工作台”从最原始的 API 调用一路折腾到带 Skill 编排、Prompt 模板库、多模型路由的完整形态。踩过的坑足够写一本小册子。所以当我看到“不用从零搭建这套 AI 创作工作台可以直接复制”这个说法时第一反应是——这话说得太对了但前提是你得知道“复制”的到底是什么。很多人对 AI 工作台的理解还停留在“装个客户端、填个 API Key、能聊天就行”。这顶多叫“AI 聊天入口”离“工作台”差着十万八千里。真正的工作台核心不在于模型本身而在于模型外面那一层Prompt 怎么组织、Skill 怎么编排、上下文怎么管理、输出怎么沉淀。这四件事才是决定你效率上限的东西模型只是发动机工作台是整台车。我见过太多人一上来就想着“我要自己写一套”结果两周过去还在调 UI 布局核心的 Prompt 工程和 Skill 逻辑一行没动。这就是典型的把力气用错了地方。一套成熟的 AI 创作工作台它的价值 80% 在“编排层”20% 才在“界面层”。而编排层这东西是完全可以复制、可以迁移、可以拿来就用的。这篇文章我想聊的就是一套可以直接复制的 AI 创作工作台它的骨架长什么样每个模块为什么这么设计Skill 和 Prompt 到底怎么配合以及我在实际搭建和使用过程中总结出来的那些“文档里不会写”的经验。适合两类人看一类是想快速拥有一套可用工作台、不想重复造轮子的实践派另一类是已经有一堆零散工具、但始终没串成体系、效率上不去的进阶用户。不管你是写代码的、做内容的、还是搞测试和数据分析的这套思路都能直接套。2. 一套可复制工作台的骨架拆解2.1 工作台的四层结构从入口到沉淀我习惯把 AI 创作工作台拆成四层从下往上分别是模型接入层、Prompt 编排层、Skill 执行层、产出沉淀层。这个分层不是为了好看而是为了让你在“复制”别人方案的时候能清楚地知道哪一层可以直接抄、哪一层必须按自己的需求改。模型接入层是最底层的负责对接各家大模型。这一层的关键不是“支持多少模型”而是统一接口。我见过有人给每个模型写一套调用逻辑结果换个模型就要改一遍代码维护成本爆炸。正确做法是抽象出一个统一的调用协议把不同模型的参数差异比如 temperature 的取值范围、system prompt 的支持情况、流式输出的格式在适配器里消化掉上层完全无感。Prompt 编排层是整套工作台的灵魂。它管的是“什么场景用什么提示词、提示词怎么组合、变量怎么注入”。这一层做得好你会发现同一个模型出来的效果能差出一倍。我自己的做法是把 Prompt 拆成角色定义、任务描述、约束条件、输出格式四个可复用片段用的时候像搭积木一样拼。这样改一个片段所有用到它的场景全部生效。Skill 执行层是最近半年最热的部分。所谓 Skill本质上是“把一段固定的能力封装成可调用的单元”。比如“读取本地文档并总结”是一个 Skill“把中文翻译成英文并保持术语一致”是一个 Skill“根据需求生成测试用例”也是一个 Skill。Skill 和 Prompt 的区别在于Prompt 是“告诉模型怎么做”Skill 是“把做这件事的完整流程固化下来”包括调用哪些工具、传什么参数、结果怎么处理。产出沉淀层最容易被忽略但恰恰是拉开差距的地方。大部分人用完 AI 就把结果复制走了下次要用又得重新生成。而一套好的工作台会把每次的输入、输出、用到的 Prompt 和 Skill 都记录下来形成可检索、可复用的知识库。时间一长这个库本身就是你最值钱的资产。2.2 为什么“复制”比“自建”更划算这里我要说一个可能有点反直觉的观点对于 90% 的人来说自建 AI 工作台的投入产出比是负的。算笔账。自建一套能用的工作台你需要设计数据结构、写模型适配、做 Prompt 管理界面、实现 Skill 编排引擎、处理上下文截断、做错误重试、搞日志记录……就算你技术很熟保守估计也要两三周的全职投入。而这两三周里你本来可以用现成方案产出多少东西更关键的是自建的东西往往“只有你自己会用”。一旦你想分享给同事、或者团队里换个人接手对方看不懂你的设计思路维护成本立刻飙升。而一套设计良好的可复制工作台它的结构是通用的、文档是完整的、别人拿来就能上手。所以我的建议是骨架直接复制血肉按需替换。骨架指的是分层结构、Skill 的组织方式、Prompt 的模板机制血肉指的是你具体业务场景里的那些提示词和流程。骨架是通用的血肉是个性化的。把骨架抄过来你省下的时间足够你把血肉打磨得非常精细。2.3 复制前必须想清楚的三件事不过在动手复制之前有三件事必须先想清楚否则抄过来也是白搭。第一你的核心场景是什么。工作台是服务于场景的不是反过来。如果你主要做内容创作那 Prompt 编排层和产出沉淀层是重点如果你主要做代码辅助那 Skill 执行层和模型接入层更关键。别想着做一个“什么都能干”的万能工作台那种东西最后往往什么都干不好。第二你的输入输出形态是什么。是纯文本对话还是要处理文件、图片、表格是单轮问答还是多轮迭代这决定了你的上下文管理策略。我见过有人抄了一套为长文档设计的工作台结果自己天天用的是短对话那套复杂的分块检索逻辑纯属累赘。第三你打算投入多少维护精力。工作台不是搭完就完事的模型会更新、Prompt 会迭代、Skill 会增删。如果你只想“搭好就不管”那就选最简结构如果你愿意持续打磨那可以上更复杂的编排。3. Prompt 与 Skill 的配合机制3.1 Prompt 不是越长越好而是要“结构化”关于 Prompt网上流传着大量“万能提示词模板”动辄几百上千字。我实测下来长 Prompt 的效果提升是有天花板的而且很容易触发模型的“注意力稀释”——你写了二十条约束模型可能只记住了前五条。真正有效的做法是结构化。我自己的 Prompt 模板固定包含四块角色一句话说清“你是谁、你擅长什么”。比如“你是一位有十年经验的测试工程师”。任务明确这次要做什么动词开头。比如“根据以下需求文档生成测试用例”。约束只写真正关键的 3 到 5 条。比如“用例要覆盖边界值”“每条用例包含前置条件和预期结果”。输出格式给出明确的格式要求最好带一个示例。比如“用 Markdown 表格输出列为用例编号、场景、步骤、预期结果”。这四块加起来通常不超过 300 字但效果比那些千字长文稳定得多。原因很简单结构化的信息模型更容易解析关键约束不会被淹没。提示约束条件宁少勿多。如果你发现某条约束模型总是忽略与其反复强调不如把它挪到 Skill 层用代码去校验。3.2 Skill 的本质把“流程”固化下来很多人把 Skill 和 Prompt 混为一谈其实两者定位完全不同。Prompt 解决的是“这一次怎么做”Skill 解决的是“这一类事怎么做”。举个例子。你要做“把一篇中文技术文章翻译成英文”。用 Prompt 的话你每次都要写“你是翻译专家请把以下内容翻译成英文保持术语一致不要意译……”而用 Skill 的话你把这套逻辑封装一次以后只需要传入文章内容Skill 自动完成调用翻译 Prompt、检查术语表、处理长文分块、合并结果、做格式校验。Skill 的价值在于可复用和可组合。一个成熟的 Skill 库应该像乐高积木一样能拼出各种复杂流程。比如“文档总结 Skill”加上“翻译 Skill”加上“格式转换 Skill”就能拼出一个“外文文档自动摘要”的完整流程。我自己的 Skill 库现在有二十多个常用的就那么七八个。这里有个经验Skill 不要贪多要贪“稳”。一个 Skill 如果十次里有两次出错那它带来的麻烦比省下的时间还多。宁可只保留那些经过反复验证、成功率 95% 以上的 Skill。3.3 两者如何配合一个真实场景的拆解光说理论没意思我拿一个真实场景拆给你看。场景我需要定期把一批英文技术文档读一遍提炼出要点整理成中文周报。拆解下来是这样配合的第一步文档读取 Skill负责把文档从各种格式PDF、Markdown、网页里抽出来统一成纯文本。这一步是纯工程活不需要模型。第二步分块总结 Prompt负责对每个文本块做摘要。这里 Prompt 的角色是“资深技术编辑”任务是“提炼这段内容的核心观点”约束是“保留关键数据和结论去掉举例和铺垫”输出格式是“三到五条要点”。第三步要点合并 Skill负责把各块的摘要去重、合并、按主题归类。这一步又用到一个 Prompt角色是“信息架构师”任务是把零散要点组织成有逻辑的结构。第四步中文润色 Prompt负责把合并后的内容改写成通顺的中文周报约束是“保持专业术语准确语气客观”。你看整个流程里Skill 负责“搬运和调度”Prompt 负责“每个环节的具体判断”。两者各司其职缺一不可。如果全用 Prompt你会写一个巨长无比的提示词效果还不稳定如果全用 Skill那每个 Skill 内部还是得靠 Prompt 来做判断。所以正确的姿势是Skill 搭骨架Prompt 填血肉。4. 从复制到跑通完整落地流程4.1 环境与依赖准备落地第一步是把环境搭起来。这里我不推荐具体的商业产品只讲通用的准备思路你按自己的技术栈对号入座。核心依赖其实就三样一个能调用模型的运行时、一个存 Prompt 和 Skill 配置的地方、一个记录产出的地方。运行时可以是本地脚本也可以是轻量服务配置存储用文件、数据库都行初期我建议直接用 Markdown 或 YAML 文件改起来直观产出记录用最简单的目录结构加命名规范就能起步。我自己的目录结构是这样的workspace/ prompts/ # 所有 Prompt 模板一个场景一个文件 skills/ # 所有 Skill 定义 outputs/ # 产出记录按日期分目录 config/ # 模型配置、密钥管理 logs/ # 运行日志这个结构的好处是所见即所得。你想改哪个 Prompt直接打开对应文件想加一个 Skill新建一个文件就行。不需要任何管理界面用 Git 管起来还能追溯每次改动。注意密钥千万别硬编码在代码里也别提交到版本库。用环境变量或者独立的配置文件并且把配置文件加进忽略列表。这个坑我见过太多人踩。4.2 把 Prompt 模板化参数注入与版本管理环境好了之后第一件事是把你的 Prompt 模板化。所谓模板化就是把 Prompt 里会变的部分抽成变量用占位符表示。比如一个翻译 Prompt 模板长这样# 角色 你是一位专业的技术文档翻译精通中英双语。 # 任务 把下面的内容翻译成{{target_lang}}。 # 约束 - 保持专业术语与术语表一致{{glossary}} - 不要增删原文信息 - 代码块和专有名词保持原样 # 输出格式 直接输出译文不要加任何说明。 # 待翻译内容 {{content}}用的时候把target_lang、glossary、content三个变量填进去就行。这样做的好处是同一个模板能服务无数个具体任务而且改模板时所有调用点自动生效。版本管理这块我要多说一句。Prompt 是会不断迭代的今天觉得好用的写法下周可能就发现有问题。所以每次改动都要记录改了什么、为什么改、改完效果如何。我习惯在 Prompt 文件顶部加一个简单的变更记录!-- v3 2024-06-10 增加术语表约束解决术语不一致问题 v2 2024-06-05 调整输出格式去掉多余说明 v1 2024-06-01 初版 --别小看这几行注释等你三个月后回头看能省下大量“我当时为什么这么写”的困惑。4.3 Skill 的编排串行、并行与条件分支Skill 编排是整套工作台里最有技术含量的部分。我把它归纳成三种基本模式几乎所有复杂流程都能用这三种模式组合出来。串行最简单就是 A 做完做 BB 做完做 C。比如“读取文档 → 总结 → 翻译 → 输出”一条线走到底。串行的关键是每一步的输出格式要稳定否则下一步的输入就乱了。并行适合那些互不依赖的环节。比如你要同时用三个不同角度分析同一段文本就可以并行跑三个 Skill最后汇总。并行能大幅缩短总耗时但要注意结果合并时的冲突处理。条件分支是进阶玩法。比如“如果文档超过一万字就走分块总结流程否则直接总结”。这种逻辑用代码判断一下就行不需要模型参与。我实际用下来80% 的场景用串行就够了剩下 20% 里大部分是并行条件分支用得很少。新手容易一上来就设计特别复杂的编排结果调试起来痛不欲生。我的建议是先用最简单的串行跑通遇到瓶颈再优化。4.4 上下文管理长对话与长文档的处理上下文管理是很多人忽略、但实际最影响体验的环节。模型有上下文长度限制超了就得截断截断策略直接决定效果。对于长对话我的策略是“滑动窗口 关键信息锚定”。保留最近 N 轮对话同时把对话早期出现的关键信息比如用户设定的角色、核心需求单独提取出来每次都带上。这样既控制了长度又不会丢失重要背景。对于长文档策略是“分块 分层总结”。先把文档切成合适大小的块每块单独总结再把总结合并。这里有个细节分块时要在边界处留重叠否则跨块的信息会被切断。我一般留 10% 到 15% 的重叠。提示分块大小不是越小越好。块太小会导致总结碎片化块太大又超出限制。我的经验值是每块 2000 到 4000 字具体看文档的信息密度。4.5 产出沉淀让每次使用都变成资产最后一步是产出沉淀这是把“一次性使用”变成“持续积累”的关键。我的做法是每次运行工作台自动在outputs/下按日期建目录把输入、用到的 Prompt 和 Skill、输出结果、耗时、模型信息全部记下来。文件名用“场景_时间戳”的格式方便检索。时间一长这个目录就成了我自己的知识库。想找之前处理过的类似内容直接搜关键词就行想复盘某个 Prompt 的效果翻记录一目了然。更重要的是这些记录本身就是优化工作台的依据——哪些 Prompt 经常被改、哪些 Skill 出错率高数据摆在那里一目了然。5. 实操中踩过的坑与排查技巧5.1 常见问题速查表下面这张表是我和朋友们实际遇到过的典型问题按出现频率排序附上排查思路。问题现象可能原因排查方向解决思路输出格式忽好忽坏Prompt 约束不够明确检查输出格式部分是否有示例加一个具体的输出示例比十条文字约束都管用长文档总结丢信息分块边界切断内容检查分块是否有重叠增加 10% 到 15% 的重叠区Skill 偶尔报错输入格式不符合预期检查上一步输出是否稳定在 Skill 入口加格式校验不合格就报错而不是硬跑术语翻译不一致术语表没生效检查术语表是否真的传进去了把术语表放在 Prompt 靠前位置别放最后响应特别慢上下文太长或并行度不够看日志里的 token 数和耗时精简上下文能并行的环节并行结果重复啰嗦约束里没限制篇幅检查是否有长度约束明确写“不超过 X 字”或“只输出要点”5.2 三个我踩过的深坑第一个坑过度依赖单一模型。我早期所有 Skill 都绑死一个模型结果那个模型一更新好几个 Skill 效果直接崩了。后来我改成模型可配置每个 Skill 声明自己需要什么能力比如“需要长上下文”“需要强推理”运行时按能力匹配模型。这样换模型时只需要改配置不用动 Skill 逻辑。第二个坑Prompt 里塞了太多“以防万一”的约束。我一度觉得约束越多越保险结果模型被一堆限制搞得畏手畏脚输出变得又短又保守。后来我狠心砍掉一半约束只留真正关键的效果反而好了。约束是用来兜底的不是用来炫技的。第三个坑没有做失败重试。模型调用偶尔会失败网络会抖动这些都很正常。但我早期的工作台一失败就整个流程中断得从头再来。后来加了重试机制单步失败自动重试两到三次成功率立刻上了一个台阶。重试时记得稍微调整参数比如提高一点随机性避免同样的输入反复触发同样的失败。5.3 让工作台越用越顺的几个习惯最后分享几个我坚持了很久的习惯它们让我的工作台越用越顺手。每周花半小时复盘产出记录。看看这周哪些 Prompt 效果好、哪些 Skill 用得频繁、哪些环节经常出问题。不用大改就做微调。积少成多一个月后你会明显感觉到顺畅。新 Skill 先小范围试跑。别一上来就接入主流程先拿几个典型样本跑一跑确认稳定了再正式用。我一般要求新 Skill 连续跑通十次不出错才让它进主流程。Prompt 改动留痕。前面说过的变更记录一定要坚持写。哪怕只写一行“调整了输出格式”也比什么都不写强。这是给未来的自己省事。定期清理。用不上的 Skill、过时的 Prompt、几个月没碰的配置该删就删。工作台不是越复杂越好保持精简才能保持可控。这套工作台我从最初的手忙脚乱到现在基本能稳定支撑日常的内容处理、代码辅助和文档分析前后迭代了大概七八个版本。最大的体会是别追求一步到位先跑起来再慢慢打磨。骨架复制过来先用最简的方式跑通一个场景然后在这个基础上一点点加东西。你会发现真正难的不是搭建而是坚持用、坚持改。那些看起来“直接复制就能用”的方案背后都是别人反复打磨的结果你复制的是骨架血肉还得自己长。
别再从零搭AI工作台：可复制骨架与Prompt/Skill编排实战
1. 为什么我劝你别再从零搭 AI 工作台先说结论过去大半年我前后帮三个团队、两个独立开发者朋友搭过所谓的“AI 创作工作台”从最原始的 API 调用一路折腾到带 Skill 编排、Prompt 模板库、多模型路由的完整形态。踩过的坑足够写一本小册子。所以当我看到“不用从零搭建这套 AI 创作工作台可以直接复制”这个说法时第一反应是——这话说得太对了但前提是你得知道“复制”的到底是什么。很多人对 AI 工作台的理解还停留在“装个客户端、填个 API Key、能聊天就行”。这顶多叫“AI 聊天入口”离“工作台”差着十万八千里。真正的工作台核心不在于模型本身而在于模型外面那一层Prompt 怎么组织、Skill 怎么编排、上下文怎么管理、输出怎么沉淀。这四件事才是决定你效率上限的东西模型只是发动机工作台是整台车。我见过太多人一上来就想着“我要自己写一套”结果两周过去还在调 UI 布局核心的 Prompt 工程和 Skill 逻辑一行没动。这就是典型的把力气用错了地方。一套成熟的 AI 创作工作台它的价值 80% 在“编排层”20% 才在“界面层”。而编排层这东西是完全可以复制、可以迁移、可以拿来就用的。这篇文章我想聊的就是一套可以直接复制的 AI 创作工作台它的骨架长什么样每个模块为什么这么设计Skill 和 Prompt 到底怎么配合以及我在实际搭建和使用过程中总结出来的那些“文档里不会写”的经验。适合两类人看一类是想快速拥有一套可用工作台、不想重复造轮子的实践派另一类是已经有一堆零散工具、但始终没串成体系、效率上不去的进阶用户。不管你是写代码的、做内容的、还是搞测试和数据分析的这套思路都能直接套。2. 一套可复制工作台的骨架拆解2.1 工作台的四层结构从入口到沉淀我习惯把 AI 创作工作台拆成四层从下往上分别是模型接入层、Prompt 编排层、Skill 执行层、产出沉淀层。这个分层不是为了好看而是为了让你在“复制”别人方案的时候能清楚地知道哪一层可以直接抄、哪一层必须按自己的需求改。模型接入层是最底层的负责对接各家大模型。这一层的关键不是“支持多少模型”而是统一接口。我见过有人给每个模型写一套调用逻辑结果换个模型就要改一遍代码维护成本爆炸。正确做法是抽象出一个统一的调用协议把不同模型的参数差异比如 temperature 的取值范围、system prompt 的支持情况、流式输出的格式在适配器里消化掉上层完全无感。Prompt 编排层是整套工作台的灵魂。它管的是“什么场景用什么提示词、提示词怎么组合、变量怎么注入”。这一层做得好你会发现同一个模型出来的效果能差出一倍。我自己的做法是把 Prompt 拆成角色定义、任务描述、约束条件、输出格式四个可复用片段用的时候像搭积木一样拼。这样改一个片段所有用到它的场景全部生效。Skill 执行层是最近半年最热的部分。所谓 Skill本质上是“把一段固定的能力封装成可调用的单元”。比如“读取本地文档并总结”是一个 Skill“把中文翻译成英文并保持术语一致”是一个 Skill“根据需求生成测试用例”也是一个 Skill。Skill 和 Prompt 的区别在于Prompt 是“告诉模型怎么做”Skill 是“把做这件事的完整流程固化下来”包括调用哪些工具、传什么参数、结果怎么处理。产出沉淀层最容易被忽略但恰恰是拉开差距的地方。大部分人用完 AI 就把结果复制走了下次要用又得重新生成。而一套好的工作台会把每次的输入、输出、用到的 Prompt 和 Skill 都记录下来形成可检索、可复用的知识库。时间一长这个库本身就是你最值钱的资产。2.2 为什么“复制”比“自建”更划算这里我要说一个可能有点反直觉的观点对于 90% 的人来说自建 AI 工作台的投入产出比是负的。算笔账。自建一套能用的工作台你需要设计数据结构、写模型适配、做 Prompt 管理界面、实现 Skill 编排引擎、处理上下文截断、做错误重试、搞日志记录……就算你技术很熟保守估计也要两三周的全职投入。而这两三周里你本来可以用现成方案产出多少东西更关键的是自建的东西往往“只有你自己会用”。一旦你想分享给同事、或者团队里换个人接手对方看不懂你的设计思路维护成本立刻飙升。而一套设计良好的可复制工作台它的结构是通用的、文档是完整的、别人拿来就能上手。所以我的建议是骨架直接复制血肉按需替换。骨架指的是分层结构、Skill 的组织方式、Prompt 的模板机制血肉指的是你具体业务场景里的那些提示词和流程。骨架是通用的血肉是个性化的。把骨架抄过来你省下的时间足够你把血肉打磨得非常精细。2.3 复制前必须想清楚的三件事不过在动手复制之前有三件事必须先想清楚否则抄过来也是白搭。第一你的核心场景是什么。工作台是服务于场景的不是反过来。如果你主要做内容创作那 Prompt 编排层和产出沉淀层是重点如果你主要做代码辅助那 Skill 执行层和模型接入层更关键。别想着做一个“什么都能干”的万能工作台那种东西最后往往什么都干不好。第二你的输入输出形态是什么。是纯文本对话还是要处理文件、图片、表格是单轮问答还是多轮迭代这决定了你的上下文管理策略。我见过有人抄了一套为长文档设计的工作台结果自己天天用的是短对话那套复杂的分块检索逻辑纯属累赘。第三你打算投入多少维护精力。工作台不是搭完就完事的模型会更新、Prompt 会迭代、Skill 会增删。如果你只想“搭好就不管”那就选最简结构如果你愿意持续打磨那可以上更复杂的编排。3. Prompt 与 Skill 的配合机制3.1 Prompt 不是越长越好而是要“结构化”关于 Prompt网上流传着大量“万能提示词模板”动辄几百上千字。我实测下来长 Prompt 的效果提升是有天花板的而且很容易触发模型的“注意力稀释”——你写了二十条约束模型可能只记住了前五条。真正有效的做法是结构化。我自己的 Prompt 模板固定包含四块角色一句话说清“你是谁、你擅长什么”。比如“你是一位有十年经验的测试工程师”。任务明确这次要做什么动词开头。比如“根据以下需求文档生成测试用例”。约束只写真正关键的 3 到 5 条。比如“用例要覆盖边界值”“每条用例包含前置条件和预期结果”。输出格式给出明确的格式要求最好带一个示例。比如“用 Markdown 表格输出列为用例编号、场景、步骤、预期结果”。这四块加起来通常不超过 300 字但效果比那些千字长文稳定得多。原因很简单结构化的信息模型更容易解析关键约束不会被淹没。提示约束条件宁少勿多。如果你发现某条约束模型总是忽略与其反复强调不如把它挪到 Skill 层用代码去校验。3.2 Skill 的本质把“流程”固化下来很多人把 Skill 和 Prompt 混为一谈其实两者定位完全不同。Prompt 解决的是“这一次怎么做”Skill 解决的是“这一类事怎么做”。举个例子。你要做“把一篇中文技术文章翻译成英文”。用 Prompt 的话你每次都要写“你是翻译专家请把以下内容翻译成英文保持术语一致不要意译……”而用 Skill 的话你把这套逻辑封装一次以后只需要传入文章内容Skill 自动完成调用翻译 Prompt、检查术语表、处理长文分块、合并结果、做格式校验。Skill 的价值在于可复用和可组合。一个成熟的 Skill 库应该像乐高积木一样能拼出各种复杂流程。比如“文档总结 Skill”加上“翻译 Skill”加上“格式转换 Skill”就能拼出一个“外文文档自动摘要”的完整流程。我自己的 Skill 库现在有二十多个常用的就那么七八个。这里有个经验Skill 不要贪多要贪“稳”。一个 Skill 如果十次里有两次出错那它带来的麻烦比省下的时间还多。宁可只保留那些经过反复验证、成功率 95% 以上的 Skill。3.3 两者如何配合一个真实场景的拆解光说理论没意思我拿一个真实场景拆给你看。场景我需要定期把一批英文技术文档读一遍提炼出要点整理成中文周报。拆解下来是这样配合的第一步文档读取 Skill负责把文档从各种格式PDF、Markdown、网页里抽出来统一成纯文本。这一步是纯工程活不需要模型。第二步分块总结 Prompt负责对每个文本块做摘要。这里 Prompt 的角色是“资深技术编辑”任务是“提炼这段内容的核心观点”约束是“保留关键数据和结论去掉举例和铺垫”输出格式是“三到五条要点”。第三步要点合并 Skill负责把各块的摘要去重、合并、按主题归类。这一步又用到一个 Prompt角色是“信息架构师”任务是把零散要点组织成有逻辑的结构。第四步中文润色 Prompt负责把合并后的内容改写成通顺的中文周报约束是“保持专业术语准确语气客观”。你看整个流程里Skill 负责“搬运和调度”Prompt 负责“每个环节的具体判断”。两者各司其职缺一不可。如果全用 Prompt你会写一个巨长无比的提示词效果还不稳定如果全用 Skill那每个 Skill 内部还是得靠 Prompt 来做判断。所以正确的姿势是Skill 搭骨架Prompt 填血肉。4. 从复制到跑通完整落地流程4.1 环境与依赖准备落地第一步是把环境搭起来。这里我不推荐具体的商业产品只讲通用的准备思路你按自己的技术栈对号入座。核心依赖其实就三样一个能调用模型的运行时、一个存 Prompt 和 Skill 配置的地方、一个记录产出的地方。运行时可以是本地脚本也可以是轻量服务配置存储用文件、数据库都行初期我建议直接用 Markdown 或 YAML 文件改起来直观产出记录用最简单的目录结构加命名规范就能起步。我自己的目录结构是这样的workspace/ prompts/ # 所有 Prompt 模板一个场景一个文件 skills/ # 所有 Skill 定义 outputs/ # 产出记录按日期分目录 config/ # 模型配置、密钥管理 logs/ # 运行日志这个结构的好处是所见即所得。你想改哪个 Prompt直接打开对应文件想加一个 Skill新建一个文件就行。不需要任何管理界面用 Git 管起来还能追溯每次改动。注意密钥千万别硬编码在代码里也别提交到版本库。用环境变量或者独立的配置文件并且把配置文件加进忽略列表。这个坑我见过太多人踩。4.2 把 Prompt 模板化参数注入与版本管理环境好了之后第一件事是把你的 Prompt 模板化。所谓模板化就是把 Prompt 里会变的部分抽成变量用占位符表示。比如一个翻译 Prompt 模板长这样# 角色 你是一位专业的技术文档翻译精通中英双语。 # 任务 把下面的内容翻译成{{target_lang}}。 # 约束 - 保持专业术语与术语表一致{{glossary}} - 不要增删原文信息 - 代码块和专有名词保持原样 # 输出格式 直接输出译文不要加任何说明。 # 待翻译内容 {{content}}用的时候把target_lang、glossary、content三个变量填进去就行。这样做的好处是同一个模板能服务无数个具体任务而且改模板时所有调用点自动生效。版本管理这块我要多说一句。Prompt 是会不断迭代的今天觉得好用的写法下周可能就发现有问题。所以每次改动都要记录改了什么、为什么改、改完效果如何。我习惯在 Prompt 文件顶部加一个简单的变更记录!-- v3 2024-06-10 增加术语表约束解决术语不一致问题 v2 2024-06-05 调整输出格式去掉多余说明 v1 2024-06-01 初版 --别小看这几行注释等你三个月后回头看能省下大量“我当时为什么这么写”的困惑。4.3 Skill 的编排串行、并行与条件分支Skill 编排是整套工作台里最有技术含量的部分。我把它归纳成三种基本模式几乎所有复杂流程都能用这三种模式组合出来。串行最简单就是 A 做完做 BB 做完做 C。比如“读取文档 → 总结 → 翻译 → 输出”一条线走到底。串行的关键是每一步的输出格式要稳定否则下一步的输入就乱了。并行适合那些互不依赖的环节。比如你要同时用三个不同角度分析同一段文本就可以并行跑三个 Skill最后汇总。并行能大幅缩短总耗时但要注意结果合并时的冲突处理。条件分支是进阶玩法。比如“如果文档超过一万字就走分块总结流程否则直接总结”。这种逻辑用代码判断一下就行不需要模型参与。我实际用下来80% 的场景用串行就够了剩下 20% 里大部分是并行条件分支用得很少。新手容易一上来就设计特别复杂的编排结果调试起来痛不欲生。我的建议是先用最简单的串行跑通遇到瓶颈再优化。4.4 上下文管理长对话与长文档的处理上下文管理是很多人忽略、但实际最影响体验的环节。模型有上下文长度限制超了就得截断截断策略直接决定效果。对于长对话我的策略是“滑动窗口 关键信息锚定”。保留最近 N 轮对话同时把对话早期出现的关键信息比如用户设定的角色、核心需求单独提取出来每次都带上。这样既控制了长度又不会丢失重要背景。对于长文档策略是“分块 分层总结”。先把文档切成合适大小的块每块单独总结再把总结合并。这里有个细节分块时要在边界处留重叠否则跨块的信息会被切断。我一般留 10% 到 15% 的重叠。提示分块大小不是越小越好。块太小会导致总结碎片化块太大又超出限制。我的经验值是每块 2000 到 4000 字具体看文档的信息密度。4.5 产出沉淀让每次使用都变成资产最后一步是产出沉淀这是把“一次性使用”变成“持续积累”的关键。我的做法是每次运行工作台自动在outputs/下按日期建目录把输入、用到的 Prompt 和 Skill、输出结果、耗时、模型信息全部记下来。文件名用“场景_时间戳”的格式方便检索。时间一长这个目录就成了我自己的知识库。想找之前处理过的类似内容直接搜关键词就行想复盘某个 Prompt 的效果翻记录一目了然。更重要的是这些记录本身就是优化工作台的依据——哪些 Prompt 经常被改、哪些 Skill 出错率高数据摆在那里一目了然。5. 实操中踩过的坑与排查技巧5.1 常见问题速查表下面这张表是我和朋友们实际遇到过的典型问题按出现频率排序附上排查思路。问题现象可能原因排查方向解决思路输出格式忽好忽坏Prompt 约束不够明确检查输出格式部分是否有示例加一个具体的输出示例比十条文字约束都管用长文档总结丢信息分块边界切断内容检查分块是否有重叠增加 10% 到 15% 的重叠区Skill 偶尔报错输入格式不符合预期检查上一步输出是否稳定在 Skill 入口加格式校验不合格就报错而不是硬跑术语翻译不一致术语表没生效检查术语表是否真的传进去了把术语表放在 Prompt 靠前位置别放最后响应特别慢上下文太长或并行度不够看日志里的 token 数和耗时精简上下文能并行的环节并行结果重复啰嗦约束里没限制篇幅检查是否有长度约束明确写“不超过 X 字”或“只输出要点”5.2 三个我踩过的深坑第一个坑过度依赖单一模型。我早期所有 Skill 都绑死一个模型结果那个模型一更新好几个 Skill 效果直接崩了。后来我改成模型可配置每个 Skill 声明自己需要什么能力比如“需要长上下文”“需要强推理”运行时按能力匹配模型。这样换模型时只需要改配置不用动 Skill 逻辑。第二个坑Prompt 里塞了太多“以防万一”的约束。我一度觉得约束越多越保险结果模型被一堆限制搞得畏手畏脚输出变得又短又保守。后来我狠心砍掉一半约束只留真正关键的效果反而好了。约束是用来兜底的不是用来炫技的。第三个坑没有做失败重试。模型调用偶尔会失败网络会抖动这些都很正常。但我早期的工作台一失败就整个流程中断得从头再来。后来加了重试机制单步失败自动重试两到三次成功率立刻上了一个台阶。重试时记得稍微调整参数比如提高一点随机性避免同样的输入反复触发同样的失败。5.3 让工作台越用越顺的几个习惯最后分享几个我坚持了很久的习惯它们让我的工作台越用越顺手。每周花半小时复盘产出记录。看看这周哪些 Prompt 效果好、哪些 Skill 用得频繁、哪些环节经常出问题。不用大改就做微调。积少成多一个月后你会明显感觉到顺畅。新 Skill 先小范围试跑。别一上来就接入主流程先拿几个典型样本跑一跑确认稳定了再正式用。我一般要求新 Skill 连续跑通十次不出错才让它进主流程。Prompt 改动留痕。前面说过的变更记录一定要坚持写。哪怕只写一行“调整了输出格式”也比什么都不写强。这是给未来的自己省事。定期清理。用不上的 Skill、过时的 Prompt、几个月没碰的配置该删就删。工作台不是越复杂越好保持精简才能保持可控。这套工作台我从最初的手忙脚乱到现在基本能稳定支撑日常的内容处理、代码辅助和文档分析前后迭代了大概七八个版本。最大的体会是别追求一步到位先跑起来再慢慢打磨。骨架复制过来先用最简的方式跑通一个场景然后在这个基础上一点点加东西。你会发现真正难的不是搭建而是坚持用、坚持改。那些看起来“直接复制就能用”的方案背后都是别人反复打磨的结果你复制的是骨架血肉还得自己长。
