CRC卡片建模通过用例驱动的结构化协作推演职责，每张卡片聚焦一个类的名称、职责（知道什么/做什么）及协作类，双向对齐消息传递链条，并借助团队物理摆卡“角色扮演”暴露设计漏洞。
对象职责划分不是靠经验拍脑袋，而是通过结构化协作推演出来的。CRC卡片建模的核心价值，就在于把模糊的“这个类该做什么”转化成可讨论、可移动、可验证的具体卡片动作。
一张卡片只表达一个类的完整视角
每张3×5英寸索引卡顶部写类名，比如Order；左侧列出它“知道什么”和“必须做什么”，例如“保存订单号、创建时间、状态”“校验库存是否充足”；右侧只写它明确需要交互的类名，如Customer、Inventory。背面可补充关键约束，比如“订单创建后不可修改客户ID”。不堆砌细节，不写实现逻辑，只聚焦“谁负责什么”和“找谁帮忙”。
职责必须来自用例场景，不能脱离上下文
拿到一个用例（比如“客户提交新订单”），就从头到尾走一遍事件流：
- 第一步是谁触发？通常是控制器类或UI类，先建一张OrderController卡，责任写“接收提交请求、协调订单创建流程”
- 它下一步要调谁？发现需要查客户信息 → 在Customer卡右栏加上OrderController，左栏补上“返回客户等级与信用额度”
- 接着要扣库存 → 把Inventory拉进来，给它加责任“检查指定商品剩余量”“执行预占库存”
职责不是静态定义的，而是在消息传递链条中自然浮现的。没有用例驱动的职责，大概率是多余或错位的。
协作关系要双向对齐，避免单向依赖幻觉
看到Order卡右边写了Payment，立刻翻到Payment卡：它的左边有没有对应的责任？比如“根据订单金额发起支付”“返回支付结果码”。如果Payment卡上没这项责任，说明协作断了——要么Order不该找它，要么Payment职责没写全。真正的协作是双方都“认账”的，不是A单方面觉得B该干啥。
团队一起摆卡片，比写文档更能暴露设计漏洞
把所有CRC卡摊在桌面上，让业务人员、分析师、开发者围坐一圈，按用例脚本“角色扮演”：
- 一人拿OrderController卡，念：“我要创建订单，先问Customer要信用额度”
- 另一人立刻举起Customer卡：“我有这个责任，返回额度是20000”
- 再问：“那我怎么告诉Inventory扣哪几件？”——如果没人能马上举起卡并读出对应责任，就卡住了
这种物理互动会快速暴露缺失类、职责错配、循环依赖等问题，比画完UML再评审高效得多。
