我把公司内部那套繁琐的审批流用 AI 重新跑了一遍
很多企业在搞自动化的时候容易陷入一个误区，就是试图用死板的逻辑判断去覆盖所有场景，结果导致配置表长得像天书一样，稍微改个需求就得全盘推翻。其实现在把 LLM 引入工作流，最核心的价值在于它能处理那些“模糊”的判断，而不是单纯的 if-else。
下一篇
用 AI 生成那种“励志海报”真的能给人带来动力吗 →
我之前尝试在企业内部部署一套自动化处理客户反馈的实战方案，最头疼的是要把非结构化的邮件内容转换成结构化的工单。如果用传统的正则匹配，只要用户写错一个词，整个流程就挂了。后来我尝试把这个环节改成一个轻量级的处理节点，让模型先做实体提取，再交给下游系统执行。
这里分享一个我当时调试成功的 Prompt 逻辑，大家可以直接参考，重点在于强制它输出 JSON 格式，方便后续 API 调用：
# Role: 企业工单结构化专家
# Task: 将用户反馈转换为标准JSON格式
# Constraints:
- 仅输出JSON，不要任何解释性文字
- 必须包含 [priority, department, issue_type] 三个字段
- priority 仅限: High, Medium, Low
# Input: {{user_feedback}}
# Output:在实操过程中我踩了一个大坑，就是模型偶尔会输出
...JSONDecodeError。后来我发现不能完全依赖模型的稳定性，必须在代码层加一个简单的清洗逻辑，把所有非 JSON 字符剔除掉。具体排查过程和解决代码如下：
import json
import re
def clean_llm_json(raw_response):
# 使用正则提取 { ... } 之间的内容，过滤掉 Markdown 标签
match = re.search(r'\{.*\}', raw_response, re.DOTALL)
if match:
return match.group(0)
return raw_response
# 之前报错：json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
# 处理后：成功解析为 dict现在这套工作流跑起来非常顺滑，只要提示词写得足够精准，模型在处理复杂语义时的鲁棒性真的比以前强太多。只要敢于尝试，这种从零构建自动化的过程其实很有成就感，哪怕中间报错几次也完全在可控范围内。
