还记得上高中那会儿，智能手机还没影，手里最像样的电子设备就是文曲星。那时候闲极无聊，就在那个简陋的小屏幕上用GVBASIC也就是文曲星自带的BASIC语言写程序。
那个环境现在想以此为生的人大概很难想象。它甚至有9999行代码的硬性限制，更要命的是，它没有现代编程语言中“函数”的概念。如果你想复用一段逻辑，唯一的办法就是用GOTO。你得人肉记住第500行是干嘛的，让程序跳转过去，执行完了再用另一个GOTO跳回来。
那是资源匮乏时代的生存智慧，也是一种不得已的野蛮生长。
后来上了大学正经学C语言，老师定下的一条死规矩让我印象极深：绝对不能用goto关键字。不管你代码逻辑多精妙，只要出现这个词，卷面直接零分。
当时年轻气盛，觉得老师简直不可理喻。明明一个跳转就能解决的问题，非要逼着我写一大堆结构体和循环，这不是舍近求远吗？但为了拿学分，只能硬着头皮戒掉了这个习惯。
直到后来写了几万行代码，去处理那些真正复杂的系统时，我才突然明白了当年的良苦用心。老师杀死的不是一个关键字，而是一种线性的、打补丁式的思维惯性。如果你习惯了用GOTO去修补流程，你就不可能建立起“面向对象”的大局观。那样写出来的程序，就像一盘纠缠不清的意大利面，根本无法在更大规模的生产环境里存活。
如今到了AI时代，我惊讶地发现，几十年前的这一幕正在Prompt Engineering也就是提示词工程的领域里重演。
看看大家现在的Prompt是怎么写的吧。满屏的大写字母，充斥着MUST、MANDATORY、STRICTLY这样的词汇。还有那一长串的“负面约束”：不准用这个词，不准用那种句式，切记不要胡编乱造。
这背后其实是一种很深的不安全感。我们觉得模型是一个不可控的黑盒，所以下意识地试图用音量去压服它，用威胁去锁死它。
但在我这个老程序员眼里，这种做法本质上就是在写自然语言版本的GOTO语句。
当你发现模型偶尔不听话，你的第一反应不是去重新梳理上下文的结构，而是加一句“必须严格执行”。这就像是在一个逻辑混乱的函数里，强行插入了一个跳转指令。虽然这一次它可能侥幸蒙对了，但你其实是在给整个系统增加熵值。
如果你认为AI未来会强大到成为你的Copilot甚至是私人助理，那你真该试着把它当人看。
这个道理放在管理学上也是通用的。想象一下你招了一个实习生，即便他经验尚浅，你会选择PUA他吗？你会整天冲他大喊大叫，或者列出一百条“禁止事项”贴在他脑门上吗？
如果你不停地告诉一个实习生“不要犯A错误，不要犯B错误”，他的脑子里就会被这些错误填满。他会变得战战兢兢，动作变形，把所有的注意力都用来避免踩雷，而不是去思考如何把事情做得出彩。
对于大模型也是一样。从技术原理上讲，模型的注意力机制其实很难处理“不”这个概念。当你反复强调“不要去想粉色大象”时，模型的注意力权重反而被迫聚焦在了“粉色大象”上。你越是罗列各种反例，其实越是在把模型的关注点往沟里带。
真正的管理者，懂得尊重人权。这种尊重不是为了所谓的政治正确，而是为了效能，为了发挥每个人的主观能动性和潜力，更是因为每个人都需要一个机会成长。
我们在写代码时，遇到函数逻辑混乱，最好的办法不是加更多的if-else去打补丁，而是停下来，把整个函数重构一遍。同理，当模型的输出不尽如人意时，我们不该用更多的MUST去打补丁，而应该去重构我们的Prompt。
试着告诉它“什么是好的”，而不是“什么是不好的”。给它一个优秀的示例，给它清晰的背景和目标。这就像是面向对象编程里的接口定义，你把结构搭好了，逻辑自然就顺了。
当我们放下手中的鞭子，不再试图用恐吓来控制概率，而是用结构去引导方向时，你会发现，那个被你尊重的实习生，往往能展现出超乎你想象的创造力。