前言 在 AI 辅助编程时代，一个关键问题浮现：AI 助手会如何影响开发者的工具选择？ Amplifying AI 团队进行了一项开创性研究，他们让 Claude Code 处理 2,430 个真实代码仓库，观察它在没有任何工具提示的情况下如何选择技术工具。 这项研究的规模和深度令人印象深刻：3 个模型、4 种项目类型、20 个工具类别、85.3% 的提取率。研究涉及 Sonnet 4.5、Opus 4.5 和 Opus 4.6 三个模型，覆盖从 CI/CD 到实时开发的广泛场景。 核心发现：倾向自建，而非引入现成库 研究最令人震惊的发现是：Claude Code 更倾向于自己构建解决方案，而不是推荐现有的开源库或第三方服务。 在 20 个类别中，有 12 个类别（60%）Claude 选择"自定义/DIY"而非成熟工具。总计有 252 次自定义实现，超过任何单一工具的推荐次数。 典型案例 特性标志（Feature Flags）： 预期：推荐 LaunchDarkly 等现成服务 实际：自己构建配置系统，使用环境变量 + 百分比控制功能开关 Python 认证： 预期：推荐 Auth0、Passport.js 等库 实际：从零编写 JWT + bcrypt 实现（100% DIY 比例） 缓存： 预期：推荐 Redis、Memcached 实际：实现内存 TTL 包装器 这种倾向在以下领域尤为明显： 特性标志：69% DIY Python 认证：100% DIY 可观测性：22% DIY 整体认证：48% DIY 默认工具栈：JavaScript 生态的主导地位 当 Claude Code 确实选择推荐工具时，它的偏好非常明确： ...

Git 支持许多配置文件来变更其行为，这篇博客详细介绍了各种配置文件的作用。 必备配置：.gitignore 用的最多，甚至可以说每个项目必备。定义哪些文件不应该被 Git 跟踪。 其他实用配置 .gitattributes 配置 Git 如何处理特定文件，如行尾归一化、二进制文件标记、自定义 diff 驱动等。 .lfsconfig Git LFS 的配置文件，让团队可以使用统一的 LFS 设置。 .gitmodules 子模块配置文件，用于管理嵌套的 Git 仓库依赖。 .mailmap 邮箱映射，解决 contributors 更换邮箱或姓名后显示为多个人的问题——再也不会出现两个我了。 .gitmessage 配置提交消息的模板。但需要每次 clone 后手动运行 git config commit.template .gitmessage，所以不是常规的选择，大多数项目更喜欢用 commit-msg hooks。 参考： Git’s Magic Files - nesbitt.io 本文包含AI生成内容

阿里巴巴开源的 Zvec 向量数据库是一个轻量级、快速的进程内向量数据库，为开发者提供了一个简单而强大的方式来构建向量搜索应用。在 AI 和向量搜索技术快速发展的今天，我们来深入了解这个值得关注的项目。 什么是 Zvec？ Zvec 是一个开源的进程内向量数据库，主打"轻量级、闪电般快速"。与传统的独立向量数据库服务不同，Zvec 采用进程内架构，可以直接嵌入到应用程序中运行。它基于阿里巴巴经过实战检验的 Proxima 向量搜索引擎构建，继承了阿里巴巴在高并发、大规模场景下的技术积累。 核心特性 极快的速度：能够在毫秒级别搜索数十亿个向量，性能表现优异 开箱即用：安装后几秒钟即可开始使用，无需复杂的服务器配置 多种向量支持：同时支持密集向量（dense vectors）和稀疏向量（sparse vectors） 混合搜索：可以结合语义相似度和结构化过滤条件进行精确搜索 跨平台运行：作为进程内库，可以在笔记本、服务器、CLI 工具甚至边缘设备上运行 数据持久化：支持本地文件存储，数据不会因为进程退出而丢失 快速上手 Zvec 目前支持 Python 和 Node.js 两种语言，Python 版本支持 3.10-3.12，覆盖了主流的开发环境。 安装 1 pip install zvec 或者使用 Node.js： 1 npm install @zvec/zvec 基本使用示例 让我们通过一个完整的例子来了解 Zvec 的基本用法： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 import zvec # 定义集合 schema schema = zvec.CollectionSchema( name="example", vectors=zvec.VectorSchema("embedding", zvec.DataType.VECTOR_FP32, 4), ) # 创建集合（本地文件存储） collection = zvec.create_and_open(path="./zvec_example", schema=schema) # 插入文档 collection.insert([ zvec.Doc(id="doc_1", vectors={"embedding": [0.1, 0.2, 0.3, 0.4]}), zvec.Doc(id="doc_2", vectors={"embedding": [0.2, 0.3, 0.4, 0.1]}), ]) # 按向量相似度搜索 results = collection.query( zvec.VectorQuery("embedding", vector=[0.4, 0.3, 0.3, 0.1]), topk=10 ) # 结果按相关性排序 print(results) 这个简单的例子展示了 Zvec 的三个核心操作：定义 schema、插入数据和搜索查询。 ...

最近在探索 AI 工具生态时，发现了一个很有用的工具——mcporter。这是一个专门用于 Model Context Protocol (MCP) 的 CLI 工具和生成器，可以帮助我们更方便地发现和使用各种 MCP 服务器提供的工具。 什么是 MCP？ Model Context Protocol (MCP) 是一个开放标准，定义了 AI 助手如何与外部工具和服务进行通信。通过 MCP，我们可以将各种功能集成到 AI 助手中，比如文档查询、数据库访问、API 调用等。 mcporter 的核心功能 mcporter 提供了几个关键功能： 1. 服务器管理 1 2 mcporter list # 列出所有配置的 MCP 服务器 mcporter list <server> --schema # 查看特定服务器的工具定义 这个功能让我能够快速了解有哪些可用的工具，以及每个工具的输入输出格式。 2. 工具调用 1 mcporter call <selector> [key=value ...] 可以直接调用 MCP 工具，支持通过 HTTP URL 或服务器名.工具名的选择器来定位。 3. 配置管理 mcporter 会自动从 config/mcporter.json 加载服务器配置，也支持从编辑器（如 Cursor、Claude）导入配置。 实际应用场景 配置好 mcporter 后，我发现它在以下几个场景特别有用： ...

My LLM codegen workflow atm, Harper Reed在文中介绍了基于LLM的代码生成工作流。主要介绍了两种场景，开发一个新项目（Greenfield）以及老项目的持续迭代(Non-greenfield)。 新项目基于需求细化（spec），计划制定（todo）以及代码生成三部分来开展。老项目则通过生成代码上下文（repomix）来制定测试回归和代码审查任务。这对我来说是一个巨大的启发，准备找时间试一下其中描述的工作流程。 同时Harper Reed也给出了具体的Prompt，局限于目前LLM的特性，仍然需要通过提示工程来引导AI生成我们需要的内容。前一阵子较火的DeepSeek从入门到精通也指出掌握提示语设计是AIGC时代的必备技能，在平时使用这些LLM工具中也感受到怎么清晰的向AI表达需求非常重要，因为你的提示语完全决定了AI生成的质量，进而决定了AI是否好用或者为你带来提效。另外，由于中文的特性（高上下文依赖）以及模型的训练数据分布，可能会出现提示效果不如英文的情况。

Go 1.24 Release Notes， Go 1.24已经于2.11正式发布，主要语言特性为泛型类型别名和基于Swiss Tables的map实现，通过轻微的delete性能损耗来显著提升查询和插入的性能（via）。

Three Observations, 奥尔特曼提出了关于AI经济学的3个论断： AI模型的智能水平大致等于用于训练和运行它的资源的对数； 使用特定水平的AI的成本每12个月大约下降10倍（摩尔定律18个月才有2倍）； 线性增加的智能所带来的社会经济价值是超指数级的。 随着DeepSeek-R1的火爆，整个社会更广泛的进入了AI时代，一众大厂应用纷纷接入，普通人使用的成本进一步下降。之前一直有观点认为AI会逐步淘汰部分岗位，并且这种事情会首先发生在程序员这个职业上。目前就我个人的体验来讲，AI现在已经能做到生成不错的代码，处理较为复杂的任务。虽然在整个公司层面还没有开始大规模在开发流程中使用AI，但我认为这是未来近几年的方向，届时会出现Cursor、通义灵码这些产品的终极形态，AI变成你的同事。而作为程序员的我们，工作方式会更向需求分析、架构设计和团队协作等需要人类创造力和判断力的方向靠拢（via）。

Build a link blog, 最近从Simon Willison看到的想法，觉得是一个重新捡起Blog的机会。这个依托于Github Pages 的博客站点荒废了好久，最早可以追溯到2018年，彼时还未大学毕业，中间有一段时间荒废，后续迁移到博客园上重启，过来一段时间后又荒废。如今又重新捡起，说实话整体感受还是比较复杂的，之前荒废的原因无外乎以下几点： 懒； 觉得无法输出有意思的观点，只是在拾人牙慧； 由于2，导致写blog过程中没收到什么反馈，没有反馈的事情，对人类来说还是太难坚持了。 但是近期从Simon Willison那了解到了关于blog内容的新思路： It’s easy to get hung up on this. I’ve definitely felt the self-imposed pressure to only write something if it’s new, and unique, and feels like it’s never been said before. This is a mental trap that does nothing but hold you back. 这个我深有同感，一开始其实整体内容围绕着一些常见的学习知识点、读书内容，慢慢就发现，如果说我不能输出独特的观点，这值得我写一篇文章/博客吗？进而转到如果我的博客没人看，我还要花时间在上面吗？甚至之前还觉得我应该写英文文章，这样部署在Github Pages才有更多的读者。说回来，Simon Willison认为blog的价值在于保持长期的写作习惯，同时随着时间的推移有所收获， 同时Simon Willison给出了写blog的几个内容(via)： TIL(Things I Learned)； DMP(Descriptions of My Projects)； TIF(Things I’ve Found)。 基于3就衍生出了本文的主题，“links”, 也就是说通过blog的形式分享记录自己阅读的内容。作为一个Link Blog, 可以包含以下内容： ...