1. 项目背景与系统设计思路1.1 为什么需要一套岗位分析系统做这个项目的起因是帮一位做招聘SaaS的朋友处理一个长期摩擦点HR每天从招聘后台导出几十份简历挨个看匹配度再手动查岗位薪资区间、城市分布、行业趋势整个流程极其耗时。更麻烦的是招聘数据散落在多个系统里——简历库、岗位JD库、行业报告彼此割裂HR很难快速判断“这个人到底适不适合这个岗位”。当时市面上虽然有不少AI招聘工具但要么是黑盒没法解释匹配逻辑要么是纯SaaS数据必须上传到对方服务器很多企业根本不敢把简历这种敏感数据放到外部。所以朋友的需求很明确一套能本地部署、能结合企业私有数据、能解释决策依据的岗位分析系统。我用 Spring AI 搭了一套 RAG Tool Calling 架构核心就干三件事第一把岗位JD、简历、行业报告通过RAG技术做成可检索的知识库第二用Tool Calling让模型能够查询实时薪资数据、计算技能匹配度第三把两套能力串成一条完整的分析链路输入一个岗位描述输出一份结构化的匹配报告并且每个结论都能追溯来源。这套系统的价值在于它不依赖某个特定的大模型底层可以切换不同的模型服务数据全部留在企业内部分析过程有据可查。我后面会详细拆解整个搭建过程包括踩过的坑和最终沉淀下来的可复用方案。1.2 技术选型为什么是Spring AI而不是LangChain在做技术选型的时候我对比了LangChain、LangChain4j和Spring AI三个方向。LangChain生态最成熟但Python技术栈为主和现有Java技术体系整合成本高LangChain4j虽然JVM友好但社区活跃度和Spring生态的契合度都差一些。最终选择Spring AI核心逻辑有三个第一团队就是Java背景Spring Boot是我们最熟悉的技术栈。引入Spring AI之后不需要另起炉灶维护一套Python服务一个应用里就能把RAG流程、工具调用、外部接口全部串起来。第二Spring AI从2024年开始迭代速度非常快尤其是1.0.0 GA版本发布之后抽象层已经比较稳定。它的ChatClient、Advisor、ToolCallback这套API设计得很符合Spring风格——约定优于配置扩展点清晰。第三也是最实际的考量客户环境多是内网或私有云部署没有外网访问OpenAI的条件。Spring AI对Ollama、Qwen这类本地模型的适配做得很好切换到本地模型服务只需要改配置不用改业务代码。用一套代码兼容私有化部署和云端SaaS两种交付模式这对做To B项目的团队来说性价比非常高。2. 知识库构建与RAG检索链路2.1 数据准备与文档切分策略RAG效果好不好第一道关口就是文档切分。系统里需要处理的文档有三类岗位JD几百字的短文档、简历1-3页的中等文档、行业报告几十页的长文档。文本切分我直接用了Spring AI内置的DocumentReader体系针对不同文档类型配置了不同的切分策略public ListDocument loadDocuments() { // 处理JD文档按段落切分保留足够上下文 ParagraphTextSplitter jdSplitter new ParagraphTextSplitter(); // 处理简历按固定token切分重叠区域设置较大 TokenTextSplitter resumeSplitter TokenTextSplitter.builder() .withChunkSize(300) .withOverlapTokens(80) .build(); // 处理长报告先按标题分块再二级切分 MarkdownTextSplitter reportSplitter MarkdownTextSplitter.builder() .withChunkSize(500) .withOverlapTokens(50) .build(); }这里的参数是我实测之后调出来的。chunkSize太小切出来的碎片缺乏上下文语义检索时容易漏掉关键信息chunkSize太大检索结果会混入大量无关内容拉低精确率。JD文档我直接用段落切分因为JD本身结构清晰每段就是一个完整语义单元。简历和报告用固定token切分但重叠区域要设得比较大否则一个技能描述正好被切在边界上两边都检索不到完整内容。切分的时候有个容易被忽略的细节要把文档元数据一起带上。比如JD文档可以附加jobId、department、postDate这些字段简历附加candidateId、yearsOfExperience。后面做过滤检索的时候这些元数据就是天然的筛选条件不用每次都跑到向量数据库里去全量搜。2.2 向量化Embedding模型的选择与对比RAG检索质量的上限很大程度上由Embedding模型决定。我对比测试了三类方案方案维度中文效果部署难度单次调用延迟OpenAI text-embedding-3-small1536优秀需要外网200ms左右阿里云 DashScope embedding1024优秀国内直连150ms左右Ollamabge-m31024良好纯本地无外网依赖80ms左右客户那边要求数据不出内网所以最终选了Ollama部署bge-m3。这个模型是BAAI开源的中文场景效果在开源模型里属于第一梯队而且支持8192的上下文长度对长文档切分后的段落向量化完全够用。部署Ollama之后Spring AI里接入方式极其简单spring: ai: ollama: base-url: http://localhost:11434 embeddin-model: bge-m3等等我写错了配置项是embedding-model不是embeddin-model。这类拼写错误我在实际配置里踩过不止一次Spring AI对配置项名字非常敏感写错不会报错但会静默用默认值导致向量维度对不上查询时报错。后面在踩坑章节还会细说。2.3 向量库选型与存储向量数据库我对比了Chroma、Milvus和pgvector。个人项目或小规模部署Chroma足够了它是嵌入式部署启动一个进程就能用。但如果要跑到生产环境我强烈建议直接用pgvector理由很朴素客户大部分已经有了PostgreSQL再加一个pgvector扩展不用额外多维护一个中间件备份和运维体系都是现成的。Spring AI 1.0之后提供了VectorStore的统一抽象切换向量库只需要换依赖和配置。我是这么配置pgvector的spring: ai: vectorstore: pgvector: index-type: HNSW distance-type: COSINE dimensions: 1024这里dimensions必须和Embedding模型的输出维度严格对应。bge-m3输出1024维配置里就写1024。如果你换成了其他模型这个参数没同步改运行时插入向量就会报维度不匹配。存储文档的时候我建议把原始文本和向量分开管理。向量库只管检索原始文档放在PostgreSQL的业务表里。这样检索结果命中之后直接查业务表拿完整文档做展示和引用都方便也能避免向量库数据量过大的问题。2.4 检索与重排序解决“知识割裂”问题建立好索引之后检索环节最容易遇到的问题就是“检索结果分散、语义不连贯”。比如问“Java高级工程师的薪资区间和技能要求”如果只做一次向量检索可能返回的结果一条讲薪资、一条讲技能、一条讲城市分布直接拼给模型模型很难组织出有逻辑的答案。这就是最近圈子里讨论很多的“知识割裂”问题。我参考了agentic RAG的思路把检索拆成两层先粗召回、再精排序。粗召回阶段会用多路查询比如把用户输入改写成一正一反两个问题外加元数据过滤条件同时查技能、薪资、行业趋势三个子知识库。精排序阶段我实现了ReRankingAdvisor对召回的候选文档集计算重排序得分只保留Top-3喂给大模型。Component public class ReRankingAdvisor implements Advisors { Override public void advise(AdvisedRequest request) { // 这里拿到向量检索的候选结果集 ListDocument candidates request.param(candidates); // 对候选结果做重排序保留语义最相关的Top-3 ListDocument ranked candidates.stream() .sorted(Comparator.comparingDouble(this::calcRelevance).reversed()) .limit(3) .toList(); request.param(topDocs, ranked); } }重排序用的是什么模型我偷懒的方法是用GPT-4做打分器但客户环境不允许外网所以最终用本地Qwen模型做了个简化版的交叉编码器——效果虽然不如GPT-4但足够区分出“高度相关”和“有点相关”的文档。这里有个值得反思的点单独靠RAG解决不了所有问题这也是热词里“RAG瓶颈”讨论的核心。RAG擅长的是从已有文档中检索事实但岗位分析场景里还有一类动态数据比如实时招聘市场的薪资波动、某城市最近一周的岗位增量这些不在企业内部的静态文档库中RAG无法回答。这个时候就需要Tool Calling来补齐。3. Tool Calling让模型能查数据、能算匹配度3.1 Tool Calling在岗位分析里的用途岗位分析系统里模型光靠知识库里的历史文档回答不了这么几类问题“这个岗位目前市场平均薪资是多少”——薪资数据是实时变化的知识库里的数据可能几个月前的过期了“岗位要求里提到的技能候选人简历里到底匹配了几项”——需要做精确的技能列表对比不能用大模型自己“发挥”“这个岗位最近30天在招聘市场的竞争热度如何”——需要实时统计数据这些场景的共同特征是结果是可计算的、数据是动态的、答案是确定性的。用大模型生成这种答案一来容易幻觉二来没法追溯。Tool Calling就是DeepSeek和行业里常说的让模型“长出手脚”模型负责理解问题、拆解任务具体执行交给外部工具执行结果再回传给模型生成最终答案。3.2 Spring AI中定义工具的三种方式Spring AI实现Tool Calling的API设计得很好提供了三种方式。第一种注解方式定义POJO方法Component ToolCallbacks public class SalaryTools { Tool(description 查询某岗位在指定城市的平均薪资返回单位为K/月) public String queryAverageSalary(String jobTitle, String city) { // 调用薪资接口或者查数据库 return salaryService.getAvgSalary(jobTitle, city); } Tool(description 查询最近N天某岗位的招聘岗位数量变化) public String queryJobTrend(String jobTitle, int days) { return jobTrendService.getTrend(jobTitle, days); } }Spring AI启动时扫描ToolCallbacks注解的Bean自动把方法注册成工具JSON Schema都是自动生成的。这种方式最省心适合大部分场景。第二种代码方式构造ToolCallback适合需要动态拼装工具的场景Bean public ToolCallback skillMatchTool(ObjectMapper objectMapper) { return ToolCallbacks.builder() .name(calculateSkillMatchRate) .description(计算候选人简历与岗位JD的技能匹配率返回百分比) .inputType(SkillMatchRequest.class) .toolResponseConverter(this::convertResponse) .build(); }第三种直接实现FunctionCallback接口完全自己控制参数的解析和结果序列化适合对接已有服务接口时用。我实际项目中大部分工具都用注解方式但如果工具的参数比较复杂比如需要传一个对象我会用代码方式因为可以明确指定输入类型。3.3 一个完整的工具实现技能匹配度计算技能匹配度计算是系统里最有代表性的一个工具我拆开讲讲实现细节。首先定义请求对象public record SkillMatchRequest( ListString requiredSkills, ListString candidateSkills ) {}然后实现计算逻辑Tool(description 根据岗位要求的技能列表和候选人掌握的技能列表计算匹配率和缺失技能) public String calculateSkillMatch(SkillMatchRequest request) { SetString required new HashSet(request.requiredSkills()); SetString candidate new HashSet(request.candidateSkills()); ListString matched required.stream() .filter(candidate::contains) .toList(); double matchRate required.isEmpty() ? 0 : (double) matched.size() / required.size() * 100; MapString, Object result new HashMap(); result.put(matchRate, String.format(%.1f, matchRate)); result.put(matchedSkills, matched); ListString missing required.stream() .filter(skill - !candidate.contains(skill)) .toList(); result.put(missingSkills, missing); return objectMapper.writeValueAsString(result); }这个工具解决了大模型的一个典型问题让它直接数技能匹配项它经常数错。比如JD里写了“熟悉Spring、MyBatis、Redis、Kafka”简历里写了“精通Spring Boot、MyBatis、RabbitMQ”大模型可能给你算出80%匹配率因为它把Redis和RabbitMQ当成同类技术做了模糊匹配。但我用工具精确计算这俩就是不同技能匹配率只有50%结果是确定性的可以复现的。工具返回的JSON会回传给模型由模型再组织成自然语言答案。为了引导模型在必要时调用工具提示词里要写清楚“当用户询问薪资、技能匹配率、岗位趋势等数据时你必须先调用对应工具获取数据再基于数据回答。”这背后的原理是有了Tool Calling之后Spring AI会把用户消息、工具描述和调用结果一起放进上下文里模型看到的是“我调用了工具工具返回了这个结果”接下来它要做的就是基于事实进行语言组织而不是凭空猜测。3.4 工具选择的兜底策略实际项目里一个棘手问题是模型有时候会自作主张不调用该调的工具而是用知识库里的文档硬答。比如用户问“2024年Java平均薪资”模型要是没触发工具调用可能拿2022年的文档数据直接回答。我的解决方案是设置了一个校验Advisor在模型返回之后、输出给用户之前检查回答中是否包含了关键的数字或者比例如果发现回答里的数据没有对应的工具调用记录就强制要求模型重新生成并且提示“请先查询实时数据不要使用过时的文档信息”。这个兜底策略在实测中减少了至少70%的“幻觉式回答”。但代价是多一次模型调用响应时间会变长300-500ms。在项目里这个代价是值得的因为岗位分析场景容错率很低给HR一份薪资数据错了就是误导决策。4. 系统集成的完整流程与关键代码4.1 从“查知识库”到“调工具”的串联逻辑前面分别讲完了RAG和Tool Calling各自的能力这一步把它们串起来。系统整体的处理流程是这样的用户输入岗位描述比如“帮我分析Java架构师的岗位要求和市场情况”系统先做意图识别这个问题需要检索知识库吗需要调用工具吗如果需要知识库执行向量检索重排序把Top-3文档作为上下文如果需要工具让模型协调工具调用Spring AI内部通过ChatClient的.tools()方法启用收集所有上下文和工具结果让模型生成最终分析报告对应的Java代码是这样Service public class JobAnalysisService { private final ChatClient chatClient; private final VectorStore vectorStore; private final ToolCallback toolCallback; public AnalysisResult analyze(JobAnalysisRequest request) { // 检索知识库 ListDocument knowledgeBaseDocs vectorStore.similaritySearch( SearchRequest.builder() .query(request.jobDescription()) .topK(5) .similarityThreshold(0.65) .build() ); // 构建提示词注入知识库上下文 PromptTemplate template new PromptTemplate( 你是一位资深的岗位分析顾问。请基于以下参考资料和工具数据 对用户的岗位分析请求给出结构化分析报告。 参考资料 {knowledgeBase} 用户请求{userQuestion} 注意 1. 必须基于参考资料作答如果参考资料没有相关内容明确说明“未找到相关数据” 2. 涉及实时数据薪资、趋势、匹配率时必须先调用工具获取 3. 每个结论后面标注信息来源 ); // 组装消息 ChatClient.ChatClientRequest requestSpec chatClient.prompt() .user(u - u.text(template.render( Map.of(knowledgeBase, formatDocs(knowledgeBaseDocs), userQuestion, request.question()) ))) .tools(toolCallback) // 启用工具调用 .system(s - s.text(你是岗位分析专家回答要客观、可追溯。)); // 执行调用 String response requestSpec.call().content(); return parseResponse(response, knowledgeBaseDocs); } }这里有个关键参数similarityThreshold相似度阈值我设了0.65。太高了相关文档会被过滤掉太低了检索出的文档跟问题关联度不够模型会去“强行引用”不相关内容反而增加幻觉概率。具体阈值要根据Embedding模型和领域数据调我用一批标注好的问答对跑了两轮测试最终定在0.65。4.2 提示词设计的几个关键约束提示词是整个系统效果的最直接影响因素之一比模型选型还重要。我迭代了好几版提示词沉淀出几个要点。要点一明确告诉模型“不知道就直说”。岗位分析场景里最忌讳的就是模型明明没数据还强行编一个数据。所以在提示词里专门加了一句“如果参考资料中没有相关内容必须明确说明‘未找到相关数据’禁止编造”。要点二要求每个结论标注来源。因为RAG流程中可以定位到具体文档我要求模型在生成报告时在关键结论后面用[来源xxx公司2024年Java岗位分析文档]这种格式标注。这让报告的可信度和可用性提高了一个量级HR能直接点进去核验。要点三规定输出格式。我让模型按“岗位概述、核心技能要求、匹配度分析、市场薪资参考、招聘趋势建议”五个小节输出。结构化输出方便下游展示也方便用户扫读。这里的教训是提示词不要试图“教”模型做事要把边界说清楚。你要做的不是告诉它“你很聪明、你很专业”而是告诉它“什么能做、什么不能做、输出长什么样”。4.3 对话记忆与多轮交互岗位分析不是一个一次性问答HR往往会追着问“那同样条件下3年经验的薪资呢”“如果候选人换到杭州匹配度会变吗”这些追问需要系统保持对话上下文。Spring AI提供了MessageChatMemoryAdvisor我配合一个简单的内存聊天记忆实现ChatMemory chatMemory new InMemoryChatMemory(); ChatClient chatClient ChatClient.builder(chatModel) .defaultAdvisors(new MessageChatMemoryAdvisor(chatMemory)) .defaultAdvisors(new ReRankingAdvisor()) .defaultAdvisors(new SourceValidationAdvisor()) .build();有两点实际经验第一内存聊天记忆只适合单机演示。一旦部署到多实例环境需要换成Redis等分布式存储否则用户请求负载均衡到不同实例时上下文就丢了。第二要限制对话轮次的记忆长度我设的是最近10轮。否则上下文塞满了历史对话影响模型对当前问题的关注度也会推高token成本。4.4 异步处理与流式输出岗位分析报告生成通常要5-15秒如果同步等待用户会以为系统卡死了。所以最终我用Spring的WebFlux SSE做异步流式输出模型生成一点内容页面就显示一点。这里要单独提一个坑如果上层用的是Spring MVC底层模型又是阻塞式API那就别强行用WebFlux。我一开始为了让方案“看着高级”引入了WebFlux结果两种servlet容器混在一起出现了诡异的线程阻塞问题。后来老老实实用了CompletableFuture异步编排配合SSE输出效果一样好代码还更好维护。技术选型要匹配场景不是越新越好。5. 踩坑实录与问题排查速查表5.1 版本兼容性Spring AI版本号变化的坑Spring AI版本演进非常快API变化也频繁。我建项目时用的是Spring AI 1.0.0-M6中间升到1.0.0 GA光API迁移就花了一天。最典型的旧版的AiClient接口在新版中改成了ChatClient.BuilderToolCallback的注册方式从构造函数手动传入改成了ToolCallbacks注解自动扫描。如果升级版本不是简单改依赖版本号就完事模块结构和配置项都可能变。我的建议是锁定版本不要轻易升级。如果项目没有刚需比如新模型支持、性能提升就在pom.xml里固定版本号。非要升级先跑完一遍全量回归用例重点测工具调用和向量检索这两条链路。5.2 配置项错误静默失败最可怕Spring AI对很多配置项做了“宽容处理”拼错不报错直接走默认值。最坑的有两个一个是Embedding模型的配置。我最早拼错了embedding-model这个配置项前面我自己给自己挖的坑导致Ollama默认用了nomic-embed-text维度768而pgvector建表时按1024维建的。结果插入向量时直接报维度不匹配数据库日志刷了几百行错误才反应过来。另一个是Ollama的base-url如果不加http://前缀Spring AI也能启动但它会去连localhost:11434的默认端口连不上才报错。排查这种问题比报错本身还费时间。建议配置完先打印一次生效的配置快照。如果项目里能上Spring Boot Actuator直接把/actuator/env拉出来对一遍确认配置项拼写、值都对再跑业务逻辑。5.3 检索质量差命中率上不去的排查方向“RAG hit rate”这个热词对应的就是这个问题。我系统上线第一版的时候检索命中率大概只有65%回答里经常出现“查无此项”。排查下来问题出现在三个层面第一切分不合理。我原来把所有文档都用500个token固定切分简历里的“项目经历”被切成了两段技能描述被切开语义就不完整了。改为按简历字段结构化切分命中率直接上升10个百分点。第二Embedding模型能力上限。bge-m3虽然中文效果好但和专业领域术语的理解还是比商业API差一些。比如“高可用架构”这种说法它检索的时候可能召回的是“系统稳定性”相关的文档而不是“容灾架构”相关的文档。这个没法完全靠调参解决要么换成更强的Embedding模型要么在检索阶段增加关键词辅助召回。第三查询意图不清晰。用户经常问“这个岗位怎么样”这种模糊问题向量检索很难命中。我的做法是加了一个查询改写步骤先用模型把模糊问题扩展成多个具体的检索子问题再分别去知识库检索。这一步对最终效果提升明显。5.4 工具调用失败Model返回参数不匹配Tool Calling不是一个“开箱即用”的功能模型调用工具时可能产生几类问题类别一参数格式错误。模型生成的JSON参数跟工具定义的Schema不匹配比如定义的是requiredSkills模型传了skills。这个问题可以通过给工具的description写得更详细来缓解。我在工具描述里明确写了参数示例“requiredSkills: 必须是字符串列表例如 [Java, Spring Boot]”。类别二死循环调用。有一次模型反复调用同一个工具返回结果之后又继续调循环了好几次token消耗爆炸。排查发现是模型认为工具返回的数据“不够精确”想通过反复调用来获得更准确的答案。我的解决办法是在系统提示里加了一句“如果工具已经返回结果请直接基于结果作答禁止重复调用同一工具。”类别三模型不知道什么时候该调工具。这个前面提过用校验Advisor做兜底。5.5 本地模型推理慢性能优化思路用Ollama部署7B、14B模型在普通GPU机器上推理速度很不理想。岗位分析报告要生成五段内容14B模型可能跑30秒以上用户体验很差。我做了三件事优化第一量化模型。Qwen2.5-7B的Q4_K_M量化版在4G显存下也能跑推理速度比FP16快近1倍回答质量差距可接受。第二小模型负责工具调用大模型负责最终报告。工具调用因为只需要理解意图、生成JSON参数用Qwen2.5-3B就够了。最终生成报告时再把上下文切给7B模型。这样整体延迟从35秒降到了12秒左右。多模型协同有一个前提就是对话上下文必须完整传递不然小模型理解不了后续意图。第三流式输出缓解等待感。这个前面说过了不再赘述。6. 常见问题速查表与扩展方向6.1 问题速查表为了方便遇到同样问题的同学快速定位我把踩过的坑整理成了一张速查表问题现象可能原因排查方法解决方案启动时报向量维度不匹配Embedding模型维度与VectorStore配置不一致对比两个配置的维度数统一模型和配置或者重建向量表检索结果相关性很差切分策略不合理打印切分后的文档样本人工检查语义是否完整按文档结构定制切分策略模型回答不调用工具提示词没有明确工具使用边界查看模型调用日志确认工具列表是否正确加载在提示词中写明“必须调用工具的触发条件”工具返回参数格式错误模型的JSON输出与工具Schema不一致在日志中打印模型原始工具调用参数在工具描述中补充参数示例和格式说明多轮对话上下文丢失部署多实例内存聊天记忆不共享查看负载均衡下不同实例的处理日志换成Redis分布式聊天记忆对话速度太慢模型过大或推理设备性能不足查看模型推理耗时统计换量化模型或小模型拆流程回答出现编造数据RAG检索不到相关内容模型被“逼”编答案检查检索日志确认是否有Top-K文档被召回提高相似度阈值增加“不知道就直说”的提示6.2 后续可以扩展的方向这套系统目前的架构是标准的三段式RAG做静态知识检索Tool Calling做动态数据获取大模型做自然语言组织和分析。跑通之后其实还有一些值得继续深化的方向。一个是把岗位分析从“单点问答”升级成“Agent式任务编排”。比如HR可以这样下指令“帮我筛选这30份简历中符合Java架构师岗位的前5名并为每个候选人生成优劣势报告。”系统拆解任务后自动调用简历解析工具、技能匹配工具、岗位比对工具最后汇总输出。这个方向对应的是agentic RAG的思路也是Spring AI Agent目前重点推进的场景。另一个是引入知识图谱做“Ontology RAG”。岗位和技能、行业和岗位、技能和薪资之间存在大量显式的实体关系用向量检索是“模糊匹配”用知识图谱查询是“精确关联”。把两者结合岗位分析系统对“3年Java经验熟悉Spring Cloud在上海”这类复合条件的回答会更精准。第三个方向是引入GraphRAG对行业报告这类长文档做摘要级别的知识索引。GraphRAG做的是“先理解文档结构再建立实体关系图”适合回答“这个行业里哪些技能需求在上升”这类需要全局视角的问题。我个人觉得RAGTool Calling这套组合目前的实用价值是很高的它不依赖某个特定模型、能本地部署、能解释结果来源对很多企业场景已经够用了。至于Agent化、图谱化属于“进一步优化”而不是“必须马上做”的事情。说回实际操作。我给朋友的SaaS系统实际上线之后HR那边反馈最好的功能是“匹配度分析”的输出——以前人工要花半小时看一份简历才能得出的结论现在30秒就出来了而且每个结论都能追溯到原始简历或者JD文档。这个效果本身就是对整套方案最好的验证。最后再分享一个小实践如果模型输出质量不稳定不要急着换更大的模型先检查你的提示词和工具描述是否足够清楚。我调了三轮提示词把“什么时候调用工具、输出什么格式、不知道说什么”写明白之后本地7B模型的效果在关键指标上已经接近云端商用模型了。大模型应用开发的难点从来不在“调用API”而在“把上下文组织得让模型容易输出正确结果”。