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

2.1.3. 1c.gif (113 bytes)开叫遭遇自然性的1s.gif (111 bytes)争叫

坦率地说,在我方开叫1c.gif (113 bytes)或1d.gif (109 bytes)并遭遇对方的1s.gif (111 bytes)争叫后,应叫者持c.gif (113 bytes)套时的转移叫结构会有一些问题。我们的对策是把邀请性3c.gif (113 bytes)的长度放宽为5张以上,以解决这个困难。

而反过来说,我们可以更舒服地处理7-9大牌点,6+h.gif (112 bytes)的牌——使用2d.gif (109 bytes)转移叫。

使用转移应叫,应叫者有如下选项:
加倍 - 否定性加倍,原则上承诺4张h.gif (112 bytes)
1NT - 自然叫,我希望由自己来主打无将定约
2c.gif (113 bytes) - 转移到d.gif (109 bytes)
2d.gif (109 bytes) - 转移到h.gif (112 bytes)
2h.gif (112 bytes) - 转移到对方争叫花色,进局逼叫,没有4张h.gif (112 bytes),可能包括5张c.gif (113 bytes)的5332均型
2s.gif (111 bytes) - 转移到c.gif (113 bytes)
2NT - 邀局,我希望由自己来主打无将定约
3c.gif (113 bytes) - 5+c.gif (113 bytes),邀局
3d.gif (109 bytes) - 6+d.gif (109 bytes),邀局
3h.gif (112 bytes) - 6+h.gif (112 bytes),邀局
3s.gif (111 bytes) - 转移到3NT,持坚固低花套,询问同伴有无s.gif (111 bytes)止张

在1s.gif (111 bytes)争叫后,由于叫牌空间的缺乏,局势变得有点复杂。

承诺4张h.gif (112 bytes)的否定性加倍仍然是非常有效的约定叫,不能因为要设计转移叫结构而舍弃掉。在这种情况下,2阶上的花色转移都不得不包含3种持牌类型:

-6+转移花色,弱牌
-5+转移花色,邀请实力
-5+转移花色,逼局实力

开叫者总是先假定同伴的转移叫是第一种类型的弱牌。

我们没有空间来实现转移式邀叫。所有的3阶邀请都是自然性的。

序列1
2d.gif (109 bytes) - 如果你的牌是7-9大牌点,6+d.gif (109 bytes)(或坚固5张套),我建议以2d.gif (109 bytes)作为最终定约
2h.gif (112 bytes) - 5+c.gif (113 bytes)和4张h.gif (112 bytes)的逆叫实力
2s.gif (111 bytes) - 等待叫,逼局,询问s.gif (111 bytes)有无止张
2NT - 等待叫,逼局,通常是均型牌
3c.gif (113 bytes) - 6+c.gif (113 bytes)(如果1c.gif (113 bytes)是精确16+则为逼叫)
3d.gif (109 bytes) - d.gif (109 bytes)有配合,12-14大牌点,但大牌质量不错
3h.gif (112 bytes) - h.gif (112 bytes)单缺的爆裂叫
3s.gif (111 bytes) - s.gif (111 bytes)单缺的爆裂叫
 
牌例

3s.gif (111 bytes)的含义这里需要着重说明一下。开叫者一般首先将这个叫品处理成询问s.gif (111 bytes)止张,寻求无将定约。应叫者的牌可能是s.gif (111 bytes)108 h.gif (112 bytes)KQ10 d.gif (109 bytes)KQJ84 c.gif (113 bytes)432,对3NT定约有兴趣。

在开叫者叫出3NT后,应叫者的4c.gif (113 bytes)是扣叫,c.gif (113 bytes)QJ足以弥补在同伴主套花色中缺少A或K。同时这个叫品也解释了此前的3s.gif (111 bytes)叫品是扣叫,而非询问止张。

序列2
2h.gif (112 bytes) - h.gif (112 bytes)价值,逼叫一轮。上一轮转移到d.gif (109 bytes)已经否认了持有4张h.gif (112 bytes)
2s.gif (111 bytes) - 等待叫,逼局,询问s.gif (111 bytes)有无止张
2NT - 邀请实力
3c.gif (113 bytes) - 5+d.gif (109 bytes),4+c.gif (113 bytes),逼局
3d.gif (109 bytes) - 邀请
3h.gif (112 bytes) - h.gif (112 bytes)单缺的自动爆裂叫
3s.gif (111 bytes) - s.gif (111 bytes)单缺的自动爆裂叫
 
牌例

(这里不明白为什么Martens把3s.gif (111 bytes)处理为显示c.gif (113 bytes)单缺——小肖译注)

绝大多数理论家们都把4c.gif (113 bytes)处理为显示A的扣叫。但我却是下面这个自洽概念的强烈奉行者:

1) 加叫一个倾向于花色定约的问叫显示单缺
2)加叫一个单缺花色表明在这个花色上没有浪费点力

在这副牌里4c.gif (113 bytes)是一个精彩绝伦的呼应同伴满贯兴趣的叫品,但我同时也承认,东需要极佳的纪律性才能叫出6d.gif (109 bytes),因为摆在他面前的是一个非常困难的智力问题。可以肯定的一点是,开叫者必须有很多控制才能用这个叫品来表达对满贯的渴望。如果他的牌是1个A,2个K和3个J的话,则4c.gif (113 bytes)是不合理的。

例如西的牌是:s.gif (111 bytes)AJ6 h.gif (112 bytes)KJ109 d.gif (109 bytes)KJ c.gif (113 bytes)9843,他只能在3s.gif (111 bytes)后再叫4d.gif (109 bytes),但我们真能对同伴保持高度信任么?

在开叫者的4c.gif (113 bytes)后,应叫者使用关键张问叫也不能完全解决问题——开叫者答叫5h.gif (112 bytes)(5个关键张中的2个)有可能把定约推得过高。扣叫也许能提供某种解决方案。

4h.gif (112 bytes)扣叫否认了c.gif (113 bytes)缺门(为什么?——小肖注)。因此接下来的5c.gif (113 bytes)是一个纯粹的功能性叫品。

序列3

2d.gif (109 bytes)转移到h.gif (112 bytes)是个非常重要的序列,但原则上和2c.gif (113 bytes)转移到d.gif (109 bytes)这个序列并没有什么不同。

同时我们也要注意,否定性加倍是一个额外的选择。

在同伴转移到h.gif (112 bytes)后,开叫者持12-14大牌点的均型牌时必须再叫2h.gif (112 bytes)(当然配合好时也可以3h.gif (112 bytes)邀请)。这一结论是非常明显的。在应叫者持7-10大牌点时,2阶转移叫保证6张h.gif (112 bytes)

由此得出的推论是,应叫者持7-10大牌点但只有5张h.gif (112 bytes)时应该从加倍起步。这样给同伴提供了一个无将定约的选择。

牌例

这是个很差的定约。使用转移叫在这里是个不当的选择。

让我们试试另一种方法。

2h.gif (112 bytes)表示5张h.gif (112 bytes),建议最终定约。开叫者更渴望由自己来主打无将定约,将定约改成了2NT。这才是正确的叫牌方式。当然应叫者也可以简单放过1NT。

2h.gif (112 bytes) - 如果同伴是7-10大牌点的弱牌,我愿意打2h.gif (112 bytes)定约
2s.gif (111 bytes) - 等待叫,倾向于花色定约的一手牌
2NT - 18+大牌点,等待叫——仍然是倾向于花色定约的牌
3c.gif (113 bytes) - 自然叫
3d.gif (109 bytes) - 5+c.gif (113 bytes),4d.gif (109 bytes)的逆叫实力,逼局
3h.gif (112 bytes) - 邀请实力
3s.gif (111 bytes) - s.gif (111 bytes)单缺的爆裂叫
4d.gif (109 bytes) - d.gif (109 bytes)单缺的爆裂叫
 
牌例
 
序列4
Pass - 没什么特别的
2s.gif (111 bytes) - 等待叫,逼局
2NT - 邀请实力,h.gif (112 bytes)套的均型牌
3c.gif (113 bytes) - 自然叫,逼局
3d.gif (109 bytes) - 自然叫,逼局
3h.gif (112 bytes) - h.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)单缺的自动爆裂叫
 
牌例

非常典型的邀请序列。

序列5
3c.gif (113 bytes) - 自然叫
3d.gif (109 bytes) - 自然叫
3h.gif (112 bytes) - 自然叫,6+h.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)单缺的自动爆裂叫

在开叫者显示强牌的2NT后的理想设计应该包括显示6+h.gif (112 bytes)的重复转移。

然而我们没有足够的叫牌空间来达成这一目的。因此3c.gif (113 bytes)/3d.gif (109 bytes)/3h.gif (112 bytes)都只能表示自然叫。

序列6
2NT - 18+大牌点,等待
3c.gif (113 bytes) - 12-14大牌点
3d.gif (109 bytes) - 5+c.gif (113 bytes),4d.gif (109 bytes)的逆叫实力,逼局
3h.gif (112 bytes) - 5+c.gif (113 bytes),4h.gif (112 bytes)的逆叫实力,逼局
3s.gif (111 bytes) - 询问s.gif (111 bytes)止张
4c.gif (113 bytes) - 对同伴c.gif (113 bytes)的强加叫,邀请扣叫
 
牌例

3s.gif (111 bytes)询问止张,同时暗示s.gif (111 bytes)单缺。开叫者4s.gif (111 bytes)是自愿性的,表示s.gif (111 bytes)上没有浪费点力。应叫者4NT询问关键张,开叫者5NT显示两个A+将牌Q+一个额外的K。

转移到c.gif (113 bytes)后的设计极为困难,因此有必要减轻这个叫品所背负的压力,让邀请性的3c.gif (113 bytes)多分担一些:9-11大牌点,6+c.gif (113 bytes);或10-12大牌点,好的5张c.gif (113 bytes)

如果是13+大牌点,5张c.gif (113 bytes)的5332型,我们可以转移到无将(借助下面这个序列)。

2h.gif (112 bytes)转移到对方争叫花色表示没有4张h.gif (112 bytes)的均型牌,逼局。在开叫者再叫2NT后,应叫者的3c.gif (113 bytes)表示5张c.gif (113 bytes)的5332型。

那么2s.gif (111 bytes)转移叫到底包含哪几种类型的牌呢?

1) 6-8大牌点,6+c.gif (113 bytes)。这往往是同伴做出最佳决定的关键信息。

2) 13+大牌点,5+c.gif (113 bytes),逼局。

我们对于那些9-11大牌点,5张c.gif (113 bytes)但又不适合跳叫3c.gif (113 bytes)邀请的牌暂时没有合适的叫品进行描述。

应叫者在持有3张好的h.gif (112 bytes)时也许可以冒险进行否定性加倍。如果有s.gif (111 bytes)止张的话可以视牌力在1阶或2阶上叫出无将。Pass也是一种选择,希望叫牌不会停在1s.gif (111 bytes)上。

牌例1

在这里5c.gif (113 bytes)是非常好的牺牲叫。

牌例2

如果东第一次叫牌时pass,而南跳叫3s.gif (111 bytes)的话,很难想象东西方仍然能找到3NT最佳定约。

序列7
3c.gif (113 bytes) - 6+c.gif (113 bytes)
3d.gif (109 bytes) - 5+c.gif (113 bytes),4d.gif (109 bytes)
3h.gif (112 bytes) - h.gif (112 bytes)单缺
3s.gif (111 bytes) - s.gif (111 bytes)单缺
3NT - 没什么特别的

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

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