2016 年 3 月AlphaGo 与李世石五番棋的第二局第 37 手落在棋盘的中腹。现场解说的第一反应是“这手棋是不是失误了”但职业棋手反复拆解之后发现那不是失误而是 AI 在人类棋谱之外自己算出来的一种更开阔的落法。Move 37 从此成了 AI 历史上的一个象征系统不再只是按规则执行命令而是开始生成人类没有写进规则里的答案。今天再看这个瞬间我觉得它更像是“AI 突然无处不在”的起跑线。代码补全、AI Agent、大模型部署、智能体开发、Spring AI 这类框架、Credits 计费……这些词密集出现在技术社区和招聘要求里本质上都是同一件事AI 正在从“演示能力”进入“工程落地”。这篇内容不准备复述围棋故事而是把 Move 37 式变化拆成开发者真正能用的落地路径包括概念边界、最小可运行方案、参数取舍、部署判断和学习路线。先说结论AI 无处不在不等于 AI 一键解决所有问题。真正值得关注的是你能不能把一个 LLM 接到真实任务里让它稳定地做完一件事。下面按实际落地顺序拆解。1. Move 37 不是远古新闻而是今天每一支 AI 应用团队都在面对的分界线1.1 一个棋局里的“意外落子”说透了 AI 与普通工具的本质区别Move 37 之所以出名不是因为下棋本身而是因为它暴露了 AI 的一种新能力在没有任何人类标注这条路径的情况下模型自己选择了策略。它不是从规则库里查答案而是从大量数据里学到了一个更抽象的模式再用这个模式应对没见过的局面。这个区别放在今天的开发场景里非常明显。普通工具是“输入什么格式输出什么格式”行为可预测。大模型不一样它给的是概率分布一次调用和另一次调用可能给出不同说法。很多人第一次用 AI 编程插件时会有一种错觉觉得它“什么都会”但真到项目里才发现它需要你给它上下文、给它边界、给它验证方式否则它会一本正经地给出错误方案。Move 37 真正教会工程团队的是AI 的“意外答案”既是价值也是风险。价值在于它能绕过惯性思维风险在于你必须用流程把这些意外约束在可接受范围内。1.2 从 AlphaGo 到日常开发AI 的“突然无处不在”到底指什么现在热词里到处是 AI Agent、AI 编程、AI 智能体、AI 应用开发、模型部署、AI 工程实践这些词看起来散其实是同一条链路的几个环节底层是模型能力GPT 类闭源模型、开源大模型、垂直小模型。中间是开发方式API 调用、提示词工程、Agent 编排、RAG 检索增强。上层是交付形态Web 应用、内部工具、自动化流程、智能客服、内容生产管线。外围是工程保障成本控制、日志、评估、版本管理、部署、监控。也就是说AI 突然无处不在不是某一个工具突然成神而是整条链路的基础设施成熟了。过去想做一个智能对话应用要从模型训练开始现在更多团队是从 API 接入、Agent 编排和业务系统集成入手。门槛降低了但工程难度没有消失只是转移到了上下文管理、稳定性和成本控制上。所以下面几个部分我会围绕这条链路来展开。先把概念理清楚再给一条能照着跑的路径最后说部署和排查。2. AI 编程、AI Agent、大模型部署先把概念和边界理清楚2.1 AI 编程不是自动写代码而是“带上下文的结对编程”“AI 编程”是当前最热的落地场景之一Cursor 这类工具也让很多人第一次体会到 AI 直接改代码是什么感受。但这里有一个常见的误解AI 编程不是“你说一个需求它给你一个完整项目”。更准确的描述是AI 编程是一种带上下文的结对编程。你负责拆解需求、审查结果、处理边界它负责根据当前文件内容、项目结构和你的提示生成候选代码。我一般会这样用 AI 编程工具先把任务写清楚不要只说“实现登录”要说清楚技术栈、输入输出、异常处理、是否需要兼容旧接口。再给少量约束比如“不要改数据库表结构”“不要引入新的依赖包”“函数必须带类型注解”。让它生成最小实现而不是一次性生成全部模块。跑测试看报错把报错信息贴回去让它基于真实日志继续改。这里最容易踩的坑是上下文过大或过小。上下文太少AI 不知道你的编码规范上下文太多它可能被无关代码带偏改到不该改的地方。所以我通常会把任务拆成 20 到 40 分钟能验证完的小块一块一块推进。这比“用一条长提示词生成整个后端”靠谱得多。如果你看到“AI 编程提示词”这类热词也别神话它。提示词只是入口真正的效果取决于代码库质量、依赖清晰度和你能不能准确描述失败现象。AI 编程新手最容易犯的错误是接受第一版输出就直接上线完全不看它是否处理了异常分支。2.2 AI Agent从“能聊”到“能做事”的关键转变如果说 AI 编程解决的是“辅助写代码”那 AI Agent 解决的是“让 AI 自己完成任务”。我对 Agent 的定义比较朴素Agent 大模型 工具调用 记忆 循环。它不是一个聊天框而是一个能自己决定下一步做什么的程序。比如你让它“查一下订单状态并给用户写一封解释邮件”它需要先识别出这是一个查库动作再去调用订单查询接口拿到结果后组织语言最后生成邮件草稿。和普通对话相比Agent 最大的变化是引入了工具。模型本身不会查数据库不会发请求不会操作文件但工具调用机制让它可以选择“我该调用哪个函数传什么参数”。这一层是 Agent 能“做事”的关键。对于刚接触 Agent 开发的读者我建议先不要想得太复杂。不要一上来就搭多智能体、规划器、反思机制。先把单 Agent 做稳一个模型循环、几个明确工具、一套清晰提示词这已经能解决很多真实问题。2.3 Spring AI、Credits 这些词背后是两套完全不同的落地方式Spring AI 和“Credits”这两个词经常一起出现在讨论里但它们说的是不同层面的东西。Spring AI 是 Java 生态里用来集成大模型能力的框架类似把 OpenAI、通义千问、文心一言等模型 API 抽象成统一接口让 Java 开发者不必关心每家厂商的请求格式差异。如果你的技术栈是 Spring Boot又不希望团队为每个模型写一堆 HttpClient 封装那这类框架确实能省事。但要注意框架只是封装了调用不改变底层模型的能力边界。Credits 则是模型平台或第三方 API 平台里的计费单位。国内很多模型服务按 Token 计费也有一些聚合平台按 Credits 计费1 次调用消耗多少 Credits通常由输入 Token、输出 Token、模型档位、是否使用图片或音频能力共同决定。我见过不少团队在 Credits 上栽过跟头开发时用小模型测试上线前换大模型结果开销突然涨了十几倍。所以只要涉及 Credits就必须先回答三个问题每次请求平均消耗多少 Credits高峰期并发是多少峰值时每小时要花多少Credits 有没有过期时间、额度限制和超额熔断机制这里给一个保守建议用一个专门记录 Token 和费用的中间层或者至少在日志里输出每次请求的 usage 字段。如果没有这个数据你会在第一个月账单出来后才意识到成本失控。3. 从提示词到最小 AI 应用一条可以照着跑的落地路径3.1 第一步先跑通一个带上下文的 AI 编程工作流不要一开始就想着写完整应用。先在一个小项目里把 AI 编程工作流跑通比如“读取一个 CSV 文件统计缺失值输出一个摘要报告”。我建议的验证顺序是这样的准备环境确认 Python 或 Node 版本、依赖管理工具、能访问模型 API 的凭据。把模型接入 IDE 或命令行工具先用最简单的对话确认密钥有效。给 AI 一个小任务要求它只返回代码不解释。运行它生成的代码把报错原样贴回去让它修正。重复直到通过。这个流程看起来很基础但它能帮你在进入 Agent 开发之前先摸清三个关键点模型 API 的响应格式、上下文窗口够不够、你描述问题的能力够不够。很多人跳过这一步直接写 Agent结果连“API 返回 401”都排查很久。不是能力不行而是连最基本的请求通路都没有验证过。3.2 第二步用一段最简代码搭一个能调用工具的 Agent下面这个示例是我在项目里常用的 Agent 雏形。它演示的是“模型决定调用哪个工具拿到结果后生成最终回复”的标准循环。代码里的细节是示意实际使用时要按你的模型接口调整。from openai import OpenAI client OpenAI(api_keyyour-api-key, base_urlyour-model-endpoint) tools [ { type: function, function: { name: search_order, description: 根据订单号查询订单状态, parameters: { type: object, properties: { order_id: {type: string} }, required: [order_id] } } } ] def execute_tool(name, arguments): # 这里接你的真实业务逻辑 if name search_order: return {status: 已发货, order_id: arguments[order_id]} return {error: unknown tool} def run_agent(user_input): messages [ {role: system, content: 你是客服助手。需要查订单时调用 search_order查完之后再回答用户。}, {role: user, content: user_input} ] # 第一轮让模型决定是否调用工具 first client.chat.completions.create( modelyour-model, messagesmessages, toolstools ) msg first.choices[0].message # 模型没有调用工具直接返回 if not msg.tool_calls: return msg.content # 模型决定调用工具把请求结果放回对话 messages.append(msg) for call in msg.tool_calls: result execute_tool(call.function.name, call.function.arguments) messages.append({ role: tool, tool_call_id: call.id, content: str(result) }) # 第二轮模型基于工具结果生成最终回复 second client.chat.completions.create( modelyour-model, messagesmessages ) return second.choices[0].message.content print(run_agent(用户说订单 A10086 一直没收到帮我查一下状态))这段代码表达的是 Agent 最核心的循环先让模型看用户输入再让它决定要不要调用工具最后把工具结果交还给模型生成回复。真实生产里还需要补上错误重试、超时保护、日志记录和敏感操作提醒但整体骨架就是这样。我自己在带新人时一定会让他们先把这段循环写出来再谈别的。因为多智能体、记忆机制、规划器最后都会回到这个基础循环模型思考、调用工具、拿到结果、再看下一步。3.3 第三步把它变成真正能用的应用最简 Agent 跑通之后再往应用方向扩展。这里有几个常见方向需要对外提供服务用 FastAPI 或 Spring Boot 包一层 HTTP 接口设计请求体和返回体。需要多轮记忆把历史消息存到数据库或 Redis每次请求带上最近 N 轮对话。需要处理文件加文件解析工具比如 PDF、CSV、Excel让 Agent 有权限调用这些解析函数。需要稳定输出格式要求模型返回 JSON并在代码里做 schema 校验解析失败就重试一次。这一步最需要注意的是输出一致性。模型生成的内容是自然语言直接原样返回给用户时产品体验可能不稳定。更好的做法是定义清晰的输出结构让模型按结构返回再用代码强制校验。比如客服场景你可以定义返回值包括status成功/失败、answer给用户的回复、need_human是否转人工。这样下游逻辑就能根据结构化字段做判断而不是靠正则去猜语气。4. AI 应用开发的环境、参数和验证标准4.1 环境准备模型选型、依赖版本、密钥和网络条件进入 AI 应用开发之前先把环境问题解决。很多项目卡住不是因为模型不行而是前置条件没检查。我一般按这个顺序检查确认开发语言和框架版本。Python 建议 3.10 以上Java 项目要注意 Spring Boot 版本和 Spring AI 的兼容关系。确认依赖安装是否完整。凡是报ModuleNotFoundError或No such method先看是不是版本冲突。确认 API Key 或访问凭据有效并且有足够额度。不要拿生产密钥写死在代码里环境变量或密钥管理服务更稳。确认网络条件。模型 API 通常是外网或厂商专有网络本地开发环境能不能连通、有没有防火墙限制必须先测通。确认磁盘和内存。如果涉及本地模型还要确认显存和内存不要以为 8GB 显存能跑所有模型。环境问题有一个共性报错信息经常不直接指向根因。比如超时可能是网络问题也可能是模型服务端负载高还可能是你的请求体太大。所以排查时不要只看最后一屏要把请求发出时间、响应时间、错误码和重试次数一起看。4.2 核心参数Context、Temperature、Retry、超时大模型 API 的参数不多但每个参数都影响结果。我把最常用的几个整理成表参数作用常见建议model选择模型档位开发阶段用小模型上线前用强模型或做 AB 对比temperature控制随机性事实类任务 0 到 0.3创意类任务 0.7 到 0.9不要无脑拉满max_tokens限制输出长度按业务需要设置避免生成长文导致成本上升context 窗口决定能带多少上下文超长文档要分段或使用向量检索不能硬塞timeout单次请求超时建议按业务容忍时间设置比如 10 到 30 秒retry失败重试次数建议 2 到 3 次配合指数退避避免打爆模型服务这里我想特别强调 temperature。很多人以为调大 temperature 就能让 AI“更有创意”但代价是输出不稳定可能导致 JSON 格式错乱、事实漂移、甚至胡说八道。做代码生成、结构化输出、数据抽取我基本都控制在 0.2 以下。另外重试机制要有但不是所有失败都值得重试。如果是 429 限流或 5xx 服务暂不可用可以重试如果是客户端参数错误、鉴权失败重试一百次也没用。所以在代码里先区分错误类型再决定是否重试。4.3 怎么看“跑通了”功能、稳定性、成本三个维度一个 AI 功能跑通不能只看“它回应了”。要有可量化的判断标准。功能层面输入是预定义的测试样例输出是否符合预期格式关键字段是否完整是否出现了答非所问。稳定性层面同一条输入连续调用 10 次结果能不能保持语义一致。这个测试非常重要因为模型的输出天然有波动如果你的业务不允许波动就要在提示词里加约束或者在输出层做后处理。成本层面记录每次请求的 Token 消耗、响应时间和错误率。我一般会在本地测试阶段就打印 usage 字段顺便算一下如果每天调用 10 万次大概要花多少钱。这个数字比任何性能指标都更能决定项目能不能长期跑下去。跑通之后再考虑批量任务。批量任务有一个原则先小批量再大批量。先跑 5 条确认输出和日志正常再跑 100 条观察失败率和耗时最后再上并发。不要一上来就开最大并发否则一旦提示词有 bug你会收获几千条同样错误的输出。5. AI 模型部署与工程实践能跑 Demo 和能上线是两回事5.1 本地部署还是 API 调用先看四个指标模型部署是 AI 工程实践里分歧最大的环节。有人坚持本地部署开源模型认为数据安全有人全部走 API认为省心。我建议不要先站队而是用四个指标来判断指标本地部署厂商 API数据隐私数据不出内网可控性强取决于服务协议和是否使用私有化方案初始成本需要 GPU 服务器、运维成本按量付费启动门槛低延迟取决于硬件和模型大小网络往返 服务端排队能力迭代依赖自己升级模型厂商更新模型自动可用对大多数中小团队来说先接 API 跑通业务是最稳妥的方式。只有当你对数据出域有硬性要求或者调用量足够大、单次成本明显高于自建时再考虑本地部署。本地部署开源模型不是“更高级”它只是另一种成本结构。如果决定本地部署优先确认三个点模型权重文件是否完整、显存是否够用、推理框架版本是否匹配。常见坑包括模型下载到一半导致文件损坏、量化版本和框架不兼容、显存刚好只够跑一次推理但一上并发就 OOM。5.2 工程化必须补的三块日志、评估、提示词版本管理AI 应用和普通应用最大的不同是它的输出不能靠“对不对”简单判断。所以工程化要做三件专门的事。第一日志要记录输入和输出。不只是记录“调用了模型”还要记录完整的 prompt、模型返回、Token 消耗、耗时和错误类型。没有这些日志线上出了问题你根本不知道模型看到了什么。第二要有一个评估集。不需要很大20 到 50 条代表性用例就够。每次改提示词、换模型、调参数都跑一遍评估集看输出质量是否下降。这一步能防止“修复一个问题破坏三个场景”。第三提示词要版本化。提示词是会变的把它当成代码一样管理每次修改都要记录变更原因并和评估结果关联。最稳妥的做法是提示词模板和策略配置放在独立目录不硬编码在业务代码里。5.3 批量任务和并发控制的常见坑批量任务和并发是 AI 应用从 Demo 走向生产的必经关卡。这里有几类常见问题限流模型服务有 QPS 限制并发太高会触发 429需要做请求排队和退避。输出文件命名冲突多条任务同时写结果时如果命名规则不包含任务 ID会互相覆盖。部分失败单条任务调用失败后不应该让整个批次中断。要记录失败原因单独重试。幂等性如果网络超时但实际已经处理成功重试会导致重复扣费和重复输出所以任务要有唯一 ID。建议用任务队列代替裸并发。每条任务带上 ID、输入、状态、重试次数和输出路径。脚本跑完后根据状态字段统计成功、失败、重试三类数量。这个设计虽然多花一点时间但对任何批量场景都值得。6. AI 学习路线和避坑清单6.1 给不同背景的人一个路线参考AI 应用开发学习路线经常被讲得很复杂。按我的经验路线不需要长但顺序不能乱。如果你是从前端或后端转过来的开发者路线可以这样安排先理解大模型的基础概念Token、上下文、温度、Prompt。学会调用至少一个模型 API跑通一个最简单的对话。学习结构化输出让模型返回 JSON并在代码里校验。学习检索和上下文管理用向量数据库给模型补充私有知识。学习 Agent 工具调用自己实现一个能调函数的循环。学习工程化日志、评估、成本、部署、监控。如果你是产品经理或非技术背景路线可以更短先理解模型能力边界再做需求拆解重要的是学会把用户问题拆成“哪些部分必须写规则代码哪些部分可以交给模型”。如果你是 Java 技术栈可以重点关注 Spring AI 这类框架但不要只看框架文档还是要理解它背后封装的模型 API、工具调用和消息历史机制。6.2 踩过几次坑之后我会优先检查的五个点在 AI 应用开发里很多问题看起来像模型能力不足实际是别的原因。我现在的排查顺序固定是这样先看输入文件格式、编码、路径、内容是否完整。模型报错经常是因为你喂进去的数据本身就是脏的。再看密钥和环境有没有权限、额度是否用尽、网络能否连通。再看依赖版本模型 SDK 和框架版本是不是太旧或者和当前接口不兼容。再看参数temperature 是不是太高超时是不是太短重试次数是不是太多。最后才怀疑模型本身换一个更简单的样例排除业务逻辑干扰后单独验证模型输出。这套顺序帮我解决过大量“看起来玄学”的问题。其实大部分都不是玄学只是排查顺序不对。6.3 哪些场景不该急着用 AI说完了怎么做最后说说什么场景不推荐用 AI。如果你的任务有明确规则、固定流程、输入输出完全可枚举那写普通代码更合适。比如状态机流转、金额计算、权限校验这些场景用 AI 只会引入不确定性。如果你的输出必须绝对确定不允许任何格式偏差那也要谨慎。比如医疗、法律、金融领域不是不能用 AI而是必须有人工复核、输出校验和明确的责任边界。如果你只是临时处理一个小数据文件也不需要为一个 CSV 接一个 Agent。用现成脚本处理完比调模型更快更稳。AI 的“Move 37 时刻”之所以震撼是因为它跨越了那条“人类预期”的边界。但在工程世界里越是有意外能力的系统越需要更强的约束和验证。今天做 AI 应用不需要每个人都从零训练模型但每个人都应该学会给模型搭好上下文、接好工具、盯好成本、写好日志。我个人的建议是先把单任务跑稳把日志和评估建起来再考虑批量、Agent 编排和部署。Move 37 的意义不在于那一手棋而在于它提醒我们AI 的价值往往藏在预期之外但工程的价值恰恰是把预期之外的答案安全地接住。