夜雨聆风
做信息化一路走来，从最早的财务软件实施到后来的B端产品设计，再到这两年一头扎进AI智能体的落地，我越来越觉得一件事：工具本身不是问题，怎么用工具才是问题。
飞书AILY智能应用上线有一段时间了，官方文档写得漂亮，演示视频也做得流畅，但真正落到企业环境里，你会发现一堆文档里不会告诉你的坑。有些坑是配置层面的理解偏差，有些是系统本身的隐性限制，还有些是你用"传统思维"去理解"AI产品"导致的错位。
这篇文章不聊概念，不灌鸡汤，只聊我在实际项目里踩过的坑、吃过的亏、总结出的经验。如果你也在做智能客服、知识库问答或者智能体工作流的落地，这篇应该能帮你少走一些弯路。
AILY智能应用的工作流功能很强大，可以把多个节点串起来，实现复杂的业务逻辑。但这里有一个隐性的天花板——工作流数量控制在50个以内。
什么意思？当你的智能应用里配置了超过50个工作流时，在多工作流引用场景下，系统就查不到超出的那些了。不是报错，不是提示，就是静默失败。你在调试的时候可能一切正常，因为调试走的是单一路径；但一旦用户的问题触发了多工作流匹配，超出50个的那部分就像不存在一样。
• 做工作流规划时，先画一张总图，把业务场景拆清楚，合并同类项
• 能用条件分支解决的，就别拆成两个独立工作流
• 定期清理废弃工作流，别让历史包袱拖累系统
这个限制目前文档里没有明确标注，我是花了整整一个下午排查"为什么某个工作流偶尔不触发"才发现的。希望看到这里的你，别重蹈覆辙。
这是我最想强调的一点，也是很多做传统信息化的人最容易掉进去的坑。
AILY里的智能体节点、字段提取节点、LLM节点，都需要写提示词。很多人把提示词当成聊天对话来写，觉得"我说明白就行了"。大错特错。
提示词在这个场景下，本质上是一段结构化指令。它的执行对象不是人，是大模型。大模型对格式、层级、边界条件的敏感度，远超你的想象。一段模糊的自然语言，在你看来"意思很清楚"，但在模型眼里，每一个"大概""尽量""如果可能"都是一条发散的岔路。
我总结了几条提示词编写原则：
一、分段落、加标签。用明确的标记区分"角色定义""输入内容""输出格式""约束条件"，别揉成一坨。
二、示例先行。给1-2个输入输出的正例，比写十行描述都管用。模型看到例子，比看到规则学得快。
三、拒绝模糊表达。"大概""尽量""如果可能"这类词全部删掉，换成"必须""仅当""否则"。这不是在跟人沟通，是在给机器下指令，确定性是第一优先级。
四、输出格式固定化。如果要求JSON，就写明键名、类型、默认值；如果要求列表，就规定分隔符。不给模型任何"发挥创意"的空间。
❌错误写法："请判断用户是想查订单状态还是申请退款，如果是其他问题就告诉用户我帮不了"
✅正确写法：
【角色】你是客服意图分类器
【输入】用户问题：{user_question}
【输出格式】JSON，包含字段：
• intent: 字符串，取值范围["query_order", "apply_refund", "other"]
• confidence: 数字，0-1之间
• reason: 字符串，分类依据，不超过20字
【约束】仅当明确提及"退款"时，intent才为apply_refund；其他情况一律归为other
第二种写法，意图识别的准确率在我负责的项目上提升了将近30%。不是因为模型变强了，是因为指令变清晰了。这30%的提升，不是技术红利，是规范红利。
这个问题我第一次遇到的时候，第一反应是系统出bug了。后来排查下来，发现是配置层面的理解偏差。
你设置了"人工客服"兜底，但用户进线后，系统却把服务台管理员、其他系统的客服、甚至领导拉进了会话。这种情况，通常有三个原因：
第一，客服状态不对。你配置的人工客服，当前可能处于"离线""休假"或"忙碌"状态。AILY的转人工逻辑里，如果目标客服不可用，它会尝试找"替代方案"——而这个替代方案的范围，可能比你想象的大得多。一旦一线客服不在，系统就往更大范围去找人，找着找着就把不该进来的角色拉进来了。
第二，服务时间窗口。每个客服可以配置服务时段。如果用户进线时不在有效服务时间内，系统同样会走兜底逻辑。这个兜底逻辑配置在哪里、指向谁，直接决定了"谁会被拉进来"。很多团队在这个环节只配了"有人兜底"，但没仔细核对兜底对象到底是谁。
第三，兜底配置越界。这是最常见也最容易被忽视的问题。你的兜底客服，可能配置成了某个"客服组"，而这个组里除了你期望的一线客服，还包含了管理员、二线支持、甚至跨系统的账号。一旦触发兜底，所有人都会收到会话邀请。
检查项 → 常见问题
客服在线状态 → 状态设为"离线"但未察觉
服务时间配置 → 午休/节假日未覆盖
兜底客服设置 → 指向了过大的客服组
客服组人员 → 混入非一线人员
我的经验：兜底客服永远指向一个"最小可用集合"，宁可少不可多。真遇到高峰期人手不够，再通过调度策略动态扩容，而不是在兜底配置里"预埋"一堆人。预埋的后果，就是你某天收到一条消息："XX总被拉进了客户会话。"——那场面，谁经历谁知道。
这个技巧看似简单，但能省大量时间。
AILY智能应用支持直接调试，不需要每次修改后都走一遍发布流程。调试模式下，你可以快速验证工作流逻辑、提示词效果、节点输出格式。只有当你确认调试通过、所有路径都跑通了，再执行发布。
为什么强调这一点？因为发布失败的提示信息有时候并不直观。你可能改了一个节点的输出格式，影响了下游另一个节点的输入校验，但报错信息指向的却是第三个毫不相干的节点。这种"连锁报错"排查起来非常头疼。
• 所有工作流的输入输出节点是否都有明确的连线？
• 是否存在"死节点"（没有出边的节点）？
• 条件分支是否覆盖了所有可能的情况？有没有遗漏的else路径？
• 引用的外部资源（知识库、API、模型）是否都在有效状态？
养成"调试先行、发布殿后"的习惯，能避免很多不必要的返工。别小看这步，在多人协作的项目里，一次失败的发布会直接影响其他成员的调试环境。
AILY的智能知识空间问答模块，需要选择底层大模型。这里有一个很多人没注意到的点：企业高频调用的模型，可能会有限制。
某些模型因为调用量太大，平台方可能会对单企业的并发或总量做限制。当你选的模型恰好撞上了这个限制，就会出现"三方调用失败"的情况。不是每次都失败，是高峰期失败、偶发失败、难以复现的失败——这种间歇性故障，排查起来最折磨人。
我的选型思路：
一、先摸底。向平台方确认各模型的企业级调用限制策略，哪些模型有并发上限、哪些有日调用量限制，心里有数再选。
二、留冗余。不要把所有问答场景都绑在同一个模型上。核心场景用主力模型，边缘场景用备用模型。鸡蛋别放一个篮子里，这道理谁都懂，但在模型选型上，很多人就是图省事全选了一个。
三、做降级。配置模型调用失败时的降级策略，比如自动切换到另一个模型，或者返回一条固定话术让用户稍后重试。别让一次模型故障变成用户眼里的"系统挂了"。
• 简单FAQ问答 → 轻量级模型即可，响应快、成本低
• 复杂推理与多轮对话 → 重量级模型，准确率和理解力有保障
• 过度配置是浪费，配置不足是事故
AILY的问答模块里，有一系列响应标识配置，比如"深入检索""多轮检索"之类的选项。听起来很高级，但在实际生产环境里，我建议慎用。
原因很简单：每一次"深入"或"多轮"，都是时间和Token的消耗。
用户问一个简单问题，你调了三轮检索、做了深度分析，等了五秒钟才出结果——这五秒钟里，用户可能已经在心里给这个系统打了差评。智能客服的第一要义是快，其次才是准。一个两秒钟返回的"基本正确"答案，远比一个五秒钟返回的"完美"答案体验更好。
• 常规问题：单轮检索 + 直接回答
• 复杂问题：根据意图识别结果，动态决定是否启用多轮
• 永远不要全局开启"深入检索"，除非你的业务场景对准确率的要求远高于响应速度
响应标识的配置，本质上是一个精度与效率的权衡。没有标准答案，只有适合你的答案。建议上线前做A/B测试，用真实用户数据来验证不同配置下的满意度指标，别拍脑袋。
另外，更费时间意味着更费流量、更费Token。在企业级部署里，这些隐性成本累积起来是相当可观的。别让"追求完美"变成成本失控的导火索。
做AILY智能应用这段时间，我最大的感受是：技术门槛越来越低，业务理解的要求越来越高。
以前做信息化，会配服务器、会写SQL、会调接口，你就是专家。现在这些都被平台化了，真正的竞争力在于——你能不能把一个模糊的业务需求，拆解成清晰的系统逻辑；能不能在"能用"和"好用"之间找到平衡点；能不能在出问题的时候，快速定位这是配置问题、逻辑问题还是理解问题。
飞书AILY是个很好的工具，但工具不会自己跑起来。它需要你理解业务、理解用户、理解技术的边界。
我们做信息化，相信大家都见过太多"上了系统但用不起来"的案例。问题的根因往往不是技术不行，是落地的人没想清楚：我要解决什么问题、怎么验证我解决了、出了问题怎么排查。这三个问题想明白了，工具是AILY还是别的什么，其实没那么重要。
希望这篇手记对你有帮助。如果你也在做类似的落地项目，欢迎在评论区交流，咱们一起把坑填平。
欢迎关注 “数智产研笔记” 公众号，一起探索数智化前沿，解码产业发展新机遇。