最近一段时间重点在维护两个工具产品。第一个是 TranslateP，开源后主要在修复大家的问题，自己的诉求早已满足。第二个是 PFollow，这个产品原本设想挺大的，但经过一些调整还是决定从小做起，最终带来了全新的模式，回忆感拉满，我很喜欢。

前言

先说说最近的状态再进入主题吧。年后回京后，开始和年前约的一些人聊了聊。按照最初的想法，给自己留了一年的 buff 去任性的做一些事情，这些事情是什么都可以，但也不拒绝接触找上门来的事情。因为命运这只大手谁知道轻轻的这么一扒拉，会以何种方式给你一个点拨呢。尽量不去拒绝任何人和事的发生，但要听从内心。

目前找上门的有三个方向的事，具体是谁和做什么的就不说了，纯务虚。这三个事都是熟人介绍，我觉得挺有意思的。对我比较了解或者看过我之前博客的朋友肯定知道我大学时有三大目标，其中之一就是“让工作来找自己”。这个事情底下有一个本质的思考，最近几年发生的事越发的佐证了这个思考结果的可信度，那就是工作都是「聊出来的」。越在面试过程中唧唧歪歪、磨磨唧唧的大概率会凉透。越是在面试过程中像朋友一样好好的、平等的「坐下来聊」，大概率当天就可以拿到 offer。

我现在快要把这个思考结果作为「人生律例」了，希望能打脸。等再过一段时间再来说说当下这个时代背景下我对面试的看法，之前写过关于面试的几篇文章，都是不同时期下的思考结果，每次回去看都挺有意思的。就目前的感受来看，还是存在不少用上一个时代的范式来招聘，不管是对招聘方还是候选人都不够公平客观，很容易聊不下去，互相浪费时间。

还有一点观察，我现在越来越不想与人争辩了。比如之前可能会敏锐的捕捉到一个人在一件事或者一段话的错误，马上就点出来或者修正。这本身也没错，毕竟人无完人，本身我也想让别人指出我的问题。现在就变成了你说什么我都静静地听着，就算你说到了我的心坎上，我也静静地听着，因为想观察一个人的完整表达。

这点改变在最近和一个朋友接触过程中被他发现了。他说和上一个人聊的过程中都没有让他把话说完，而我就这么安静地坐着听。其实我确实没有太感受到这个变化，但被这么点了下后，才发现原来让人把话说完是一件这么重要的事情。最后当然聊得也很好，观察出了这个第一次见面的朋友有很多我值得学习的地方，期待未来的发展。

TranslateP

还在年前假期中时就收到了一封反馈 TranslateP 问题的邮件，说实话非常意外。我做这个工具的初衷就是解决自己的问题，发现无法找到商业化思路后开源罢了。反而开源之后，我对这个工具的心态有了个比较大的转变，来的用户也翻倍了，真实情况确实也卖了一点点钱，是个意外。

反馈邮件里说的问题主要是多行翻译后，翻译结果窗口高度不对，用户在邮件中推测是不是他的 M4 MacBook Air 有兼容问题。当然肯定是没有兼容问题的，这个事情很早就发现了，但一直觉得没啥必要去修，做给自己用的东西，能用就行。

本质问题就是 SwiftUI 的高度渲染计算和 Text 标签内容高度计算二者出了差异。修复的思路也很简单把邮件截图丢给 AI 就完事了，反正不能改字体只能改字号，并且翻译结果窗口的宽度是固定的，最终只需要根据字号大小和翻译后的字数估算一个宽高即可。这个思路系统都有完整 API 可以解决，本质就是计算一段字符串在固定width或 者height下最终的boundingBox多大。

此外就是把一些之前想做但困于时间和优先级问题而没做的事情给彻底都加上了，比如「查词」和「单词本」功能，尤其是单词本。在之前的 roadmap 中单词本是作为一大收费利器的，大概的思路是查词后跨平台复习。但经过较长一段时间的平静后，我对这个功能的兴趣不大了，主要是没有场景和目的的学习没有意义，通过坚持做一件事是不长久的。

有个观点我挺喜欢的，一个教育家在解答家长的问题。家长问到“我不能不给孩子报课外班呀，因为他的英语实在是不好，我们担心他的英语”，教育家一语点破，“你们有带孩子去过美国吗？去一趟他自然会明白，没去过的话，家长努力带孩子去一趟吧”。

至于单词本，因为并不想做大，基于 md 格式做了一份本地文件存储后就算暂告一段落了。如果哪个用户想导出曾经查过的词，拿着这份 md 文件自己用 AI 自行 filtering 一波数据都能按照想要的格式处理好。

提审的时候更有意思，给了两次拒绝。第一次果子说这个翻译软件并没有提供给残障人士用的功能，为什么要申请辅助功能权限，言下之意就是让我把监听两次 cmd + c 快捷键的功能给去除。我想了想，确实有道理，换了个方案，通过让用户自定义两次 cmd + c 快捷键间隔时间来做监听。唯一膈应的地方就是 observer 会一直在跑着，可能会比之前耗点电。实际上用辅助功能去做，区别就是是用系统的硬件 IO 循环还是自己的循环了，耗电问题可以忽略不计吧。

第二次拒绝的理由居然说这个翻译 app 和系统自带的翻译软件太像了，当时我就有点黑人问号。直接回了邮件解释了几点，总之就是跟果子说了你不要无中生有，暗度陈仓。好在一切都比较顺利，审核通过后 app store 上的最新版本号是 1.0.7。

这个翻译软件我确实真的没想到有人会用它，因为完全没有把心思放在它上面。现在开源了后，只是在 app store 上象征性的收了 1 元人民币（其他国家和地区等价 0.99 美金），但就是这么一收费，居然还来了一些用户。过去一年虽然只有百位数的下载量，但开始收费后也稍微挣了几十元吧。虽然聊胜于无，但这个观察还挺有意思的，当你高调性或者象征性的拦截一部分用户后，反而能筛选进来更符合你预期的用户。

不过以后大的方向上就是看用户反馈了，没人反馈就这么放着了，已经捐献给了 PJ.Studio 组织。目前我对 PJ.Studio 还没有具体的想法，去年 9 月也只是心一热把域名给拿下了，觉得还挺酷的。现在想起来依旧觉得很酷，还有几个域名想搞，有机会可以再推进。

PFollow

接下来，将分为「产品迭代」和「性能优化」两部分进行分享 PFollow。

产品策略

PFollow 在最新 1.2 版本中，产品层面我主要加上了「地点收藏」、「地点罐子」和「旅程模式」。

地点收藏比较好理解，我出去玩耍时会在小红书上收藏很多帖子，比如出国的话出机场怎么坐车去市中心之类的会收藏不少。但本身因为这些事情其他产品做得都比 PFollow 要好，比如小红书的实效性无敌了，直面竞争只会死得体无完肤。换个思路，我提供了另外一层的数据，如果有类似的地点收集癖用户可以自己筛选先去的特殊标签点专辑，自动匹配去过的地方，增加一个维度给更小众的需求人群吧，

地点罐子这个东西是延续了九年前实习时做的一个游戏思路。基于设备的陀螺仪和物理引擎搭了个框架，筛选用户去过的地方包括国家、中国省份、5A 景区、一级博物馆和历史文化名城都会自动检索到不同的罐子里，罐子里的「珠子」会跟随用户设备的倾斜角度而移动，我自己体验下来还可以，希望你能喜欢。

接下来要花费较大的篇幅说清楚本次更新的重中之重——旅程模式。

PFollow 在过去的很长一段时间里都专注在单个离散的照片点，铺洒在地图上。简单的给了用户一个立体的感受，自己曾经去过的这些地方都在地球上的哪里。但不管是用已有的时间尺去筛选一段时间里的照片，还是通过地点筛选，看到的都是一堆离散的点，很难串起整条回忆线。

在最初的规划里，我有想过做导入 GPX 文件或者提供轨迹记录的方式帮助用户记录下一趟旅程的轨迹，但仔细琢磨了几回觉得这事都不太行。首先是外出旅行的过程中就应该全身心的投入到当地文化的感受中，而不是还要盯着轨迹记没记上，这个 app 开没开等等增加负担的行为，因此排除掉了做「一生足迹」和「世界迷雾」类似竞品的能力。

其次导入 GPX 文件或者读取 apple 健康甚至是 Strave、Garmin 等二方或者三方 app 的数据这事和 PFollow 的调性不对，如果说 PFollow 是一个自我管理的数据平台，尽可能多的收集和展示用户自身的数据，成为一个数据展示和管理的工具产品，自我管理或自我量化的话，这个思路才是对的。并且最近观察到有在收紧对轨迹记录的产品管控，这事不是很适合个人去做，特别是映射回真实地图上的轨迹记录，风险在加大。

最后是还要再强调下 PFollow 是一款通过用户本机照片数据，提供与系统相册不同的照片浏览和回忆方式的产品。目的是让用户换一种方式去看自己曾经去过的地方。我并不想做一款「AI 旅行规划」产品，现在看到 AI + 旅行头都要大了，我很想跟做这些产品的人说别折腾了，因为这根本就是个死局。

因为旅行决策太复杂了，AI 难以替代人类的情感。用户可能今天想「穷游」明天又想「奢侈一把」，AI 无法实时捕捉这种情绪变化。以及无法应对突发情况的灵活性，航班取消、天气突变甚至是临时想改行程，强行用 AI 去「严丝合缝」的计划反而成为负担。而旅行的魅力恰恰在于「不确定性」，而 AI 试图用「确定性」去规划，本身就是矛盾的。因此我一直在找如何把照片可以更好的串联起来，给用户提供一个完整的回忆就足够了，至于旅行中即将或者已经发生的事情，放宽心去体验就好。

顺着「点线面」的思路走下去，点已经完成了，下一步当然就是线了。仅仅通过照片就帮用户筛选出一段段完整的旅程这件事本身是不容易的，因为你不知道一段旅程里用户如何才算叫进入「旅行状态」，何时想结束。一开始思路有点走歪，设计的策略比较大，简单来说就是被现有的产品给带歪了。比如如何精准切割多国链接和多省份链接，还考虑到用户可能想在一段长旅程里切割出多段小旅程进行查阅，甚至还出现了多段旅程经过同一个点时如何展示出多条旅程线等等。

后来想得烦了，回归「完成比完美更重要」的王道，这些策略逻辑全给删了，只留下了最简单最纯粹的时间维度，只要照片之间相距在 24 小时之内都算同一旅程线。只是在分享旅程线的时候增加了「反选」功能，如果有不想被看到的照片取消选中即可，并且旅程线会实时的重新绘制。这样，就通过了最简单的产品策略先把功能做完，后面观察用户反馈再继续。

我逐渐变得更少的去看竞品去看别人怎么做的，而是变成我想做成什么样的，尽可能快的做完。但我还是会去看很多别人的思路，别的开发者是如何拆解类似问题，通过什么样的方式去解决的。在看的过程中逐渐发现，类似的产品很多，多如牛毛，精品并不多。以前我很喜欢「独立开发者」这个身份，因为它代表着某些特质，比如「品质感」和「专注感」，独立开发者们可以做大厂或者小团队看不上的方向和思路，花费大量的精力去打磨一个垂类甚至一个问题，我很喜欢这种思路。

这里要重点宣传下 PolarSteps 这个产品，基本上它达到了我下一步对 PFollow 的初步框架，而且盈利方式很有意思。首先 PolarSteps 整体是个免费产品，最主要的功能是提供自动轨迹记录、地图日记、旅行统计和最重要的旅行书。旅行书提供免费的 PDF 版本和付费的实体精装书，而售卖整条旅程线的实体书服务也是他们的主要收入来源，另外再加上自定义分享范围的旅程线，整个产品给我感觉完善度非常高。

但我不太喜欢他们现在重点推的目的地旅程，原因还是跟前面说的不喜欢 AI + 旅行背后的原因一样。不过他们可能有营收压力吧，会收一些广告主的付广告付费，在旅程推荐和规划里加上这些广告主，有点像当代孤独星球的意思了。

不知道后面自己还有没有时间继续做这件事，先透露出来吧，能够吸引到有识之士一起做当然是更好。PFollow 下一步的产品规划想做「旅途跟踪」。开始一段旅程后，每天可以分享一句话和一张照片到旅程线上，分享给互联网或者私密的朋友们。如果你有用过 garmin 的队友跟踪功能，其实很类似。

性能优化

至于优化层面主要是解决了查询去过的地方过慢的问题，现在重新安装或者更新版本后会发现去过的地方在一分钟之内都可以查询完毕。之前确实走到了死胡同里，认为从用户照片的 exif 信息里解析出了 GPS 点位后，想要知道这张照片的 GPS 点位到底是哪里，需要做一次「地理信息反查询」。iOS 自带的 MapKit 有这个 API 能力可以支持，但很慢，大批量查询非常容易触碰到限流策略。

常规思路就是找一个允许大批量反查的 API 接口或者工具交钱就完事了，最终发现如果要找高德的话，需要先交 5 万拿到「开户」资格，再根据 API 调用次数收费，每个月有固定的免费额度。如果换用 MapBox 查询不需要先交钱，但依旧会有固定免费额度，用光后依旧要交钱。我不是不愿意交钱，而是总觉得这事不应该交这么多钱。

过去了一段时间后本来想逃避这个问题的，因为除了交钱貌似没有更好的解法，有点死胡同了。在做地点罐子和旅程模式两个功能中发现，如果不彻底解决查询慢的问题，这俩功能也别做了，相当于 PFollow 接下来的每一个我想做的需求都做不了。此时我开始仔细推演这里的关键问题，现在已经有了 GPS 点位，要做的只是把 GPS 点位在哪个省范围或者市县范围甚至是国家范围就足够了。

那么是不是可以找到一个范围数据，通过 GPS 点位做范围比对就行。如果某张照片的 GPS 点位数据在某个区域范围里，本身就是代表去了这个地方，没必要非得通过某个 API 「查出来」。想通这件事后，我开始怀疑其实 API 提供商背后说不定也是这套策略，固化了一套 GeoJson 边界数据外加一套区域规划和街道信息来卖钱。明确了思路剩下的事情就是去找数据源了，关于中国市县、省份和国家边界区划的数据有很多源在做这个事，就不公开了。但千万要注意我们自己国家的关键边界信息，不要被别有用心之人利用了。

下一个版本

下一个版本我准备搞个更大的，目前 PFollow 的整体产品框架搭好了，后面除了思考如何把目前已有的模块都给完善好，就主要做「旅程跟踪」了。我对这事还挺感兴趣的，因为总算可以再次全栈了！18 年和毕设时的两次全栈经历真是让我爽了好久，第一次有服务端视角、有全局视角、有 leader 视角去看待每一端在一个项目中的作用，爽飞了！

对 PFollow 这次的版本更新真是呕心沥血，做得昏天黑地的。但不得不承认如果没有 AI Coding 的帮助，真的是还要痛苦好久。大概算了下从 24 年 11 月开始到今天总共给各种 AI Coding 工具交的钱，都不到三千元人民币，虽然中间因为上班耽误了不少想做的事，但我的预期是要在近期要把这些 AI 工具的费用再至少再扩大 10 倍。这确实是实打实的提效，帮我实现了很多之前想做的事。

总结

目前网络上对 AI Coding 的趋势发展成这样挺悲观的，但我并不担心，很期待程序员这个岗位彻底消失的那一天。本身写代码这件事就是越来越容易，现在只有非常少的 case 还要盯着汇编看，涉及到极致的性能优化、老项目维护和疑难 crash 时都需要用上全套吃饭的家伙。但可以推测的未来发展的方向可能是，再差就换条路走，难道我们还要回头去打孔、去写汇编吗？我一直不觉得这是件美妙的事。

就是因为编程语言变得与自然语言更接近了，我们才能基于此构建出更广大的产品和平台，可以加速创造出一些东西，这些东西有好有坏，但量变才会引起质变。可以畅想如果以后真的出现了一个东西可以做人类和计算机的翻译者，精准的把人类的思想转换成计算机能理解和实施的方案，我们只需要做验收，这能够带来多大的改变啊！尤其是把曾经那一波就是作为产品经理和计算机沟通的程序员岗位给取代了才是更好，这样人人都是产品经理的时代才能真正降临。

现在慢慢发现我可能只是喜欢计算机但并不喜欢写代码，写代码只是擅长的事。但我更喜欢在计算机前做些事情，甚至是通过计算机去感受一些现实世界里感受不到的东西，写代码只是能够让我更长久接触到计算机的一个方式。

本身我就觉得程序员这个岗位有点奇怪，非要类比的话就是接线员了。明明你可以直接给对方打电话，但以前居然还需要一个接线员帮你路由，现在想起来确实有点意思。甚至我觉得程序员都不能算作是一个「职业」或者「岗位」，因为他没有任何的行业知识壁垒。比如曾经都很嫌弃的图书管理系统，我们要的是系统本身，服务的是管理图书，需要程序员来写这个系统，只是因为系统正在构建中。

当构建完成的那一刻，这个系统受益的或者服务的对象是图书馆和书二者，甚至也没有图书管理员什么事，更别说程序员。其实你会发现程序员在这个其中所承担的角色或者价值极低，因为把程序员这个身份标签已经把自己给限制住了，你无法参与到这个真正的系统当中。甚至你都不知道这个系统背后真正的价值是什么，因为程序员只负责构建。

但我并不是不尊重技术，本身我也是个程序员，确实作为程序员也赚到了一点钱。但一直觉得这感觉不对，不是我当初所想象的那个感觉，但我现在不知道怎么说，可能我更尊重的是「创造」本身吧。或者现在把 Coder 换成 Builder 更好，我们这些有想法 Coder 会不会只是喜欢创造，本质上是想做一名 Builder 呢？当我们把视角转变成一个 Builder 构建起整套链路时，程序员原本所处在的环节只是这条链路上的一环罢了，好像这种说法更能表达我的思考。

现在确实是程序员的末法时代了，真修实证的极少、邪见横行、门槛变极低，看着只有程序员才会明白程序员这一行究竟有多难，但好在大家对处在 AI 岗位里的程序员还有尊重，也算是个安慰。但千万别忘了，AI 不能代替你看风景，不能代替你享受人生。