最近看了向阳乔木的一篇访谈文章的整理，访谈的嘉宾叫 Jason，聊的是他做的一个开源项目 CC Switch。这个工具在 GitHub 上拿到了 2 万多个 Star，累计下载量超过 130 万次。

Jason 这个人的经历非常接地气，就是一个编程小白，却做出了爆款软件。他 36 岁，之前做进出口贸易，去年才开始自学编程，三个月学完基础，六个月做出了这个项目。没有计算机专业背景，没有大厂履历，就是一个在焦虑中选择行动的普通人。

通过向阳乔木整理的文章，我能感受到访谈信息量非常大，从产品设计到 AI 编程方法论，从开源运营到人生选择，几乎每个话题都有值得细品的东西。我尽量把里面的核心观点都整理出来，希望对你有用。

1、一个真实的需求，往往藏在很小的不便里

CC Switch 做的事情说起来很简单。用过 Claude Code 的人都知道，国内用户大多依赖各种中转站或者国产模型来使用这个工具。但在不同供应商之间切换的时候，需要手动去改环境变量或者配置文件，操作很繁琐，还容易出错。

当时市面上已经有一些脚本工具可以解决这个问题，但都是命令行操作，对普通用户来说门槛太高了。Jason 正好在给另一个开源项目贡献代码，学了 Electron 框架，就想着能不能做一个可视化的界面，让切换这件事变得简单直观。

第一版不到一周就做完了，功能非常基础，就是通过修改配置文件后缀名来实现切换，而且只支持 Claude Code。但就是这么一个简单的东西，解决了一个真实存在的痛点。

你看，很多人总觉得要做出什么惊天动地的产品才值得动手。但现实中，那些真正被大量使用的工具，往往就是解决了一个很小的、但很多人每天都会遇到的不便。把一个命令行操作变成可视化界面，技术上没有任何创新，但它让原本只有技术高手才能完成的操作，变成了普通人也能轻松搞定的事情。这就够了。

2、产品设计的核心是克制，不是堆功能

Jason 在访谈里反复强调一个词：易用性。他说无论添加什么功能，都不能破坏“填写一个 API Key 就能导入，一次点击就能切换”的基本体验。

这种克制说起来容易，做起来非常难。随着用户越来越多，GitHub 的 Issue 区很快积累了上百条功能请求。每个请求单独看都很合理，但如果全部加上去，产品就会变得臃肿复杂。

他分享了一个很苦涩的教训。有段时间他在主界面上加了本地代理和故障转移的快捷开关，本来是给中转站用户设计的，因为公益站的服务很不稳定，需要频繁切换。但很多不需要这些功能的用户看到按钮就顺手打开了，结果产生了一系列问题。最后他不得不把这些开关移到设置里，默认隐藏。

他说这次经历违背了易用性的核心原则，增加了额外的复杂度。

这个教训其实适用于任何产品，甚至适用于我们做任何事情。总想着多加一点、再多加一点，觉得功能越多越好，选项越多越体贴。但实际上，每多一个选项，就多一分用户犯错的可能。真正好的设计，是让用户根本不需要思考。

3、技术选型要匹配产品定位

CC Switch 经历过一次重大的技术重构，从 Electron 迁移到了 Tauri。

Electron 的问题在于它把整个 Chrome 浏览器运行时打包在里面，即使你只写了一个页面，软件基础大小也得 80MB 左右，内存占用也大。对于一个仅仅做供应商管理和切换的小工具来说，太重了。

但迁移到 Tauri 意味着要从 TypeScript 转向 Rust，编程语言变了，很多现成的库都用不了了，很多功能得从头写。重构过程中最痛苦的是本地代理功能，开发到一半，Claude Code 官方自己支持了热切换，等于白做了一大半。但代理功能已经做到一半，只能硬着头皮继续。

重构完成后，软件体积从 80MB 降到了 6 到 7MB，内存占用几乎可以忽略，点击后零点几秒就能打开。

Jason 总结说，选 Electron 还是 Tauri，取决于你的项目定位。如果是大而全的项目，Electron 是明智选择。如果是小工具，Tauri 足够轻量。

这个判断背后有一个更普遍的道理：做任何事情之前，先想清楚你要做的到底是什么量级的东西。杀鸡用牛刀和大炮打蚊子，本质上都是资源错配。选择和你目标匹配的方案，往往比选择最强的方案更重要。

4、配置管理的反复：有些弯路避不开

文章中最让我印象深刻的一段，是 Jason 讲他在配置管理策略上的反复。

最初他用的是全量替换策略，切换供应商的时候直接覆盖整个配置文件。这样做是因为 Claude Code 的配置字段几乎每个小版本都在变，而且不同供应商有独特的字段，全量替换最省事。

但问题来了，全量替换会把用户之前的一些自定义配置也覆盖掉。他设计了一个“通用配置”功能来解决这个问题，但很多用户没注意到这个选项，新建供应商后发现配置全丢了，就开始骂人。这个问题被问了很多次，甚至让他心态崩溃。

于是他在春节期间把整个逻辑重构为关键字段替换，只替换 API Key 和请求地址，其他配置保持不变。结果刚发布一天就翻车了，因为有些用户需要用到自定义字段，关键字段替换没法传递这些字段。

反复分析之后，他发现还是全量替换加通用配置更稳妥，又把逻辑回滚了。好在他重构的时候没有改变数据结构，两个版本之间完全兼容，不会丢数据。

这段经历特别真实。做产品的过程中，你会不断在两个看起来都有道理的方案之间摇摆。用户骂你的时候你觉得应该改，改完又发现新方案有新的问题。这种反复很消耗人，但也是成长的必经之路。关键是每次折腾之后要沉淀下来一些判断力，下次遇到类似的选择时，能更快地做出决定。

5、AI 编程的一套完整方法论

Jason 在访谈里分享了一套非常系统的 AI 编程方法论，我觉得不管你是不是程序员，里面的思路都很有参考价值。

第一，用对的模型。如果你不是资深程序员，直接用最好的模型。因为你可能没有足够强的判断代码质量的能力，用最好的模型能降低出错概率。在重要任务上，别省这个钱。

第二，先规划再动手。在开始一项功能之前，先分析、计划一下怎么做。如果是复杂任务，要独立维护一个文档，写清楚整个大任务需要几个步骤，每个步骤是什么，目的是什么。每次开始一项小任务之前，先从这个文档里读取这一次的任务，完成之后再把结果写回去。

第三，上下文管理是核心。从最早的 Copilot 到后来的 Cursor 再到现在的 Claude Code，本质上都是上下文管理的进步。如果你知道问题大概在哪，直接告诉 AI 在哪个方面去找。如果知道任务集中在哪个文件，直接告诉它。这样可以非常节约上下文。该压缩的时候就压缩，该新开对话的时候就新开，尽量不要让它触发自动压缩。

第四，控制代码量。Jason 说了一句很有意思的话：代码是债务，不是资产。千万不要追求今天写了多少行。AI 不会拒绝你，你让它实现什么它都会去做，但有可能把一个简单的功能用非常复杂的路径实现了。他收到过一个 8000 行的 PR，只是为了测试服务器是否可用，而当时整个项目才 6000 行。

第五，及时清理技术债。一个文件尽量保持在 1000 行以内，最好是五六百行。因为 Claude Code 的默认读取工具只读前 2000 行代码，文件太长会降低 AI 读取到目标代码的概率，上下文很快就被塞满了，钱花了效果还不好。

第六，做好架构设计。不能让 AI 直接开始写功能，要先想清楚实现什么功能，应该有哪些页面，前后端怎么交互。工程量上去之后再去重构，即使有 AI 帮忙也很费功夫。

第七，一定要学 Git。新手可以不学其他技术，但 Git 必须学。否则搞坏了真的找不回来。

这套方法论的核心思想其实就一句话：AI 是工具，不是替代品。你得知道自己要什么，才能让 AI 帮你高效地实现。如果你自己都没想清楚，AI 只会帮你更快地走向混乱。

这个道理放到任何领域都成立。不管是用 AI 写文章、做设计还是做数据分析，先想清楚目标和路径，再让 AI 去执行，效果会好得多。

6、不要提交你看不懂的代码

Jason 提到一个他认为在 AI 时代对新手特别重要的底线：不要提交你看不懂的代码。

AI 生成完代码后，不说把每个细节都看懂，最起码得看懂这些代码是在干什么。

很多人担心 AI 时代工程师会出现断层，传统的从新手到资深的中间学习过程好像被 AI 替代了。Jason 觉得新手更应该观察 AI 的工作过程。他看到很多高手同时开好几个窗口、多个任务并行推进，但他建议新手还是集中在一个任务上，仔细观察 AI 的思考过程，能学到很多东西。而且 AI 中间思路出问题的时候，你也可以及时打断纠正。

这个建议特别实在。AI 降低了上手门槛，但没有降低理解门槛。你可以借助 AI 更快地做出东西，但如果你完全不理解自己做出来的东西，那你就永远只能停留在表面。长远来看，理解力才是真正的竞争力。

7、关于 Vibe Coding，他有一个独特的看法

Jason 说他不太喜欢 Vibe Coding 这个词。他的理由很有意思：语言是有力量的，它不只影响听到你说话的人，反而会影响你自己。如果你说“这个项目是我 Vibe Coding 的”，容易让自己放松对产品代码质量的要求。

他强调这种自我约束只用来要求自己，不会要求别人。但这个提醒确实很有价值。

访谈中有人补充了维特根斯坦的一句话：语言即世界的边界。我们使用的语言已经给自己带上了一些暗示。你怎么描述自己正在做的事情，会反过来影响你对这件事的态度和投入程度。

这个观点放到更大的范围来看也很有启发。我们日常中很多看似随意的用词，其实在潜移默化地塑造我们的心态。说“随便搞搞”和说“认真做一个项目”，带来的行动力和结果可能完全不同。

8、做产品的人要学会蹭热度

Jason 在推广方面也分享了一些经验。CC Switch 的增长和 Claude Code 在国内的热度直接相关，从去年年底开始，AI 编程突然普及开了，再加上 Claude Code 和 OpenClaw 的热度变得很高，CC Switch 也跟着水涨船高。

他在前期也主动做过一些推广。比如国产厂商发新模型的时候，他就去蹭热度，说用我的工具只需要填写一个 Key 就可以把新模型导入到 Claude Code 里使用。

他说了一句很实在的话：如果你是自己做产品，尤其是现在 AI 时代产品井喷式发展，做营销或者蹭热度还是很有必要的。如果你是技术出身，没有必要觉得做营销有点不好意思，一定要勇敢去蹭。你的软件有什么优势，能解决什么问题，要把它说出来，让大家都知道。

很多技术人确实有这个心理障碍，觉得好产品应该自己说话，主动推广显得不够体面。但现实就是，再好的东西如果没人知道，就等于不存在。在信息过载的时代，主动让别人看到你，本身就是产品能力的一部分。

9、写在最后

整篇文章看下来，我感觉 Jason 身上有一种很难得的品质：他很坦诚。他说自己技术比较菜，说自己心态很脆弱，说自己曾经想过 Learning in Public 但因为害怕被打击而放弃了。他不包装自己，不美化过程，就是很真实地讲述了一个普通人在 AI 时代找到方向的故事。

在 AI 时代，技术门槛确实在降低。但正如访谈中提到的，共情能力、产品思维、对用户需求的理解，这些东西变得更加重要了。一个想法到产品的成本变低了，但能站在用户的角度去分析需求、设计功能，这种能力在未来只会越来越值钱。

Jason 说他技术比较菜，所以能用更平民的视角去看待软件，去做功能。这句话听起来像是自谦，但仔细想想，这恰恰是他的优势。因为他自己就是普通用户，所以他天然知道普通用户需要什么、害怕什么、会在哪里卡住。

你不需要是天才，不需要科班出身，不需要大厂背景。你需要的是找到一个真实的痛点，保持对产品的克制，在压力中依然选择行动。

那道双重彩虹，每个人都可能遇到。关键是你看到它的时候，有没有勇气把它当作一个信号，然后真的迈出那一步。

#科技先锋官# #How I AI#