跬步 On Coding

打造一个属于自己的AI书签

Jul 7 2025

前言

我一直是个重度的书签使用者，多年来都依赖 Pocket 来收藏和沉淀那些在网上看到的、值得一读的文章。然而，最近 Pocket 宣布其通知服务即将关闭，这对我来说像是一个信号，是时候去寻找一个更稳定、更可控的替代品了。

我的探索之旅就这样开始了：

  1. Raindrop.io：社区里很多人推荐，功能也确实强大。但不知道是不是网络原因，我这边访问起来总是感觉有点慢，而且用惯了 Pocket 的我，对它的界面和交互逻辑始终有些不太习惯。
  2. 自建服务：作为程序员，第一反应自然是自己动手。我找到了像 linkding 这样的优秀开源项目。我尝试把它部署在 fly.io 的免费实例上，但 linkding 对资源的要求不低，最低配的 256M 内存实例直接就 OOM (Out of Memory) 了，升级配置又意味着成本。
  3. 从零开始写一个？ 这个念头一闪而过。我甚至构思好了技术选型：参照 linkding 的功能，用我最近在学习的 Rust 实现后端，部署在 Cloudflare Workers 上，再配上 Cloudflare D1 的 SQLite 数据库。这套方案 Serverless、成本极低，堪称完美。但转念一想，这工程量可不小，对于业余项目来说，我实在没有那么多时间投入进去。

就在我快要放弃，准备将就着用某个方案时，我想起了一篇以前收藏过的文章。

我理解的AI Agent与MCP

Apr 2 2025

前言

最近AI圈子里Manus这个项目可以说是相当火了，连带着MCP（Model Context Protocol）这个概念也开始频繁出现在各种技术讨论区。作为一个程序员，自然也对这些新东西充满了好奇，于是花时间捣鼓了一下AI Agent和MCP相关的知识。这篇文章就是我学习和思考后，对这两个概念的一些个人理解和梳理。

1. 从Workflow到AI Agent：大脑的进化

回顾我们以前做自动化任务，比如搞个自动抢票、自动下单之类的，思路基本都是围绕着一个固定的workflow。我们会预先设定好一套流程逻辑：收到指令 -> 判断条件 -> 走对应分支 -> 调用特定工具（API、脚本等）。整个过程就像一个流程图，每个节点和路径都是我们程序员预先设计好的。在这个模式下，我们程序员就是这个workflow的“大脑”，我们把执行计划通过代码逻辑，“硬编码”到系统里。比如预定机票这个场景，我们会写代码一步步调用查询接口、选择航班接口、填写乘机人信息接口、支付接口等等。

云原生开发入门

Mar 28 2025

作为一名在云原生领域摸爬滚打了一段时间的开发者，我时常会遇到一些刚接触这个领域的朋友，他们面对 Kubernetes (K8s)、容器这些概念时，常常感到有些迷茫，不知道从何学起。这篇文章，我想结合自己的一些学习体会，为想要入门云原生开发的同学提供一个相对清晰的指引。

我自己并非科班出身，从最初接触软件测试写 Lua 脚本，到后来学习 Python 做后端，再到进入腾讯接触 Golang 和 K8s 相关开发，一路走来也踩了不少坑。云原生技术栈确实庞大，但核心的理念是利用容器、微服务、声明式 API 等方式，去构建更可靠、更具弹性的分布式系统。而 K8s 作为这个生态的核心编排引擎，可以说是我们必须掌握的关键技能。

这篇文章，我会从基础概念聊起，分享几本我学习过程中觉得非常有帮助的书籍，一个不错的社区文章集合，以及两个可以动手实践的代码项目。最后，还会结合实际工作经验，聊聊 K8s 运维实践中一些重要的事情。希望这些能帮助大家在学习云原生的路上少走一些弯路。

一、云原生与 Kubernetes：从基础概念开始

云原生到底是什么？

我理解的云原生（Cloud Native），它不是指某一个具体的技术，更像是一种面向云环境的应用设计、开发和部署的最佳实践集合。它鼓励我们使用像容器、微服务、不可变基础设施、声明式 API 这些技术和方法，目标是让我们的应用能更好地利用云计算的弹性、分布式、自动化等优势。根据 CNCF（云原生计算基金会）的定义，这些是关键要素。简单说，就是让应用为云而生，能在云上运行得更好。

为什么 Kubernetes 这么重要？

容器技术（比如 Docker）解决了环境一致性的问题，但当你有成百上千个容器需要管理时，手动操作就变得不现实了。Kubernetes 就是来解决这个问题的。它是一个开源的容器编排平台，最初由 Google 开发，现在由 CNCF 维护。它可以自动化地完成应用的部署、扩缩容、服务发现、负载均衡、故障恢复等一系列复杂工作。在我看来，掌握 K8s 是进入现代后端开发、特别是平台工程领域的一张重要门票。

我的学习路径建议：

回顾我自己的学习过程，我建议可以按以下步骤来：

  1. 先搞懂容器：理解 Docker 的基本概念，比如镜像（Image）、容器（Container）、Dockerfile，能自己动手构建、运行一个简单的容器化应用。
  2. 再深入 K8s 核心：学习 K8s 的核心组件（比如 Pod、Service、Deployment、StatefulSet、Namespace 等）都是做什么的，它们之间是如何协作的。了解控制平面（Master）和数据平面（Node）的基本工作原理。
  3. 动手实践是关键：理论学习后，一定要动手实践。尝试编写 YAML 文件部署应用，使用 kubectl 与集群交互。然后可以去探索存储（Volumes, PV, PVC）、网络（Ingress, CNI）、配置（ConfigMap, Secret）等更深入的主题。
  4. 理解运维视角：开发的应用最终要跑在生产环境。了解 K8s 集群的监控、日志、告警、排错等运维实践，对于写出更健壮、更易于维护的应用非常有帮助。

接下来，分享一些我在学习过程中用过且觉得不错的资源。

从《软件设计的哲学》谈代码的复杂性与应对

Jan 10 2025

几个月前读完了《软件设计的哲学》这本书，在结合自己多年的工作体会，对于代码的可读性，可维护性有了系统性的体会，然后基于我记录的读书笔记然后经过AI的润色，形成了这篇笔记。希望对你也有所帮助。

读完《软件设计的哲学》，感觉像经历了一次代码的“深度体检”。这本书没有讲解具体的编码技巧，而是从更高的维度帮助我们重新审视代码复杂性的问题，并提出了许多实用的建议。今天，我想结合自己的理解，分享这本书带来的启发。

什么是代码的复杂性？

简单来说，复杂性就是那些让系统难以理解和修改的因素。它不仅仅指代码的行数或逻辑深度，还包括：

  • 难以理解：即便是自己写的代码，过一段时间可能也看不懂，更别提其他人。
  • 修改成本高：一个小改动需要改动多个地方，甚至引发新的问题。
  • 模糊的改动范围：不知道该修改哪些模块才能实现目标，或者不确定修改后是否会引发其他问题。
  • 难以修复的错误：修复一个 bug 可能需要大量时间，还可能引入新的问题。

如何快速上手项目

Jan 8 2025

职业生涯中接手过很多项目了，各种项目都接触过，一个对新人友好的项目一般具备如下特征：

  1. 完备的安装/功能文档
  2. 完备的技术方案，架构设计文档
  3. 合理的分层，清晰的代码目录结构
  4. 可读，可维护性高的代码

但是往往我们会忽略一个一个简单的指引性的文档：Quick Start，这个文档不需要很详细，只需要说明，如何快速上手的过程，具体的步骤链接到对应的文档即可。一般我们会在Quick Start上写明：

  1. 最简安装的步骤
  2. 主流程功能的使用
  3. 开发环境的搭建
  4. 开发注意事项
    1. 包含组件的架构图
    2. 包含代码的分层目录说明

这个文档需要由项目的负责人编写，在后续由项目的新人实践的过程中逐步完善。

当然这都是比较理想的情况，实际情况中，我们可能遇到的项目可能根本就没有文档，然后只有一个代码仓库的情况，那怎么才能快速上手呢？其实还是按照Quick Start的思路，只不过需要自己来摸索来了。