事情的起因源于一个非常质朴的需求——我想写一个极简的 memcpy 测试程序，用来观察 CPU 和 RAM 总线之间的吞吐行为。说人话就是：用最直给的方式把一堆数据从内存这里搬到那里，然后记录一下搬运的耗时，丢进 Perfetto 里看看时序火焰图，验验自己的猜想。

这个需求清晰得就像一瓶矿泉水。没有复杂的业务逻辑，没有晦涩的领域知识，甚至代码量都不该超过 50 行。

我打开了 Cursor，切到 Claude Opus 4.6，在对话框里输入了几句大白话。我没写任何“你是一个精通系统底层的专家”，没加“请一步一步思考”，也没用任何叹号去强调“这是非常重要的”。我只是说：写个 memcpy 的 benchmark，测一下大块内存拷贝的耗时，用 perfetto 能看懂的方式把 trace 打出来。

Opus 像一个不动声色但内力深不见底的高手。它瞬间生成了一段干净利落的 C 代码： clock_gettime 掐表，不同大小的块循环，每个关键步骤打一个 TRACE_EVENT 宏，最后产出一个 JSON trace 文件。接着 Cursor 帮我抓了一把终端输出，我把那个 JSON 往 Perfetto 的网页版里一拖——完美的时序图瞬间展开，拷贝事件像一段段整齐的方阵，延迟、带宽一目了然，正是我脑子里想象的样子。全程不到十分钟，咖啡还是热的。

我膨胀了。

我以为这是 AI 编程的日常。我甚至产生了一种已经驯服了猛兽的错觉，觉得所谓“提示词工程”不过尔尔——只要把需求说清楚，模型自然能懂。那一刻我忘了许多前辈的血泪告诫，得意洋洋地打开了另一个工具：TRAE。

于是，我下午的噩梦正式拉开帷幕。

同样的话投喂给 TRAE，它先是诚恳地生成了一段代码。我一看， memcpy 调用是有的，但 trace 埋点完全不对——它自作主张地给我插了一堆 std::cout 打印时间戳，硬生生把一个 profiling 程序写成了日志输出器。我皱眉，但没慌。提示词工程嘛，微调一下就好。

我尝试更精确地描述：“请使用 TRACE_EVENT_BEGIN 和 TRACE_EVENT_END 宏，生成 Chrome Tracing 格式的 JSON。” 它立刻道歉，然后生成了一版新的。我定睛一看，trace 宏终于出现了，但它把所有宏放在了同一个函数里，没有配对，没有分层，Perfetto 打开后只剩一团纠缠在一起的黑线，仿佛不是内存拷贝的轨迹，而是我脑血管的造影图。

接下来的几个小时，我进入了一种“提示词炼狱”的状态。我开始疯狂地补充上下文，写小作文一样地解释 perfetto 的 trace 格式规范，甚至手写了一段期望的 JSON 结构作为 few-shot 示例。我史无前例地动用了“角色扮演”技巧：“假设你是一个性能分析工具开发者……” 我甚至给它发了官方文档的链接（当然我知道它大概率不会真去读）。我还尝试了复读机式纠正：“不，你没有理解，我要的不是 chrono 输出，是 OS 层面的 trace event，要能被 Perfetto 可视化……”

每一次，TRAE 都表现得极度礼貌且自信。“您说得对，我明白了。” 然后生出一版更令人心梗的东西。要么是 trace 的时间戳全是零，要么是把整个循环写成了一个巨无霸 trace，要么是代码压根编译不过。期间它还产生了一次幻觉，信誓旦旦地告诉我某个 API 存在于一个根本不存在的头文件里，我盯着 #include <linux/tracepoint.h> 沉默了很久，开始怀疑自己是不是才是不懂的那个人。

最讽刺的一幕发生在下午四点。我放弃治疗，把 Cursor 生成的正确代码完整地复制到 TRAE 的上下文里，对它说： “请严格仿照这个实现，只是帮我微调一下缓冲区大小。” 它答应得很好，然后输出了一个融合怪——一半是 Opus 的优雅宏调用，一半是它自己顽固的 fprintf 时间戳。我盯着屏幕上那个不伦不类的缝合怪，忽然领悟到一个残酷的真相：

提示词工程不是一门科学，甚至不是一门手艺，它是一份针对特定模型-工具组合的“专属方言土语词典”。

你在 Cursor + Claude 下练就的百发百中的提示词直觉，换到另一个环境里，可能立刻变成一堆噪声。你以为自己在用通用自然语言下达指令，其实你不过在无意识地配合那个模型独特的潜意识和底层工具链能力。Opus 可能天生对系统级的 trace 概念和 C 工程结构有更深的“体感”，或者 Cursor 对代码上下文和工具调用的整合使得“生成-运行-抓trace”这个闭环无比顺滑，模型能从中获得隐性反馈。而 TRAE 背后那个模型（可能是某个版本，我不想猜了），在这个具体的细分场景下，就像是一个熟背了所有烹饪书但从未进过厨房的学徒——你说的每一个词它都懂，但组合在一起，它给你端上来的永远是一盘看不出原材料的糊状物。

有人会说：“那是你的提示词不够好，你没有用对方法。”这论调我太熟悉了，它暗示着只要掌握某种咒语，一切模型皆可驯服。可我的亲身经历恰恰打了这个耳光：同样的提示词，截然不同的结果，而差的不是我的努力程度，是背后模型对这个问题的“近场直觉”和工具链的打磨度。 我在 TRAE 上耗费的那个下午，写的提示词小作文足以拿去发表一篇知乎高赞回答，但代码质量甚至没有达到我在 Cursor 里用几个词得到的水平。这不是我的失败，这是提示词工程作为一种“通用接口”的承诺的失灵。

我们被灌输的叙事是：大模型越来越强，工具越来越好，人类只需要学会和它们对话。但现实是，这种对话极度“挑食”，每一种模型都有自己的隐性偏好、看不见的雷区和不可预测的临场发挥。你以为你在驾驶一辆自动驾驶汽车，实际上你每次换车都像在重新考驾照，而且这台车的方向盘有时是反的，有时刹车会变成喇叭。

最后，那个不伦不类的程序被我扔进了回收站。我默默回到 Cursor，花三分钟重新生成了那个干净版本，成功跑出数据，截图发了个朋友圈，轻描淡写地配文：“下午随便测了测带宽。” 没有人知道屏幕背后我曾经历过怎样一场提示词的叙利亚巷战。

如果你问我学到了什么，那就是：AI 编程的当前阶段，选择工具和模型比打磨提示词重要一万倍。以及，永远不要在一个让你感到痛苦的组合里证明自己有多会写提示词，有那时间，不如直接换一个更懂你的“灵魂搭档”。

毕竟，真正的效率，是识别出什么时候该停止对牛弹琴，直接起身去另一个牛棚。那里可能连琴都不用弹，牛自己就开口唱了。