让脚本写出“成都味儿”这事儿，本质上是个语料库工程问题，不是简单的关键词替换。我花了三天，用 GPT-4 API 批量处理了从“成都吃喝玩乐”论坛爬下来的三万条本地人发言，清洗、去重、打标签。结果发现，最核心的“味道”不是“巴适”或者“安逸”这些词，而是句式和节奏。比如，成都话描述动作喜欢用“V+一下”的短促结构（“走一下春熙路嘛”），以及那种带点抱怨又亲昵的转折（“这家火锅辣是辣，但第二天不得遭”）。我最初的规则引擎完全跑偏了。
这实验的背景是，我看到 Coze 国际版（那时候还叫 Bot）悄无声息地上线了。界面干净得吓人，拖拽节点、连接大模型、发布到 Discord 一气呵成。我当时心里就咯噔一下。2016年我为了做个自动回复客服，得自己搭服务器、写 Flask 接口、处理微信的 XML 协议，掉头发掉得跟秋天的梧桐树似的。现在呢？一个高中生，用这玩意儿半小时就能搓出一个能查天气、讲笑话、订外卖的机器人。工具的门槛正在以肉眼可见的速度蒸发。
所以问题来了。当造一个“能用的”机器人变得跟搭积木一样简单，你靠什么吃饭？靠什么让甲方觉得这钱花得值？我那个“成都味儿”的脚本，最后能跑出点样子，靠的不是我 Python 多线程爬虫写得溜（这技术2023年已经快成考古学了），而是我花了大量时间去做“语料诊断”。我知道哪些是无效数据（比如游客的点评），知道怎么设计 prompt 让大模型去模仿“本地嬢嬢”的吐槽语气而不是新闻稿腔调，知道在“椒盐普通话”和纯方言之间取一个商业化的平衡点。这些判断，来自我之前做本地生活小程序时，被甲方反复折磨修改了四十多版文案的“痛苦记忆”。这些经验，没法被封装成一个节点。
这就是现在的壁垒。以前壁垒是技术实现，是你能不能绕过某个平台的 API 频率限制，是你能不能破解那个该死的动态加载 DOM 树。现在的壁垒，是你对业务场景的理解深度，是你手里有没有高质量、高纯度的“经验数据”。你能不能用 prompt 准确描述出“成都街头巷尾苍蝇馆子老板招呼熟客时那种随意又精准的热情”？这需要你真正蹲过那些馆子，跟老板摆过龙门阵，而不是仅仅看过大众点评的排行榜。
工具民主化是好事，它把我们从重复的代码劳动中解放出来。但它也把竞争推到了下一个层面：认知与经验的较量。你的语料库就是你的护城河，你的 prompt 设计能力就是你的新代码。当每个人都能用 Coze 搭个架子，往里填什么，怎么填得“对味儿”，就成了唯一的胜负手。我盯着我那个终于能吐出几句像样成都话的脚本，感觉到的不是轻松，而是另一种更精细、更耗神的焦虑正在袭来。你得从“工程师”变成“语言教练”兼“民俗学家”，这他妈比调参难多了。
