1. 项目概述一个为Ruby语言量身打造的LLM应用框架如果你是一名Ruby开发者最近被各种AI应用搞得心痒痒想在自己的Rails项目里集成一个智能聊天助手或者给后台加个自动生成报告的功能那你可能已经发现了一个尴尬的现实主流的LLM大语言模型生态无论是OpenAI的API、LangChain这样的框架还是Hugging Face上的模型其“第一公民”往往是Python。我们Ruby开发者想要玩转AI常常需要绕个弯子要么调用HTTP API然后自己处理复杂的JSON要么就得忍受一些封装不那么地道的Gem。这就是crmne/ruby_llm这个项目出现的背景。它不是一个简单的API客户端包装而是一个旨在为Ruby社区提供一套完整、优雅、符合Ruby开发者习惯的LLM应用开发框架。你可以把它理解为Ruby世界的“LangChain”它的目标是把构建基于大语言模型的智能应用变得像写普通的Ruby业务逻辑一样自然流畅。这个项目的核心价值在于“集成”与“抽象”。它集成了多个主流LLM提供商如OpenAI、Anthropic、Google等的接口并用统一的、面向对象的方式将它们抽象出来。这意味着你今天用OpenAI的GPT-4写代码明天想换成Anthropic的Claude来处理可能只需要改动配置中的一行模型名称而不需要重写整个调用和处理逻辑。更进一步它提供了诸如提示词模板管理、对话历史追踪、函数调用Tool Calling封装、以及输出解析等高级功能这些都是构建复杂AI应用时必不可少的“脚手架”。简单来说ruby_llm想让Rubyist在AI时代不再只是旁观者或简单的API调用者而是能够快速、高效地成为智能应用的构建者。它降低了门槛把开发者从繁琐的协议细节和胶水代码中解放出来让我们能更专注于业务逻辑和创造性的提示词工程。2. 核心架构与设计哲学解析2.1 统一客户端接口面向协议而非实现ruby_llm最核心的设计是提供了一个统一的Client抽象层。在传统的做法里如果你要调用OpenAI你会用openai这个gem调用Anthropic可能得换另一个gem或者直接手搓HTTP请求。每个服务的参数命名、响应格式、错误处理都不同代码会迅速变得臃肿且难以维护。ruby_llm的做法是定义了一套通用的LLM交互协议。它有一个顶层的LLM::Client基类或模块然后为每个支持的提供商如OpenAIAnthropicGoogle实现一个具体的客户端类。这些客户端类都遵循相同的接口方法比如#chat用于对话#completions用于文本补全#embeddings用于生成向量。从使用者的视角看代码会变得非常清晰# 初始化客户端通过参数指定提供商 client LLM::Client.new(provider: :openai, api_key: ENV[OPENAI_API_KEY]) # 无论底层是OpenAI还是Anthropic调用方式都一样 response client.chat( messages: [{ role: user, content: 你好世界 }], model: gpt-4 ) puts response.content这种设计的好处是显而易见的。首先它实现了关注点分离业务逻辑代码不需要关心今天用的是哪家的模型。其次它极大地提升了代码的可测试性你可以轻松地用 mock 或 stub 来替换真实的客户端进行单元测试。最后它赋予了系统可扩展性未来新的LLM提供商出现只需要在框架内添加一个新的客户端实现即可现有应用无需改动。2.2 消息与对话的标准化建模与LLM交互核心数据单元就是“消息”。ruby_llm没有使用原始的哈希数组来代表消息历史而是将其抽象为Message对象。一个典型的Message对象可能包含role角色userassistantsystem、content内容、以及可选的name或tool_calls等属性。通过对象化框架可以内置一些验证逻辑例如确保role是枚举值之一提供便捷的构造方法以及实现更智能的历史管理。例如框架可能会提供一个Conversation类它持有一个Message数组并负责自动处理上下文窗口的截断Truncation——这是一个非常实际的问题当对话轮次太多超过了模型的最大上下文长度时需要智能地丢弃最早的一些消息而保留最重要的系统指令和近期对话。conversation LLM::Conversation.new(system_prompt: “你是一个Ruby编程助手。”) conversation.add_user_message(“如何优雅地处理异常”) conversation.add_assistant_message(“可以使用begin-rescue-end块...”) # 当对话历史过长时Conversation对象可以自动处理截断策略 # 例如优先保留system message和最近的N轮对话 trimmed_messages conversation.truncate(max_tokens: 4000) client.chat(messages: trimmed_messages)这种对对话的标准化建模使得构建多轮交互的AI功能如聊天机器人、持续的分析会话变得结构化和易于管理。2.3 提示词模板与输出解析器直接拼接字符串来构造提示词Prompt是初级且容易出错的做法。ruby_llm借鉴了其他成功框架的经验引入了提示词模板的概念。模板允许你定义带有占位符的字符串然后在运行时注入变量。template LLM::PromptTemplate.new( “请将以下用户输入分类为{{ categories | join: }}中的一种。输入{{ user_input }}” ) prompt template.render(categories: [“咨询” “投诉” “表扬”] user_input: “你们的产品很好用”) # 输出“请将以下用户输入分类为咨询投诉表扬中的一种。输入你们的产品很好用”更重要的是输出解析器Output Parser。LLM的输出是自由文本但我们的程序往往需要结构化的数据比如一个Ruby哈希、一个数组甚至是一个自定义的业务对象。手动用正则表达式去解析响应内容既脆弱又麻烦。ruby_llm的解析器可以将自然语言响应自动转换为结构化格式。例如你可以指定期望的输出格式是JSON框架会在调用时自动将这一要求注入提示词并在收到响应后尝试解析JSON。更高级的用法是你可以定义一个Ruby类Struct或普通类解析器会尝试将LLM的输出填充到这个类的实例中。class SentimentAnalysis attr_accessor :sentiment, :confidence, :keywords # 解析器会利用这个信息来指导LLM输出 end parser LLM::OutputParsers::StructuredOutputParser.from_ruby_class(SentimentAnalysis) client.chat( messages: [...], response_format: parser.inject_format_instruction # 自动添加“请输出JSON”等指令 ) result parser.parse(response.content) # 返回一个SentimentAnalysis实例这个特性对于构建可靠的AI流水线至关重要它确保了机器可读的输出使得AI能够真正无缝地嵌入到现有的自动化流程中。3. 核心功能模块深度实操3.1 多提供商模型的集成与切换在实际项目中你可能因为成本、性能、功能特性或冗余备份等原因需要同时使用或多个LLM提供商。ruby_llm的配置系统为此提供了灵活的支持。一个典型的配置可能放在config/initializers/llm.rbRails项目中LLM.configure do |config| config.providers { openai: { api_key: ENV[OPENAI_API_KEY], organization_id: ENV[OPENAI_ORG_ID], # 可选 default_model: gpt-4-turbo-preview }, anthropic: { api_key: ENV[ANTHROPIC_API_KEY], default_model: claude-3-opus-20240229 }, google: { api_key: ENV[GOOGLE_GEMINI_API_KEY], default_model: gemini-pro } } config.default_provider :openai end在代码中你可以轻松地指定使用哪个提供商# 使用默认提供商 default_client LLM::Client.default # 使用特定提供商 anthropic_client LLM::Client.for(:anthropic)实操心得模型降级与回退策略一个重要的生产环境实践是设置回退链Fallback Chain。例如你的主要功能使用GPT-4但它可能因为速率限制或临时故障而失败。你可以在ruby_llm的基础上封装一个带有重试和回退逻辑的客户端。class ResilientLLMClient PROVIDER_CHAIN [:openai_gpt4, :openai_gpt35, :anthropic_claude].freeze def chat_with_fallback(messages, **kwargs) PROVIDER_CHAIN.each do |provider| begin client get_client(provider) # 根据provider返回配置好的LLM::Client return client.chat(messages, **kwargs) rescue LLM::RateLimitError, LLM::ServiceUnavailableError e Rails.logger.warn(Provider #{provider} failed: #{e.message}. Trying next.) next end end raise All LLM providers failed. end private def get_client(provider_key) # 将自定义的provider_key映射到实际的LLM::Client和模型 case provider_key when :openai_gpt4 then LLM::Client.for(:openai, model: gpt-4) when :openai_gpt35 then LLM::Client.for(:openai, model: gpt-3.5-turbo) when :anthropic_claude then LLM::Client.for(:anthropic, model: claude-3-sonnet) end end end这个策略能显著提升应用的鲁棒性。注意不同模型的性能和输出风格可能有差异在关键功能上切换模型后最好能有人工审核或额外的验证步骤。3.2 工具调用函数调用的Ruby式封装OpenAI的Function Calling和Anthropic的Tool Use特性允许LLM根据对话内容请求调用外部工具函数来获取信息或执行操作。这是实现AI智能体Agent的关键。ruby_llm需要优雅地封装这一复杂过程。框架需要提供一个方式来定义“工具”。一个工具定义通常包括名称、描述、参数模式JSON Schema以及实际要执行的Ruby代码块或方法。weather_tool LLM::Tool.new( name: “get_current_weather” description: “获取指定城市的当前天气” parameters: { type: “object” properties: { location: { type: “string” description: “城市名如‘北京’” }, unit: { type: “string” enum: [“celsius” “fahrenheit”] default: “celsius” } }, required: [“location”] } ) do |parameters| # 这里是实际的业务逻辑例如调用天气API WeatherService.fetch(parameters[:location], parameters[:unit]) end在聊天调用时将工具定义传入response client.chat( messages: messages, tools: [weather_tool] # 框架负责将工具定义转换为LLM所需的格式 )如果LLM决定调用工具它的响应中会包含一个特殊的tool_calls字段。ruby_llm的客户端需要能识别这个响应自动执行对应的工具代码块并将执行结果作为一条新的tool角色消息追加到对话历史中然后可以选择自动进行下一次调用以让LLM基于工具结果生成最终回复。这个过程可能被封装在一个#chat_with_tools的循环方法中。注意事项工具执行的沙盒与安全允许LLM触发代码执行是强大的但也危险。在生产环境中必须考虑安全权限隔离工具函数应运行在严格的权限控制下避免执行文件操作、系统命令或访问敏感数据。输入验证即使有JSON Schema在执行前也应对工具参数进行二次验证。资源限制为工具执行设置超时和资源限制防止恶意或错误的提示词导致无限循环或资源耗尽。审计日志所有工具调用及其参数、结果都应被详细记录便于追踪和调试。3.3 流式响应与实时交互处理对于需要长时间生成文本的场景如创作长文、实时对话等待LLM完全生成再返回会给用户带来糟糕的等待体验。流式响应Streaming允许服务器端一边从LLM API接收数据一边就推送给前端。ruby_llm需要为支持流式传输的提供商如OpenAI实现相应的流式客户端。它可能提供一个#stream_chat方法该方法返回一个Enumerator或支持SSEServer-Sent Events的对象。在Rails控制器中它可能这样使用def stream_chat response_stream client.stream_chat(messages: messages) # 设置响应头为流式 response.headers[Content-Type] text/event-stream response.headers[Cache-Control] no-cache response_stream.each do |chunk| # chunk可能是一个包含增量文本或特殊事件如结束的对象 if chunk.delta_content # 将增量内容推送给前端 response.stream.write(data: #{JSON.dump({content: chunk.delta_content})}\n\n) end end ensure response.stream.close end在前端你可以使用EventSourceAPI来接收这些数据块并实时更新UI。实操心得处理不完整的令牌和句子流式传输的一个小挑战是数据块chunk的边界可能与单词或句子的边界不对齐。你可能会收到一个不完整的单词如“app”后跟“le”。对于追求完美体验的应用你可能需要在客户端或服务端做一个简单的缓冲累积字符直到遇到空格或标点符号再一次性渲染这样可以避免单词在屏幕上“抖动”着被拼写出来。不过这也会引入微小的延迟需要根据场景权衡。4. 实战构建一个智能客户支持助手让我们用一个具体的例子串联起ruby_llm的大部分功能构建一个能集成到网站的后台智能客服助手。这个助手能自动分类用户问题、从知识库检索信息、生成回答并在无法解决时转接人工。4.1 系统架构与工作流设计我们的助手将遵循一个典型的多步骤工作流Chain意图分类判断用户输入属于“产品咨询”、“账单问题”、“技术故障”还是“人工服务”。信息检索根据分类从对应的知识库如FAQ文档、产品手册中检索相关片段。答案生成结合检索到的信息生成友好、准确的回答。最终检查与路由对生成的答案进行自信度评估如果自信度低则生成请求人工介入的回复。我们将使用ruby_llm来构建这个工作流中的每一个环节。4.2 使用输出解析器实现结构化分类首先我们定义分类的领域模型和解析器。# app/models/llm/intent_classification.rb class IntentClassification attr_reader :intent, :confidence, :extracted_entities # 意图枚举 INTENTS [:product_inquiry, :billing_issue, :technical_support, :human_agent].freeze def initialize(intent:, confidence:, extracted_entities: {}) intent intent confidence confidence extracted_entities extracted_entities # 例如可能提取产品型号、订单号 end end # 创建输出解析器指导LLM输出JSON intent_parser LLM::OutputParsers::StructuredOutputParser.from_ruby_class( IntentClassification, schema_hint: { intent: “One of #{IntentClassification::INTENTS.join(, )}” confidence: “A float between 0 and 1” extracted_entities: “A hash of any extracted information” } )然后我们创建分类链。这里我们引入ruby_llm可能提供的“链Chain”抽象它可以帮助我们顺序执行多个LLM调用。# app/services/support_agent/intent_classifier.rb class SupportAgent::IntentClassifier def classify(user_input) prompt_template LLM::PromptTemplate.new(~PROMPT) 你是一个客户支持意图分类器。请分析用户的输入判断其意图并尽可能提取关键实体信息。 用户输入{{user_input}} 请严格按照要求输出JSON。 PROMPT messages [ { role: “system” content: “你是一个精准的意图分类助手。” }, { role: “user” content: prompt_template.render(user_input: user_input) } ] response client.chat( messages: messages, model: “gpt-3.5-turbo” # 分类任务不需要太强的模型 response_format: intent_parser.inject_format_instruction ) intent_parser.parse(response.content) end private def client client || LLM::Client.for(:openai) end end4.3 结合向量数据库进行知识检索假设我们的知识库已经将文档切片并生成了向量嵌入Embedding存储在了如Pinecone、Weaviate或PGVector这样的向量数据库中。ruby_llm的嵌入Embedding功能可以用于实时查询。首先我们需要一个检索器服务# app/services/knowledge_base/retriever.rb class KnowledgeBase::Retriever def search_by_intent(intent_classification, limit: 3) # 1. 将用户输入转换为向量 query_embedding embedding_client.embeddings( input: intent_classification.user_input, # 假设我们存储了原始输入 model: “text-embedding-3-small” ).first.embedding # 获取向量数组 # 2. 在向量数据库中执行相似性搜索 # 这里假设使用了一个封装好的向量数据库客户端 vector_db_client.search( embedding: query_embedding, filter: { intent: intent_classification.intent }, # 可选按意图过滤 limit: limit ).map(:document_text) # 返回相关文档片段 end private def embedding_client embedding_client || LLM::Client.for(:openai) # 通常与聊天模型使用同一个提供商 end end4.4 组装完整对话链与答案生成现在我们将分类、检索和生成组合起来。这里我们展示一个简化的、线性的链式调用。# app/services/support_agent/assistant.rb class SupportAgent::Assistant def process(user_input) # 步骤1分类 classifier SupportAgent::IntentClassifier.new intent_result classifier.classify(user_input) # 步骤2检索 retriever KnowledgeBase::Retriever.new relevant_docs retriever.search_by_intent(intent_result) # 步骤3生成答案 answer_prompt LLM::PromptTemplate.new(~PROMPT) 你是一名专业的客户支持代表。请根据以下用户问题、分类结果和相关知识库信息生成一份有帮助的回复。 用户问题{{user_input}} 问题分类{{intent}} (置信度{{confidence}}) 相关参考信息 {% for doc in relevant_docs %} - {{doc}} {% endfor %} 如果参考信息足以回答问题请基于信息生成回复。 如果信息不足或问题复杂请诚实地告知用户并建议其联系人工客服。 回复请使用友好、专业的口吻。 PROMPT messages [ { role: “system” content: “你是一名乐于助人且准确的客户支持助手。” }, { role: “user” content: answer_prompt.render( user_input: user_input, intent: intent_result.intent, confidence: intent_result.confidence, relevant_docs: relevant_docs )} ] response client.chat(messages: messages, model: “gpt-4”) final_answer response.content # 步骤4可选自信度检查 # 可以再用一个小模型快速评估生成的答案是否直接回答了问题 # 如果自信度低则修改final_answer为转人工话术 { answer: final_answer, intent: intent_result.intent, confidence: intent_result.confidence, sources: relevant_docs } end end这个例子展示了如何利用ruby_llm提供的各种抽象将复杂的AI逻辑组织成清晰、可维护的Ruby代码。每个步骤职责单一易于测试和调试。5. 性能优化、成本控制与生产环境实践5.1 缓存策略为嵌入和常见问答加速LLM API调用有延迟和成本。合理的缓存可以极大提升响应速度并节省费用。ruby_llm框架本身可能不内置缓存但我们可以很容易地在应用层集成。嵌入缓存文本的嵌入向量是确定的对于同一模型版本。我们可以缓存{文本 向量}的映射。# 使用Rails.cache或Redis cache_key “embedding:v3-small:#{Digest::SHA256.hexdigest(text)}” embedding Rails.cache.fetch(cache_key, expires_in: 30.days) do embedding_client.embeddings(input: text, model: “text-embedding-3-small”).first.embedding end对话结果缓存对于常见、确定性的用户问题如标准FAQ可以直接缓存完整的AI回复。但要注意如果知识库更新了缓存需要失效。一个更精细的策略是缓存“检索到的文档片段 用户问题”的哈希所对应的最终答案。5.2 令牌使用监控与预算控制LLM API按令牌数收费。必须监控使用量防止意外超支或滥用。估算令牌数在调用前可以使用ruby_llm可能提供的#count_tokens方法或独立的如tiktoken针对OpenAIgem来估算本次请求的令牌消耗特别是对于长上下文。请求限流在应用层面为用户或API端点设置速率限制和每日令牌预算。日志与审计记录每一次LLM调用的模型、输入输出令牌数、成本可估算、响应时间。这有助于分析使用模式和优化提示词。设置硬性上限在调用客户端时始终使用max_tokens参数来限制单次响应的最大长度防止生成跑题的冗长内容。5.3 错误处理、重试与降级网络和远程API服务是不稳定的。一个健壮的生产系统必须妥善处理错误。网络超时与重试为LLM客户端配置合理的超时时间如30秒。对于瞬时网络错误或速率限制错误通常返回429状态码实现带有指数退避的自动重试逻辑。服务降级如前所述准备一个模型回退链。对于非核心功能可以在主模型失败时优雅地返回一个“服务暂时降级”的提示而不是抛出错误给用户。内容安全与审核在将用户输入发送给LLM或向用户展示LLM输出前应考虑增加内容安全过滤层防止生成不当或有害内容。这可以是简单的关键词过滤也可以是调用专门的内容审核API。5.4 测试策略如何测试AI应用测试依赖非确定性LLM输出的应用是一个挑战。策略需要分层单元测试隔离LLM使用测试替身Mock/Stub完全模拟LLM::Client的响应。测试你的提示词模板渲染、输出解析逻辑、业务链的流程控制。确保给定特定的输入你的代码能产生正确的行为。RSpec.describe SupportAgent::IntentClassifier do it “正确解析分类结果” do # 模拟LLM返回一个固定的JSON mock_client instance_double(LLM::Client) allow(mock_client).to receive(:chat).and_return(OpenStruct.new(content: ‘{“intent”: “product_inquiry” “confidence”: 0.9}’)) classifier SupportAgent::IntentClassifier.new(client: mock_client) result classifier.classify(“这个产品多少钱”) expect(result.intent).to eq(:product_inquiry) end end集成测试有限真实调用在CI环境中可以运行少量针对真实LLM API的集成测试但使用最便宜、最快的模型如gpt-3.5-turbo并严格限制令牌数。这些测试用于验证端到端的连通性和基本功能。评估测试提示词质量这是最复杂的。可以构建一个包含“输入-期望输出”对的评估数据集定期如每天用生产提示词运行计算匹配度或使用另一个LLM进行评分以监控提示词效果的退化。6. 常见问题与排查技巧实录在实际使用ruby_llm或类似框架构建应用时你会遇到一些典型问题。以下是一些实录的排查经验。6.1 响应格式不符合预期或解析失败问题你使用了StructuredOutputParser但LLM返回的文本无法被解析为有效的JSON或Ruby对象。排查步骤检查提示词指令首先打印出实际发送给LLM的完整消息列表。确认inject_format_instruction方法生成的指令如“请输出一个JSON对象...”是否清晰、强硬地包含在系统或用户消息中。有时指令被淹没在长文本中模型会忽略。简化测试用一个极简的提示词如“请返回一个JSON包含key ‘name’和‘age’”和最简单的模型如gpt-3.5-turbo测试看是否能正确返回。这可以排除业务逻辑的干扰。使用更严格的模型对于复杂的输出结构gpt-3.5-turbo可能不如gpt-4可靠。如果成本允许在生成结构化数据时优先使用gpt-4。后处理与容错在解析代码中添加容错逻辑。如果JSON解析失败可以尝试用正则表达式提取可能的JSON部分或者记录错误并返回一个兜底值而不是让整个流程崩溃。begin parsed JSON.parse(llm_response) rescue JSON::ParserError e Rails.logger.error(“Failed to parse LLM response: #{llm_response}”) # 尝试提取花括号内的内容 if llm_response.match(/\{.*\}/m) parsed JSON.parse(llm_response.match(/\{.*\}/m)[0]) rescue nil end parsed || { error: “parse_failed” } end6.2 对话历史上下文管理混乱问题在多轮对话中AI似乎“忘记”了之前的内容或者上下文长度超限导致API调用失败。排查技巧实施主动截断不要依赖API返回的错误。在每次调用前计算当前对话历史的令牌总数。ruby_llm应当提供或你可以集成令牌计数器。设定一个安全阈值如模型最大限制的80%超过则触发截断。智能截断策略简单的“丢弃最老的消息”可能不合适。优先保留system指令和最近几轮对话。对于很长的中间对话可以尝试使用LLM本身进行摘要Summarization将多轮对话压缩成一条摘要信息再放入上下文。这本身就是一个有趣的链式应用。使用更长的上下文模型如果对话非常长考虑切换到支持更长上下文的模型如gpt-4-128kclaude-3-200k。但这会显著增加成本和延迟。外部记忆存储对于超长对话或需要持久记忆的场景考虑将重要的对话摘要或关键事实存储在外部的数据库或向量数据库中在需要时通过检索类似RAG的方式重新注入到上下文中而不是把所有历史都传过去。6.3 工具调用陷入循环或执行错误操作问题AI在应该调用工具时不调用或者反复调用同一个工具甚至尝试调用不存在的工具。排查与解决清晰描述工具工具的名称和描述至关重要。确保描述准确说明了工具的用途、适用场景和不适用场景。例如get_weather的描述应写明“获取当前天气”避免AI用它来查询天气预报。限制工具集一次只提供必要的工具。如果AI有多个相似工具可选它可能困惑。根据对话的上下文动态加载工具集。处理“无工具调用”在chat_with_tools循环中设定最大迭代次数如5次防止AI陷入“思考-调用-再思考”的死循环。达到上限后强制结束并返回当前结果。验证工具参数在工具执行代码块中第一步就是严格验证参数。即使LLM提供了参数也可能不符合业务规则。验证失败时返回清晰的错误信息给LLM让它有机会修正。人工审核环路对于高风险操作如发送邮件、修改数据库不应完全自动化。可以在工具被触发时将操作详情暂停并发送给人工审核批准后再实际执行。6.4 生产环境下的延迟与超时问题AI功能导致API响应时间变长影响用户体验。优化方向异步处理对于非实时性的任务如生成报告、分析文档使用后台作业如Sidekiq异步处理。前端可以轮询或通过WebSocket通知获取结果。设置合理的超时为LLM客户端配置比HTTP请求更短的超时时间如15秒。如果超时立即返回一个友好的降级消息如“思考中请稍后再试”并在后台重试或记录问题。优化提示词长度冗长的提示词和上下文是延迟和成本的主要来源。定期审查你的system提示词和注入的上下文删除冗余信息。使用更精确的指令。使用流式响应对于实时对话务必使用流式接口。即使整体生成时间相同用户看到文字逐字出现的感觉会比长时间等待一个空白页面好得多。边缘缓存对于公开的、非个性化的AI生成内容如产品描述、通用解释可以考虑在CDN层面进行缓存。构建基于LLM的应用是一个充满探索的工程过程。ruby_llm这样的框架提供了强大的基础设施但真正的挑战在于如何设计可靠的工作流、编写有效的提示词、处理各种边界情况以及将非确定性的AI输出整合进确定性的软件系统中。从简单的自动化任务开始逐步迭代积累针对你特定领域的经验是通往成功最实际的路径。记住最重要的工具不是最强大的模型而是你作为开发者的迭代速度和问题分解能力。