前段时间外媒一篇报道里被 AI 转型影响到的工人说了一句话“I feel like I dug my own grave”翻译过来就是“我觉得我给自己挖了坑”。这句话出现在不少技术社群的讨论里也戳中了很多开发者的焦虑点AI 能力越来越强我们辛辛苦苦掌握的技能会不会在几年内变得不值钱我做的自动化工具是不是最终会代替我自己这篇文章不打算贩卖焦虑而是想从一个更落地的视角来聊这件事。我会先拆解“AI 转型”到底在转什么然后给你一条完整的技术升级路径从环境搭建、提示词工程、大模型 API 调用到两个可运行的实战项目最后补上常见问题排查和工程建议。希望读完你能有这样一个感受AI 转型不是“挖坑”而是重新修路。1. 先搞清楚一件事AI 转型到底在转什么1.1 新闻里的工人和技术圈里的我们报道里的工人通常是从事重复性劳动、工作内容容易被规则化的人群。当企业引入自动化系统和 AI 工具后原本需要人力完成的环节被压缩工人觉得“自己亲手把工作流程优化掉了”于是产生了“给自己挖坑”的无力感。技术圈也存在类似现象。程序员写脚本解放重复劳动结果脚本越写越多团队发现很多需求不需要那么多人手动实现了。但程序员和流水线工人有一个关键区别程序员本身就是能够理解、改造、维护这套系统的人。也就是说技术人受到的冲击和拥有的机会是同时出现的。1.2 AI 转型对技术岗位的三类冲击为了不把“AI 替代人”这个话题说得太笼统我们把冲击拆成三类冲击类型具体表现受影响岗位举例重复编码类通用 CRUD、页面搭建、单元测试生成可以被 AI 快速完成初级后端、前端页面开发流程编排类多工具联动、数据搬运、定时报表等自动化工作被 AI Agent 替代运维脚本维护、数据分析师知识查询类文档检索、代码解释、错误排查等可以通过大模型对话完成技术支持、部分测试岗位可以看到越是标准化、越容易被描述成“规则”的工作越容易被 AI 处理。反过来越是依赖业务理解、架构判断、异常决策和团队协作的工作越难被简单替代。1.3 技术人真正需要关心的转变与其纠结“AI 会不会替代我”不如把问题换成“哪些能力是我掌握后能让 AI 成为杠杆的”这里我总结了四个关键能力方向后面几节会逐一展开利用 AI 编程工具提升开发效率掌握提示词工程能够稳定产出高质量结果学会搭建简单的 AI Agent把多步骤工作流自动化了解大模型部署与 API 集成让 AI 能力进入自己的业务系统。这四个能力不是取代原有技术栈而是在原有技术栈上增加一层“AI 中间层”。这也是本文的核心主线。2. 环境准备搭建一个最小可用 AI 开发环境工欲善其事必先利其器。在写代码之前我们先准备环境。本节会比较基础已经熟悉 Python 和 API 调用的同学可以跳过前两小节。2.1 操作系统与 Python 版本本文示例以常见开发环境为例系统可以是 Windows、macOS 或 Linux。需要确保已安装 Python 3.9 或以上版本。你可以用以下命令检查python --version如果输出类似Python 3.10.12说明版本满足要求。如果尚未安装建议从 Python 官网下载对应安装包或在 Ubuntu 中使用apt install python3。2.2 安装 Python 依赖后续实战案例会用到requests库发起 HTTP 请求以及python-dotenv管理密钥。我们可以先创建一个项目目录并安装依赖。mkdir ai-transition-demo cd ai-transition-demo pip install requests python-dotenv这里我故意不用openai这类官方 SDK因为各家大模型 API 的版本更新很快直接用 HTTP 请求最直观也最容易迁移到不同厂商的模型服务。2.3 准备 API Key 与环境变量调用商业大模型 API 通常需要 API Key。请根据你所使用的模型厂商申请密钥并把它放到.env文件里避免硬编码到代码中。# 创建 .env 文件 touch .env.env文件内容示例LLM_API_KEY你的密钥 LLM_BASE_URLhttps://api.example.com/v1 LLM_MODELyour-model-name这里需要注意不同厂商的base_url和模型名完全不同。https://api.example.com/v1是示例占位符请替换成实际地址。为了方便代码读取我们建立一个简单的配置读取脚本。# 文件路径config.py import os from dotenv import load_dotenv load_dotenv() LLM_API_KEY os.getenv(LLM_API_KEY, ) LLM_BASE_URL os.getenv(LLM_BASE_URL, ) LLM_MODEL os.getenv(LLM_MODEL, )2.4 封装一个通用的大模型调用函数为了后面两个实战案例都能复用我们封装一个chat_completion函数。这个函数会向大模型接口发送对话消息并返回文本结果。# 文件路径llm_client.py import requests import config def chat_completion(messages, temperature0.2, max_tokens1024): 调用 OpenAI 兼容的大模型接口。 :param messages: 消息列表例如 [{role: system, content: 你是一个助手}, {role: user, content: 你好}] :return: 模型返回的文本内容 payload { model: config.LLM_MODEL, messages: messages, temperature: temperature, max_tokens: max_tokens, } headers { Authorization: fBearer {config.LLM_API_KEY}, Content-Type: application/json, } url f{config.LLM_BASE_URL}/chat/completions resp requests.post(url, jsonpayload, headersheaders, timeout60) resp.raise_for_status() data resp.json() # 不同厂商的返回结构可能存在差异这里按常见 OpenAI 兼容格式解析 return data[choices][0][message][content]这个函数有几个值得注意的细节Authorization头使用Bearer前缀这是当前大多数兼容接口的通用鉴权方式。temperature控制随机性做代码生成时建议设置较低值例如 0.2。max_tokens限制最大输出长度避免超长响应造成额外费用。timeout60防止网络请求长时间卡住。到这里环境就准备好了。接下来我们进入主题如何用提示词工程提升 AI 输出质量。3. 提示词工程决定 AI 输出质量的核心很多人觉得自己用 AI 效果不好第一反应是“模型不行”。但实际上很多时候是提示词不够清晰。提示词工程并不是玄学它有一些可以复制的方法论。3.1 为什么提示词这么重要大模型的本质是根据输入的文本序列预测输出。如果你给出的需求含糊模型只能靠猜测补全结果自然不稳定。反过来当你把角色、任务、背景、约束、输出格式都定义清楚模型的表现会立刻提升。我们可以看一个对比。下面是模糊提示词帮我写个登录接口。效果通常是一个平平无奇的代码片段。但如果改成下面这种结构化提示词效果会好很多你是一名资深 Python 后端工程师。请帮我实现一个基于 FastAPI 的登录接口。 需求 1. 使用手机号 密码登录。 2. 密码使用 bcrypt 加密存储。 3. 登录成功后返回 JWT token。 4. 用户不存在或密码错误时返回统一错误码。 输出要求 - 给出完整的 Python 代码。 - 代码中包含必要的注释。 - 同时给出对应的 SQL 建表语句。提示词越具体AII 就越容易生成贴合需求的代码。这里的核心思想是把模型当成一位刚入职、能力很强但对业务一无所知的员工你需要把所有上下文交代清楚。3.2 高质量提示词的五个要素我习惯把高质量提示词拆成五个部分要素说明示例角色告诉模型它应该以什么身份回答问题“你是一名资深数据库管理员”任务明确要完成的具体动作“对下面 SQL 做性能分析”上下文提供背景信息、表结构、业务规则“这是订单表按月分表”约束说明不能做什么、必须做到什么“不要修改查询结果只优化索引”输出格式让结果结构整齐便于程序解析“使用 JSON 返回”当你在实战中不断套用这五个要素会发现提示词逐渐变成了一种“模板工程”。3.3 让 AI 输出稳定 JSON在很多工程场景里我们不仅需要 AI 生成文本还需要它生成可解析的结构化数据。最常见的做法是要求模型输出 JSON。下面是一个示例提示词模板# 文件路径prompts.py JSON_PROMPT_TEMPLATE 你是一个信息抽取助手。 请从用户输入的文本中提取以下字段 - summary: 一句话总结 - keywords: 关键词列表最多3个 - risk_level: 风险等级值为 high / medium / low 要求 1. 只输出 JSON不要输出多余文本。 2. JSON 格式如下 {summary: ..., keywords: [...], risk_level: ...} 用户输入 {user_input} 配合通用调用函数我们可以在代码里这样使用# 文件路径demo_json.py import json import config from llm_client import chat_completion user_input 客户反馈支付成功后未收到短信通知需排查消息队列是否存在积压。 prompt JSON_PROMPT_TEMPLATE.format(user_inputuser_input) content chat_completion([ {role: system, content: 你是一个严谨的信息抽取助手。}, {role: user, content: prompt}, ]) print(模型原始输出:, content) # 尝试解析为 JSON try: result json.loads(content) print(解析结果:, result) except json.JSONDecodeError as e: print(JSON 解析失败, e)注意有些模型会在 JSON 前后加反引号或多余文字比如json {summary: ...}为了兼容这种输出建议在解析前做一次清洗。一个简单的兼容方式是删除所有反引号字符。 python import re def parse_model_json(content: str): # 去除可能的 markdown 代码块标记 cleaned re.sub(rjson|, , content).strip() return json.loads(cleaned)3.4 常见误区误区一提示词越短越好。短提示词虽然省 token但输出不确定性高。误区二一次就想得到完美结果。AI 生成代码后需要人工 review 和二次追问这本来就是流程的一部分。误区三忽视系统提示词。system消息可以用来设定模型的全局行为比在用户消息里反复强调更稳定。4. 实战案例一用 AI 把需求描述转成可复用代码有了环境、API 调用函数和提示词模板我们开始做第一个实战项目输入一段业务需求描述自动生成 Python 函数代码并自动保存到文件。4.1 场景分析在日常开发中我们经常遇到这样的需求把一段自然语言描述变成代码。虽然这类任务 AI 能完成但直接复制粘贴到项目里仍然有风险。我们的目标是做一个“半自动代码生成器”它完成初稿人工负责审查和修改。4.2 完整代码下面代码会调用大模型把用户输入的需求描述转换成代码然后写入到指定 Python 文件。# 文件路径code_generator.py import os import config from llm_client import chat_completion CODE_GENERATION_PROMPT 你是一名资深 Python 开发者。请根据下面的需求描述编写代码。 需求描述 {requirement} 要求 1. 代码必须完整可运行包含必要的 import。 2. 使用函数封装核心逻辑函数名应见名知意。 3. 添加关键的注释。 4. 如果需求涉及文件读写注意处理文件不存在等情况。 5. 只输出代码不要输出解释文字。 输出代码 def generate_code(requirement: str) - str: prompt CODE_GENERATION_PROMPT.format(requirementrequirement) response chat_completion([ {role: system, content: 你是一个代码生成助手只输出代码。}, {role: user, content: prompt}, ], temperature0.2, max_tokens2048) return response def save_code_to_file(code: str, filename: str): with open(filename, w, encodingutf-8) as f: f.write(code) print(f代码已保存到: {filename}) if __name__ __main__: requirement input(请输入需求描述) code generate_code(requirement) print(------ 生成代码预览 ------) print(code) print(----------------------------) filename generated_code.py save_code_to_file(code, filename)运行方式python code_generator.py输入示例实现一个函数接收一个整数列表返回其中出现次数最多的数字。如果有多个数字出现次数相同返回最小的那个。4.3 预期输出与人工审查建议模型可能输出的代码大致如下from collections import Counter def most_frequent_number(nums): if not nums: return None counter Counter(nums) max_count max(counter.values()) candidates [num for num, count in counter.items() if count max_count] return min(candidates)这个结果不算复杂但已经能解决需求。重要的是后面的“人工审查”环节检查边界条件空列表是否返回None是否合理。检查命名项目里是否有类似的命名规范。检查依赖是否引入了不必要的外部库。补充单元测试。我通常会把这个流程理解为“AI 写初稿人做质检和定稿”。让 AI 直接提交到生产分支是不可取的。5. 实战案例二构建一个 AI Agent自动生成 Git 周报第二个案例更接近“AI Agent”的雏形让 AI 根据 Git 提交记录自动生成周报。Agent 不只是简单的一问一答而是能够读取数据、调用工具、生成结构化输出。5.1 什么是 AI AgentAI Agent 可以理解为一个“能调用外部工具的 AI 流程”。它通常包括任务规划拆解目标。工具调用执行命令、读写文件、请求接口。上下文管理把工具结果作为新一轮输入。最终决策生成结论或输出成果。在我们的周报案例里工具是git logAI 负责总结和分类。5.2 获取 Git 提交记录第一步是获取最近一周的提交信息。我们用 Python 的subprocess模块执行 Git 命令。# 文件路径git_utils.py import subprocess from datetime import datetime, timedelta def get_git_log(since1 week ago): cmd [ git, log, --since, since, --prettyformat:%h %ad %s, --dateformat:%m-%d %H:%M ] result subprocess.run(cmd, capture_outputTrue, textTrue, encodingutf-8) if result.returncode ! 0: raise RuntimeError(fgit log 执行失败: {result.stderr}) return result.stdout.strip()调用示例logs get_git_log() print(logs)输出类似3f2a1e2 06-01 10:23 fix: 修复订单超时状态未更新问题 8c9d01 06-01 09:41 feat: 新增优惠券过期提醒 ...5.3 调用 AI 生成周报拿到提交记录后我们构建一个“结构化周报提示词”要求模型按照模块输出总结。# 文件路径weekly_report.py from git_utils import get_git_log from llm_client import chat_completion WEEKLY_REPORT_PROMPT 你是一名技术团队负责人。请根据下面的 git 提交记录生成一份周报。 提交记录 {git_log} 周报要求 1. 按照功能模块分类整理例如新功能、Bug修复、性能优化、文档维护。 2. 每个模块用 1-2 句话概括说明。 3. 最后给出下周建议事项不超过3条。 4. 语言简洁专业。 周报正文 def generate_weekly_report(): logs get_git_log() if not logs: print(最近一周没有提交记录) return prompt WEEKLY_REPORT_PROMPT.format(git_loglogs) report chat_completion([ {role: system, content: 你是一个严谨的技术周报助手。}, {role: user, content: prompt}, ], temperature0.3, max_tokens800) return report if __name__ __main__: report generate_weekly_report() print(report)运行python weekly_report.py5.4 安全性说明这里提醒一句git log是只读命令不会修改仓库安全性较高。但如果你扩展 Agent 功能让它执行git push、删除文件或修改配置就必须做好权限控制和确认机制。工程上有个简单原则Agent 能自动执行的命令一定要限制在最小必要范围内并且留有人工确认开关。你可以进一步扩展这个项目让周报自动推送到企业微信群或钉钉群。把报告内容按日期拆分生成每日站会摘要。将输出保存为 Markdown 文件供团队文档系统使用。6. 常见问题与排查思路在实践 AI 项目时有几个问题几乎是必然会遇到的。我这里整理成表格方便你按图索骥。问题现象常见原因解决思路API 调用返回 401API Key 错误或环境变量未加载检查.env文件是否存在确认密钥是否有效API 调用超时网络不稳定或模型推理过慢增加timeout值重试一次检查模型服务状态返回结果被截断max_tokens设置过小调大max_tokens或要求模型分多次输出JSON 解析失败模型在输出中加入了 markdown 代码块使用正则清洗后再解析生成代码运行报错模型版本差异或缺少依赖人工审查代码安装缺失依赖不要盲目相信生成结果结果总是千篇一律temperature太低适当调高例如 0.7但代码场景建议保持低值上下文太长超出模型限制传入的日志过多截断日志提取关键信息后再发送排查时建议按照“日志 → 复现 → 定位 → 修复 → 加防护”的顺序来。不要在不确定原因时反复修改提示词那样容易陷入盲目调参。7. 最佳实践与工程建议7.1 将 AI 能力纳入代码审查流程AI 生成代码之后必须经过 review 才能进入主干。建议采用“双人复核”机制AI 只是候选人最终批准权始终在人手里。团队里可以约定一个简单的检查清单[ ] 功能是否符合需求[ ] 边界条件是否覆盖[ ] 是否有安全隐患[ ] 是否引入不必要的依赖[ ] 是否有配套测试7.2 密钥管理与安全边界调用大模型 API 时密钥是敏感信息。请做到以下几点不要把 Key 写死在代码里。使用环境变量或专门的密钥管理工具。如果使用 Git 仓库确保.env已被加入.gitignore。给密钥设置调用额度和权限范围避免泄露后造成不可控损失。7.3 控制成本与性能大模型 API 是按 token 计费的。在工程化使用中要尽量降低请求量。常见做法对相似请求做结果缓存。能用小模型完成的简单任务不要用大模型。把长期不变的上下文提前写入系统提示词避免重复发送。合理设置max_tokens不要留太多冗余空间。7.4 打造“领域知识与 AI 工程”的复合能力AI 工具本身很容易学会真正拉开差距的是“领域理解 AI 工程”。举个例子同样是写“优化慢查询”一个懂数据库索引的人和一个只会复制粘贴的人对同一段 AI 输出判断完全不同。所以我建议你在 2025 年后的技术规划中同时做两件事加深主业继续深入学习操作系统、数据库、网络、架构设计等硬核知识。拓展 AI 能力掌握提示词工程、Agent 开发、模型部署、RAG 应用等新方向。把这两者结合起来你就不再只是“会用 AI 的人”而是“能用 AI 解决复杂业务问题的工程师”。7.5 个人学习路线参考如果你完全不知道下一步学什么可以参考这个顺序熟练使用一款 AI 编程工具例如 GitHub Copilot、Cursor 或通义灵码。学会写结构化提示词并用 Python 调用大模型 API。做一个自动化小工具例如日报生成器、代码生成器。学习 RAG检索增强生成把公司文档接入大模型。尝试自己部署一个开源模型理解推理资源与工程成本。每一步不需要做到精通但必须做出一个能运行的项目。项目经验比零散知识更有价值。8. 总结回到开篇那句话“I feel like I dug my own grave”。AI 转型确实会淘汰一些重复性工作也会让某些曾经“稳定”的技能快速贬值。但如果你愿意把注意力从“是否被替代”转移到“如何利用 AI 产生更大的价值”那这条技术路线的主动权就会回到自己手里。这篇文章涉及的内容从一个最小可运行的大模型 API 调用到提示词模板再到代码生成器和 AI 周报助手本质上都是在说同一件事AI 不是魔法而是一种需要工程化使用的基础能力。你可以从今天开始把某个日常开发中的小流程拆出来尝试用 AI 去改造它并持续迭代。下一篇的 AI 应用实践可以继续向 RAG 知识库问答、私有模型部署或 Agent 多工具协作方向深入。建议动手写一个自己的项目遇到问题回到本文的排查清单里找思路。