企业官网建设流程全解析

这套 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 都放在独立的文件夹里，包含三个文件：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 怎么组织。

环境准备好之后，先建一个空文件夹，初始化 Git：

mkdir 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 = f"skills/{config['skill']}/skill.md" with open(skill_path, 'r') as f: skill_def = f.read() # 加载 Prompt prompts = [] for p in config['prompts']: with open(f"prompts/{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_ok=True) # 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 开始，慢慢把工作台养起来。