交给Google AI Studio
出开发文档
给出一份简洁清晰的开发文档,主要阐述项目架构和功能实现路径。开发项目是一个浏览器插件。基础内容如下:
- 核心交互逻辑:一个嵌在对话输入框中的按钮,用户按下按钮,优化输入框中的提示词。
- 基础架构:
- 前端:定位输入框;捕捉用户提示词原版文本;发送文本到后端;
- 交互:嵌入进输入框右下的按钮,四个状态optimize,optimizing,aplly or cancel;随处理状态变化,合乎交互逻辑。
- 扩展配置:API配置选项;模板配置选项;历史记录;
- 后端处理:流式实时显示在输入框;分离LLM思考和输出部分;
- 适配网站(开发版本暂定):deepseek,Gemini,chatgpt,豆包,千问。
优化开发文档
分阶段开发
好的,这是一种非常专业且高效的软件工程实践。将复杂的项目分解为可管理、可交付的阶段性里程碑,可以确保每个阶段都有明确的目标和可验证的成果,最终组合成一个健壮且功能强大的产品。
以下是为你制定的、基于阶段性迭代的开发流程,每个阶段都是一个独立的
build 任务。智能提示词优化插件:分阶段迭代开发计划
为确保项目质量、降低开发风险并实现快速迭代,我们将整个开发过程划分为四个核心阶段(Milestone)。每个阶段都有明确的目标、任务和交付成果。
阶段一 (M1): 核心技术验证 (Proof of Concept)
核心目标: 验证从前端捕获文本 -> 调用 Gemini API -> 返回优化结果这一核心技术链路的可行性。此阶段不关心 UI 和用户体验,只关注功能跑通。
主要任务 (Key Tasks):
- [后端] Prompt 原型设计 (In Google AI Studio):
- 任务: 投入 80% 的精力在 Google AI Studio 中设计并迭代一个高性能的“元提示词” (Meta-Prompt)。
- 验证: 针对至少 20 种不同类型(日常、技术、创意、代码等)的输入进行测试,确保优化结果的稳定性和高质量。
- 产出: 一份经过充分验证、可直接用于生产的
prompt.txt文档。
- [后端] 部署“裸”API (In Google Cloud Function):
- 任务: 将验证后的 Prompt 部署为一个最简化的 Google Cloud Function。
- 要求:
- API Key 在代码中硬编码(仅供内部测试)。
- 实现流式响应 (
streamGenerateContent)。 - API 可通过 Postman 或
curl等工具成功调用并返回流式数据。
- [前端] 最小化内容脚本:
- 任务: 编写一个极简的内容脚本。
- 要求:
- 硬编码适配: 仅针对一个网站(例如
chat.openai.com)的输入框selector进行硬编码。 - 无 UI 注入: 不创建按钮。可以通过在控制台手动执行一个函数来触发优化逻辑。
- 功能实现: 该函数能成功捕获输入框文本,调用后端 API,并将返回的流式结果打印在控制台 (
console.log)。
交付成果 (Deliverable):
- 一份最终版的元提示词文档。
- 一个可公开访问的、功能单一的 Cloud Function API Endpoint。
- 一个能在特定网站的开发者控制台中手动触发、并验证完整数据链路的
content_script.js文件。
阶段二 (M2): 最小可行产品 (Minimum Viable Product)
核心目标: 构建一个拥有核心交互体验的、可供内部人员日常使用的插件版本。重点是实现端到端的自动化流程和基础 UI。
主要任务 (Key Tasks):
- [前端] 核心 UI 注入与状态管理:
- 任务: 在内容脚本中实现按钮的动态注入。
- 要求:
- 按钮能稳定地出现在目标输入框的右下角。
- 实现完整的按钮状态机:
- 空闲 (Idle): 显示“优化”图标。
- 处理中 (Processing): 显示加载动画,按钮不可交互。
- 确认 (Confirm): 显示“应用”和“取消”选项。
- [前端] 流式渲染到输入框:
- 任务: 将 M1 中打印到控制台的流式数据,改为实时、逐字地渲染到页面输入框中。
- 要求:
- 优化过程平滑流畅。
- “取消”功能可以成功将输入框内容恢复到优化前的状态。
- [前端] 弹出式配置页面 (Popup):
- 任务: 创建插件的弹出页面 (
popup.html)。 - 要求:
- 包含一个输入框,用于用户填写自己的 Gemini API Key。
- 使用
chrome.storage.sync来安全地存储和读取 API Key,以便跨设备同步。
- [后端] API 认证:
- 任务: 改造 Cloud Function,不再硬编码 API Key。
- 要求:
- 从请求的
Authorizationheader 中读取前端传递过来的用户 API Key。 - 使用该 Key 初始化
GoogleGenerativeAI实例。
交付成果 (Deliverable):
- 一个功能完整的
.zip插件包。
- 该插件在单个目标网站上运行稳定,用户可以配置自己的 API Key 并完成整个优化流程。
阶段三 (M3): 多站适配与功能扩展
核心目标: 将插件的适用范围扩大到所有目标网站,并增加历史记录、自定义模板等高级功能,提升产品的实用性和灵活性。
主要任务 (Key Tasks):
- [前端] 创建网站适配层:
- 任务: 重构内容脚本,实现多网站动态适配。
- 要求:
- 创建一个配置文件 (如
sites.config.js),用数据驱动的方式管理不同网站的host和selector。 - 内容脚本在运行时根据当前 URL 自动选择合适的配置。
- 逐一适配并测试 DeepSeek, Gemini, ChatGPT, 豆包, 千问,确保按钮注入位置和样式在各个网站上都表现良好。
- [前端] 历史记录功能:
- 任务: 在弹出页面中增加“历史记录”标签页。
- 要求:
- 每次成功“应用”一次优化后,将“优化前”和“优化后”的文本对存储到
chrome.storage.local。 - 历史记录页面可以清晰地展示最近的 10-20 条记录。
- 提供一键复制或恢复某条历史记录的功能。
- [可选/高级] 自定义 Prompt 模板:
- 任务: 在弹出页面增加“高级设置”,允许用户修改用于优化的元提示词模板。
- 要求:
- 提供一个文本区域,显示默认的元提示词模板,并允许用户编辑和保存。
- 前端在调用后端 API 时,如果用户有自定义模板,则将其一并发送。
- 后端 API 相应修改,优先使用用户提供的模板。
交付成果 (Deliverable):
- 一个支持所有目标网站的、功能丰富的插件版本。
- 拥有历史记录和(可选的)自定义模板功能,满足高级用户的需求。
阶段四 (M4): 优化、发布与维护
核心目标: 对产品进行全面的质量保证(QA)、性能优化和代码重构,最终将其打包上架到 Chrome 网上应用店。
主要任务 (Key Tasks):
- [代码质量] 重构与优化:
- 任务: 对 M1-M3 阶段的代码进行审查和重构。
- 要求:
- 清理无用代码,增加必要的注释。
- 优化 DOM 操作性能,减少不必要的重绘和回流。
- 统一代码风格,确保项目可维护性。
- [质量保证] 全面测试:
- 任务: 对所有功能在所有目标网站上进行回归测试。
- 要求:
- 测试各种边界情况(如网络错误、API Key 无效、输入框被动态移除等)。
- 确保插件在不同分辨率和浏览器缩放比例下 UI 表现正常。
- [发布] 上架准备:
- 任务: 准备上架所需的所有材料。
- 要求:
- 设计不同尺寸的插件图标。
- 撰写清晰的插件介绍、功能说明和隐私政策。
- 根据 Chrome 网上应用店的要求打包并提交插件。
交付成果 (Deliverable):
- 一个在 Chrome 网上应用店上公开发布的、稳定、高效、文档齐全的 1.0 版本插件。
- 一份精简的开发者文档和项目代码库。
更集中的开发策略
好的,这是一个更集中的开发策略,旨在通过一个核心开发阶段,直接从技术验证(PoC)跨越到功能完整(Feature-Complete)的版本。
以下是合并了原计划阶段二和阶段三的、一份清晰的开发方案。
智能提示词优化插件:开发计划 V2.0
阶段一 (M1): 核心技术验证 (Proof of Concept)
- 状态: 已完成 (As per previous plan)
- 成果:
- 一份经过 Google AI Studio 验证的高性能元提示词。
- 一个可通过
curl或 Postman 调用的、实现了流式响应的后端 API(Cloud Function)。 - 一个可在浏览器控制台手动触发并验证完整数据链路的极简内容脚本。
阶段二 (M2): 功能完整版开发 (Feature-Complete Development)
核心目标:
此阶段的目标是整合核心功能与扩展特性,构建一个支持多网站、提供高级配置、并拥有完整用户体验的“功能完整版”插件,为公测(Beta)或 1.0 版本发布做好准备。
开发路径与任务分解 (Development Path & Task Breakdown):
我们将按照功能依赖关系,分步骤完成此阶段的开发,确保每一步都有坚实的基础。
第一步:构建核心交互框架 (Build the Core Interaction Framework)
- 目标: 让用户在单个网站上获得完整的、自动化的使用体验。
- 前端任务:
- UI 注入: 编写内容脚本,实现在单个目标网站(建议首先选择 ChatGPT)的输入框旁稳定地注入交互按钮。
- 状态机实现: 为按钮实现完整的四状态交互逻辑:
空闲 (Idle): 显示“优化”图标。处理中 (Processing): 显示加载动画,按钮禁用。确认 (Confirm): 按钮分裂为“应用”和“取消”两个选项。- 流式渲染: 将后端返回的数据流实时、平滑地渲染到输入框中。
- 状态恢复: 确保“应用”和“取消”功能可以正确地确定最终文本或恢复原始文本。
第二步:实现用户配置与安全认证 (Implement User Configuration & Secure Authentication)
- 目标: 解除硬编码限制,让插件可以被任何拥有 API Key 的用户使用。
- 前端任务:
- 创建 Popup 页面: 开发
popup.html及其关联的脚本和样式。 - API Key 配置: 在 Popup 页面中提供一个输入框,让用户可以输入并保存他们的 Gemini API Key。
- 安全存储: 使用
chrome.storage.syncAPI 来存储用户的 API Key,确保其安全且能在不同设备间同步。
- 后端任务:
- 升级 Cloud Function: 修改后端 API,使其不再使用硬编码的 Key。
- 认证逻辑: 从前端请求的
AuthorizationHeader 中读取用户 API Key,并用其来初始化 Google AI SDK。
第三步:实现多网站动态适配 (Implement Multi-Site Dynamic Adaptation)
- 目标: 将插件的适用性从单个网站扩展到所有目标平台。
- 前端任务:
- 重构内容脚本: 将硬编码的 CSS 选择器和注入逻辑抽象化。
- 创建适配层: 建立一个配置文件(例如
sites.config.js),其中包含一个对象数组,每个对象定义一个目标网站的hostname、selector以及可能的特定样式调整。JavaScript - 动态加载: 内容脚本启动时,根据
window.location.host匹配配置文件,并使用对应的selector来定位输入框。 - 兼容性测试: 在所有目标网站上进行详尽测试,确保按钮的定位和功能表现一致。
第四步:增加高价值功能 (Add High-Value Features)
- 目标: 提升用户粘性,并为高级用户提供更强的自定义能力。
- 前端任务:
- 历史记录:
- 在 Popup 页面中增加“历史记录”标签页。
- 当用户点击“应用”时,使用
chrome.storage.local存储优化前后的文本对。 - 在历史记录页面中展示最近的优化记录,并提供“一键复制”功能。
- (可选/高级)自定义模板:
- 在 Popup 页面增加“高级设置”部分。
- 提供一个文本区域,允许用户覆盖默认的元提示词模板。
- 当用户发起优化请求时,将自定义模板一同发送到后端。
- 后端任务 (如果实现自定义模板):
- API 扩展: 修改后端 API 的请求体(Request Body),使其可以接收一个可选的
template字段。 - 动态 Prompt: 如果请求中包含
template字段,则使用该模板构建发送给 Gemini 的最终 Prompt;否则,使用默认模板。
交付成果 (Deliverable):
在此阶段结束时,我们将得到一个功能完整、可直接分发给测试用户的插件
.zip 包。具体包括:- 一个可在所有目标网站(ChatGPT, Gemini, 豆包, 千问, DeepSeek)上稳定运行的浏览器插件。
- 一个功能完善的弹出式菜单,用户可以配置自己的 API Key 并查看历史记录。
- 一套安全可靠的前后端通信机制,通过用户提供的 API Key 进行认证。
- (如果完成可选任务)为高级用户提供 Prompt 自定义能力。
完成此阶段后,项目将直接进入最后的“优化、发布与维护”阶段(原 M4)。
阅读+处理方案
智能提示词优化插件:分阶段迭代开发计划
核心目标: 验证从前端捕获文本 -> 调用 Gemini API -> 返回优化结果这一核心技术链路的可行性。此阶段不关心 UI 和用户体验,只关注功能跑通。
核心目标: 构建一个拥有核心交互体验的、可供内部人员日常使用的插件版本。重点是实现端到端的自动化流程和基础 UI。
核心目标: 将插件的适用范围扩大到所有目标网站,并增加历史记录、自定义模板等高级功能,提升产品的实用性和灵活性。
核心目标: 对产品进行全面的质量保证(QA)、性能优化和代码重构,最终将其打包上架到 Chrome 网上应用店。
阶段一 (M1): 核心技术验证 (Proof of Concept)
- 设计并迭代一个高性能的“元提示词” (Meta-Prompt)。
- 验证: 针对至少 20 种不同类型(日常、技术、创意、代码等)的输入进行测试,确保优化结果的稳定性和高质量。
- 产出: 一份经过充分验证、可直接用于生产的
prompt.txt文档。
阶段二 (M2): 最小可行产品 (Minimum Viable Product)
- [前端] 核心 UI 注入与状态管理:
- 任务: 在内容脚本中实现按钮的动态注入。
- 要求:
- 按钮能稳定地出现在目标输入框的右下角。
- 实现完整的按钮状态机:
- 空闲 (Idle): 显示“优化”图标。
- 处理中 (Processing): 显示加载动画,按钮不可交互。
- 确认 (Confirm): 显示“应用”和“取消”选项。
- [前端] 流式渲染到输入框:
- 任务: 将 M1 中打印到控制台的流式数据,改为实时、逐字地渲染到页面输入框中。
- 要求:
- 优化过程平滑流畅。
- “取消”功能可以成功将输入框内容恢复到优化前的状态。
- [前端] 弹出式配置页面 (Popup):
- 任务: 创建插件的弹出页面 (
popup.html)。 - 要求:
- 包含一个输入框,用于用户填写自己的 Gemini API Key。
- 使用
chrome.storage.sync来安全地存储和读取 API Key,以便跨设备同步。
- [后端] API 认证:
- 任务: 改造 Cloud Function,不再硬编码 API Key。
- 要求:
- 从请求的
Authorizationheader 中读取前端传递过来的用户 API Key。 - 使用该 Key 初始化
GoogleGenerativeAI实例。
交付成果 (Deliverable):
- 一个功能完整的
.zip插件包。
- 该插件在单个目标网站上运行稳定,用户可以配置自己的 API Key 并完成整个优化流程。
阶段三 (M3): 多站适配与功能扩展
主要任务 (Key Tasks):
- [前端] 创建网站适配层:
- 任务: 重构内容脚本,实现多网站动态适配。
- 要求:
- 创建一个配置文件 (如
sites.config.js),用数据驱动的方式管理不同网站的host和selector。 - 内容脚本在运行时根据当前 URL 自动选择合适的配置。
- 逐一适配并测试 DeepSeek, Gemini, ChatGPT, 豆包, 千问,确保按钮注入位置和样式在各个网站上都表现良好。
- [前端] 历史记录功能:
- 任务: 在弹出页面中增加“历史记录”标签页。
- 要求:
- 每次成功“应用”一次优化后,将“优化前”和“优化后”的文本对存储到
chrome.storage.local。 - 历史记录页面可以清晰地展示最近的 10-20 条记录。
- 提供一键复制或恢复某条历史记录的功能。
- [可选/高级] 自定义 Prompt 模板:
- 任务: 在弹出页面增加“高级设置”,允许用户修改用于优化的元提示词模板。
- 要求:
- 提供一个文本区域,显示默认的元提示词模板,并允许用户编辑和保存。
- 前端在调用后端 API 时,如果用户有自定义模板,则将其一并发送。
- 后端 API 相应修改,优先使用用户提供的模板。
交付成果 (Deliverable):
- 一个支持所有目标网站的、功能丰富的插件版本。
- 拥有历史记录和(可选的)自定义模板功能,满足高级用户的需求。
阶段四 (M4): 优化、发布与维护
主要任务 (Key Tasks):
- [代码质量] 重构与优化:
- 任务: 对 M1-M3 阶段的代码进行审查和重构。
- 要求:
- 清理无用代码,增加必要的注释。
- 优化 DOM 操作性能,减少不必要的重绘和回流。
- 统一代码风格,确保项目可维护性。
- [质量保证] 全面测试:
- 任务: 对所有功能在所有目标网站上进行回归测试。
- 要求:
- 测试各种边界情况(如网络错误、API Key 无效、输入框被动态移除等)。
- 确保插件在不同分辨率和浏览器缩放比例下 UI 表现正常。
- [发布] 上架准备:
- 任务: 准备上架所需的所有材料。
- 要求:
- 设计不同尺寸的插件图标。
- 撰写清晰的插件介绍、功能说明和隐私政策。
- 根据 Chrome 网上应用店的要求打包并提交插件。
交付成果 (Deliverable):
- 一个在 Chrome 网上应用店上公开发布的、稳定、高效、文档齐全的 1.0 版本插件。
- 一份精简的开发者文档和项目代码库。
交付
开发项目是一个浏览器插件。现在新建完了基础的项目空文件,请继续开发具体内容。基础核心交互逻辑:一个嵌在对话输入框中的按钮,用户按下按钮,优化输入框中的提示词。开发内容如下:
- [前端] 核心 UI 注入与状态管理:
- 任务: 在内容脚本中实现按钮的动态注入。
- 要求:
- 按钮能稳定地出现在目标输入框的右下角。
- 嵌入按钮的位置以及定位方式:在原输入框中“发送”按钮的上方
- 实现完整的按钮状态机:
- 空闲 (Idle): 显示“优化”图标。
- 处理中 (Processing): 显示加载动画,按钮不可交互。
- 确认 (Confirm): 显示“应用”和“取消”选项。
- [前端] 流式渲染到输入框:
- 任务: 将后台调用LLM处理后的文本中打印到控制台的流式数据,改为实时、逐字地渲染到页面输入框中。
- 要求:
- 优化过程平滑流畅。
- “取消”功能可以成功将输入框内容恢复到优化前的状态。
- [配置] 配置页面 (options.html):
- 任务1: 创建插件的配置页面 (options.html)。
- 要求:
- 输入框,用于用户填写自己的API Key, URL, model,即常规的自定义API接口请求内容类型。
- 任务: 在页面增加“高级设置”,允许用户自定义用于优化的元提示词模板。
- 要求:
- 提供一个文本区域,显示默认的元提示词模板,并允许用户编辑和保存。
- 前端在调用后端 API 时,如果用户有自定义模板,则将其一并发送。
- 后端 API 相应修改,优先使用用户提供的模板。
- 任务2:元提示词模板:
- 普通优化
- 你的任务是优化提示词文本本身,而不是回答或执行提示词的内容
- 请直接输出改进后的提示词,不要对提示词内容进行回应
- 保持用户的原始意图,只改善表达方式和补充必要信息
- 自定义:由用户自定义原提示词模板,并保存在本地,可在配置页选用生效
请对以下用户提示词进行基础优化,消除模糊表达,补充关键信息。
重要说明:
需要优化的用户提示词:
{{originalPrompt}}
请输出优化后的提示词:
- [前端] 创建网站适配层:
- 任务: 重构内容脚本,实现多网站动态适配。
- 要求:
- 创建一个配置文件 (如
sites.config.js),用数据驱动的方式管理不同网站的host和selector。 - 内容脚本在运行时根据当前 URL 自动选择合适的配置。
- 选择策略以输入框中的“发送”按钮为参考坐标,在其上方即可
- 逐一适配并测试 DeepSeek, Gemini, ChatGPT, 豆包, 千问,确保按钮注入位置和样式在各个网站上都表现良好。
- [前端] 历史记录功能:
- 任务: 在配置页面中增加“历史记录”标签页。
- 要求:
- 每次成功“应用”一次优化后,将“优化前”和“优化后”的文本对存储到
storage.local。 - 历史记录页面可以清晰地展示最近的 10-20 条记录。
- 提供一键复制或恢复某条历史记录的功能。
给studio build
项目不适配,studio的build基本是用内置的Gemini来响应跟LLM相关的请求,且以web和app为输出格式。将“交付 ”提示词喂给其它LLM的build试试。
分步骤推进的策略是对的
