开源 or 闭源？这是个问题

问大家一个问题：对一个个人开发者来说，产品到底应该开源，还是闭源？ 这个问题表面上看是技术问题，实际上很快就会变成商业问题，再往下想，又会变成一个很现实的人性问题——我到底愿意把多少东西暴露给外界？我暴露之后，换来的到底是什么？ 以前我对开源和闭源的理解比较简单。开源就是把代码放出来，大家一起用，一起改，一起提 PR。 闭源就是把代码藏起来，自己部署，自己收费，自己承担所有维护成本。 但做产品久了之后，越觉得事情没有那么简单。 对一个个人开发者来说，开源和闭源并不是一道选择题。 更准确地说，它是一张边界表。哪些东西可以公开，哪些东西不能公开；哪些东西公开之后会增强信任，哪些东西公开之后只会增加风险；哪些东西看起来是秘密，其实没有那么值钱；哪些东西看起来很普通，却反而是你真正的资产。 我现在越来越倾向于一个判断：产品的核心资产可以闭源，但构建过程最好尽量公开。 代码未必要开源。服务器架构、支付链路、风控策略、上游 API、私有 Prompt、用户数据，这些东西不仅不应该开源，有些甚至不应该讲得太细。 但你的思考、踩坑、取舍、产品判断、用户反馈、设计过程、增长实验，这些东西反而应该适度公开。因为 AI 时代最大的变化不是所有人都会写代码了，而是代码本身正在变得越来越便宜。以前一个功能可能要写两三天，现在你和 AI 来回磨，几个小时就能做出一个能跑的版本。 以前你不会前端，不会后端，不会部署，一个想法基本就停在脑子里。现在你只要有足够强的表达能力、判断力和耐心，至少可以把一个东西从 0 推到 0.6。但问题也随之出现了：当代码越来越便宜，什么东西会变贵？ 我的答案是：注意力、信任、分发、审美、运营、持续维护能力。 这也是为什么我觉得，个人开发者今天讨论开源 or 闭源，不能只盯着 GitHub 仓库。真正的问题不是“要不要把代码放出来”，而是“我要不要把自己正在做这件事公开出来”。 先别急着站队 很多人讨论开源闭源的时候，很容易把它变成一种立场问题。 开源的人会觉得闭源太保守，太商业，太不互联网精神。闭源的人会觉得开源太理想主义，太容易被抄，最后辛辛苦苦给别人做嫁衣。 但我觉得对个人开发者而言，你手上可能就是一台电脑，几个域名，一个服务器，一些 API key，一个还在不断修补的产品。这个时候讨论开源闭源，必须回到很具体的问题上。 比如： 你的产品靠什么赚钱？你的用户为什么信你？别人复制你的代码之后，能不能复制你的数据、你的渠道、你的内容、你的运营节奏、你的用户关系？你有没有精力维护社区 issue？你有没有能力处理别人部署失败之后来找你问问题？ 你开源之后，是更容易获得用户，还是更容易吸引一堆白嫖和售后？ 你闭源之后，是保护了核心资产，还是把自己彻底关进了一个没人知道的小房间？ 这些问题比“开源伟大还是闭源赚钱”要现实得多。 我并不反对开源。相反，我非常尊重开源。 没有开源，今天绝大多数个人开发者连起步都起不来。我们用的框架、数据库、编辑器、部署工具、模型推理框架，背后都有大量开源项目。 某种意义上，我们每天都在吃开源生态的红利。 但吃开源生态的红利，不等于你自己的商业产品也必须无条件开源。 这两件事要分开看。 对一个个人开发者来说，闭源不丢人。你要赚钱，要活下去，要付服务器钱，要付模型调用费，要维护用户，要解决支付，要处理售后，要应对攻击，要持续迭代。 你不是在做公益项目，你是在做一个业务。 开源不是一种道德姿态，闭源也不是一种原罪。 真正需要判断的是：你公开这个东西之后，是否会换来更大的复利。 大厂说开源好，不代表你就应该把自己的全部代码公开。大厂说闭源安全，也不代表你就应该把所有思考都藏起来。 你要看的不是它们怎么说，而是它们通过开源或闭源获得了什么。 换句话说，DeepSeek或者任何大模型进行开源，我认为本质上都是商业行为，并不是出于开源精神或者其他什么东西。 说白了，都是生意。 比被抄更危险的是没人知道你 我总被问到一个问题，“鑫哥，如果我做的产品or网站被攻击或抄袭了怎么办”。 我说这是好事，说明你有一定的影响力和用户了。 很多人不愿意公开构建，最常见的原因就是怕被抄。 这个担心很正常。我自己也会担心。你辛辛苦苦想了一个功能，熬夜做了几天，刚发出去，结果别人两天后也做了一个类似的，还比你会营销，比你会包装，比你更会发小红书和推特。 这个事情想想就很难受。但做了一段时间之后，我对“被抄”这件事的看法有一点变化。对个人开发者来说，被抄当然是风险，但更大的风险其实是没人知道你。 如果一个产品从头到尾都藏着，代码藏着，过程藏着，思考藏着，用户反馈藏着，连你是谁都没人知道，那它也许确实不会被抄，但它大概率也不会被看见。很多人低估了“被看见”的难度。 现在不是产品稀缺的时代。 恰恰相反，现在产品太多了。AI 工具、图片生成、视频生成、Prompt 工具、Agent 平台、效率工具、浏览器插件、知识库、SaaS 小工具，每天都在冒出来。 用户不缺选择。 用户缺的是信任。他为什么要用你的产品？为什么要给你付费？为什么要相信你不会跑路？为什么要相信你能持续维护？为什么要相信你的产品遇到问题你会修？ 闭源代码无法回答这些问题，公开构建可以回答一部分。 你每天在修什么 bug，你为什么改这个按钮，你为什么放弃某个功能，你怎么处理一次服务宕机，你怎么优化速度，你怎么设计价格，你怎么处理用户反馈，你怎么权衡上游 API 的稳定性，这些东西看起来不是代码，但它们在建立一种很具体的信任。 别人会慢慢知道：这个产品背后有一个真实的人，这个人每天都在处理问题，不是随便套个壳骗一波就跑。 因为 AI 生成内容太多了，AI 生成产品也会越来越多。用户在信息流里看到的东西越来越像：一样的落地页，一样的渐变色，一样的“让 AI 改变你的工作流”，一样的截图，一样的宣传语。这时候，一个真实的人反而会变得稀缺。 你讲一次真实的故障，讲一次设计犹豫，讲一次你怎么在车上临时修站点，讲一次你为了一个弹窗改了半天，讲一次你为什么把某个功能删掉，这些内容比一张精美海报更有记忆点。 对个人开发者而言，公开构建不是泄密，它更像是一种低成本的信任建设。 当然，前提是你知道边界。 什么该藏，什么该讲 我先说不能公开的部分。 对个人开发者来说，有些东西公开了不是勇敢，是给自己挖坑。 第一类是安全相关的细节。 比如你的服务器真实结构、后台管理入口、风控规则、反刷策略、支付回调细节、API key 管理方式、数据库结构、鉴权漏洞、限流细节。 这些东西可以讲原则，不能讲操作路径。 你可以说“昨天被刷了，我加了限流、验证码、IP 风控和异常监控”。但你不应该把具体的规则、路径、阈值、接口参数全部写出来。做产品不是写靶场教程。 第二类是商业命脉。 比如你的上游供应商、真实成本结构、特殊折扣、账户池策略、余额管理方式、私有渠道、未公开的商务合作、支付通道细节。 这些东西一旦暴露，别人抄不抄你是一回事，你自己的运营风险会先变大。尤其是一人公司，本来抗风险能力就弱，能不暴露的关键链路，就不要暴露。 第三类是用户数据和用户隐私。 这个不用多说。用户上传了什么图，生成了什么内容，付费记录，聊天记录，邮箱，手机号，任何可以识别用户的信息，都不应该成为公开构建的素材。 哪怕你想讲一个用户案例，也应该做脱敏处理。 公开不是裸奔。公开是有边界地建立信任。 不能公开的东西很多，但这不意味着你什么都不能讲。 恰恰相反，个人开发者有大量内容可以公开，而且这些内容对业务有帮助。 一，公开你的学习过程。 比如你今天研究了某个模型，发现它在中文提示词上不稳定；你测试了某个视频生成 API，发现 5 秒和 10 秒在成本和效果上差异很大；你尝试了某种 CDN 或线路优化，发现某些地区速度提升明显；你改了一个上传流程，用户的完成率变高了。 这些都不是商业机密。但它们很有价值。 因为用户和同行都能从里面看到你的判断力，你是真的在每天处理具体问题。 二，公开你的产品取舍。 比如一个按钮为什么放这里？为什么不做某个看起来很酷的功能？为什么首页不堆太多模型？为什么某个弹窗改了三版？为什么无限画布里图片节点、视频节点、音频节点暂时不强行融合？这些东西很接地气，也很真实。 很多时候，用户不一定关心你的代码怎么写，但他会关心你是不是理解使用场景。 个人开发者最容易犯的错误，是把自己关在功能列表里。觉得我今天加了 A，明天加了 B，后天加了 C，就算进步。可用户不是按功能数量付费的。 用户是按“这个东西有没有解决我的问题”付费的。 你公开产品取舍，本质上是在公开你的思考质量。 三，公开失败和修复。 我以前会觉得故障最好别讲，怕别人觉得网站不稳定。现在我反而觉得可以讲，但要讲得有分寸。比如网站被刷爆了，短暂停运几个小时。 你可以讲发生了什么，怎么发现的，临时怎么止血，之后补了哪些防御，未来怎么监控。用户看到的不是“这个网站出过问题”，而是“这个人遇到问题会处理，而且处理得越来越成熟”。 这不是功能更新，这是产品判断。 四，公开你的个人状态。 这个部分要适度，但我觉得有必要，因为个人开发者和公司账号不一样。 公司账号可以装得很稳定，很官方，很完美。个人开发者没有必要完全这样。你可以讲今天工作了多久，卡在哪里，为什么焦虑，为什么删掉游戏，为什么跑步，为什么觉得 UI 难，为什么觉得售后消耗精力，为什么一个看起来简单的网站背后有一堆琐碎事情。这些内容不一定每篇都写，但它们会让读者知道：这个产品背后的人不是一个自动发布更新的机器。这在 AI 时代会变得越来越重要。 很多人说公开构建会被抄。我觉得这句话要拆开看。 你公开一个想法，别人能抄。 你公开一个页面，别人能抄。 你公开一个功能，别人能抄。 你公开一个提示词，别人能抄。 但别人能不能抄走你的业务，这就不一定了，毕竟一个业务不是一个功能。 一个业务包括流量来源、转化路径、支付系统、售后能力、稳定性、内容供给、SEO、GEO、上游 API 管理、用户信任、定价策略、品牌记忆、持续更新。你被抄的往往是表层。 这些东西不在代码里，它们在日常运营里。 所以如果你的产品唯一的壁垒就是“别人不知道我这个想法”，那确实很危险。 因为今天 AI 已经把“从想法到 Demo”的门槛拉得很低了。 一个点子藏不了太久。 你能想到，别人也能想到。你能用 AI 做，别人也能用 AI 做。 真正的差异来自执行密度。 你是不是每天都在改？你是不是比别人更懂用户？你是不是能持续发内容？你是不是能在故障时快速修？你是不是能把一个普通功能磨到顺手？你是不是能把一个模糊方向做成稳定现金流？ 这些东西很难被一键复制。 个人开发者不要把“秘密”看得太重，也不要把“执行”看得太轻。 秘密当然有价值，但秘密的价值通常没有我们想象中那么高。尤其在 AI 时代，很多秘密只是暂时的信息差。信息差会过期，执行力不会那么快过期。 公开构建不是发流水账 我看到很多人对公开构建有一个误解：以为公开构建就是每天发“我今天做了什么”。今天写了登录。明天接了支付。后天修了 bug。大后天优化了首页。 这种内容不是不能发，但如果一直这么发，读者很快就会没感觉。 因为它像工作日志，不像文章。 公开构建真正有价值的地方，不是告诉别人“我今天提交了多少代码”，而是告诉别人“我为什么这样做”。 同样是做支付系统，写法可以完全不同。 一种写法是：“今天接入了 Stripe，后续准备拓展海外市场。” 另一种写法是：“我之前一直觉得支付只是一个接口问题，接上就完了。 但真开始做海外支付时，我发现它更像信任问题。用户看到价格、货币、退款规则、支付失败提示、发票、订阅取消入口，每一步都在判断你是不是靠谱。 支付不是最后一步，支付其实是产品说服力的总验收。” 后者明显更像人写的，也更有价值。 同样是做 UI，写法也可以不同。 一种写法是：“今天优化了无限画布 UI。” 另一种写法是：“我现在最头痛的不是节点能不能连起来，而是连起来之后用户会不会觉得它自然。图片节点、视频节点、音频节点单独看都能跑，但放在同一个画布里，它们之间到底是什么关系？是素材流？是工作流？还是一个创作时间线？这几个定义不清楚，UI 就会一直别扭。” 这就是公开构建的价值。 你是在公开思考。进度很容易被抄，思考没那么容易被抄。 就算别人看到了你的思考，他也未必能把它消化成自己的产品判断。 我很喜欢开源精神，但如果从个人开发者角度说，我觉得更应该训练的是公开能力。 公开能力是你能把一件复杂的事情，用别人听得懂、愿意看、看完还信你的方式讲出来。这件事很难。你做了一个功能，不代表你能讲清楚它为什么重要。你解决了一个 bug，不代表你能写出一篇有价值的复盘。你有一个产品，不代表你能让用户理解它适合谁。你会写代码，不代表你会建立信任。 以前程序员最重要的能力可能是“把东西做出来”。现在这件事依然重要，但已经不够了。 AI 让更多人能把东西做出来，于是新的差异就会往前后两端移动。 前端是判断：做什么，为什么做，先做哪一块，砍掉什么。 后端是分发：怎么让人知道，怎么让人信，怎么让人持续回来，怎么让用户愿意付费。 个人开发者不能只把自己定位成“写代码的人”。你同时是产品经理、设计师、运营、客服、安全负责人、增长负责人、内容创作者、商务对接人。 听起来很痛苦，但这就是现实。 一个人承担一条业务链路。 而这条链路里，公开表达是很重要的一环。 这是我目前觉得最适合个人开发者的策略。