为了让 AI 写代码更稳，我们真要忍受更难学的库吗

团队推进 AI 编程时，最棘手的通常不是 AI 写不出代码，而是它写出的代码看起来没什么问题，真正运行后却处处是坑。这也带来了一个有些反常的问题：有些库对人类开发者来说学习曲线极其陡峭，AI 却非常擅长调用。如果一个库能让 Claude Code 或 Kiro 更可靠地完成调用，即使它会让开发者更痛苦，项目选型时是否也应该优先考虑它？

Effect 正是这一逻辑最明显的例子。它号称是 AI 时代的可靠 TypeScript 方案。传统异步函数通常拥有明确的成功类型，失败行为却可能只写在注释里，或者需要开发者依赖经验，也就是 Tribal Knowledge 去猜。Effect 则把错误直接放进了类型通道。

比如，一个项目定义了多种错误类型：

import { Data, Effect } from 'effect'

export class NotFoundError extends Data.TaggedError('NotFoundError') {}
export class RateLimitError extends Data.TaggedError('RateLimitError') {}
export class NetworkError extends Data.TaggedError('NetworkError') {}

接下来编写加载用户信息的函数时，Effect 会强制开发者处理这些错误：

export const loadProfile = (scenario: Scenario) =>
 Effect.gen(function* () {
 if (scenario === 'not-found') {
   return yield* new NotFoundError({ handle: 'agent-editor' })
 }
 if (scenario === 'rate-limited') {
   return yield* new RateLimitError({ retryAfterSeconds: 30 })
 }
 if (scenario === 'offline') {
   return yield* new NetworkError({ reason: 'The demo API is offline.' })
 }
 return profile
 })

类型检查如何自动捕获 AI 遗漏的分支

这里最关键的地方在于，假设 AI 在后端逻辑中偷偷加入了 MaintenanceError，却没有同步修改前端，assertNever 这样的类型检查便会在编译阶段直接找出这个漏洞。

这个闭环让 AI 的输出变得极其确定，但相应的代价是：如果团队成员不熟悉函数式编程，看到这类代码可能会感到完全无法理解。

样式管理如何避免 AI 混淆全局选择器

样式管理中也有类似情况，比如 StyleX。传统的 CSS 全局选择器很容易让 AI 混淆，常见的问题就是修改了 A 页面，结果 B 页面的样式也跟着出问题。StyleX 将样式定义在一个具备强类型的 JS API 后面：

const styles = stylex.create({
  result: {
    borderRadius: '8px',
    padding: '16px',
  },
})

有了类型约束，AI 编写样式时不再靠猜测类名，而是像调用接口一样调用样式。大部分低级错误都会在编译阶段被拦截，不必等页面真正渲染后才发现问题。

AI 效率提升是否带来了认知壁垒

但在公司内部推行这类方案时，我发现了另一个矛盾：AI 的确提升了开发效率，同时也在技术栈周围筑起了一道“认知墙”。目前，AI 对这套技术栈的理解程度可能已经超过负责维护它的开发者。如果某天 AI 不在身边，或者生成的代码中出现了一个极其隐蔽的逻辑 Bug，人类维护者或许需要花费三倍的时间，才能读懂这段代码的作用。

未来的趋势可能是，团队会为了“AI 可维护性”牺牲一部分“人类可读性”。如果一个库能为 AI 提供更加精准的信号，例如强类型错误通道和确定的 API 边界，那么即使开发者需要花一个月阅读文档，面对公司的规模化交付，这种交换依然划算。相比让用户从生产环境中反馈 Bug，能够在编译阶段就被拦截的错误，成本要低得多。