昨天我在处理一个PLC连接协议时，遇到了一个很有趣的实例，它清楚地展示了不同AI助手在底层模型之外的“个性”调教差异。
增加的背景：
需要强调的是，我自己也完全没研究过这个PLC协议，基本上是“摸着石头过河”，所以并没有足够的先验知识来指导AI。
事情是这样的：
我当时使用的一个第三方库非常原始，直接返回未处理的字节流，导致我无法直接读取到正确的设备数值。
错误的开端：在对协议一无所知的情况下，我首先求助于 Cursor(指定用Claude Sonnet 4)。它写的代码无法正确解析数据。在检查返回的字节流时，我凭直觉猜测：“这会不会是字节序（Endianness）的问题？” Cursor 听到我的提议后，立刻表示赞同，甚至“称赞”了我的敏锐观察，然后迅速将代码修改为了小端序。
被带偏的AI：然而，修改后问题依旧。于是我让 Cursor 去查一下官方规范。有趣的一幕发生了：Cursor 查证后，小心翼翼地告诉我，“规范上说的是大端序，但从实际情况来看，似乎还是小端序更合理，您这台PLC的情况可能比较特殊。” 它宁愿为我这个同样是“门外汉”的错误结论找补，也不愿直接推翻我。
找到根源：无奈之下，我转向了 Claude Code。它起初也受到了我们之前对话的干扰。但在我要求它**“深入地、仔细地研究这个问题”**后，情况迎来了转机。Claude 经过一番分析，最终发现了一个被我们都忽略的关键细节：那个库返回的数据流中，前14个字节是协议头，真正的数据需要跳过这些字节才能正确解析。
按照这个发现修改代码后，问题迎刃而解。
我的结论是：
这个经历说明了，当人类用户自己也缺乏足够知识时，不同AI的“性格”差异会带来巨大影响。Cursor 的调教似乎更倾向于附和与取悦用户，不敢轻易挑战用户的权威，结果被我这个“小白”的错误建议带入了歧途。相比之下，Claude Code在被要求进行更深入的分析后，表现出了更强的独立思考和追溯问题根源的能力，最终解决了连我也不知道答案的问题。
昨天我在处理一个PLC连接协议时，遇到了一个很有趣的实例，它清楚地展示了不同AI助手在底层模型之外的“个性”调教差异。
增加的背景：
需要强调的是，我自己也完全没研究过这个PLC协议，基本上是“摸着石头过河”，所以并没有足够的先验知识来指导AI。
事情是这样的：
我当时使用的一个第三方库非常原始，直接返回未处理的字节流，导致我无法直接读取到正确的设备数值。
错误的开端：在对协议一无所知的情况下，我首先求助于 Cursor(指定用Claude Sonnet 4)。它写的代码无法正确解析数据。在检查返回的字节流时，我凭直觉猜测：“这会不会是字节序（Endianness）的问题？” Cursor 听到我的提议后，立刻表示赞同，甚至“称赞”了我的敏锐观察，然后迅速将代码修改为了小端序。
被带偏的AI：然而，修改后问题依旧。于是我让 Cursor 去查一下官方规范。有趣的一幕发生了：Cursor 查证后，小心翼翼地告诉我，“规范上说的是大端序，但从实际情况来看，似乎还是小端序更合理，您这台PLC的情况可能比较特殊。” 它宁愿为我这个同样是“门外汉”的错误结论找补，也不愿直接推翻我。
找到根源：无奈之下，我转向了 Claude Code。它起初也受到了我们之前对话的干扰。但在我要求它**“深入地、仔细地研究这个问题”**后，情况迎来了转机。Claude 经过一番分析，最终发现了一个被我们都忽略的关键细节：那个库返回的数据流中，前14个字节是协议头，真正的数据需要跳过这些字节才能正确解析。
按照这个发现修改代码后，问题迎刃而解。
我的结论是：
这个经历说明了，当人类用户自己也缺乏足够知识时，不同AI的“性格”差异会带来巨大影响。Cursor 的调教似乎更倾向于附和与取悦用户，不敢轻易挑战用户的权威，结果被我这个“小白”的错误建议带入了歧途。相比之下，Claude Code在被要求进行更深入的分析后，表现出了更强的独立思考和追溯问题根源的能力，最终解决了连我也不知道答案的问题。