企业官网建设流程全解析

1. 项目概述：当Bug修复遇上AI Agent

最近在团队内部搞了个挺有意思的自动化项目，核心目标就一个：让飞书上的Bug报告能自己“跑”起来，自动完成从识别、分析到尝试修复的全过程。听起来有点科幻，但用LangGraph这个框架搭起来后，发现路径其实挺清晰的。这本质上是一个AI驱动的流程自动化Agent，它像一个不知疲倦的虚拟工程师，7x24小时盯着飞书群里的Bug消息，一旦发现符合条件的报告，就自动触发一系列的分析、诊断甚至修复动作。

这个想法的诞生，源于我们日常开发中一个非常具体的痛点：在飞书群或项目空间里，测试同学或用户经常会直接丢出一段错误日志、一个截图，或者简单描述“某某功能点不动了”。开发同学需要手动复制错误信息、去日志系统查询、在本地或测试环境复现、定位问题根因，最后才能开始修复。这个过程里，大量时间花在了重复的、机械的上下文切换和信息搜集上。我就想，能不能让AI把前面这些“脏活累活”先干了，甚至对于一些已知的、模式固定的Bug，直接给出修复建议或自动执行修复脚本？

LangGraph的出现，让这个想法有了落地的“骨架”。它不像传统的线性脚本，而是允许你定义一套有状态的、可循环的、能根据条件分支的工作流（Graph），这完美契合了Bug分析这种多步骤、可能回溯、需要调用不同工具（Tool）的场景。再结合飞书开放平台提供的机器人API，一个能自动响应、智能处理的Bug修复助手就有了雏形。这个实践不仅仅是接个API调个模型那么简单，它涉及到工作流设计、状态管理、工具调用编排以及与实际开发环境的安全集成，是一套完整的工程化思考。

2. 为什么是LangGraph？核心设计思路拆解

在决定用LangGraph之前，我们也评估过其他方案，比如直接用LangChain的Chain，或者自己写一套状态机。最终选择LangGraph，主要是看中了它在构建复杂、有状态Agent方面的独特优势，这与我们Bug修复场景的需求高度匹配。

2.1 场景需求与框架选型考量

Bug自动修复不是一个简单的问答（Q&A）过程，而是一个典型的多步骤决策循环。它可能包含以下环节：1) 解析飞书消息，提取关键信息（如错误堆栈、用户描述）；2) 判断Bug类型（前端UI？后端API？数据库？）；3) 根据类型，调用不同的诊断工具（如查询日志平台、执行测试用例、检查数据库状态）；4) 分析诊断结果，定位可能根因；5) 生成修复方案（或直接执行修复脚本）；6) 将结果反馈回飞书。这个过程可能需要循环（例如，诊断结果不明确，需要进一步查询），也可能有分支（前端Bug走UI测试工具，数据库Bug走SQL检查工具）。

LangGraph的“图”概念，正好用来建模这个流程。它的几个核心特性解决了我们的关键问题：

• 显式的状态管理：整个Agent的运行有一个中心化的State对象，所有节点（Node）都读取和更新这个状态。这意味着Bug分析的中间结果（如提取的错误码、查询到的日志、诊断结论）可以很方便地在不同步骤间传递和共享，避免了在函数间手动传递大量参数的混乱。
• 循环与条件边：通过conditional_edges，我们可以轻松实现“如果诊断置信度低，就返回‘进一步分析’节点；如果置信度高，就进入‘生成修复方案’节点”这样的逻辑。这是实现智能决策流的关键。
• 持久化与人类干预：LangGraph支持将状态持久化，这意味着一个耗时的Bug分析流程可以被暂停（例如，等待人工确认），稍后再从断点恢复。这对于处理复杂、需要人工复核的Bug非常有用。
• 与LangChain生态无缝集成：我们可以直接使用LangChain已有的各种Tool、Memory组件和LLM封装，大大减少了造轮子的工作量。

相比之下，单纯的Chain更擅长线性管道，而自己实现状态机则维护成本较高。LangGraph在灵活性和工程化之间取得了很好的平衡。

2.2 系统架构与核心组件设计

我们的Agent整体架构可以划分为三层：交互层、智能中枢、执行层。

1. 交互层（飞书机器人）：负责与用户的触点。飞书机器人配置了事件订阅（监听@消息、关键词等）和消息发送能力。当收到疑似Bug报告的消息时，它会将消息内容、发送者、群聊等信息打包，作为初始输入，触发后端的Agent工作流。

2. 智能中枢（LangGraph工作流）：这是大脑，是一个定义好的StateGraph。其核心状态（State）我们设计为如下结构（以Pydantic模型为例）：

   from typing import List, Optional, Annotated from typing_extensions import TypedDict from langgraph.graph.message import add_messages import operator class AgentState(TypedDict): # 来自飞书的原始输入 lark_message: dict sender_id: str chat_id: str # 分析过程数据 extracted_info: dict # 提取的错误码、模块、描述等 bug_type: Optional[str] # 初步分类，如“前端”、“后端-数据库”、“后端-API” diagnostic_results: List[dict] # 调用各种工具查询到的结果 root_cause_hypothesis: Optional[str] # 根因假设 confidence: float # 当前分析结果的置信度 # 输出与动作 action_plan: Optional[str] # 建议的修复方案或操作指令 need_human_review: bool # 是否需要人工介入 # LangGraph内置的对话历史，用于让LLM理解上下文 messages: Annotated[list, add_messages]

   这个State对象随着工作流的推进，被各个节点逐步填充。

3. 执行层（工具集）：这是Agent的“手”和“眼睛”。我们为它装备了一系列Tools：

   • 日志查询工具：封装公司内部日志平台（如ELK、Loki）的API，可以根据错误码、时间范围、服务名进行检索。
   • 代码库查询工具：集成GitLab/GitHub API，用于搜索相关错误码附近的代码变更，或查看最近提交。
   • 静态分析工具：对于某些语言，可以调用简单的lint或安全检查。
   • 测试执行工具（谨慎使用）：在隔离的测试环境中，运行特定的单元测试或集成测试来验证假设。
   • 修复脚本执行工具（高风险，需严格管控）：对于极少数预先定义好、风险极低的修复操作（如清理特定缓存、重启某个非核心服务），提供执行能力。这部分必须加上严格的权限和确认机制。

工作流的大致路径是：飞书消息触发 -> 初始化状态 -> 信息提取节点 -> Bug分类节点 -> 根据分类，条件跳转到不同的诊断工具节点 -> 聚合诊断结果，生成根因假设 -> 判断置信度，高则生成修复方案，低则请求更多信息或标记需人工复核 -> 最终结果返回飞书。

3. 核心实现细节与实操要点

搭建这个Agent，关键在于把LangGraph的抽象概念和飞书API的具体调用，以及实际运维工具串联起来。这里分享几个核心环节的实现细节和踩过的坑。

3.1 飞书机器人的配置与安全接入

第一步是创建一个飞书机器人，并让它能安全地接收和处理消息。

1. 创建机器人：在飞书开放平台创建一个自定义机器人，获取app_id和app_secret。这里有个大坑：飞书机器人的app_secret在控制台复制时，可能会因为前端显示问题导致首尾有多余空格或换行符。直接粘贴使用会报错invalid app_secret。务必在复制后，在纯文本编辑器里检查并清理。

   提示：建议写一个配置校验函数，在应用启动时主动用app_id和app_secret调用一次“获取tenant_access_token”的接口，验证凭证是否有效。

2. 配置事件订阅：为了让机器人能响应群聊中的@消息，需要配置“接收消息”事件。在开放平台后台，配置请求网址（你的服务端API地址），并勾选im:message:receive_v1权限。飞书会向这个地址发送一个携带加密参数的验证请求，你需要按照文档正确响应challenge值，才能通过验证。

3. 消息解密与安全：飞书发送的事件消息是加密的。你需要用verification_token和encrypt_key对收到的请求体进行解密，才能拿到真正的消息内容。这个过程一定要做好错误处理和日志记录，否则问题排查起来会像无头苍蝇。建议使用飞书官方提供的SDK或社区成熟的开源库来处理加解密，避免自己实现出错。

4. 处理@消息：解密后的消息体里，event.message.mentions字段包含了被@的用户（机器人）的ID。只有当mentions里包含你的机器人ID时，才触发Bug处理流程，避免机器人响应所有群消息造成骚扰。

3.2 LangGraph工作流的具体构建

我们用代码来勾勒这个工作流的核心骨架。首先定义工具（Tools）：

from langchain.tools import tool from langchain_community.tools import DuckDuckGoSearchRun import your_log_service_client # 假设的日志查询客户端 import your_git_client # 假设的代码库查询客户端 @tool def query_error_logs(error_code: str, service_name: str, last_minutes: int = 30) -> str: """根据错误码和服务名，查询最近一段时间内的相关错误日志。""" # 调用内部日志系统API logs = your_log_service_client.query( query=f'error_code:"{error_code}" AND service:"{service_name}"', start_time=f'now-{last_minutes}m' ) return str(logs[:5]) # 返回前5条，避免上下文过长 @tool def search_recent_code_changes(keyword: str, repo: str, branch: str = 'main') -> str: """在指定代码仓库中搜索近期包含关键字的提交。""" commits = your_git_client.search_commits(repo, branch, keyword, days=7) return str(commits) # 可以定义更多工具，如 run_test, check_database_health 等 tools = [query_error_logs, search_recent_code_changes, DuckDuckGoSearchRun()]

接下来，定义Graph的节点（Nodes）。每个节点是一个函数，接收并返回整个State。

from langgraph.prebuilt import ToolExecutor tool_executor = ToolExecutor(tools) def extract_info_node(state: AgentState): """节点1：从飞书消息中提取结构化信息。""" message_content = state['lark_message']['event']['message']['content'] # 这里可以调用一个LLM，用Prompt工程让它提取关键信息 # 例如：错误码、服务名、用户描述的问题现象等 # 简化示例：假设我们用一个简单的正则或规则提取 extracted = {"raw_text": message_content} # ... 实际处理逻辑 ... state['extracted_info'] = extracted return state def classify_bug_node(state: AgentState): """节点2：对Bug进行初步分类。""" info = state['extracted_info'] # 调用LLM进行分类。使用LangChain的LCEL语法更简洁，这里为清晰拆成节点。 # 提示词示例：“请根据以下错误描述判断它最可能属于哪类问题：前端UI、后端API、数据库、配置、网络或其他。” classification_result = "后端-API" # 假设的LLM调用结果 state['bug_type'] = classification_result return state def diagnose_with_tools_node(state: AgentState): """节点3：根据Bug类型，调用相应的工具进行诊断。""" bug_type = state['bug_type'] extracted = state['extracted_info'] results = [] if "后端" in bug_type: # 假设提取到了错误码和服务名 if 'error_code' in extracted: log_result = tool_executor.invoke( {"input": f"{extracted['error_code']} {extracted.get('service_name', 'my-service')}"}, query_error_logs ) results.append({"tool": "query_error_logs", "result": log_result}) # 搜索相关代码变更 code_result = tool_executor.invoke( {"input": extracted.get('error_code', 'error')}, search_recent_code_changes ) results.append({"tool": "search_recent_code_changes", "result": code_result}) # 其他类型Bug的诊断逻辑... state['diagnostic_results'] = results return state

然后，定义决定下一个节点是谁的条件边（Conditional Edges）。

def should_continue(state: AgentState) -> str: """根据当前状态，决定下一步是继续诊断、生成方案，还是结束。""" # 规则1：如果诊断结果为空或置信度太低，可能需要更多信息或人工介入 if not state.get('diagnostic_results'): return "need_more_info" # 规则2：这里可以加入基于LLM判断的逻辑，分析diagnostic_results，给出置信度 state['confidence'] = 0.7 # 假设计算出的置信度 if state['confidence'] > 0.8: return "generate_fix" elif state['confidence'] > 0.5: return "analyze_cause" else: state['need_human_review'] = True return "end" def route_by_bug_type(state: AgentState) -> str: """在诊断前，根据Bug类型路由到不同的专用诊断节点（如果需要）。""" bug_type = state.get('bug_type', '') if '前端' in bug_type: return 'diagnose_frontend' elif '数据库' in bug_type: return 'diagnose_database' else: return 'diagnose_with_tools' # 默认诊断节点

最后，组装成图并编译。

from langgraph.graph import StateGraph, END workflow = StateGraph(AgentState) # 添加节点 workflow.add_node("extract_info", extract_info_node) workflow.add_node("classify_bug", classify_bug_node) workflow.add_node("diagnose_with_tools", diagnose_with_tools_node) # 可以添加更多节点，如 diagnose_frontend, diagnose_database, analyze_cause, generate_fix # 设置入口 workflow.set_entry_point("extract_info") # 添加普通边 workflow.add_edge("extract_info", "classify_bug") # 添加条件边 workflow.add_conditional_edges( "classify_bug", route_by_bug_type, { "diagnose_frontend": "diagnose_frontend", "diagnose_database": "diagnose_database", "diagnose_with_tools": "diagnose_with_tools", } ) workflow.add_conditional_edges( "diagnose_with_tools", should_continue, { "need_more_info": "extract_info", # 返回重新提取信息（可设计一个询问节点） "analyze_cause": "analyze_cause", "generate_fix": "generate_fix", "end": END } ) # ... 添加其他边 # 编译图 app = workflow.compile()

这样，一个基本的、可运行的LangGraph工作流就构建完成了。你可以通过app.invoke(initial_state)来执行它。

3.3 与LLM的集成与Prompt工程

在整个工作流中，多个节点需要LLM的参与，如信息提取、Bug分类、根因分析、修复方案生成。这里的关键是设计好的系统提示词（System Prompt）和思维链（Chain-of-Thought）。

例如，在classify_bug_node中，我们不会直接让LLM输出“前端”或“后端”，而是引导它思考：

你是一个资深的软件工程师。请对用户报告的问题进行分类。 请按以下步骤思考： 1. 仔细阅读错误描述和堆栈信息（如果有）。 2. 识别问题涉及的技术栈关键词（如React, Vue, API endpoint, SQL error, 404, 500等）。 3. 判断问题最可能发生的层面：用户界面（UI）、后端应用程序接口（API）、数据库（DB）、服务器配置、网络通信或其他。 4. 输出最终的分类结果，格式必须严格为：`类别：前端` 或 `类别：后端-API` 或 `类别：后端-数据库` 等。 用户问题：{user_input}

通过强制LLM输出结构化的结果，我们可以方便地在后续节点中解析。对于分析诊断结果、生成根因假设的节点，Prompt会更复杂，需要将之前步骤的结果（diagnostic_results）作为上下文喂给LLM，并要求它给出推理过程和置信度评估。

注意：LLM的调用成本（尤其是GPT-4）和延迟是需要权衡的。对于信息提取、分类这种轻量级任务，可以使用更快的模型（如Claude Haiku， GPT-3.5-Turbo）。对于复杂的根因分析和方案生成，再使用能力更强的模型。同时，要做好API调用失败的重试和降级处理。

4. 关键工具的实现与安全考量

工具（Tools）是Agent能力的延伸，但也是最容易出安全问题的地方。工具的实现必须遵循“最小权限原则”和“操作可审计原则”。

4.1 日志与代码查询工具的实现

这类“只读”工具相对安全，重点是稳定性和数据过滤。

• 日志查询工具：不要直接暴露原始的日志查询语句给LLM去拼接，这可能导致注入攻击或查询到无关数据，消耗资源。应该在工具函数内部，将LLM提取的关键词（如错误码ERR_1001）映射成固定的、安全的查询模板。例如：f’error_code:“{sanitized_error_code}” AND service:“{allowed_service}” AND time:>now-30m’。同时，对返回的日志条数做限制，避免一次返回几万条日志撑爆LLM的上下文。
• 代码查询工具：同样，限制搜索的范围（如最近7天的提交）、仓库和分支。可以考虑只允许搜索主分支或发布分支，避免触及正在开发中的、不稳定的代码。

4.2 高风险操作工具的设计与管控

对于“执行测试”或“执行修复脚本”这类写操作工具，必须加上多层防护：

1. 环境隔离：所有自动化执行的操作，必须在完全独立的、与生产环境隔离的测试或沙箱环境中进行。绝对不允许Agent直接对生产数据库执行DELETE或UPDATE操作。
2. 操作白名单：不是所有命令都能执行。预先定义一个经过严格评审的“操作脚本白名单”。Agent只能触发执行白名单内的脚本，且脚本本身应是幂等的、可回滚的。例如，白名单里可以有“清理测试环境A的缓存”、“重启集成测试环境B的服务X”。
3. 人工确认环节：在LangGraph的工作流中，设计一个human_review节点。当Agent准备执行一个高风险操作时，将操作计划和预估影响生成一份报告，通过飞书机器人发送给指定的负责人（或一个审批群）。只有负责人回复“同意”或输入特定的确认码后，工作流才会继续走向执行节点。这可以通过LangGraph的interrupt机制或一个等待外部事件（如飞书回调）的节点来实现。
4. 完备的审计日志：每一个工具的调用，无论读还是写，都必须记录详细的审计日志：谁（哪个飞书用户/群）触发的、在什么时间、调用了什么工具、输入参数是什么、输出结果是什么。这些日志对于事后复盘、问题排查和安全审计至关重要。

5. 部署、监控与迭代优化

将开发好的Agent部署上线，只是开始。如何让它稳定、可靠地运行，并持续改进，是更大的挑战。

5.1 部署架构与依赖管理

建议采用微服务或无服务器架构部署Agent后端。一个简单的架构是：飞书事件回调 -> API网关 -> 触发Lambda函数/FaaS（或一个常驻的轻量级Web服务）。这个服务负责解密飞书消息、初始化Agent状态、调用编译好的LangGraphapp。

关键依赖：

• Python环境：LangGraph和LangChain对Python版本有一定要求，需在部署环境中锁定。
• 模型API密钥：OpenAI、Anthropic等LLM服务的API密钥，必须通过环境变量或安全的密钥管理服务（如AWS Secrets Manager）传入，绝不能硬编码在代码中。
• 网络访问：你的服务需要能访问飞书API、内部日志/代码库系统以及LLM供应商的API。确保网络安全组和路由配置正确。

5.2 监控、日志与告警

没有监控的自动化系统是危险的。你需要监控以下几个维度：

• Agent工作流执行状态：记录每次工作流的触发、每个节点的开始结束时间、状态流转。特别是失败的情况，要记录完整的错误堆栈和当时的State快照。这能帮你快速定位是哪个工具调用超时、哪个LLM API返回了意外格式。
• 工具调用性能与错误：监控每个工具（如日志查询）的响应时间和错误率。如果某个工具频繁超时或失败，会影响整个Agent的可用性。
• LLM使用成本与速率限制：监控不同LLM模型的token消耗量和API调用次数。设置成本预算告警，防止意外流量导致巨额账单。同时关注速率限制（Rate Limit）错误，做好请求队列和退避重试。
• 飞书API调用：监控飞书消息发送的成功率。如果发送失败，需要有重试或备选通知机制（如发邮件给负责人）。

可以在关键节点注入详细的日志，并使用像Prometheus+Grafana这样的组合来收集指标和展示仪表盘。

5.3 效果评估与迭代闭环

如何判断这个Agent是否真的有用？需要建立评估体系。

1. 人工抽样评估：定期（如每周）随机抽取一批Agent处理过的Bug案例，由资深开发工程师进行复核。评估维度包括：Bug分类是否准确？根因分析是否合理？提供的修复方案是否有价值？记录准确率、有用率等指标。
2. 用户反馈收集：在飞书机器人每次回复的末尾，可以附加一个简单的反馈按钮（飞书消息支持交互组件），比如“👍 有帮助”和“👎 不准确”。收集直接用户的反馈。
3. A/B测试：对于关键节点（如分类Prompt、诊断策略），可以设计不同版本，在小流量范围内进行A/B测试，对比哪个版本的处理结果更优。
4. Bad Case分析会：定期组织项目成员回顾典型的失败案例或效果不佳的案例。是工具数据不全？还是Prompt引导有误？或者是工作流逻辑有缺陷？基于这些分析，持续优化你的图结构、工具集和Prompt。

这个迭代过程是永无止境的。一开始Agent可能只能处理非常明确、简单的Bug（比如固定的错误码）。随着工具越来越丰富，Prompt越来越精准，工作流逻辑越来越完善，它能处理的场景会逐渐变多，最终成为一个真正能提升团队效率的智能助手。

6. 常见问题与避坑指南实录

在实际开发和运行过程中，我们遇到了不少问题，这里总结一份“避坑指南”，希望能帮你节省时间。

6.1 飞书集成相关

• 问题：飞书事件回调验证一直失败，返回invalid signature。
  • 排查：首先检查你的服务器时间是否与网络时间同步（NTP），飞书会对时间戳进行校验。其次，确认你在计算签名时，使用的verification_token和encrypt_key是否正确，且与飞书开放平台后台配置的一致。最后，检查你的签名计算代码是否完全按照飞书官方文档的示例实现，注意参数拼接的顺序。
• 问题：机器人能收到消息，但发送消息失败，报{“code”:99991663, “msg”:“request access:fail invalid redirect uri in h5 case”}或其他权限错误。
  • 排查：这个错误通常与OAuth2.0授权有关，但机器人发送消息一般使用tenant_access_token。请确认：
    1. 你获取tenant_access_token的接口地址和参数是否正确（/open-apis/auth/v3/tenant_access_token/internal）。
    2. 你的app_id和app_secret绝对正确（再次检查空格问题）。
    3. 机器人是否已被添加到目标群聊中。
    4. 机器人是否拥有所需权限（im:message:send_v1等），并在开放平台“权限管理”中已申请且已获批。

6.2 LangGraph工作流相关

• 问题：工作流陷入无限循环，或者在某个条件边卡住。
  • 排查：使用LangGraph的调试工具或手动打印每个节点执行后的State。重点检查你定义的条件函数（如should_continue）的返回值，是否严格匹配你为add_conditional_edges定义的映射字典中的键（str类型）。一个常见的错误是条件函数返回了END，但映射字典里没有END这个键，导致找不到下一个节点。确保所有可能的返回值都有对应的目标节点。
• 问题：状态（State）在节点间传递时，某些字段丢失或被覆盖。
  • 排查：记住LangGraph的State是一个TypedDict，每个节点函数应该返回完整的、更新后的State字典。如果你在函数内部修改了State，但最后return了一个新的字典，可能会丢失其他节点添加的字段。最安全的做法是直接修改传入的state字典（它是可变的），然后return state。或者，使用state.update({...})来更新部分字段。
• 问题：工具（Tool）调用超时或返回异常，导致整个工作流中断。
  • 处理：在每个工具调用处添加超时设置和异常捕获。对于非核心工具，可以考虑设置一个较短的超时时间（如5秒），并在超时或失败时，在diagnostic_results中记录一条“工具X调用失败”的信息，让工作流继续向下执行，由后续的LLM节点来处理这种部分信息缺失的情况。不要因为一个工具的失败就让整个Agent瘫痪。

6.3 LLM与提示词相关

• 问题：LLM的输出格式不稳定，有时不遵守Prompt中要求的格式（如“类别：前端”），导致后续节点解析失败。
  • 解决：除了在Prompt中强调格式，还可以使用LangChain的OutputParser（如PydanticOutputParser,StructuredOutputParser）来强制结构化输出。这样，如果LLM输出格式不对，解析器会抛出异常，你可以在节点中捕获这个异常，并采取降级策略（如使用一个更简单的规则进行解析，或直接标记为“解析失败，需人工处理”）。
• 问题：处理长文本（如完整的错误堆栈）时，消耗token过多，成本高且速度慢。
  • 解决：在信息提取节点，先让LLM进行总结和摘要，而不是把原始长文本一直往后传。例如，Prompt可以是：“请从以下错误堆栈中，提取最关键的错误信息（错误码、发生位置、异常类型），总结成不超过100字的内容。” 用摘要代替全文，能大幅减少后续节点的token消耗。

6.4 安全与运维相关

• 问题：担心Agent执行未经授权的高风险操作。
  • 重申原则：这是设计阶段就必须定下的铁律。坚持“只读优先，写操作白名单+人工确认”的原则。将所有写操作工具集中管理，并配上严格的权限校验（例如，检查触发飞书用户是否在许可名单内）。在沙箱环境充分测试后再考虑灰度上线。
• 问题：如何管理不同环境（开发、测试、生产）的配置？
  • 建议：使用不同的飞书机器人应用和LLM API密钥。开发环境Agent可以拉一个内部测试群，使用GPT-3.5等低成本模型；生产环境则使用更稳定的模型，并指向正式的日志和代码库系统。通过环境变量来切换所有配置。

这个项目的核心价值不在于实现一个全能的、能修复所有Bug的AI，而在于将重复、繁琐的排查流程自动化、标准化，并在这个过程中积累可复用的诊断知识和模式。它更像是一个“初级开发助手”，能把工程师从大量重复劳动中解放出来，让他们专注于更复杂、更有创造性的问题。从最简单的规则匹配开始，逐步引入LLM的推理能力，小步快跑，持续迭代，才是落地的正道。