1. 为什么我决定不再从零搭工作台去年有段时间我连续接了三个内容项目每个项目都要重新配一遍提示词库、重新调一遍工作流、重新写一遍素材整理脚本。做到第三个项目的时候我盯着屏幕上那堆散落在不同文件夹里的 prompt 文件突然意识到一件事我花在“搭环境”上的时间已经快赶上真正做内容的时间了。这不是我一个人的问题。我观察过身边做 AI 内容的朋友大部分人的工作状态是这样的收藏夹里躺着几十篇“提示词大全”硬盘里存着七八个版本的“工作流模板”每次开始新项目还是从零开始拼。问题不在于他们不会用 AI而在于没有一个可以“直接复制”的工作台。所谓 AI 创作工作台说白了就是把提示词、技能模块、素材管线、输出模板这几样东西按照一套固定的目录结构和调用逻辑组织起来让下一个项目可以直接复用上一套骨架。它解决的不是“AI 能不能写”的问题而是“每次都要重新教 AI 怎么写”的问题。这套东西适合谁如果你每周至少用 AI 产出三篇以上内容或者你正在带一个小团队做批量内容又或者你只是单纯受够了每次都要重新写一遍系统提示词那这套工作台的思路对你就有用。它不需要你会写代码但需要你愿意花一个下午把结构搭好之后就是长期省时间。我接下来要拆的就是这套工作台从设计思路到落地实操的完整过程。包括目录怎么分、Skill 怎么切、Prompt 怎么管、IMA 这类知识库工具怎么接进来以及我在搭建过程中踩过的那些坑。2. 工作台的整体设计思路拆解2.1 核心逻辑把“一次性对话”变成“可复用资产”大部分人用 AI 的方式是对话式的打开对话框输入需求拿到结果关掉。下次再打开上下文没了之前调好的语气、格式、约束条件全部归零。这种用法在单次任务上没问题但一旦进入批量生产或者长期项目效率损耗非常惊人。工作台的核心逻辑就是把这套“一次性对话”变成“可复用资产”。具体来说就是把每次对话中那些稳定的部分——角色设定、输出格式、质量约束、领域知识——抽出来固化成文件下次直接调用。而变化的部分——具体选题、临时需求、特殊要求——才留给每次对话去输入。这个思路听起来简单但真正落地的时候大部分人卡在一个地方不知道该把什么固化下来什么该保持灵活。我的经验是凡是你在三次以上对话中重复输入过的内容都应该被固化。比如“你是一个资深科技编辑输出要口语化不要用首先其次最后”这种话如果你每次都在打那就该写进系统提示词里。2.2 目录结构设计三层分离原则我试过很多种目录组织方式最后稳定下来的是一套三层分离的结构第一层是角色层存放不同场景下的系统提示词比如“科技博主”“产品文案”“脚本策划”各一个文件。这一层解决的是“AI 是谁”的问题。第二层是技能层存放具体的操作模块比如“标题生成”“大纲扩写”“去 AI 味改写”“素材摘要”各一个文件。这一层解决的是“AI 会做什么”的问题。第三层是项目层每个具体项目一个文件夹里面放这个项目的素材、输出、临时提示词。这一层解决的是“这次做什么”的问题。三层分离的好处是角色层和技能层可以跨项目复用项目层保持独立不互相污染。我见过有人把所有 prompt 堆在一个文件夹里结果做 A 项目的时候不小心调用了 B 项目的提示词输出风格直接串了。2.3 为什么选择 Skill 化而不是 Prompt 堆叠这里要专门说一下 Skill 这个概念。早期我也是把所有东西都写成 prompt一个文件里塞几百行调用的时候整段贴进去。后来发现两个问题一是 token 消耗大二是维护困难改一个细节要翻半天。Skill 化的思路是把大 prompt 拆成小模块每个模块只负责一件事通过组合调用来完成复杂任务。比如“写一篇博文”这个任务可以拆成“生成标题候选”“生成大纲”“扩写段落”“去 AI 味”“格式检查”五个 Skill每个 Skill 单独维护需要的时候按顺序调用。这样做的好处很明显每个 Skill 可以独立迭代改“去 AI 味”的规则不会影响“生成大纲”的逻辑token 消耗更可控不需要每次都把全部规则塞进去复用性更强同一个“去 AI 味”Skill 可以用在博文、脚本、文案各种场景。注意Skill 拆分不是越细越好。我一开始拆了二十多个 Skill结果调用的时候光记顺序就记了半天。后来收敛到八个核心 Skill覆盖百分之九十的场景剩下的用临时 prompt 补充。2.4 IMA 这类知识库工具的接入位置IMA 是腾讯出的一款知识库工具核心能力是把你上传的文档、网页、笔记做成一个可检索的知识库然后 AI 可以基于这个知识库来回答问题。放到工作台里它解决的是“领域知识”这一层的问题。举个例子如果你做的是专利相关的内容那专利法条文、审查指南、常见驳回理由这些资料就可以全部丢进 IMA 建一个知识库。写相关内容的时候AI 先从这个知识库里检索相关条款再结合你的 Skill 模块生成内容准确率比纯靠模型记忆高很多。接入位置很明确IMA 负责“知道什么”Skill 负责“怎么做”角色层负责“以什么身份做”。三者配合才是一套完整的工作台。3. 核心模块的详细配置与实操要点3.1 角色层配置如何写出一个稳定的系统提示词角色层的文件我一般用 Markdown 写因为结构清晰AI 也容易解析。一个稳定的系统提示词包含五个部分身份定义一句话说清楚 AI 是谁服务什么场景。比如“你是一个有十年经验的科技内容编辑服务于一个面向开发者的技术社区”。能力边界明确哪些事能做哪些事不做。比如“你擅长把复杂技术概念用生活化类比解释但不编造具体数据遇到不确定的信息要标注”。输出风格语气、人称、句式偏好。比如“用从业者之间交流的口吻直接、不废话避免首先其次最后的八股结构”。格式约束标题层级、列表使用、代码块标注等。比如“二级标题必须带数字编号禁止使用 emoji”。质量红线绝对不能出现的内容。比如“禁止出现任何政治敏感、法律法规评论、历史事件评价”。这五个部分写下来大概三百到五百字不用太长关键是每条都要具体可执行。“输出要专业”这种话没用“输出中每个技术术语首次出现时用一句话解释”才有用。我自己的角色层文件命名习惯是“角色名-版本号.md”比如“tech-editor-v3.md”。每次调整都存一个新版本方便回滚。别小看版本管理我有次改了一版提示词输出质量突然下降翻了半天才发现是新加的一条约束和原有规则冲突了。3.2 Skill 模块拆分八个核心 Skill 的职责划分经过多次收敛我现在稳定使用八个核心 Skill。每个 Skill 是一个独立的 Markdown 文件里面包含这个 Skill 的触发条件、输入要求、处理逻辑、输出格式。Skill 1标题生成器。输入一个主题和三个关键词输出十个标题候选按吸引力排序。处理逻辑里写清楚标题的几种类型——悬念型、数字型、对比型、痛点型每种给两个示例。Skill 2大纲生成器。输入标题和核心观点输出三级大纲。约束条件是每个二级标题下至少两个三级标题每个三级标题标注预计字数。Skill 3段落扩写器。输入大纲节点和关键信息输出完整段落。这个 Skill 里要写清楚段落结构——观点句、解释句、案例句、过渡句以及每段的字数下限。Skill 4去 AI 味改写器。这是用得最多的一个。输入一段文字输出改写后的版本。处理逻辑包括替换模板化表达、打散过于整齐的句式、加入口语化连接词、删除归纳性总结句。Skill 5素材摘要器。输入一篇长文或一堆资料输出结构化摘要。输出格式固定为核心观点三条、关键数据若干、可引用案例两个。Skill 6格式检查器。输入一篇成稿检查标题编号、层级、列表使用、代码块标注是否符合规范输出问题清单。Skill 7关键词自然分布器。输入一篇文章和一组关键词检查关键词是否自然分布给出调整建议。这个 Skill 主要防止关键词堆砌。Skill 8多平台适配器。输入一篇成稿输出适配不同平台的版本。比如技术社区版保留代码块和表格生活社区版增加口语化表达职场社区版强化结论前置。这八个 Skill 覆盖了从选题到发布的完整链路。每个 Skill 文件控制在两百到四百字写清楚“什么时候用”“输入什么”“输出什么”“注意什么”四个问题就够了。3.3 Prompt 管理版本控制与调用规范Prompt 文件多了之后管理就成了问题。我的做法是三条规矩第一所有 prompt 文件用 Git 管理。对就是程序员用的那个 Git。每次修改提交一次写清楚改了什么、为什么改。这样出问题可以随时回滚也能看到迭代轨迹。第二命名规范统一。角色层用“role-角色名.md”技能层用“skill-技能名.md”项目层用“项目名/”文件夹。不要用中文文件名不要用空格不要用特殊符号。第三每个 prompt 文件头部写一个注释块包含创建日期、最后修改日期、适用场景、依赖的其他文件。这样拿到任何一个文件都知道它的来龙去脉。调用规范方面我习惯在项目层的入口文件里写清楚这个项目调用了哪些角色和技能按什么顺序调用。比如一个博文项目的入口文件可能写# 项目AI 工作台博文 ## 调用链 1. role-tech-editor-v3.md 2. skill-title-generator.md 3. skill-outline-generator.md 4. skill-paragraph-expander.md 5. skill-de-ai-rewriter.md 6. skill-format-checker.md这样每次打开项目照着调用链走一遍就行不用想下一步该用什么。3.4 IMA 知识库的建库与调用技巧IMA 建库的核心是资料质量。我试过把一堆网页直接丢进去结果检索出来的内容质量参差不齐反而干扰输出。后来总结出三条建库原则资料要经过筛选只放权威来源、经过验证的内容。宁可库小一点也不要塞垃圾进去。资料要结构化上传之前先整理成统一格式比如每篇文档都有标题、来源、日期、核心观点。IMA 对结构化内容的检索效果明显更好。资料要定期更新过时的内容及时删除或标注避免 AI 引用旧信息。调用的时候我一般在 Skill 里写清楚“先从知识库检索相关条目再基于检索结果生成内容”。这样 AI 不会凭空编造输出的内容有据可查。提示IMA 的知识库检索结果会作为上下文传给模型所以要注意 token 消耗。如果库很大建议在 Skill 里加一条“只检索最相关的三条结果”。4. 从零复制这套工作台的完整实操流程4.1 第一步搭建目录骨架找一个你习惯放项目的地方新建一个文件夹名字随意比如“ai-workbench”。在里面建三个子文件夹mkdir -p ai-workbench/roles mkdir -p ai-workbench/skills mkdir -p ai-workbench/projectsroles 放角色层文件skills 放技能层文件projects 放具体项目。然后在 ai-workbench 根目录下建一个 README.md写清楚这个工作台是干什么的、怎么用、有哪些模块。这个 README 是给你自己看的三个月后你忘了怎么用的时候翻出来看一眼就能想起来。接着在 projects 下面建第一个项目文件夹比如“demo-project”。项目文件夹里再建三个子文件夹input 放素材output 放产出temp 放临时文件。这个结构看起来简单但能有效防止文件混乱。4.2 第二步写第一个角色文件打开 roles 文件夹新建一个文件比如“role-general-editor.md”。内容按前面说的五个部分来写。我建议第一个角色文件不要写太复杂先把身份定义和输出风格写清楚能力边界和格式约束可以后面慢慢补。写完之后打开任意一个 AI 对话工具把这个文件的内容作为系统提示词贴进去然后随便问一个问题看看输出风格是否符合预期。如果不符合调整文件内容再试。这个调试过程可能要重复三五次但一旦调好后面所有项目都受益。我自己的经验是角色文件调好之后至少用一周再改。频繁修改会导致你对输出质量的判断失准今天觉得这个风格好明天觉得那个风格好最后哪个都不稳定。4.3 第三步拆出你的前三个 Skill不要一上来就拆八个。先拆三个最常用的标题生成、大纲生成、段落扩写。这三个 Skill 覆盖了内容生产最核心的环节先把它们跑通再考虑其他。每个 Skill 文件写四块内容触发条件、输入要求、处理逻辑、输出格式。触发条件写“当用户需要生成标题时使用”输入要求写“需要提供主题和至少两个关键词”处理逻辑写清楚步骤输出格式给一个示例。写完一个 Skill就在实际任务中试用一次。比如用标题生成 Skill 给一个真实选题生成十个标题看看质量如何。不满意就改 Skill 文件满意就继续下一个。4.4 第四步接入 IMA 知识库如果你做的是需要领域知识的项目这一步很关键。打开 IMA新建一个知识库把整理好的资料上传进去。上传完成后在 IMA 里测试几个问题看看检索结果是否准确。然后在你的 Skill 文件里加入知识库调用的说明。比如在段落扩写 Skill 里加一条“生成内容前先从 IMA 知识库检索相关条目基于检索结果生成不要编造。”这里有个实操细节IMA 的检索结果需要手动复制到对话里或者通过 API 接入。如果你用的是支持 API 的工具可以写一个简单的脚本自动完成检索和拼接。如果不想写代码手动复制也完全可以只是多一步操作。4.5 第五步跑通一个完整项目前面四步做完就可以跑一个完整项目了。选一个你最近要做的内容任务按照调用链走一遍打开角色文件贴入系统提示词。调用标题生成 Skill生成标题候选。选定标题调用大纲生成 Skill生成大纲。逐段调用段落扩写 Skill生成初稿。调用去 AI 味 Skill改写初稿。调用格式检查 Skill检查格式。输出到 output 文件夹。跑完一遍之后记录下哪些环节顺畅、哪些环节卡顿。卡顿的地方就是需要优化的 Skill。我第一遍跑的时候在“去 AI 味”环节卡了很久因为初稿的 AI 味太重改写工作量很大。后来我在段落扩写 Skill 里就加入了“避免模板化表达”的约束从源头减少 AI 味改写环节就轻松多了。4.6 第六步建立迭代机制工作台不是搭完就完了需要持续迭代。我的做法是每周花半小时做一次复盘这周哪些 Skill 用得多哪些没用上哪些输出质量不稳定需要调整有没有新的重复性任务可以做成新 Skill角色文件有没有需要更新的地方复盘之后改文件提交 Git写清楚改了什么。这个习惯坚持三个月你的工作台就会越来越贴合你的实际需求。5. 常见问题与排查技巧实录5.1 输出风格不稳定怎么办这是最常见的问题。同一个角色文件有时候输出很满意有时候完全跑偏。原因通常有三个第一角色文件写得太模糊。“输出要专业”这种话AI 理解不了。要改成具体的、可执行的约束比如“每个技术术语首次出现时用一句话解释解释不超过三十字”。第二对话历史污染。如果你在同一个对话里先聊了别的话题再切换到内容生产之前的上下文会影响输出。解决办法是每个任务开一个新对话或者用工具提供的“清除上下文”功能。第三模型本身的随机性。即使提示词完全一样不同次的输出也会有差异。这个没办法完全消除但可以通过降低 temperature 参数来减少波动。如果工具支持调参把 temperature 设在 0.3 到 0.5 之间比较稳。5.2 Skill 调用顺序错了会怎样会输出一堆看起来对但实际没用的东西。比如你先调用了段落扩写再调用大纲生成那扩写出来的段落就没有大纲约束结构会散。或者你先调用了去 AI 味再调用段落扩写那新扩写的部分又会带上 AI 味。解决办法很简单在项目入口文件里写清楚调用顺序每次照着走。我还会在 Skill 文件头部写一句“本 Skill 应在 XX 之后调用”防止自己搞错。5.3 知识库检索结果不相关怎么调IMA 的检索质量取决于资料质量和检索词。如果检索结果不相关先检查资料是不是太杂。把不相关的资料删掉或者给资料打上更细的标签。然后调整检索词。不要用太宽泛的词比如“专利”要用更具体的词比如“专利审查意见答复”。检索词越具体结果越相关。如果还是不行可以在 Skill 里加一条“如果检索结果不相关忽略检索结果基于通用知识生成但标注不确定”。这样至少不会输出错误信息。5.4 Token 消耗太快怎么优化Token 消耗主要来自三个地方角色文件太长、Skill 文件太长、知识库检索结果太多。优化方向对应三个角色文件控制在五百字以内只保留最核心的约束。Skill 文件控制在四百字以内处理逻辑用短句不用长段。知识库检索限制条数一般三条足够最多五条。另外不是每次调用都需要加载全部 Skill。只加载当前任务需要的 Skill其他不加载。我见过有人把所有 Skill 一次性贴进去token 消耗直接翻倍。5.5 常见问题速查表问题现象可能原因排查方法解决措施输出风格忽好忽坏角色文件模糊或上下文污染检查角色文件是否具体检查对话历史细化角色约束每个任务开新对话输出结构散乱Skill 调用顺序错误检查调用链是否按顺序执行按入口文件顺序重新调用知识库检索不相关资料杂或检索词宽泛检查资料质量和检索词清理资料用具体检索词Token 消耗过快文件太长或检索结果太多统计各文件字数和检索条数精简文件限制检索条数输出有 AI 味段落扩写 Skill 约束不足检查扩写 Skill 是否有去 AI 味约束在扩写环节加入口语化约束格式不符合要求格式检查 Skill 未调用检查是否执行了格式检查在调用链末尾加入格式检查5.6 几个我踩过的坑第一个坑一开始我把所有 Skill 写在一个大文件里结果改一个地方要翻半天还容易改错。后来拆成独立文件世界清净了。第二个坑我试过用中文文件名结果在某些工具里出现编码问题文件读不出来。后来全部改成英文命名再没出过问题。第三个坑有次我改角色文件的时候不小心删了一条关键约束导致接下来一周的输出全部跑偏。因为没做版本管理找不回旧版本只能重新写。从那以后所有文件都上 Git。第四个坑我一开始把知识库当万能药什么都往里塞结果检索出来的内容互相矛盾AI 输出也跟着矛盾。后来只放经过验证的权威资料问题就解决了。提示工作台搭建过程中最重要的不是一次搭得多完美而是先跑通一个最小可用版本然后在使用中持续迭代。我第一版工作台只有两个角色文件和三个 Skill但已经能覆盖大部分日常任务了。6. 工作台的扩展方向与长期维护6.1 从个人使用扩展到小团队协作如果你带一个小团队这套工作台可以直接扩展成团队协作版。做法是把 roles 和 skills 文件夹放到共享仓库里每个人都可以调用但只有指定的人有修改权限。项目层每个人独立互不干扰。团队版还需要加一个“变更日志”文件记录每次修改的内容、修改人、修改原因。这样出现问题时可以快速定位是哪次修改导致的。另外团队版建议加一个“审核 Skill”在输出最终稿之前自动检查是否符合团队规范。比如检查是否包含敏感词、是否符合格式要求、是否引用了未经验证的数据。6.2 定期清理与归档工作台用久了会积累很多不再使用的文件。我每季度做一次清理删除三个月内没有调用过的 Skill。归档已完成的项目文件夹移到 archive 目录。更新角色文件删除过时的约束加入新的经验。检查知识库删除过时资料补充新资料。清理的目的是保持工作台的精简和高效。一个塞满无用文件的工作台用起来比没有工作台还累。6.3 保持对新工具的敏感度AI 工具迭代很快每隔几个月就有新东西出来。我的做法是每个月花一个小时看看有什么新工具评估是否值得接入工作台。评估标准很简单能不能解决我现在的一个具体痛点如果能就试用一周如果确实好用就正式接入如果只是看起来酷就放弃。不要为了追新而追新。工作台的核心价值是稳定和复用频繁更换工具会破坏这种稳定性。我见过有人每个月换一套工具结果一年下来什么都没积累下来。6.4 最后分享一个小技巧如果你觉得从零搭工作台太麻烦可以先从“复制一个现成的”开始。找一个你认可的内容创作者看看他们分享的工作流直接拿过来用。用一段时间之后你自然会知道哪里需要改。改着改着这套工作台就变成你自己的了。我自己的第一版工作台就是从别人的模板改出来的。当时我连 Skill 是什么都不知道就是照着别人的目录结构建文件夹把别人的提示词改成自己的需求。用了两个月之后我才真正理解为什么要这样组织。所以如果你现在还在犹豫要不要开始我的建议是先复制再理解最后优化。别想着一步到位那只会让你永远开始不了。