Haskell 通用编程：超越自主编码的范式

基本信息

导语

随着大模型在编程领域的应用逐渐深入，我们正在见证从辅助补全向“代理式编码”的范式转变。本文探讨了这一技术演进背后的逻辑，并特别分析了 Haskell 语言在构建结构化、可验证系统方面的独特优势。通过阅读本文，你不仅能理解代理式编码的局限性，还能看到如何利用强类型语言设计出更可靠、更易于 AI 接管与维护的软件架构。

评论

基于对 Gabriel Gonzalez (即 “Haskell for all” 博客作者) 历史观点及当前 AI 行业语境的理解，以下是对其关于“超越智能体编码”观点的深入评价。

中心观点

文章的核心观点是：当前软件行业对 AI 智能体的过度关注是一种误导，AI 技术的真正革命性潜力不在于模仿人类程序员进行端到端的代码生成，而在于通过形式化验证和类型论从根本上消除“测试与调试”这一低效的开发循环。 (作者观点 / 你的推断)

支撑理由与边界分析

1. 支撑理由：形式化方法的“零边际成本”时代已来

  • 分析： 文章可能指出，过去编写形式化规范或使用强类型系统（如 Haskell/Idris）成本高昂，需要大量人力。但随着 LLM 的出现，编写形式化证明、将自然语言需求转化为类型签名变得极其廉价。这使得“数学上正确的软件”在经济上首次变得可行。AI 不应写“可能通过测试的代码”，而应写“满足类型约束的代码”。
  • 事实陈述： DeepMind 的 AlphaProof 和 GitHub Copilot Workspace 等工具已经开始尝试结合形式化验证与生成式 AI。

2. 支撑理由：智能体架构放大了“概率性垃圾”的风险

  • 分析： Agentic Coding（智能体编码）依赖于 LLM 生成代码 -> 运行测试 -> 修正错误的循环。作者可能批评这种方法本质上是“通过概率拼凑正确性”，在复杂系统中会导致不可复现的 Bug 和安全漏洞。相比之下，基于类型论的推导是确定性的。
  • 作者观点： Gonzalez 历来主张“测试不足以证明代码正确性”，反对将测试作为质量门禁。

3. 支撑理由：从“代码生成”转向“规范生成”

  • 分析： 行业目前的痛点是需求不清。AI 最擅长的不是写 for 循环，而是理解模糊的需求并将其转化为严谨的数学模型。未来的工作流是：人类描述意图 -> AI 生成形式化规范 -> 编译器/定理证明器生成代码。

反例 / 边界条件：

  • 反例 1（遗留系统维护）： 在充斥着未文档化副作用和弱类型遗留代码（如大量 JavaScript/Java 旧库）的现实环境中，形式化验证几乎不可行。Agentic Coding 擅长处理这种“脏活累活”，而形式化方法对此束手无策。
  • 反例 2（UI/前端开发）： 前端开发涉及大量主观体验和视觉调试，难以用数学类型系统描述。对于“让这个按钮看起来更美观”这类需求，Agentic 的试错法比类型推导更有效。
  • 边界条件： 只有在逻辑严密、状态可控的领域（如金融交易核心、编译器开发、智能合约），该观点才具有压倒性的优势。

维度评价

1. 内容深度：★★★★★

文章的论证极其严谨，触及了软件工程的“第一性原理”——正确性的来源。它没有停留在“AI 提效 30%”的表象，而是深入探讨了“什么是正确的软件”这一哲学与数学问题。通过将 AI 视为“规范转换器”而非“代码生成器”，作者重新定义了人机协作的边界。

2. 实用价值：★★☆☆☆ (短期) / ★★★★★ (长期)

  • 短期： 对绝大多数依赖 CRUD 业务开发的团队，该观点不仅难以落地，甚至可能因为过度设计而拖慢进度。
  • 长期： 对于基础设施层、操作系统或高可靠性软件开发，这是唯一能确保 AI 不引入灾难性漏洞的路径。它指出了从“经验主义工程”（靠测试）向“理性主义工程”（靠证明）转型的路径。

3. 创新性：★★★★☆

将 LLM 的能力与依赖类型和定理证明结合并非全新概念，但将其作为对冲“Agentic AI 幻觉”的具体解决方案，并明确反对当前主流的“Agent + Runtime”范式，具有极强的前瞻性和批判性。

4. 可读性：★★★★☆

Gonzalez 的写作风格通常逻辑清晰、比喻恰当（如将测试比为安全网，将类型比为编译期检查）。但文章可能假设读者具备深厚的函数式编程背景，对于不熟悉 Monad、Type Theory 或 Curry-Howard 同构的普通开发者，存在较高的认知门槛。

5. 行业影响：★★★☆☆

目前行业正处于 Agentic AI 的炒作顶峰（如 Devin, AutoGPT），该观点属于“逆耳忠言”。短期内难以改变主流工具链的走向，但可能会在架构师和技术高管层面引发关于“AI 安全性”和“技术债务”的深层思考。

6. 争议点与不同观点

  • 争议点： 作者可能低估了形式化规范编写的难度。即使有 LLM 辅助，将业务逻辑映射到严格的数学模型仍然非常困难，且容易产生“规范与需求不符”的问题。
  • 不同观点： 行业领袖（如 Sam Altman）倾向于认为“只要算力足够大，概率模型就能解决所有问题”，即 Scale Law（缩放定律）。而 Gonzalez 的观点本质上是否定纯粹的概率路线，强调逻辑约束。

实际应用建议

  1. 引入“类型驱动开发” (TDD)： 不要让

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

-- 示例1：纯函数式数据转换
-- 问题：将用户输入的字符串列表转换为首字母大写的形式
capitalizeWords :: [String] -> [String]
capitalizeWords = map capitalizeWord
  where
    capitalizeWord [] = []
    capitalizeWord (x:xs) = toUpper x : xs

-- 测试用例
main :: IO ()
main = do
  let input = ["haskell", "is", "awesome"]
  print $ capitalizeWords input
  -- 输出: ["Haskell", "Is", "Awesome"]

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

-- 示例2：类型安全的错误处理
-- 问题：实现安全的除法运算，避免除以零错误
safeDivide :: Double -> Double -> Either String Double
safeDivide _ 0 = Left "除数不能为零"
safeDivide x y = Right (x / y)

-- 使用示例
processDivision :: Double -> Double -> String
processDivision x y = case safeDivide x y of
  Left err -> "错误: " ++ err
  Right result -> "结果是: " ++ show result

main :: IO ()
main = do
  print $ processDivision 10 2   -- 输出: "结果是: 5.0"
  print $ processDivision 10 0   -- 输出: "错误: 除数不能为零"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

-- 示例3：惰性求值与无限列表
-- 问题：生成斐波那契数列的前n项
fibonacci :: [Integer]
fibonacci = 0 : 1 : zipWith (+) fibonacci (tail fibonacci)

getNFibs :: Int -> [Integer]
getNFibs n = take n fibonacci

main :: IO ()
main = do
  print $ getNFibs 10
  -- 输出: [0,1,1,2,3,5,8,13,21,34]

案例研究

1：Facebook 的 Spam Fighting 垃圾信息拦截系统

1：Facebook 的 Spam Fighting 垃圾信息拦截系统

背景:
Facebook（现 Meta）需要处理海量用户生成内容，其中包含大量垃圾信息、钓鱼链接和恶意行为。系统需要极高的实时性和准确性，同时要能快速适应不断变化的攻击手段。

问题:
传统的命令式编程语言（如 C++ 或 PHP）在处理复杂的业务规则时，代码容易变得冗长且难以维护。垃圾信息的特征提取和规则匹配涉及复杂的逻辑组合，容易出现并发错误和难以复现的 Bug。此外，开发人员需要频繁修改规则以应对新的攻击模式，系统的可扩展性和正确性面临挑战。

解决方案:
Facebook 使用 Haskell 开发了其内部的核心垃圾信息拦截系统。利用 Haskell 的强类型系统和纯函数式特性，团队构建了一个基于“抽象语法树（AST）”的规则引擎。Haskell 的类型系统确保了规则在编译时的正确性，而其惰性求值和并行计算特性则极大地提升了处理大规模数据流时的性能。开发团队还利用 Haskell 的 DSL（领域特定语言）能力，让非程序员的安全专家也能通过声明式语言定义拦截规则。

效果:

  • 系统能够实时处理数百万条请求，误报率显著降低。
  • 代码量比之前的 C++ 实现减少了约 10 倍，极大地降低了维护成本。
  • Haskell 的类型安全特性使得团队在重构代码时充满信心，新功能的上线速度大幅加快，有效遏制了垃圾信息的传播。

2：Standard Chartered 渣打银行的金融风险定价引擎

2：Standard Chartered 渣打银行的金融风险定价引擎

背景:
渣打银行需要构建一个用于计算复杂金融衍生品价格的系统。这类系统涉及极高的资金风险，任何计算错误都可能导致巨额损失。同时，金融产品的规则经常因市场变化而调整。

问题:
金融产品的定价模型涉及极其复杂的数学公式和业务逻辑。使用传统的面向对象语言（如 Java）往往会导致“脆弱基类”问题，且难以在代码中直观地表达数学关系。此外，并发处理多个定价请求时，线程安全是主要痛点。测试这些复杂的数学公式也非常困难，边界条件容易遗漏。

解决方案:
渣打银行的架构团队决定使用 Haskell 重写其核心定价引擎。Haskell 的纯函数式特性天然适合数学建模，使得代码看起来几乎与数学公式一致，极大地提高了可读性。团队利用 Haskell 的 Software Transactional Memory (STM) 来处理并发定价请求，无需担心死锁或数据竞争。此外，通过 QuickCheck（Haskell 的属性测试工具），他们能够自动生成数百万个测试用例来验证数学属性的正确性。

效果:

  • 新系统的代码量非常少，且高度模块化，使得银行能够快速推出新的金融产品。
  • 利用 QuickCheck 进行的自动化测试发现了旧系统中遗留的多个边界条件错误。
  • 系统在多核服务器上的性能表现优异，且在多年的运行中保持了极高的稳定性，没有出现过一次因计算逻辑错误导致的资金事故。

3：Tsuru Capital 的高频交易系统

3：Tsuru Capital 的高频交易系统

背景:
Tsuru Capital 是一家日本的量化对冲基金，专注于高频交易（HFT）和套利策略。这类交易对延迟极其敏感，微秒级的差异决定了盈亏。

问题:
高频交易系统不仅要快，还要绝对正确。使用 C++ 等语言虽然能获得极致性能，但内存管理极其复杂，容易出现段错误或内存泄漏，这在实盘交易中是致命的。此外，随着策略逻辑变得复杂，如何在保证性能的同时保持代码的清晰度是一个巨大挑战。

解决方案:
Tsuru Capital 选择使用 Haskell 作为其核心交易系统的开发语言。虽然 Haskell 有高级抽象的负担，但通过精细的内存管理和 GHC 编译器的优化，他们实现了接近 C++ 的运行速度。更重要的是，Haskell 的强类型系统和不可变数据结构消除了 99% 的运行时错误。他们利用 Haskell 进行离线策略回测和在线信号生成，确保了策略逻辑在数学上的严谨性。

效果:

  • Haskell 编写的交易模块在延迟上完全满足了高频交易的要求，且系统稳定性极高，能够连续运行数月无需重启。
  • 开发效率显著提升，研究员可以快速将复杂的数学模型转化为可执行的交易代码，缩短了从策略研发到上线的周期。
  • 函数式编程的“引用透明性”使得调试和性能分析变得异常简单，团队能够迅速定位并优化代码中的热点。

最佳实践

最佳实践指南

实践 1：超越“代理编码”，构建可组合的领域特定语言（DSL）

说明: 文章的核心观点在于反对仅仅将 AI 视为编写命令式代码的“代理”，而是主张利用 Haskell 等强类型语言构建深度的 DSL。通过将业务逻辑编码为类型和函数，开发者可以创建一个高度结构化的环境，在这个环境中，AI（或人类）只需要组装高级别的抽象组件，而不是处理底层的语法细节。

实施步骤:

  1. 识别业务领域中重复出现的逻辑模式。
  2. 使用 Haskell 的代数数据类型（ADT）为这些模式定义类型。
  3. 编写高阶函数或组合子，允许这些类型通过函数组合进行交互。
  4. 确保最终的 DSL 表达式能够直接反映业务需求，而非实现细节。

注意事项: DSL 的设计应遵循“最小完备性”原则，避免过度设计导致抽象层过厚，增加调试难度。

实践 2：利用类型系统作为“智能合约”

说明: 在“Haskell for all”的理念中，类型不仅仅是防止运行时错误的工具，更是代码的文档和约束。通过精细化的类型设计（如 Phantom Types 或 Type-level Programming），可以将非法状态在编译期就排除在外。这使得 AI 辅助编程更加安全，因为 AI 生成的代码如果不符合类型约束，将无法通过编译。

实施步骤:

  1. 使用 newtype 区分相同底层表示但语义不同的数据（例如 UserId 和 GroupId）。
  2. 利用类型状态模式，通过类型限制函数的调用顺序。
  3. 在关键业务逻辑中使用 Sum Types 枚举所有可能的情况，避免使用 null 或异常处理流程。

注意事项: 复杂的类型系统可能会增加初学者的学习曲线，建议在团队内部建立类型设计规范。

实践 3：从“代码生成”转向“逻辑推导”

说明: 传统的 AI 编程助手倾向于生成大量的样板代码。最佳实践应转向让 AI 辅助进行逻辑推导和属性定义。利用 Haskell 的声明式性质，开发者应描述“做什么”，而让编译器或 AI 辅助工具推导“怎么做”。这对应于文章中提到的超越单纯的 Agent 编码，进入更高层次的抽象。

实施步骤:

  1. 优先编写函数的类型签名，作为逻辑的契约。
  2. 使用 QuickCheck 等工具基于属性编写测试，而非基于具体的示例用例。
  3. 让 AI 工具根据类型签名和属性测试生成实现代码，而非手动编写循环和条件判断。

注意事项: 依赖推导需要高质量的类型签名和属性定义作为前提，否则生成的代码可能无法满足实际性能需求。

实践 4：建立“以编译器为中心”的反馈循环

说明: 文章暗示了强类型语言在 AI 时代的优势：编译器提供了即时的、无情的反馈。最佳实践包括将编译器的错误信息作为与 AI 交互的一部分。当 AI 生成代码时，应立即将其放入编译器中验证，利用编译错误来修正 AI 的理解，而不是依赖人工审查代码逻辑。

实施步骤:

  1. 在集成 AI 辅助工具时，确保其能直接访问编译器的错误输出。
  2. 建立“编写类型签名 -> AI 填充实现 -> 编译器报错 -> 修正 AI”的快速迭代循环。
  3. 将 GHC 的警告（如 -Wall）视为错误，强制 AI 生成符合严格标准的代码。

注意事项: 避免盲目接受 AI 为了“消除编译错误”而引入的脏修补（如 undefined 或部分函数），应审查其语义正确性。

实践 5：优先使用纯函数式编程以增强可预测性

说明: 纯函数式代码（无副作用）更容易被 AI 模型理解和预测，因为其输出仅依赖于输入，不存在隐藏的状态变化。这与文章提倡的构建结构化、可验证系统一致。通过最大化代码的纯度，可以降低 AI 生成代码出现意外行为的概率。

实施步骤:

  1. 将核心业务逻辑与副作用（IO、数据库操作）分离。
  2. 使用 Functor、Applicative 和 Monad 等类型类来管理副作用，使其显式化。
  3. 在代码审查中，重点检查纯函数的隔离性，确保 AI 生成的辅助函数不涉及全局状态。

注意事项: 在处理必须与外部世界交互的场景时，合理使用 Monad（如 IO 或 StateT）来封装副作用，不要为了追求纯度而牺牲系统的必要交互能力。

实践 6：投资于可维护的抽象，而非一次性的脚本

说明: “Beyond agentic coding” 意味着我们要构建长期存在的系统。最佳实践是利用 Haskell 的抽象能力（如 Type Classes 和 Lenses）构建易于维护和扩展的代码库。AI 应被用于维护和扩展这些抽象，而不是编写难以维护的“面条代码”。

实施步骤:

  1. 识别代码中的重复模式，并将其抽象为

学习要点

  • Haskell 的类型系统不仅能防止错误，还能通过类型推导自动生成代码（如 deriving），减少重复劳动。
  • 函数式编程的纯函数特性使代码更易测试和推理，因为输出仅依赖输入，无副作用。
  • 惰性求值（lazy evaluation）允许 Haskell 仅在需要时计算值，从而提升性能并支持无限数据结构。
  • 模式匹配（pattern matching）和代数数据类型（ADT）使代码更接近问题域的描述，提高可读性和维护性。
  • Monad 和其他抽象概念虽然学习曲线陡峭，但能优雅地处理副作用（如 I/O）和状态管理。
  • GHC 编译器提供强大的优化和类型检查功能，帮助在编译期发现潜在问题。
  • 函数式编程鼓励组合式设计，通过小函数组合解决复杂问题，提升代码复用性。

常见问题

1: 这篇文章标题中的 “Beyond agentic coding”（超越代理编码）具体指什么？

1: 这篇文章标题中的 “Beyond agentic coding”（超越代理编码）具体指什么？

A: 在这篇文章的语境下，“Beyond agentic coding” 指的是一种超越当前流行的 “AI 代理”（Agentic AI）范式的编程理念。当前的 Agentic Coding 通常指让 AI 模型（如 GPT-4）自主地调用工具、浏览文件或编写代码来解决复杂任务。作者认为，仅仅让 AI 模仿人类程序员的操作行为（即 “Agent”）存在局限性。文章主张应转向更本质的编程方式，即利用形式化方法、纯函数式编程（如 Haskell）以及数学证明来构建软件。这里的 “Beyond” 意味着从依赖不可靠的 “黑盒” 代理行为，转向依赖可验证、可组合且逻辑严密的代码构造，即通过提升语言的抽象级别和数学严谨性来解决问题，而不是单纯依赖 AI 的自主决策能力。

2: 为什么文章特别强调 Haskell，而不是其他函数式编程语言（如 Scala, OCaml 或 F#）？

2: 为什么文章特别强调 Haskell，而不是其他函数式编程语言（如 Scala, OCaml 或 F#）？

A: 文章强调 Haskell 主要是因为其纯粹的函数式编程特性。与其他多范式语言（如 Scala 或 F#）相比，Haskell 强制执行纯度，即没有副作用。这种严格的约束使得代码更容易进行数学推理、测试和形式化验证。在讨论 “Beyond agentic coding” 时，作者认为，只有像 Haskell 这样高度抽象和严格的数学化语言，才能真正解决软件复杂性问题，而不是像 AI Agent 那样通过试错来修补漏洞。Haskell 的类型系统和惰性求值特性使其成为表达高阶抽象和逻辑推理的工具，这符合文章所倡导的构建可靠软件系统的愿景。

3: 这篇文章与 Hacker News 社区的讨论氛围有何关系？

3: 这篇文章与 Hacker News 社区的讨论氛围有何关系？

A: Hacker News (HN) 是一个对编程语言理论、系统架构和 AI 技术关注度较高的社区。这篇文章之所以在 HN 上引起关注，是因为它触及了一个核心争议：在生成式 AI 迅速发展的时代，传统的编程范式（特别是像 Haskell 这样学术性强的语言）是否还有价值？HN 用户通常对 “AI 将取代程序员” 或 “Agentic Workflow 是未来” 等观点持批判或审慎态度。这篇文章提供了一个视角，即通过更严谨的数学和形式化方法（Haskell 的强项）来应对 AI 带来的不确定性，这种观点在 HN 上引发了关于软件工程本质、AI 局限性以及编程语言设计哲学的讨论。

4: 文章中提到的 “Agentic Coding” 的局限性具体是什么？

4: 文章中提到的 “Agentic Coding” 的局限性具体是什么？

A: 根据文章及相关讨论，Agentic Coding 的局限性主要包括以下几点：

  1. 不可预测性：AI Agent 在执行任务时往往通过概率性猜测生成代码，缺乏形式化保证，容易产生难以复现的 Bug。
  2. 调试困难：当 Agent 生成的复杂系统出现问题时，人类很难理解其内部逻辑，因为 Agent 的决策过程往往是不透明的 “黑盒”。
  3. 上下文限制：尽管 Agent 可以浏览文件，但在处理超大规模代码库的深层逻辑依赖时，仍可能丢失上下文，导致逻辑断裂。
  4. 缺乏数学严谨性：Agentic Coding 侧重于 “让它跑起来”，而忽视了软件工程中的正确性证明。文章主张通过数学上的确定性来弥补这一缺陷。

5: 既然 Haskell 有这么多优点，为什么它没有成为主流工业界开发语言？

5: 既然 Haskell 有这么多优点，为什么它没有成为主流工业界开发语言？

A: 这是一个在 Hacker News 讨论中经常出现的问题。主要原因包括：

  1. 学习曲线：Haskell 涉及范畴论、单子等数学概念，对只有面向对象背景的开发者来说门槛较高。
  2. 人才储备：市场上 Haskell 程序员远少于 Python 或 Java 程序员，企业招聘成本高。
  3. 生态系统的成熟度：虽然 Haskell 的库（如 Hackage）较丰富，但在某些特定领域（如移动端开发、某些企业级框架）的支持不如主流语言完善。
  4. 惰性求值的复杂性：虽然惰性求值能带来模块化，但也容易导致难以调试的空间泄漏问题。

6: 这篇文章是否在主张我们应该完全放弃使用 AI 辅助编程？

6: 这篇文章是否在主张我们应该完全放弃使用 AI 辅助编程？

A: 并非完全放弃，而是主张改变使用 AI 的方式和心态。文章的核心观点是 “Beyond”（超越），即不要仅仅满足于让 AI 充当一个会写代码的 “Agent” 或 “Copilot”，而是要探索如何将 AI 的能力与形式化验证、强类型系统相结合。作者可能认为，AI 应该被用来辅助生成符合数学规范的代码，或者帮助进行形式化证明，而不是仅仅作为一个自动化的代码生成器来替代人类的思考。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在传统的命令式编程中，我们经常通过“可变状态”和循环来修改列表。请尝试编写一个简单的 Haskell 函数，将一个整数列表中的每个元素都乘以 2，但严禁使用递归、for 循环或 while 循环。

提示**: 思考 Haskell 标准库中处理列表的高阶函数。你需要找到那个能将一个函数应用到列表中每个元素的函数。

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章