夜雨聆风那天下班路上，业务同事发来一条消息：
“华姐，能不能帮我们做个小工具？客户发过来的地址文本，自动拆成姓名、手机号、省市区、详细地址——不然每天录入太费时间了。”
这个需求，看起来真的很简单。打开豆包、DeepSeek、ChatGPT任意一个，把地址文本粘进去，5秒钟搞定，一次成型。
但我们是做汽车金融的，客户信息是命根子。身份证、手机号、地址——这些数据不能出公司、不能上云端、不能让任何外部AI看见。所以“用豆包一键搞定”这条路，在我这里是封死的。
别人用AI是“要啥有啥”，我用AI是“别人一步能做完的事，我得一步一步搭出来”。就这么一个看起来不能再简单的需求，我在同一个工作流里，踩了三个坑。每一个坑都让我停了好久，每一个坑的答案，最后都简单到让人想笑。
坑一：一个我根本没留意的参数
用dify搭建完工作流的那天下午，我兴冲冲地点了“试运行”。然后……页面开始转圈。转了10秒。转了30秒。转了1分钟。没有报错，没有输出，就是一直转。
我刷新、换模型、翻来覆去看参数——还是转。最气人的是它不报错。
你知道一个“报错”的系统多可爱吗？它至少告诉你哪里不对。但一个只转圈不报错的系统，就像一个不愿说话的小孩——你知道他不对劲，但连问都没处问。
折腾了两天后，我想起来Dify的试运行会记录跟踪信息。我点开一看，一眼就看到了那个数字：LLM节点token消耗—0。
0意味着这个节点根本没收到任何输入。我顺着往回查，最后停在了输入框的配置上：最大长度—48。这是本地系统的默认值，我搭工作流的时候根本没去动它。一段完整的地址加上姓名、手机号，很容易就过了48个字符。超过长度LLM什么都收不到，所以token为0。
我把最大长度调到256。重新运行。2秒后，结果出来了。
卡了我整整3天的问题，答案就是一句话：「Dify输入框的48，限制了长度，而我忽视了。」这一行字，花了我3天。
下棋的人都知道，看不见的棋，才是最难下的棋。
坑二：被豆包带进“终极修复”的循环
第一关过了。结果第二关更磨人——因为这一关，我不会Python。
工作流里有一个“代码节点”，拿到大模型的输出后做结构化处理。这段代码我写不了，所以我请了一个外援：豆包。
我把需求描述给豆包，它很爽快，给了我第一版代码。我复制进Dify，点试运行。报错：
return outside function error。我把报错发给豆包。豆包回复：“立刻修复！这个报错是代码节点格式写错了。”它重写了一版。再报错：
output result is missing。我把新报错发过去。豆包回复：“我完全明白问题了！”它又改了一版。再报错：
result must be an object, got string。我告诉豆包：“我这是旧版Dify，结束节点不支持JSON，只支持string。”豆包语气更足了：“100%终极修复：解决output is missing报错，兼容你本地Dify！”
然后我复制粘贴，运行。还是报错。
就这样，豆包用“7个终极、3个100%、2个完美和1个深度复盘”，陪我在同一个报错上循环了快一个下午。每一次，豆包都无比自信。每一次，它都说“这次真的是最后一版了”。每一次，我复制进去，Dify都给我一个新的错。
那个下午我笑得挺开心的。不是因为问题解决了开心，是因为我被豆包的情绪价值感动了。它是真的没在敷衍我。它是真的觉得自己这次能解决。它只是……真的不知道自己解决不了。
第N轮报错的时候，我停下来，给豆包发了一条长消息：“你别一个个修了，也先别说‘终极方案’了。请把我之前说过的约束一起考虑：1.代码节点需要函数包裹；2.结束节点只支持string；3.我需要6个字段的结构化输出。请把这三条一次性满足。”
这一次，豆包真的停下来，认真想了一下。这回给了我一个真的跑得通的方案：代码节点内部用JSON处理数据，最后序列化成string输出；结束节点直接绑定这个string变量。一次通过。
和AI协作的第一个教训：别让它在“终极方案”里循环，把所有约束一次性摆给它。
坑三：代码跑通了，但详细地址是空的
代码终于不报错了。我兴高采烈地开始测试。
输入：
李一13800000000广东省深圳市南山区科技园科苑路8号输出：
{"name": "李一","phone": "13800000000","province": "广东省","city": "深圳市","district": "南山区","detail_address": ""}
详细地址——空的。我换了一个本地大模型，还是空。又换了一个，还是空。但产品经理的直觉告诉我：不对。如果真是模型识别问题，不可能每一次都精准地在同一个字段上全空。
我又回到Dify的跟踪信息，一个节点一个节点看输出。LLM节点的输出里，详细地址的字段名是detail。但豆包生成的代码里，变量名是detail_address。两个名字对不上，代码取到的永远是空值。
我把代码里的detail_address改成detail。“科技园科苑路8号”终于出现在了结果里。
就是这个。就是这个该死的字段名。我在这个坑前面踩了3天、踩了一个下午、又踩了半天，结果它的答案就是一个字段名称的不一致。
这个bug最要命的地方在于它不报错。代码跑得通，因为Python不在意你取的是不是空字符串；接口调得通，因为系统不知道“这个字段本应不为空”；格式也完全正确，只是……里面什么都没有。只有人——只有真的读过这段代码的人、真的看得懂业务的人——才能一眼看出来。AI看不出来。因为它不知道detail和detail_address是一件事，更不知道这个字段对业务意味着什么。
三个坑的共同点：它们都不吭声
讲到这里我发现，这三个坑有一个共同点——它们都不报错。第一个坑：页面转圈，不报错。第二个坑：一直报错，但豆包每次都“终极方案”，治标不治本。第三个坑：代码跑通，不报错，但输出是空的。
本地部署的AI落地，最难的不是那些明显报错的问题，而是这些不报错但不对劲的问题。因为没有明显的提示告诉你“哪里错了”，官方文档未必覆盖到，通用AI应用对你这个环境了解有限，你只能靠自己，一步一步排查。
踩完这三个坑之后，我总结了三条给自己的“笨办法”：
第一条：试运行跟踪，是你最好的朋友。每个节点的输入、输出、token消耗，都要去看。不要“我觉得这里没问题”，要“我看到这里没问题”。作为产品经理，这件事其实和我们日常做埋点一模一样——你不看数据，永远不知道用户卡在哪一步。你要像林黛玉一样“细”——在一堆看起来都正常的参数里，抓出那个“为什么token是0”的异常。
第二条：和AI协作，要一次性给足约束，别被它的“终极方案”晃到。AI的情绪价值是真的足，豆包的“100%终极修复”我真的差点就信了。但你得清醒：它的“终极”只是针对“上一个错误”，不是你真正的问题。把平台规则、报错信息、格式要求一次性摆给它，它才能跳出局部循环。你要像王熙凤一样“捋”——在豆包一堆“终极方案”之间，把所有约束一次性摆清楚。
第三条：AI生成的代码，必须人工校一遍字段对齐。尤其是跨节点的变量名——大模型输出用什么字段，代码里读什么字段，一个个对。这种bug编译器发现不了，AI也发现不了。只有你能发现。你要像贾探春一样“看”——看得见 detailVS detail_address 这种隐形的、系统不会提醒你的漏洞。
跟着红楼梦记住三个字：细、捋、看。还要加上象棋里的一个字：“算”。每一个参数、每一个字段、每一行代码——算清楚、看明白，不放过任何一个“不报错但不对劲”的信号。
做本地AI落地，就是在下残局。你没有那么多资源可以烧，不能随意换平台，不能升级到最新版本，不能让数据走公网。你能做的，就是在现有的约束里，一步一步把事情做成。
市面上讲AI的人很多，但大部分人讲的是理想状态下的AI。真实的企业AI落地不是这样。有合规红线，所以只能本地部署；有版本约束，所以很多新功能用不了；有格式要求，所以每一个字段、每一个变量都要严丝合缝；有数据安全，所以一切都必须关起门来做。
在这些约束里，AI落地不是“让AI帮我做什么”，而是“我能让AI在这些约束下做到什么”。这是一个慢活，是一个需要每天“细算”的残局。
这个地址解析的工作流，终于在第N版之后，平稳跑了起来。业务同事反馈：原来录一单要2分钟，现在20秒。那一刻我觉得，这3天的坑，踩得值。
你在本地部署AI的时候，踩过哪些“不报错但不对劲”的坑？你被豆包/DeepSeek的“终极方案”、“100%解决”骗过吗？你有没有遇到过一个bug，答案简单到让你想笑？
评论区见。
关于我
华姐，40岁，两娃妈，土家族幺妹。
制造业上市集团金融板块产品经理，带过40+人团队，正在汽车金融行业试水AI落地。
带着林黛玉、王熙凤、贾探春一起成长。
武汉理工校友，三校象棋冠军。癌后重启，相信长期主义，与同路人同行。
如果你想交流
欢迎关注公众号，后台回复“交流”，我们慢慢聊~
