事情发生在一个平平无奇的周二下午，代码审查的会议室里气氛有些微妙。我原本只是想解决一个让人头疼的表单维护问题，提议把那些纠缠不清的业务逻辑抽离到一个独立的 rules.ts 文件中。我以为这只是一个简单的“代码整洁”运动，没想到却引发了一场关于开发哲学的小型辩论。

后端的同事kan了一眼，慢悠悠地说：“这不就是 Business-Driven Development吗？”

另一位前端伙伴则摇了摇头，插嘴道：“我kan这geng像是面向 AI 编程的重构思路。”

而我当时脑子里想的是 Spec-Driven Development。

那一刻，我有点懵。明明是同一个文件，同一行代码，为什么在不同人的眼里折射出了完全不同的光谱？这让我开始重新审视这个kan似简单的 rules.ts 构想。它到底代表了什么？是旧瓶装新酒，还是我们在 AI 时代必须掌握的新生存法则？

混乱的起点：当表单逻辑变成一团乱麻

让我们先回到问题的原点。在 React + TypeScript 的日常开发中，我们经常遇到那种“巨无霸”式的表单组件。场景大概是这样的：一个订单表单，里面躺着十几个字段。每个字段的显示、禁用、必填状态，不仅依赖彼此的值，还受到用户角色、当前流程状态，甚至后端动态配置项的影响。

随着需求像滚雪球一样迭代，这些判断逻辑开始像杂草一样疯长。它们散落在 JSX 的各个角落，有的藏在 disabled 属性里有的埋在 hidden 的判断中，还有的躲在 useEffect 的深处。想改一个逻辑？你得像侦探一样在文件里跳来跳去。想写测试？你得费劲地把整个组件环境搭起来哪怕你只是想验证“购物车为空时不Neng提交”这么个简单的道理。

这种代码，人类读着累，AI 改着geng累。

破局之道：rules.ts 的诞生

我的思路其实hen简单，甚至有点返璞归真：把“判断逻辑”从“执行逻辑”里彻底剥离出来。

于是我创建了这样一个文件：

// env: React + TypeScript
// scene: extract form business rules into a single file
// OrderForm.rules.ts
export type OrderState = {
  items: CartItem;
  address: Address | null;
  userRole: 'guest' | 'member' | 'vip';
  flowStatus: 'draft' | 'pending' | 'submitted';
  isPending: boolean;
};
// 核心问题：当前订单是否允许提交？
export const canSubmitOrder = : boolean => 
  state.items.length> 0 &&
  state.address !== null &&
  !state.isPending &&
  state.flowStatus === 'draft';
// 辅助功Neng：Ru果不允许提交，原因是什么？
export const getSubmitDisabledReason = : string | null => {
  if  return '购物车空空如也';
  if  return '请先填写配送地址';
  if  return '订单Yi处理，无法重复提交';
  return null;
};
// UI 逻辑：是否展示 VIP 专属折扣栏？
export const shouldShowVipDiscount = : boolean => 
  state.userRole === 'vip' && state.items.length> 0;

kan着这几行代码，你可Neng会觉得：“这不就是几个纯函数吗？” 没错，这正是关键所在。这些函数有几个显著的特征：它们是纯函数，没有副作用，完全不依赖 UI 层的任何东西。它们Ke以被独立测试，也Ke以被 AI Copilot 单独修改，完全不用担心会误伤组件的渲染逻辑。

不仅仅是代码：通用语言的落地

这背后其实暗合了 DDD中“通用语言”的理念。什么是通用语言？就是领域专家、产品经理、开发人员，大家用同一套词汇来描述同一件事。

试想一下当产品经理说“Ru果购物车是空的，就要提示用户”，你的代码里正好有一个函数叫 getSubmitDisabledReason，并且返回值里包含了“购物车空空如也”的描述。这种对应关系，就是代码与业务需求的同频共振。

在这个层面上，rules.ts 扮演了一个“翻译官”的角色，它把模糊的业务需求，翻译成了严谨的 TypeScript 逻辑。

哲学视角一：Spec-Driven Development

我Zui初提出这个构想时脑子里想的是 Spec-Driven Development。虽然后来我觉得这个词可Neng不够精准，但它的核心逻辑依然成立。

SDD 强调的是流程先定义“规范是什么”，再让代码去“实现规范”。在 API 开发中，这表现为先写 OpenAPI YAML，再生成代码；在前端组件里rules.ts 就是那份“规范”。

它定义了业务规则的“单一真相来源”。组件不再是规则的制定者，而是规则的消费者。UI 只负责展示，至于“Neng不Neng展示”、“Neng不Neng点击”，全听 rules.ts 的指挥。这种分离，让代码的意图变得异常清晰。

哲学视角二：Business-Driven Development

后端同事提到的“业务驱动”，其实geng侧重于语义和可读性。

这里有一个hen有趣的对比。请kan下面两组命名：

// 面向业务
export const canSubmitOrder = ...
export const shouldShowVipDiscount = ...
export const isAddressRequired = ...
// 面向技术
export const checkFlag = ...
export const validateConditionA = ...
export const controlVisibility = ...

前者使用的是业务动词，哪怕是不懂代码的产品经理，kan一眼函数名也Neng猜出大概意思。后者则是典型的技术，Ru果不深入阅读代码逻辑，没人知道 validateConditionA 到底是在验证什么。

在 rules.ts 的世界里我们强制自己使用业务词汇。这不仅仅是为了好记，geng是为了让代码成为业务文档的一部分。当业务规则发生变化时我们Neng迅速定位到对应的业务函数，而不是在一堆 if 的逻辑里大海捞针。

哲学视角三：AI-First Architecture

这可Neng是Zui让我兴奋，也是Zui具时代特征的一个视角。另一位前端同学说的“面向 AI 编程的重构”，一语道破了这种模式在当下的特殊价值。

我们要承认一个现实：AI Copilot Yi经成为了我们日常开发的协作者。但是AI 并不是全知全Neng的。在一个 500 行的巨型组件文件里混杂着 UI 结构、样式逻辑、副作用和业务判断，AI 想要精准地修改某一条业务规则，难度堪比大海捞针。它hen容易“误伤”其他逻辑，或者生成出kan似正确实则跑不通的代码。

但是Ru果你把逻辑抽离到一个只有 50 行的 rules.ts 文件里呢？情况就完全不同了。

这个文件里只有纯函数和类型定义，没有 JSX 的干扰，没有副作用的牵绊。AI 一眼就Neng理解意图，修改起来精准且可预测。从这个角度kan，rules.ts 实际上是为 AI 协作创造了一个“安全操作区”。

我们Ke以把目录结构设计成这样：

OrderForm/
  index.tsx           ← UI 结构，调用规则，不包含复杂逻辑
  OrderForm.rules.ts  ← 纯业务规则，AI 的安全操作区
  OrderForm.test.ts   ← 只测试规则，无需挂载组件
  OrderForm.types.ts  ← 共享类型定义

这种结构以前这种轻量级、高内聚的规则文件的价值被重新放大了。它不只是为了人类维护，geng是为了让 AI Neng像外科医生一样精准地操作业务逻辑。

实践中的权衡与思考

当然rules.ts 并不是银弹，它不Neng解决所有问题。在实际落地时我也产生了一些新的疑问，目前还没有标准答案。

比如随着业务越来越复杂，rules.ts 会不会变得臃肿？当函数数量增多时我们是否应该按业务子域继续拆分？比如变成 OrderForm.submit.rules.ts 和 OrderForm.display.rules.ts？这又涉及到粒度的把控问题。

此外什么样的逻辑适合放进去，什么样的不适合？这也是个需要经验判断的活儿。

适合放进 rules.ts 的：

基于状态的布尔判断。

纯数据的转换和计算。

复杂的表单验证逻辑。

不太适合放进去的：

涉及 DOM 操作的副作用。

复杂的 UI 动画控制。

与特定 UI 库强耦合的状态管理。

殊途同归：多维度的统一

回头kan那次 CR 的对话，三位同学说的其实dou有道理，只是各自站在了不同的维度上。

Spec-Driven、Business-Driven、AI-First，这三个标签并不是互斥的选择，它们描述的是同一个设计决策在不同语境下的意义。

SDD 关注的是流程：先定义，后实现。

BDD 关注的是语义：代码要像业务文档一样可读。

AI-First 关注的是工具链适配：代码结构要适合 AI 理解和修改。

而 rules.ts 恰好处于这三者的交汇点上。它既是一份规范，也是一种业务语言，geng是一个 AI 友好的接口。

未来的代码组织

这次关于 rules.ts 的讨论，让我开始思考一个geng深层的问题：我们在Zuo代码组织决策的时候，“对 AI 是否友好”，会不会慢慢变成和“可读性”、“可测试性”同等重要的考量维度？

以前我们写代码是为了让机器执行，让同事kan懂。现在我们多了一个“读者”——AI。为了让这个协作者发挥Zui大的效Neng，我们可Neng需要调整传统的工程实践。

把业务规则从组件里抽出来这件事本身并不新鲜；但这种结构的价值被重新放大了。它既是给人类读者的清晰表达，也是给 AI 工具的精准操作界面。

所以下次当你面对一个逻辑复杂的表单组件时不妨试试创建一个 rules.ts。这不只是为了代码整洁，geng是保持代码的“可理解性”和“可操控性”，或许才是我们Zui大的底气。

---