DOMPrompter 的技术选择要围绕“开发者正在调页面”这个场景。它需要读页面、截图、生成提示词、保存上下文，还要尽量不打断用户当前工作流。

桌面壳的优势在于整合能力强：可以承接本地文件、窗口操作、剪贴板、截图和跨平台分发。代价是包体和更新机制需要控制。

开发细节补充：这篇记录放在 DOMPrompter 的产品日记里，不是为了把一个功能包装成故事，而是把“04 · 技术选择：桌面壳、本地截图和跨平台发布”放回真实项目推进中看。它要同时回答三件事：用户为什么需要这个点，开发时哪些边界必须先定住，以及这个选择会怎样影响上架、推广和后续课程复盘。平台口径是 macOS / Electron / AI 编程，当前公开状态是 失败复盘 / 本地优先 / 开源，所以文案不能脱离真实发布进度。

对应的 docs 线索主要来自 visual-inspector 架构文档、产品哲学记录、i18n 工作流、MAS 可行性和重构进度。公开页面不会照搬内部工作记录，而是把可公开、可学习、不会泄露私密路径和账号信息的事实整理出来。相关 docs 记录过产品哲学、架构、国际化工作流和 MAS 重构，说明它原本试图把前端视觉检查变成可操作工具。 DOM 选择、样式差异、截图上下文和提示词合约都成立，但 AI 浏览器代理进步后，中间层厚度变成主要风险。 开发记录里可复用的是视觉 QA 思路：明确目标元素、修改范围、视口、截图证据和回归检查。 2026-04-15 DOMPrompter 0.1.0 曾因 Settings 菜单无响应和 Unrestricted Web Access 年龄分级不准被拒；0.1.0 (26) 修复 IPC listener cleanup 与 Age Rating 后通过。 失败复盘要把工具价值从生成提示词，收缩到前端验收、截图差异和设计判断。

从产品功能看，DOMPrompter 关联的能力包括：点击元素获取 selector 和上下文、可视化记录样式差异、生成 Codex / Cursor 提示词、适合设计还原和前端细节修改。写这类日记时，不能只说“做了什么”，还要说明为什么先做这些、为什么暂时不做另一些。比如一个按钮、一个导入流程、一个本地模型开关或一段截图文案，放在代码里只是小改动，放在产品里却会影响用户理解、审核员复现和后续推广素材。

从工程推进看，这篇日记对应的检查点是：AI 前端微调工作流案例；产品本身也能服务本站后续迭代。真实开发最容易失真的是中间过程，因为最后页面看起来只有一个结果，但实际会经历方案取舍、权限确认、素材准备、测试设备、审核备注和发布节奏。把这些过程写下来，后面做同类产品时才不会重新踩同一个坑。

从隐私和合规看，当前约束是：选择元素、样式差异和提示词生成流程在本地完成。这类信息必须前置到开发日记里，因为独立产品的可信度不是靠口号建立的，而是靠数据在哪里处理、用户能不能退出、功能是否离线可用、商店页怎么承诺、隐私政策是否与实现一致这些小事实积累出来的。

从课程和复用看，这篇内容可以沉淀到 前端视觉微调、AI 提示词结构化、DOM 选择器、设计实现复盘。它的价值不只是给访问者看一个产品，而是展示一个独立开发者怎样把想法转成可验证的产品：先收窄场景，再选技术路径，再做体验最小闭环，最后把审核、推广、运营数据和失败教训都纳入下一次迭代。

前端 AI 工具最终要卖验收和判断，而不是卖复制上下文的步骤。 这也是为什么每篇产品日记都要写到足够长：不是为了凑字数，而是为了把“证据、决策、实现、边界、复盘”都放在同一页，让读者看到一个判断是怎样被逐步验证出来的。最难的是避免产品只停留在 AI 暂时不会读页面的能力缺口上。

所以这篇日记的结论不是“功能已经写完”，而是把一个阶段的判断公开化：哪些证据足够支撑继续推进，哪些资料还需要回到源码、商店材料、公开文案或运营观察里补齐。这样的记录会比单纯的发布公告更慢，但也更真实，能让产品页、发布记录和课程内容保持同一条事实线。

验收时我会把它拆成四个层次：第一层是用户路径能不能走通，第二层是异常状态有没有被诚实处理，第三层是页面上的按钮、状态、截图和文案是否对应真实发布渠道，第四层是公开证据能否支撑这个判断。只要其中一层对不上，产品看起来再完整，也不能算真正进入下一个阶段。

交接时也要保留边界：源码、构建、测试、商店元数据、公开文案、平台反馈和运营观察分别保存原始资料。产品日记只把这些事实翻译成读者能理解的过程，不替任何私有记录保存原始材料。

把这些内容公开出来，还有一个很现实的原因：AI 教程如果只展示成功结果，很容易让人误以为产品是一次生成出来的。真实情况恰好相反，真正可学习的是一次次收窄、验证、失败、补证据和重新提交。日记越具体，后续读者越能看到判断的脉络，而不是只看到一个漂亮的截图。

为什么不是纯网页工具

纯网页工具很难自然访问本地开发页面、截图和剪贴板，也不容易和用户的编辑器工作流结合。桌面工具更适合成为前端微调的工作台。

跨平台不是第一天就全部完美

macOS、Windows、Linux 的窗口、权限和打包体验不同。早期应该先跑通核心体验，再把签名、自动更新和平台适配逐步补齐。

发布材料也是产品的一部分

开发者工具需要清楚展示它解决什么问题，截图最好显示真实前端微调前后，而不是只放抽象图标。