这套 AI 创作工作台我从去年底开始折腾前后推倒重来过三版现在终于稳定跑起来了。它不是某个具体的软件而是一套把 Prompt、Skill、知识库和自动化流程串起来的组合方案。核心解决的问题就一个每次做新项目都要从零搭环境、写提示词、调工具链重复劳动太多。现在这套工作台可以直接复制到新项目里改改配置就能用。适合经常用 AI 做内容生产、代码辅助、资料整理的人不管你是刚接触 AI 工具的新手还是已经用过一段时间但觉得效率上不去的老手都能从这套方案里找到能直接抄的部分。1. 为什么大多数人搭的 AI 工作台最后都吃灰了我见过太多人兴致勃勃地搭了一套 AI 工作流用了不到两周就放弃了。问题基本都出在三个地方而且这三个问题往往是连锁反应。1.1 把工作台当成了工具收藏夹最常见的误区是把工作台理解成把好用的 AI 工具都装在一起。于是浏览器书签栏塞满了各种 AI 网站本地装了一堆客户端笔记软件里存了几百条 Prompt。结果真到要用的时候光是找上次那个写文案的提示词存在哪了就要花五分钟。这种做法的根本问题在于工具之间没有形成协作关系。每个工具都是孤岛你需要在它们之间手动搬运数据。搬运的过程消耗的精力往往比工具本身帮你省下的还多。我第二版工作台就犯了这个错。当时我装了六七个 AI 客户端每个都配了不同的模型和参数还专门建了一个表格来记录什么任务用什么工具。用了十天我就发现光是维护这张表格就让我不想打开它了。1.2 Prompt 散落在各处没有版本管理Prompt 是 AI 工作台的灵魂但大多数人对 Prompt 的管理方式极其随意。微信收藏里存几条备忘录里记几条聊天记录里翻几条。同一个任务今天写的提示词和上周写的可能完全不一样效果也参差不齐。更麻烦的是当你发现某个 Prompt 效果特别好时你很难回溯我到底改了哪个词让它变好的。没有版本对比就没有迭代优化的基础。我现在的做法是所有 Prompt 都放在一个统一的目录结构里用 Git 做版本管理。每次调整都提交一次效果变差就回滚效果变好就保留。这个习惯看起来麻烦但实际用下来它帮我省下了大量重新调试提示词的时间。1.3 忽略了 Skill 的封装价值Skill 这个词在这两年被提得很多但很多人对它的理解还停留在一个预设好的提示词模板。实际上一个完整的 Skill 应该包含四个部分触发条件、输入规范、处理逻辑、输出格式。举个例子我工作台里有一个周报生成的 Skill。它的触发条件是当我输入本周的工作记录时自动激活输入规范是需要包含日期、任务名称、完成状态、耗时这四个字段处理逻辑是按项目分组、按优先级排序、提取关键进展输出格式是Markdown 表格加一段总结。把这四部分封装好之后我每周只需要把零散的工作记录丢进去出来的就是可以直接发给团队的周报。如果只把它当成一个提示词模板每次还要手动整理输入格式那封装的价值就丢了一大半。很多人搭工作台失败不是因为工具不够好而是因为把搭建当成了终点。实际上搭建只是起点真正的价值在于持续使用和迭代。2. 这套工作台的骨架四层结构拆解我的工作台经过三次重构最终稳定在四层结构上。这四层从下到上分别是存储层、Prompt 层、Skill 层、编排层。每一层解决一个特定问题层与层之间通过约定好的接口通信。2.1 存储层所有资产的唯一真相来源存储层是整个工作台的地基。我用的方案很简单一个本地文件夹用 Git 管理里面按类别分目录。目录结构大概是这样ai-workbench/ ├── prompts/ # 所有提示词 │ ├── writing/ # 写作类 │ ├── coding/ # 编程类 │ ├── analysis/ # 分析类 │ └── misc/ # 其他 ├── skills/ # 封装好的 Skill │ ├── weekly-report/ │ ├── code-review/ │ └── doc-summary/ ├── knowledge/ # 知识库文件 │ ├── docs/ # 参考文档 │ └── examples/ # 示例库 ├── outputs/ # 生成结果存档 └── config/ # 配置文件这个结构看起来平平无奇但它解决了一个关键问题任何资产都有唯一的位置。我不会再花时间找那个提示词存哪了因为我知道写作类的提示词一定在prompts/writing/下面。用 Git 管理的好处是每次修改都有记录。我可以在任何时候对比这周和上周的提示词有什么不同也可以随时回滚到某个效果最好的版本。对于知识库文件Git 还能帮我追踪哪些参考资料是最近新增的。2.2 Prompt 层从随手写到工程化Prompt 层是工作台的核心生产力。我把 Prompt 分成三类来管理每类的写法和管理方式都不一样。第一类是一次性 Prompt用完就丢的那种。比如帮我把这段话翻译成英文这种不需要存。但如果我发现某个一次性 Prompt 效果特别好我会把它升级成第二类。第二类是可复用 Prompt有固定结构和变量占位符。比如我的文章摘要Prompt# 角色 你是一个专业的内容编辑擅长从长文中提取核心信息。 # 任务 从以下文章中提取摘要要求 - 保留核心论点和关键数据 - 删除重复表述和冗余修饰 - 输出长度控制在原文的 15% 以内 # 输入 {{article_content}} # 输出格式 ## 核心观点 列出 3-5 个核心观点 ## 关键数据 列出文中出现的重要数据这种 Prompt 的特点是结构固定、内容可变。我只需要替换{{article_content}}部分就能复用到不同文章上。第三类是组合 Prompt由多个可复用 Prompt 串联而成。比如深度分析报告这个组合 Prompt实际上调用了资料摘要、观点提取、逻辑梳理、报告撰写四个子 Prompt。每个子 Prompt 单独维护组合关系在编排层定义。2.3 Skill 层把重复劳动封装成可调用单元Skill 层是工作台从能用到好用的关键。一个 Skill 本质上是一个有明确输入输出契约的功能单元。我目前工作台里常驻的 Skill 有十几个举几个有代表性的Skill 名称触发场景输入输出周报生成每周五下午零散工作记录格式化周报代码审查提交 PR 前代码 diff审查意见列表文档摘要阅读长文档时文档全文结构化摘要会议纪要会议结束后录音转文字纪要待办竞品分析调研新领域时竞品列表对比分析表每个 Skill 都放在独立的文件夹里包含三个文件skill.md定义文件、examples/示例输入输出、config.json参数配置。以代码审查 Skill 为例它的skill.md大概长这样# Skill: 代码审查 ## 触发条件 当输入包含代码 diff 且标注为审查时激活。 ## 输入规范 - 代码 diff统一格式 - 项目技术栈说明 - 重点关注项可选 ## 处理逻辑 1. 识别变更类型新增/修改/删除 2. 检查常见问题命名、边界、异常处理 3. 评估对现有功能的影响 4. 按严重程度排序输出 ## 输出格式 ### 严重问题 - [文件:行号] 问题描述 修改建议 ### 建议改进 - [文件:行号] 问题描述 修改建议 ### 总体评价 一段话总结这个 Skill 封装好之后我每次审查代码只需要把 diff 丢进去出来的就是结构化的审查意见。不需要每次重新想我应该从哪些角度审查。2.4 编排层让各层协同工作的胶水编排层负责把存储层、Prompt 层、Skill 层串起来。我用的是一个简单的脚本系统核心逻辑就是读取配置 → 加载对应资源 → 执行 → 保存结果。编排层的关键设计是配置文件驱动。每个任务对应一个配置文件里面定义了用哪个 Skill、加载哪些 Prompt、输入从哪里来、输出到哪里去。比如周报生成的配置文件{ skill: weekly-report, prompts: [work-log-parser, report-formatter], input: { source: manual, format: text }, output: { path: outputs/weekly/, format: markdown } }这样设计的好处是新增任务不需要改代码只需要加配置文件。我想加一个月度总结的任务复制一份周报的配置改改 Skill 名称和输出路径就行了。3. 从零复制这套工作台的具体步骤前面讲的是结构这一部分讲怎么落地。我会按顺序给出每一步的操作你跟着做就能搭出一套能跑的工作台。3.1 环境准备只需要三样东西搭这套工作台不需要复杂的开发环境三样东西就够了一个文本编辑器VS Code 就行免费且插件丰富Git用于版本管理命令行或图形界面都可以一个 AI 对话入口网页版或客户端都行能稳定访问即可我特意没有把安装某个特定 AI 工具作为前置条件因为这套工作台的设计原则就是与具体工具解耦。你用什么 AI 工具不重要重要的是你的 Prompt 和 Skill 怎么组织。环境准备好之后先建一个空文件夹初始化 Gitmkdir ai-workbench cd ai-workbench git init然后按照 2.1 节的目录结构建好子文件夹。这一步花不了五分钟但它是后面所有工作的基础。3.2 迁移现有 Prompt先收集再分类如果你之前已经积累了一些 Prompt第一步是把它们全部收集到一个地方。微信收藏、备忘录、聊天记录里的都翻出来统一放到prompts/目录下。收集的时候不用管质量先全部丢进去。收集完之后再做分类和清理效果差的直接删掉效果一般的归到misc/目录效果好的按类别归到writing/、coding/、analysis/等目录分类的标准不是这个 Prompt 是干什么的而是我在什么场景下会用到它。比如一个改写句子的 Prompt如果主要用于写文章就归到writing/如果主要用于改代码注释就归到coding/。这一步的关键是建立索引习惯。我在prompts/目录下放了一个README.md里面列出了所有 Prompt 的清单和一句话说明。每次新增 Prompt 都更新这个清单。这样我找 Prompt 的时候先看清单不用一个个文件翻。3.3 封装第一个 Skill从最高频的任务开始不要一上来就封装十个 Skill那样你会被细节淹没。选一个你每周至少用三次的任务把它封装成第一个 Skill。我选的第一个 Skill 是文档摘要。因为我每天都要读大量资料手动整理摘要很耗时。封装过程分四步第一步记录当前的手动流程。我连续三天记录了自己做文档摘要时的每一步操作先通读一遍、划出重点、按主题分组、写成摘要、检查是否遗漏。这个记录让我发现我每次其实都在做同样的五件事。第二步把流程写成 Prompt。把上面五步转化成 AI 能理解的指令。注意要给出具体的输出格式要求不能只说帮我写个摘要。第三步准备示例。找三篇不同类型的文档手动做出摘要作为这个 Skill 的示例。示例的作用是让 AI 理解好的摘要长什么样。第四步测试和迭代。用十篇新文档测试这个 Skill记录哪些地方效果不好针对性调整 Prompt。我大概迭代了五轮摘要质量才稳定下来。封装好第一个 Skill 之后你会发现后面封装其他 Skill 的速度会快很多因为流程和格式都是现成的。3.4 建立编排脚本让重复任务一键执行编排脚本不需要多复杂一个简单的 Shell 脚本或 Python 脚本就够了。核心功能就三个读取配置、调用 AI、保存结果。我用 Python 写了一个大概五十行的脚本核心逻辑是import json import os def run_task(config_path): with open(config_path, r) as f: config json.load(f) # 加载 Skill 定义 skill_path fskills/{config[skill]}/skill.md with open(skill_path, r) as f: skill_def f.read() # 加载 Prompt prompts [] for p in config[prompts]: with open(fprompts/{p}.md, r) as f: prompts.append(f.read()) # 组装最终输入 final_input skill_def \n\n \n\n.join(prompts) # 这里调用你的 AI 接口 # result call_ai(final_input, user_input) # 保存结果 output_path config[output][path] os.makedirs(output_path, exist_okTrue) # save_result(result, output_path)这个脚本本身不复杂但它把找 Skill、找 Prompt、组装、保存这一串操作自动化了。以前我做完一个任务要手动复制粘贴好几次现在只需要运行一条命令。编排脚本的复杂度应该和你的任务复杂度匹配。如果你只有三五个任务手动操作可能比写脚本更快。脚本的价值在于任务数量多、执行频率高的时候。4. 让工作台真正跑起来的三个关键习惯搭好工作台只是第一步能不能持续用起来取决于三个习惯。这三个习惯我都是踩过坑之后才养成的。4.1 每次用完立刻归档我以前有个坏习惯用完 AI 生成的内容复制到目标位置就关掉了不保存原始输出。结果过了一周想参考上次那个方案是怎么写的完全找不到。现在的做法是所有 AI 输出都自动保存到outputs/目录按日期和任务类型分文件夹。比如outputs/2025-01-15/weekly-report.md。保存的时候顺手加一行注释说明这次用的哪个 Skill、哪个 Prompt、有什么特殊调整。这个习惯带来的好处是三个月后我回头看能清楚地知道哪些 Prompt 效果好、哪些需要改进。没有这个归档工作台就只是一个用完即走的工具积累不下任何东西。4.2 每周做一次 Prompt 复盘每周五花十五分钟把这周用过的 Prompt 过一遍。重点看三个问题哪些 Prompt 效果特别好能不能提炼成通用模板哪些 Prompt 效果不稳定问题出在哪个环节有没有新的重复任务能不能封装成新 Skill这个复盘习惯让我工作台里的 Skill 数量从最初的 1 个增长到现在的十几个而且每个都是真正高频使用的没有凑数的。4.3 保持工作台的可丢弃性这听起来有点反直觉但很重要不要让你的工作台变得不可替代。意思是如果某天你换了一个 AI 工具或者某个 Skill 突然不能用了你应该能快速迁移到新方案上。具体做法是所有 Skill 和 Prompt 都用纯文本格式存储不依赖任何特定平台的专有格式。编排脚本也尽量用通用语言写不绑定特定 API。这样即使底层工具换了上面的资产还能继续用。我第三版重构的时候就是把所有资产从某个特定平台迁移到了纯文本方案。迁移过程花了半天但之后再也没有被平台绑定过。5. 常见问题与排查思路这套工作台跑起来之后我遇到过不少问题。挑几个有代表性的说说排查思路。5.1 Prompt 效果不稳定同样的输入有时好有时坏这是最常见的问题。原因通常有三个一是 Prompt 本身有歧义AI 每次理解不一样二是输入内容格式不统一导致 AI 抓不住重点三是模型本身的随机性。排查顺序是先固定输入格式确保每次输入的结构完全一致然后检查 Prompt 里有没有模糊表述比如写得好一点这种主观要求改成具体的标准最后如果还是不稳定就在 Prompt 里加示例用具体例子告诉 AI 你要什么。我遇到过一个典型案例一个提取关键信息的 Prompt有时候提取五条有时候提取十条。后来发现是 Prompt 里写了提取关键信息但没定义关键的标准。改成提取包含数据或结论的句子最多八条之后输出就稳定了。5.2 Skill 之间互相干扰输出格式混乱这个问题通常出现在组合 Prompt 的场景。多个 Skill 串联时如果前一个 Skill 的输出格式和后一个 Skill 的输入要求不匹配就会出问题。解决办法是在 Skill 定义里明确输入输出契约。每个 Skill 的skill.md里都要写清楚我接受什么格式的输入和我输出什么格式的结果。组合的时候在编排层加一个格式转换步骤确保上一个的输出符合下一个的输入要求。5.3 工作台越搭越复杂维护成本超过收益这是最危险的问题。如果你发现维护工作台的时间超过了它帮你省下的时间说明你过度设计了。我的经验是工作台的复杂度应该和你的任务数量成正比。如果你只有三五个高频任务一个文件夹加几个 Prompt 就够了不需要 Skill 层和编排层。只有当任务数量超过十个且有很多重复操作时才值得投入时间做封装和自动化。我第一版工作台就是过度设计搞了复杂的目录结构和一堆用不上的 Skill结果维护起来比手动操作还累。后来砍掉了一半的功能只保留真正高频的部分效率反而提升了。5.4 换电脑或重装系统后工作台丢失这个问题的根源是没有做好版本管理和备份。我的做法是整个ai-workbench目录用 Git 管理同时推送到一个私有仓库。换电脑的时候git clone下来就能用。需要注意的是知识库文件可能比较大不适合全部放进 Git。我的做法是知识库文件单独备份Git 里只存一个索引文件记录每个知识库文件的位置和用途。6. 这套工作台还能怎么扩展工作台跑稳定之后我陆续加了一些扩展功能这里分享几个我觉得比较有价值的。6.1 接入自动化触发目前我的工作台还是手动触发的需要我主动运行脚本。下一步我打算接入一些自动化触发机制比如每周五下午五点自动生成周报草稿、检测到新文档时自动生成摘要。实现方式可以用系统的定时任务也可以用一些轻量的自动化工具。核心思路是把记得用工作台这个负担也去掉让工作台主动来找我而不是我去找它。6.2 建立 Prompt 效果评分机制我现在判断一个 Prompt 好不好主要靠主观感觉。下一步想做一个简单的评分机制每次用完 Prompt 后花五秒钟打个分1-5 分记录在文件里。积累一段时间后就能用数据说话知道哪些 Prompt 真正有效。这个机制的关键是评分要足够简单如果打分本身很麻烦就不会有人坚持。五秒钟能完成的操作才有可能持续。6.3 跨项目复用配置这套工作台目前是单项目的。如果同时做多个项目每个项目都要单独配置一套有点浪费。下一步想做一个基础配置 项目覆盖的机制基础配置放通用的 Prompt 和 Skill项目配置只放这个项目特有的部分。这样新项目启动的时候只需要写项目特有的配置通用的部分直接继承。能省下不少重复配置的时间。我在实际使用中发现这套工作台最大的价值不在于某个具体的 Prompt 或 Skill而在于它建立了一套可积累、可迭代、可迁移的工作方式。每次使用都在为下一次积累素材每次调整都在让系统变得更好用。如果你也在用 AI 做重复性的工作不妨试试这个思路从一个最小的 Skill 开始慢慢把工作台养起来。