第二章 对方一阶争叫后的转移应叫

2.1.1. 1c.gif (113 bytes)开叫遭遇自然性的1d.gif (109 bytes)争叫

假设叫牌以如下方式开始:

使用转移应叫,应叫者有如下选项:
加倍 - 转移到h.gif (112 bytes)
1h.gif (112 bytes) - 转移到s.gif (111 bytes)
1s.gif (111 bytes) - 转移到c.gif (113 bytes)或NT
1NT - 自然叫,我希望由自己来主打无将定约
2c.gif (113 bytes) - 转移到对方的花色,表示没有4张高花的进局逼叫
2d.gif (109 bytes) - 转移到h.gif (112 bytes),6+以上套,弱牌或逼局实力
2h.gif (112 bytes) - 转移到s.gif (111 bytes),6+以上套,弱牌或逼局实力
2s.gif (111 bytes) - 转移到c.gif (113 bytes),6+以上套,弱牌或逼局实力
2NT - 邀局,我希望由自己来主打无将定约
3c.gif (113 bytes) - 6+c.gif (113 bytes),邀局
3d.gif (109 bytes) - 6+h.gif (112 bytes),转移式邀局
3h.gif (112 bytes) - 6+s.gif (111 bytes),转移式邀局
3s.gif (111 bytes) - 转移到3NT,6+c.gif (113 bytes),询问同伴有无d.gif (109 bytes)止张

上述设计的原则之一是不把NT用作转移叫,因为由此导致的庄位错误实在是太常见了。在对手的1d.gif (109 bytes)争叫后,1阶上的转移叫是无上限的。2阶上的转移叫既可以是强牌也可以是弱牌,根据应叫者此后的行动即可轻易确认。我们对2阶转移叫强弱的定义是:

  • 弱牌:低于邀请实力,至少6张转移花色

  • 强牌:逼局实力,至少6张转移花色

通常只有单套牌才在2阶上进行转移应叫。

同伴坐西开叫1c.gif (113 bytes),北家对方争叫1d.gif (109 bytes)后,你持下面几手牌如何应叫?

   
2d.gif (109 bytes):转移到h.gif (112 bytes)。同伴接受转移后,我们pass。   2d.gif (109 bytes):转移到h.gif (112 bytes)。同伴接受转移后,我们扣叫3d.gif (109 bytes)显示这手牌的无将特征。   2h.gif (112 bytes):转移到2s.gif (111 bytes)。同伴接受转移后,我们叫4d.gif (109 bytes)——自动爆裂叫(自然应叫体系不可能有的叫品)。
2h.gif (112 bytes):转移到s.gif (111 bytes)。同伴接受转移后,我们pass。   2s.gif (111 bytes):转移到c.gif (113 bytes)。如果同伴应以逼叫性的2NT,则再叫3s.gif (111 bytes)显示单缺。   2s.gif (111 bytes):转移到c.gif (113 bytes)。同伴3c.gif (113 bytes)接受转移后,3d.gif (109 bytes)询问止张,或3s.gif (111 bytes)显示价值所在,取决于同伴间的具体协议。

如果我们持有一个5张套花色和逼局实力怎么办?

很简单,我们先在1阶上做转移应叫,然后再扣叫对方争叫花色就能显示我们的意图。


开叫者该如何应对同伴的转移应叫呢?

如果他持一手在应叫者做了非逼叫性应叫后通常会pass的牌,那么他就应该简单接受转移。

序列1
1h.gif (112 bytes) - 3张h.gif (112 bytes),绝对是一手倾向于花色定约的牌
2d.gif (109 bytes) - 等待叫,逼局
2h.gif (112 bytes) - 12-14大牌点,4张h.gif (112 bytes)支持
其它叫品 - 取决于同伴间协议

和应叫自然性的1h.gif (112 bytes)相比,我们得到了一个额外的叫品来显示3张h.gif (112 bytes)支持及一手倾向于花色定约的牌。

牌例

转移应叫后跟随的是一个超级自然的进程。开叫者的描述使得东家找到了最佳定约。

序列2
2h.gif (112 bytes) - 3张h.gif (112 bytes)支持,均型
其它叫品 - 取决于同伴间协议

在开叫者再叫1NT后,应叫者可以使用一些非常流行的标准约定叫。比如他可以叫2c.gif (113 bytes)双路重询,或如上所示扣叫对方争叫花色等待。

序列3
1s.gif (111 bytes) - 3张s.gif (111 bytes)支持,不愿意自己叫出无将
2d.gif (109 bytes) - 等待叫,逼局
2s.gif (111 bytes) - 12-14大牌点,4张s.gif (111 bytes)支持
其它叫品 - 取决于同伴间协议
 
序列4

后续叫牌取决于搭档间的协议。开叫者最常见的再叫是1NT,即使他并没有d.gif (109 bytes)止张。

序列5
2c.gif (113 bytes) - 止叫
2d.gif (109 bytes) - 询问止张,同伴的1NT并不保证d.gif (109 bytes)止张
2h.gif (112 bytes) - c.gif (113 bytes)套+h.gif (112 bytes)价值
2s.gif (111 bytes) - c.gif (113 bytes)套+s.gif (111 bytes)价值
2NT - 邀叫
3c.gif (113 bytes) - 邀局,但是c.gif (113 bytes)套非常之弱,因为持c.gif (113 bytes)好套时可以直接跳叫3c.gif (113 bytes)邀请
3d.gif (109 bytes)/h.gif (112 bytes)/s.gif (111 bytes) - c.gif (113 bytes)为将牌的自动爆裂叫
 
牌例

应叫者的2h.gif (112 bytes)表示价值所在。拿着如此强大的一手牌,我们可以撕去伪装而直接核对有无s.gif (111 bytes)止张。开叫者再叫3h.gif (112 bytes)表示4张h.gif (112 bytes),同时担心联手的s.gif (111 bytes)情况。应叫者4h.gif (112 bytes)建议最终定约。

序列6

2c.gif (113 bytes)转移到对方争叫花色,表示进局逼叫,同时没有4张高花。这个设计的目的在于如果最终定约是无将的话,我们可以让正确的一方来主打。本章稍后我们将讨论这个思路的细节。


 下面我们来看看2阶转移应叫的后续发展。

序列7
2h.gif (112 bytes) - 如果你的牌是6-9大牌点,6张h.gif (112 bytes)的话,我建议以此为最后定约
3h.gif (112 bytes) - 邀局,通常非强牌
2s.gif (111 bytes) - 5+c.gif (113 bytes)和4s.gif (111 bytes),18+大牌点的逆叫
2NT - 等待叫,逼叫,询问同伴的牌力和牌型。至少18+大牌点
3c.gif (113 bytes) - 自然叫,不逼叫(但如果你打精确,1c.gif (113 bytes)表示16+大牌点,则3c.gif (113 bytes)也是逼叫的)
3d.gif (109 bytes) - 等待叫,d.gif (109 bytes)没有止张——可能是c.gif (113 bytes)单套强牌,又或者是无将类型的强牌
其他叫品 - 取决于同伴间协议

为什么这里的2NT是逼叫?因为我们需要一个经济的等待叫;扣叫对方争叫花色(3d.gif (109 bytes))可能会把定约推得过高了。

牌例

开叫者2NT再叫表示18+大牌点。应叫者3d.gif (109 bytes)再次转移是示弱,低限,没有满贯兴趣。但开叫者的牌太强了,因此他没有简单封局而再叫3h.gif (112 bytes)等待,强迫同伴扣叫。应叫者3s.gif (111 bytes)扣叫显示单缺,接着双方几个扣叫后,开叫者4NT是罗马关键张问叫,应叫者答叫一个关键张,开叫者冲上6h.gif (112 bytes)定约。

开叫者接受转移后的发展

序列8
Pass - 所有7-9点的牌。注意应叫者如果是10-12点的邀请实力,第一轮应叫时应该直接跳叫3d.gif (109 bytes)转移式邀局
2s.gif (111 bytes) - 等待叫,s.gif (111 bytes)上有大牌
2NT - 自然叫,6张h.gif (112 bytes)的6322牌型
3c.gif (113 bytes) - 等待叫,c.gif (113 bytes)上有大牌
3d.gif (109 bytes) - 询问同伴有无d.gif (109 bytes)止张
3h.gif (112 bytes) - 没有单缺,邀请同伴扣叫
3s.gif (111 bytes) - s.gif (111 bytes)单缺的自动爆裂叫
3NT - 表达愿意由自己来主打无将定约的强烈愿望
4c.gif (113 bytes) - c.gif (113 bytes)单缺的自动爆裂叫
4d.gif (109 bytes) - d.gif (109 bytes)单缺的自动爆裂叫

除了Pass以外的所有再叫都显示13+大牌点和至少6张h.gif (112 bytes)。所有的自动爆裂叫都表示持有h.gif (112 bytes)坚固套。

牌例

虽然开叫者的牌力在12-14这个区间,但他的牌却有很大的额外价值——非常好的顶张大牌(5个关键张占了3个)和这些大牌的位置。在我看来,对这手牌的评估在0-10分制里可打9分,因此满贯定约是势在必得的。为什么开叫者不使用黑木问叫呢?原因在于应叫者知道开叫者所有的牌,他才应该是叫牌的主导者。在一系列扣叫过后,他可以使用5NT黑木约定叫来核实关键张数目,开叫者将报出自己的3个关键张。应叫者已经知道开叫者在c.gif (113 bytes)上有额外实力,因为他扣叫了这个花色两次。不叫大满贯的唯一原因是应叫者无法确定开叫者是否有4张c.gif (113 bytes)

序列9

这个序列的后续设计并非很容易。在2d.gif (109 bytes)并不总是进局逼叫的情况下,应叫者必须小心翼翼地3阶描述他的牌。而且我们还要有一个有效的机制,使得应叫者持弱牌(7-9大牌点,6+h.gif (112 bytes))时也能进行满贯试探。下面是我们的方法:

3c.gif (113 bytes) - 7-9大牌点,愿意与同伴探讨满贯的可能性
3d.gif (109 bytes) - 7-9大牌点,没有满贯兴趣(重复转移)
3h.gif (112 bytes) - 6+h.gif (112 bytes),13+大牌点,倾向于花色定约的牌
3s.gif (111 bytes) - s.gif (111 bytes)单缺的自动爆裂叫,13+大牌点
3NT - 6张h.gif (112 bytes)的6322牌型,倾向于无将定约的牌
4c.gif (113 bytes) - c.gif (113 bytes)单缺的自动爆裂叫,13+大牌点
4d.gif (109 bytes) - d.gif (109 bytes)单缺的自动爆裂叫,13+大牌点

在这个序列里我们采用了“伪装”原则:持弱牌时应叫者并不立刻披露自己的牌型。然而如果开叫者仍然坚持要知道这个信息,他可以在3阶上接受转移,强迫应叫者进行描述。通常开叫者再叫2NT时,应叫者的牌力绝大多数情况下都在7-9的范围内,因此把3c.gif (113 bytes)/3d.gif (109 bytes)这两个经济型的叫品设计成如上所述是合理的。

同时我们也要意识到所有其他的应叫都显示13+大牌点,这样联手已至少有31大牌点,无论如何都要探索满贯的可能性。

序列10
3NT - 没有单缺
4c.gif (113 bytes) - c.gif (113 bytes)单缺
4d.gif (109 bytes) - d.gif (109 bytes)单缺
4h.gif (112 bytes) - s.gif (111 bytes)单缺,没有额外价值
4s.gif (111 bytes) - s.gif (111 bytes)单缺,有额外价值

3s.gif (111 bytes)是等待叫,开叫者对局势已全盘掌控。额外价值可以是如下三种中的一种:

A)大牌实力,在这个序列里表示15+大牌点。
B)形状特征,有缺门。
C)将牌有额外长度,7+h.gif (112 bytes)

序列11
3s.gif (111 bytes) - s.gif (111 bytes)单缺
3NT - 没有单缺
4c.gif (113 bytes) - c.gif (113 bytes)单缺
4d.gif (109 bytes) - d.gif (109 bytes)单缺
4h.gif (112 bytes) - 我不愿意显示有无单缺

我们对上述答叫结构已经非常熟悉了。

在应叫者2d.gif (109 bytes)转移应叫后,如果开叫者再叫3d.gif (109 bytes)等待,通常表示d.gif (109 bytes)无止张(或半止张),对同伴h.gif (112 bytes)无支持的强牌,我们该如何应对呢?开叫者的持牌可能是:

应叫者此时面对的是两个互相之间有一定冲突的叫牌意图:

1)有d.gif (109 bytes)止张就叫3NT
2)让我们选择一个更好的成局定约

同样的问题在开叫者的3c.gif (113 bytes)再叫是逼叫的时候也存在。

3d.gif (109 bytes)再叫是命令性的——如果你有d.gif (109 bytes)止张——就叫无将。

3c.gif (113 bytes)则是合作性的,双方可以协商来选择一个最好的成局定约。

序列12
3h.gif (112 bytes) - 7-9大牌点,没什么特别值得显示的
3s.gif (111 bytes) - 等待叫,通常是13+大牌点,持逼局实力做的2阶转移
3NT - 我有d.gif (109 bytes)止张
4c.gif (113 bytes) - c.gif (113 bytes)配合
4d.gif (109 bytes) - 扣叫,通常是单缺
4h.gif (112 bytes) - 我想打h.gif (112 bytes)成局定约,7-9大牌点
 
序列13
3NT - d.gif (109 bytes)半止张
4c.gif (113 bytes) - 自然叫,逼叫
 
序列14
2s.gif (111 bytes) - 如果同伴是弱牌,就打2s.gif (111 bytes)定约
2NT - 等待叫,逼叫,询问同伴的牌力和牌型。至少18+大牌点
3c.gif (113 bytes) - 自然叫,不逼叫(但如果你打精确,1c.gif (113 bytes)表示16+大牌点,则3c.gif (113 bytes)也是逼叫的)
3d.gif (109 bytes) - 等待叫,询问d.gif (109 bytes)止张
3h.gif (112 bytes) - 5+c.gif (113 bytes)和4h.gif (112 bytes),18+大牌点的逆叫
3s.gif (111 bytes) - 邀局,通常非强牌
4c.gif (113 bytes)/d.gif (109 bytes)/h.gif (112 bytes) - 所叫花色单缺的爆裂叫
 
序列15
3c.gif (113 bytes) - 7-9大牌点,愿意与同伴探讨满贯的可能性
3d.gif (109 bytes) - 6+s.gif (111 bytes),13+大牌点
3h.gif (112 bytes) - 7-9大牌点,没有满贯兴趣(重复转移)
3s.gif (111 bytes) - 13+大牌点,没有单缺,我愿意由自己来主打s.gif (111 bytes)定约
3NT - 6张s.gif (111 bytes)的6322牌型,倾向于无将定约的牌
4c.gif (113 bytes) - c.gif (113 bytes)单缺的自动爆裂叫,13+大牌点
4d.gif (109 bytes) - d.gif (109 bytes)单缺的自动爆裂叫,13+大牌点
4h.gif (112 bytes) - h.gif (112 bytes)单缺的自动爆裂叫,13+大牌点

非常困难的序列设计,但符合我的一贯叫牌理念;这是每个严肃的搭档关系都需要的重要机制来有效地探索满贯。

牌例
 
序列16
2NT - 等待叫
3c.gif (113 bytes) - 如果同伴是7-9大牌点,就打3c.gif (113 bytes)定约
3d.gif (109 bytes) - 等待叫,询问同伴有无d.gif (109 bytes)止张,通常是18+大牌点和均型牌
 
序列17
3c.gif (113 bytes) - 13+大牌点,6+c.gif (113 bytes)
3d.gif (109 bytes) - d.gif (109 bytes)单缺,7-9大牌点
3h.gif (112 bytes) - h.gif (112 bytes)单缺,7-9大牌点
3s.gif (111 bytes) - s.gif (111 bytes)单缺,7-9大牌点
3NT - 没有单缺,7-9大牌点

我们的首要任务是在应叫者持7-9点的弱牌时选择最佳的成局定约。

当应叫者持强牌时,我们也无需过分担心越过3NT定约。当然在应叫者再叫3c.gif (113 bytes)显示强牌后,开叫者的3d.gif (109 bytes)仍然是等待叫,要求应叫者进一步描述。

牌例
 
序列18
3h.gif (112 bytes) - h.gif (112 bytes)单缺
3s.gif (111 bytes) - s.gif (111 bytes)单缺
3NT - 没有单缺,确切的6张c.gif (113 bytes),逼叫(联手已至少有31大牌点)
4c.gif (113 bytes) - d.gif (109 bytes)单张
4d.gif (109 bytes) - d.gif (109 bytes)缺门

 

序列19
3d.gif (109 bytes) - 询问有无d.gif (109 bytes)止张
3h.gif (112 bytes) - h.gif (112 bytes)单缺
3s.gif (111 bytes) - s.gif (111 bytes)单缺
3NT - 建议最终定约
 
牌例

注意这里的4NT是排除性罗马关键张问叫,因为应叫者此前的4d.gif (109 bytes)已经显示过d.gif (109 bytes)缺门,因此开叫者不能把d.gif (109 bytes)A算成关键张。

点击这里 来做一个简单的叫牌测验。

版权所有©小肖的桥牌世界