从一句「我想找回那张照片」，
到一款真正能用的 App。

先把“想做一个 App”，
变成一个具体问题。

一开始最容易陷入的，是把所有期待都放进去：智能相册、视频理解、语音搜索、自动拼图、跨设备同步……但第一版需要先回答一个更小的问题：用户能不能从自己拥有的照片里，找回某一个画面？

我先让 AI 拆出三件事：谁在使用、什么时候需要、找到什么才算成功。由此确定核心路线：授权访问照片 → 选择整理范围 → 建立本地索引 → 输入线索 → 查看原片。这里的“索引”，可以理解成替相册做一份能快速查找的目录。

我想做一个在手机本地寻找照片和视频的 App。请先梳理目标用户、最常见的场景、第一版必须具备的功能，以及暂时不做的内容。先用普通人能理解的话解释。

这一步的交付物是一份需求说明。验收它的方法也很简单：读完之后，能否用一句话说清楚这个 App 帮谁解决什么问题。

把需求写成可检查的产品方案。

“支持本地 AI”还不是完整需求。用户只给了部分照片权限怎么办？模型没下载好怎么办？整理到一半离开 App，会不会从头开始？照片删掉以后，旧搜索结果还会出现吗？这些才决定它能不能被日常使用。

我让 AI 把正常情况和失败情况一起写进方案：权限受限时给出入口；下载可以取消和续接；整理保留检查点；资源不足时说明原因。每一个状态，都要让用户知道发生了什么，以及接下来可以做什么。

从这里开始，聊天里的决定沉淀成产品文档、技术规格和测试计划。以后修改功能，就有了共同依据。对非技术用户来说，最值得要求的交付不是“一大段代码”，而是“可操作的版本＋哪些地方已验证、哪些还没有”。

漂亮的界面，要能把事情讲清楚。

UI 是眼睛看到的颜色、排版和按钮；UX 是完成一件事时的整体感受。Phovue 探索过清透原生、温润搜索和深色图库，后来收敛到带一点建筑感的淡紫、薄荷绿与米白色。设计参考的是一种安静、有空间感的视觉语言，照片仍然是主角。

AI 图片生成工具适合探索气质、构图和品牌图标，但一张好看的图不能代替可点击的界面。文字可读性、按钮状态、滚动和系统权限，需要在实际 App 里实现并检查。官网的页面探索使用了 Superdesign，再由 Codex 接入项目中的真实素材和功能。

我反复调整的一个细节，是把“本机处理、内容不上传”放在用户能看见的位置；另一个是减少模型参数对普通用户的干扰。用户是来找照片的，不应该先研究手机使用哪一种硬件加速。

这些截图使用演示素材。它们能说明页面组织和操作路线，实际手机上的持续功耗、加速兼容性和完整相册整理用时仍要分别验证。

先能找到，再逐步理解得更深。

最初的想法很直观：让视觉大模型逐张描述照片，再拿这些描述搜索。实际推进后发现，把全相册都做一遍深度分析，可能带来很长的等待、内存压力和发热。“小模型”也不等于“几乎不占资源”。

于是方案发生了重要调整：基础搜索先为画面建立向量索引；有需要时，再用 Qwen 做更细的文字和画面分析。向量可以理解成一组描述画面特征的数字，让“公园里的小路”和相关照片更容易匹配；深度分析则像请一位更仔细的助理，再读一遍画面。

当前 Android 工程接入 EmbeddingGemma 2 基础搜索和 Qwen 深度分析，分别保留索引。更换不兼容的检索模型，需要重新建立对应目录。下载模型和运行模型的内存也分开估算，不能把“下载 2GB”直接理解成“运行只需要 2GB 内存”。

隐私边界同样写进方案：模型就绪后，照片、视频和分析结果在本机处理，不上传给服务器。模型下载需要联网；用户主动打开在线地图时也会另行联网，并涉及所选坐标等必要信息。开发时使用 ChatGPT/Codex，与 App 运行时依赖云端聊天接口，是两件不同的事。

真正的开发，是不断发现问题。

Codex 在工程里修改代码、构建安装包、运行测试，Git 保存每次变化。我的反馈尽量从“感觉不对”变成“在什么情况下，发生了什么，希望怎样处理”。例如：“取消一个等待中的下载后，列表还显示下载中；请修正状态，并验证重新下载可以开始。”

按已确认的产品和界面方案实现一条完整流程。完成后运行构建和相关测试，提供实际界面、失败情况和验证范围。没有测试过的部分请明确列出。

工程记录里已经出现过下载状态、取消与重试、模型释放、索引范围、推荐去重、详情布局和后台续接等修复。每次修改都尽量带上对应检查，避免修好一个按钮却弄坏另一条路线。

测试也分层进行：单元测试检查小规则，比如日期边界和弱证据不乱推荐；模拟器测试检查页面和操作；真实模型测试检查公开样例能否产生合理结果；真机长测才回答锁屏、后台、发热和持续整理的问题。

这里有个容易误会的地方：模拟器截图正常，不代表所有手机都稳定。现有测试计划中，仍有真机后台、整年照片长测和资源压力验证待完成；一次被锁屏阻断的测试，不能写成“测试通过”。把这些限制记录下来，比只展示一个绿色成功提示更有用。

做出安装包之后，还要让人找到它。

安装包可以理解成 App 的交付文件。Phovue 的 Android 开发预览包通过腾讯云 COS 分发：COS 是一个在线文件仓库，适合存放可以被下载的大文件。官网则是一家店的门面，介绍用途、真实界面、隐私边界、版本状态和未来方向。

这条交付链路是：构建并核验安装包 → 为版本生成独立文件名 → 上传 COS → 配置下载域名与 HTTPS → 核对远端文件大小和 SHA-256 → 把官方链接和二维码接入官网。SHA-256 像文件指纹，帮助确认下载到的文件与本地准备的版本一致。

我们的主域名是 dpinsight.world。app.dpinsight.world 提供产品页面，download.dpinsight.world 提供下载。同一个已购买的域名可以配置这些子域名，不用为了每个入口再买一个域名。

官网使用静态 HTML、CSS 和少量 JavaScript，通过 Python 脚本构建，由腾讯云香港服务器上的 Nginx 提供访问。它复用已有服务器，没有为介绍页新增应用服务或云数据库。中英文页面、手机布局、下载链接和 HTTPS 都需要检查，不能只看电脑上的首页。

Android 的安装包下载也不等于已上架应用商店。当前是开发预览体验；以后如果进入商店，仍有审核、签名、隐私披露和相应政策要求。更新网站时保留旧版目录，确认后切换，出现问题才有机会快速恢复。

从“找到”，走向理解、整理和创作。

接下来最重要的不是一口气增加很多入口，而是先把首次整理、后台恢复、耗电和搜索质量做好。以下是阶段方向，不代表当前版本已经实现，也不承诺上线日期。

普通拼图只是排列原片，生成式融合需要新的模型能力，两者会明确区分。生成内容另存副本，保留原片；模型能力按需下载，避免为了一个小功能让所有人下载一大包组件。

iOS 也会采用分阶段路线：先做照片授权、浏览、本地索引和搜索，再评估问答与创作。Swift、SwiftUI、PhotoKit 是规划基础；Metal、Core ML 或其他推理运行时要按模型兼容性独立验证，不能把 Android 的实现直接搬过去就承诺相同性能。

最后，把工具和账单摊开。

不需要先记住这些名字。先看它们分别负责哪件事，再区分“已使用”“规划中”和“按需付费”。下表基于项目记录；价格核查日期为 2026 年 10 月 22 日。

AI 与研发工具

这里把对话工具、插件和本地工具分别列出。项目中没有证据表明使用过的插件，不列为实际依赖。Figma 也不是当前 Android 工程构建所必需的工具。

Android 与 iOS 技术栈

这些开发工具大多可以免费获取，但模型许可、商业使用条件、测试设备、开发者账号和商店费用仍需单独确认。App 端侧推理不按每次搜索向 OpenAI API 付费；这不包含开发期间使用 AI 工具的订阅费用。

服务器、域名与 COS：固定成本和浮动成本

估算 COS 可以先不纠结单价：当前安装包约 143.8MiB，一次完整下载约 0.1404GB（按 1024 进制）。若每月完整下载 1,000 次，约产生 140.4GB 下行流量。按 0.75 元/GB，下载流量费约 105.3 元。若平均存储 1GB，一个月容量费约 0.136 元；假设只有 1,000 次标准读请求，再约 0.001 元。未使用优惠时合计约 105.44 元/月。这是简化预算，实际重试、分段请求、历史版本与账单周期都会影响结果。

通用公式是：每月 COS 费用 ≈ 月均存储 GB × 容量单价 ＋ 下载 GB × 下行单价 ＋ 请求费。不要把“存一个安装包很便宜”，理解成“很多人下载也基本免费”。