汽车普及之后马并没有立刻灭绝。消失的是“用马拉车运输”这一整套任务组合而围绕马出现的职业比如马车夫、马掌匠、马具商贩都跟着被重新洗牌。今天重新审视这句话——The Day the World Stopped Needing Horses会发现它对理解 AI 和人类工作的关系很有帮助AI 对编程岗位的冲击本质不是“AI 是否取代程序员”而是“程序员的日常任务被重新分配之后哪些工作价值上升哪些工作价值下降”。本文就从开发者的视角把这个话题拆成可操作的工程问题AI 会先接管哪些编程任务开发者需要补齐哪些能力以及如何通过一个真实的最小 Agent 项目把大模型、工具调用、参数调优、故障排查串成一条完整链路。学完以后你可以用它作为评估自身技能方向、设计 AI 应用原型、以及向 AI 工程化转型的参考框架。1. 先看懂替换逻辑当世界不再需要马岗位去了哪里1.1 被替代的是“任务组合”不是“职业”马车被汽车替代不是马这个物种突然消失了而是“用马运输”这种任务组合失去了竞争价值。马的饲养、驯化、钉掌、马具制作这些老技能对应的是马车时代的固定分工。汽车出现后马仍然存在但马的价值从生产工具变成了体育、娱乐、伴侣等新场景需求数量也远不如前。这个类比放到 AI 时代非常准确。一个程序员岗位并不是一个不可分割的整体而是一堆任务的组合写 CRUD 接口、写 SQL、处理 JSON 字段、定位线上 bug、设计表结构、评估需求成本、和产品经理确认边界、发布上线、处理事故。不同任务的自动化难度差异很大AI 对它们的替代速度也完全不同。判断 AI 对某个岗位的影响应该先把岗位拆成任务再逐项评估。编程任务AI 当前能完成的程度人类仍需投入的重点写 CRUD 接口可以生成初稿尤其是结构清晰的业务代码表结构设计、字段语义、数据一致性写单元测试能根据函数签名生成测试用例边界条件设计、断言是否真正有效写 SQL 查询能生成常见查询和索引建议数据模型、慢查询分析、余额等敏感数据校验排查 bug能定位报错、给出怀疑方向日志链路分析、真实业务影响判断需求评估能整理出需求的文字描述成本、风险、技术债、排期取舍这张表说明一件事AI 替代的是“任务组合”里那些输入输出明确、反馈速度快、失败代价低的部分。真正难替代的是“目标不清晰时如何定义目标”“多个方案冲突时如何取舍”“系统出问题时如何决策”这类工作。1.2 判断一个任务是否会被 AI 接管的三条标准面对一个新的工作内容可以先用三条标准判断 AI 会不会很快占据主导输入是否明确如果输入是一段需求描述输出是一段代码路径很清晰那么自动化概率高。如果输入是模糊的“提升注册转化率”输出需要大量业务判断自动化概率就低。反馈是否快速写代码后立刻能编译、能跑测试、能看结果这类反馈闭环非常适合 AI 反复试错。而调整系统架构、推动跨团队协作反馈周期以周或月计AI 很难独立完成。失败代价是否低AI 生成一段代码写错了本地改一次就好。但 AI 错误判断了生产环境的数据删除权限或者错误回答了用户的合同条款问题代价就完全不同。这三条标准可以直接用来评估自己的日常工作。如果一个任务同时满足“输入明确、反馈快、失败代价低”那么无论它现在叫“初级程序员”还是“AI 训练师”本质上都处于高度自动化的候选区。反过来那些需要搜集背景、判断取舍、承担后果的工作反而是更值得投入的方向。1.3 对开发者最现实的变化岗位不是消失而是转移AI 编程助手普及后很多开发者担心初级编码岗位会消失。更准确的判断是编码本身的需求没有消失但“从零写代码”这部分需求在减少“验证、集成、维护、微调 AI 生成代码”的需求在增加。实际项目中常见的变化包括一个熟悉业务的开发者用 AI 助手能比从前更快地完成数据报表接口但前提是他清楚表的粒度、过滤条件、指标口径。新人用 AI 写出的代码可读性往往不错但当代码报错或性能不达标时如果不懂底层原理排查成本反而更高。团队开始把“提示词”当成代码管理把 prompt 文件提交到仓库做版本回滚因为 prompt 直接影响线上表现。所以对开发者来说真正该焦虑的不是“AI 会不会写代码”而是“AI 写的代码越来越多之后验证它、约束它、把它安全地放进生产环境的工程能力你有没有”。2. 开发者要补齐的四种能力提示词、评测、Agent、部署2.1 提示词工程把业务需求翻译成模型能执行的约束提示词不是简单写一句话而是业务需求与模型行为之间的转译层。一个有用的 prompt 至少包含三部分角色定位、输入输出约束、负面清单。下面是一个最小客服分类示例你是一名客服工单分类助手。输入是一段用户问题输出是一个 JSON字段为 - category: 可选值 [支付, 物流, 退换货, 其他] - summary: 不超过 20 字的问题摘要 - urgent: 布尔值表示是否需要人工优先处理 只输出 JSON不要输出解释。{category: 物流, summary: 快递三天没有更新, urgent: false}这段提示词的每一个约束都有目的角色定位让模型使用客服领域知识输出约束让下游程序可以直接解析负面清单防止模型输出额外解释导致解析失败。在真实项目里prompt 要像代码一样放到版本管理里每次修改都要记录原因并配合下面的评测机制验证效果。很多人误以为提示词只是“问得更清楚”其实它更接近编写规则引擎。使用技巧包括给几个 few-shot 示例、明确分隔用户输入与指令、把动态内容放在固定的占位符区域避免与指令混淆。这些细节在简单 demo 里看不出来但一旦要上线每条约束都可能影响准确率。2.2 评测没有评测模型升级就是一场赌博很多团队在接入大模型时只验证了少数几条用例上线后才发现模型在不同提问方式下表现不稳定。解决这个问题不能靠“更长的 prompt”而要靠一套评测集。评测集可以是一个 JSON 文件每条记录包含输入、期望输出和打分规则[ { id: 1, query: 我的订单显示已发货但一直没物流信息, expected_category: 物流, expected_urgent: true }, { id: 2, query: 怎么修改绑定的手机号, expected_category: 其他, expected_urgent: false } ]有了评测集之后每次升级模型版本、修改 prompt、调整参数都要跑一遍全量评测。重点观察两类指标一是整体准确率可以看分类正确比例二是 badcase 回归也就是之前修过的问题有没有在新版本里复发。没有评测的 AI 项目行为是不可观测的也就不具备上线条件。2.3 AI Agent从生成文本到完成流程如果把大模型当作聊天机器人它的价值很有限。真正有工程潜力的是 Agent模型不只是回答问题而是通过“思考-调用工具-观察结果-再思考”的循环去完成任务。这种结构通常被称为 ReAct 模式。一个典型 Agent 循环包含模型根据用户请求决定调用哪个工具。程序执行工具函数拿到结果。结果以新消息的形式返回给模型。模型根据结果生成下一轮动作或最终回答。要让模型能调用工具必须给模型提供工具描述包括函数名、功能、参数结构。模型本身不执行代码它只负责输出“我想调用某个函数参数是什么”真正执行的是你的程序。这也是 Agent 工程最核心的分工模型负责推理程序负责边界和校验。2.4 模型部署本地运行大模型与接口服务化理解模型部署不是为了自己训练模型而是为了知道线上系统如何消费模型能力。本地部署大模型有几个实际用途数据不出内网、研发阶段调试快、可控成本。早期实验阶段使用本地模型可以减少外部依赖也能顺便观察模型的真实能力边界。常见做法是用 Ollama 等工具把开源小模型跑在本地机器上再通过 HTTP 接口提供服务。工具层面模型暴露的接口与主流大模型服务保持相似结构所以切换成本可控。关键是开发者要理解接口里的几个核心字段模型名、消息列表、工具描述、温度、是否流式输出。理解了这些字段就能在本地完成原型验证再平滑迁移到生产环境。3. 最小实战用本地大模型做一个会调用工具的 Agent3.1 环境准备与验证这一节的目标是跑通一个最小闭环用户输入问题模型判断需要工具就调用工具拿到结果后生成最终回答。为了降低环境依赖使用 Python 与requests 直接调用本地模型 HTTP 接口不引入重量级框架。环境要求组件说明Python3.10 或更高版本requests通过 pip 安装Ollama本地模型运行工具本地模型例如 qwen2.5:3b具体以本机能拉取的模型为准安装 Ollama 的命令在不同操作系统上不一样常见 Linux 与 macOS 环境可以通过安装脚本执行Windows 使用安装包具体以官方安装说明为准。安装完成后启动服务再拉取一个小参数模型ollama pull qwen2.5:3b验证模型是否可用ollama list curl http://localhost:11434/api/tags如果本地模型启动成功curl会返回包含模型列表的 JSON。这里要注意模型体积与生成质量、响应速度直接相关小模型适合验证流程不代表线上最优选择。3.2 项目结构与工具定义创建项目目录agent_demo/ main.py tools.py requirements.txtrequirements.txt只需要一行requests工具定义放在tools.py。为了让模型能够调用每个工具都要有函数实现和结构描述。import datetime import json def get_current_time(): return datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) def calculator(expression): try: result eval(expression, {__builtins__: {}}, {}) return str(result) except Exception as exc: return ferror: {exc} TOOLS [ { type: function, function: { name: get_current_time, description: 获取当前系统的日期和时间, parameters: { type: object, properties: {} } } }, { type: function, function: { name: calculator, description: 计算数学表达式支持加减乘除和括号, parameters: { type: object, properties: { expression: { type: string, description: 数学表达式例如 15*73 } }, required: [expression] } } } ] def execute_tool(name, args): if name get_current_time: return get_current_time() if name calculator: return calculator(args.get(expression, )) return unknown tool: name这里有两个关键点。第一工具描述要足够明确模型是根据 description 决定是否调用工具的描述含糊会导致模型误调用或该调用时不调用。第二calculator里的eval只适合本地原型演示绝对不能原样放进生产环境否则存在严重安全风险后文会专门说明替代方案。3.3 主循环消息组织与工具调用main.py负责组织对话、调用模型、执行工具、循环直到模型给出最终回答。import json import requests from tools import TOOLS, execute_tool MODEL qwen2.5:3b API_URL http://localhost:11434/api/chat SYSTEM_PROMPT 你是一个运行在本地环境中的智能助手。 你可以使用工具获取实时时间或计算数学表达式。 当用户问题需要使用工具时先调用工具等工具返回结果后再回答。 不要编造工具未返回的数字或事实。回答要简洁。 def chat_once(messages): payload { model: MODEL, messages: messages, tools: TOOLS, stream: False, temperature: 0.0, } resp requests.post(API_URL, jsonpayload, timeout60) resp.raise_for_status() return resp.json() def run_agent(user_input): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input}, ] max_iterations 4 for _ in range(max_iterations): data chat_once(messages) msg data.get(message, {}) tool_calls msg.get(tool_calls) if not tool_calls: print(msg.get(content, )) return messages.append(msg) for call in tool_calls: func call.get(function, {}) name func.get(name, ) args json.loads(func.get(arguments) or {}) result execute_tool(name, args) print(f[tool] {name}({args}) - {result}) messages.append( { role: tool, name: name, content: str(result), } ) print(已达最大工具调用次数停止循环。) if __name__ __main__: run_agent(现在几点了)这段代码的关键点有三个。一是max_iterations限制循环次数这是 Agent 工程里的护栏。如果没有这个限制模型可能陷入“反复调用工具但始终不收敛”的循环导致请求要等很久或者号码耗尽。二是工具调用结果以role: tool的角色追加到消息列表这样模型才知道刚才的工具执行结果。注意不同模型服务的消息结构略有差异有些服务不需要name字段落地时以你所用的模型服务端文档为准。三是temperature设置为 0.0让模型输出尽量稳定这在工具调用场景很重要。温度越高模型越可能在应该调用工具时“突发奇想”或者生成不同的参数值。3.4 运行与预期输出执行python main.py如果一切正常会看到类似下面的输出[tool] get_current_time({}) - 2026-07-01 14:30:22 当前系统时间是 2026-07-01 14:30:22。实际时间会是你本机的时间。这个结果说明整个链路已经跑通模型识别到问题需要工具输出了工具调用请求程序执行了 Python 函数并把结果交回给模型生成最终回答。再换一个计算问题验证工具分支run_agent(计算 15*73 的结果)预期会看到模型先调用calculator再基于返回结果回答。如果模型没有调用工具而是直接回答先检查系统提示词是否明确说明“需要工具时调用工具”再确认模型本身是否支持工具调用。4. 关键参数、运行验证与常见坑4.1 核心参数说明参数含义默认行为或常见值设置不当的表现model模型名称根据本地已拉取模型确定模型不存在时接口返回错误messages对话消息列表system、user、assistant、tool 四种角色角色顺序混乱会导致上下文错乱tools工具定义列表可选不传则模型只能文本回复不传工具模型无法发起工具调用temperature采样温度0.0 到 1.0工具场景建议 0过高会输出不稳定参数stream是否流式输出false 便于调试不影响原理解影响用户体验max_iterations应用层循环上限常见 3 到 5 次不设置会无限循环这里要特别强调 messages 的角色顺序。一个正确的 Agent 对话流顺序大致是system、user、assistant可能带有工具调用、tool、assistant最终回答。如果程序把工具结果拼错角色模型可能无法理解调用结果或者发生幻觉。4.2 验证链路不能只看“能跑通”一个 AI Agent 原型是否合格至少要验证四类场景普通问答不需要工具模型直接回答。例如“你好”。工具调用问题必须借助工具才能回答。例如“现在几点”。工具结果异常工具返回错误模型能否如实说明而不是编造一个结果。超出能力范围模型不支持的领域能否说“不知道”而不是强行回答。每个场景都要观察请求日志、工具调用参数、最终回答三个位置。常见做法是在chat_once里打印返回的原始 JSON这样能直接看到模型选择了哪个工具、传入的参数长什么样。4.3 常见问题排查问题现象可能原因检查方式处理建议接口返回模型不存在本地没有拉取该模型或模型名写错执行ollama list确认模型名用ollama pull 模型名拉取模型不调用工具system prompt 没说明可用工具或模型太小打印请求原始消息确认 tools 是否传入在 system prompt 中明确提示必要时使用更大参数模型工具调用参数解析失败arguments不是合法 JSON打印func.get(arguments)用 json.loads 包裹并增加异常处理对话循环不结束缺少 max_iterations 限制或模型连续误调用查看日志是否反复出现 tool_calls增加最大次数限制并终止循环工具结果未被模型采纳tool 消息结构不对或 role 写错检查追加消息的 role 字段参考模型服务端文档修正消息结构回答明显与工具结果不一致幻觉或模型能力不足对比工具返回值和模型最终文本temperature 降为 0在提示词中强调只能依据工具结果回答4.4 关于 AI 幻觉一定要当成工程问题处理AI 幻觉指模型生成看起来合理但实际错误的内容在问答场景很隐蔽在 Agent 场景可能直接造成错误操作。缓解幻觉不能只靠“告诉模型别胡说”需要组合手段降低 temperature减少随机性。把外部数据放入上下文而不是让模型凭记忆回答。在系统提示词中明确负面约束没有工具结果时直接说明无法获取。程序层做校验工具返回结果和模型最终回答可以用规则核对关键字段不匹配则告警。建立评测集把曾经出现幻觉的提问纳入回归用例。幻觉不可能完全消除但工程上可以通过约束、校验、评测把风险控制到可接受范围。凡是 Agent 要执行真实操作都必须做权限和输出双重校验。注意原型中的eval只是演示功能生产环境严禁直接执行模型生成的表达式。推荐使用ast模块解析表达式或者使用专门的表达式计算库并对可用操作符做白名单限制。5. 从原型到生产的工程化清单5.1 可观测性日志、追踪和指标本地原型可以靠print看结果生产环境必须把每次模型调用变成可追踪的数据。推荐记录以下内容请求唯一 ID用于串联用户问题、工具调用、最终回答。模型名称、prompt 版本、temperature 参数。每次请求的耗时、token 数、工具调用次数。工具执行结果是否成功以及关键结果摘要。当次请求是否触发了告警规则。有了这些数据线上出现错误回答时才能回放链路而不是面对一堆模型输出猜原因。AI 项目的排障比传统后端更依赖上下文追踪因为同一个输入在不同 prompt 版本下结果可能完全不同。5.2 安全与权限Agent 能调用的工具就是它拥有的权限。一个搜索引擎 Agent 不需要数据库删除权限一个客服 Agent 不应该访问全部用户隐私字段。工具权限要贯彻最小化原则工具列表按场景拆分不同 agent 进程使用不同工具集。工具函数内部做入参校验不能信任模型传入的参数。涉及写操作、发送消息、资金操作时增加人工确认环节。外部输入与系统指令做隔离防止提示注入。提示注入是一个容易被忽略的问题。用户提交的内容可能包含“忽略之前指令”之类的文本如果直接拼接进 messages模型可能把用户输入当作指令执行。把系统级约束和不可信的外部内容放在不同消息区域并在程序层过滤危险操作是基本要求。5.3 性能与成本大模型接口不是普通数据库查询延迟和成本都要提前规划。常见优化手段缓存相同或相似问题命中缓存后直接返回减少重复调用。流式输出长文本生成使用 stream提升用户感知速度。模型分级简单分类用小模型复杂推理用大模型组合使用控制成本。并发控制设置上限防止模型服务被打满。成本不只包括 API 费用。在本地部署场景模型参数越大对内存和显存要求越高。小团队早期验证建议先用小模型跑通流程再按业务指标评估是否需要升级模型。5.4 发布前检查清单检查项完成标准评测集至少有覆盖正常、边界、异常场景的评测用例提示词版本prompt 文件已提交到版本库有变更记录日志追踪请求 ID、模型名、prompt 版本、耗时均可查询工具权限工具列表最小化危险操作有二次确认输入校验用户输入长度、内容格式有限制输出校验模型返回必填字段程序可解析回滚方案之前稳定版本的 prompt 和模型可快速恢复告警规则错误率、超时率、工具失败率有告警6. 路线图从写代码的人到设计智能系统的人6.1 核心思维转变从“自己实现”到“验证与编排”过去开发者的核心价值在于把需求翻译成代码亲手实现每一个逻辑分支。AI 参与编码后这部分工作的高性价比部分正被快速蚕食。真正稀缺的能力变成把模糊需求拆成模型可执行的任务、设计工具调用边界、验证模型输出质量、控制风险和成本。这个转变不是抛弃编码而是把编码放到更大的系统里考虑。你仍然需要懂数据结构、懂 HTTP、懂数据库但这些知识的作用不再只是“写对一行代码”而是“判断模型生成的代码是否正确、能不能上线、出了问题怎么定位”。6.2 一条可执行的实践路线按照以下顺序推进每一步都能形成独立可展示的成果把提示词当作代码管理。从一个简单分类任务开始建立评测集记录每次 prompt 修改后的准确率变化。完成一个工具调用 Agent。用本文的最小原型做基础加入天气、搜索、数据库查询等工具体会消息循环和参数校验。建立回归测试机制。把测试集接入自动化流程每次修改 prompt 或换模型都跑一遍。了解模型部署基础。学会用本地工具启动模型、查看接口日志、调整模型参数理解延迟、上下文长度、并发之间的取舍。阅读关键文档与论文。重点理解 Transformer 结构、上下文窗口、RLHF 对齐等概念不需要全部读懂但要知道模型能力边界来自哪里。6.3 给正在转型的开发者的一句话建议不要只追框架和工具名追框架永远追不完。真正值得投入的是判断能力判断一个任务能否被 AI 自动化判断一个 AI 输出是否可信判断一个 Agent 方案是否值得上线。汽车时代到来后有人去做司机有人去修公路有人去设计交通规则。AI 时代也一样岗位不是消失是换了一批新岗位。而你最需要的是看到“任务组合变化”这双眼睛然后围绕新的组合重新组织自己的技能树。