GopherDaily

Go技术生态

AWS 大神发文炮轰：Go 的并发就是个“笑话”，JVM 的方案要更优越
但就在前几天，AWS 的资深布道师 James Ward，在 X 平台上突然向 Go 语言的这个“优势高地”发起了猛烈炮轰： “开发者普遍认为 Go 在并发方面很出色。但事实并非如此。JVM 的方案要优越得多。当你把虚拟线程、结构化并发和 Effects 加进来时，它 甚至是全行业最好的方案之一。”

使用 Tiptap Golang 后端的技巧
在 ClarityBoss 中，我们将 Tiptap 用作所有日志条目的编辑器。它支持简便的富文本格式设置，以及与 Markdown 和 HTML 的输入输出。目前为止，我们发现它非常适合我们。它让我们能够专注于真正想要构建的功能，而不是重复造轮子。它还具有强大的扩展性，例如只需实现一个提供建议的函数，就能实现“@人员”样式的提及功能。然而，与 90% 使用 Tiptap 的人不同，我们的后端是使用 Go 编写的，而不是运行在 Node 中的 Typescript。有时我们需要在服务端理解 Tiptap 内容，无论是为了邮件通知还是收集未完成的任务。因此，由于无法直接在服务端导入并使用 Tiptap，我们必须采取一些不同的处理方式。## Go 中的 Tiptap 内容反序列化大多数情况下，我们将 Tiptap 的内容视为通用的 JSON 对象。这意味着我们可以将其存储在 Postgres 的 JSONB 列中，而不必担心其结构。目前我们也没有尝试使用 CRDT 或实时冲突解决来做过于复杂的操作，因为日志条目目前仅对特定的 ClarityBoss 用户私有。当我们需要解析它时，相应的结构体定义非常简单。JSONContent 是递归的，除了各种字段的原始类型外，Mark 是唯一需要的其他类型。```hljs go// Mark 表示 TipTap 编辑器中的文本标记。// 这镜像了 Typescript 类型。type Mark struct { Type string `json:"type"` Attrs map[string]any `json:"attrs,omitempty"`}// JSONContent 表示 TipTap 编辑器中内容的结构。// 这镜像了 Typescript 类型。type JSONContent struct { Type string `json:"type,omitempty"` Attrs map[string]any `json:"attrs,omitempty"`

Solod v0.1发布
Solod 是一门具有 Go 语法且零运行时的系统级语言。它主要针对两类受众：- 想要底层控制和零成本 C 互操作，且无需学习新语言或标准库的 Go 开发者。- 喜欢 Go 风格的 C 开发者。初始版本（v0）专注于选择 Go 的子集并将其转换为 C。下一步顺理成章地是移植 Go 的标准库并使其更容易与 C 进行交互。这就是我今天发布的 v0.1 版本的主要内容。标准库 • SQLite 绑定 • 持久化映射 • 存储与检索 • 命令行界面 • 性能 • 总结## 标准库Solod v0.1 随附了从 Go 移植的以下标准库包：- io, bufio 和 fmt — 通用 I/O 的抽象和类型。- bytes, strings, strconv 和 unicode/utf8 — 常见的字节和文本操作。- slices 和 maps — 泛型堆分配数据结构。- crypto/rand 和 math/rand — 生成随机数据。- flag, os 和 path — 处理命令行和文件。- log/slog — 结构化日志。- time — 时间的测量与显示。以及它自己的一些包：- mem — 带有可插拔分配器接口的内存分配。- c — 底层 C 互操作助手。在接下来的章节中，我将使用一个简单的示例演示 v0.1 的一些功能：一个由 SQLite 支持的持久化键值存储。## SQLite 绑定

云原生技术

Microcks 成为 CNCF 孵化项目
CNCF 技术监督委员会 (TOC) 已投票通过，接纳 Microcks 为 CNCF 孵化项目。### 关于 Microcks现代软件团队将应用程序构建为相互关联的 API 和微服务的集合，这种架构带来了一个重大挑战：当如此多的服务相互依赖时，如何隔离地开发和测试服务？Microcks 通过提供一个用于 API 模拟和测试的开源云原生平台解决了这个问题。借助 Microcks，团队可以将现有的 API 合约文档（无论是 OpenAPI 规范、AsyncAPI 规范、gRPC/Protobuf 定义、GraphQL 模式、Postman 集合还是 SOAP/WSDL 项目）即时转换为在线模拟服务器。这些资产随后可用于针对真实实现执行自动化合约一致性测试。其结果是一种统一的、多协议的方法，涵盖同步 REST/RPC API 和事件驱动的异步架构 —— 这种组合使 Microcks 在更窄的工具中脱颖而出。### Microcks 的关键里程碑与生态系统发展Microcks 由 Laurent Broudoux 于 2015 年 2 月创建，是一个社区驱动的项目，拥有来自全球的贡献者和采用者，包括金融机构（法国巴黎银行、兴业银行和洛希尔银行）以及技术/咨询公司（德勤、安利和 J.B. Hunt）。自 2023 年 6 月 22 日加入 CNCF 沙箱以来，Microcks 在采用、贡献、开发和生态系统覆盖范围方面取得了显著增长。采用率激增，2025 年容器镜像下载量超过 250 万次（是 2024 年总量的三倍）。超过 34 个组织公开采用 Microcks，仅 2025 年就增加了 13 个。该项目受到社区的高度关注，主仓库拥有 1,800 个 GitHub star 和 311 个 fork，文档流量持续增长。贡献者基础不断扩大，GitHub 上总计 645 人。

工具已就绪，为什么大多数云原生团队仍在运行三套可观测性技术栈？
我在云原生基础设施领域工作了足够长的时间，深知我们在标准化理论方面做得相当不错。OpenTelemetry 用于仪表化，Prometheus 用于指标，Jaeger 和 Tempo 用于分布式追踪，Fluentd 或 Loki 用于日志聚合——多年来，社区在这些工具周围达成了真正的共识。工具已经成熟，标准已经存在。那么，团队现在的实际处境如何？2026 年 2 月的一项行业调查针对 407 名从业者（DevOps 工程师、SRE、平台工程师、云架构师和跨越 20 多个行业的工程领导者）进行，提供了我们目前所掌握的最清晰的情况快照之一。数据表明有些方面是令人鼓舞的，但也有些方面表明我们还有很多工作要做。### 工具碎片化仍然是默认状态尽管有成熟、可互操作的云原生可观测性项目可用，但仍有近 46.7% 的组织并行运行两到三种可观测性工具。只有 7.4% 的组织实现了单一统一的可观测性体验。当问及哪一项单一改进最有利于他们的可观测性设置时，无论公司规模大小，从初创公司到大型企业，缺乏统一解决方案都排在首位。这并非真正的工具差距——至少在明显的意义上不是。像 OpenTelemetry 这样的项目在跨语言和运行时提供供应商中立、一致的仪表化层方面做了大量工作。挑战似乎更多是组织和运营层面的：团队在不同的时间段和针对不同的用例逐步采用工具，而统一这些数据流所需的集成工作并不会自动发生。对于云原生社区来说，这似乎既是文档挑战也是采用挑战。为将 OpenTelemetry、Prometheus 和分布式追踪工具组合成连贯、可操作的技术栈提供更清晰的路径——同时需要更多...

Kubernetes v1.36：服务端分片列表与监视 (List and Watch)
随着 Kubernetes 集群增长到数万个节点，监视高基数资源（如 Pod）的控制器面临着扩展瓶颈。水平扩展控制器的每个副本都会从 API 服务器接收完整的事件流，并支付 CPU、内存和网络成本来反序列化所有内容，却丢弃了它不负责的对象。扩展控制器并不能减少每个副本的成本，反而会将其成倍增加。Kubernetes v1.36 引入了服务端分片列表与监视作为 alpha 功能 (KEP-5866)。启用此功能后，API 服务器会在源头过滤事件，以便每个控制器副本仅接收它拥有的那部分资源集合。## 客户端分片的痛点一些控制器（例如 kube-state-metrics）已经支持水平分片。每个副本被分配一部分键空间并丢弃不属于它的对象。虽然这在功能上有效，但它并没有减少从 API 服务器流出的数据量：- N 个副本 x 完整事件流：每个副本反序列化并处理每个事件，然后丢弃它不需要的内容。- 网络带宽随副本数量扩展，而不是随分片大小扩展。- 用于反序列化的 CPU 浪费在丢弃的部分上。服务端分片列表与监视通过将过滤上移至 API 服务器解决了这个问题。每个副本告诉 API 服务器它拥有的哈希范围，API 服务器只发送匹配的事件。## 工作原理该功能向 ListOptions 添加了一个 shardSelector 字段。客户端使用 shardRange() 函数指定哈希范围：```shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')```API 服务器计算确定性的 64 位 FNV-1a 哈希...

缓存一致性与缓存命中率
**编者注：** 我们知道 P99 CONF 社区又爱又恨延迟，因此我们很高兴 Pekka Enberg 决定写一本关于它的书，并且我们很自豪能赞助该书的 3 个章节。获取延迟书摘 PDF此外，Pekka 最近在一次关于构建低延迟应用程序的大师班中分享了该书的关键要点（现已可按需观看）。让我们继续我们的延迟书摘，分享 Pekka 缓存章节的更多内容。经出版商许可在此转载。***## 缓存一致性缓存一致性意味着多个缓存对缓存数据保持统一的视图。例如，在具有多个核心的现代 CPU 中，每个核心都维护自己的缓存。当您的程序从内存读取数据时，该数据会被缓存到每个核心的 CPU 缓存中以加快后续访问。如果另一个核心读取相同的数据，它会将该数据拉入其缓存，因此它被缓存在两个地方。然而，当其中一个核心写入其他核心缓存的数据时，就会出现一致性问题。只有一个核心会看到最新的值——其他核心看到的是陈旧数据，导致系统不一致，除非不同缓存之间存在协调。这就是为什么现代多核 CPU 实现缓存一致性协议，以确保缓存不会有陈旧数据。从正确性的角度来看，程序可以继续读取和写入内存，就好像中间没有缓存一样。当然，保持缓存更新的缓存一致性协议是有延迟代价的，因为由于协调的存在，更新现在变得更加昂贵。这就是为什么在许多情况下，分布式缓存是不一致的，允许读取陈旧数据。缓存一致性是指确保...

重温 2015 年开源普查
2015 年 7 月，Heartbleed 事件一年后，Linux 基金会的核心基础设施倡议发布了一份开源项目普查。其想法是在下一个 OpenSSL 发现我们之前找到它：获取 Debian 流行度竞赛中的每个包，对其风险进行评分，并列出需要寻求帮助的优先级列表。David Wheeler 设计了评分，一小组人员进行了人工审查，输出的是一份包含 428 个项目的 CSV 文件，按 risk_index 从 1 到 13 排序。我差点忘了它的存在，直到 Daniel Stenberg 本周在 Mastodon 上发布了一个十年后的提醒，链接回他在 2016 年的文章。普查发布时，我才刚刚开始构建 Libraries.io 九个月。当时我以为自己是在构建一个发现引擎，一种在注册表中查找包的方法，又过了几年我才注意到，我积累的依赖图对于可持续性和安全性问题比搜索更有用。所以我记得读过普查结果，然后像大多数人一样，再也没有想过它们。数据仍然在那里，自 2016 年以来未被触动。现在阅读它是一种奇怪的体验，因为你知道接下来的十年发生了什么，而那些填写电子表格的人却不知道。xz-utils 排在第 254 行。风险指数 6，处于后半部分。liblzma5，最终链接到互联网上一半 sshd 的库，排在第 237 行。分数相同。更有趣的字段是最后一列，审稿人输入了自由文本评论：> 广泛使用的压缩/解压缩。至关重要，这里的漏洞可能非常严重。……由少量提交者维护，相当活跃。未发现错误跟踪器。2015 年有人直接看着它，并用通俗的英语写下了 xz 为什么危险的确切原因。然后公式给了它一个 6，它就沉到了 236 行以下。## 如何

直接IO将压缩期间的 p99 读取延迟降低了 5 倍
我为 Apache Cassandra 6 贡献的一个补丁将压缩期间的 p99 读取延迟降低了 5 倍。压缩会用应用程序认为是丢弃的数据污染页面缓存，但内核却不知道这一点。压缩是不可避免的，这是 Cassandra 为快速写入所支付的代价。数据在进入时并没有排序；它是在后台通过合并磁盘上的文件稍后进行排序。减少压缩吞吐量或增加节点内存可以减轻对尾部查询延迟的影响。前者牺牲了吞吐量，后者花费金钱。两者都是妥协。直接 I/O 允许 Cassandra 与其自身的管家更好地和谐相处，完全绕过压缩读取的页面缓存。### Linux 页面缓存任何时候发生基于文件的读取或写入（通常通过 read() 和 write() 系统调用），数据都会经过页面缓存，这是应用程序和存储设备之间由内核管理的内存缓存。内核通过两个 LRU（最近最少使用）列表来管理这一点：活跃列表和非活跃列表。热页面位于活跃列表中；冷或只读一次的页面保留在非活跃列表中，作为驱逐的首选对象。缓冲 I/O：压缩和查询共享页面缓存缓冲 I/O 对大多数应用程序运行良好，通过缓存和预读实现读取优势，并通过延迟合并的刷新实现写入优势，使开发人员无需考虑 I/O 大小和访问模式。对于大多数工作负载，内核做出的决策很好。但并非所有工作负载都是大多数工作负载。页面缓存是一个神圣的空间，最好填充可能很快被重新访问的数据，或者受益于在命中磁盘之前进行合并的写入。### 压缩与页面缓存压缩，即将多个 SSTable 合并为单个 SSTable，是页面缓存污染的一个主要例子。

Kubernetes Service 到底是如何工作的以及你需要了解的 5 种类型

程序员如何打发自己的时间
# Probably Dance我可以编程并且喜欢游戏### 程序员的时间都花在哪里了#### 作者：Malte Skarupke我提交了一个针对 flash attention 的微小补丁。更改所需的打字时间不到十秒，但整个更改花费了十多个小时。那么时间都去哪了？事情始于同事发现一个错误，导致 cudnn attention 随机崩溃。我们查看了他未发布的更改并断定这些更改绝不可能导致这种情况，因此我们怀疑通过对相关代码进行无害更改而暴露出了一个长期存在的错误。步骤 1，几个小时：同事尝试仅通过反复运行代码来尝试各种理论来解决这个问题。这个错误很难重现，因此在几个小时内没有取得太大进展。步骤 2，1 小时：我认为这是尝试 compute sanitizer 的好理由。如果能在现有测试上运行它而没有同事的更改，看看是否发现任何问题，那将是最容易的。但测试运行在另一台机器上，因为它们需要特定的 GPU，这意味着你必须通过一些层来运行测试。不幸的是，compute sanitizer 真的想负责整个程序，所以我们必须说服这些层让 compute sanitizer 运行整个过程。它一直失败，我们找不出原因，直到最后我怀疑问题在于测试运行在沙箱中，并且沙箱非常严格，以某种方式破坏了 compute sanitizer。事实证明这是真的，我们可能一起浪费了一个小时。步骤 3，10 分钟：在测试框架之外运行测试。这出奇地容易，只花了五分钟。Compute sanitizer 立即发现了一个问题。好吧，几乎是立即。你必须知道关闭 pytorch 缓存分配器，因为它隐藏了内存问题。如果我不知道这一点，我可能...

更快的时序聚合
我们通过使用缓存友好的平铺列式执行，将查询执行引擎重构，使真实世界性能提升了 2 倍。将时序查询引擎想象为处理二维数据矩阵：垂直维度是序列，水平维度是时间，单元格是该时间的测量值。查询将在垂直维度聚合之前在两个维度上进行过滤（它选择与您的查询匹配的序列，并将其限制在指定的时间范围内）。

平台工程的端到端
我交谈过的大多数工程师要么认为平台工程是“带有门户的 DevOps”，要么是“拥有 Kubernetes 集群的团队”。两者都不对，但也不完全错。在阅读了 Camille Fournier 和 Ian Nowland 编写的《平台工程：技术、产品和人员领导者指南》之后，并且在 GCP 上构建和支持这些东西几年后，我认为这个学科最好用一句话来理解：平台团队构建和运营一个内部产品，其用户是其他工程师。这听起来很简单。事实并非如此。这篇文章用我自己的话走完了这本书的全过程，以便你可以决定平台工程是否是你真正需要的，以及它在成功运作时是什么样子。假设你已经知道如何交付生产系统。我不会过度解释基础知识，但我会确保每个想法都回答了“它为什么存在”。作为背景，2025 年 DORA 报告发现 90% 的组织至少采用了内部平台，而平台质量现在是人工智能工具产生价值还是混乱的直接预测指标。这不再是一个边缘话题。## 为什么平台工程存在### 过度通用的沼泽云和 OSS 给了我们无限的原语。需要队列吗？你有十二个。需要对象存储、数据库、CI 运行程序、服务网格吗？挑选一个风格。每个应用程序团队的选择都不同，一年后你的“基础设施”就成了一个胶水代码的沼泽，每个服务都有自己的部署流水线、自己的重试逻辑、自己的监控约定、自己的微妙错误的 IAM 绑定。这本书称之为过度通用的沼泽。两种变化将我们推入其中：选择的爆炸式增长（每个云上的每个原语）和更高的运营期望（24/7 正常运行时间、安全性、合规性、成本控制）。每个应用程序团队都在并行地、糟糕地自己处理所有这些。

编程仍然很糟糕
我在参加一个生日聚会，虽然这里的大多数人也在科技行业工作，但总有一个有“真正工作”的人。你知道，一种体力活，构建人们需要的东西。而这个人总是问同样问题的变体：你不担心 AI 会取代你的工作吗？我环顾四周，看到几张脸转向我们，稍微翻了个白眼，然后又回到之前的谈话中。是的，又是这个问题。他们有个侄子在建 Shopify 商店，他们不懂他用的一半词汇，但他确实有真正的麻烦，并说科技行业的每个人都一样。他的侄子需要学习一门“手艺”吗？我们都需要吗？喝得足够多时我会正式回答，因为我不再关心别人是否认为我说的有趣或真实了。但通常我会叹口气说：“当然，是的，有点。我们大多数人都担心。如果不担心才愚蠢，对吧？”他们点点头，然后转向一个更轻松的话题，比如我们是否要核平伊朗。事实是，在科技行业工作一直很糟糕，也从来不是他们想象的那样。有些人认为，我的工作是坐在角落办公室干净的桌子旁，周围是摆满 MacBook 或 Thinkpad 长桌的开放式办公室。在我的角落办公室里，我制定完美的计划，我的完美员工为我鼓掌。没有什么能逃过我的目光，每一个决定都是由我完美地做出的，每一分钱和每一分钟都是有据可查的。当掌声渐息，我的员工、下属，或者当我心情愉快时的“我的团队”，开始疯狂地打字。打字，打字，打字。不久之后，完美的软件就生产出来了。它从集体的流水线上滚下来，就像第一个孩子一样，绝不会出错。除非，那根本不是任何事情的样子。是的，我很沮丧从来没有得到一个角落办公室，但我太忙于恐慌了，因为我不知道自己在做什么，没有人知道，而轮子...

Krabby: 一个从零开始的 Rust 编译器实现
Rust 是我最喜欢的编程语言，但它的编译器非常慢。有许多非常有才华的人致力于改进 rustc，编译速度对他们来说也很重要。在这一点上，如果更改单个函数可以显着提高性能，那么它已经实现了。有意义的改进现在来自于对 API 和数据结构的更改，这些更改的演进非常困难。在像 rustc 这样的大型代码库中，许多功能同时被处理且需要稳定性，进行这种大规模的更改实际上是不可能的。我非常感谢那些找到方法缓慢且逐步推动这些更改的人，但我想要采用一种不同的方法。我发现编译器架构非常迷人，我假设彻底改善编译性能的唯一方法是完全重新思考我们设计编译器的方式。无论目标语言如何，大规模架构优化总是等待被发现。这对于 C 等简单语言可能看起来更明显，但我想证明它可以一直延伸到频谱的另一端，即 Rust。最终的设计可能针对目标语言，但学习总是很有价值的。Krabby 是一个从零开始的 Rust 编译器实现，设计时将性能作为优先级。它与 rustc 的目标有根本的不同；它是一个由个人控制的小型代码库，其中稳定性不是问题。通过在考虑所有其他组件的情况下设计每个组件，我希望找到新的优化机会，并最终获得一个更具凝聚力的架构。称其为一项庞大的工程将是一种轻描淡写。我不知道我有多大可能完成它。我甚至不知道我是否是承担此类项目的合适人选。但我绝对喜欢优化和完善代码的过程，到目前为止...

嵌入式开发：Rust vs C
围绕 Rust 编程语言有很多炒作，我看到它被各种项目采用，尤其是 Linux 内核。然而，到目前为止，我还不清楚它是否适合嵌入式固件开发，因为微控制器的硬件资源是有限的。需要低的内存和存储占用，最佳性能也可能很重要，例如，降低电池供电设备的功耗。由 STMicroelectronics、Inria 和柏林自由大学撰写的题为“利用 Ariel OS 进行工业微控制器用例的教训”的研究论文尝试通过嵌入式 C 和 Rust 来回答这个问题，结论是 Rust 是一个可行的选择：> 随着 Rust 在开发更安全系统软件方面的吸引力，对微控制器硬件领域进行现实核查变得必要。Rust 生态系统为这个领域做好了多少准备？Rust 在实践中能否与 C 竞争？> 这篇论文报告了一个物联网工业案例研究，有助于回答这些问题。两个团队同时开发相同的功能（一个用 C，一个用 Rust），在几个月的时间里进行了分析。提供了对他们的方法、结果和迭代工作的比较分析。硬件上的分析和测量表明，没有强有力的理由基于内存占用或执行速度偏好 C 而不是 Rust 进行微控制器固件开发。> 此外，Ariel OS 被证明提供了一个高效且可移植的 Rust 系统运行时，其占用空间比在这种上下文中传统使用的最先进的裸机 C 堆栈更小。结论是，Rust 是今天在这个领域进行固件开发的一个合理的选择。但让我们不要认为结论是理所当然的，请查看研究（PDF）。

CI/CD中的代码覆盖率究竟意味着什么
看到拉取请求通过所有检查是一种安慰。构建是绿色的，没有测试失败，一切看起来都很稳固。但这是一个令人不安的问题：**你的测试到底覆盖了什么？**这就是代码覆盖率进入对话的地方——不是作为一个虚荣指标，而是作为一个信号。当使用得当时，它不仅可以帮助你理解代码是否有效，还可以理解你实际上验证了多少代码。## 覆盖率是一张地图，而不是分数其核心是，代码覆盖率衡量的是当你运行测试套件时，你的代码库有多少被执行了。最常见的类型包括：- **行覆盖率** – 哪些行被执行了- **分支覆盖率** – 采取了哪些逻辑路径（if/else, switch cases）- **函数/方法覆盖率** – 调用了哪些函数大多数工具默认使用行覆盖率，因为它易于计算和理解。但它也可能具有误导性。执行一行的测试不一定验证其正确性。你可以达到 100% 的行覆盖率，但仍然错过关键错误——特别是在边缘情况和分支逻辑周围。因此，与其将覆盖率视为一个目标，不如将其视为一张未测试区域的地图更有用。## 为什么覆盖率在 CI/CD 中很重要CI/CD 流水线关乎信心。流入你流水线的每次提交都是一次潜在的生产部署。覆盖率充当了保护栏——不是通过保证正确性，而是通过突出风险。当集成到 CI/CD 中时，覆盖率可以帮助你：- 检测拉取请求中引入的未测试代码- 防止测试质量随着时间的推移而悄无声息地下降- 鼓励跨贡献者的一致测试实践更重要的是，它创造了问责制。没有覆盖率检查...

AI

Vibe coding 和智能体工程正变得比我希望的更接近
我最近与 Joseph Ruscio 讨论了 Heavybit High Leverage 播客的 AI 编码工具：[第 9 集，与 Simon Willison 的 AI 编码范式转换](https://www.heavybit.com/library/podcasts/high-leverage/ep-9-the-ai-coding-paradigm-shift-with-simon-willison)。以下是我的一些亮点，包括我令人不安的认识：vibe coding 和代理工程已经开始在我自己的工作中趋同。我真正喜欢播客的一点是，它们有时会促使我大声思考，以一种暴露我以前无法用语言表达的想法的方式。#### Vibe coding 和代理工程开始重叠在 vibe coding 首次被创造出来的几周后，我发布了 [并非所有的 AI 辅助编程都是 vibe coding（但 vibe coding 很酷）](https://simonwillison.net/2025/Mar/19/vibe-coding/)，我在那里坚定地表明了我的信念，即“vibe coding”与负责任地使用 AI 编写代码是非常不同的野兽，我后来开始称之为 [代理工程](https://simonwillison.net/guides/agentic-engineering-patterns/what-is-agentic-engineering/)。当 Joseph 提出两者之间的区别时，我突然意识到它们对我来说已经不像过去那样截然不同了：> 奇怪的是，这些事情对我来说已经开始模糊了，这相当令人不安。>> 我以为我们有非常清晰的界定，其中 vibe coding 是你根本不看代码的事情。你甚至可能不知道如何编程。你可能是一个非程序员，要求一个东西，得到一个东西，如果东西有效，那就太棒了！如果它无效，你告诉它它无效并交叉手指。>> 但在任何时候，你都不会真正关心代码质量或任何那些额外的约束。我对 vibe coding 的看法是，它是美妙的，前提是你明白何时可以使用它，何时不能。>> 对你来说的一个个人工具，如果有 bug，它只会伤害你自己，那就去做吧！

流行工具与项目

traefik/traefik
云原生应用程序代理

jackc/pgx
适用于 Go 的 PostgreSQL 驱动程序和工具包

googleapis/mcp-toolbox
MCP Toolbox for Databases 是一个用于数据库的开源 MCP 服务器。

bjarneo/cliamp
cliamp - 受 winamp 启发的终端音乐播放器

fleetdm/fleet
开放式设备管理

open-telemetry/opentelemetry-collector-contrib
OpenTelemetry Collector 的贡献仓库

aquasecurity/trivy
查找容器、Kubernetes、代码仓库、云平台等中的漏洞、配置错误、密钥、SBOM

xpzouying/xiaohongshu-mcp
小红书的 MCP

gosom/google-maps-scraper
从谷歌地图抓取数据。提取每个地点的名称、地址、电话号码、网站 URL、评分、评论数、纬度和经度、评论、电子邮件等信息

FiloSottile/mkcert
一个简单的零配置工具，用于制作带有你想要的任何名称的本地信任开发证书。