本文分为两篇,本篇为下:

上篇:发布 AI Share Card 插件,介绍使用效果和安装方式

下篇:解析 AI Share Card 插件的提示词设计与产品化过程,以及新的词生卡 Prompt 组织方法

前不久,我发布了一个好用的 AI 浏览器插件:AI Share Card。

利用 Cursor AI 进行编程,在不到 3 小时内便完成了核心功能的开发。(详见:《这款 AI 浏览器插件,想让你的网页链接分享更高级》

用户使用反馈也相当不错。

本文作为 AI Share Card 插件发布系列的下篇,将开源 AI 产品的提示词设计与产品化过程。通过分享实战经验,希望为有意开发 AI 工具的开发者提供参考。


🏃 初版提示词:纯 Prompt 快速验证效果

插件的 idea 其实来自早先挖的一个坑,在词生卡刚火那阵子,就想更进一步的发挥大模型对话产品的能力,做一个真正的提示词智能体。

目标是实现输入任意文章链接后,AI 自动生成适合微信分享的文章推荐卡片。

为了达到这一效果,大模型对话产品需要完成以下关键步骤:

  1. 网页爬取:自行访问链接,解析网页内容
  2. 内容总结:根据提示词要求,提炼标题、摘要、要点等信息
  3. 二维码生成:利用 qrcode.js 库,将 URL 转换为二维码图片
  4. 卡片样式生成:基于特定模板设计要求(暂不考虑自适应样式主题),将卡片内容、二维码组合为精美的分享卡片

理论上来说,这类词生卡任务正是大模型对话产品的天然“舒适区”。

所以直接编写「网页分享卡片生成」词生卡 Prompt 如下:

值得一提的是,通过实践探索,我发现了新的词生卡 Prompt 组织方法:

设计要求拆分为“设计规范”和“内容结构”,再细分为“布局与尺寸”、“字体规范”、“颜色规范”的独立模块,并结合“内容结构”进行要求提示。

这种提示词组织方式有 3 个显著优势:

  1. 模型通用性:采用纯 Markdown 格式编写,不依赖特定模型的特性,可以适配不同的大语言模型
  2. 提示简易性:提示词结构清晰易读,便于自然语言编写,降低使用门槛。
  3. 生成稳定性:通过清晰的模块划分和自然语言描述,避免了指令间的相互干扰,提高了 AI 生成样式代码的准确性和一致性

如果你还不了解如何从 0-1 编写词生卡 Prompt,请务必阅读前作《我的 Prompt 爆火全网| AI 一键生成高颜值社交名片全解析》,这应该是全网最细致的词生卡 Prompt 教程了。

# 网页分享卡片生成
- 作者:一泽Eze
- 名称:网页分享卡片生成
- 版本:1.0
- 用途:根据用户给出的网页链接,生成带二维码的网页分享卡片,方便移动端分享网页内容

## 任务
你需要访问给定的链接,根据模板要求,生成对应的网页分享卡片

## Workflow
1. 访问网页链接并阅读
2. 按下列 Template,使用 html 生成移动端网页分享卡片

注意:输出卡片后, 不再输出任何额外文本解释

## Template
### 设计规范
#### 布局与尺寸
- 卡片宽度:360px
- 内边距:32px
- 圆角:20px
- 阴影:0 8px 24px rgba(0,0,0,0.08)

#### 字体规范
- 字体族:'Noto Sans SC'
- 标题:22px, 700权重
- 摘要:15px, 400权重
- 要点:15px, 400权重
- 日期:14px, 400权重

#### 颜色规范
- 主色:#3E7BFA
- 背景:
  - 卡片:#FFFFFF
  - 页面:#F5F5F5
  - 摘要:#F8F9FC
- 文字:
  - 主要:#2B2B2B
  - 次要:#666666

### 卡片结构
#### 日期
- 内容:文字发布日期
- 格式:YYYY/MM/DD
- 位置:顶部
- 样式:灰色小字

#### 标题
- 内容:文章主标题
- 样式:粗体,大字号

#### 摘要框
- 背景:浅色背景
- 圆角:12px
- 内边距:16px

#### 要点列表
- 数量:4点
- 标记:圆点(6px;#287cf6)
- 间距:12px

#### 二维码区域
- 分隔:上方1px分割线 (#F5F5F5)
- 二维码
  - 尺寸:76x76px
     - 位置:左侧
  - 实现细节:
     - 引入最新版本的 qrcode.js CDN:https://cdn.rawgit.com/davidshimjs/qrcodejs/gh-pages/qrcode.min.js
     - 使用 id="qrcode" 的 div 容器
     - 在 window.onload 中初始化二维码
     - 设置 correctLevel 为 QRCode.CorrectLevel.H
     - 确保容器和图片都设置固定尺寸 76x76px
- 引导信息
  - 主标题:“扫码阅读全文”
  - 副标题(针对文章阅读价值,生成一句话引导文案)
  - 平台名称(#287cf6)

# init
链接:{{待访问的网页链接}}

在后续的测试中,无论是 Claude 3.5 sonnet,还是国内的通义千问 2.5 ,这套提示词始终保持了更高的成功率,都能给出稳定的预期效果。


🚀 AI 能力产品化:明确技术方案,构建 API 调用提示词

在成功验证了纯提示词方案后,接下来就是产品化开发阶段。

虽然代码编程不是我的强项,但配合 Cursor、Windsurf 这类 AI 编程工具,插件的实现效果相当不错。

所以,我想试着分享一些关键过程,尤其是提示词封装环节,希望对有意开发 AI 产品的朋友有所启发。

与提示词智能体不同,产品化开发需要考虑更多:

  1. 如何稳定的获取网页内容
  2. 如何选择适合的 AI 大模型 API 服务
  3. 面向大模型 API ,如何构建生产级提示词

1)如何稳定的获取网页内容?💻

在上述初版提示词实验中,获取网页内容极大依赖于大模型对话产品的外链解析能力。

然而,这种方式非常容易遭到平台反爬机制的制裁。

在实验过程中,最影响提示词方案效果的因素,不是大模型的生成质量,而是无法稳定地捕获网页内容。

转换思路来看,网页内容通常以明文形式展示在用户浏览器中,内容平台不可能对用户设备进行反爬制裁。

通过用户浏览器,以浏览器插件形式本地提取网页内容,正是一种稳定、经济的解决方案。

以下是 AI Share Card 插件所获取的网页元素清单:

附:开发时,如何确定需要插件获取哪些网页元素?

你可以拿着初版提示词,询问 AI :

我希望通过浏览器插件,获取提示词中所需的标签页标题、链接、内容元素,请你帮我设计获取相关元素的 js 代码

参考对话如下,也可以直接在 Cursor、Windsurf 里提示 AI 帮你完成开发


2)如何选择适合的 AI 大模型 API 服务?🔌

纯靠词生卡 Prompt 完成卡片样式输出,固然是非常灵活的 AI 智能体方案。

但倘若在最终落地产品中,还是每次都依赖大模型重新生成卡片的样式代码,反而会消耗大量的输出 token,耗时且不经济。

此外,在实际使用中,用户通常只固定使用一到两个常用模板,对自定义样式的需求并不频繁。

所以在开发 AI Share Card 插件的过程中,我选择将模板生成功能设计为固定的代码组件,而让大模型专注于内容总结的功能

如果用户需要选择其他模板,则通过增加更多模板选项 or 自定义模板代码功能实现。

如此一来,对 AI 大模型的要求就不会动辄需要像 Claude 3.5 sonnet 那样高不可攀的顶级模型。

处理纯文本总结任务,仅需 13B 或更小参数的模型,加上精调的提示词,就能产生很好的结果。

一旦明确模型的任务,AI API 服务的选型要求就清晰了:

  1. 较长的上下文窗口:内容总结类任务需要较大的上下文长度;
  2. 响应速度要快、并发支持要高:以便在多人使用插件时,保持良好的性能表现;
  3. 免费或尽量低价:减少模型 token 费用。

经过简单调研后,AI Share Card 选用的是GLM-4-flash(没恰饭。截至 2024-12,长达 128k 的上下文窗口,完全免费的调用价格,200 RPM 高并发支持,还要什么自行车 🚲 ~)


3)面向大模型 API ,如何构建生产级提示词?💬

与大模型对话产品的提示词不同。

对于大模型 API,我们需要利用插件预先获取的网页内容变量、提示词和 API 请求参数,拼搭出完整的 API 提示请求,精确引导 API 返回我们想要的生成结果。

根据 BigModel 官网给出的请求示例,可以看到需要在请求中传递Model类型、系统提示词、用户提示词、top_p、temperature等关键参数。

因此,可以构建相应的 API 请求内容如下:

1.设定系统提示词,定义基础任务:

# 网页分享卡片生成
- 作者:一泽Eze
- 名称:网页分享卡片生成
- 版本:1.0
- 用途:根据内容和链接,生成制作网页分享卡片所需的变量信息

## 任务
根据模板要求,分析输入内容的语种,并以对应的语种,生成制作网页分享卡片所需的变量信息

## Workflow
1. 读取网页内容、链接
2. 按变量要求,生成制作网页分享卡片所需的变量数据

注意:只需要直接输出变量数据, 不再输出任何额外文本解释

 

2.设定用户提示词提供具体任务数据,并要求大模型按 JSON 格式返回生成结果

注:为确保大模型能有效进行内容总结,提示词中使用 ${} 语法动态引用插件获取的网页数据(如标题、描述、正文等)。在实际发送 API 请求时,这些变量会被替换为真实的网页内容。

请分析以下网页内容,生成一个结构化的分享卡片数据:
    
网页标题:${title}
网页链接:${url}

时间信息:
- 文章发布日期:${content.meta.publishDate || '未知'}
- 当前日期:${new Date().toISOString().split('T')[0]}

元数据信息:
作者:${content.meta.author || '未知'}
描述:${content.meta.description || ''}
关键词:${content.meta.keywords || ''}

Open Graph 信息:
${JSON.stringify(content.openGraph, null, 2)}

网页正文内容:
${content.text.slice(0, 15000)}   // 【此注释非提示词内容,仅用于解释 15000 的原因】网页总结类任务,一般获取正文的前 15000 字,这个长度既能保证主要内容的完整性,又不会超出模型处理范围

注意:不要直接号召用户做利益相关的决策

请step by step的思考,使用与原网页内容一致的语种,严格按照以下 JSON 格式返回数据:
{
  "DATE": "YYYY-MM-DD",                // 优先使用文章发布日期,如果无法获取则使用当前日期
  "TITLE": "文章标题",                 // 原网页主标题
  "AUTHORS": "名称1, 名称2",           // 提取作者 or 公司名称,多个作者用逗号分隔; 若未识别到作者 or 公司名称,则返回网站顶级域名
  "SUMMARY": "内容摘要",           // 140字以内,网页内容概述,说明"这个网页是关于什么的",突出核心内容和用途,避免营销宣传语
  "POINTS": [                          // 理解整体内容意图,输出3-5个关键要点,必须聚焦文章的关键论点、数据、结论、利益相关信息,应独立且互补,简洁清晰准确,按重要性排序
    "要点1",
    "要点2",
    "要点3"
  ],
  "QR_TITLE": "扫码阅读全文",         // 必须使用与原网页内容一致的语种
  "QR_SUBTITLE": "引导扫码阅读的文案", // 根据文章内容生成的吸引人的一句话引导文案,不超过 15 字
  "PLATFORM": "文章发布平台",          // 提取或识别文章发布平台
  "QR_URL": "${url}"                   // 原文链接
}

 

3. 最后,根据文本总结类任务的通常经验与实际调试情况,设定其他 API 所需关键参数:

如果你缺少参数设定的经验,也可以先询问 AI 文本总结类的模型 API 请求,temperature 设定多少合适,再逐步调试效果即可。

MODEL: "glm-4-flash",
temperature: 0.6

 

附:以下是 Claude AI 对 AI Share Card 插件的大模型 API 请求与提示词的设计架构解释,希望能对你有所帮助。


📝 总结

以上就是我在 AI Share Card 插件开发过程中的关键经验,尤其是提示词封装方面的思考。如果你有更好的提示词封装方案,也欢迎提出建议🙋。

提示词虽然强大,但也只是技术实现的一部分。

在实践中,我选择将提示词智能体转化为固定模板加内容总结的混合方案,在保持相同效果的同时,让产品变得更加稳定、经济

希望这些开发过程中的思考和取舍,能为正在开发 AI 应用的朋友们提供一些参考。


 

0
0