AI 时代的到来，我到底要不要转行？

在 2023 年 2 月 1 日，OpenAI 正式对外发布了 ChatGPT 的 3.5 版本，标志着通用 AI 技术正式「破圈」，不但引爆了计算机行业，也同时引起非计算机行业的广泛关注。对于身处计算机行业内的程序员们，也第一次深深的感受到了巨大焦虑。因为这一波 AI 技术在生成常见代码上有了肉眼可见的巨大进步。

2023 年 3 月，我自己正好经历了公司裁员，面临寻找下一份工作的困境。而与此到来的 AI，让我变得更加焦虑，期间甚至有过考虑转行的短暂尝试。所以，「AI 时代的到来，我到底要不要转行」这个问题也让我不得不有更多的思考。

经过过去一年多的发展和观察，虽然 AI 行业还在快速发展，但新闻舆论的声音似乎小了一些。同时也给了我自己一些时间来思考一下自己未来的职业道路。

那么，AI 时代的到来，我到底要不要转行？先说我自己的结论，短期内可以不用转行。这个短期是多短？我自己主观判断是至少「十年」。

为什么说是「十年」？我已经说过了，是主观判断……

那这「十年」的鸿沟是什么？现在 AI 不是已经可以生成代码了吗？甚至可以生成简单的软件项目。为什么不是两三年就完全取代程序员？因为这一波 AI 是以人类的自然语言作为输入，以生成式文字作为输出。然而人类的自然语言与编程语言之间最大的区别就是逻辑严谨性或者说是精确性。

程序员这个职业之所以存在，解决的核心问题就是将不精准的人类语言转换成精确的编程语言，以此来控制计算机。如果有一天 AI 可以将人类语言通过某种方式或者方案精准的转换成编程语言，那么程序员这个职业才会真正面临着彻底消失。

所以我上边说的「十年」只是给了一个相对长的时间范围。当然，也有人说三五年。我不是 AI 专家，所以在这一点上给不了精确的时间。但如果一个「专家」现在告诉你十年之内必定会「xxxxx」，其可信度也同样值得商榷。除非他能严谨的论证自己的结论。否则都可以看作是主观判断。

如果短期内程序员这个职业还能存活一段时间，那么 AI 的到来对这个职业会有哪些影响呢？

首先，就像网上很多媒体说的那样。AI 的到来一定会提升开发效率。这会不会导致从业人员锐减？以前需要十个人，现在只需要两三个人就可以搞定同样的开发任务。我认为短期内「会」，但长期不好说。为什么呢？因为市场一直在变化，如果市场能挖掘出新的需求，那么剩余的七个人依然可以继续从业。

其次，AI 的到来，肯定会进一步降低入门的门槛。但，同时也会拉升「专业」的门槛。现如今，即便是没有经过专业学习的人员，也可以通用 AI 生成一段代码片段来解决眼下特定的问题。这种情况下，可以被看作是一种入门门槛的降低。这意味着初级开发人员可以被部分非专业人员替代。相对而言，以前初级开发人员就需要提升技术水平才能入行，即所谓拉升了入行的门槛。所以，短期内开发人员供给会受到一定冲击。当然，现如今市场状况原本就不好，所以不能将当下的就业问题简单看作是 AI 的冲击。AI 只是未来一段时间的一方面原因，并不是全部。

最后，长期来看，其实是提高了成为专业程序员的门槛。至于市场到底还需不需要更多的开发人员，得具体看市场的发展需求。不过，关于这一点，我还是保持乐观的态度。私以为，万物互联的时代才刚刚开始，编程介质会越来越多样化。之前集中在 PC、手机 App。未来会有更多的可编程介质出现，至于需要多少开发人员我不知道，但是一定会是专业化更高的开发人员。

Kagi 搜索引擎

大概一个月前，将 Arc 浏览器换成了日常使用的默认浏览器，替换了过去用了将近十年的 Safari 浏览器。Chrome 浏览器也仅仅用作开发浏览器，日常使用是不会用的，原因也很简单，太占用内存，用起来感觉非常的「笨重」。

大概三周前，从 Arc 浏览器里的可选搜索引擎里了解到 Kagi 搜索。

说起来，在 Arc 浏览器里最先体验的搜索引擎是 Perplexity.ai。但因为日常使用代理访问网络，每隔一段时间不用再次访问就会触发 Cloudflare 的「人类」验证机制，很烦人。在寻找替换搜索引擎的时候，这才了解到 Kagi。

话说 Kagi 搜索引擎用了大概两天，我就决定将 Google 替换掉。最核心的原因就是因为没有广告。由于 Kagi 的搜索结果里没有广告，所以 Kagi 的收入基本来自付费订阅。我目前订阅了「乞丐版」，按照 Kagi 文档里的推荐，对于大多数使用者来说，基础版就已经够用了。将近三周用下来，也确实如官方文档里所述，远远用不完。当然，也可能是因为最近这段时间工作太忙，导致没有时间划水有关……

Kagi 除了没有广告之外，目前体验下来，搜索结果比 Google 也不差，特别是英文内容，我自己体验下来没有什么太大的差别。中文内容也几乎没有出现搜不到有用东西的情况，当然比百度要强太多了，单就没有广告这一条就甩百度几条街。

使用 Kagi 搜索，需要用户登陆，因为 Kagi 可以提供个性化搜索。比如我在这段时间使用过程中，将中文搜索结果中的百度内容权重降低了很多，所以即便是中文内容，百度的搜索内容也会出现的很少。当然，也可以将某个网站的搜索权重提高，这样对于一些有价值的小型网站会友好很多，同时也可以帮助你更准确找到相关内容。

Kagi 对于更高级的付费用户提供 Ai 搜索，目前对我来说还用不到，或者说，我还有其他可以用的 Ai 替代品，也许以后其他替代品到期之后也说不定会继续订阅 Kagi 的更高级服务。

总体使用下来，搜索页面上再也看不到广告了，也不会因为前脚搜索某个商品，下一秒「某宝」上就会给你推荐相关产品。

使用搜索引擎这么多年，第一次让我对搜索结果有一种清新的感觉，非常棒！

暂时关闭了播客的独立站点

关闭了今年一月份建立的独立播客站点。

原因是因为经过两个月的实际操作，实在没有时间来录制播客，即便后续如果有，也不会太频繁，算来倒不如暂时托管在 YouTube 上，以此节省成本。

理想总是很美好，但还是要面对客观现实，把精力集中放在最重要的事情上。不能再犯十年前的错误。

另外，还有一个小小的感悟。

十年前当初决定技术方向转型的时候虽然年纪也不小了，按照行业的「规矩」，过不了三五年就会面临「大龄」问题而被淘汰。

记得当年独立开发者失败之后，兜里已经没钱了。在两年多没进公司工作的情况下，加上 Web 开发几乎零经验，能成功转型也是堪称一个奇迹。真是「自信」即巅峰，自助者天助。

Arc 浏览器使用体验

过去一周时间，尝试了 Arc 浏览器。体验可以说是非常的好，甚至将其设置成了默认浏览器。同时也将 iOS 上的默认浏览器也切换成了 Arc。可惜没有 iPad 版，iPad 上的版本是 iOS 的兼容版。

喜欢的点

  • 淡化 URL

Arc 访问 Web，更像是访问本地应用，如果网络足够快，Web 应用体验很好，使用过程中要比现有的浏览器有更好的沉浸感。甚至在使用的某一个瞬间几乎忘记是在使用Web 应用。

  • 多 Space

所谓的 Space，就是使用场景。使用场景之间的切换真是方便太多了，只需要手指左右滑动，即可完成场景的切换。工作和个人的 Space 切换，让不同内容互不干扰。

  • 将默认搜索引擎从 Google 切换成了 Perplexity

目前还不敢确认能否最终替换 Google。因为经过过去一周的使用，除了每天在第一次使用的时候会触发 Cloudflare 的安全检测以外，又发现一个新的问题，就是对给出的结果还是不太多元化。

怎么说呢？在大多数时候，Perplexity 给出的前六个搜索结果都还行。但如果想探求更多的不同信息，想要进一步交叉验证，就变得有些困难。不过，对于大多数使用场景，其实体验已经很好了，这一点还是有一说一。

  • 方便的 Split 双开

Arc 可以很方便的左右双开，加上自带的笔记功能，可以左边打开在线资料，右边打开笔记，一边看资料，一边做笔记，非常的方便和自然。

体验了一次左边开YouTube 视频讲解，右边做笔记，非常丝滑。

  • iOS 版本不是 macOS 版本的延续

iOS 版本跟 macOS 版本没有什么太大的关联，基本上交互是自成体系。iOS 版本的使用体验目前也还挺好的，自有其特色。关键还是脑袋里不要总是想着 macOS 版本与 iOS 版本有什么关联就还好。

  • 实用的小工具

macOS 版本有很多很实用的小工具。比如快速的截屏工具，可以自定义网页的 Boost 工具，以及提供可以在线分享文档，也就是上边提到的笔记可以通过在线链接的方式分享给第三方。

  • AI 加持

现在 AI 已经深入到各个产品，Arc 也不例外，提供了很多 AI 加持的工具，比如 iOS 版本对网页的归纳总结功能。macOS 版本通过 ChatGPT 直接回答问题等。

不完美的点

  • 没办法将 macOS 版本的密码同步到 iOS 版

目前来看，这个功能还在探索中，想必还没有考虑清楚。原因么，大概也是因为 iOS 版本的交互跟 macOS 版本差异太大，统一的技术方案还在探索中吧。另外，Windows 版本还在研发阶段，开发资源或许比较紧张吧。

  • 基于 Chromium 的 macOS 版本还不够完美

目前 macOS 版本一旦涉及到 Chromium 的个别设定，还是会有一些瑕疵或者说小 bug，但是不至于影响使用。只不过让强迫症会有些难受。

  • macOS 版本的密码没办法导出

macOS 的密码除了不能与 iOS 版本同步以外，还不能独立导出。如果将 Safari 或者 Chrome 的密码导入，那么此时就无法将密码导出。所以这也是目前让我将密码导入变的很犹豫的点。

总结

Arc 是真的好用，完全打破了之前使用浏览器的使用体验。如果 Arc 能够流行起来，我大概率会从开发 App 产品重新优先考虑 Web 产品，原因就是因为在 Arc 上使用 Web 产品真的很像使用 App。

被上传了将近两百个 G

今天早上醒来发现国外的很多网站上不去了，虎躯一震，立马看了一下代理，竟然是流量用完了。

代理的流量计算是上行和下行的总和。登录后台，看了一下过往一个月的流量统计，发现上行流量占了将近两百个 G。上行流量突然增加的时间是从 2 月 23 日，也就是大年初三开始。那些天没有用过电脑，在家一直用手机上网，一时想不出来为什么流量猛增，而且还是上行流量。

紧接着又查了一下过往 24 小时的流量，发现 Proton Drive 仅在过去 12 小时上行流量就用了 7 个 G。虽然 2 月份的流量数据统计在 macOS 上已经不太好查到，但就过去 24 小时的流量使用情况来看，基本可以初步确定是 Proton Drive 干的。还有另外一个重要的原因，Proton Drive 上一共存储的数据也就 5 个多 G。单就这一晚上上传 7 个 G 流量来看，就完全不正常。

短暂考虑之后，决定将 iOS 和 macOS 上的 Proton Drive 立刻删除，并且以后会非常警惕第三方云端硬盘的 App。现在手机上只保留了一个 Dropbox，里边只会对 Ulysses 的文章做可选项的备份服务，其他数据全为空，并且日常处于关闭状态，需要的时候手动开启同步，用完立即关闭。以后自己搭建 NAS 之后再考虑开启日常备份。

一年一度的个人所得税申报踩坑

今年的个人所得税申报踩坑了，记录一下。

2019 年 1 月 1 日开始，实行个人所得税申报，一年一次。申报方式基本上都是通过一个叫「个人所得税」的手机 App。

老实说，我自己对财务真的是一窍不通，主要也是对这个不太感兴趣，所以往年的很多次申报都是我老婆帮我填写，我自己只填写过一次？好像只有第一次是我自己填的，总之印象里已经完全记不清了，只记得进入 App 之后一直点击「下一步」，然后就会有一个退税或追缴的结果。

今年因为工作原因，只能自己缴纳。

前几天在「个人所得税」App 上进行了预约。我竟然连每年申报之前都需要预约这事都忘的一干二净了，事后问了我老婆才隐约想起来，往年其实也是需要预约的。

今天是预约申报的日子。好在提前几天在「提醒事项」App 上添加了弹窗提醒，否则也是忘得一干二净了。

进入「个人所得税」App 首页，直接进行申报，麻溜点击「下一步」，不到一分钟，申请完毕，需要补交 x 元税费，金额比往年都多，我还纳闷为啥去年需要补交这么多？但我还是通过支付宝把钱给老实补缴了。把这事跟我老婆说了，她提醒我是不是没有填写「专项附加扣除」？我才隐约意识到，往年好像确实是先填写「专项附加扣除」，然后再申报。

随后在「个人所得税」App 上先重新填写「专项附加扣除」项，然后在已经申报的流程里找到了「重置申报」的按钮，重新填写。一路下一步，结果果然不仅不用补缴，还会退 x 元税费。

走完重置申报流程，申报的状态变成了「申请退税」，点击「申请退税」，弹窗提示「税款未入库，暂时无法申请退税，请稍后重试」。网上查了一下原因，是因为税款只是已扣除，还未进入国库，所以退税的流程需要等钱先进入国库，然后才能继续走下边的退税流程。网上查的信息是需要等待三到四个工作日。

想来如果有人跟我一样，不知道怎么报税，每年就会多交很多钱。如果一直没人提醒的话，就会一年又一年的补缴。这个「坑」挖的好哇，国库的税收只赚不赔。

其实，我想说的是，父母家人这种信息，其实 App 完全可以代劳，甚至独生子女也可以 App 代劳。这些信息在街道办早就已经有了。另外在填写申报之前，完全可以提醒用户是否有需要填写的「专项附加扣除」，甚至可以放在申报流程之前让用户优先确认，再不济也应该在填报流程开始前很醒目的告知用户，而不是悄无声息的直接就让用户申报。

SwiftUI 中的 @State 与 @Binding 和 @ObservableObject 与 @ObservedObject 以及全局 @EnvironmentObject 的极简示例

SwiftUI 提供了一套强大的属性包装器，帮助管理状态和数据流。以下是这几种属性包装器的定义和用法。

  1. @State 和 @Binding:

• @State

@State 是一个属性包装器，用于在 SwiftUI 视图中声明本地状态。当 @State 变量的值改变时，它将使视图失效，并促使视图重新渲染。它通常用于简单的本地组件状态，这些状态不需要共享给其他视图。

例如：

import SwiftUI

struct Content: View {
    @State private var isToggled = false

    var body: some View {
        Toggle("Switch", isOn: $isToggled)
    }
}

• @Binding

@Binding 是一个属性包装器，它提供了对一个 @State 属性的引用，或者其它 @Binding 属性的双向绑定。它允许不同的视图共享对同一状态的访问，并能相互更新状态。

例如，使用 @Binding 将状态传递到子视图：

import SwiftUI

struct Content: View {
    @State private var isToggled = false

    var body: some View {
        ChildView(isToggled: $isToggled)
    }
}

struct ChildView: View {
    @Binding var isToggled: Bool

    var body: some View {
        Toggle("Switch", isOn: $isToggled)
    }
}
  1. @ObservableObject 和 @ObservedObject:

• @ObservableObject

这是一个协议，当遵从该协议的类的某些属性被标记为 @Published 时，这些属性在发生变化会通知其订阅者。通常用于定义外部的数据模型或状态，这些模型或状态将被多个视图访问和修改。

import Combine
import SwiftUI

class MyModel: ObservableObject {
    @Published var isToggled = false
}

struct Content: View {
    @ObservedObject var model = MyModel()

    var body: some View {
        Toggle("Switch", isOn: $model.isToggled)
    }
}

• @ObservedObject

这个属性包装器用于声明一个视图要观察的 ObservableObject 实例。当这个实例的 @Published 属性发生变化时，它会重新渲染视图。

  1. @EnvironmentObject:

@EnvironmentObject 是一个属性包装器，用于从环境中获取一个由某个父视图提供的 ObservableObject 实例。这对于跨多个视图共享数据模型非常有用，不必显式地将模型一层一层传递下去。

例如，在根视图中提供环境对象，并在子视图中访问它：

import Combine
import SwiftUI

class SharedModel: ObservableObject {
    @Published var isToggled = false
}

struct Content: View {
    @StateObject var model = SharedModel()

    var body: some View {
        ChildView()
            .environmentObject(model)
    }
}

struct ChildView: View {
    @EnvironmentObject var model: SharedModel

    var body: some View {
        Toggle("Switch", isOn: $model.isToggled)
    }
}

使用 @EnvironmentObject 之前，需要确保在视图层级中的某个点已经往环境中注入了对象，通常是在视图树的顶层进行。如果在环境中找不到相应的对象，那么试图访问 @EnvironmentObject 会导致运行时错误。

如何将 Xcode 中 Vim 模式下的 JK 按键映射到 ESC 按键

自从 Xcode 推出 Vim 模式，我就研究了一下如何在 Xcode 中开启。

有趣的是我在日常使用中并不会将 Xcode 作为常用编辑器。甚至可以更绝对一些，日常工作学习中几乎就不会使用 Xcode。一来是因为 Xcode 太「重」，启动很慢。二来也不开发 iOS App。开启 Vim 模式的原因仅仅是因为好奇，加上日常自己写代码使用 Vim 较多，所以就想感受一下在 Xcode 中使用 Vim 是怎样一种体验。

对于 Vim 的使用，虽然会有很多快捷键，但使用最频繁的就是 ESC 按键。我在自己的 Vim 设置中，就是将 ESC 按键映射到了 JK 两个按键，也就是连续快速点击「J」和「K」就会触发 ESC 按键。

但 Xcode 并没有提供 Vim 模式下的自定义按键的映射功能。最近重新学习 iOS 开发，对于 ESC 按键的映射实在忍无可忍。终于让我找到了一种「曲线救国」的方案。

实现这个功能的是一款 macOS 系统下的开源键盘映射软件，名字叫「Karabiner-Elements」。

首先，直接到官网下载最新的版本。

接着，按照官方文档的截图示意进行授权安装。安装过程包括开启对应的系统权限，相应的根据提示开启即可。官方文档的步骤很详细，还配了截图，步骤不算多，很快就能设置完。

安装完成之后，本地启动「Karabiner-Elements」App，点击窗口左侧的「Complex Modifications」，如下图所示：

点击右侧设置界面顶部的「Add your own rule」按钮，将弹窗里的默认配置删除。打开 Gist 页面，复制里边的 json 配置信息，将其原封不动的粘贴到弹窗里，点击弹窗右上方的「Save」按钮，保存配置。完成之后即可看到一条名为「jk to escape for xcode」的配置。

此时，在Xcode 中开启 Vim 模式（如果已经是开启状态，可以直接体验），即可享有 「J」「K」 按键映射到 ESC 按键的丝滑体验。

Gist 中的配置是我根据网上找到的一份配置稍微进行了的修改，如果想自行修改配置，可参考官方配置手册。

如何在 Xcode 点击 command+S 保存时，自动对 Swift 代码进行格式化

开始学习 SwiftUI，发现 Xcode 貌似没有自动格式化的功能。网上找了一些资料，有些教程里的截图已经过时了，简单摸索后，重新总结了一下。

完成此功能，一共需要三步：

  1. 安装 SwiftFormat-for-xcode 插件
brew install --cask swiftformat-for-xcode
  1. 系统设置

插件安装完成后，需要先进行系统设置，路径如下：

系统设置 -> 隐私与安全性 -> 扩展 ->Xcode Source Editor

点击 Xcode Source Editor，出现一个弹窗，将 SwiftFormat勾选上。

此时，重启 Xcode，完成后会在 Xcode 的 Editor 选项下方出现 SwiftFormat 选项，说明 SwiftFormat 已经安装完成。

但如果想在 Xcode 点击 command + s 保存的时候执行格式化，还需要最后一步设置。

  1. keyboard 快捷键设置

按照如下路径，从系统设置进入：路径如下：

系统设置 -> 键盘 -> 键盘快捷键(键盘导航下方) -> App 快捷键

点击窗口右侧的 + 按钮，如下图所示添加快捷键：

其中 「Format File」可以根据你喜好编辑为「Format Selection」或「Lint File」，点击「完成」即全部设置完毕。

此时，在 Xcode 中编辑代码后，点击 command + S 保存时，会自动执行 Xcode 中 SwiftFormat 功能。

有趣的 Bret Victor

大概在十二年前，也就是 2012 年左右，在 Vimeo 上看了 Bret Victor 的几次演讲视频，其中包括著名的《Inventing on Principle》。

当时给我的理解认知，仅仅停留在 UI 设计以及创意的层面，对背后的核心理念完全没有感知。对于这一点的佐证，也是因为我在搜索 Bret 相关中文内容的时候，无意间搜到了当年 Coolshell 上的一篇文章，在文章的下方，竟然惊奇的发现了我的留言。坦白说，我不太喜欢在网上给人留言，如果真的需要沟通，大概率会发邮件。不过这更加侧面印证了当年的演讲内容确实触动到了我，但很可惜，也只停留在看得见的 UI 设计层面，对于背后的理念，完全没有意识。

时隔十二年，因为今年计划尝试开发自己的产品，所以又想到了当年的 Bret Victor。这一次，有了不一样的理解。

十二年前第一次访问他的网站1的时候，完全没有理解网站的导航为什么会是那样设计？而且还划分了「章节」，搞的一头雾水，以为仅仅是为了标新立异，完全没兴趣进一步了解，所以很快关闭了网页。

这次当我认真看了网站上的大部分内容，包括一些论文以及设计的 Demo，结合他自己写的简介，我终于理解了这个网站的信息架构。Bret 的个人网站其实是他自己写的一本书，这本书就是他的人生，章节是人生中的不同阶段。甚至，在他的网站中发现了很多年前给自己设计的一个仆告。

在简介的左侧，介绍了他曾经探索的两个方向。一个方向是对「技术」的探索。正如他所说：

But technology has no soul, and code no conscience.

技术没有灵魂，代码没有意识，他认为在这条路上行走的人，仅仅是对代码的狂热。所以，他认为这条路是错误的。

另一个方向，是对「设计」这条路的探索，比如本文开头提到的那个演讲。经过一些实践和思考之后，他认为这条路也是错误的。他认为这条路只能教给人类回答问题。

最后，他希望能够找到一条路，里边「没有」技术，「没有」设计，只有人类自己的愿景，以及通过实现这个愿景的自驱动力。所以，他在 2014 年，开启了人生的第四篇章——dynamicland。

在他的网站上，看到曾经推荐的一些资料，其中有一本书，名字叫《一个数学家的叹息》，在这本书的开篇有一句引言，我认为可以作为 Bret 探索方向的一个比喻：

如果你要造船，不要招揽人来搬木材，不要给人指派任务和工作，而是要教他们去渴望那广袤的大海。—— 安托万·得·圣埃克苏佩里

Bret 的网站上有很多有趣的资料，包括一些高质量的论文以及一些有趣的设计。对我的启发很大，帮助我跳出了「技术男」的思维框架。也让我明白了，「UI 设计」到底意味着什么？

不过，虽然我明白了前方道路意味着什么，但想要抵达前方，还是要一步一个脚印的走。但好在，我不会在迷茫中前行，也不会对前方的「景色」有不切实际的幻想。

感谢 Bret 将他的想法分享出来，也希望他的探索在未来能够有新的发现。

  1. Bret Victor 网站首页于 2024 年 3 月 1 日改版。之前的网站首页链接变成了 https://worrydream.com/Home2011/。 ↩