首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >当 AI 成为技术人标配工具:覆盖开发、运维、测试、网工全场景

当 AI 成为技术人标配工具:覆盖开发、运维、测试、网工全场景

原创
作者头像
大盘鸡拌面
发布2026-08-16 22:16:55
发布2026-08-16 22:16:55
310
举报

说句大实话:2024 年你还在讨论"要不要用 AI",就像 2015 年讨论"要不要上云"一样,属于已经落后了。问题早就不是用不用,而是怎么用得更深、更稳、更接地气。

我写这篇文章不是为了给 AI 打广告,而是想把我这一年多在四个技术岗位上看到、用过、踩过坑的真实场景掰开揉碎了讲讲。每个岗位我会给一个完整的实战案例,附上能跑的代码,尽量不整虚的。


一、先聊聊"标配"这个词

"标配"是什么意思?不是说每个工程师都得成为 AI 专家,而是说 AI 工具应该像 Git、Docker、Jenkins 一样,成为你日常工作流的一部分,不需要刻意想起,但它一直在那。

我画个图,大家感受一下 AI 在技术全链路中的位置:

看到了吧,不是某个环节用 AI,是每个环节都有 AI 的位置。下面我一个岗位一个岗位地聊。


二、开发岗:AI 不只是写代码,更是你的"结对编程伙伴"

场景:接口参数校验——最烦人但最该做的事

说真的,写 Controller 谁都会,但参数校验这种活儿,又烦又容易漏。漏一个就是线上 P0。我现在的做法是:让 AI 根据接口文档自动生成校验逻辑 + 边界用例。

看个具体例子,一个用户注册接口:

代码语言:javascript
复制
@RestController
@RequestMapping("/api/users")
public class UserController {

    @Autowired
    private UserService userService;

    /**
     * 用户注册接口
     * AI 根据需求文档自动生成的完整参数校验 + 异常处理
     */
    @PostMapping("/register")
    public ResponseEntity<ApiResponse<UserVO>> register(
            @RequestBody @Valid RegisterRequest request,
            BindingResult bindingResult) {

        // 1. JSR-303 注解校验失败的第一道防线
        if (bindingResult.hasErrors()) {
            String errorMsg = bindingResult.getFieldErrors().stream()
                .map(e -> e.getField() + ": " + e.getDefaultMessage())
                .collect(Collectors.joining("; "));
            return ResponseEntity.badRequest()
                .body(ApiResponse.fail(400, errorMsg));
        }

        // 2. 业务层校验——AI 建议补充的边界场景
        // 手机号归属地校验
        if (!PhoneUtil.isValidChinaMobile(request.getPhone())) {
            return ResponseEntity.badRequest()
                .body(ApiResponse.fail(400, "手机号格式不正确或非中国大陆号码"));
        }

        // 密码强度校验——AI 指出弱密码是注册接口最常见的安全风险
        PasswordStrength strength = PasswordUtil.checkStrength(request.getPassword());
        if (strength.getScore() < 3) {
            return ResponseEntity.badRequest()
                .body(ApiResponse.fail(400, 
                    "密码强度不足,建议:" + strength.getSuggestion()));
        }

        // 防刷:同一 IP 60 秒内只能注册一次
        String clientIp = RequestUtil.getClientIp();
        String rateLimitKey = "register:rate:" + clientIp;
        if (!redisTemplate.opsForValue().setIfAbsent(
                rateLimitKey, "1", 60, TimeUnit.SECONDS)) {
            return ResponseEntity.status(429)
                .body(ApiResponse.fail(429, "操作太频繁,请稍后再试"));
        }

        // 3. 调用 Service
        UserVO userVO = userService.register(request);
        return ResponseEntity.ok(ApiResponse.success(userVO));
    }
}

/**
 * AI 生成的请求 DTO,包含完整的校验注解
 * 关键:每个字段的校验规则都有注释说明"为什么这么校验"
 */
@Data
public class RegisterRequest {

    @NotBlank(message = "用户名不能为空")
    @Size(min = 3, max = 20, message = "用户名长度3-20个字符")
    @Pattern(regexp = "^[a-zA-Z0-9_]+$", 
             message = "用户名只能包含字母、数字、下划线")
    private String username;

    @NotBlank(message = "密码不能为空")
    @Size(min = 8, max = 64, message = "密码长度8-64个字符")
    private String password;

    @NotBlank(message = "手机号不能为空")
    @Pattern(regexp = "^1[3-9]\\d{9}$", message = "手机号格式不正确")
    private String phone;

    @Email(message = "邮箱格式不正确")
    private String email;

    // AI 指出:很多团队漏了这一层校验,导致脏数据入库
    @Size(max = 100, message = "昵称长度不能超过100")
    private String nickname;
}

有人可能觉得"这代码我也写得出来啊"。没错,关键不在于你能不能写出来,而在于你每次都能想到这些边界场景吗?密码强度校验忘了、IP 防刷忘了、手机号归属地没查——这种事在 Code Review 里见得太多了。

AI 的价值在于它不会"忘"。你把需求文档丢给它,它每次都会把这些标准动作走一遍。

AI 辅助 Code Review 实战

光写代码还不够,Review 环节也能让 AI 上。我写了个脚本,拿 PR diff 喂给 AI 做自动审查:

代码语言:javascript
复制
import subprocess
import json
import requests

# 获取当前 PR 的 diff
def get_pr_diff(pr_number):
    result = subprocess.run(
        ["git", "diff", f"origin/main...HEAD"],
        capture_output=True, text=True, encoding="utf-8"
    )
    return result.stdout

# 团队编码规范(精简版,喂给 AI 当上下文)
TEAM_CODING_STANDARDS = """
1. 所有外部输入必须经过校验,不允许直接信任前端参数
2. 数据库查询禁止使用字符串拼接SQL,必须用参数化查询
3. 敏感信息(密码、token)不允许出现在日志中
4. 所有 Controller 方法必须有权限注解
5. 循环内禁止执行数据库查询
6. 异常必须分类处理,不允许 catch(Exception) 后吞掉
7. 新增 API 必须有对应的单元测试
"""

def ai_code_review(diff_content):
    prompt = f"""你是一位资深 Java Code Reviewer,请审查以下代码变更。

团队编码规范:
{TEAM_CODING_STANDARDS}

代码变更:
{diff_content[:8000]}

请按以下格式输出审查结果:
1. 【严重问题】可能导致 bug 或安全风险的代码
2. 【规范问题】违反团队编码规范的代码
3. 【建议改进】可以写得更好的地方
4. 【通过项】做得好的地方(简述即可)

注意:只关注有实质内容的变更行,忽略 import 语句和空行。"""

    response = requests.post(
        "http://localhost:8000/v1/chat/completions",
        json={
            "model": "qwen2.5-coder-32b",
            "messages": [{"role": "user", "content": prompt}],
            "temperature": 0.3,
        },
        timeout=120
    )
    return response.json()["choices"][0]["message"]["content"]

# 主流程
diff = get_pr_diff(123)
review_result = ai_code_review(diff)
print(review_result)

# 真实输出示例:
# 【严重问题】
# - UserController.java 第45行:phone 参数直接拼接到日志中,
#   如果包含特殊字符可能导致日志注入,建议用 PhoneUtil.sanitize() 过滤
# - OrderMapper.xml 第12行:使用了 ${orderId} 而非 #{orderId},
#   存在 SQL 注入风险,必须修复
#
# 【规范问题】
# - PaymentController.java:缺少 @PreAuthorize 权限注解
# - UserService.java 第88行:for 循环内调用了 userMapper.selectById(),
#   违反规范第5条

上面那个 SQL 注入的发现是真实案例。上线前 Review 的时候 AI 揪出来了,​​${orderId}​​​ 这种写法在 MyBatis 里就是直接拼 SQL,参数化查询应该用 ​​#{orderId}​​。要是没拦住,这事儿可大可小。


三、运维岗:AI 不是替代你值班,是让你少被半夜叫醒

场景:告警风暴自动分流

运维最头疼的不是单条告警,是告警风暴。一个交换机抖一下,五十条告警同时炸出来,值班手机直接被打爆。

我搞了一套告警聚合 + AI 分流的系统,思路很直接:先把告警按时间和标签聚类,再把聚合后的事件丢给 AI 判断优先级和可能的根因。

代码语言:javascript
复制
import re
from collections import defaultdict
from datetime import datetime, timedelta
import requests

class AlertCorrelator:
    """告警聚合器:把短时间内相关的告警归到一起"""

    def __init__(self, window_seconds=300):
        self.window = timedelta(seconds=window_seconds)
        self.alert_buffer = []

    def add_alert(self, alert):
        """添加一条告警,返回所属的事件组ID"""
        now = datetime.now()

        # 清理过期告警
        self.alert_buffer = [
            a for a in self.alert_buffer
            if now - a["timestamp"] < self.window
        ]

        # 尝试匹配已有事件组
        group_id = self._find_matching_group(alert)

        if group_id is None:
            group_id = f"INC-{now.strftime('%Y%m%d%H%M%S')}-{len(self.alert_buffer)}"

        alert["group_id"] = group_id
        alert["timestamp"] = now
        self.alert_buffer.append(alert)

        return group_id

    def _find_matching_group(self, alert):
        """简单规则:同一主机/服务的告警归为一组"""
        for existing in reversed(self.alert_buffer):
            if (existing.get("host") == alert.get("host") or
                existing.get("service") == alert.get("service")):
                return existing["group_id"]
        return None


class AIDiagnosticEngine:
    """AI 诊断引擎:分析告警事件组,输出根因判断和处置建议"""

    def __init__(self, model_url, model_name):
        self.url = model_url
        self.model = model_name

    def diagnose(self, alert_group):
        """对一组关联告警进行诊断"""
        alerts_summary = "\n".join([
            f"- [{a['severity']}] {a['service']}: {a['message']}"
            for a in alert_group
        ])

        prompt = f"""你是一位有 10 年经验的运维专家,请分析以下告警事件组,给出诊断。

告警事件组(同一时间窗口内的关联告警):
{alerts_summary}

请输出:
1. 【根因判断】最可能的根本原因(一句话)
2. 【置信度】高/中/低
3. 【影响评估】影响哪些业务,影响范围多大
4. 【处置建议】按优先级排列的行动项
5. 【是否需要升级】是否需要通知上级或拉群

格式要求:简洁,不要废话,运维看的是效率不是文采。"""

        response = requests.post(
            f"{self.url}/v1/chat/completions",
            json={
                "model": self.model,
                "messages": [{"role": "user", "content": prompt}],
                "temperature": 0.2,
            },
            timeout=60
        )
        return response.json()["choices"][0]["message"]["content"]


# ===== 实战运行 =====
correlator = AlertCorrelator(window_seconds=180)
ai_engine = AIDiagnosticEngine(
    model_url="http://localhost:8000",
    model_name="qwen2.5-32b"
)

# 模拟一次告警风暴:交换机端口抖动导致连锁反应
raw_alerts = [
    {"service": "switch-core-01", "severity": "critical",
     "host": "10.0.1.1", "message": "端口 Gi0/24 link down"},
    {"service": "switch-core-01", "severity": "warning",
     "host": "10.0.1.1", "message": "端口 Gi0/24 link up"},
    {"service": "switch-core-01", "severity": "critical",
     "host": "10.0.1.1", "message": "端口 Gi0/24 link down"},
    {"service": "nginx-web-01", "severity": "critical",
     "host": "10.0.2.5", "message": "upstream timeout, backend unreachable"},
    {"service": "nginx-web-02", "severity": "critical",
     "host": "10.0.2.6", "message": "upstream timeout, backend unreachable"},
    {"service": "order-service", "severity": "critical",
     "host": "10.0.3.10", "message": "健康检查失败,实例被踢出注册中心"},
    {"service": "payment-service", "severity": "warning",
     "host": "10.0.3.11", "message": "调用 order-service 超时率 35%"},
]

# 聚合告警
groups = defaultdict(list)
for alert in raw_alerts:
    gid = correlator.add_alert(alert)
    groups[gid].append(alert)

# 对每个事件组做 AI 诊断
for gid, alerts in groups.items():
    print(f"\n{'='*60}")
    print(f"事件组: {gid} ({len(alerts)} 条告警)")
    print(f"{'='*60}")
    diagnosis = ai_engine.diagnose(alerts)
    print(diagnosis)

# AI 输出示例:
# 1.【根因判断】核心交换机 switch-core-01 的 Gi0/24 端口物理链路不稳定,
#   导致下游 web 服务器和微服务不可达
# 2.【置信度】高
# 3.【影响评估】影响订单和支付服务,核心交易链路受损
# 4.【处置建议】
#   a. 立即检查 Gi0/24 物理连接(光模块/网线)
#   b. 如短期无法恢复,将流量切换至备用链路
#   c. 通知业务侧暂停大促活动
# 5.【是否需要升级】是,核心交易链路受损,建议立即拉群

这个方案上线之后,最直接的效果是:值班同学收到告警后不用一条一条看,AI 直接告诉你"根因大概率是交换机端口抖动,影响订单和支付"。从看到告警到开始处理,从之前的 15 分钟缩短到 2 分钟。


四、测试岗:AI 让你从"写用例"变成"设计策略"

场景:根据接口变更自动生成回归测试

测试同学最痛苦的事是什么?需求改了一行,回归用例要改一百条。但如果让 AI 根据 diff 来生成用例,效率完全不一样。

代码语言:javascript
复制
import json
import requests
import subprocess

class AITestGenerator:
    """AI 测试用例生成器:根据接口变更生成回归用例"""

    def __init__(self, model_url, model_name):
        self.url = model_url
        self.model = model_name

    def get_api_diff(self, old_spec, new_spec):
        """对比新旧接口定义,提取变更"""
        changes = []

        old_paths = set(old_spec.get("paths", {}).keys())
        new_paths = set(new_spec.get("paths", {}).keys())

        # 新增的接口
        for path in new_paths - old_paths:
            for method in new_spec["paths"][path]:
                changes.append({
                    "type": "new_api",
                    "path": path,
                    "method": method,
                    "spec": new_spec["paths"][path][method]
                })

        # 变更的接口
        for path in old_paths & new_paths:
            for method in new_spec["paths"][path]:
                old_def = old_spec["paths"][path].get(method, {})
                new_def = new_spec["paths"][path].get(method, {})
                if old_def != new_def:
                    changes.append({
                        "type": "modified_api",
                        "path": path,
                        "method": method,
                        "old_spec": old_def,
                        "new_spec": new_def
                    })

        return changes

    def generate_test_cases(self, changes):
        """根据接口变更生成测试用例"""
        changes_desc = json.dumps(changes, ensure_ascii=False, indent=2)

        prompt = f"""你是资深测试工程师,请根据以下接口变更生成回归测试用例。

接口变更内容:
{changes_desc}

要求:
1. 为每个变更接口生成正常流程、边界值、异常场景用例
2. 特别关注参数类型变更、必填项变更、权限变更
3. 每条用例包含:用例名称、前置条件、请求参数、预期结果、优先级
4. 输出 JSON 数组格式

输出示例:
[{{"name": "注册-正常流程", "precondition": "数据库无该用户", 
   "params": {{"username": "testuser", "password": "Test@1234"}}, 
   "expected": {{"code": 200, "msg": "success"}}, "priority": "P0"}}]"""

        response = requests.post(
            f"{self.url}/v1/chat/completions",
            json={
                "model": self.model,
                "messages": [{"role": "user", "content": prompt}],
                "temperature": 0.4,
            },
            timeout=120
        )
        return response.json()["choices"][0]["message"]["content"]

    def generate_playwright_script(self, test_cases):
        """把用例转成 Playwright 自动化脚本"""
        prompt = f"""请把以下测试用例转换成 Playwright (Python) 自动化脚本。

测试用例:
{test_cases}

要求:
1. 使用 pytest 框架
2. 每条用例一个 test 函数
3. 包含断言
4. 失败时截图保存
5. 加上中文注释"""

        response = requests.post(
            f"{self.url}/v1/chat/completions",
            json={
                "model": self.model,
                "messages": [{"role": "user", "content": prompt}],
                "temperature": 0.3,
            },
            timeout=120
        )
        return response.json()["choices"][0]["message"]["content"]


# ===== 实战运行 =====
generator = AITestGenerator(
    model_url="http://localhost:8000",
    model_name="qwen2.5-coder-32b"
)

# 对比新旧 API 文档(这里用简化数据演示)
old_api_spec = {
    "paths": {
        "/api/users/register": {
            "post": {
                "summary": "用户注册",
                "requestBody": {
                    "username": "string, required",
                    "password": "string, required, min 6",
                    "phone": "string, required"
                }
            }
        }
    }
}

new_api_spec = {
    "paths": {
        "/api/users/register": {
            "post": {
                "summary": "用户注册",
                "requestBody": {
                    "username": "string, required, 3-20 chars",
                    "password": "string, required, min 8, need upper+lower+digit",
                    "phone": "string, required",
                    "email": "string, optional"
                }
            }
        },
        "/api/users/profile": {
            "get": {
                "summary": "获取用户资料",
                "parameters": {
                    "Authorization": "header, required"
                }
            }
        }
    }
}

# Step 1: 提取变更
changes = generator.get_api_diff(old_api_spec, new_api_spec)
print(f"检测到 {len(changes)} 个接口变更")

# Step 2: 生成用例
test_cases = generator.generate_test_cases(changes)
print("\n生成的测试用例:")
print(test_cases)

# Step 3: 生成自动化脚本
playwright_script = generator.generate_playwright_script(test_cases)

# 保存到文件
with open("test_register_regression.py", "w", encoding="utf-8") as f:
    f.write(playwright_script)

print("\n自动化脚本已保存到 test_register_regression.py")

跑一下看效果——密码规则从"min 6"变成"min 8 且包含大小写+数字",AI 自动生成了:弱密码被拒、强密码通过、边界值(7位/8位/特殊字符)等用例。还有新增的 ​​/api/users/profile​​ 接口,AI 生成了无 token 被拒、有 token 正常返回、token 过期等场景。

这就是测试岗的转型方向:你不再是一个一个手写用例的人,你是测试策略的设计者,AI 帮你把策略落地成具体用例和脚本。


五、网工岗:AI 让网络排障从"拼经验"变成"拼数据"

场景:跨厂商网络设备批量巡检 + AI 异常分析

网工巡检这活儿,说实话技术含量不高但极度依赖经验。同一套命令,不同厂商语法不一样(Cisco 一套、华为一套、华三又一套),看输出也得靠经验判断哪些指标异常。我写了个巡检脚本,统一采集 + AI 分析,效果还不错。

代码语言:javascript
复制
from netmiko import ConnectHandler
from concurrent.futures import ThreadPoolExecutor, as_completed
import json
import re
import requests

class NetworkInspector:
    """跨厂商网络设备巡检器"""

    # 不同厂商的命令映射
    COMMAND_MAP = {
        "cisco_ios": {
            "interface": "show interfaces",
            "cpu": "show processes cpu sorted",
            "memory": "show memory statistics",
            "log": "show logging | last 50",
            "arp": "show arp",
            "route": "show ip route summary"
        },
        "huawei": {
            "interface": "display interface",
            "cpu": "display cpu-usage",
            "memory": "display memory-usage",
            "log": "display logbuffer | last 50",
            "arp": "display arp",
            "route": "display ip routing-table statistics"
        },
        "hp_comware": {
            "interface": "display interface",
            "cpu": "display cpu-usage",
            "memory": "display memory",
            "log": "display logbuffer reverse | last 50",
            "arp": "display arp",
            "route": "display ip routing-table statistics"
        }
    }

    def inspect_device(self, device_info):
        """巡检单台设备"""
        device_type = device_info["device_type"]
        commands = self.COMMAND_MAP.get(device_type, {})

        results = {"device": device_info["host"], "data": {}}

        try:
            with ConnectHandler(**device_info) as conn:
                for category, cmd in commands.items():
                    output = conn.send_command(cmd, read_timeout=30)
                    results["data"][category] = output

            results["status"] = "success"
        except Exception as e:
            results["status"] = "failed"
            results["error"] = str(e)

        return results

    def batch_inspect(self, device_list, max_workers=10):
        """批量并行巡检"""
        all_results = []

        with ThreadPoolExecutor(max_workers=max_workers) as executor:
            futures = {
                executor.submit(self.inspect_device, dev): dev["host"]
                for dev in device_list
            }

            for future in as_completed(futures):
                host = futures[future]
                try:
                    result = future.result()
                    all_results.append(result)
                except Exception as e:
                    all_results.append({
                        "device": host,
                        "status": "failed",
                        "error": str(e)
                    })

        return all_results


class AINetworkAnalyzer:
    """AI 网络异常分析器"""

    def __init__(self, model_url, model_name):
        self.url = model_url
        self.model = model_name

    def analyze(self, inspection_results):
        """分析巡检结果,找出潜在问题"""
        # 把巡检数据整理成 AI 能看的格式
        device_reports = []
        for r in inspection_results:
            if r["status"] != "success":
                device_reports.append(
                    f"设备 {r['device']}: 巡检失败,错误: {r.get('error', '未知')}")
                continue

            # 只提取关键信息,避免 prompt 太长
            iface_data = r["data"].get("interface", "")[:2000]
            cpu_data = r["data"].get("cpu", "")[:500]
            mem_data = r["data"].get("memory", "")[:500]
            log_data = r["data"].get("log", "")[:1500]

            device_reports.append(
                f"设备 {r['device']}:\n"
                f"[接口状态]\n{iface_data}\n\n"
                f"[CPU使用率]\n{cpu_data}\n\n"
                f"[内存使用率]\n{mem_data}\n\n"
                f"[最近日志]\n{log_data}"
            )

        combined_report = "\n\n---\n\n".join(device_reports)

        prompt = f"""你是一位有 15 年经验的网络工程师,请分析以下网络设备巡检数据,找出潜在问题。

巡检数据:
{combined_report[:12000]}

请输出:
1. 【严重问题】需要立即处理的(如链路 down、CRC 错误持续增长、CPU > 80%)
2. 【潜在风险】目前不影响但可能恶化的(如内存缓慢增长、错误包有上升趋势)
3. 【建议操作】针对每个问题的具体处理建议
4. 【健康度评分】每台设备的健康度(0-100分)

注意:重点关注接口的 CRC 错误、丢包率、CPU 和内存趋势。"""

        response = requests.post(
            f"{self.url}/v1/chat/completions",
            json={
                "model": self.model,
                "messages": [{"role": "user", "content": prompt}],
                "temperature": 0.2,
            },
            timeout=90
        )
        return response.json()["choices"][0]["message"]["content"]


# ===== 实战运行 =====
devices = [
    {"device_type": "cisco_ios", "host": "10.0.1.1",
     "username": "admin", "password": "***", "port": 22},
    {"device_type": "huawei", "host": "10.0.1.2",
     "username": "admin", "password": "***", "port": 22},
    {"device_type": "hp_comware", "host": "10.0.1.3",
     "username": "admin", "password": "***", "port": 22},
]

inspector = NetworkInspector()
analyzer = AINetworkAnalyzer(
    model_url="http://localhost:8000",
    model_name="qwen2.5-32b"
)

# Step 1: 批量巡检
print("开始巡检...")
results = inspector.batch_inspect(devices)
print(f"巡检完成: {len(results)} 台设备")

# Step 2: AI 分析
print("\nAI 分析中...")
analysis = analyzer.analyze(results)
print(analysis)

# AI 输出示例:
# 1.【严重问题】
# 设备 10.0.1.1 (Cisco):
#   - Gi0/24 接口 CRC 错误率异常,过去1小时增长 152 个,
#     结合 input errors 持续增长,大概率光模块或光纤物理层问题
#   - 建议:立即检查光模块发光功率,准备备件更换
#
# 设备 10.0.1.2 (Huawei):
#   - CPU 使用率 85%,持续 10 分钟以上
#   - 日志显示有大量 ARP 请求,可能是 ARP 攻击或环路
#   - 建议:检查 ARP 表项,排查是否有环路
#
# 2.【潜在风险】
# 设备 10.0.1.3 (H3C):
#   - 内存使用率 72%,虽未告警但过去一周呈缓慢上升趋势
#   - 建议:关注内存趋势,排查是否有内存泄漏的进程
#
# 4.【健康度评分】
# 10.0.1.1: 65分(有严重接口问题)
# 10.0.1.2: 55分(CPU 高且有潜在安全风险)
# 10.0.1.3: 85分(正常,需关注内存趋势)

这个方案最实在的好处是:以前巡检 30 台设备,一个网工得花一整天,看输出看得眼花。现在批量采集 10 分钟搞定,AI 分析 30 秒出结果,直接告诉你哪台设备有问题、问题在哪、怎么处理。


六、四个岗位协同:一次完整的线上故障复盘

光说单个岗位的 AI 应用还不够直观,我讲一个真实的跨岗协作案例,看看 AI 在全链路中的配合。

故障背景: 某天下午 2 点,用户反馈下单偶尔超时,监控显示订单服务 P99 延迟从 200ms 飙到 3 秒。

四个岗位同时用 AI 介入,15 分钟定位根因:

最终复盘: 开发同学改了一个查询 SQL,把索引条件去掉了(Code Review 的时候 AI 其实提示了"该查询涉及大表全表扫描风险",但当时赶版本没注意)。上线 2 小时后数据量上来,慢查询把连接池吃光了。

整个排查过程,四个岗位并行分析,AI 帮每个人快速聚焦到自己的领域,15 分钟拼出完整因果链。要是纯靠人工翻日志,至少一个小时起步。


七、别把 AI 当万能药——避坑指南

写了这么多 AI 的好处,泼点冷水。这一年多踩的坑也不少,总结几条:

第一,AI 有幻觉,关键决策必须人审。 AI 说"根因是光模块故障",你不能直接冲去机房换光模块。你得自己看一眼接口状态确认。AI 是参谋,不是司令。

第二,别把敏感数据喂给公网模型。 用户数据、生产密钥、内网拓扑——这些东西一旦出了内网就收不回来。要么用内网部署的开源模型,要么做好数据脱敏。我见过有人把数据库连接串贴到 ChatGPT 里问问题的,这操作属于直接送人头。

第三,Prompt 不是一劳永逸的。 你写了个 Prompt 效果不错,过两周换了模型版本或者业务场景变了,效果可能就拉了。Prompt 需要持续调优,就像监控阈值需要定期校准一样。

第四,AI 适合重复性高的场景,不适合需要创造性判断的。 参数校验、用例生成、日志分析——这些有规律可循的活儿交给 AI。架构设计、技术选型、故障的最终决策——这些还是得人来。

第五,别追求一步到位。 先在一个场景里跑通,看到效果了再扩展。上来就想全岗位全流程 AI 化的,最后大概率哪个都没落地。


回到标题——"当 AI 成为技术人标配工具"。标配的意思不是每个工种都用一样的方式,而是每个工种都找到了适合自己的 AI 用法

  • 开发用 AI 做 Code Review 和边界场景补全,不是让 AI 替你写业务逻辑
  • 运维用 AI 做告警聚合和根因初判,不是让 AI 替你做运维决策
  • 测试用 AI 生成用例和自动化脚本,不是让 AI 替你设计测试策略
  • 网工用 AI 分析巡检数据,不是让 AI 替你上设备敲命令

核心思路就一句话:AI 干脏活累活重复活,人干判断活决策活创造活。

工具准备好了,场景也聊了,代码也给了。剩下的事,就是挑一个你手头最烦的重复性任务,先跑个最小闭环试试。别等"准备好了"再开始——这事儿永远没有准备好的时候。

要是你在实际落地中遇到了什么有意思的坑或者好用的玩法,欢迎聊聊。技术这条路,一起踩坑比一个人摸索快多了。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 一、先聊聊"标配"这个词
  • 二、开发岗:AI 不只是写代码,更是你的"结对编程伙伴"
    • 场景:接口参数校验——最烦人但最该做的事
    • AI 辅助 Code Review 实战
  • 三、运维岗:AI 不是替代你值班,是让你少被半夜叫醒
    • 场景:告警风暴自动分流
  • 四、测试岗:AI 让你从"写用例"变成"设计策略"
    • 场景:根据接口变更自动生成回归测试
  • 五、网工岗:AI 让网络排障从"拼经验"变成"拼数据"
    • 场景:跨厂商网络设备批量巡检 + AI 异常分析
  • 六、四个岗位协同:一次完整的线上故障复盘
  • 七、别把 AI 当万能药——避坑指南
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档