我明白你遇到的这个困扰——当用:o:选项或者手动{bs}实现无空格触发热字符串时，后续输入的相同热字符串会被误触发，导致重复替换。咱们先拆解一下问题根源，再给出针对性的解决方案。

问题原因 #

当你设置:o:ahk::AutoHotKey时，触发热字符串后，替换出的内容末尾恰好包含了触发文本ahk。AutoHotkey的热字符串检测会扫描当前输入缓冲区的全部内容，包括刚刚替换完成的文本，所以当你接着输入ahk时，它会把替换文本末尾的片段和新输入的内容拼接起来，误判为又一个热字符串触发条件，于是再次执行替换，就出现了AutoHotKeyAutoHotKey的结果。

解决方案 #

这里有两种实用的解决方法，你可以根据自己的使用场景选择：

方案1：给热字符串添加单词边界约束（推荐）

给热字符串加上B选项，要求热字符串必须作为独立单词触发——也就是前后必须有单词边界（比如空格、标点、行首/行尾）。这样一来，替换文本末尾的ahk前面是其他字符（不是单词边界），就不会被误识别为新的热字符串触发条件。

修改后的热字符串代码：

:oB:ahk::AutoHotKey

• 优势：完全符合单词级触发的逻辑，不会引入任何隐藏字符，复制粘贴文本也不会有额外问题。
• 注意：如果你的使用场景需要热字符串在非单词边界触发（比如xahky中间的ahk），这个方案就不适用了。

方案2：用零宽度空格打断检测

在替换文本的末尾添加一个零宽度空格（{U+200B}），这个字符在视觉上完全不可见，但会打断AutoHotkey对后续输入的连续检测，让它无法把替换文本的末尾和新输入的内容拼接成完整的热字符串。

修改后的热字符串代码：

:o:ahk::AutoHotKey{U+200B}

• 优势：不需要改变热字符串的触发规则，适用于需要非单词边界触发的场景。
• 注意：极少数情况下，复制粘贴包含这个隐藏字符的文本时，可能会被某些严格的文本处理工具识别，但日常使用基本没影响。

验证效果 #

用方案1的话，输入ahk+空格+ahk，第一个ahk作为独立单词触发替换成AutoHotKey，后续输入的ahk因为前面没有单词边界，不会触发热字符串，最终得到你期望的AutoHotKeyahk。

用方案2的话，替换后的文本末尾有个看不见的空格，后续输入的ahk会被这个空格隔开，不会被检测为连续的热字符串，同样能得到正确结果。

内容的提问来源于stack exchange，提问作者Ádám Bukovinszki