这是「把自己部署到互联网上」系列的第 2 篇。
上一篇我讨论了一个问题：2026 年，程序员还有没有必要搭个人博客？我的答案是，如果只是找个地方发文章，不一定非要博客；但如果想长期建设自己的技术阵地，个人博客依然值得做。
这篇继续往前走一步，聊一个更底层的问题：我为什么决定做一个属于自己的技术品牌？
我说的技术品牌，不是把自己包装成某个厉害的 title，也不是做成功学式的个人 IP。更准确地说，它是一组长期可验证的记录：你做过哪些技术实践，解决过什么问题，形成过什么方法，持续关注什么方向。别人通过这些内容，能更稳定地理解你，而不是只通过简历上的几行字或一次面试来判断你。
这个想法，是我写完一期 Git 合集后慢慢形成的
Git 不是新话题。网上有大量教程、命令速查和经验总结。刚开始写的时候，我也以为自己只是整理一些命令和使用经验。真正写完整个合集后，我才发现，技术写作最费力的地方不是贴命令，而是把问题讲清楚。
比如，为什么很多人用了很久 Git，还是害怕 rebase？为什么冲突本身不可怕，真正麻烦的是不知道自己在改哪条历史？为什么同一个命令，在不同协作场景下风险完全不同？为什么有些操作看起来简单，但不了解底层模型就很容易出事？
这些内容不能只靠查文档写出来。它需要你真实用过、踩过坑、被问题卡住过，再回头把经验整理成别人能理解的语言。
写完那期内容后，我意识到一件事：技术能力如果不被整理和表达，很容易只停留在自己的工作经历里。你可能修过 Bug、排过线上问题、改过复杂逻辑、读过源码、搭过环境、部署过服务，也做过不少项目。但如果这些过程没有被记录，外界几乎看不见。别人只能通过简历、面试、一次聊天，或者某个仓库名来判断你。
很多程序员会低估“被看见”这件事。一提到个人品牌，就容易想到包装、营销、流量和人设。我以前也这样想：只要技术够好，总会被看见；只要项目做得扎实，总会有人知道；只要持续学习，能力总会慢慢变强。
这些都对，但只对了一半。技术能力重要，但技术能力不会自动传播。你解决过一个复杂问题，如果没有记录，过几周它可能只剩一句“以前处理过类似问题”。你做过一个项目，如果没有写清背景、设计、取舍和结果，别人看到的可能只是一个仓库。你在工作中积累了很多判断，如果没有持续表达，外界也很难知道你到底擅长什么。
程序员很重视系统的可观测性。我们会给服务加日志、监控、指标和告警，避免出问题时无从排查。但很多时候，我们自己的成长路径没有日志。做过什么，为什么做，怎么判断，踩了什么坑，最后沉淀出什么方法，外界都看不到。个人技术品牌，对我来说，就是给自己的能力建立一套长期可观测的记录。
我不想只做一个会写代码的人
这句话听起来有点大，但实际很现实。程序员当然首先要会写代码，没有代码能力，表达再好也站不住。但真实工作里，一个成熟程序员的价值，不只在于把功能写出来，还包括能不能拆解问题、解释方案、判断取舍、控制风险、沉淀方法，以及让别人复用你的经验。
这些能力很难靠一句“熟悉某某技术栈”讲清楚。它们更适合通过长期内容、项目复盘、技术文章和作品展示来体现。所以我决定做自己的技术品牌，不是因为我觉得自己已经足够厉害，而是想用更长期的方式要求自己。
当你知道某个问题以后可能会写成文章，处理它时就会更认真。当你知道某个项目以后可能会放到作品站上，设计时就会更关注边界和质量。当你知道自己的输出会被别人看到，就不太容易满足于“我自己懂了就行”。这种外部呈现，会反过来约束内部成长。
我的公众号叫 Code of Duty。这个名字里有一点玩笑，也有一点认真。Code 是代码，Duty 是责任，也是一种持续做事的意识。我希望它不是一个只追热点的账号，而是一个长期记录技术实践、工程判断和个人成长的地方。
我也不想把它做成单纯的教程仓库。教程会有，比如后面会写服务器、域名、备案、防火墙、Docker、Nginx、HTTPS、对象存储、博客部署和个人官网。但我更希望每篇文章背后都有一个真实问题：一个普通程序员在建设长期技术阵地时，会遇到什么，又是怎么做判断的。
我理解的技术品牌，不是人设，而是证据链。
你说自己擅长后端，证据是什么？你说自己懂部署，证据是什么？你说自己有工程化思维，证据是什么？你说自己在持续成长，证据又是什么？
技术品牌不能只靠一句自我介绍支撑。它需要一组能被验证的东西：写过的技术文章，做过的项目，公开的代码，解决问题的过程，对技术选型的判断，踩坑后的复盘，以及长期坚持的主题。这些内容叠在一起，才会慢慢形成别人对你的判断。
所以，我现在更愿意把个人品牌理解成一条持续积累的证据链。它一开始不完整，但必须真实。真实比完美重要。如果一个人只展示漂亮结果，从不暴露过程，别人反而很难判断他的能力边界。相反，如果他愿意写下犹豫、误判、踩坑、调整和最终方案，读者更容易相信：这个人是真的做过，也是真的思考过。
既然要做技术品牌，为什么第一步是搭个人博客，而不是继续只发公众号？因为公众号更像分发渠道，博客更像长期资产。公众号适合触达读者、连续更新、建立关系；个人博客的价值在于，它是自己控制的入口。
在博客里，Git 合集可以成为专题，部署文章可以成为专题，项目复盘可以和代码仓库关联，个人官网可以链接到文章和作品。以后内容可以分发到不同平台，但最终需要有一个地方归档、沉淀，并能被长期访问。
对程序员来说，从服务器、域名、备案、Docker、Nginx、HTTPS 一路搭下来，本身也是一次完整的工程实践。它会逼着我把零散知识串起来，不只是写业务代码，而是真的把一个面向公网的系统跑起来。
所以这个系列不会只讲“我要做个人品牌”。我会把它拆成一系列具体动作：先搭个人博客，再处理域名解析和备案；接着配置服务器、安全组、防火墙、普通用户、SSH 和健康检查；然后比较 Conda 和 Docker，确定 Docker Compose 与 Nginx 的方案；再配置 HTTPS、证书和域名访问；后续还会涉及对象存储、静态资源、数据库、发文、防爬和维护；最后把博客延伸成个人官网和作品站。
个人品牌如果只停留在概念里，很虚
拆成这些动作后，它就变成了一个可以逐步推进的工程项目。
我不期待这个系列立刻带来很夸张的结果。它不会让我一夜涨粉，也不会马上带来合作或收益。短期看，搭建、截图、排查、整理、润色都很慢。但长期看，这些内容会变成我的公开资产。以后别人想了解我，不只看到一句简介，也能看到我持续做过什么；以后我复盘某个技术问题，也能回到文章里重新查看。
所以，我为什么决定做一个属于自己的技术品牌？
不是为了把自己包装得多厉害，而是因为我越来越觉得，一个程序员如果长期认真做事，就应该给自己的经验一个能被看见、被理解、被复用的地方。
技术品牌不是口号。它是你持续解决问题后留下的痕迹，是写过的文章、部署过的项目、踩过的坑、做过的取舍和积累下来的判断。它不会一天建成，也不会因为发几篇文章就完成。但它可以从一个很小的动作开始。
对我来说，这个动作就是：先把个人博客搭起来。
接下来，我会先讲清楚个人博客、技术博客和作品站的区别。动手之前，我需要先想明白：我要搭的到底只是一个写文章的地方，还是一个能长期承载个人品牌的入口。
本文由 楸木 原创，转载请注明出处。