从零重建 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->p == '(') { p->p++; float v = expr(p); skipws(p); if (*p->p != ')') return NAN; p->p++; return v; } // 数字字面量 if (isdigit(*p->p) || *p->p == '.') return number(p); // 单元格引用 return cellval(p); }B. 项解析处理乘法和除法运算：float term(struct parser* p) { float l = primary(p); for (;;) { skipws(p); char op = *p->p; if (op != '*' && op != '/') break; p->p++; float r = primary(p); if (op == '*') l *= r; else if (r == 0) return NAN; else l /= r; } return l; }C. 表达式解析处理加法和减法运算：float expr(struct parser* p) { float l = term(p); for (;;) { skipws(p); char op = *p->p; if (op != '+' && op != '-') break; p->p++; float r = term(p); l = (op == '+') ? l + r : l - r; } return l; }4. 单元格引用解析将单元格地址（如 A1、AB123）转换为网格坐标：int ref(const char* s, int* col, int* row) { const char* p = s; // 解析列字母 if (!isalpha(*p)) return 0; *col = toupper(*p++) - 'A'; if (isalpha(*p)) *col = *col * 26 + (toupper(*p++) - 'A'); // 解析行数字 char* end; int n = strtol(p, &end, 10); if (n <= 0 || end == p) return 0; *row = n - 1; return (int)(end - s); }5. 函数支持支持基本的内置函数：@SUM：求和函数，支持范围参数（如 @SUM(A1...C3)）@ABS：绝对值函数@INT：取整函数@SQRT：平方根函数四、响应式计算1. 计算依赖问题电子表格的核心特性是响应式计算：当某个单元格的值发生变化时，所有引用该单元格的公式都应该自动重新计算。2. VisiCalc 的解决方案原始 VisiCalc 受限于 16KB 内存，采用了简单而有效的策略：每次单元格更新时重新计算整个表格用户可以选择按行优先或按列优先的计算顺序对于复杂依赖，建议用户多次运行手动重新计算命令3. 自动迭代计算现代实现可以自动化这个过程，运行多次迭代直到没有新的变化：graph TD A[单元格更新] --> B[开始重新计算] B --> C[遍历所有单元格] C --> D{单元格是否为公式?} D -->|是| E[重新计算公式值] D -->|否| C E --> F{值是否改变?} F -->|是| G[标记已变化] F -->|否| C G --> C C --> H{是否遍历完成?} H -->|否| C H -->|是| I{是否有变化?} I -->|是| B I -->|否| J[完成]实现代码void recalc(struct grid* g) { for (int pass = 0; pass < 100; pass++) { int changed = 0; for (int r = 0; r < NROW; r++) for (int c = 0; c < NCOL; c++) { struct cell* cl = &g->cells[c][r]; if (cl->type != FORMULA) continue; struct parser p = {cl->text, cl->text, g}; float v = expr(&p); if (v != cl->val) changed = 1; cl->val = v; } if (!changed) break; } }五、单元格设置1. 输入分类根据用户输入的第一个字符，自动判断单元格类型：以 +、-、( 或 @ 开头：公式以数字或小数点开头：数值其他：标签void setcell(struct grid* g, int c, int r, const char* input) { struct cell* cl = cell(g, c, r); if (!cl) return; // 空输入清空单元格 if (!*input) { *cl = (struct cell){0}; recalc(g); return; } // 保存原始输入 strncpy(cl->text, input, MAXIN - 1); // 分类输入类型 if (input[0] == '+' || input[0] == '-' || input[0] == '(' || input[0] == '@') { cl->type = FORMULA; } else if (isdigit(input[0]) || input[0] == '.') { char* end; double v = strtod(input, &end); cl->type = (*end == '\0') ? NUM : LABEL; if (cl->type == NUM) cl->val = v; } else { cl->type = LABEL; } // 触发重新计算 recalc(g); }2. 测试用例struct grid g = {0}; // 设置 A1=5, A2=7, A3=11, A4=@SUM(A1...A3) setcell(&g, 0, 0, "5"); setcell(&g, 0, 1, "7"); setcell(&g, 0, 2, "11"); setcell(&g, 0, 3, "+@SUM(A1...A3)"); assert(g.cells[0][3].val == 23.0f); // 修改值，总和应重新计算 setcell(&g, 0, 0, "5"); setcell(&g, 0, 1, "+A1+5"); setcell(&g, 0, 2, "+A2+A1"); assert(g.cells[0][3].val == 5.0f + 10.0f + 15.0f); // 修改 A1，所有公式应重新计算 setcell(&g, 0, 0, "7"); assert(g.cells[0][3].val == 7.0f + 12.0f + 19.0f);六、用户界面1. 界面布局VisiCalc 的屏幕分为四个区域，垂直排列：graph TB subgraph VisiCalc 界面 S[状态栏: 单元格地址 + 值/公式 + 模式] E[编辑行: 当前输入或单元格内容] H[列标题: A, B, C, ...] G[网格区域: 单元格内容 + 行号] end2. 视口设计由于网格可能比终端屏幕大，需要实现滚动视口：#define CW 9 // 列显示宽度 #define GW 4 // 行号栏宽度 // 可见的行列数 int vcols(void) { return (COLS - GW) / CW; } int vrows(void) { return LINES - 4; } struct grid { struct cell cells[NCOL][NROW]; int cc, cr; // 光标列、行 int vc, vr; // 视口左上角 };3. 视口滚动逻辑当光标移动到屏幕外时，视口自动跟随：// 水平滚动 if (g.cc < g.vc) g.vc = g.cc; if (g.cc >= g.vc + vcols()) g.vc = g.cc - vcols() + 1; // 垂直滚动 if (g.cr < g.vr) g.vr = g.cr; if (g.cr >= g.vr + vrows()) g.vr = g.cr - vrows() + 1;4. 渲染实现A. 状态栏显示当前单元格地址、值或公式，以及当前模式：// 状态栏：单元格地址 + 值 + 模式指示器 attron(A_BOLD | A_REVERSE); mvprintw(0, 0, " %c%d", 'A' + g->cc, g->cr + 1); if (cur->type == FORMULA) printw(" %s = %.10g", cur->text, cur->val); mvprintw(0, COLS - 6, mode == ENTRY ? "ENTRY" : "READY"); attroff(A_BOLD | A_REVERSE);B. 编辑行显示当前输入或单元格内容：if (mode) mvprintw(1, 0, "> %s_", buf); else if (cur->type != EMPTY) mvprintw(1, 0, " %s", cur->text);C. 列标题和网格绘制列标题（A、B、C...）和网格内容：// 列标题 attron(A_BOLD | A_REVERSE); for (int c = 0; c < vcols(); c++) mvprintw(2, GW + c * CW, "%*c", CW, 'A' + g->vc + c); attroff(A_BOLD | A_REVERSE); // 网格单元格 for (int r = 0; r < vrows() && g->vr + r < NROW; r++) { int row = g->vr + r, y = 3 + r; // 行号栏 attron(A_REVERSE); mvprintw(y, 0, "%*d ", GW - 1, row + 1); attroff(A_REVERSE); // 单元格内容 for (int c = 0; c < vcols() && g->vc + c < NCOL; c++) { int col = g->vc + c; struct cell* cl = cell(g, col, row); // 格式化显示 int is_cur = (col == g->cc && row == g->cr); if (is_cur) attron(A_REVERSE); mvprintw(y, GW + c * CW, "%s", formatted_buf); if (is_cur) attroff(A_REVERSE); } }七、输入处理1. 模态界面设计VisiCalc 采用模态界面设计，用户处于两种模式之一：READY 模式：在网格中导航ENTRY 模式：编辑单元格内容2. 特殊字符处理在 READY 模式下，以下字符有特殊含义：/：进入命令模式（/B 清空、/Q 退出、/F 格式化）：进入跳转模式（输入单元格地址如 B5 并按 Enter）其他可打印字符：进入单元格编辑模式3. 命令模式实现if (ch == '/') { mvprintw(1, 0, "Command: /"); refresh(); ch = getch(); if (toupper(ch) == 'Q') break; // 退出 if (toupper(ch) == 'B') { // 清空单元格 *cell(&g, g.cc, g.cr) = (struct cell){0}; recalc(&g); } if (toupper(ch) == 'F') { // 格式化 // 格式化命令处理 } }4. 确认和导航在 ENTRY 模式下：Enter：确认输入并向下移动Tab：确认输入并向右移动if (ch == 10 && mode == ENTRY) { setcell(&g, g.cc, g.cr, buf); if (g.cr < NROW - 1) g.cr++; mode = READY; }八、实现总结1. 核心功能通过约 500 行 C 代码，我们实现了：完整的单元格数据模型递归下降公式解析器自动迭代重新计算机制模态 TUI 用户界面视口滚动和渲染2. 未实现功能完整版本还可以添加：文件 I/O/R 复制命令（批量复制公式）更多内置函数移动和删除行列更复杂的格式化选项3. 设计启示VisiCalc 的设计历经 47 年仍然有效，证明了其核心设计的优雅和简洁。关键设计原则包括：极简的数据模型响应式计算直观的用户界面高效的实现方式参考资料VisiCalc reconstructed - zserge.comkalk - VisiClone implementation on GitHubWorld smallest office suite
比亚迪电动汽车需求激增：油价上涨推动司机转向新能源
比亚迪电动汽车需求激增：油价上涨推动司机转向新能源一、新闻概述1. 标题比亚迪电动汽车需求激增：油价上涨推动司机转向新能源2. 发布时间2026 年 3 月 20 日3. 来源Electrek二、核心内容1. 事件摘要A. 主要内容随着中东局势紧张导致石油和天然气价格飙升，中国新能源汽车巨头比亚迪正迎来一波电动汽车购买热潮。B. 核心亮点比亚迪自 2022 年停止生产纯内燃机汽车后，已成为全球最大的电动汽车制造商2025 年比亚迪全球销量首次超越福特，排名第六，销量超过 460 万辆亚洲部分地区电动汽车需求激增，菲律宾马尼拉某经销商两周内订满一个月的配额全球电动汽车采用帮助每天减少 170 万桶石油消耗2. 关键信息A. 涉及企业比亚迪（BYD）：全球最大电动汽车制造商VinFast：越南电动汽车品牌，同样见证需求激增B. 重要数据比亚迪 2025 年销量：超过 460 万辆电动和插电式混合动力汽车全球石油消耗减少：每天 170 万桶（约占伊朗通过霍尔木兹海峡出口量的 70%）亚洲电动汽车采用率：约 40%亚洲进口石油中约 40% 需通过霍尔木兹海峡美国汽油平均价格：每加仑 3.91 美元（较年初上涨 93 美分）Edmunds 数据显示：3 月第一周电动化车型关注度增长超过 20%C. 背景介绍中东地区局势紧张导致石油和天然气价格持续上涨，促使消费者寻求传统燃油汽车的替代方案。比亚迪早在 2022 年就做出战略性决策，停止生产纯内燃机汽车，全力投入电动汽车领域，这一决策如今正带来丰厚的回报。三、详细报道1. 主要内容A. 市场表现比亚迪的市场策略已见成效。作为全球最大的电动汽车制造商，比亚迪在 2025 年取得了里程碑式的成就，全球销量排名第六，历史上首次超越福特汽车公司。尽管近期面临新竞争和政策变化导致销售增长放缓，但油价上涨带来的需求激增正在为比亚迪注入新的增长动力。B. 区域市场动态在菲律宾首都马尼拉，一家比亚迪经销商的需求旺盛到短短两周内就订满了原本一个月的配额。销售人员表示，客户因为油价上涨而纷纷选择更换为电动汽车。同样，越南电动汽车品牌 VinFast 也经历了类似的繁荣。距离马尼拉约 1100 英里的一家 VinFast 经销店，由于展厅客流量增长了 4 倍，不得不额外雇佣销售人员。C. 行业影响分析根据英国能源智库 Ember 的分析，全球电动汽车的普及帮助在 2025 年每天减少 170 万桶石油消耗，这相当于伊朗通过霍尔木兹海峡出口量（约 240 万桶/日）的 70%。虽然亚洲，特别是泰国和菲律宾等东南亚国家的电动汽车采用率（约 40%）高于美国和欧洲，但油价上涨对这些国家的冲击仍然严重。亚洲进口石油中约 40% 需要通过霍尔木兹海峡运输。2. 政策响应A. 各国激励措施为应对油价上涨并推动电动汽车普及，部分亚洲国家已开始调整政策：老挝：削减电动汽车注册和服务费，同时提高燃油车的相关费用泰国：此前因政府降低补贴导致电动汽车价格吸引力下降，对 2026 年需求持谨慎态度。泰国工业联合会汽车行业发言人表示，如果油价维持当前水平或继续上涨，预计电动汽车需求将显著增加B. 比亚迪市场策略中国作为全球最大的电动汽车生产国，预计将见证最大的需求增长。比亚迪为进一步巩固市场地位，推出了极具吸引力的促销活动：部分车型提供 18 个月免费充电服务。这一策略旨在给传统燃油汽车和石油行业带来最后的冲击。3. 美国市场动态A. 价格趋势截至 2026 年 3 月 20 日，美国汽油平均价格达到每加仑 3.91 美元，较年初上涨了 93 美分，并呈现持续上涨趋势，全国平均价格正逼近 4 美元/加仑的关口。B. 消费者行为变化权威汽车购物平台 Edmunds 的数据显示，仅 3 月第一周，消费者对电动化车型的关注度就较前一周增长了 20% 以上。其中，大部分兴趣集中在纯电动汽车领域。随着汽油价格持续攀升，目前的关注度很可能已经更高。四、影响分析1. 行业影响A. 竞争格局比亚迪的成功验证了其早期战略转型（全面停产内燃机汽车）的正确性。这不仅巩固了其在电动汽车领域的领导地位，也为其他传统汽车制造商提供了转型参考。B. 电动汽车普及加速油价上涨成为推动电动汽车普及的催化剂。当电动汽车的经济优势更加明显时，消费者的购买决策会更加倾向于新能源车型。2. 用户影响A. 现有电动汽车车主已享受较低的能源使用成本车辆保值率可能因需求增加而提升B. 潜在购车用户油价上涨使电动汽车的总拥有成本优势更加突出政府激励措施（如降低注册费）进一步降低了购买门槛免费充电等促销活动增强了吸引力C. 燃油车用户面临不断上涨的燃油成本二手车价值可能受到影响转换为电动汽车的动力增强3. 能源安全A. 石油依赖降低全球电动汽车普及每天减少 170 万桶石油消耗，这一数字凸显了电动汽车在降低石油依赖、提高能源安全方面的重要作用。B. 地缘政治影响降低对中东石油的依赖可以减少地缘政治风险对本国经济的冲击，电动汽车是实现能源独立的重要途径。五、各方反应1. 行业观点泰国工业联合会汽车行业发言人：如果油价维持当前水平或继续上涨，预计电动汽车需求将显著增加能源分析师指出，电动汽车已成为实现能源独立的首要途径2. 消费者反馈菲律宾消费者：正在用电动汽车替换燃油车，主要原因是油价上涨越南消费者：将燃油车（丰田 Vios）换成 VinFast 电动汽车，预计能大幅节省开支3. 市场前景中国作为全球最大的电动汽车生产国，将见证最大的需求增长美国和欧洲等主要市场也正在出现消费者向电动化转型的趋势Edmunds 数据显示消费者关注度显著上升，预示市场需求将持续增长六、相关链接1. 相关报道Electrek: 油价上涨提醒：电动汽车是能源独立的最佳途径Ember: 全球电动汽车采用对石油消耗的影响分析2. 参考资料Edmunds 汽车购物数据泰国工业联合会汽车行业报告参考资料BYD's bet on EVs is paying off as drivers ditch gas amid rising oil prices
SharpAI 发布 HomeSec-Bench 基准测试：本地 AI 性能逼近 GPT-5.4
SharpAI 发布 HomeSec-Bench 基准测试：本地 AI 性能逼近 GPT-5.4一、新闻概述1. 标题SharpAI 发布 HomeSec-Bench 基准测试：本地 AI 性能逼近 GPT-5.42. 发布时间2026 年 3 月 21 日3. 来源SharpAI Aegis 官方网站二、核心内容1. 事件摘要A. 主要内容SharpAI 发布 HomeSec-Bench v1 基准测试结果，展示本地 AI 模型在家庭安全场景下的性能表现。测试显示，Qwen3.5-9B 模型在 MacBook Pro M5 上本地运行时，取得了 93.8% 的通过率，仅比 OpenAI GPT-5.4 低 4.1 个百分点。B. 核心亮点Qwen3.5-9B 本地得分 93.8%，距离 GPT-5.4 仅 4.1 分零 API 成本，完全数据隐私Qwen3.5-35B-MoE 首 token 时间（TTFT）优于所有 OpenAI 云端模型96 个测试用例覆盖 15 个真实家庭安全场景2. 关键信息A. 测试版本HomeSec-Bench v1B. 重要数据测试数量：96 个 LLM 测试 + 35 个 VLM 测试测试套件：15 个场景套件本地模型最佳成绩：Qwen3.5-9B 达到 93.8% 通过率硬件配置：MacBook Pro M5（18 核，64 GB 统一内存）本地模型内存占用：Qwen3.5-9B 仅需 13.8 GBC. 涉及产品SharpAI Aegis（本地优先的 AI 家庭安全系统）Qwen3.5 系列（9B、27B、35B-MoE、122B-MoE）OpenAI GPT-5.4 系列3. 背景介绍A. 前置版本这是 HomeSec-Bench 的首个公开版本 v1。B. 相关上下文HomeSec-Bench 是专为评估家庭安全助手工作流设计的基准测试，而非通用聊天场景。它覆盖了上下文预处理、主题分类、事件去重、工具使用、安全分类、多轮推理等 16 个实际应用场景。三、详细报道1. 主要内容A. 测试范围HomeSec-Bench 包含 15 个测试套件，涵盖家庭安全 AI 的核心能力：上下文预处理（6 个测试）主题分类（4 个测试）知识蒸馏（5 个测试）事件去重（8 个测试）工具使用（16 个测试）聊天与 JSON 合规（11 个测试）安全分类（12 个测试）叙事综合（4 个测试）提示注入抵抗（4 个测试）多轮推理（4 个测试）错误恢复（4 个测试）隐私与合规（3 个测试）警报路由（5 个测试）知识注入（5 个测试）VLM 到警报分流（5 个测试）B. 测试方法所有测试 fixture 图像均为 AI 生成，不涉及真实用户 footage。测试可针对任何兼容 OpenAI API 的端点运行。C. 硬件要求推荐配置为 MacBook Pro M5/M5 Pro，18 核心处理器，64 GB 统一内存，运行 macOS 15.3 (arm64)，使用 llama.cpp 推理引擎。2. 技术细节A. 排行榜分析graph LR A[GPT-5.4 97.9%] --> B[GPT-5.4-mini 95.8%] B --> C[Qwen3.5-9B/27B 93.8%] C --> D[Qwen3.5-122B-MoE GPT-5.4-nano 92.7%] D --> E[Qwen3.5-35B-MoE 91.7%] E --> F[GPT-5-mini 62.5%] style A fill:#f9d5cc style B fill:#f9e5cc style C fill:#faedad style D fill:#fcf6d5 style E fill:#fcfad9 style F fill:#e8e8e8B. 性能指标对比首 Token 时间（TTFT）Qwen3.5-35B-MoE：435ms（最快，优于所有云端模型）GPT-5.4-nano：508msGPT-5.4-mini：553msGPT-5.4：601msQwen3.5-9B：765msQwen3.5-122B-MoE：1627msQwen3.5-27B：2156ms解码速度GPT-5.4-mini：234.5 tok/sGPT-5.4-nano：136.4 tok/sGPT-5.4：73.4 tok/sQwen3.5-35B-MoE：41.9 tok/sQwen3.5-9B：25 tok/sQwen3.5-122B-MoE：18 tok/sQwen3.5-27B：10 tok/s显存占用（本地模型）Qwen3.5-35B-MoE：27.2 GBQwen3.5-27B：24.9 GBQwen3.5-9B：13.8 GBQwen3.5-122B-MoE：40.8 GBC. 架构设计graph TB subgraph 输入 A[用户查询] B[摄像头画面] C[事件日志] end subgraph HomeSec-Bench 测试套件 D[上下文预处理] E[主题分类] F[事件去重] G[安全分类] H[工具使用] I[多轮推理] end subgraph 输出 J[警报路由] K[知识注入] L[隐私合规] end A --> D B --> F C --> I D --> E E --> G F --> G G --> H H --> J I --> K H --> L3. 数据与事实A. 本地 vs 云端通过率差距：Qwen3.5-9B 与 GPT-5.4 仅差 4.1%成本优势：本地模型零 API 调用费用隐私优势：数据完全本地处理，无需上传云端延迟优势：Qwen3.5-35B-MoE 的 TTFT 比最快的云端模型还快 73msB. 硬件适配性Qwen3.5-9B 可在 16 GB 内存设备上运行Qwen3.5-35B-MoE 需要 32 GB 以上内存推荐使用 64 GB 统一内存的 Apple Silicon 设备四、影响分析1. 行业影响A. 技术趋势HomeSec-Bench 的结果表明，本地 AI 模型在特定领域任务上已经具备与顶级云端模型竞争的能力。这一趋势可能推动更多边缘计算场景下的 AI 部署，特别是在隐私敏感领域如家庭安全、医疗健康等。B. 竞争格局本地模型阵营：Qwen、Llama 等开源模型持续优化云端模型阵营：OpenAI、Anthropic 等保持性能领先混合部署：可能催生本地优先、云端兜底的新型架构2. 用户影响A. 现有用户对于使用 Apple Silicon 设备的用户，现在可以在不牺牲太多性能的前提下，享受完全本地化的 AI 服务。B. 潜在用户家庭安全、智能家居等场景的 AI 应用可以降低对云端的依赖，减少延迟和隐私风险。C. 成本考量长期来看，本地部署可显著降低 AI 应用成本，无需支付持续的 API 调用费用。3. 技术趋势A. 边缘 AI随着硬件性能提升和模型优化，边缘设备上的 AI 能力将持续增强。B. 隐私优先数据隐私法规的收紧将推动更多本地化 AI 方案。C. 混合架构未来可能形成本地处理常规任务、云端处理复杂任务的混合模式。五、各方反应1. 官方回应SharpAI 强调，9B 参数模型在笔记本电脑上达到接近 GPT-5.4 的性能，且完全离线、隐私安全，这正是本地 AI 的价值主张。2. 业内评价HomeSec-Bench 提供了针对垂直领域（家庭安全）的基准测试，填补了通用基准测试（如 MMLU、GSM8K）在特定场景评估方面的空白。3. 技术社区开源 AI 社区对 Qwen3.5 系列的表现表示认可，认为其在中文场景和多模态任务上表现突出。六、相关链接1. 官方资源SharpAI Aegis 官网：https://www.sharpai.org/HomeSec-Bench GitHub：https://github.com/SharpAI/DeepCamera/tree/master/skills/analysis/home-security-benchmark2. 相关项目DeepCamera：去中心化 AI 技能生态系统llama.cpp：Apple Silicon 上的高效推理引擎3. 技术文档SharpAI 隐私政策：https://www.sharpai.org/privacySharpAI 使用条款：https://www.sharpai.org/terms参考资料HomeSec-Bench — Local AI vs Cloud Benchmark | SharpAI Aegis
10x 数据效率 NanoGPT Slowrun 技术突破一、新闻概述1. 标题NanoGPT Slowrun 实现 10x 数据效率突破2. 发布时间2026 年 3 月 19 日3. 来源Q Labs 官方博客二、核心内容1. 事件摘要A. 主要内容Q Labs 宣布其 NanoGPT Slowrun 项目在数据效率方面取得重大突破，实现了 10x 数据效率提升。一个由 1.8B 参数模型组成的集成系统（总计 18B 参数）在 100M tokens 上训练，达到了通常需要 1B tokens 才能实现的标准基线性能。B. 核心亮点10x 数据效率提升，在数周内实现使用 8 个模型的集成训练与 Chinchilla 缩放定律相比，参数规模提升 3600 倍下一步目标是实现 100x 数据效率2. 关键信息A. 技术指标数据效率：10x单模型参数：1.8B总参数量：18B（8 模型集成）训练数据量：100M tokensB. 技术手段集成学习（Ensemble）链式知识蒸馏（Chain Distillation）强正则化策略循环变换器（Looping）多项架构优化C. 涉及项目NanoGPT Slowrun（GitHub 开源项目）3. 背景介绍A. 问题背景当前 AI 模型的缩放定律要求计算和数据同比例增长。由于计算增长速度远快于数据，智能发展最终会被数据瓶颈而非计算瓶颈限制。B. 技术意义这项数据效率突破使得通过扩展计算而非数据来提升模型性能成为可能。三、详细报道1. 主要技术A. 集成学习集成学习可能是预训练缩放中被研究最少的方向。与其训练单个模型，不如训练多个相对独立的模型，在推理时聚合其预测。这样可以在固定数据下持续利用更多计算，并持续改进泛化能力。集成学习的训练动态与单模型截然不同。Pandey 等人的研究显示，集成等后验变换会逆转常规的过拟合动态：基座模型会随着更多训练而过拟合，但集成更倾向于训练更多轮次的基座模型。B. 链式蒸馏链式知识蒸馏显著提升了集成训练效果。其灵感来自 Born-Again Neural Networks，核心思想是顺序训练模型，每个新模型都从紧邻的前一个模型进行蒸馏：graph LR D[数据 D] --> M1[模型 M1] M1 -.蒸馏.-> M2[模型 M2] M2 -.蒸馏.-> M3[模型 M3] M3 -.蒸馏.-> MK[模型 MK] M1 -->|集成| E[最终预测] M2 -->|集成| E M3 -->|集成| E MK -->|集成| E算法流程：在数据 D 上用标准交叉熵损失训练模型 M1对于 k = 2, ..., K：加载 M_{k-1} 作为冻结教师模型从头训练 M_k，损失函数为：L = (1 - α) · CE(M_k(x), y) + α · T² · KL(M_k(x)/T ‖ M_{k-1}(x)/T)其中 α = 0.5, T = 1.0从内存中丢弃教师模型推理时通过对 logits 取平均来集成所有 K 个模型C. 正则化策略Q Labs 认为泛化与压缩密切相关，而正则化是简洁性的代理。最有用的正则化技术包括 L2 权重衰减和 dropout。他们使用的正则化强度远超标准实践：权重衰减：1.6（标准实践约 0.1，提升 16 倍）Dropout：0.1这种极端正则化之所以有效，是因为模型严重过参数化。Kim 等人发现在数据受限场景下，最优权重衰减可达标准实践的 30 倍以上。D. 循环变换器循环变换器比标准变换器具有更好的归纳偏置，因为它们允许模型对每个预测应用更多计算。训练策略：首先在前半程训练 30 层变换器（无循环）然后启用循环：层 15-24 循环 4 次保持最后几层不循环graph TD A[输入] --> B[层 0-14] B --> C[层 15-24 第1次] C --> D[层 25-29] C -.第2次.-> C2[层 15-24] C2 -.第3次.-> C3[层 15-24] C3 -.第4次.-> C4[层 15-24] C2 --> D C3 --> D C4 --> D D --> E[输出]2. 架构改进A. 关键改进排他自注意力（XSA）：移除自注意力输出的自值投影SwiGLU 激活函数：替换平方 ReLUU-Net 跳跃连接：在镜像变换器层之间添加值嵌入：通过输入嵌入的学习投影替换单独的嵌入表EMA 权重平均：与权重衰减调优结合B. 架构搜索元模式这些架构改进表明神经架构搜索对数据效率至关重要。系统性的架构搜索是重要方向。3. 数据与事实A. 效率提升路径Muon 优化器 + 强正则化 + 多轮训练：3.8x8 模型集成：提升至 5x值投影 + SwiGLU：继续提升U-Net + 注意力门控：继续提升更长集成训练：继续提升集成链式蒸馏：提升至 8x添加循环：继续提升增加循环 + 权重 EMA：最终达到 10xB. 与缩放定律对比根据 Chinchilla 缩放定律，100M tokens 应训练约 5M 参数模型。而 Q Labs 使用 1.8B 参数模型，相差 3600 倍。四、影响分析1. 技术趋势A. 数据效率成为新方向随着计算增长快于数据增长，数据效率突破成为 AI 发展的关键路径。B. 集成学习潜力巨大集成学习在预训练缩放中被严重低估，仍有巨大探索空间。2. 行业影响A. 降低数据依赖这项突破意味着可以用更少的数据训练出同等性能的模型。B. 计算资源利用优化通过扩展计算而非数据来提升性能，为 AI 发展提供了新路径。3. 技术方向A. 原理性技术可迁移团队认为其中一些原理性技术（如集成学习、强正则化、循环变换器）可以迁移到更大规模。B. 下一步目标团队表示 100x 数据效率可能在一年内实现，需要几项新的突破。五、各方反应1. 官方观点团队指出：一些趋势只是架构微调，背后没有太多原理。但有几项是原理性的，相信它们会迁移到更大规模——这些才是根本重要的。2. 技术观察A. 打破常规认知10x 数据效率在数周内实现，这在大多数人的想象之外。B. 与缩放定律偏离当前结果与现有缩放定律（如 Chinchilla）显著偏离，表明可能有新的缩放规律等待发现。六、相关链接1. 项目地址NanoGPT Slowrun GitHub 仓库Q Labs 官网2. 相关研究Pandey et al.：集成学习训练动态研究Kim et al.：数据受限场景下的正则化研究Born-Again Neural Networks：链式蒸馏灵感来源参考资料10x Data Efficiency - NanoGPT Slowrun
研究证实赌博营销攻势显著加剧赌博危害
研究证实赌博营销攻势显著加剧赌博危害一、新闻概述1. 标题研究证实轰炸式营销优惠极大地增加投注和赌博危害2. 发布时间2026 年 3 月 19 日3. 来源英国布里斯托尔大学官网二、核心内容1. 事件摘要A. 主要内容一项由澳大利亚中央昆士兰大学与英国布里斯托尔大学合作开展的研究，首次证实了赌博营销与赌博危害之间的因果关系。B. 核心亮点首次在真实环境中证实赌博营销与危害的因果联系退出营销的参与者下注量减少 23%，支出减少 39%赌博相关短期危害减少 67%2. 关键信息A. 研究内容关于直接营销（免费投注、邮件、推送通知、短信）对赌博行为影响的研究B. 重要数据下注减少：23%支出减少：39%短期危害减少：67%研究样本：227 人研究周期：2 周C. 涉及机构澳大利亚中央昆士兰大学英国布里斯托尔大学期刊 Addiction资助方：Gambling Research Australia3. 背景介绍A. 研究背景英国政府 2023 年赌博白皮书认为无需监管营销，因为缺乏因果联系证据。这项研究填补了这一空白。B. 相关上下文赌博行业通过电视、社交媒体、邮件、短信等多种渠道进行大规模营销推广。三、详细报道1. 主要内容A. 研究方法这是一项随机对照试验，监测并比较了 227 名主要在澳大利亚的参与者（以 45 岁男性为主，定期对体育和赛马下注）在两周内的赌博活动。参与者分为两组：接收直接营销组：继续接收赌博账户的邮件、推送通知和短信退出营销组：选择不接收任何直接营销B. 研究结果接收营销的参与者相比退出营销组：下注次数多 23%资金支出多 39%报告的短期赌博危害（如因赌博感到痛苦）高 67%C. 关键观点布里斯托尔大学心理学高级讲师 Philip Newall 博士指出，虽然研究针对直接营销，但电视或社交媒体上的赌博广告很可能产生类似或更严重的不良影响。2. 技术细节A. 研究设计graph TD A[227 名参与者] --> B{随机分组} B --> C[接收营销组] B --> D[退出营销组] C --> E[继续接收邮件/推送/短信] D --> F[屏蔽所有直接营销] E --> G[监测两周赌博行为] F --> G G --> H[数据分析与对比]B. 数据统计指标退出营销组 vs 接收营销组减少幅度下注次数减少23%资金支出减少39%短期危害报告减少67%3. 真实案例A. 案例背景Naman Jawaid，34 岁，来自曼彻斯特，18 岁时因看到电视广告提供免费投注而开始赌博。B. 成瘾过程起点：10 英镑投注峰值：20 多岁时日均投注 2000 英镑结果：为筹集赌资犯下金融犯罪，入狱服刑C. 康复经历在监狱中意识到需要改变，出狱后进入康复计划，现在拥有一份有回报的工作、稳固的婚姻和良好的朋友关系。他目前在 GamLEARN 慈善机构担任研究项目协调员，帮助刑事司法系统中的人们。D. 营销影响Naman 表示，赌博公司知道发送什么类型的个性化消息。如果几天没有下注，他们会用免费投注诱惑你，将你吸回去。知名足球运动员和喜剧演员代言大品牌，让你觉得这是无害的娱乐，但实际上会陷入一个可能控制你整个生活的恶性操纵循环。四、影响分析1. 政策影响A. 监管需求研究强调迫切需要更严格的限制和法规来约束赌博营销。B. 白皮书影响这项研究改变了英国政府 2023 年赌博白皮书的立场，可为许多受赌博成瘾困扰的人的经历提供验证。2. 行业影响A. 营收影响若禁止直接营销，赌博公司可能面临显著的用户活跃度和营收下降。B. 合规成本行业需要投入更多资源开发负责任的营销策略。3. 用户影响A. 现有用户退出营销选项可显著减少赌博行为自我排除计划可有效减少赌博危害B. 潜在用户减少营销暴露可降低新用户入门门槛社会整体赌博危害可能显著降低五、各方反应1. 官方回应Matthew Rockloff 教授（澳大利亚中央昆士兰大学实验赌博研究实验室主任）指出，这项研究提供了明确的证据，表明直接赌博营销会增加与赌博相关的危害。这加强了更严格监管的论证，甚至可能完全禁止，以更好地保护消费者。2. 机构立场布里斯托尔赌博危害研究中心是一个跨学科研究的全球中心，旨在提高对赌博危害的认识，通过政策变革加强消费者保护，并改善支持和治疗。六、相关链接1. 研究论文Direct gambling marketing, direct harm: a randomised experiment（期刊 Addiction）2. 相关机构布里斯托尔赌博危害研究中心澳大利亚中央昆士兰大学实验赌博研究实验室3. 相关资源GamLEARN 慈善机构参考资料Study shows bombarding gamblers with offers greatly increases betting and gambling harm
使用 AI Agent 将 MiniJinja 移植到 Go 语言一、新闻概述1. 标题使用 AI Agent 将 MiniJinja 移植到 Go 语言2. 发布时间2026 年 1 月 14 日3. 来源Armin Ronacher 个人博客（lucumr.pocoo.org）二、核心内容1. 事件摘要A. 主要内容Armin Ronacher 使用 AI Agent 成功将 MiniJinja（Rust 编写的 Jinja2 模板引擎）移植到 Go 语言。整个移植过程耗时约 10 小时，但人工参与时间仅 45 分钟，主要用于高层指导。B. 核心亮点AI Agent 独立完成绝大部分移植工作采用测试驱动开发方式，逐步实现词法分析、语法分析和运行时Agent 从字面移植转向行为移植，更符合 Go 语言习惯API 成本约 60 美元，使用 220 万 tokens2. 关键信息A. 涉及项目MiniJinja：Rust 版本的 Jinja2 模板引擎移植目标：原生 Go 语言实现B. 重要数据Agent 运行时长：10 小时（3 小时人工监督 + 7 小时独立运行）人工参与时间：约 45 分钟消息总数：2698 条用户提示：34 条工具调用：1386 次API 成本：60 美元Token 总量：220 万C. 使用的模型Claude Opus 4.5（主要开发阶段）GPT-5.2 Codex（测试修复阶段）3. 背景介绍A. MiniJinja 简介MiniJinja 是 Jinja2 模板引擎的 Rust 重新实现版本。Armin Ronacher 最初编写它是为了在 Rust 中进行基础设施自动化项目，虽然原项目没有继续，但 MiniJinja 本身对作者和其他用户都很有用。B. 测试机制MiniJinja 使用快照测试进行验证，通过 insta 工具比较输入和预期输出。这些快照测试成为验证 Go 移植版本的重要依据。三、详细报道1. 移植策略A. 测试驱动方法初始提示要求 Agent 确定如何验证移植。通过对话，作者与 Agent 达成一致路径：复用现有的 Rust 快照测试，逐步移植（词法分析器 → 语法分析器 → 运行时）。Agent 构建了 Go 端工具链：解析 Rust 测试输入文件（嵌入 JSON 配置头）解析参考 insta 快照文件并比较输出维护跳过列表以暂时排除失败的测试这形成了一个紧凑的反馈循环：Agent 有明确目标（让所有测试通过）和清晰的进度路径。graph LR A[Rust 快照测试] --> B[Go 测试工具] B --> C[词法分析器] C --> D[语法分析器] D --> E[运行时] E --> F[所有测试通过]B. Pi 的分支功能作者使用 Pi 的分支功能将会话结构化为不同阶段。通过回滚到较早部分并使用分支切换功能，自动告知 Agent 已完成的工作。分支切换时做两件事：保持在同一会话中，但从较早消息创建新分支切换时，将已完成的工作摘要作为引导消息添加到分支点这避免了 Agent 重新从头开始探索进度。C. 从字面移植到行为移植有趣的是，Agent 很快从字面移植转向行为移植。作者没有阻止这种转变，只要行为保持一致。原因有两个：代码库不大，必要时可以在最后调整这样更符合 Go 语言习惯例如，在运行时方面：实现了树遍历解释器（而非 Rust 的字节码解释器）决定使用 Go 的反射来实现值类型这些是 Agent 自主决定的，但比复制 Rust 解释器设计更合理（Rust 设计部分原因是缺乏垃圾回收器和运行时类型信息）。2. 需要人工干预的情况A. 错误消息处理Agent 完全放弃了所有必须失败的测试，因为运行时差异导致无法完美复制错误消息。作者引导它改用模糊匹配。B. 行为回归Agent 想要回退作者想保留的行为（如精确的 HTML 转义语义，或 range 必须返回迭代器）。如果没有引导，Agent 可能无法完成，或者作者会对结果失去信心。3. 完整覆盖的攻坚阶段修复主要语义不匹配后，剩余工作是填补所有缺失部分：缺失的过滤器、测试函数、循环扩展、宏、调用块等。作者切换到 Codex 5.2，排队提交几个继续让测试通过的提示，然后让它通过压缩独立工作。一旦基础覆盖完成，作者确信 Agent 可以在没有指导的情况下让剩余测试通过。这个阶段在无人监督的情况下通宵运行。4. 最终清理功能收敛后，作者要求 Agent：记录内部函数重新组织（如将过滤器移到单独文件）记录所有函数和过滤器（类似 Rust 代码库）此时设置了 CI、发布流程，并讨论创建的内容以进行最后的完善，然后合并。sequenceDiagram participant H as 人工 participant A as AI Agent participant R as Rust 代码 participant G as Go 代码 participant T as 测试 H->>A: 提供高层指导 A->>R: 分析现有代码 A->>G: 编写 Go 实现 A->>T: 运行快照测试 T-->>A: 测试结果 A->>G: 修复失败 H->>A: 纠正行为偏差 G-->>H: 最终代码四、影响分析1. 行业影响A. 技术选择不再受限这类移植现在已经可行。虽然几个月前移植已经可能，但需要更多关注。这种情况改变了某些动态。作者感觉技术选择不再受生态系统锁定约束。B. 代码价值转移价值正从代码本身转向测试和文档。一个好的测试套件可能比代码本身更有价值。不过，这不是保守测试秘密的理由——生成良好覆盖的测试也变得越来越容易。2. 移植可能性评估简单库：完全可行中等复杂度：如 MiniJinja，可行高度优化库：如 NumPy 移植到 Go 会更复杂，使其具有竞争力甚至更困难（多年优化积累）但总的来说，感觉现在可以使用更多库了。3. 社会动态变化过去有人将你的代码移植到其他语言是值得骄傲的事情。这是成就的标志——项目足够酷，有人花时间让它在其他地方可用。有了 Agent，它不再引起同样的感觉。Will McGugan 也指出了这种变化。五、各方反应1. 相关资源PR #854：MiniJinja Go 移植的 Pull RequestPi 会话记录：完整的 Agent 交互记录视频演示：移植过程的旁白视频2. 技术社区反馈Will McGugan 在 Bluesky 上指出，Agent 改变了代码移植带来的社会意义——从致敬行为变成了技术可行性的展示。六、关键经验总结1. 成功因素完善的测试套件是移植成功的基础测试驱动方法提供了清晰的进度指标适度的人工引导确保了方向正确从字面移植到行为移植的灵活性提高了代码质量2. 成本效益60 美元 API 成本45 分钟人工时间相比手动移植数小时到数天的工作量，效率提升显著3. 未来展望跨语言库的同步需要共享测试，否则不可避免地会出现分歧AI Agent 使得技术选型不再受限于语言生态代码的价值正在向测试和文档转移参考资料Porting MiniJinja to Go With an Agent
生活在平面国的程序员一、概述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. 突破认知偏见需要的只是：好奇心理解最好的编程思想有时无法立即被欣赏识别自己的认知偏见认识到这种偏见足以打破它，这是作为程序员成长的最好方式之一。五、社区讨论与反馈1. Valerie Kim：Laws of Form 的类比A. 稀有抽象的概念文章中关于"稀有抽象"的论述让她想起 George Spencer-Brown 的《Laws of Form》（1969）。B. 形式系统的维度扩展即使是最简单的形式系统（一个符号、两个规则、约一个值），在引入"重新进入"（re-entry）的自指扩展后，也能获得全新的维度：类似于引入虚数 i 作为 x = -1/x 的解宏本质上是自指的它们提供了引入新区分（概念）的强大方式2. ao：实用主义的质疑A. 维护成本论点实际程序在其生命周期中经常被修改修改的成本和速度很重要宏像"魔法"：难以快速理解B. Blub 语言的优势可能更冗长，但显式更容易找到替代开发者更快地进行更改C. 维度的代价第三维度需要很多时间，用户并不总是愿意为此付费。这就像大多数人通勤使用道路车辆而不是飞机。D. Viaweb 的后续据互联网消息，Yahoo 在长期维护中将 Viaweb 从 Lisp 迁移到主流技术栈。3. Nathan Marz 的回应A. "魔法"与"难以理解"的误解这是混淆了糟糕的使用与思想本身：可以用宏写出糟糕的代码，就像任何语言构造一样宏确实能让你写出更糟糕的代码但这不是反对宏的论据，你可以选择不写糟糕的代码B. 宏的使用原则Lisp 中有句俗话："宏的第一条规则是不要使用宏"：绝对正确除非需要，否则不应使用当你使用它们时，你在做任何其他语言构造都无法很好完成的事情C. Specter 项目示例一个项目中的关键宏实现了：极具表现力的抽象难以匹配的性能即使是手写优化代码也难以匹敌D. 知情决策的缺失确实有少数程序员理解 Lisp/Clojure 并做出知情决定不使用它们但大多数程序员没有花时间真正理解它们的益处只有约 2.6% 的开发者使用 Lisp 或 Clojure作者怀疑甚至不到 5% 的程序员真正理解 Lisp/Clojure 足以做出知情决定E. 团队入职经验在 Red Planet Labs 的亲身经验：如果大型 Clojure 代码库编写良好，让开发者入职不是问题即使是新学习 Clojure 的开发者也能适应有调整期，但任何大型代码库都有调整期当学习新的编程范式时，调整期可能更强烈，但这是值得的Clojure 中的开发速度高于其他语言，因为能够构建更好的核心抽象宏是重要因素，Clojure 对不可变性的强调也是六、结论1. 选择权最终，生活在 Flatland 是一个选择。2. 关键时刻选择出现在你注意到自己对不熟悉思想的本能退缩时，当你感觉到"这没有意义"和"也许我还没有概念来理解它"之间的张力时。3. 定义时刻你在那一刻做的事情定义了你是留在 Flatland 还是走出它。4. 更广泛的启示宏不是唯一具有这种维度转移品质的伟大编程思想：函数式编程的概念类型系统的抽象并发模型领域特定语言（DSL）每一个伟大的编程思想都可能遇到同样的"Flatland 效应"。关键在于保持开放的心态，认识到自己的认知局限，并愿意投入时间去理解新的维度。参考资料The programmers who live in Flatland - Red Planet Labs Blog
Lotus Notes 与 PLATO：协同软件的历史回眸一、文章概述1. 来源标题：LotusNotes作者：J. B. Crawford发布时间：2026 年 3 月 14 日来源：Computers Are Bad2. 文章摘要本文追溯了协同软件 Groupware 的历史源头，从 20 世纪 60 年代的 PLATO 系统开始，讲述其 =notes= 功能如何影响了后来的 Lotus Notes，以及 Lotus Notes 如何从巅峰走向衰落的过程。二、PLATO：协同计算的先驱1. 军事与学术的交汇第二次世界大战对美国高等教育产生了深远影响。GI Bill 使得大量退伍军人能够负担大学教育，而军方规划者认为盟军的胜利源于技术和工业卓越。雷达、无线电导航、科学管理、运筹学、核武器等许多决定性创新都起源于顶尖大学的学术研究实验室。MIT、斯坦福、加州大学等许多高校创建了子公司和衍生机构，至今仍是主要国防承包商。2. PLATO 系统的诞生在这种军事学术合作精神下，伊利诺伊大学的一组研究人员（主要是物理学家）获得了军事资金，开发了名为 Programmed Logic for Automatic Teaching Operations，即 PLATO 的系统。PLATO 起源于 20 世纪 50 年代末，鼎盛于 20 世纪 70 年代，通常被认为是计算机辅助教学的首次尝试。PLATO 与当时的其他大型计算机系统（如空中交通管制系统 9020）有许多相似之处：它 struggling 在大范围内连接终端和计算机，在互联网甚至只是一个想法之前；它必须显示图形，这在当时是非常原始的计算机能力，但被认为对课堂演示至关重要；系统支持许多同时用户，并且必须实时处理数据以同步他们的各种工作空间。但 PLATO 也有重要的差异。与 SAGE 和 9020 不同，与商业会计和制表系统不同，与几乎所有已发明的计算机应用程序不同，PLATO 是为用户主导的内容而设计的。3. 协作与 =notes= 的诞生PLATO 强调协作，反映了其起源于学术物理学。20 世纪 60 年代早期的许多 PLATO 开发侧重于简化学习模块的开发，使教师能够用较少的专业计算机培训创建交互式 PLATO 课程。到 20 世纪 70 年代，随着 PLATO 终端越来越多地安装在伊利诺伊州的学校和其他机构，对协作的重点转向了通信。如果学习模块对教师来说容易开发，学生也应该能够使用系统创建自己的课程和学习材料。研究人员和其他学术用户也有类似的愿望，希望有一个计算机系统，可以在其中保存笔记、撰写报告并与同事保持联系。伊利诺伊大学计算机辅助教育研究实验室的 PLATO 开发人员长期以来有一种简单的沟通方式，通过编辑一系列名为 notes1 到 notes19 的课程。虽然功能尚可，但并不完美：完全缺乏访问控制、格式或任何组织方式，随着系统用户的增加，notes 课程变得令人头疼。1972 年，随着 PLATO IV 终端、新资金和新的后端计算机，PLATO 快速增长。显然需要一个更好的 notes 版本。通过学术界的运作，构建更好的 notes 文件的任务落在了两名高中生身上，他们正在伊利诺伊大学附属实验室高中过暑假。使用 PLATO 原生的 TUTOR 编程语言和用于考试和课程讨论的设施，Dave Woolley 和 Kim Mast 编写了一个名为 =notes= 的课程。=notes= 课程最初用于系统公告、故障报告和 PLATO 操作员之间的通信。但很快，它做的事情远不止这些。4. PLATO 的历史地位PLATO 并没有证明是一个持久的成功，尽管进行了数十年的商业化努力，但它很昂贵，计算机辅助教学的实际益处仍未得到证实。很少有 PLATO 系统逃出伊利诺伊大学及其卫星交付点网络。后续项目逐渐消失，尽管 PLATO 从 1960 年的概念发展到 1970 年代复杂的多用户交互系统，但 PLATO 在 1980 年代走向衰落。如今很少有人想到 PLATO，这是不幸的，因为它是那些非凡的、孤立的历史时刻之一，一种概念上的奇点，在这个项目中，现实成功有限的项目孕育了如此多的概念，以至于它决定了后来的历史进程。当我们看看现代计算机、智能手机和社交媒体时，很难找到任何不是以某种方式从 PLATO 衍生而来的东西。通过 PLATO 在 20 世纪 70 年代的 NSF 资金以及与其他 NSF 努力的互动，我认为 PLATO 可能是比 ARPANET 和 NSFNET 更重要的现代互联网先驱。不是在技术方面，PLATO 紧密耦合到主帧终端架构，不太可能产生我们灵活的分组路由互联网架构。而是在氛围方面。PLATO 是一个大型、联网的计算机系统，强调发布事物和查看其他人发布的事物。它提供数学课程，但也提供游戏。最重要的是，它有 notes。graph TD A[PLATO 系统 1960s-1970s] --> B[=notes= 功能 1973] A --> C[在线游戏] A --> D[计算机辅助教学] B --> E[公共优先通信文化] E --> F[PLATO notes 1976] F --> G[Ray Ozzie 伊利诺伊大学学生] G --> H[Iris Associates 1984] H --> I[Lotus Notes 1989]三、Lotus Notes 的诞生1. Ray Ozzie 与伊利诺伊大学渊源20 世纪 70 年代末，伊利诺伊大学正在发生其他事情：未来微软首席技术官 Ray Ozzie 正在那里攻读计算机科学本科学位，其中很大一部分涉及 PLATO。1979 年毕业后，他为 Data General 工作，Data General 是流行的小型计算机制造商，他向 Jonathan Sachs 汇报。离开 Data General 后，他在 Software Arts 工作，Software Arts 是 VisiCalc 背后的开发公司。他一定与 Jonathan Sachs 保持联系，后者于 1982 年离开 Data General 成立了自己的公司：Lotus Development。Lotus 因 Lotus 1-2-3 而闻名，这是取代 VisiCalc 成为个人计算中可能最重要软件包的热门电子表格应用程序。Lotus 的两位创始人是 Sachs 和 Mitchell Kapor，他们都有 Data General 和 Software Arts 的背景。Lotus 1-2-3 是有史以来最成功的软件产品之一，但办公计算的前沿正在迅速扩展到文字处理和演示。与 Google Docs 和 Microsoft Office 仍然勉强维持的现代单一文化不同，生产力软件市场在 20 世纪 80 年代极其竞争，几乎每个独立软件供应商都在开发某种生产力或办公套件。其中绝大多数都是商业失败，Lotus SmartSuite 也不例外。2. Iris Associates 与 Lotus Notes 的开发1984 年，Ray Ozzie 离开 Lotus 成立了一家名为 Iris Associates 的新公司。Iris Associates 是一家独立公司，但有合同义务将其产品的独家出版权提供给 Lotus Development。作为交换，Iris 运营的前几年由 Lotus 的大量投资资助。Ozzie 现在控制着自己的王国，迅速聘请了另外三名伊利诺伊大学校友——他在 PLATO 工作时认识的人。不清楚这是 Iris Associates 的最初目标，还是由于他们对 PLATO 的经验而成为目标。无论如何，Iris Associates 花了大约五年时间构建了一个可以在 Windows PC 网络上运行的 PLATO =notes= 课程版本。通过他们与 Lotus 的出版安排，这将被称为 Lotus Notes。sequenceDiagram participant P as PLATO =notes= 1973 participant R as Ray Ozzie 伊利诺伊大学 participant I as Iris Associates 1984 participant L as Lotus Development participant N as Lotus Notes 1989 P->>R: 影响学生 R->>I: 创立公司 L->>I: 投资并要求独家版权 I->>N: 开发五年 L->>N: 发布产品四、Lotus Notes 的技术架构1. Groupware 的定义Lotus Notes 是最著名或最臭名昭著的 Groupware 示例之一。Groupware 是一个难以确切定义的概念，很大程度上是因为其历史。整个类别可以追溯到 Douglas Engelbart 在 SRI 的人类增强工作——这项工作像 PLATO 一样未能获得市场采用，但对整个艺术产生了巨大影响。人类增强是 Groupware 的核心思想，也称为计算机支持的协作工作。这些是高层次的学术思想，关于计算机如何增强大多数生产力工作背后的社会过程。在 Iris Associates 的时代，Groupware 意味着类似这样的东西：协助人类进行通信、协作以及跟踪和执行流程的软件。实际上，这意味着核心 PIM 应用程序，如电子邮件和日历，但也包括协作编辑、工作流自动化、文档和策略管理，以及涉及多人的所有其他核心业务需求。2. 复制数据库架构Lotus Notes 的许多怪异之处反映了其在 PLATO 的起源。20 世纪 80 年代的大多数微机网络产品都是围绕对等网络构建的，这是多个小计算机可以直接相互通信的想法。那是 20 世纪 80 年代的热门新事物，但 PLATO 不属于 20 世纪 80 年代，它属于 20 世纪 60 年代。PLATO 甚至不是真正的客户机服务器架构：它是一种终端计算机架构，其中单个 PLATO 终端与运行实际逻辑的多个（主要是 DEC）大型机或中型计算机之一交互。PLATO 不仅是多用户的，它是多计算机的。为了从多组独立的计算机和终端形成一个集成系统，PLATO 在计算机之间复制所有用户数据。Lotus Notes 继承了相同的方法：数据存储在数据库中，通过在机器之间复制该数据库在用户之间通信。Lotus Notes 中的一切都是一个 note，数据库是由唯一 ID 标识的 notes 集合。当 note 更新时，该 note 被复制到数据库的其他副本。随着时间的推移，这种架构明显的性能和可靠性问题变得显而易见，复制过程变得更加复杂，但它始终在这个简单的逻辑模型上工作：更新本地数据库，然后将其复制到其他。graph LR subgraph 办公室 A UA[用户 A] --> |编辑| NA[本地 Notes 数据库] end subgraph 办公室 B UB[用户 B] --> |读取| NB[本地 Notes 数据库] end subgraph 办公室 C UC[用户 C] --> |读取| NC[本地 Notes 数据库] end NA <--> |复制同步| NB NB <--> |复制同步| NC NA <--> |复制同步| NC3. 客户机服务器模型由于 PLATO 的例子，Notes 围绕客户机服务器模型进行架构设计。客户端通常称为 Lotus Notes，部分复制数据库以允许用户查看和编辑 notes。服务器后来称为 Domino，保留数据库的完整副本并执行足够的逻辑来处理访问控制。像 PLATO 的复制模型一样，并不期望有一个单一的中心服务器。许多 Domino 服务器可以共享同一个数据库，并在自己之间复制更改。这种架构对于那个时代的企业部署非常方便，每个办公室位置都有局域网，但站点之间的网络连接昂贵且相对较慢。Domino 服务器具有将用户活动整合到减少的复制流量中的效果，当办公室间网络链接丢失时，办公室仍然正常运行，尽管作为一个孤岛。graph TB subgraph 总部 Domino1[Domino 服务器] end subgraph 分公司 A ClientA1[Notes 客户端] ClientA2[Notes 客户端] DominoA[Domino 服务器] ClientA1 --> DominoA ClientA2 --> DominoA end subgraph 分公司 B ClientB1[Notes 客户端] ClientB2[Notes 客户端] DominoB[Domino 服务器] ClientB1 --> DominoB ClientB2 --> DominoB end Domino1 <--> |复制同步| DominoA DominoA <--> |复制同步| DominoB DominoB <--> |复制同步| Domino1五、Lotus Notes 的兴衰1. 巅峰时期在 20 世纪 90 年代中期，Lotus Notes 是占主导地位的 Groupware 平台。Forbes 报道 Lotus Notes 的市场份额在 1995 年为 64%。在那个巅峰时期，IBM 花费超过 30 亿美元收购了 Lotus。1995 年，Lotus 与 IBM 合并。IBM 对客户机服务器微机应用程序投入巨大，因为它们是与 IBM 在大型机系统传统优势最接近的匹配。收购 Lotus 无疑是为了推进这一重点：Lotus Notes 必须是 Windows 95 时代最突出的客户机服务器产品之一。2. 技术演进A. Java 化Lotus Notes 1 到 3 是迭代改进，从 1989 年到 1993 年，添加功能和修复缺陷。随着 Lotus Notes 4，从 1996 年到 1999 年，IBM Lotus Development 开始全面移植到 Java。Java 被添加为原生脚本语言，与 Formula 和 LotusScript 一起，许多更新的 Lotus Notes 功能是 Java 优先的。Lotus Notes 的 Java 化可以说在 2008 年完成，当时 Lotus Notes 客户端被完全替换为基于 Eclipse 的完整 Java 实现。B. Web 适配除了新的面向对象用户界面世界，IBM 还使 Lotus Notes 适应了 Web。版本 4 引入了一个非常简单的 Web 界面，用户可以通过 Web 浏览器查看静态 notes，IBM 添加了 SMTP 桥以与其他电子邮件系统互操作。2002 年左右，IBM 逐步淘汰了 Lotus 品牌，果断地将 IBM Notes 和 IBM Domino 折叠进 Big Blue。Domino Web Access 到 2002 年提供了 Web 界面，尽管它有限并且与我们现在认为的仅仅是 Webmail 没有多大区别。2008 年，IBM 推出了 XPages。XPages 基本上是在 Domino 服务器上运行的 Java Server Faces 组件。它们直接与 Notes 数据库交互，在某些方面只是 Notes 表单的基于 Web 的版本。你甚至使用 Domino Designer 编辑它们，这是严肃 Notes 开发的 IDE。3. 衰落的原因A. 市场份额流失Lotus Notes 最迷人的部分是它的衰落。1995 年，Lotus Notes 市场份额为 64%。1997 年，下降到 47%。2008 年的一项调查将 Lotus Notes 定为 10%。考虑到企业软件的长周期和持久性，这是一个惊人的衰落。B. 竞争对手 MicrosoftIBM 以巨资收购热门软件产品然后将其推入地下是一个老故事。但这里还有另一个主要参与者：Microsoft 处于最佳状态。绝大多数 Lotus Notes 用户直接转向 Microsoft Exchange。Microsoft 除了与 Windows 的更高级别集成（在技术和销售层面）之外，还被公认性能更高且更易于维护。我认为 Microsoft 在 21 世纪初处于其工程能力的顶峰，并且他们在软件方面比所有带有开放标准 TCP/IP 网络之前包袱的软件具有相当大的后发优势。C. 标准化问题标准本身是故事的另一个重要部分。早期的电子邮件系统都是专有的，不一定是网络系统——第一个电子邮件实现只是将邮件存储在所有用户通过终端访问的单台机器上。Lotus Notes 拥有完全专有的电子邮件实现，在那个世界中并不突出。当 Microsoft 首次推出 Exchange 时，它有相同的限制。这种情况很快改变，尽管更多是意外而非有意。ITU X.400 预期为公共互联网上的电子邮件提供标准，取代专有和网络特定的开放标准的大杂烩。相反，X.400 未能做太多事情——但在 Exchange 甚至可以推出之前，它成为了 Microsoft Exchange 的基础。Exchange 最终处于某种标准炼狱中，一种开放标准的实现，该标准在 Exchange 可以推出之前就已经消亡。Exchange 的 X.400 功能成为一种不同寻常起源的专有标准，而工业和学术界的大部分选择遵循 NSF 示例并采用更简单更古老的 SMTP。D. 身份模糊最后，房间里的大象是 Lotus Notes 的身份问题。今天很难准确解释 Lotus Notes 是什么。这并不是一个新问题。1998 年，Forbes 写道：甚至在 IBM 到达之前，Notes 的身份就已经模糊；现在也不清楚。首先，软件被营销为一个系统，使广泛分散的员工群体能够轻松地协作编辑文档或管理项目。然后 Notes 被重新定义为构建定制协作应用程序的工具。现在 Lotus 似乎正在强调 Notes 中的电子邮件功能，并将其定位为 cc:Mail 的替代品。Lotus Notes 在某种程度上定义了一个产品类别这一事实成为了其他供应商用更有针对性、更狭隘、更明显有用的竞争产品挤入的负担。Lotus Notes 开始听起来像 Zombocom：你可以做任何事情。Microsoft 只是销售电子邮件和日历。Notes 的大范围对用户体验也是一个问题；除了 Notes 客户端在 21 世纪看起来和感觉过时之外，其功能的通用性和深度意味着它也很难使用。graph LR A[1995 市场份额 64%] --> B[1997 市场份额 47%] B --> C[2008 市场份额 10%] C --> D[2018 出售给 HCL] A --> E[IBM 收购 $30 亿] E --> F[Java 化 1996-2008] F --> G[XPages 2008] G --> C六、结语2018 年，IBM 将 Lotus Development 的剩余部分出售给一家名为 HCL 的印度软件公司。HCL 是一家经典的 IT 咨询公司，其投资组合涵盖工业 4.0 到 SAP 咨询。他们作为 IBM 摆脱品的一部分收购了 Lotus。Lotus Notes 现在是 HCL Notes，据我所知，HCL 打算只要遗留客户愿意支付他们继续运行 Notes 的费用，就享受收入。那是 Lotus Notes 魅力的另一部分：它可能是最传统的传统软件。我从未在一家使用 Lotus Notes 的组织工作过，但我工作过的每一家非初创公司都有强大的制度记忆，回想起在 Lotus Notes 时代的过去。有些人愉快地记住它，大多数人讨厌地记住它，但他们都记得它。Gmail 会激发这样的情感吗？参考资料LotusNotes - Computers Are Bad
Astral 加入 OpenAI一、新闻概述1. 标题Astral 宣布加入 OpenAI，Ruff 和 uv 等工具将继续开源2. 发布时间2025 年（具体日期未在原文中注明）3. 来源Astral 官方博客二、核心内容1. 事件摘要A. 主要内容Astral 公司宣布已达成协议加入 OpenAI，成为 Codex 团队的一部分。B. 核心亮点Astral 被 OpenAI 收购，加入 Codex 团队开源工具 Ruff、uv、ty 将继续维护每月下载量达数亿次承诺继续保持开源2. 关键信息A. 涉及产品Ruff：Python 代码检查工具uv：Python 包管理工具ty：类型检查工具B. 重要数据月下载量：数亿次公司成立时间：约 3 年投资方：Accel（种子轮和 A 轮）、a16z（B 轮）C. 收购方OpenAI Codex 团队3. 背景介绍A. 公司历史Astral 由 Charlie Marsh 创立，致力于改变 Python 开发体验。三年前的发布文章中提到："如果能让 Python 生态系统生产力提高 1%，想象一下这种影响会如何复合增长。"B. 相关上下文Astral 开发的工具链已成为现代 Python 开发的基础设施。Ruff 作为快速的 Python linter，uv 作为极速的 Python 包管理器，在开发者社区中广受欢迎。三、详细报道1. 主要内容A. 收购详情Astral 团队将加入 OpenAI 的 Codex 团队收购完成后将继续支持开源工具保持与社区共同构建的开发模式B. 开源承诺所有工具将继续开源继续为 Python 生态系统构建工具与 OpenAI 的开源理念一致C. 未来规划继续维护现有开源工具探索与 Codex 的集成方式更广泛地思考软件开发未来2. 技术细节A. Astral 工具链架构graph LR Dev[开发者] --> Ruff[Ruff 代码检查] Dev --> uv[uv 包管理] Dev --> ty[ty 类型检查] Ruff --> Code[高质量代码] uv --> Env[快速环境] ty --> Type[类型安全]B. 工具特点Ruff：用 Rust 编写的极速 Python linteruv：用 Rust 编写的极速 Python 包管理器ty：类型检查工具C. OpenAI Codex 集成展望Astral 工具与 Codex 的无缝集成AI 辅助编程工具链增强提升软件开发生产力3. 数据与事实A. 用户规模月下载量达数亿次工具已成为 Python 开发基础设施B. 投资情况Accel 领投种子轮和 A 轮a16z 领投 B 轮C. 社区影响拥有全球用户基础被称为"最受喜爱的软件之一"四、影响分析1. 行业影响A. 技术趋势AI 与开发工具的深度融合开源工具在 AI 时代的重要性Rust 编写的工具在开发者工具领域的崛起B. 竞争格局OpenAI 加强开发工具领域布局Python 开发工具进入 AI 辅助新阶段可能推动其他厂商类似投资2. 用户影响A. 现有用户工具将继续免费开源功能持续改进可能获得 AI 增强功能B. 潜在用户更易接触 AI 辅助开发工具Python 开发体验提升C. 迁移成本无需迁移，工具保持不变可选的新 AI 功能3. 技术趋势A. 技术方向AI 与传统开发工具的边界模糊开源与商业模式的结合探索开发者工具进入新纪元B. 生态影响Python 生态系统持续繁荣开发工具标准化加速AI 辅助编程成为标配五、各方反应1. 官方回应Astral 创始人 Charlie Marsh 表示："AI 正在快速改变我们构建软件的方式，这种变化的步伐只会加速。如果我们的目标是让编程更高效，那么在 AI 和软件的前沿领域构建就感觉是最有杠杆作用的事情。"2. OpenAI 官方声明OpenAI 在其公告中确认将继续支持 Astral 的开源工具。3. 社区反馈A. 正面期待开源承诺获得社区认可期待与 AI 的结合创新B. 关注点收购后产品独立性未来商业化策略六、相关链接1. 官方公告Astral 官方博客公告OpenAI 收购公告2. 项目链接Ruff GitHub 仓库uv GitHub 仓库ty GitHub 仓库参考资料Astral to join OpenAI
足够详细的规范就是代码一、新闻概述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. 规范文档规模Symphony 规范文档长度：已达到所含 Elixir 实现的 1/6若继续扩展，将重演博尔赫斯"论科学的精确性"中的荒谬故事B. 代码质量问题作者指出 Symphony 规范中充斥着"AI 产物"的痕迹：代码片段标注为 text 而非代码块缺乏连贯性、目的感和对全局的理解例如第 10.5 节的"规范形"句子杂乱堆砌四、影响分析1. 行业影响A. 技术趋势Agentic coding 运动试图将工程师转变为规范编写者，但这忽视了软件工程对精确性的内在需求。B. 工程实践过度依赖规范文档可能导致：规范本身质量下降（为求快而牺牲思考）生成代码质量不稳定维护成本增加2. 用户影响A. 工程师被误导以为可以"外包"编码工作实际上需要投入与编码相当的精力编写精确规范B. 团队在追求速度的工程文化中，规范质量无法保证"垃圾输入，垃圾输出"原则依然适用3. 技术趋势A. 根本问题代码就是规范最精确的表达形式。试图绕过这一本质是徒劳的。B. 前景AI 辅助编码有价值，但不应寄望于完全替代精确思维和直接编码。五、各方反应1. 作者立场规范文档从来不是省时设备。如果优化交付时间，直接写代码比通过中间规范文档更有效。2. 业内观点A. 支持 Agentic Coding认为规范能提高质量、减少编码工作、让工程师转向更高层抽象。B. 反对意见强调精确描述必然演变为代码，规范质量决定生成质量。六、相关链接1. 相关项目OpenAI Symphony 项目Symphony Haskell 实现2. 参考资料Dijkstra EWD667YAML 规范参考资料A sufficiently detailed spec is code - Haskell for all