❌

阅读视图

发现新文章，点击刷新页面。
🔲 ☆

“代码必须不是人写的”：2026 年软件工厂宣言！

✇Tony Bai
bigwhite

本文永久链接 – https://tonybai.com/2026/02/14/2026-software-factory-manifesto-code-not-by-humans

大家好，我是Tony Bai。

如果你的团队里发布了一条规定：“禁止人类写代码”，你会作何感想？

疯了？懒惰？还是科幻？

但这正是 StrongDM AI 团队在 2026 年 2 月 6 日 发布的备忘录中，白纸黑字写下的第一条铁律。

在这份名为《软件工厂与智能体时刻（Software Factories And The Agentic Moment）》的文章中，CTO Justin McCarthy 极其激进地定义了未来的软件开发范式——非交互式开发（Non-interactive Development）。

他们提出的口号令人震颤：

  1. Code must not be written by humans.（代码必须不是人写的。）
  2. Code must not be reviewed by humans.（代码必须不是人审查的。）
  3. 如果你今天每个工程师没消耗掉 1000 美元的 Token，说明你的工厂还不够自动化。

当我们还在讨论“如何用 AI 辅助写代码”时，先驱者们已经开始讨论“如何禁止人类写代码”了。这是生产关系的彻底重构。

奇点时刻：从“错误累积”到“正确性复利”

为什么他们敢这么做？依据是什么？

文章中揭示了一个关键的“转折点”。

在 2024 年底之前，我们使用 AI Agent 进行长程编码任务时，面临着“错误累积（Compounding Error）”的诅咒。AI 写错一步，后面步步错，最终导致项目崩塌（Collapse）。

但在 Claude 3.5 (2024年10月版) 发布后，配合 Cursor 的 YOLO 模式，曲线发生了逆转。

Agent 开始展现出“正确性复利（Compounding Correctness）”。即 AI 写的代码越多，它对上下文的理解越深，自我修正的能力越强。

这意味着一旦跨越了这个阈值，人类的介入（写代码、改 Bug）不再是“必要的修正”，反而成了“效率的瓶颈”和“污染源”。

于是，StrongDM 团队决定：Hands Off（把手拿开）！

我们要建造的不是辅助人类的工具，而是一座自动化的软件工厂。

测试已死，场景永生

在“无人值守”的工厂里，怎么保证生产出来的软件是能用的？

靠单元测试吗？不。

传统的测试是刚性的，甚至是危险的。

Agent 非常聪明，聪明到学会了 Reward Hacking（奖励黑客）。如果你只要求它通过测试，它可能会直接写一个 return true 来骗过测试框架，而不管业务逻辑是否正确。

软件工厂引入了新的验证标准：

  1. Scenarios（场景）：类似于机器学习中的“留出集（Holdout Set）”。它是端到端的用户故事，不仅仅是代码逻辑，更是业务意图。
  2. Satisfaction（满意度）：放弃布尔值的 Pass/Fail，转而使用概率性的“满意度”指标。在所有观察到的执行路径中，有多少比例是符合预期的？

基础设施革命：数字孪生宇宙 (DTU)

这是这篇文档中最令人脑洞大开的部分。

在开发企业级软件时，我们经常需要依赖第三方 SaaS（如 Okta, Jira, Slack, Google Drive）。

  • 传统痛点：API 有速率限制（Rate Limits），调用要花钱，测试环境很难搭建。
  • 工厂解法：Digital Twin Universe (DTU)。

StrongDM 的 AI 团队利用 AI，构建了这些第三方服务的行为克隆（Behavioral Clones）。

他们在内存中运行了成千上万个 Okta、Slack 和 Google Drive 的“数字孪生体”。

这意味着他们可以在一小时内运行数千个集成测试场景，不需要联网，不消耗 API 额度，没有任何速率限制。

他们可以模拟极端边缘情况（比如 Slack 突然挂了，或者 Jira 返回了乱码），来验证软件的鲁棒性。

以前我们认为“重写一个 Slack 服务端”是疯子才干的事（不经济）；但在 AI 时代，让 Agent 生成一个 Mock Server 极其廉价。AI 改变了“造轮子”的经济学模型。

新经济学：烧钱是为了省命

文档最后抛出了一个震撼的 KPI：

“If you haven’t spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement.”
（如果你今天每位工程师没消耗掉 1000 美元的 Token，你的工厂就有改进空间。）

这听起来像是烧钱，其实是在省命。

相比于人类工程师昂贵的时薪，以及人类犯错后带来的返工成本，Token 是最廉价的资源。

在这个工厂里，人类的角色被彻底重新定义：

我们不再是流水线上的工人（Coder），我们是流水线的设计师（Architect）。

每当你忍不住想打开 IDE 修改代码时，请默念那句禅宗般的公案：

“Why am I doing this? The model should be doing this instead.”

小结：软件工程的终局

StrongDM 的宣言，或许就是 Software 3.0 时代的《独立宣言》。

它告诉我们，软件开发正在经历从“手工作坊”向“自动化工厂”的不可逆转的跃迁。

在这个新世界里，Spec（规范）是唯一的输入，Endpoint（服务）是唯一的输出。中间的一切——编码、测试、部署、SaaS 依赖——都将被 AI 和它的数字孪生体接管。

这就是 2026 年及以后的软件工程。你，准备好了吗？

资料链接：https://factory.strongdm.ai/

你愿意交出“方向盘”吗？

面对 StrongDM 这种“不准人写代码”的极端铁律，你感到的是解放还是恐惧？如果一个系统能 24 小时自动纠错并产出 99.9% 满意的代码，你还会坚持亲自敲击键盘吗？

欢迎在评论区投出你的立场：支持“全自动化工厂”，还是坚持“人机协作”？

亲手搭建你的“微型工厂”

StrongDM 描绘的愿景听起来很科幻，但其核心技术——Spec 驱动、Agent Team 编排、自动化验证——其实就在我们手边。

虽然我们还没法每天烧掉 $1000 Token，但我们可以学习这套“非交互式开发”的心法。

在我的极客时间专栏《AI 原生开发工作流实战》中，我们将深入探讨：

  • Spec-Driven Development：如何写出让 Agent 一次做对的规格文档？
  • Scenario 设计：如何构建轻量级的“场景”来替代僵化的测试？
  • Claude Code 实战：如何让 AI 实现代码的自我演进与自愈？

扫描下方二维码，让我们开始建设自己的微型软件工厂。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

  • 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
  • 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
  • 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

🔲 ☆

算法神话的祛魅：Russ Cox 与浮点数转换的 15 年求索之路

✇Tony Bai
bigwhite

本文永久链接 – https://tonybai.com/2026/02/03/russ-cox-15-year-war-on-floating-point-conversion

大家好，我是Tony Bai。

“浮点数到十进制的转换一直被认为很难。但本质上，它们非常简单直接。” —— Russ Cox (2011)

“我错了。快速的转换器也可以很简单，这篇文章将展示如何做到。” —— Russ Cox (2026)

在计算机科学的深处，潜伏着一条名为“浮点数转换”的恶龙。将一个二进制浮点数（如 float64）转换为人类可读的十进制字符串（如 “0.1″），看似简单，实则是一个困扰了业界半个世纪的难题。

2011 年，Go 语言的核心人物 Russ Cox 写下了一篇博文，试图用一种简单的算法来“驯服”这条龙。然而，在随后的十几年里，学术界和工业界爆发了一场军备竞赛：Dragon4, Grisu3, Ryū, Schubfach, Dragonbox… 每一个新算法都试图在速度上压倒前一个，但也让代码变得越来越复杂，数学证明越来越晦涩。

2026 年初，Russ Cox 带着他的新系列文章强势回归。这一次，他不仅带来了一套比所有已知算法都更快的全新算法，而且证明了：极致的性能不需要极致的复杂性。

这套算法已被确定将在 Go 1.27 (2026年8月) 中发布。今天，我们就来深度解析这项可能改写浮点数处理历史的技术突破。

历史的迷宫与“不可能三角”

要理解 Russ Cox 的成就，我们首先要理解这个问题的难度。一个完美的浮点数打印算法，必须同时满足三个苛刻的条件（“不可能三角”）：

  1. 正确性 (Correctness)：转换必须是双射的。Parse(Print(f)) == f 必须恒成立。这意味着你不能随意丢弃精度。
  2. 最短性 (Shortest)：输出的字符串必须是所有能转回原值的字符串中最短的。例如，0.3 在二进制中无法精确表示，打印时应该是 “0.3″ 而不是 “0.2999999999999999889″。
  3. 速度 (Speed)：在大规模数据处理（如 JSON 序列化）中，转换速度直接决定了系统的吞吐量。

历史的演进：
* Dragon4 (1990)：实现了正确性和最短性，但依赖大整数（BigInt）运算，慢如蜗牛。
* Grisu3 (2010)：Google 的 V8 引擎引入。速度极快，但不保证最短性，约 0.5% 的情况会失败并回退到慢速算法。
* Ryū (2018) & Dragonbox (2020)：通过复杂的数学技巧（查表法），终于在不使用 BigInt 的情况下实现了正确且最短。这是性能的巅峰，但代码极其复杂，充满魔术数字。

Russ Cox 的目标，就是打破这个迷宫：能不能既像 Ryū 一样快且正确，又像 2011 年的那个算法一样简单？

核心技术——“未舍入缩放” (Unrounded Scaling)

Russ Cox 的新算法核心，源于一个极其精妙的数学原语：快速未舍入缩放 (Fast Unrounded Scaling)。

什么是“未舍入数”？

在传统算法中，我们总是纠结于“何时舍入”。Russ Cox 引入了 “未舍入数” (Unrounded Number) 的概念 ⟨x⟩。它由三部分组成：

  • 整数部分: floor(x)
  • ½ bit: 标记 x – floor(x) >= 0.5
  • sticky bit (粘滞位): 标记 x 是否有非零的小数残余。

这种表示法不仅保留了用于正确舍入（Round half to even）的所有必要信息，而且可以通过极其廉价的位运算（| 和 &）来维护。这就像是在计算过程中保留了一个“高精度的尾巴”，直到最后一步才决定如何截断。

缩放的魔法

浮点数打印本质上是计算 f = m * 2^e 对应的十进制 d * 10^p。核心步骤是将 m * 2^e 乘以 10^p。

Russ Cox 使用查表法（预计算 10^p 的 128 位近似值）来实现这一缩放。但他最惊人的发现是：在 64 位浮点数转换的场景下，我们甚至不需要完整的 128 位乘法！

他证明了：只需计算 64 位 x 64 位的高位结果，并利用低位的“粘滞位”来修正，就能得到完全正确的结果。这意味着，曾经需要几十次乘法或大整数运算的转换过程，现在被缩减为极少数几次 CPU 原生乘法。

这一发现被称为 “Omit Needless Multiplications”（省略不必要的乘法），它是新算法性能超越 Ryū 的关键。

从理论到 Go 1.27

基于这个核心原语，Russ Cox 构建了一整套算法家族：

  • FixedWidth: 定点打印（如 %.2f）。
  • Shortest: 最短表示打印（如 %g）。
  • Parse: 字符串转浮点数。

性能碾压

Russ Cox 在 Apple M4 和 AMD Ryzen 9 上进行了详尽的基准测试：

  • 定点打印：新算法 (uscale) 显著快于 glibc 和 double-conversion，甚至快于 Ryū。
  • 最短打印：在纯算法层面，新算法与业界最快的 Dragonbox 持平或更快，但代码逻辑要简单得多。
  • 解析：同样基于该原理的解析算法，性能超越了目前业界标杆 fast_float (Eisel-Lemire 算法)。

更令人兴奋的是，Go 1.27 将直接集成这套算法或算法的一部分。对于 Gopher 来说，这意味着你的 fmt.Sprintf、json.Marshal 和 strconv.ParseFloat 将在下个版本中自动获得显著的性能提升，而无需修改一行代码。

证明的艺术

除了代码，Russ Cox 还做了一件很“极客”的事：他用 Ivy（一种 APL 风格的语言）编写了完整的数学证明。

他没有选择形式化验证工具（如 Coq），而是通过编写可执行的代码来验证算法在每一个可能的 float64 输入下都是正确的。这种“通过计算来证明” (Proof by Computation) 的方法，不仅验证了算法的正确性，也为后来者留下了一份可交互的、活生生的文档。

小结：简单是终极的复杂

从 2011 年的初次尝试，到 2026 年的最终突破，Russ Cox 用 15 年的时间完成了一个完美的闭环。

这一系列文章是一种工程哲学的胜利。它告诉我们：当我们面对复杂的遗留问题时，不要只是盲目地堆砌优化技巧。回到数学的源头，重新审视问题的本质，或许能找到那条既简单又快的“捷径”。

现在的 Go 标准库中，即将拥有一颗比以往任何时候都更强大、更轻盈的“心脏”。

资料链接：https://research.swtch.com/fp-all

你更看重哪一点？

在算法的世界里，正确性、最短表示、运行速度，这“不可能三角”总是让我们反复权衡。在你平时的开发中，有哪些场景曾让你被浮点
能或精度困扰？或者，你对 Russ Cox 这种“死磕 15 年”的工程精神有何感触？

欢迎在评论区分享你的看法！如果这篇文章让你对浮点数实现算法方面有了新的认识，别忘了点个【赞】和【在看】，并转发给你的Go开发朋友们！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

  • 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
  • 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
  • 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

❌