企业官网建设流程全解析

我搭建了一个公文写作AI提示词聚合平台。先别笑，这个名字听起来像是一个正儿八经的科技项目，但按项目实际的样子来说，它就是一个专门收集、整理、优化“公文写作提示词”的网页工具，把散落在聊天记录、收藏夹、各部门同事手机里的AI写作模板，集中到一个能搜、能复制、能按变量替换的平台上。做这个事的起因很简单：单位里越来越多人用大模型写材料，但大家真正缺的并不是“会用AI”，而是“会问AI”——同样一个通知，会写提示词的人一分钟能拿到能直接改的稿子，不会写的人折腾半小时，拿到一篇“正确的空话”。这个平台就是用来解决这个问题的。

这篇内容我打算从为什么做、怎么设计、怎么落地、遇到什么坑，一路讲到目前我在维护中的真实体会，希望能给同样想做“垂直领域提示词库”的朋友一些参考。

1. 项目背景：写材料的人需要什么样的AI助手

1.1 先说说我为什么要搭这个平台

我在单位里主要负责综合文字工作，日常打交道最多的就是通知、函、会议纪要、工作总结、情况报告这类文种。过去两三年，AI写作工具陆续进入办公室，一开始大家觉得“这事稳了，以后写材料只要复制粘贴就行”。但实际用下来，骂声远多于掌声。

核心矛盾是：通用大模型很聪明，但它不懂单位的“语言习惯”。比如我让它写一份会议纪要，它确实能写出“会议认为”“会议强调”这类话，但经常漏掉最关键的信息，比如会议时间写得不完整、出席人范围写得模糊、主持人没写、最后落款也没有。再比如写请示，AI经常写得像散文，缺少“妥否，请批示”这类规范结尾。

问题的根子不在AI，而在提示词。单位同事用大模型的方式五花八门，有人一句“帮我写个开会通知”就发出去了，有人只会复制网上的“万能提示词”。相比之下，有经验的文字骨干会提前把文种、格式、语气、字数、材料背景、输出格式都说明白，给AI的上下文越具体，结果越接近能用。

我一开始只是自己整理了一批“用得顺手”的提示词，存在本地文档里。后来几个部门的同事听说后都来要，有人干脆直接坐到我电脑前，说“你帮我写一份关于某某事项的通知，用你那个模板跑一遍”。我从这些零散请求里意识到一个共性问题：大家缺的不是写作能力，甚至不是提示词本身，而是一个能让他们在几秒钟内拿到“标准提问方式”的工具。

于是我就有了一个想法：不如把这些提示词集中到一个平台上，按文种分类，配好变量，谁要写什么材料，打开页面，填几个空，复制完整提示词，丢给对话式AI产品，出来的结果马上就能用。

1.2 平台要解决的三个具体问题

我梳理了当时大家最常抱怨的三件事，这三个问题后来就成了产品设计的功能支点。

第一，提示词太分散。有人存在微信收藏里，有人记在备忘录里，有人直接在聊天记录里翻。真到写材料的时候，找到一个能用的模板全靠运气。平台首先要把散落的信息集中起来。

第二，提示词水平参差不齐。网上的所谓公文提示词，大量是“你是一名资深文秘，请帮我写一份通知”这种一句话万能式写法。这种提示词不能说完全没用，但基本谈不上质量，因为它既没约束结构，也没定义语气，更没给出格式。平台需要做质量过滤，只收录能真正产出规范文字的模板。

第三，提示词不接地气。很多模板明明写的是“政务公文”，实际用起来却是营销号文风，动不动就是“赋能”“抓手”“闭环”，AI产出的内容看着很热闹，往单位的正式材料里一放，立刻露馅。平台收录的提示词必须经过真实材料场景检验。

这个项目最终服务两类人：第一类是办公室、综合部、宣传部这类常年和文字打交道的人，他们需要“按文种找提示词”；第二类是对提示词工程有点兴趣的开发者和研究者，他们可以从我的分类逻辑、变量设计和使用数据里，看到“垂直提示词库”这个东西的搭建思路。

2. 核心设计思路：让提示词也“建章立制”

2.1 提示词分类体系怎么设计

做聚合平台，第一个绕不开的问题就是：提示词怎么分类。

一开始我偷懒，按“通知类”“总结类”“会议类”这么粗分。用了几天发现不行，因为一个“总结”和一个“汇报材料”，在格式和语气上差别很大，混在一起之后用户找不准。后来我调整成“文种优先、场景辅助”的思路，重新设计了一套分类维度。

分类体系分成三层：

• 第一层：文书大类。包括“通用法定公文”（通知、请示、报告、函、纪要等）、“事务文书”（工作计划、工作总结、述职报告、情况说明、简报等）、“写作辅助”（格式缩写、扩写、润色、降重、提炼小标题等）三类。
• 第二层：文种细分。比如通知下面再区分“会议通知”“事项通知”“转发性通知”；总结下面区分“年度工作总结”“季度工作汇报”“专项活动总结”。
• 第三层：场景标签。比如“简短版”“正式版”“有数据素材版”“领导汇报版”“快速草稿版”，方便用户按实际需要缩小范围。

这样设计背后是有逻辑的。公文属于强格式文本，每一种文种都有自己的结构惯性。写“请示”必须有一文一事的原则，写“函”要注重商洽语气，写“会议纪要”要保留会议要素。所以提示词的第一个维度必须是文种，而不是“字数”或者“风格”，文字工作者的第一反应永远是“我要写个什么文种”。

分类体系稳定之后，我又给每条提示词配了一组标准字段，包括：标题、适用场景、分类、标签、变量列表、模板正文、使用提示、参考案例、评分。这一步非常重要，因为纯靠人脑记不住几百条提示词各自的特点，字段化以后，后续的搜索、筛选、评分都有了数据基础。

2.2 一条好用的公文提示词长什么样

在平台里，提示词不等于“一句话的魔法咒语”，而是一套结构完整的输入模板。我自己总结了一条好用的公文提示词至少包含五个部分：角色、任务、背景、要求、输出格式。

举个实际例子，我在平台里收录了这么一条“会议通知”提示词：

请以{单位名称}办公室的名义，起草一份关于召开{会议主题}会议的通知。会议时间拟定为{会议时间}，地点为{会议地点}，参会人员为{参会人员}。

要求：

1. 结构完整：标题、主送单位、正文（依据、事项、要求）、落款齐全；
2. 语言庄重、简洁，使用规范公文用语；
3. 不写空话套话，凡未提供的具体信息统一写“另行通知”；
4. 正文字数控制在300字以内；
5. 结尾使用“特此通知”。

输出格式：标题居中，正文首行缩进两字符，落款单位名称与日期居右。

拆开看，这条提示词把最关键的信息全部前置了。“角色”是“单位办公室”，“任务”是开会通知，“背景”里给出了时间、地点、参会人员这些占位符，之后是明确的结构和语言要求。尤其最后一句输出格式，直接告诉大模型应该呈现的版式，这能省掉大量返工时间。

这里面有个非常实际的坑：如果只给AI“角色+任务”，它产出内容的自由度太大，会给你补一堆根本不存在的素材。比如它可能自己编一个“为保证会议质量，请各部门提前准备发言材料”——你本意只是通知大家开会，它却替你加戏。所以我在模板里专门加了“凡未提供的具体信息统一写另行通知”这条约束，把AI自由发挥的空间压到最小。

2.3 模板变量机制：提示词如何复用

如果平台只是堆一堆提示词文本，那用户每次复制之后还要手动改“单位名称”“会议时间”，效率提升有限。我在设计平台时就考虑：提示词必须支持“变量替换”。

具体做法是，在模板正文里用{单位名称}、{会议时间}这类占位符记录可变信息。用户在打开某条提示词时，页面会自动扫描这些占位符，动态生成一个表单。比如模板里有三个占位符，页面上就出现三个输入框。用户填完之后，系统把真实值替换回模板，最终生成一条可以直接复制给AI对话产品的完整提问。

这个机制的好处有两个。第一，用户不用理解提示词语法，只需要填内容。哪怕完全没接触过AI写作的小白，也能通过表单生成一条结构完整、约束清晰的提示词。第二，变量让模板的复用性大大提升，一条提示词可以在不同部门、不同场景之间共用，不会因为固化了具体信息而失效。

从实际操作角度看，变量也不是越多越好。我最早做的一条模板设置了8个变量，结果用户填起来很痛苦，而且AI拿到太多参数之后反而不知道重点在哪。后来我把大部分模板的变量控制在3到5个之间，把高频信息固化成下拉选项，把真正每次都会变化的内容，如主题、时间、地点、对象，保留为输入框。

3. 动手搭建：技术实现全过程

3.1 技术选型：纯前端加静态数据为什么够用

平台的技术方案，我在动手前做了很多比较。最开始想过用一套带后台的框架，把用户管理、权限、在线编辑都做进去，后来复盘需求时我给自己泼了盆冷水：这个平台的用户规模就是单位内部几十个人，数据量也就几百条提示词，最重要的场景是“打开就看、搜到就复制”。上一套完整后端，维护成本远远大于实际收益。

最后我选择了“纯前端加静态JSON数据”的架构。用一个HTML文件作为页面框架，一个CSS文件处理样式，一个JavaScript文件负责所有交互逻辑，数据全部放在一个JSON文件里。不接数据库，不需要登录系统，不依赖任何第三方服务。

这套方案的实际优势非常明显：

• 部署成本极低，任意静态托管服务都能跑，甚至拷到局域网共享文件夹里用浏览器打开也能跑。
• 内容更新方便，管理提示词就是编辑JSON文件，几分钟就能上线。
• 不会有大故障，页面挂了顶多是文件坏了，不存在“服务不可用”的问题。

有一句玩笑话说它“高级得像老年机”，但实际用下来非常踏实。对类似规模的内部工具，这种极简架构往往是性价比最高的。

3.2 数据模型与目录结构

平台的目录结构长这样：

project/ ├── index.html ├── style.css ├── app.js └── data/ └── prompts.json

核心数据模型的定义是这段开发中最关键的一步。我在prompts.json里为每一条提示词定义了一个完整对象，示例如下：

{ "id": "notice-meeting", "title": "会议通知（模板化）", "category": "official-doc", "categoryName": "法定公文/通知", "tags": ["会议", "通知", "通用"], "description": "适用于单位内部会议通知，可自动生成含会议主题、时间、地点、参会范围的规范通知", "variables": { "单位名称": "某单位办公室", "会议主题": "季度工作交流", "会议时间": "本周五下午2点", "会议地点": "三楼会议室", "参会人员": "各部门负责人" }, "template": "请以{单位名称}办公室的名义，起草一份关于召开{会议主题}会议的通知。……", "tips": "写清时间地点，避免AI补充超范围内容", "level": 3, "createdAt": "2025-01-12" }

这个JSON结构里的设计重点是variables字段。它既承担了展示作用，也承担了替换作用。页面渲染时，系统遍历这个对象，把键名生成输入框标签，把值当作默认值；用户提交时，系统再拿用户输入替换模板里的占位符。一个字段拆成两处使用，把代码量压缩了不少。

3.3 核心功能实现

平台的核心功能主要围绕四个动作：列表加载、搜索过滤、变量替换、一键复制。

列表加载用的是最朴素的fetch方式。页面启动时从data/prompts.json读取全部数据，然后渲染成卡片列表。核心代码如下：

fetch('data/prompts.json') .then(response => response.json()) .then(data => renderList(data)) .catch(error => console.error('数据加载失败：', error));

这里有个开发细节：如果直接用file://协议双击打开HTML文件，浏览器会阻止fetch读取本地JSON，最简单的解决办法是在本地起一个静态服务，或者把JSON数据直接嵌入到JavaScript文件里。对于单位内网这类没有现成服务的环境，我建议在发布时用一个简单的命令行工具起服务，或者干脆把所有数据写进app.js里。

搜索过滤功能的实现对数据质量要求很高。我允许用户在搜索框输入关键词，系统同时匹配标题、标签、描述和模板正文四个字段。这里有一个经验：搜索时不要只匹配标题，因为很多提示词的内容价值恰恰体现在模板正文里，用户可能记不住标题，但记得“上次那个写工作要点的模板”，正文里有“工作要点”几个字就能搜到。

变量替换功能的实现，是整个平台里最核心的一段逻辑。系统需要一个函数扫描模板里的占位符，并替换成用户填写的真实内容：

function fillTemplate(template, values) { return template.replace(/\{([^}]+)\}/g, (match, key) => values[key] || match); }

这段正则表达式会把所有形如{单位名称}的占位符找出来，然后去values对象里找对应的值。如果用户没填，就保留原占位符，避免生成内容里出现空字符串。

一键复制功能用浏览器原生的剪贴板接口实现：

async function copyText(text) { try { await navigator.clipboard.writeText(text); showToast('已复制到剪贴板'); } catch (err) { const textarea = document.createElement('textarea'); textarea.value = text; document.body.appendChild(textarea); textarea.select(); document.execCommand('copy'); document.body.removeChild(textarea); showToast('已复制到剪贴板'); } }

这段代码里我把降级方案也一并写了。现在多数浏览器都支持navigator.clipboard，但如果页面是在非安全上下文里运行（比如单位内网用IP访问），这个接口可能不可用。降级方案用临时textarea加老接口document.execCommand('copy')，虽然写法有点过时，但在内网环境里它就是最好用的方式。

本地状态管理我用了localStorage，记录两类信息：一是最近使用过的提示词，方便下次快速找回；二是用户手动标注过的收藏列表，让高频模板排在前面。这里没有用任何前端框架，代码量大约只有几百行，逻辑清晰，后续想加功能也不会被复杂的数据流绊住手脚。

3.4 部署与发布

平台本身是静态文件，发布方式就非常自由。我的做法是，在开发机上把三个核心文件加上data目录一起打包，放到一台内网服务器的静态服务目录下，然后让同事们通过浏览器访问。整个过程不需要数据库初始化，不需要环境配置，拷贝文件即完成部署。

如果想在外网环境使用，找一个支持静态托管的平台，把文件夹拖进去就完成了。甚至如果只是想自己用，放在电脑本地盘符里，配合一个随手起的轻量服务命令，也能跑起来。

部署过程中最容易踩的坑是路径问题。建议所有资源引用都使用相对路径，尤其是fetch('data/prompts.json')，不要写成绝对路径。因为同一个项目可能被部署在子目录、内网根目录、个人电脑文件夹等不同的位置，绝对路径会让所有资源加载全部失败。

4. 内容运营与质量控制

4.1 提示词入库标准

平台代码写好只算完成了一半，另外一半是内容维护。我见过很多类似的提示词工具，界面做得漂亮，但点开一看，提示词质量参差不齐，这类工具很快就没人用了。所以我在建设平台时定了一套“四个不收录”的入库标准。

第一，一句话万能式提示词不收录。比如“你是一个公文专家，帮我写一份通知”，这类提示词没有约束力，产出不稳定，留存价值低。第二，没有变量设计的提示词不收录。模板如果写死了某个具体场景，换个单位名就失效，复用性太差。第三，没有使用提示的提示词不收录。用户不但需要模板，还需要知道什么情况下用、用了以后怎么改，没有解释的提示词就是冰冷的文本。第四，来源不明的提示词不收录。从网络摘抄的所谓“公文提示词”，很多没有经过真实场景检验，收进平台只会拉低整体质量。

另外还有一条特殊约定：涉及具体单位、具体领导、具体项目信息的“一次性质材料模板”，也不直接入库。这类内容敏感性太强，不适合放在共享平台上，我会先把它脱敏，把具体信息全部改成占位符，再决定是否收录。

4.2 效果反馈与版本迭代

提示词不是写完就一劳永逸的。为了让平台里的模板越用越准，我给每条提示词设计了一个“使用效果”字段，记录最近一次被使用后AI产出结果的质量评价。每次用户点击复制，后台逻辑会在本地记录一次使用次数；每隔一段时间，我会主动询问几位使用频繁的同事，让他们反馈哪些模板效果好、哪些效果差，然后据此更新模板。

这里有一个我在实践中总结出的重要规律：提示词的优化方向，并不是“把模板写得更长”。很多人以为给AI的指令越详细越好，但实际用下来发现，写得过长之后，模型反而会丢失重点。优化提示词的正确方式，是把核心约束不断前置，把可有可无的背景说明往后挪。

比如最早一条年度工作总结的提示词里，我写了一长串关于“结合本单位实际”的背景描述。后来发现AI对这句话基本无感，无论背景写多长，产出的内容都一样空。于是我把这句话删掉，改成“请提供具体项目名称、关键数据、实际举措，未提供的信息按数据待补充处理”。这一改，AI自动减少编造内容的冲动，输出质量明显提升。

目前平台里收录了大约一百多条提示词，每个月会经历一轮“淘汰赛”。效果连续两次评分偏低，或者连续一个月使用次数为零的，我就把线索移到“待优化”名单里，逐条看是模板问题还是分类问题。这个运营动作，比再写一百条新提示词都重要。

5. 常见问题与排查实录

5.1 大模型写出来的东西千篇一律、套话连篇

这是最常见的抱怨，几乎每个用过AI写材料的人都遇到过。原因其实不难分析：如果你给AI的提示词只有“帮我写一份年度总结”这一句话，它只能从自己的知识库里去“猜”一份年度总结。因为训练数据里这类材料本来就是高度格式化的，所以它产出的内容自然全是正确的套话。

解决办法是在提示词里加入“反套话约束”，并且明确告诉AI“信息不足就标注待补充”。我在平台上的一条工作汇报提示词是这样写的：

请结合项目名称、目标任务、实施进度、存在问题等方面撰写季度工作汇报。要求：有明确的数据和事例，数据暂缺的位置用“数据待补充”标出；不使用空泛修饰语；每个板块不超过200字；若有未达预期的工作，可以不回避，直接写原因和整改方向。

这里的核心思路是“允许AI说没有数据，但不允许AI编数据”。加了这条约束之后，模型会倾向于输出更具体、更诚实的草稿，而不会为了凑篇幅生造素材。

5.2 同一套提示词在不同AI产品里效果波动大

不同的大模型产品对提示词的解析方式差异很大，这是大家经常会遇到的问题。我在单位里推广平台时，同事们有人用A产品，有人用B产品，还有人习惯让AI多个版本对比着看。结果同一套提示词，在不同的产品里产出的公文质量截然不同。

排查之后我发现，问题多数出在“要求”和“输出格式”没有被严格遵守。有些产品对指令的理解偏弱，需要把要求写得非常直白。比如“正文首行缩进两字符”这个要求，有些产品能理解并执行，有些产品根本不知道什么叫“首行缩进”。

我建议的做法是在平台里为提示词增加一个“兼容模式”。兼容模式下的模板会把所有排版要求，改为通用表述。例如不写“首行缩进两字符”，而是写“正文段落开头空两个字的位置”。同时明确告诉模型“请直接输出正文，不要额外解释”。这样在换产品使用时，提示词的粘合度会高很多。

5.3 平台上的提示词多了之后用户反而不会选

我一开始平台里只有二三十条提示词时，大家觉得好用，因为打开就能看到全部内容。后来扩充到一百多条，新问题出现了——用户站在搜索框前发呆，不知道该搜什么词。有些人甚至跟我抱怨“模板太多了，比翻聊天记录还累”。

这个问题的本质不是内容多，而是缺少“场景导览”。平台不能只有“搜索框”，还要有“新手引导”。我的做法是在首页增加一个“常用场景”模块，把使用频率最高的几条置顶，比如“快速生成会议通知”“写一份部门季度汇报”“把大白话改成规范表述”“给一段长材料提炼小标题”。用户点进去之后，系统直接带他进入对应的模板表单，所有操作都前置完成。

另外一个有效的思路是“按角色引导”。我调研过几位同事的提问方式，发现办公室同事问“要一个开会的通知”，而部门写材料的同事会问“要一个有紧迫感的提醒通知”。同一个文种，不同角色对语气的要求完全不同。于是我在分类页加了一个“使用角色”的筛选维度：起草人、审核人、转达人。选“审核人”，平台会优先展示包含格式检查清单的模板；选“转达人”，则优先展示语气正式、结构紧凑的通知类模板。

5.4 本地JSON数据更新后用户端缓存不刷新

这是一件特别容易栽跟头的小事。平台部署之后，我每次更新JSON里的提示词，都会在群里告诉同事们“刷新一下”。但现实中总有人不刷新，或者浏览器缓存了旧版本，导致他们看到的还是旧内容。

排查之后，我采用了最简单的缓存破除方案：给静态资源链接加上版本号查询参数。比如在引用app.js时，写成app.js?v=20250118。每次更新数据，就顺手改一下版本号。浏览器看到URL变化，就会重新请求资源，而不是沿用缓存。

同样的问题也可能出现在prompts.json上。如果用的是fetch加载JSON，可以在请求时手动加一个随机参数，或者用cache: 'no-store'告诉浏览器不要缓存。不过后者对局域网静态服务的支持不太稳定，我更推荐版本号方案，简单直接。

6. 写在最后：一点个人体会

平台从最初一个单机整理用的提示词文档，做到现在可以供一群人日常使用的聚合工具，我最大的感受是：提示词工程里最难的部分，不是写代码，也不是掌握某种魔法句式，而是对自己所在领域的业务逻辑有足够深的理解。公务员写作领域的提示词，本质上是对“好公文是什么样”的一次结构化表达。如果不懂会议通知的要素构成，不知道请示为什么要一文一事，不理解工作总结为什么要讲亮点也要讲问题，那再多的提示词模板也只是花架子。

我个人在实际维护这个平台的过程中，还有一个很深的体会：工具要做得“轻”，但维护要做得“重”。越简单的工具，它背后的内容标准、分类体系、反馈闭环越需要认真对待。平台代码几百行就够了，但让一条提示词从“能用”到“好用”，背后是我翻了大量实际材料、反复对比AI产出之后慢慢磨出来的。

如果你也想做类似的东西，我的建议是别急着上技术方案，先把你要聚合的领域拆清楚，把“什么样算一条好用的内容”定义出来，然后再用最简单的方式把信息流跑通。先把第一条提示词打磨到自己满意，再考虑要不要建一个平台。这个顺序反了，平台越大，维护压力越大。