我搭建了一个公文写作AI提示词聚合平台。先别笑这个名字听起来像是一个正儿八经的科技项目但按项目实际的样子来说它就是一个专门收集、整理、优化“公文写作提示词”的网页工具把散落在聊天记录、收藏夹、各部门同事手机里的AI写作模板集中到一个能搜、能复制、能按变量替换的平台上。做这个事的起因很简单单位里越来越多人用大模型写材料但大家真正缺的并不是“会用AI”而是“会问AI”——同样一个通知会写提示词的人一分钟能拿到能直接改的稿子不会写的人折腾半小时拿到一篇“正确的空话”。这个平台就是用来解决这个问题的。这篇内容我打算从为什么做、怎么设计、怎么落地、遇到什么坑一路讲到目前我在维护中的真实体会希望能给同样想做“垂直领域提示词库”的朋友一些参考。1. 项目背景写材料的人需要什么样的AI助手1.1 先说说我为什么要搭这个平台我在单位里主要负责综合文字工作日常打交道最多的就是通知、函、会议纪要、工作总结、情况报告这类文种。过去两三年AI写作工具陆续进入办公室一开始大家觉得“这事稳了以后写材料只要复制粘贴就行”。但实际用下来骂声远多于掌声。核心矛盾是通用大模型很聪明但它不懂单位的“语言习惯”。比如我让它写一份会议纪要它确实能写出“会议认为”“会议强调”这类话但经常漏掉最关键的信息比如会议时间写得不完整、出席人范围写得模糊、主持人没写、最后落款也没有。再比如写请示AI经常写得像散文缺少“妥否请批示”这类规范结尾。问题的根子不在AI而在提示词。单位同事用大模型的方式五花八门有人一句“帮我写个开会通知”就发出去了有人只会复制网上的“万能提示词”。相比之下有经验的文字骨干会提前把文种、格式、语气、字数、材料背景、输出格式都说明白给AI的上下文越具体结果越接近能用。我一开始只是自己整理了一批“用得顺手”的提示词存在本地文档里。后来几个部门的同事听说后都来要有人干脆直接坐到我电脑前说“你帮我写一份关于某某事项的通知用你那个模板跑一遍”。我从这些零散请求里意识到一个共性问题大家缺的不是写作能力甚至不是提示词本身而是一个能让他们在几秒钟内拿到“标准提问方式”的工具。于是我就有了一个想法不如把这些提示词集中到一个平台上按文种分类配好变量谁要写什么材料打开页面填几个空复制完整提示词丢给对话式AI产品出来的结果马上就能用。1.2 平台要解决的三个具体问题我梳理了当时大家最常抱怨的三件事这三个问题后来就成了产品设计的功能支点。第一提示词太分散。有人存在微信收藏里有人记在备忘录里有人直接在聊天记录里翻。真到写材料的时候找到一个能用的模板全靠运气。平台首先要把散落的信息集中起来。第二提示词水平参差不齐。网上的所谓公文提示词大量是“你是一名资深文秘请帮我写一份通知”这种一句话万能式写法。这种提示词不能说完全没用但基本谈不上质量因为它既没约束结构也没定义语气更没给出格式。平台需要做质量过滤只收录能真正产出规范文字的模板。第三提示词不接地气。很多模板明明写的是“政务公文”实际用起来却是营销号文风动不动就是“赋能”“抓手”“闭环”AI产出的内容看着很热闹往单位的正式材料里一放立刻露馅。平台收录的提示词必须经过真实材料场景检验。这个项目最终服务两类人第一类是办公室、综合部、宣传部这类常年和文字打交道的人他们需要“按文种找提示词”第二类是对提示词工程有点兴趣的开发者和研究者他们可以从我的分类逻辑、变量设计和使用数据里看到“垂直提示词库”这个东西的搭建思路。2. 核心设计思路让提示词也“建章立制”2.1 提示词分类体系怎么设计做聚合平台第一个绕不开的问题就是提示词怎么分类。一开始我偷懒按“通知类”“总结类”“会议类”这么粗分。用了几天发现不行因为一个“总结”和一个“汇报材料”在格式和语气上差别很大混在一起之后用户找不准。后来我调整成“文种优先、场景辅助”的思路重新设计了一套分类维度。分类体系分成三层第一层文书大类。包括“通用法定公文”通知、请示、报告、函、纪要等、“事务文书”工作计划、工作总结、述职报告、情况说明、简报等、“写作辅助”格式缩写、扩写、润色、降重、提炼小标题等三类。第二层文种细分。比如通知下面再区分“会议通知”“事项通知”“转发性通知”总结下面区分“年度工作总结”“季度工作汇报”“专项活动总结”。第三层场景标签。比如“简短版”“正式版”“有数据素材版”“领导汇报版”“快速草稿版”方便用户按实际需要缩小范围。这样设计背后是有逻辑的。公文属于强格式文本每一种文种都有自己的结构惯性。写“请示”必须有一文一事的原则写“函”要注重商洽语气写“会议纪要”要保留会议要素。所以提示词的第一个维度必须是文种而不是“字数”或者“风格”文字工作者的第一反应永远是“我要写个什么文种”。分类体系稳定之后我又给每条提示词配了一组标准字段包括标题、适用场景、分类、标签、变量列表、模板正文、使用提示、参考案例、评分。这一步非常重要因为纯靠人脑记不住几百条提示词各自的特点字段化以后后续的搜索、筛选、评分都有了数据基础。2.2 一条好用的公文提示词长什么样在平台里提示词不等于“一句话的魔法咒语”而是一套结构完整的输入模板。我自己总结了一条好用的公文提示词至少包含五个部分角色、任务、背景、要求、输出格式。举个实际例子我在平台里收录了这么一条“会议通知”提示词请以{单位名称}办公室的名义起草一份关于召开{会议主题}会议的通知。会议时间拟定为{会议时间}地点为{会议地点}参会人员为{参会人员}。要求结构完整标题、主送单位、正文依据、事项、要求、落款齐全语言庄重、简洁使用规范公文用语不写空话套话凡未提供的具体信息统一写“另行通知”正文字数控制在300字以内结尾使用“特此通知”。输出格式标题居中正文首行缩进两字符落款单位名称与日期居右。拆开看这条提示词把最关键的信息全部前置了。“角色”是“单位办公室”“任务”是开会通知“背景”里给出了时间、地点、参会人员这些占位符之后是明确的结构和语言要求。尤其最后一句输出格式直接告诉大模型应该呈现的版式这能省掉大量返工时间。这里面有个非常实际的坑如果只给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?v20250118。每次更新数据就顺手改一下版本号。浏览器看到URL变化就会重新请求资源而不是沿用缓存。同样的问题也可能出现在prompts.json上。如果用的是fetch加载JSON可以在请求时手动加一个随机参数或者用cache: no-store告诉浏览器不要缓存。不过后者对局域网静态服务的支持不太稳定我更推荐版本号方案简单直接。6. 写在最后一点个人体会平台从最初一个单机整理用的提示词文档做到现在可以供一群人日常使用的聚合工具我最大的感受是提示词工程里最难的部分不是写代码也不是掌握某种魔法句式而是对自己所在领域的业务逻辑有足够深的理解。公务员写作领域的提示词本质上是对“好公文是什么样”的一次结构化表达。如果不懂会议通知的要素构成不知道请示为什么要一文一事不理解工作总结为什么要讲亮点也要讲问题那再多的提示词模板也只是花架子。我个人在实际维护这个平台的过程中还有一个很深的体会工具要做得“轻”但维护要做得“重”。越简单的工具它背后的内容标准、分类体系、反馈闭环越需要认真对待。平台代码几百行就够了但让一条提示词从“能用”到“好用”背后是我翻了大量实际材料、反复对比AI产出之后慢慢磨出来的。如果你也想做类似的东西我的建议是别急着上技术方案先把你要聚合的领域拆清楚把“什么样算一条好用的内容”定义出来然后再用最简单的方式把信息流跑通。先把第一条提示词打磨到自己满意再考虑要不要建一个平台。这个顺序反了平台越大维护压力越大。