运维123 - 编程
type: channel
link: https://www.sddts.cn/index.php/category/%E7%BC%96%E7%A8%8B/
items: AI 时代代码的价值被严重低估
items: Linux 应用开发基础教程
items: 从零重建VisiCalc电子表格软件
items: 生活在平面国的程序员
items: 足够详细的规范就是代码
items: 每一层审查让你慢 10 倍
items: Emacs 与 Vim 在 AI 时代的未来
items: 2026年重返Rails
items: CLI-Anything：让所有软件成为 AI Agent 原生工具
items: AI 如何影响技能养成：Anthropic 实验研究揭示关键发现

AI 时代代码的价值被严重低估
type: item
date: 2026-03-22T22:48:28+00:00
description: AI 时代代码的价值被严重低估一、新闻概述1. 标题AI 时代代码的价值被严重低估：自然语言的精确性陷阱2. 发布时间2026 年 3 月 21 日3. 来源Steve Krouse 技术博客二、核心内容1. 事件摘要A. 主要内容Steve Krouse 发表文章反驳"代码已死"的观点，深入探讨了 AI 时代编程的价值，以及自然语言规格与代码规格在精确性上的本质差异。B. 核心亮点自然语言规格存在精确性错觉Vibe Coding 在规模化时遭遇抽象泄漏抽象是掌握复杂性的关键工具AGI 时代仍需高质量代码和更好的抽象2. 关键信息A. 背景当前社会舆论普遍认为"编程已死"，甚至知名播客主持人 Sam Harris 也公开表示"没有人应该再学习编程"。B. 核心论点代码是精确思维的产物，不仅仅是生成软件的工具AI 的真正价值在于帮助我们创造更好的抽象编程在 AI 时代将迎来新的繁荣3. 背景介绍A. 相关概念Vibe Coding：指用自然语言描述想法，让 AI 生成代码，然后通过视觉反馈迭代调整的开发方式。B. 讨论起源文章引用了"A sufficiently detailed spec is code"的观点，用漫画展示了自然语言规格的精确性错觉。三、详细报道1. 自然语言的精确性陷阱A. 核心问题自然语言规格在直觉上让人感觉很精确，但实际经验会揭示其充满歧义的本质。引用 Bertrand Russell 的名言："Everything is vague to a degree you do not realize till you have tried to make it precise."B. 规格对比graph LR A[自然语言规格] -->|感觉精确| B[直觉理解] B -->|实际| C[充满歧义] C -->|导致| D[意外行为] D -->|揭示| E[抽象泄漏] F[代码规格] -->|强制精确| G[编译/执行] G -->|反馈| H[错误暴露] H -->|促进| I[迭代改进]C. 迭代精确化编程和写作一样，是迭代精化的活动。AI 能帮助我们将英语转化为可运行的代码，然后通过反应式调整逐步精确化我们的想法。2. Vibe Coding 的局限性A. 概念解析Vibe Coding 让人停留在英语层面的直觉感受，同时通过 AI 生成的产物来帮助精化思维。B. 潜在风险Vibe Coding 给人一种错觉：认为直觉感受就是精确的抽象。这种感觉会持续到抽象泄漏发生时——当你添加足够多的功能或达到足够大的规模时，你不理解的底层抽象的意外行为会悄悄出现，破坏整个系统。C. 实际案例Dan Shipper 的 vibe-coded 文本编辑器应用爆火后崩溃的经历表明："实时协作极其困难"。看似精确的规格背后，隐藏着巨大的复杂性。graph TB subgraph Vibe Coding 流程 A1[英语想法] --> A2[AI 生成代码] A2 --> A3[视觉反馈] A3 --> A4[迭代调整] end subgraph 隐藏的复杂性 B1[底层抽象] --> B2[意外行为] B2 --> B3[故障调试] end A4 -->|规模化时触发| B1D. 复杂性的隐蔽性复杂性可能极其无聊、令人不快，难以记住所有细节和边缘情况。例如 Slack 决定何时发送通知的经典流程图展示了通知逻辑的复杂性。3. 抽象的价值A. 认知限制人类大脑存在基本限制：我们一次只能思考 7 个（±2）事物。B. 抽象的作用思考超过 7 个事物的唯一方法是将多个事物压缩为一个事物。这种压缩可以递归应用，使人类能够掌握无限的复杂性。引用 Edsger Dijkstra 的名言："The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise."C. 抽象机制graph TD A[复杂系统] -->|通过抽象| B[压缩认知] B --> C[7±2 项] C -->|递归应用| D[多层抽象] D --> E[掌握无限复杂性] F[具体细节] -->|抽象为| G[语义层] G -->|实现精确性| H[高层概念]D. 最佳实践编程的最佳部分之一是提出越来越好的抽象来帮助我们掌握复杂性。例如 ReactJS 和 TailwindCSS 在各自领域通过抽象简化了开发。4. AGI 时代的编程A. 错误观点认为 AGI 到来后将不再需要关注细节，只需让 AI 处理所有麻烦。B. 正确理解代码不仅仅是软件的副产品，它本身就是重要的产物。当做得好时，代码是…

Linux 应用开发基础教程
type: item
date: 2026-03-22T04:02:24+00:00
description: Linux 应用开发基础教程一、概述1. 简介A. 是什么《Linux Application Development By Example - The Fundamental APIs》是由 Arnold Robbins 编写的 Linux 应用程序开发教程书籍，第二版于 2026 年出版。本书通过大量示例代码，系统介绍 Linux 系统编程的核心 API 和开发技巧。B. 为什么学掌握 Linux 系统编程基础，理解操作系统工作原理学习 POSIX 标准 API，提升跨平台开发能力通过实例代码快速掌握复杂的系统调用概念培养底层思维，为学习高级框架打下坚实基础C. 学完能做什么开发 Linux 命令行工具和系统程序处理文件 I/O、进程管理、信号处理等系统级任务进行网络编程和国际化应用开发使用调试工具分析和修复程序问题2. 前置知识A. 必备技能C 语言基础：指针、结构体、内存管理基本 Linux 操作：命令行使用、文件系统概念编译工具使用：gcc、makeB. 推荐知识操作系统基础概念：进程、线程、虚拟内存POSIX 标准了解Git 版本控制二、书籍结构1. 内容组织本书共 17 章，涵盖 Linux 应用开发的各个方面：mindmap root((Linux 应用开发)) 基础入门 第1章 简介 第2章 命令行 第3章 内存 文件操作 第4章 文件IO 第5章 文件信息 第7章 ls 实现 进程管理 第9章 进程 第10章 信号 第12章 资源限制 系统功能 第6章 通用工具1 第8章 挂载 第13章 通用工具2 高级主题 第14章 网络 第15章 国际化 第16章 扩展属性 第17章 调试2. 章节概览章节目录主题第 1 章ch-01-intro入门示例，数学计算程序第 2 章ch-02-cmdline命令行参数处理，环境变量第 3 章ch-03-memory动态内存分配，地址空间第 4 章ch-04-fileio文件 I/O，系统调用与库函数第 5 章ch-05-fileinfo文件元数据，stat 系统调用第 6 章ch-06-general1通用工具：时间、用户信息第 7 章ch-07-ls实现 ls 命令第 8 章ch-08-mounting文件系统挂载第 9 章ch-09-processes进程创建与管理第 10 章ch-10-signals信号处理第 12 章ch-12-limits系统资源限制第 13 章ch-13-general2更多通用工具第 14 章ch-14-networking网络编程基础第 15 章ch-15-i18n国际化与本地化第 16 章ch-16-extended扩展属性第 17 章ch-17-debugging调试技巧与工具三、核心概念1. 系统调用与库函数Linux 编程中区分两类函数：A. 系统调用直接进入内核态执行开销较大，需要上下文切换提供核心功能：文件操作、进程管理、网络通信B. 库函数在用户态执行通常封装系统调用，提供更友好的接口标准 C 库函数：printf、malloc、fopengraph TB A[应用程序] --> B{函数类型} B -->|库函数| C[glibc 等] B -->|系统调用| D[内核] C --> D D --> E[硬件资源]2. Linux 编程模型A. 一切皆文件普通文件、目录、设备、套接字都通过文件描述符访问标准 I/O：stdin（0）、stdout（1）、stderr（2）B. 进程模型进程是资源分配的基本单位fork + exec 创建新进程父子进程关系与等待机制C. 权限模型用户 ID 和组 ID文件权限：rwx 权限位setuid/setgid 机制四、快速上手1. 获取代码克隆本书的代码仓库：git clone https://github.com/arnoldrobbins/LinuxByExample-2e.git cd LinuxByExample-2e2. 编译示例各章节目录包含独立的示例程序，使用 gcc 编译：cd ch-01-intro gcc -o sindegrees ch-intro-sindegrees.c -lm ./sindegrees3. 代码风格说明命名规范：ch-<章节名>-<功能描述>.c头文件：ch-<章节名>-<功能描述>.h测试程序：ch-<章节名>-<功能>-test*.c脚本文件：功能描述.sh五、重点章节解析1. 第 1 章：入门示例A. 数学计算程序该章实现一个角度与弧度转换的程序，展示基本的 C 程序结构和数学库使用。核心代码结构：主程序：ch-intro-sindegrees.c头文件：ch-intro-sindegrees.h测试程序：多个测试版本2. 第 2 章：…

从零重建VisiCalc电子表格软件
type: item
date: 2026-03-21T01:27:12+00:00
description: 从零重建 VisiCalc 电子表格软件一、概述1. 项目背景A. VisiCalc 的历史意义VisiCalc 是世界上第一款电子表格软件，由 Dan Bricklin 和 Bob Frankston 于 1979 年创造。这款软件仅用数千行 6502 汇编代码编写，却能在 16KB 内存的机器上运行。它成为 Apple II 的杀手级应用，销量超过 100 万份，将早期的个人电脑转变为真正的商业工具。B. 电子表格的设计理念电子表格被誉为史上最佳用户体验设计之一。它具有极简的学习曲线，允许用户快速操作数据、描述逻辑、可视化结果，甚至可以用它创作艺术和运行 GameBoy 模拟器。C. 本文目标从零开始构建一个最小化的 VisiCalc 克隆版本，探索电子表格的核心设计原理。最终实现将包含完整的数据模型、公式求值器和简单的终端用户界面。2. 核心问题如何用最少的代码实现一个功能完整的电子表格系统，需要解决以下问题：如何表示和存储单元格数据如何解析和计算数学公式如何处理单元格间的依赖关系如何构建高效的用户界面二、系统设计1. 核心概念电子表格系统由以下几个基本概念组成：单元格（Cell）：表格的基本单位，可存储值、公式或标签网格（Grid）：单元格的二维集合公式（Formula）：引用其他单元格的数学表达式响应式计算：当单元格值变化时自动重新计算相关公式2. 数据模型设计A. 单元格结构每个单元格可以处于四种状态之一：空、数值、标签或公式。#define MAXIN 128 // 单元格输入最大长度 enum { EMPTY, NUM, LABEL, FORMULA }; // 单元格类型 struct cell { int type; // 单元格类型 float val; // 数值 char text[MAXIN]; // 原始用户输入 };B. 网格结构Excel 有 1,048,576 行和 16,384 列的限制，原始 VisiCalc 有 256 行和 64 列。我们的迷你版本可以使用更小的尺寸：#define NCOL 26 // 最大列数 (A..Z) #define NROW 50 // 最大行数 struct grid { struct cell cells[NCOL][NROW]; };3. 系统架构graph TB subgraph 用户界面 UI[TUI 界面] Input[输入处理] end subgraph 核心引擎 Grid[网格数据] Parser[公式解析器] Recalc[重新计算] end subgraph 数据模型 Cell[单元格] Formula[公式] end UI --> Input Input --> Grid Grid --> Parser Parser --> Recalc Recalc --> Grid Grid --> Cell Cell --> Formula三、公式求值器1. 解析器设计使用递归下降解析器（Recursive Descent Parser）来计算公式。解析器需要能够：识别数字和单元格引用处理运算符优先级支持函数调用访问网格中的单元格值A. 解析器结构struct parser { const char* s; // 公式字符串 int pos; // 当前位置 struct grid* g; // 网格引用 };2. 语法解析层次公式解析遵循经典的运算符优先级规则：表达式（Expression）：由加法和减法连接的项项（Term）：由乘法和除法连接的因子因子（Factor）：数字、单元格引用、函数调用或括号表达式graph TD A[表达式 Expression] --> B[项 Term] B --> C[因子 Factor] C --> D[数字 Number] C --> E[单元格引用 CellRef] C --> F[函数调用 Function] C --> G[括号表达式 ParenExpr] B -->|+/-| B A -->|*//| A3. 解析实现A. 因子解析因子是最基本的语法单位，可以是：带符号的一元运算函数调用（以 @ 开头）括号表达式数字字面量单元格引用float primary(struct parser* p) { skipws(p); if (!*p->p) return NAN; // 处理一元加号 if (*p->p == '+') p->p++; // 处理一元减号 if (*p->p == '-') { p->p++; return -primary(p); } // 函数调用 if (*p->p == '@') { p->p++; return func(p); } // 括号表达式 if (*p->…

生活在平面国的程序员
type: item
date: 2026-03-20T06:39:28+00:00
description: 生活在平面国的程序员一、概述1. 文章简介A. 标题The programmers who live in Flatland（生活在平面国的程序员）B. 发布时间2025 年 11 月 24 日C. 来源Red Planet Labs 博客D. 作者Nathan Marz（Clojure 专家、Rama 框架创始人）2. 核心隐喻文章借用 Edwin Abbott 的经典小说《Flatland：A Romance of Many Dimensions》中的概念：二维世界的居民无法理解第三维度的存在。作者将此隐喻延伸到编程领域——许多程序员受限于自己的"维度"，无法理解更强大的编程抽象。3. 文章主旨大多数程序员生活在"编程平面国"中，他们无法理解 Lisp/Clojure 宏（macros）所代表的更高维度的编程能力。这并非因为宏没有价值，而是因为他们缺乏理解这种抽象所需的"表征机制"。二、背景故事：Paul Graham 与 Lisp1. Beating the Averages2001 年，Paul Graham 发表著名文章《Beating the Averages》，核心论点包括：A. Lisp 的根本优势Lisp 比其他语言本质上更强大宏（macros）是 Lisp 的核心区分能力Viaweb 使用 Lisp 构建了竞争对手无法实现的功能B. 作者的亲身体验Nathan Marz 受这篇文章影响，过去 15 年一直将 Clojure 作为主要编程语言。他证实 Paul Graham 关于宏的描述"绝对正确"。2. 现实困境A. 采用率极低Lisp/Clojure 全球使用比例极小（Stack Overflow 调查显示约 2.6%）与其巨大的优势不成正比B. 常见误解"生态系统"障碍：对 Common Lisp 有效，但 Clojure 可与 Java 生态系统互操作"括号很怪"的直观反应括号的感知成本从未与 Clojure 的巨大收益进行权衡C. Blub ParadoxPaul Graham 提出的"Blub 悖论"试图解释这种脱节，本文从另一个角度补充这个解释。三、编程的维度1. 两类抽象A. 自动化抽象大多数程序员使用的抽象属于此类：将一组操作打包在一个名称后面函数是经典例子：接受输入，产生输出只需要了解函数的规格和性能特征B. 维度扩展抽象罕见的抽象类型：扩展编程本身的代数改变基本概念和概念间关系的种类创造新的"维度"2. Lisp/Clojure 宏的维度之力A. 语言的自我组合源于语言的统一性，使语言能够自我组合：编译时逻辑可以像运行时一样执行使用相同的函数和技术语法树可以被操纵和转换B. 语义控制实现对代码语义本身的控制：宏不仅仅是语法糖它们改变了代码的结构和含义可以创造全新的控制结构C. 编译时的轻松操纵effortless compile-time manipulation 是一个新的编程维度：编译时代码生成变得简单元编程成为一等公民运行时和编译时的界限变得模糊3. Flatland 隐喻graph LR subgraph Flatland["2D 平面国"] F1[三角形] F2[正方形] F3[圆形] end subgraph Spaceland["3D 空间国"] S[球体] end S -.-> F1 S -.-> F2 S -.-> F3在 Flatland 中，正方形无法理解第三维度，因为他只能以 2D 思考。同样，你无法理解新的编程维度，因为你不知道如何在该维度中思考。你没有"表征机制"来理解新维度提供的东西。2D 程序员可能会得出 3D 概念客观上错误的结论——这不是因为他们理解了它，而是因为他们试图将其扁平化到自己的坐标系中。四、学习新维度1. 说服的局限性你不能用 3D 论据说服 2D 的人。这就像在 Flatland 中，球体无法让正方形理解"上"和"下"的含义。2. 隐喻的断裂点然而，这正是隐喻失效的地方：你的大脑永远无法理解 4D 空间但你的大脑可以适应新的编程维度3. Lisp 学习曲线采用 Lisp/Clojure 的人通常描述相似的经历：graph LR A[不适感] --> B[一系列清晰时刻] B --> C[无法回头的顿悟] C --> D[新维度的思维方式]A. 第一阶段：不适感语法看起来"奇怪"编程范式不同需要改变思维习惯B. 第二阶段：清晰时刻逐渐理解宏的威力开始看到代码抽象的新可能性意识到之前方法的局限性C. 第三阶段：无法回头新维度的思维成为自然回到旧语言感觉受限理解了什么是真正的编程抽象4. 突破认知偏见需要的只是：好奇心理解最好的编程思想有时无法立即被欣赏识别自己的认知偏见认识到这种偏见足以打破它，这是作为程序员成长的最好方式之一。五、社区讨论与…

足够详细的规范就是代码
type: item
date: 2026-03-19T09:10:38+00:00
description: 足够详细的规范就是代码一、新闻概述1. 标题足够详细的规范就是代码2. 发布时间2026 年 3 月 17 日3. 来源Haskell for all 技术博客二、核心内容1. 事件摘要A. 主要内容本文作者以批判的视角分析了"从规范文档生成代码"（agentic coding）的理念，认为这种做法本质上是在重蹈历史覆辙——试图用自然语言替代精确的代码表达。B. 核心亮点指出 agentic coding 宣传的两个常见误解以 OpenAI 的 Symphony 项目为案例，剖析其"规范文档"的本质引用 Dijkstra 的理论，说明精确描述必然演变为代码通过实际测试证明，即使非常详细的规范也无法可靠生成工作代码2. 关键信息A. 涉及项目OpenAI Symphony：一个声称从规范文档生成的 agent 编排器B. 核心论点当规范文档足够精确到能可靠生成实现时，它必然扭曲成代码或类似代码的形式规范文档从来不是省时工具，如果追求交付速度，直接写代码更有效C. 技术术语Agentic coding：基于 AI agent 的代码生成Specification：规范文档Narrow interfaces：狭义接口（即代码）3. 背景介绍A. 相关上下文近年来，业界兴起"从自然语言规范生成代码"的理念，宣传工程师可以转变为编写规范的"管理者"，而由 AI agent 完成编码工作。B. 作者立场作者对此持反对意见，认为这是对软件工程本质的误解。三、详细报道1. 主要内容A. 两个常见误解误解 1：规范文档比对应代码更简单Agentic coding 推广者常将此理念卖给相信者，让他们幻想工程师变成管理者，只需编写规范文档后交给 agent 团队执行。这只有在规范工作比实际编码更便宜时才成立。误解 2：规范工作必须比编码工作更深思熟虑推广者用此观点说服怀疑者，声称通过规范文档过滤工作能提高质量并促进更好的工程实践。B. Symphony 案例分析OpenAI 的 Symphony 项目被宣传为从规范文档生成项目的范例。其所谓的"规范文档"（SPEC.md）实际上更像 Markdown 形式的伪代码，而非传统意义上的规范。文档包含：数据库 schema 的散文描述：列出字段名、类型、约束代码的散文描述：如并发控制、重试逻辑专门为模型代码生成添加的"速查表"部分完整的算法代码块示例：服务启动算法function start_service(): configure_logging() start_observability_outputs() start_workflow_watch(on_change=reload_and_reapply_workflow) state = { poll_interval_ms: get_config_poll_interval_ms(), max_concurrent_agents: get_config_max_concurrent_agents(), running: {}, claimed: set(), retry_attempts: {}, completed: set(), codex_totals: {input_tokens: 0, output_tokens: 0, total_tokens: 0, seconds_running: 0}, codex_rate_limits: null } ...C. Dijkstra 理论支持Edsger W. Dijkstra 在 EWD667 文章中解释了为何精确描述必然演变为代码：数学史表明，希腊数学停留在口头和图形阶段，穆斯林代数在符号化尝试后因回归修辞风格而消亡，现代文明世界只有在西欧摆脱中世纪经院主义后才能兴起。软件工程同理，试图用自然语言追求精确性是徒劳的。2. 技术细节A. 规范与代码的关系graph LR A[自然语言想法] --> B{足够精确?} B -->|否| C[模糊规范] B -->|是| D[结构化形式] D --> E[伪代码] D --> F[形式化规范] E --> G[实际代码] F --> G C --> H[生成失败/不完整]B. 实际测试结果作者尝试使用 Claude Code 按照 Symphony 规范生成 Haskell 实现，结果：存在多个 bug，需要多次提示修复即使"成功"运行，codex agent 也只是静默旋转，无法处理 Linear 工单结果存储在 Gabriella439/symphony-haskell 仓库C. 其他规范示例YAML 规范极其详细、广泛使用、包含一致性测试套件，但大多数 YAML 实现仍不完全符合规范。这印证了精确规范不等于可靠实现。3. 数据与事实A. 规…

每一层审查让你慢 10 倍
type: item
date: 2026-03-17T11:29:21+00:00
description: 每一层审查让你慢 10 倍一、新闻概述1. 标题每一层审查让你慢 10 倍2. 发布时间2026 年 3 月 16 日3. 来源apenwarr.ca（Avery Pennarun 的个人博客）二、核心内容1. 事件摘要A. 主要内容Tailscale CEO Avery Pennarun 发表观点文章，指出软件开发中每一层审查都会让流程变慢 10 倍。文章分析了为什么 AI 代码生成无法解决这一瓶颈，并提出了通过减少审查层级和建立信任文化来提高开发效率的方案。B. 核心亮点每一层审查会让流程慢 10 倍（按实际时间计算，而非工作量）AI 的加速作用被后续审查等待时间抵消传统 QA（质量保证）模式反而会降低质量通过模块化和小组信任文化替代多层级审查2. 关键信息A. 版本号/发布内容这是一篇博客观点文章，非产品发布B. 重要数据简单 Bug 修复：30 分钟同事代码审查：300 分钟（5 小时）设计文档批准：50 小时（约 1 周）跨团队协调：500 小时（12 周，一个季度）高管决策：10 个季度（约 2.5 年）C. 涉及产品/技术软件开发流程、代码审查、质量保证、AI 编码助手、模块化架构3. 背景介绍A. 前置版本/历史作者 Avery Pennarun 之前有多篇关于系统设计的文章，本文是其系统设计系列的延续，特别关注 LLM（大型语言模型）时代的软件工程问题。B. 相关上下文随着 Claude Code 等 AI 编码工具的兴起，软件开发速度大幅提升，但传统的审查流程成为新的瓶颈。三、详细报道1. 主要内容A. 审查层级的速度衰减规律作者提出一个经验法则：每一层审查会让流程变慢 10 倍。这里的变慢指的是实际时间，而非工作量。大部分额外时间都花在等待上。具体示例：graph LR A[简单 Bug 修复 30 分钟] --> B[同事代码审查 300 分钟] B --> C[设计文档批准 3000 分钟] C --> D[跨团队协调 30000 分钟] D --> E[高管决策 75000 分钟]B. AI 无法解决等待延迟问题AI 编码工具可以将编码时间从 30 分钟缩短到 3 分钟，但：如果开发者用节省的时间自己审查 AI 生成的代码，仍然是循环等待如果直接提交未验证代码，审查者仍需 5 小时，且会因阅读低质量代码而不满如果用于大型项目，代码太长无法一次审查，需要拆分为多个小块，每个都有 5 小时审查周期C. QA（质量保证）的悖论作者引用 W. E. Deming 的质量管理哲学，指出传统 QA 模式的问题：在工厂环境中，如果每一轮 QA 能捕获 90% 的缺陷，理论上两轮就能减少 100 倍缺陷。但现实中的问题：第一道 QA 知道有第二道 QA，会降低工作标准第二道 QA 不愿过于严格，因为这会影响同事的评价生产人员知道有 QA 检查，会降低生产时的质量控制这种"多层检查"模式实际上激励了质量控制的外部化，而非内部化。D. 日本汽车制造业的启示著名的丰田生产系统完全取消了专门的 QA 阶段，而是给每个工人一个"停止生产线"按钮。当发现缺陷时，任何人都可以停止生产线进行修复。美国汽车制造商试图复制这一系统，安装了同样的按钮，但没有人敢使用，因为害怕被解雇。关键差异在于信任：员工信任上级真心希望了解每个缺陷管理层信任员工会主动发现问题执行层信任系统确实有效E. 代码审查的真正使命代码审查者的工作不是审查代码，而是弄清楚如何让这一类评论在未来不再出现。等到审查发现错误时，错误已经发生了。审查只是症状，而非根本原因。F. 模块化和小组协作的解决方案作者提出的解决方案：组件应该由能全权负责的小团队构建小团队可以建立对质量的共识和信任通过清晰定义的接口，组件可以可靠地交付给其他团队可以让多个小组竞争构建同一组件，通过进化选择质量利用 AI 快速尝试不同的模块边界代码现在很便宜，但好的想法仍然稀缺。AI 编码使我们能比以往更快地实验新想法。2. 技术细节A. AI 开发者的堕落循环作者描述了 AI 辅助开发中常见的恶性循环：graph TD A[1. 原型快速完成] --> B[2. 发现 Bug 让 AI 修复] B --> C[3. 每次修复引入新 Bug] C --> D[4. 用 AI 代理审查代码] D --> E[5. 人工在代理间传递数据] E --> F[6. 需要代理框架] F --> G[7. 让 AI 编写代理框架] G --> A许多开发者陷入这个循环，不断让 AI 生成更复杂的代理框架，而实际代码质量没有提升。B. 单体和微服务的平衡微服务之前名声不好，因为它们"太微"。在原始术语中，一个"微"服务正好适合"两个披萨团队"独立构建和运维。有了 AI，可能只需要一个披萨和一些 token。有趣的是…

Emacs 与 Vim 在 AI 时代的未来
type: item
date: 2026-03-16T03:06:05+00:00
description: Emacs 与 Vim 在 AI 时代的未来一、新闻概述1. 标题Emacs and Vim in the Age of AI（Emacs 与 Vim 在 AI 时代）2. 发布时间2026 年 3 月 9 日3. 来源(think) 个人博客二、核心内容1. 事件摘要A. 主要内容文章作者 Bozhidar Batsov 作为拥有 20 年以上 Emacs 使用经验的核心贡献者，深入分析了在 AI 工具快速发展的背景下，Emacs 和 Vim 这两款传统编辑器面临的挑战与机遇。B. 核心亮点VS Code 和专用 AI 编辑器（Cursor、Windsurf 等）正在形成强大的吸引引力AI 改变了编程的核心技能：从编辑速度转向意图表达和代码审查AI 可能降低 Emacs Lisp 和 VimScript 的学习门槛终端原生 AI 工具与 Emacs/Vim 的工作流天然契合2. 关键信息A. 作者背景Emacs 狂热使用者超过 20 年维护了多个热门 Emacs 包，包括 copilot.el近期重新学习 Vim 和 NeovimB. 涉及技术Emacs、Vim、NeovimClaude Code、Copilot、Cursor、Windsurf 等 AI 工具gptel、ellama、aider.el、avante.nvim 等集成插件C. 文章定位这是一篇技术观点文章，而非纯粹的新闻报道，基于作者多年开源社区经验对未来趋势的思考。3. 背景介绍A. 前置背景VS Code 已经在编辑器市场占据绝对主导地位，并且正在获得所有主要 AI 工具的一流集成支持。微软有充分的资源和动力让 VS Code 成为 AI 辅助开发的最佳宿主。B. 相关上下文编程领域正在经历根本性转变，AI 越来越多地承担代码生成工作，人类的角色从编写代码转向审查、引导和精炼代码。三、详细报道1. 风险分析A. IDE 的引力井VS Code 的市场份额已经远超其他编辑器，正在获得 Copilot、Codex、Claude、Gemini 等 AI 工具的深度集成。Cursor、Windsurf 等专用 AI 编辑器也吸引了大量投资和人才。这些工具围绕 AI 工作流构建完整的体验，提供集成的上下文管理、内联差异、多文件编辑和代理循环。每个转向这些工具的开发者都是一个不再学习 Emacs 或 Vim 快捷键、不再编写 Elisp、不再为生态系统做出贡献的人。这种引力井效应是真实的。B. "强力工具"的必要性存疑Emacs 和 Vim 一直以来的卖点在于让用户更快地编写和编辑代码。快捷键、宏、可扩展性——所有这些都在于让人类更高效地完成编码的机械动作。但如果 AI 正在编写你的大部分代码，机械编辑速度还重要吗？当你正在审查和引导 AI 生成的差异而不是逐个字符地输入代码时，瓶颈从"我能编辑多快"转移到"我能多清楚地表达意图并评估输出"。这是一种完全不同的技能，而且不清楚 Emacs 或 Vim 在这方面有内在优势。学习曲线的论证也变得更难成立。当使用 Cursor 的初级开发者可以在一个下午搭建整个应用程序时，要求某人花费六个月学习 Emacs 以获得 10 倍速度是一个艰难的推销。C. 企业支持的不对称VS Code 有微软。Cursor 有风险投资。Emacs 有一小群志愿者和自由软件基金会。Vim 有 Bram 和现在的维护者社区。Neovim 有一个小型但专注的核心团队。这种情况一直存在，但 AI 放大了差距。构建深度 AI 集成需要跟上快速发展的 API、模型和范式。资金充足的团队可以专门投入工程师全职从事这项工作。志愿者驱动的项目以人们业余时间和热情的节奏前进。D. 末日场景让我们走向极端：如果我们熟悉的编程在下一个十年内完全自动化会怎样？如果 AI 代理可以接收规范并生成工作、经过测试、已部署的软件而无需人工干预，我们就根本不需要编码编辑器了。没有 Emacs，没有 Vim，没有 VS Code，没有 Cursor。整个类别变得无关紧要。作者认为这在短期内不太可能，但值得承认这是一种可能性。AI 能力的轨迹甚至让乐观主义者感到惊讶。2. 机遇分析A. AI 使配置和扩展变得微不足道几乎没有人谈论这一点：Emacs 和 Vim 一直受困于其扩展语言的晦涩。Emacs Lisp 是大多数程序员从未见过的 20 世纪 80 年代的 Lisp 方言。VimScript 就是 VimScript。即使是 Neovim 专门采用因为它更易接近的 Lua，也足够小众以至于大多数开发者没有写过一行。这几十年来一直是两个生态系统的最大瓶颈。不是编辑器本身——它们极其强大——而是自定义它们需要学习一种不熟悉的语言，而且大多数人从未超越从博客文章和 README 文件复…

2026年重返Rails
type: item
date: 2026-03-13T00:32:53+00:00
description: 2026年重返Rails一、新闻概述1. 标题2026年重返Rails：一次充满乐趣的开发体验回顾2. 发布时间2026年3月5日3. 来源Mark Dastmalchi-Round 的个人博客 markround.com二、核心内容1. 事件摘要A. 主要内容作者 Mark Dastmalchi-Round 在为他的乐队开发歌曲列表管理应用时，选择了 Rails 8 作为技术栈，并分享了重新使用 Rails 的开发体验和对 Rails 8 新特性的深入分析。B. 核心亮点Rails 8 采用了"No-Build"前端开发方式，无需 Webpack 等复杂构建工具Solid 系列组件：Solid Cache、Solid Queue、Solid Cable，无需额外基础设施SQLite 生产环境支持成为默认配置新的 Kamal 部署工具提供零停机部署体验2. 关键信息A. 版本号Rails 8B. 涉及技术Ruby on Rails 8Stimulus + Turbo (Hotwire)SQLiteKamal 部署工具Solid 系列组件C. 背景介绍2025年 Stack Overflow 开发者调查显示，Rails 在框架流行度中排名第20，落后于主流 JavaScript 和 ASP.NET 框架。Ruby 语言也仅排在前十名之外，低于 Lua 甚至汇编语言。三、详细报道1. 主要内容A. 前端开发：No-Build 方式Rails 8 采用了"无构建"的前端开发方法，开发者无需配置 Webpack、Yarn、npm 或其他 JavaScript 工具链。默认的 Hotwire 技术栈由 Stimulus 和 Turbo 组成。Turbo 负责拦截链接点击和表单提交，交换页面片段以提供类似单页应用（SPA）的流畅体验，而无需实际构建 SPA。开发者可以在需要时添加少量 Stimulus JS 控制器来实现特定行为。Stimulus 组件库通过简单的 importmap 命令管理：$ bin/importmap pin @stimulus-components/dialog这会从 JS CDN 下载包并将其添加到 vendor 目录，自动更新配置。使用时只需在控制器中注册即可在视图模板中立即使用。B. 工作流：Rails 开发体验Rails 的"约定优于配置"理念让开发变得高效。通过生成器可以快速创建模型、控制器和路由。例如，创建一个标签系统：$ bin/rails generate model Tag label:string color:string band:belongs_to这会自动生成模型文件：class Tag < ApplicationRecord belongs_to :band endActiveRecord 会自动从数据库获取列名和定义，无需额外工作。路由配置也极其简单，一行代码即可生成完整的 RESTful 路由：resources :tags开发者可以使用 curl 等工具快速测试 API：$ curl --silent -XGET \ -H "Authorization: Bearer <token>" http://localhost:3000/bands/4/tags/5.json | jq .C. 后端改进：Solid 系列组件Rails 8 引入了 Solid 系列组件，解决了需要额外基础设施的问题。Solid Cache使用数据库而不是内存存储进行缓存。现代存储性能足够用于缓存目的，这意味着可以缓存更多内容，同时也不需要 Redis 等额外层级。片段缓存示例：<% cache "time_based", expires_in: 5.minutes do %> <% end %>或基于模型的缓存：<% cache ["band_dashboard", @band.cache_key_with_version, expires_in: 1.hour] do %> <% end %>Solid Queue无需 Redis 即可管理后台任务，默认使用数据库。开发环境只需简单设置：SOLID_QUEUE_IN_PUMA=1 bundle exec rails server任务声明同样简单：# app/jobs/my_sample_job.rb class MySampleJob < ApplicationJob queue_as :default def perform Rails.logger.info "Yup, I still love Ruby..." end endSolid Cable用于实时 WebSocket 功能，同样默认使用数据库。作者主要用它来启用开发环境的 debugbar…

CLI-Anything：让所有软件成为 AI Agent 原生工具
type: item
date: 2026-03-12T08:18:09+00:00
description: CLI-Anything：让所有软件成为 AI Agent 原生工具一、概述1. 简介A. 是什么CLI-Anything 是一个 Claude Code 插件，能够将任何软件自动转换为 AI Agent 可控制的命令行工具。通过一条命令，它可以为 GIMP、Blender、LibreOffice 等应用生成功能完整的 CLI 接口，让 AI Agent 获得直接控制专业软件的能力。B. 为什么学解决 AI Agent 使用软件难题：当前 AI Agent 虽然推理能力强，但难以使用真实的专业软件统一接口范式：CLI 是 AI Agent 的理想接口，结构化、可组合、自描述自动化生成：无需手动编写代码，自动分析软件架构并生成 CLI生产级质量：1,508 个测试用例验证，覆盖 11 个主流应用C. 学完能做什么为任何软件自动生成 CLI，让 AI Agent 可以控制理解 7 阶段自动化流水线的工作原理部署和使用生成的 CLI 工具通过 refine 命令迭代改进 CLI 覆盖率2. 前置知识A. 必备技能Python 3.10+ 基础基本的命令行操作经验理解 AI Agent 的基本概念B. 推荐知识Click 框架（Python CLI 工具）pytest 测试框架Claude Code 使用经验二、环境准备1. 系统要求Python 3.10 或更高版本目标软件已安装（如 GIMP、Blender 等）Claude Code 或其他支持的 AI 编码代理2. 安装步骤Claude Code 平台安装：# 添加 CLI-Anything 市场 /plugin marketplace add HKUDS/CLI-Anything # 安装插件 /plugin install cli-anything手动安装（可选）：# 克隆仓库 git clone https://github.com/HKUDS/CLI-Anything.git # 复制插件到 Claude Code 插件目录 cp -r CLI-Anything/cli-anything-plugin ~/.claude/plugins/cli-anything # 重新加载插件 /reload-plugins3. 验证安装安装完成后，在 Claude Code 会话中输入：/cli-anything:cli-anything --help三、核心概念1. 基本术语Agent-Native（Agent 原生）：专为 AI Agent 设计的接口，支持结构化输入输出Harness（工具套件）：为特定软件生成的完整 CLI 包REPL（交互式解释器）：命令行交互模式，支持状态持久化7-Phase Pipeline：从分析到发布的自动化流程2. 工作原理CLI-Anything 通过自动化流程分析软件源码，理解其功能架构，然后生成标准的命令行接口。生成的 CLI 直接调用真实软件的后端，确保功能完整性。graph TB A[软件源码/仓库] --> B[分析阶段] B --> C[设计阶段] C --> D[实现阶段] D --> E[测试规划] E --> F[测试编写] F --> G[文档更新] G --> H[发布安装] subgraph 生成产物 I[Click CLI] J[REPL 界面] K[JSON 输出] L[测试套件] end D --> I D --> J D --> K F --> L3. 架构设计graph LR A[AI Agent] -->|命令| B[CLI-Anything 生成的 CLI] B -->|调用| C[真实软件后端] C -->|渲染/处理| D[输出文件] B -->|JSON 输出| A B -->|人类可读| E[终端输出] subgraph CLI-Anything 核心 F[分析引擎] G[代码生成器] H[测试框架] end F --> G G --> H四、快速上手1. Hello World 示例生成第一个 CLI 工具：# 为本地 GIMP 源码生成完整 CLI（所有 7 个阶段） /cli-anything:cli-anything ./gimp2. 核心功能演示# 从 GitHub 仓库生成 /cli-anything:cli-anything https://github.com/blender/blender3. 代码讲解上述命令会自动执行以下流程：第 1 阶段：分析扫描源代码，映射 GUI 操作到 API第 2 阶段：设计架构命令组、状态模型、输出格式第 3 阶段：实现构建 Click CLI，包含 REPL、JSON 输出、撤销/重做功能第 4 阶段：测试规划创建 TEST.md，包含单元测试和端…

AI 如何影响技能养成：Anthropic 实验研究揭示关键发现
type: item
date: 2026-02-27T15:04:02+00:00
description: AI 如何影响技能养成：Anthropic 实验研究揭示关键发现一、新闻概述1. 标题AI 如何影响技能养成：Anthropic 实验研究揭示关键发现2. 发布时间2026 年 2 月 27 日3. 来源Anthropic 研究团队二、核心内容1. 事件摘要A. 主要内容Anthropic 研究人员通过一项随机对照实验，证实了在使用 AI 学习新技能时，不同的使用方式会导致显著不同的学习效果。整体而言，过度依赖 AI 的学习者技能掌握程度下降 17%，但正确的 AI 使用方式反而能提升学习效果。B. 核心亮点首个针对 AI 辅助学习效果的随机对照实验发现 6 种不同的 AI 使用模式，其中 3 种有益、3 种有害认知参与度是决定学习效果的关键因素调试技能是最容易因 AI 替代而退化的能力2. 关键信息A. 研究规模52 名专业开发人员参与随机对照实验B. 重要数据AI 整体组技能得分低 17%p 值为 0.010，具有统计学显著性高认知参与组得分 86%低认知参与组得分仅 24%得分差距最大的是调试类问题C. 涉及产品/技术Anthropic Claude AI 助手3. 背景介绍A. 前置研究背景随着 AI 编程助手在开发者社区中的普及，关于 AI 是否会影响学习能力的讨论日益激烈。此前缺乏系统的实证研究来回答这一问题。B. 相关上下文AI 工具被广泛认为能提高开发效率，但其对长期技能养成的影响一直是业界关注的话题。本研究填补了这一空白，提供了科学依据。三、详细报道1. 主要内容A. 实验设计研究采用随机对照实验方法，招募 52 名专业开发人员参与。任务要求参与者使用从未接触过的 Python 库进行真实编程工作。参与者被随机分为两组：AI 组配备 AI 助手，对照组无 AI 辅助。B. 实验结果整体上，AI 组在技能评估中的得分比对照组低 17%。差异的统计显著性通过 p 值 0.010 得到确认。令人意外的是，AI 组并未在速度上获得优势，他们学到的内容更少，同时也没有节省时间。C. 六种 AI 使用模式通过分析参与者的屏幕录像，研究人员识别出 6 种使用 AI 学习新技能的不同模式。这些模式对学习效果的影响呈现两极分化：3 种模式有助于保持学习效果，另外 3 种则会破坏学习效果。2. 技术细节A. AI 使用模式对比分析graph TD subgraph 有益模式 A1[模式1: 概念性提问 得分: 86%] A2[模式2: 代码后追问 得分: 高] A3[模式3: AI 作为思考伙伴 得分: 高] end subgraph 有害模式 B1[模式4: 粘贴提示词 得分: 24%] B2[模式5: 复制输出结果 得分: 低] B3[模式6: 逃避思考 得分: 低] end A1 -->|认知参与度高| 学习效果好 A2 -->|认知参与度高| 学习效果好 A3 -->|认知参与度高| 学习效果好 B1 -->|认知参与度低| 学习效果差 B2 -->|认知参与度低| 学习效果差 B3 -->|认知参与度低| 学习效果差B. 高认知参与组特征得分最高的 AI 用户提出了"为什么这样行得通"类型的问题，而非要求 AI "替我写这段代码"。他们在生成代码后会主动追问以便理解，将 AI 视为思考伙伴而非思考的替代品。这组参与者的表现甚至超过了无 AI 对照组。C. 低认知参与组特征得分最低的一组参与者采用粘贴提示词、复制输出结果、然后继续下一步的工作方式。他们完成任务的速度最快，但几乎什么也没学到。D. 调试技能退化风险研究发现，得分差距最大的是调试类问题。这项技能正是监管 AI 输出所需要的关键能力，同时也是让 AI 代劳时退化得最快的技能。3. 数据与事实A. 学习效果对比使用模式认知参与度技能评估得分相对对照组概念性提问高86%+代码后追问高高+思考伙伴模式高高+粘贴提示词低24%--复制输出低低-逃避思考低低-无 AI 对照组中基准基准B. 学习机制分析对照组在任务执行过程中犯了更多错误，遇到了各种 bug。但这番挣扎恰恰构建了他们的理解。研究表明，错误并非学习的障碍，错误本身就是学习。用 AI 消除错误，也就消除了建立能力的机制。C. 参与者反思AI 组参与者在事后反思中坦言，希望自己当时能"更用心一点"，并觉得自己的做法很"懒惰"。其中一人写道："我的理解还有很多漏洞。"他们能感受到那种完成了任务却不知其所以然的空虚感。这种体验并非生产力的胜利，而是技术债。四、影响分析1. 行业影响A. 技术趋势这项研究为 AI 辅助学习提供了科学依据，将影响未来的技术培训和教育方式。企业和教育机构需要重新思考如何有效使用 AI 工具。B. 竞争格局AI 工具提供商可能需要在产品设计中考虑引导用户采用更有效的使用模式，避免过度自动化…