我想做一个 Chrome 插件，原因很普通：提示词太容易散。
在网页上看到一段好用的指令，先复制到聊天框，后来又忘了；在 GitHub 看到一个分析模板，临时收藏一下，几周后找不到；自己写过一个顺手的提示词，下次想复用，只能去聊天记录里翻。
我一开始的想法也很朴素：做个插件，把提示词存起来。
但 Codex 没有直接开写。它先做了一次范围批判。
这一步很有用。因为这类个人工具很容易失控：一上来就想做云同步、AI 自动优化、团队共享、向量检索、知识图谱、市场分发。听起来都可以，但第一版做这些，大概率最后什么都用不上。
所以第一版被压成一句话：
收集 -> 结构化保存 -> 搜索复用 -> 导出备份我是怎么一步步推进的
第一步，把一句话想法写成 problem case。原始想法只是“我想开发一个 Chrome 插件，进行我的提示词收集，可以存储起来”。Codex 先把它改写成问题定义：提示词散落、复用成本高、需要一个本地优先的收集入口。
第二步，先做合理性批判。哪些值得做？右键保存、标签、来源 URL、搜索、一键复制、导出备份。哪些先不做？云同步、团队共享、向量检索、AI 自动优化、Chrome Web Store 上架。砍掉这些，MVP 才能落地。
第三步，写产品设计。Codex 把使用场景拆成网页保存、手动新增、检索复制、导出备份，再补信息架构：popup 做快速入口，side panel 做主工作台，options 做导入导出和设置。
第四步，写数据模型和实施计划。一个 prompt 需要 id、title、content、tags、scenario、variables、source、notes、createdAt、updatedAt。工程先走无构建版，不引入 React，目录拆成 background、popup、sidepanel、options 和 shared。
第五步，写出 MVP。右键保存选中文本，popup 快速入口，side panel 管理提示词，options 做 JSON 和 Markdown 导出。本地用 chrome.storage.local，不接后端。
第六步，记录真实修复。比如右键保存一开始只写临时 draft，不真正入库；后来修成每次保存都创建新 ID。这个修复进入 log.md，后面才知道工具是怎么变稳的。
第七步，按真实使用继续加能力。DeepSeek 拆解、AI 场景匹配、GitHub Gist 同步、全屏管理台，都不是第一天拍脑袋加的，而是在 MVP 跑起来之后再往上叠。
这就是 RsvP 的好处：一个想法不会直接跳到代码，而是先变成问题，再变成设计，再变成计划，再变成 MVP，最后留下日志。
本地优先，不急着上云
这个插件最后的定位是：个人提示词收藏夹加使用工作台。
第一版不做账号，不做后端，不做团队空间。技术上用 Chrome Extension Manifest V3，本地存储用 chrome.storage.local。网页选中文本后右键保存，自动带入页面标题和 URL，再补标题、标签、场景、备注。
它的核心不是炫技，而是顺手。
保存动作必须快。字段要足够结构化。数据不能被插件锁死，所以要支持 JSON 和 Markdown 导出。权限也要克制，不读取用户没有主动选择的页面正文。
Codex 在这里适合做两件事：先把产品边界砍清楚，再把 MVP 拆成可以落地的文件结构。
从设计到 MVP
后来这个 case 在 RsvP 里形成了完整问题卡、设计稿、实施计划和开发日志。
MVP 没有引入 React 或 Vite，先做无构建版插件，减少工具链成本。目录里有 manifest.json、background.js、popup、sidepanel、options 和共享存储层。
第一版能做这些事：
- 右键菜单保存选中文本。
- popup 快速入口。
- side panel 里新建、编辑、删除、搜索、标签过滤和复制。
- options 里做 JSON 导入导出、Markdown 导出和清空数据。
- 使用次数和最近使用时间记录。
后面又继续加了 DeepSeek 拆解、AI 场景匹配、GitHub Gist 同步和全屏管理台。这个过程里，Codex 不只是写代码，也在不断记录决策和修 bug。
比如右键保存一开始只写入临时 draft，不是真正入库。后来修成每次选中文本触发保存都会创建新 ID 并写入 chrome.storage.local。这种日志很重要，它让工具演化不是一团黑箱。
RsvP 在这里的作用
这个插件没有直接散在一个临时目录里，而是被放进 RsvP 的 problem case。
RsvP 是一个持续解决问题的工作台。每个正式问题有 problem.md、design.md、plan.md、log.md，最终材料再放到 materials/ 或 artifacts/。这样一个想法从“我想做个插件”走到“有设计、有计划、有 MVP、有日志”，中间不会丢。
这也是我觉得 Codex 很适合个人工具开发的地方。
你不一定一开始就知道工具最终长什么样。但你可以让它先帮你把问题定义清楚，把不该做的砍掉，把第一版做小，然后在真实使用里慢慢加。
个人工具最怕一开始太宏大。
先让它真的被用起来。