今天折腾了一下 Blogger。 配置自定义域名，接入广告，把之前的一部分博客内容迁移过来。折腾了好一阵，终于把这些事情都跑通了。 从技术上来说，这并不是什么复杂的事情。 对于一个程序员而言，配置域名、调整网站、迁移内容、接入广告，无非就是查资料、解决问题、验证结果。只要愿意花时间，大多数问题都能找到答案。 但当所有东西都配置完成之后，我反而开始思考一个问题。 这套系统搭起来了，然后呢？ 我想通过博客发布内容，通过搜索引擎获取流量，再通过广告获得一些收入。 这是一套非常经典的互联网变现逻辑。 写内容，获取访问量，展示广告，赚取收益。 过去很多年，这套模式被无数个人博客、内容网站和独立站验证过。对于一个想建立个人副业、尝试第二增长曲线的程序员来说，它看起来也是一条值得尝试的路。 但问题是，现在已经是 AI 时代了。 当越来越多的人开始直接向 ChatGPT 这样的 AI 工具提问，直接获取答案，而不是像过去一样打开搜索引擎、点击网页、阅读博客时，这套商业模式还能够像以前一样成立吗？ 我今天刚刚把广告接上，却开始怀疑自己搭建的这套系统。 这件事挺有意思。 因为我突然意识到， 把系统搭建成功，不代表系统所依赖的商业逻辑依然成立。 一、我刚刚接通了广告，却发现流量的入口可能正在变化 过去，我们对互联网内容变现有一个相对清晰的认知。 用户遇到问题，打开搜索引擎，输入关键词。 搜索引擎返回一系列网页。 用户点击其中一个链接，进入网站，阅读文章。网站通过广告展示获得收益，内容创作者则有机会通过持续积累内容，获得越来越稳定的访问量。 这套模式的核心，是搜索流量。 只要内容能够解决用户的问题，就有机会通过搜索引擎被发现。只要网站能够持续获得访问，就有机会产生广告收入。 我今天折腾 Blogger，本质上也是在尝试这条路。 我希望把自己过去积累的内容迁移到一个能够长期运营的平台上，配置好自己的域名，接通广告，让内容在发布之后，能够持续发挥价值。 这其实是一种很符合程序员思维的想法。 写一次代码，只要系统还在运行，就可能持续产生价值。 写一篇文章，如果它能够长期被搜索到，也可能持续带来流量和收入。 这相当于给内容建立了一条自动运行的流水线。 但 AI 的出现，让这条流水线中的某些环节开始发生变化。 以前，用户搜索一个问题，可能需要...
博文
为什么人生重大转型，不应该一次性重启系统
- 获取链接
- X
- 电子邮件
- 其他应用
为什么人生重大转型，不应该一次性重启系统 有一段时间，我经常会想一个问题： 如果有一天，我不做现在的工作了，我应该怎么办？ 这个问题以前其实没有那么强烈。 因为年轻的时候，路径很清晰。 学习技术。 积累经验。 进入更好的公司。 承担更大的项目。 提升自己的价值。 每一步虽然辛苦。 但大方向是明确的。 可是到了40岁左右。 很多事情开始变得不一样。 技术还在发展。 行业变化越来越快。 组织里的不确定性越来越高。 你会发现： 过去那套成长模型，好像正在慢慢失效。 以前： 努力 → 提升 → 晋升 → 更好的机会 现在： 努力之后， 未必有确定的结果。 于是很多人开始产生一个想法： 是不是应该彻底改变？ 换行业。 创业。 做自媒体。 转管理。 重新开始。 我也曾经有过这样的冲动。 甚至会想： 是不是应该直接离开现在的环境？ 重新开始一套人生系统。 但是后来，我想到一个程序员非常熟悉的概念： 灰度发布。 01 程序员不会直接把未经验证的代码推向所有用户 做软件的人都知道。 一个重要功能上线之前。 通常不会直接全量发布。 为什么？ 因为你不知道： 它是否真的稳定。 是否符合预期。 是否会产生新的问题。 所以成熟的软件团队通常会采用： 灰度发布。 简单来说： 先让一小部分用户使用。 观察数据。 收集反馈。 确认稳定之后。 再逐步扩大范围。 比如： 第一阶段： 1%的用户。 第二阶段： 10%的用户。 第三阶段： 50%的用户。 最后： 100%上线。 这背后的核心思想是： 不要用一次赌博，决定整个系统的未来。 后来我发现： 人生其实也应该这样。 02 我曾经误以为，改变人生需要一次“大重启” 很多人在40岁左右产生焦虑。 不是因为没有能力。 而是突然发现： 过去的路径可能不再确定。 于是容易产生一种想法： 我要彻底改变。 我要重新开始。 我要摆脱现在的一切。 这种想法其实很容易理解。 因为当一个系统运行出现问题时。 人的第一反应往往是： 重写。 程序员也一样。 看到历史代码太乱。 第一反应： “要不全部重构？” 但是实际工作中。 真正成熟的工程师很少这么做。 为什么？ 因为： 正在...
认知接口：你和世界对话的协议，可能早就过时了
- 获取链接
- X
- 电子邮件
- 其他应用
有一段时间，我经常产生一种挫败感。 明明自己做了很多事情。 明明解决了很多问题。 明明十几年技术生涯，也积累了不少经验。 但是不知道为什么： 自己的价值，好像越来越难被看见。 这种感觉很微妙。 不是没人认可你。 你的领导知道你靠谱。 你的同事知道你能扛事情。 遇到复杂问题，大家也愿意找你。 但是： 当你认真思考未来的时候。 又会产生一种不确定。 如果未来几年，我继续按照现在的方式工作。 五年以后，我会变成什么样？ 如果行业继续变化。 如果技术持续升级。 如果组织需要的人越来越年轻。 我的价值，应该如何重新定义？ 以前遇到这种问题。 我的第一反应通常是： 是不是我要再学习一些新技术？ 是不是我要提升自己的技术深度？ 因为程序员解决问题的方式，往往就是： 发现问题。 补充能力。 修复缺陷。 但是后来我发现： 这个问题可能不是能力问题。 而是： 我和这个世界沟通的接口，可能还停留在过去。 01 程序员都知道：接口决定系统如何连接 作为程序员。 我们每天都在设计和使用接口。 一个服务想调用另一个服务。 必须知道： 接口地址是什么。 参数是什么。 返回结果是什么。 如果双方协议一致。 系统可以正常通信。 如果协议不匹配。 哪怕两个系统本身都很好。 也无法正常协作。 比如： 一个系统发送： { "name":"语霖" } 另一个系统期待： { "userName":"语霖" } 从人的角度看： 信息一样。 但是系统不知道。 因为： 协议不同。 后来我发现： 人与世界之间，也存在类似的接口。 这个接口，就是： 认知接口。 02 我的旧接口：做好事情，价值自然会被看到 这是很多技术人的默认认知。 尤其是我们这一代程序员。 刚进入行业的时候。 这个逻辑非常有效。 努力学习。 提升技术。 解决问题。 然后： 获得认可。 获得机会。 获得成长。 于是我们慢慢形成了一套人生协议： 输入： 努力 + 能力 输出： 认可 + 回报 + 发展 这套协议运行了很多年。 甚至帮助我们从新人。 成长为团队里的核心成员。 所以我们相信： 只要持续提升自己。 ...
人生代码审查：把你欠的债，一笔一笔列出来
- 获取链接
- X
- 电子邮件
- 其他应用
人生代码审查：把你欠的债，一笔一笔列出来 有一段时间，我经常有一种奇怪的感觉。 每天都很忙。 会议很多。 需求很多。 问题很多。 别人看起来可能觉得： 一个工作十几年的技术人，应该已经非常稳定了。 有经验。 懂业务。 能解决复杂问题。 遇到事情也能够扛下来。 可是只有自己知道： 心里其实一直有一种隐隐的不确定感。 我开始问自己几个问题。 如果五年以后，公司不再需要现在的我。 我还能依靠什么？ 如果未来技术变化越来越快。 过去积累的经验，还有多少价值？ 如果有一天，我离开现在的位置。 我真正拥有的东西是什么？ 这些问题，以前我很少认真想。 因为每天都有新的任务。 新的需求。 新的问题。 就像一个运行中的线上系统。 只要没有宕机。 就很少有人愿意停下来检查。 但是某一天，我突然意识到： 过去十几年，我一直在维护公司的系统。 可是： 我好像很少认真维护自己的人生系统。 01 程序员会做Code Review，却很少给自己做人生Review 作为程序员，我们都知道： 代码写久了，一定会产生问题。 哪怕最开始的设计非常合理。 随着需求不断增加。 功能不断叠加。 人员不断变化。 系统里面一定会出现： 历史代码。 临时方案。 隐藏依赖。 这些东西，在刚开始的时候没有问题。 甚至帮助系统快速上线。 但是时间久了： 它们会慢慢变成维护成本。 这就是技术债。 成熟的软件团队，会定期做一件事情： Code Review。 不是为了证明谁写错了。 也不是为了否定过去的设计。 而是： 重新理解系统。 发现隐藏风险。 优化未来架构。 后来我发现： 人生其实也是一样。 我们年轻的时候，也在不断写自己的“人生代码”。 为了进入更好的公司。 我们学习技术。 为了证明自己的价值。 我们承担更多责任。 为了获得稳定。 我们接受组织安排。 为了完成目标。 我们牺牲时间和健康。 这些选择，当时都是合理的。 因为它们帮助我们走到了今天。 但是问题是： 很多代码上线以后，就再也没有回头维护。 很多人生选择也是一样。 我们不断增加功能。 不断增加责任。 不断增加负载。 却很少停下来问： 现在这套系统，还适合未来十年吗？ 02 我的第一次...
你不是不够努力，你是欠了一屁股“人生技术债”
- 获取链接
- X
- 电子邮件
- 其他应用
你不是不够努力，你是欠了一屁股“人生技术债” 40岁以后，我开始频繁问自己一个问题： 为什么我已经这么努力了，却越来越不确定？ 过去十几年，我一直相信一个公式： 技术能力提升。 解决问题增加。 经验不断积累。 未来自然会越来越好。 这个公式，在年轻的时候几乎没有错。 刚进入技术行业的时候。 学习一个新技术。 解决一个线上问题。 完成一个重要项目。 得到一次认可。 都会带来非常明显的成长反馈。 那时候的人生，很像一个不断升级的程序。 只要持续提交代码。 系统就会不断迭代。 只要不断努力。 未来就会越来越好。 可是到了某个阶段，我发现： 事情开始发生变化。 代码还在写。 问题还在解决。 项目还在推进。 经验还在增加。 但是： 职业成长的速度慢了。 收入增长变难了。 未来方向开始模糊了。 以前让我获得安全感的东西，正在慢慢失效。 我开始意识到： 也许问题不是我不够努力。 而是： 我的人生系统，积累了一些长期没有处理的技术债。 01 程序员都知道技术债，但很少审查自己的人生债 做软件的人都知道： 一个系统刚开始的时候，通常很简单。 需求来了。 快速实现。 先上线。 以后优化。 这是一种非常正常的工程选择。 因为创业公司需要速度。 业务需要验证。 项目需要交付。 但是随着时间推移： 临时方案越来越多。 历史代码越来越复杂。 系统越来越难维护。 最后出现一种情况： 没人敢轻易修改。 一个简单需求，也可能引发连锁问题。 这就是技术债。 人生其实也是一样。 我们年轻的时候，也在不断“快速上线”。 为了获得更好的机会： 我们努力提升技术能力。 为了证明自己的价值： 我们承担越来越多工作。 为了获得稳定发展： 我们接受组织安排。 为了完成目标： 我们牺牲自己的时间和身体。 这些选择，在当时没有错。 甚至很多时候： 正是这些选择，让我们走到了今天。 但是问题在于： 很多东西上线以后， 我们再也没有回来维护。 于是： 过去帮助我们成长的东西， 慢慢变成了限制我们的东西。 这就是： 人生技术债。 02 第一笔人生技术债：只积累能力，没有建设资产 很多技术人的成长路径，其实非常类似。 年轻的时候： 能力 = ...
如何用AI，给自己的知识系统做一次自动化归档
- 获取链接
- X
- 电子邮件
- 其他应用
如何用AI，给自己的知识系统做一次自动化归档 我曾经以为，知识管理最难的事情，是设计出一套足够合理的目录结构。 于是，我会研究文件夹应该怎么划分，标签应该怎么设计，哪些内容应该放进笔记，哪些内容应该沉淀成知识模型。偶尔还会重新调整主题、插件和首页，希望整个系统变得更清晰、更好用。 从程序员的角度看，这似乎是一件很自然的事。 系统要有架构，数据要有结构，内容要能分类，未来还要支持检索和复用。 但使用一段时间后，我逐渐发现了一个问题： 知识系统的设计越来越完善，并不意味着知识真的被管理好了。 真正让我头疼的，往往不是没有地方记录，而是记录之后怎么办。 看到一篇有价值的文章，我想保存下来；工作中遇到一个值得复盘的问题，我想记下来；和 AI 讨论出一个有启发的观点，我也不想丢掉。 可是，保存之后呢？ 这条内容应该放在哪里？应该打什么标签？需要提炼成知识卡片吗？应该归入某个主题，还是建立一条新的知识模型？ 如果当时很忙，我可能只是随手保存。等到有时间整理时，新的事情又来了。时间久了，知识库里积累了大量内容，但真正需要某个经验时，我未必能够及时找到。 更麻烦的是，我有时会把整理知识本身变成一项任务。 本来是想让知识系统帮助自己，最后却需要自己不断维护知识系统。 我开始意识到，问题可能不在于目录结构设计得不够好，而在于整个系统仍然过度依赖人工判断和人工整理。 这让我想到一个新的方向：能不能把一部分知识归档工作交给 AI，让自己从重复整理中解放出来？ 一、先区分两件事：保存知识和管理知识 在软件开发中，我们不会把数据写进数据库，就认为整个业务流程已经完成。 数据被保存，只解决了持久化问题。后续还需要校验、处理、建立索引，最终才能支持业务使用。 知识管理也是如此。 当我把一篇文章、一段工作经验或者一次 AI 对话保存到 Obsidian 时，我只是完成了信息采集。 如果希望这些信息以后能够帮助自己，还需要完成几个环节： 识别： 这段内容究竟在讲什么？ 理解： 哪些观点、经验或者问题值得保留？ 关联： 它和我已有的认识有什么联系？ 归档： 放在哪里，如何命名，是否需要标签？ 检索： 未来遇到相关问题时，怎样重新找到它？ 复用： 能否将它用于工作决策、内容创作或者个人成长？ 过去，这些工作大部分由我自己完成...
告警体系治理：从噪音到聚焦
- 获取链接
- X
- 电子邮件
- 其他应用
杂乱的告警就像「狼来了」的故事，一开始大家还很紧张，但喊的次数多了，大家就疲劳了，等狼真的来了，反而没人重视了。告警治理就是要解决这个问题，确保「狼真的来了」的时候，我们能第一时间发现并处理。 提升效率，降低成本 减少「噪音」，聚焦关键问题 ：技术治理可以把大量重复、无效的「噪音」告警过滤掉，让团队能集中精力处理真正重要的问题，避免在无关紧要的事情上浪费时间。 快速定位，缩短故障时间 ：通过对告警信息的整合和智能分析，可以更快地找到问题的根源，而不是像无头苍蝇一样到处排查。故障时间越短，对业务的影响就越小。 解放人力，投入更有价值的工作 ：当告警变得精准、可信之后，很多初步的判断甚至修复工作都可以自动化完成。 保障业务稳定，提升用户体验 提前预警，防患于未然 ：有效的告警治理不仅仅是「事后救火」，更能通过对数据趋势的分析，提前发现潜在的风险。 减少业务中断，提升品牌信誉 ：系统频繁出问题，最直接的影响就是用户无法正常使用产品或服务。通过有效的告警治理，可以显著减少业务中断的次数和时长。 为业务决策提供数据支持 ：治理过的告警数据，可以清晰地反映出系统的健康状况和薄弱环节。 总结 通过这项工作，我们可以： 看得更清 ：从海量信息中准确识别出真正的问题。 响应更快 ：在问题造成严重影响前就将其解决。 防得更早 ：在问题发生前就提前预警，避免损失。 告警治理的方法和工具 当市面上有不少成熟的工具和方法可以帮助实现告警的「降噪」和「聚焦」。这些工具和方法的核心思想，就是 「把信息处理得更聪明一些」 。 核心方法 这些方法是实现「降噪」和「聚焦」的指导思想，工具只是帮助我们落地这些思想。 方法 做法说明 好比是... 告警合并 (Aggregation) 把「同一个问题」引发的「一堆告警」自动合并成「一条告警」。比如一个网络设备坏了，导致100台服务器都连不上，那就只告诉你「网络设备坏了」，而不是发100条「服务器连接失败」。 办公室的打印机坏了，我只需要告诉你「打印机坏了」，而不是让每个想打印的人都来跟你报告一遍。 告警分级 (Prioritization) 给告警贴上不同等级的标签，比如「致命」、「严重」、「警告」。这样，半夜三更就只有「致命」告警才会把人叫起来。 把任务分成「十万火急」、「急」、「正常办理」。只有「十万火急」的事情才需要马上放下手...