论点，连同对它的反驳
职业摄影师需要三样东西，现有的三类产品各占其二，没有一家三样都有。 本页要论证的是：这个空位真实存在，守得住；同时坦白交代，为什么它也可能守不住。
本页没有任何预测。没有收入，没有用户，没有融资。有的是：一套能用的系统、来自真实拍摄的测量数据， 以及一份排好次序、写明了卡点的计划。关于竞品的数字来自公开信息，任何人依赖它们之前都应先核实。
空着的位置
| 产品 | 文件放在哪就留在哪 | 知道哪张更好 | 手机和网页 | 直接用你的苹果“照片”图库，无需导入 |
|---|---|---|---|---|
| Mylio Photos | 是 | 否 | 仅限 app——没有浏览器端 | 从中导入 |
| Immich, PhotoPrism | 要求自己的目录结构 | 否 | 是 | 否 |
| AfterShoot, Narrative Select | 是 | 是 | 否 | 否 |
| Lightroom Classic, Photo Mechanic | 是 | 否——靠手工 | 否 | 导入副本 |
| Lightroom（云端） | 否——由它托管 | 否——靠手工 | 是 | 导入副本 |
| 苹果“照片” | 默认放进它自己的图库 | 否——只把连拍归组 | 限苹果设备 | 它本身就是图库 |
| 7Photo | 是 | 是，并说明理由 | 浏览器工作台，目前只在家庭网络内试过 | 是——原地读取 |
真正该比的是 Mylio，而不是 Adobe。它的文件模型正是这里想要的那一种， 而且做了十二年图库管理。它从来没有的，是对“哪张照片更好”的任何判断——它的基因是家庭相册归档， 不是职业拍摄——而且它没有浏览器客户端，借来的笔记本、影棚里的 Windows 电脑，统统用不上。
在智能这一项上，真正的对手是 AfterShoot 和 Narrative Select， 它们之所以存在，是因为 Lightroom 有个窟窿。它们成熟、有支持、按订阅收费，生来是给 Lightroom 喂片的，而不是用来管理图库的。7Photo 与它们的不同在于性质，而非程度：它说明为什么选这张，而不只是替你选； 它学一位摄影师的口味，并且被规定不许比朴素的规则做得更差；它在所有拍摄里认得同一批人， 评判合影时看的是要紧的那几位；它原地读取苹果“照片”图库；它做的任何事都不会离开这台 Mac。
“照片”是最大的、却无人服务的人群。数以亿计的图库，内置人物归组， 可是在同一瞬间的三十张里挑一张时，毫无帮助。7Photo 原地打开一个相簿——不导入，不复制——然后挑片。
各竞品的功能按我们在 2026 年 10 月的理解描述；它们变化很快。
为什么是现在，而不是三年前
SWOT
优势和劣势是内部的，由我们掌控；机会和威胁是外部的，不由我们掌控。
S 优势
- 它有主见，而且主见可以检查。眼部清晰度、闭眼、按人设定的优先级、懂连拍的对比。Mylio 一样都没有。而且数字摆在你面前，所以它是第二意见，不是神谕。
- 它只学一个人，而且学不坏。只用你自己的决定、在连拍内部做比较来训练；任何学出来的模型，只要输给朴素的规则就被丢弃。必须给所有人发同一个模型的厂商，做不到这一点。
- 缓存是一份公开的契约。格式有文档，已经有两种语言在写它。一位摄影师十年的判断，永远能用
sqlite3读出来——对面是一个别人打不开的专有目录。 - Mac 当服务器，直接删掉了最难的问题。没有同步，就没有合并、没有冲突、没有“哪台设备说了算”——而这正是最接近的竞品花掉工程和客服预算的地方。
- 它做组合，不做占有。输出 XMP 旁车文件，一个拍摄在 Lightroom 或 Capture One 里打开，旗标和星级原样都在；苹果“照片”图库原地读取，什么都不导入。它站在两家老牌产品旁边，而不是对面，也不必赢下整条工作流。
- 判断跟着照片走。身份认的是画面，不是文件：改名、移动、别的程序写入的星级、RAW 和它的 JPEG、另一个拍摄里的副本、在“照片”里做过的编辑——判断都还挂在上面。
- 浏览器客户端几乎白送。一个带 24 个接口的网页工作台已经存在。Mylio 完全没有浏览器访问。
- 零成本，零托管，零责任。客户的照片从不经过任何第三方之手。
W 劣势
- Mac 必须醒着、连得上。这是设计的直接代价，没有商量余地。飞机上用不了。
- 判断表只有一份。同步曾是竞品无意中附带的备份；拒绝同步，就有义务把唯一无法重算的东西导出来。已排进计划，尚未解决。
- 图库管理还年轻。有涵盖所有拍摄（包括未接入硬盘上的拍摄）的全局目录、时间线、相簿、关键词和搜索——没有地图。Mylio 在这上面做了十二年。
- 不解码 RAW，不做显影。不做 RAW 处理是有意为之；但缺少解码，对高光的准确性是个真缺口。
- 打包只做了一半。app 是一个自包含的程序包，不需要 Python，自带 Core ML 模型，约 520 MB。尚未签名，未经公证，也没有安装程序。
- 没有手机 app，没有 Windows，没有 Android。
- “照片”只读，尚未写回。相簿可以原地挑片，但判断还不能写回“照片”，修图也还不能存成“照片”里的一次编辑。
- 只有一个人。没有公司，没有客服，没有安装程序。
O 机会
- 一个不能上传的市场。签了保密协议的工作——企业、法律、医疗、新闻——在结构上对所有云端挑片服务关闭。“永不离开你的 Mac”在那里不是功能，是入场条件。
- 三者兼备的位置确实空着，而且空了好些年，这说明它是不显眼，而不是没价值。
- 私有组网变得轻而易举，这正是这套架构如今可行的原因。
- Apple 芯片让 Mac 成为一台正经、安静、便宜的服务器，硬件恰好为这里跑的这类模型而生。
- 开放格式是切入点。对一个被目录迁移坑过的职业摄影师来说，“你的判断存在一个有文档的 SQLite 文件里”是一个具体、可验证的承诺。
- 自托管已成常态，而那个圈子里没有谁有挑片智能。
- 苹果“照片”用户完全没有挑片工具。这个平台上最大的照片图库会归组连拍和人物，却从不说哪张清晰；原地读取它，就去掉了导入这一步——否则那会是用户说“不”的头一个理由。
T 威胁
- AfterShoot 加上本地模式或图库管理。这几条里最可能发生的：它已经有智能，也有用户心智。
- Adobe 把连拍挑片做好。对已经在订阅的人来说，核心差异就此蒸发。
- Mylio 加上挑片。它有文件模型、有同步、有 app。十二年都没做，说明这不合它的本能——但一旦注意到，这是显而易见的一步。
- Apple 在“照片”里做了。考虑到它面向消费者的方向，可能性低。一旦发生就是生死问题——而现在读取“照片”已是卖点之一，就更是如此。
- macOS 的电源管理。被低估了，真正的技术敌人是它，而不是网络：App Nap、Power Nap、睡眠、完全磁盘访问权限、沙盒、公证。让一个后台服务在 Mac 上一直活着、随叫随应，才是这里难啃的工程。
- 模型授权。目前使用的 InsightFace 人脸模型（已转换为 Core ML）只许用于非商业研究，而人脸身份识别恰恰是 Apple 自家框架没有对应物的部分。替换它们，意味着把所有按它们校准的阈值重新推导一遍。它不妨碍开发；它决定的是这一切能否成为产品，而且尚无着落。
- 赌注可能就是错的，人们可能真的想在飞机上用。架构不会为此弯曲。
实际已经造出来的
工程现状
曾有一个问题可能直接毙掉这套架构：那两个在 Apple 体系里没有对应物的模型，能否离开 Python。 能。在 CPU 上，同一个 ONNX 文件在 Swift 和 Python 里产生逐位相同的输出——最大绝对差 0.000e+00。 在神经网络引擎上结果略有差异，但快十四倍；把实测差异注入真实图库后，全部 516 张脸仍落在原来的 25 个聚类里， 离任何变动还有大约三倍的余量。
这就是计划与希望的区别，而且是在动手建任何东西之前，用一个用完即弃的测试工具确认的。
此后它确实被建起来了。app 现在用 Swift 完成扫描、判断、人物归组和学习摄影师的口味，模型跑在 Core ML 上， 不需要 Python。同一场 435 张的婚礼，完整扫描不到一分钟；全部 435 个判断和全部 516 张脸的人物编号都与引擎一致， 方向检测在 435 张中有 434 张一致。修图在测试样例上与引擎逐字节一致。
纪律——因为这是最难复制的东西
这个项目里有四个常数最初是猜的，而且错得离谱——清晰度阈值差了五十倍，还有一组关键点索引、一个聚类的兜底方案。 此后的惯例是：每个阈值都在源代码里写明推导过程和实测数字，并有一个测试把它钉死。 一个图像质量模型经过测量，发现它会奖励过曝的高光，于是被排除。方向检测宁可弃权也不瞎猜， 而且检测结果只在摄影师要求时才会应用。
这不是功能清单，也没法拿去做营销，但产品页上的那些数字之所以敢写出来，靠的就是它——而且它会复利累积，功能清单不会。
先后次序
排序原则是：风险最大的假设，用最便宜的测试最先验证；凡是现在只需几百行、往后却要做数据迁移的事， 都要在上面盖任何东西之前先做掉。
现在便宜，往后要命
基于内容的照片身份，以及那张不可替代的表的导出，都已完成。模型授权还没有：它决定这东西究竟能不能成为产品，目前仍悬而未决。
从手机上用 下一步
通过私有网络使用现有的网页工作台。几乎不用写新代码，是对核心赌注最便宜的测试。在家庭网络内用手机已经可行；在外面通过 Tailscale 访问还没测，Swift 版的手机服务器就等这个测试的结果。
闭环
导出、给人物命名并设优先级、在 app 内发起扫描。去掉了工作中途打开终端的最后一个理由。
跨越各个拍摄的统一图库
日期、相簿、跨文件夹的人物，还知道某个拍摄在那块没插上的硬盘里——这件事 Lightroom 做得很差，“照片”根本做不到。
甩掉 Python
测量、判断、人物归组和口味学习全部迁入 Swift，模型转换为 Core ML，并在一整个拍摄上与引擎逐一核对。app 程序包自带模型，无需代码仓库、无需 Python 即可运行。剩下签名和公证。
修图
瘦脸、磨皮、去瑕疵、拉直与裁剪，在 app 内实时预览，在测试样例上与引擎的像素逐字节一致。不生成任何内容，原图永不被覆盖。
坦白版
下面每一条都是这件事可能失败的理由，写得毫不含糊——因为投资人的工作就是把它们找出来， 如果它们已经写在页面上，会省事得多。
赌注可能是错的
“你的 Mac 就是服务器”，这一个决定撑着整个设计。如果摄影师更想在飞机上用 iPad 看图库， 胜过想让照片永不离开家，那么架构弯不过来——那将是一次重写，而早已解决同步问题的竞品会赢。
老牌产品可以把这个空位填上
眼部清晰度和连拍对比既不能申请专利，一旦有人决定去做，也不算特别难。守得住的部分不是测量本身， 而是按摄影师定制的偏好模型、开放格式，以及拒绝上传——而这三者中只有最后一项是云公司难以复制的， 因为那就是它们的商业模式。
范围失控是最可能的死法
一个挑片工具，一个人撑得住。一个图库，加一个手机客户端，再加一个必须扛住 macOS 电源管理的服务， 就是另一个数量级了。上面的先后次序，就是为了让这种失败早点暴露，而不是到最后才现形。
还没有商业模式
一次性授权、付费专业版、开源加付费支持，都说得通，但都没验证过。这套架构恰好对三者都友好—— 不用运营服务器，就意味着每多一个用户没有边际成本——但这是一个观察，不是一个计划。
需要哪些前提成立
决定这件事的问题，没有一个能靠多写代码来回答。
- 摄影师会不会为了文件永不离开 Mac，而接受“Mac 必须开着”？一周内就能测，也是下一件要做的事：在家庭网络内可行，在外面还没试过。
- 签保密协议的工作是否普遍到足以构成一个市场，还是出了少数几个细分领域就可以忽略不计？
- 挑片挑得可测地更好，真的会改变谁买什么吗？还是一句“AfterShoot 够用了，而且已经装好了”就结束了对话？
- 开放、有文档的缓存会成为任何人换用的理由吗，还是只有工程师才在乎？
- 一个人能撑起一个图库产品吗，还是一有用户就需要一个团队？
其中第一个很便宜，已经排上日程。其余的需要的是摄影师，不是代码。