最近在开发者社区里有一个话题讨论度很高一段 POV 视频画面里是一位开发者的工位电脑屏幕自动打开AI 助手开始写代码、回消息、改需求文档屏幕上的字只有一句——An AI replaced your job this morning。评论区里有人焦虑有人嘲讽也有人真的开始反思如果 AI 明天能写代码那我现在学的技术栈还有意义吗我的看法是这类 POV 视频放大了焦虑但距离真实世界还很遥远。真正值得聊的不是“AI 会不会取代程序员”而是另一件事——AI 编程工具已经发展到了什么程度能帮我做哪些事有哪些坑必须自己绕过。这篇文章不贩卖焦虑只讲技术。我会从 AI 编程、AI Agent、AI 工程实践的角度拆解 AI 到底能替开发者做多少事再带你把一套“AI 辅助代码审查 Agent”完整跑起来。读完你会明白一件事AI 不是来取代你的但它的确会重塑你的工作方式。1. “AI 取代工作”的焦虑背后程序员真正该关注什么1.1 POV 视频里的 AI 到底在做什么这类 POV 视频通常会把 AI 包装成一个全知全能的“数字员工”它自动接收需求、写代码、提交 Git、回复邮件、生成测试用例甚至能自己决定上线。从技术视角拆解视频里至少出现了三类能力代码生成能力根据自然语言描述生成代码片段这是目前最成熟的能力。任务编排能力把“写一个用户注册接口”拆成 Controller、Service、Mapper、测试用例等多个步骤再逐步完成。工具调用能力读取文件、执行命令、操作 Git这类能力正是 AI Agent 的核心。第一类能力已经非常普及Cursor、GitHub Copilot、JetBrains 系 IDE 插件都做得不错。后两类属于 Agent 能力近年来进步很快但远远没到“全自动取代工程师”的程度。1.2 AI 编程工具的现状补全、对话、Agent 执行现在的 AI 编程工具可以从三个层次看层次代表场景成熟度依赖条件代码补全写函数时自动补全下一行成熟IDE 插件上下文窗口内的代码对话式编程提问“这段代码哪里有问题”“帮我生成一个工具类”成熟大模型 API 或本地模型Agent 任务执行让 AI 自己读取仓库、改多个文件、跑测试快速发展中工具调用、权限控制、沙箱环境前两层有基础的开发者稍加学习就能上手。第三层是当前 AI 工程实践的重点也是问题高发区。1.3 为什么“取代”没那么容易真实软件开发不是“从自然语言到代码”的单向翻译而是持续在真实环境里调试、权衡、决策的过程。AI 能生成一段看起来正常的代码但它常常不理解业务边界把不该删的逻辑删了不了解历史包袱生成的代码和现有架构风格冲突不掌握环境信息生成一段调用不存在 API 的代码没有验证手段代码能编译但运行结果完全不符合预期。所以未来被淘汰的不是程序员而是“不更新工作方式的流程”。真正需要担心的不是 AI 写代码而是一个会用 AI 的团队把产出效率拉高后还在手写重复劳动的你。2. 环境准备搭建一套 AI 辅助开发工作台先不讨论复杂的 Agent 框架我们把基础环境准备好。即使你只想在 IDE 里用 AI 补全代码也需要一个顺手的开发环境。2.1 必备开发环境我日常使用的环境如下供参考操作系统macOS / Ubuntu / Windows注意 Windows 下建议开启 WSL2 做命令行开发。语言运行时Python 3.10Java 17Node.js 18视项目需要安装。包管理pip、conda、Maven、npm、pnpm按技术栈选择。IDEIntelliJ IDEA、VS Code、Cursor或者 PyCharm。版本控制Git建议熟练使用命令行而不是只依赖 IDE 界面。以上版本只是示例具体以你实际项目为准重点演示配置思路。2.2 AI 编程助手选型比较常见的几类选择GitHub Copilot在 VS Code、JetBrains 全家桶中集成度很高适合补全场景。Cursor基于 VS Code 的 AI 原生编辑器支持对话、补全、跨文件改动是目前很多开发者尝试 AI 编程的第一站。JetBrains 系内置 AIIDEA、PyCharm 新版都有 AI Assistant 插件适合已经在 JetBrains 生态里的开发者。开源模型本地部署比如通过 Ollama 运行开源模型再接入 OpenCode、Continue 这类开源插件。好处是数据不出本机适合敏感项目。我的建议是先选一个主用工具不要同时开好几个插件。算法题、脚手架代码可以交给补全核心业务代码必须自己看一遍。2.3 模型 API 与本地模型的选择AI 编程工具有两类后端云端模型 API 和本地模型。云端 API效果普遍更好代码理解能力强但存在数据隐私问题。公司项目需要先确认是否允许把代码发到外部 API。本地模型部署在自己机器或内网数据安全但效果和速度受硬件限制尤其显存不够时体验下降明显。不管选哪种都要记住一个原则任何发到外部服务的数据都默认它可能被留存。涉及客户数据、密钥、内部系统地址的代码不要直接粘贴给任意 AI 工具。3. 核心概念拆解AI Agent、提示词与 AI 幻觉在写实战代码前先把三个高频术语讲清楚。3.1 AI Agent 的核心链路AI Agent 不是单纯“问一句答一句”而是一个带“循环”的执行系统。一条典型的 Agent 链路是接收任务 → 拆解子任务 → 调用工具/读取代码 → 观察结果 → 修正方案 → 输出结果每个环节都有可能出错所以工程设计上要做三件事限制工具权限、记录执行日志、允许人工确认。在代码审查场景里Agent 不需要太高的自主性。我们只需要它做一次“读取代码 → 本地规则扫描 → 调用大模型生成建议”的流程这已经足够体现工程化思路。3.2 提示词工程的关键要点提示词工程不是“给 AI 一段话然后祈祷它输出正确”而是把 AI 当成一个刚开始合作的新同事尽量给它清晰的上下文。写提示词时要注意几个要素角色设定告诉 AI 它是什么角色比如“你是一名高级代码审查工程师”。任务目标明确要它做什么不要模棱两可。输出格式规定输出结构比如“按严重程度排序每条给出文件名、原因、修复建议”。约束条件告诉它不要做什么比如“不要泛泛而谈必须给出具体修改建议”。补充上下文把代码、报错信息、项目结构贴给对方越完整越准确。一个常见误区是给 AI 的问题太模糊。比如“请帮我优化这段代码”AI 通常会返回一堆正确的废话。改成“这段代码在并发场景下可能出现什么问题请指出具体行并给出修复代码”之后效果会明显不同。3.3 AI 幻觉看起来正确实际是错的AI 幻觉是指模型生成的内容语法通顺、逻辑自洽但事实是错的。在编程场景里幻觉表现为推荐一个不存在的 API捏造一个不存在的报错原因生成“能编译但结果不对”的代码把两个框架的概念混淆输出四不像配置。规避幻觉最有效的手段不是换更强的模型而是增加验证环节。代码能跑、测试能过、结果符合预期永远比 AI 解释了什么更重要。4. 实战用 Python 构建一个 AI 代码审查 Agent现在开始实战。我们构建一个轻量级的代码审查 Agent它做两件事用本地规则扫描代码发现硬编码密钥、危险 SQL、遗留标记等确定性问题。把代码和本地扫描结果一起提交给大模型让它从逻辑、安全、性能、可维护性角度给建议。这个 Agent 的特点是本地规则负责确定性检查大模型负责开放性审查两者结合可以很大程度上降低 AI 幻觉的影响。4.1 需求分析我们的 Agent 需要支持输入一个代码文件路径运行本地规则调用 OpenAI 兼容格式的大模型 API输出本地扫描结果和 AI 审查建议支持通过命令行参数和环境变量配置 API。这里说的“OpenAI 兼容格式”指的是/chat/completions这种通用协议很多云服务都支持具体地址和模型由你根据合法渠道获取的 API 服务来定。4.2 项目结构ai_code_reviewer/ ├── requirements.txt ├── config.py ├── local_rules.py ├── llm_client.py ├── review_agent.py └── sample.py4.3 环境依赖# requirements.txt requests2.31.0安装命令pip install -r requirements.txt4.4 配置模块config.py负责读取环境变量避免把密钥写死在代码里。# config.py from dataclasses import dataclass import os dataclass class LLMConfig: base_url: str os.getenv(LLM_BASE_URL, https://api.example.com/v1) api_key: str os.getenv(LLM_API_KEY, ) model: str os.getenv(LLM_MODEL, your-model-name) temperature: float 0.2 max_tokens: int 2000这里默认值使用了example.com和your-model-name实际使用时必须通过环境变量或命令行参数替换为合法可用的 API 信息。4.5 本地规则检查器local_rules.py用正则扫描代码中一些确定性问题这部分不依赖大模型结果稳定可控。# local_rules.py import re RULES [ { id: RULE-001, severity: WARN, pattern: rTODO|FIXME|HACK, message: 发现 TODO/FIXME 标记注意遗留问题, }, { id: RULE-002, severity: CRITICAL, pattern: rpassword\s*\s*[\][^\][\], message: 代码中疑似硬编码密码存在安全风险, }, { id: RULE-003, severity: INFO, pattern: rprint\s*\(, message: 发现 print 调试语句生产环境建议改为日志输出, }, { id: RULE-004, severity: CRITICAL, pattern: rdelete\sfrom\s\w\swhere\s1\s*\s*1, message: 发现无 WHERE 条件的危险删除操作, }, ] def run_local_rules(file_path: str): with open(file_path, r, encodingutf-8) as f: code f.read() issues [] for rule in RULES: if re.search(rule[pattern], code, re.IGNORECASE): issues.append(rule) return issues4.6 大模型客户端llm_client.py封装一个最简聊天补全请求。核心是把 HTTP 请求封装成通用函数不绑定任何具体厂商 SDK。# llm_client.py import requests import json from config import LLMConfig class LLMClient: def __init__(self, config: LLMConfig): self.config config def chat(self, system_prompt: str, user_prompt: str) - str: url self.config.base_url.rstrip(/) /chat/completions headers { Authorization: fBearer {self.config.api_key}, Content-Type: application/json, } payload { model: self.config.model, temperature: self.config.temperature, max_tokens: self.config.max_tokens, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], } response requests.post(url, headersheaders, jsonpayload, timeout60) response.raise_for_status() data response.json() return data[choices][0][message][content]需要说明的是有些服务商的返回结构可能略有差异或者需要额外传api_base参数这个封装只是一个最通用的版本。4.7 主程序review_agent.py把整个流程串起来。# review_agent.py import argparse import os from config import LLMConfig from local_rules import run_local_rules from llm_client import LLMClient SYSTEM_PROMPT 你是一名高级代码审查工程师擅长发现代码中的逻辑缺陷、安全隐患、性能问题和可维护性问题。 请基于用户提供的代码给出简洁、可执行的改进建议。 要求 1. 按严重程度排序先列严重问题。 2. 每条问题给出文件名、行号如果可知、原因、修复建议。 3. 如果代码本身质量很高可以明确说明。 4. 不要泛泛而谈必须给出具体修改建议。 def build_user_prompt(file_path: str, local_issues: list) - str: with open(file_path, r, encodingutf-8) as f: code f.read() local_issue_text \n.join( f- [{issue[severity]}] {issue[id]}: {issue[message]} for issue in local_issues ) return ( f请审查以下代码文件{file_path}\n\n f本地规则扫描结果\n{local_issue_text}\n\n f代码内容\n\n{code}\n ) def main(): parser argparse.ArgumentParser(descriptionAI 代码审查 Agent) parser.add_argument(file, help待审查的代码文件路径) parser.add_argument(--base-url, defaultNone, helpOpenAI 兼容接口地址) parser.add_argument(--api-key, defaultNone, helpAPI Key) parser.add_argument(--model, defaultNone, help模型名称) args parser.parse_args() file_path args.file if not os.path.exists(file_path): print(f文件不存在{file_path}) return config LLMConfig( base_urlargs.base_url or os.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyargs.api_key or os.getenv(LLM_API_KEY, ), modelargs.model or os.getenv(LLM_MODEL, your-model-name), ) local_issues run_local_rules(file_path) print( * 60) print(本地规则扫描结果) print( * 60) if local_issues: for issue in local_issues: print(f[{issue[severity]}] {issue[id]}: {issue[message]}) else: print(未发现本地规则匹配的问题。) print() print( * 60) print(AI 审查结果) print( * 60) client LLMClient(config) user_prompt build_user_prompt(file_path, local_issues) try: result client.chat(SYSTEM_PROMPT, user_prompt) print(result) except Exception as e: print(f调用 LLM 接口失败{e}) print(请检查 base_url、api_key、model 配置以及网络环境。) if __name__ __main__: main()4.8 准备一个待审查的示例文件# sample.py import sqlite3 def update_user_email(user_id, email): password admin123 conn sqlite3.connect(user.db) cursor conn.cursor() # TODO: 这里需要补充参数校验 cursor.execute( UPDATE users SET email ? WHERE id ?, (email, user_id), ) conn.commit() conn.close() print(update success) def delete_all(): conn sqlite3.connect(user.db) cursor conn.cursor() cursor.execute(DELETE FROM users WHERE 11) conn.commit() conn.close()4.9 运行与验证export LLM_BASE_URLhttps://your-api.example.com/v1 export LLM_API_KEYyour-api-key export LLM_MODELyour-model-name python review_agent.py sample.py预期输出会分成两部分本地规则扫描结果和 AI 审查结果。本地规则会稳定报告RULE-001TODO、RULE-002硬编码密码、RULE-003print 调试、RULE-004危险删除。AI 审查会从数据库连接未关闭、空值校验缺失、事务未处理等角度给出更细致的建议。你可能发现AI 的建议并非每条都合理也会遗漏一些上下文。这恰恰是真实 AI 工程实践的常态AI 输出需要人工判断规则和测试才是底线。5. 实战延伸AI 编程助手在真实项目中的使用思路除了自己写 Agent直接使用 AI 编程助手也能显著提升效率。关键是掌握“怎么提问”。5.1 用提示词模板生成业务代码以 Spring Boot 项目为例一个能用的提示词不只是“写个注册接口”而是带约束的版本你是这个项目的后端开发者。 请用 Spring Boot 3 实现一个用户注册接口技术栈为 spring-boot-starter-web mybatis-plus mysql。 需求 1. Controller 路径为 /api/user/register请求方法 POST。 2. 入参包含 username、password、email 三个字段使用 DTO 对象接收。 3. 用户名唯一密码使用 BCrypt 加密后保存。 4. 返回统一 JSON 结构 ResultT成功返回 code200失败返回具体错误码。 5. 需要校验字段非空和邮箱格式。 请给出 Controller、Service、ServiceImpl、Mapper、DTO 的完整代码并补充一个单元测试示例。 输出时标注每个类的完整路径。这样做的好处是角色、技术栈、需求、输出结构都明确AI 生成的代码才有落地的可能。5.2 用 AI 生成单元测试AI 写单元测试比写业务代码更合适因为测试的输入输出是确定的。请为以下方法编写 JUnit 5 单元测试使用 Mockito 模拟外部依赖。 要求 1. 覆盖正常流程、参数为空、内部异常三个场景。 2. 断言必须验证返回值而不是只验证方法被调用。 3. 测试类命名遵循 class 名 Test 后缀。 方法代码如下生成之后不要直接信跑一次测试再看覆盖率再决定补不补。5.3 用 AI 解释和重构遗留代码遇到一段没人能看懂的旧代码可以把整段代码发给 AI请解释下面这段老代码的业务意图说明它潜在的风险并给出重构建议。 要求 1. 先用三句话概括这段代码在做什么。 2. 指出可能存在的 bug 和异常分支。 3. 给出重构后的 Java 代码保持对外接口行为不变。这种场景下AI 的“开放性解释”很有价值但重构结果必须靠测试兜底。老代码动一层就可能导致线上故障不要允许 AI 直接改生产代码。6. 常见问题与排查思路在实际使用 AI 编程工具的过程中高频问题主要集中在配置、上下文和输出质量上。问题现象常见原因解决思路调用 API 返回 401api_key 错误或无效检查环境变量、密钥权限确认服务是否在有效期内返回 404base_url 或接口路径错误确认接口是否为 OpenAI 兼容格式检查/chat/completions路径请求超时网络不稳定、模型负载过高、超时时间太短在配置中增加超时时间业务系统里建议加重试和降级生成的代码能编译但运行报错上下文缺失、技术栈版本理解错误把完整报错、依赖版本、项目结构一起发给 AI生成的代码逻辑看似正常但结果错误AI 幻觉以单元测试为准把生成代码和边界测试一起跑一遍IDE 插件一直转圈不输出插件与 IDE 版本不兼容、代理配置异常升级 IDE/插件版本检查网络和代理配置本地模型推理速度慢显存不足、模型过大换小模型或量化版本必要时使用云端 API排查时我习惯从两条链路入手配置链路环境变量、API key、接口地址、模型名是否都正确。执行链路先跑通一个最小请求确认调用没问题再叠加复杂功能。7. 最佳实践让 AI 成为可靠的生产力工具7.1 把 AI 当“实习生”而不是“权威专家”AI 写代码的能力在提升但它的可靠性还远没有到“免检”程度。正确的心态是把它当成一个执行速度极快但有概率出错的实习生。凡是它产出内容都必须经过编译、测试、人工 review 三道关卡。在实际项目里我会把 AI 生成的代码分为三类可直接使用脚手架、工具类、单元测试模板、注释生成。需人工修改业务 CRUD、权限控制、复杂 SQL。禁止 AI 直接处理生产环境脚本、数据迁移、删除操作、安全敏感逻辑。7.2 代码审查与安全边界AI 辅助开发不能变成“无人审查开发”。建议团队约定所有提交必须经过人工 Code ReviewAI 生成的代码要标记来源。涉及数据库删除、生产数据更新、第三方支付的代码不允许直接由 AI 生成并合入。把本地规则扫描类似我们上面的local_rules.py接入 CI先把确定性问题截住再交给大模型做开放性检查。7.3 数据隐私与合规千万不要把公司核心代码、客户数据、内部账号信息随意粘贴到外部 AI 服务中。建议敏感项目优先使用本地模型或私有化部署方案。使用外部 API 时先脱敏、再提交。在 IDE 插件中关闭自动发送代码的选项或者使用不允许上传代码的模式。有条件的团队在网关层做审计日志记录哪些代码片段被发送到了外部模型。7.4 性能与成本控制AI 工具不是免费的。模型调用会带来两个成本时间成本和资金成本。工程上可以这样做给不同任务分配不同模型简单补全用轻量模型复杂推理用强模型。设置合理的max_tokens和超时时间避免模型无限输出。在 Agent 链路里加入本地规则预筛确定性规则能解决的问题不要浪费大模型调用。对调用做流量控制和缓存相同代码片段不重复请求。7.5 日志、可观测性与增量接入如果团队要落地 AI 辅助工具建议从低风险场景开始小范围试运行而不是一次性让所有人在生产代码里使用。需要记录的数据包括调用了哪个模型、传了多少 token、耗时多久。AI 输出的代码是否被修改后合入修改比例是多少。是否因为 AI 输出引入了线上问题根因是什么。这些数据收集一段时间后你就能判断自己的 AI 使用方式是否真的提升了效率而不是只是“看起来热闹”。8. 总结AI 不会取代你但会重塑工作方式回到开头的 POV 视频。你真的会被 AI 取代吗我的答案是短期内不会但你的工作内容一定会变。过去一个初级开发者可能要花半小时写一个 CRUD 接口现在 AI 十几秒就能生成你要做的是理解需求、约束边界、审查代码、写出可靠的测试。这种情况下会写代码只是基础能力理解系统、控制风险、验证结果才是真正的护城河。如果你已经接触过 AI 编程下一步可以从这几个方向深入把提示词工程系统化总结一套适合自己项目的提示词模板库。学习 LangChain、Spring AI 这类 Agent 开发框架把模型调用和工作流结合起来。研究 RAG检索增强生成让 AI 基于仓库代码回答问题而不是凭“记忆”胡说。在团队里搭建一套 AI 代码审查基础设施从确定性规则开始逐步加入模型能力。动手永远是消除焦虑的最好方式。与其刷一条“AI 取代工作”的视频焦虑三分钟不如打开终端把今天这个代码审查 Agent 跑起来。当你真正理解 AI 能做什么、不能做什么之后你在这个行业里的位置会比 AI 生成的任何代码都更稳。 AI编程与Agent实战：构建AI代码审查工具
最近在开发者社区里有一个话题讨论度很高一段 POV 视频画面里是一位开发者的工位电脑屏幕自动打开AI 助手开始写代码、回消息、改需求文档屏幕上的字只有一句——An AI replaced your job this morning。评论区里有人焦虑有人嘲讽也有人真的开始反思如果 AI 明天能写代码那我现在学的技术栈还有意义吗我的看法是这类 POV 视频放大了焦虑但距离真实世界还很遥远。真正值得聊的不是“AI 会不会取代程序员”而是另一件事——AI 编程工具已经发展到了什么程度能帮我做哪些事有哪些坑必须自己绕过。这篇文章不贩卖焦虑只讲技术。我会从 AI 编程、AI Agent、AI 工程实践的角度拆解 AI 到底能替开发者做多少事再带你把一套“AI 辅助代码审查 Agent”完整跑起来。读完你会明白一件事AI 不是来取代你的但它的确会重塑你的工作方式。1. “AI 取代工作”的焦虑背后程序员真正该关注什么1.1 POV 视频里的 AI 到底在做什么这类 POV 视频通常会把 AI 包装成一个全知全能的“数字员工”它自动接收需求、写代码、提交 Git、回复邮件、生成测试用例甚至能自己决定上线。从技术视角拆解视频里至少出现了三类能力代码生成能力根据自然语言描述生成代码片段这是目前最成熟的能力。任务编排能力把“写一个用户注册接口”拆成 Controller、Service、Mapper、测试用例等多个步骤再逐步完成。工具调用能力读取文件、执行命令、操作 Git这类能力正是 AI Agent 的核心。第一类能力已经非常普及Cursor、GitHub Copilot、JetBrains 系 IDE 插件都做得不错。后两类属于 Agent 能力近年来进步很快但远远没到“全自动取代工程师”的程度。1.2 AI 编程工具的现状补全、对话、Agent 执行现在的 AI 编程工具可以从三个层次看层次代表场景成熟度依赖条件代码补全写函数时自动补全下一行成熟IDE 插件上下文窗口内的代码对话式编程提问“这段代码哪里有问题”“帮我生成一个工具类”成熟大模型 API 或本地模型Agent 任务执行让 AI 自己读取仓库、改多个文件、跑测试快速发展中工具调用、权限控制、沙箱环境前两层有基础的开发者稍加学习就能上手。第三层是当前 AI 工程实践的重点也是问题高发区。1.3 为什么“取代”没那么容易真实软件开发不是“从自然语言到代码”的单向翻译而是持续在真实环境里调试、权衡、决策的过程。AI 能生成一段看起来正常的代码但它常常不理解业务边界把不该删的逻辑删了不了解历史包袱生成的代码和现有架构风格冲突不掌握环境信息生成一段调用不存在 API 的代码没有验证手段代码能编译但运行结果完全不符合预期。所以未来被淘汰的不是程序员而是“不更新工作方式的流程”。真正需要担心的不是 AI 写代码而是一个会用 AI 的团队把产出效率拉高后还在手写重复劳动的你。2. 环境准备搭建一套 AI 辅助开发工作台先不讨论复杂的 Agent 框架我们把基础环境准备好。即使你只想在 IDE 里用 AI 补全代码也需要一个顺手的开发环境。2.1 必备开发环境我日常使用的环境如下供参考操作系统macOS / Ubuntu / Windows注意 Windows 下建议开启 WSL2 做命令行开发。语言运行时Python 3.10Java 17Node.js 18视项目需要安装。包管理pip、conda、Maven、npm、pnpm按技术栈选择。IDEIntelliJ IDEA、VS Code、Cursor或者 PyCharm。版本控制Git建议熟练使用命令行而不是只依赖 IDE 界面。以上版本只是示例具体以你实际项目为准重点演示配置思路。2.2 AI 编程助手选型比较常见的几类选择GitHub Copilot在 VS Code、JetBrains 全家桶中集成度很高适合补全场景。Cursor基于 VS Code 的 AI 原生编辑器支持对话、补全、跨文件改动是目前很多开发者尝试 AI 编程的第一站。JetBrains 系内置 AIIDEA、PyCharm 新版都有 AI Assistant 插件适合已经在 JetBrains 生态里的开发者。开源模型本地部署比如通过 Ollama 运行开源模型再接入 OpenCode、Continue 这类开源插件。好处是数据不出本机适合敏感项目。我的建议是先选一个主用工具不要同时开好几个插件。算法题、脚手架代码可以交给补全核心业务代码必须自己看一遍。2.3 模型 API 与本地模型的选择AI 编程工具有两类后端云端模型 API 和本地模型。云端 API效果普遍更好代码理解能力强但存在数据隐私问题。公司项目需要先确认是否允许把代码发到外部 API。本地模型部署在自己机器或内网数据安全但效果和速度受硬件限制尤其显存不够时体验下降明显。不管选哪种都要记住一个原则任何发到外部服务的数据都默认它可能被留存。涉及客户数据、密钥、内部系统地址的代码不要直接粘贴给任意 AI 工具。3. 核心概念拆解AI Agent、提示词与 AI 幻觉在写实战代码前先把三个高频术语讲清楚。3.1 AI Agent 的核心链路AI Agent 不是单纯“问一句答一句”而是一个带“循环”的执行系统。一条典型的 Agent 链路是接收任务 → 拆解子任务 → 调用工具/读取代码 → 观察结果 → 修正方案 → 输出结果每个环节都有可能出错所以工程设计上要做三件事限制工具权限、记录执行日志、允许人工确认。在代码审查场景里Agent 不需要太高的自主性。我们只需要它做一次“读取代码 → 本地规则扫描 → 调用大模型生成建议”的流程这已经足够体现工程化思路。3.2 提示词工程的关键要点提示词工程不是“给 AI 一段话然后祈祷它输出正确”而是把 AI 当成一个刚开始合作的新同事尽量给它清晰的上下文。写提示词时要注意几个要素角色设定告诉 AI 它是什么角色比如“你是一名高级代码审查工程师”。任务目标明确要它做什么不要模棱两可。输出格式规定输出结构比如“按严重程度排序每条给出文件名、原因、修复建议”。约束条件告诉它不要做什么比如“不要泛泛而谈必须给出具体修改建议”。补充上下文把代码、报错信息、项目结构贴给对方越完整越准确。一个常见误区是给 AI 的问题太模糊。比如“请帮我优化这段代码”AI 通常会返回一堆正确的废话。改成“这段代码在并发场景下可能出现什么问题请指出具体行并给出修复代码”之后效果会明显不同。3.3 AI 幻觉看起来正确实际是错的AI 幻觉是指模型生成的内容语法通顺、逻辑自洽但事实是错的。在编程场景里幻觉表现为推荐一个不存在的 API捏造一个不存在的报错原因生成“能编译但结果不对”的代码把两个框架的概念混淆输出四不像配置。规避幻觉最有效的手段不是换更强的模型而是增加验证环节。代码能跑、测试能过、结果符合预期永远比 AI 解释了什么更重要。4. 实战用 Python 构建一个 AI 代码审查 Agent现在开始实战。我们构建一个轻量级的代码审查 Agent它做两件事用本地规则扫描代码发现硬编码密钥、危险 SQL、遗留标记等确定性问题。把代码和本地扫描结果一起提交给大模型让它从逻辑、安全、性能、可维护性角度给建议。这个 Agent 的特点是本地规则负责确定性检查大模型负责开放性审查两者结合可以很大程度上降低 AI 幻觉的影响。4.1 需求分析我们的 Agent 需要支持输入一个代码文件路径运行本地规则调用 OpenAI 兼容格式的大模型 API输出本地扫描结果和 AI 审查建议支持通过命令行参数和环境变量配置 API。这里说的“OpenAI 兼容格式”指的是/chat/completions这种通用协议很多云服务都支持具体地址和模型由你根据合法渠道获取的 API 服务来定。4.2 项目结构ai_code_reviewer/ ├── requirements.txt ├── config.py ├── local_rules.py ├── llm_client.py ├── review_agent.py └── sample.py4.3 环境依赖# requirements.txt requests2.31.0安装命令pip install -r requirements.txt4.4 配置模块config.py负责读取环境变量避免把密钥写死在代码里。# config.py from dataclasses import dataclass import os dataclass class LLMConfig: base_url: str os.getenv(LLM_BASE_URL, https://api.example.com/v1) api_key: str os.getenv(LLM_API_KEY, ) model: str os.getenv(LLM_MODEL, your-model-name) temperature: float 0.2 max_tokens: int 2000这里默认值使用了example.com和your-model-name实际使用时必须通过环境变量或命令行参数替换为合法可用的 API 信息。4.5 本地规则检查器local_rules.py用正则扫描代码中一些确定性问题这部分不依赖大模型结果稳定可控。# local_rules.py import re RULES [ { id: RULE-001, severity: WARN, pattern: rTODO|FIXME|HACK, message: 发现 TODO/FIXME 标记注意遗留问题, }, { id: RULE-002, severity: CRITICAL, pattern: rpassword\s*\s*[\][^\][\], message: 代码中疑似硬编码密码存在安全风险, }, { id: RULE-003, severity: INFO, pattern: rprint\s*\(, message: 发现 print 调试语句生产环境建议改为日志输出, }, { id: RULE-004, severity: CRITICAL, pattern: rdelete\sfrom\s\w\swhere\s1\s*\s*1, message: 发现无 WHERE 条件的危险删除操作, }, ] def run_local_rules(file_path: str): with open(file_path, r, encodingutf-8) as f: code f.read() issues [] for rule in RULES: if re.search(rule[pattern], code, re.IGNORECASE): issues.append(rule) return issues4.6 大模型客户端llm_client.py封装一个最简聊天补全请求。核心是把 HTTP 请求封装成通用函数不绑定任何具体厂商 SDK。# llm_client.py import requests import json from config import LLMConfig class LLMClient: def __init__(self, config: LLMConfig): self.config config def chat(self, system_prompt: str, user_prompt: str) - str: url self.config.base_url.rstrip(/) /chat/completions headers { Authorization: fBearer {self.config.api_key}, Content-Type: application/json, } payload { model: self.config.model, temperature: self.config.temperature, max_tokens: self.config.max_tokens, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], } response requests.post(url, headersheaders, jsonpayload, timeout60) response.raise_for_status() data response.json() return data[choices][0][message][content]需要说明的是有些服务商的返回结构可能略有差异或者需要额外传api_base参数这个封装只是一个最通用的版本。4.7 主程序review_agent.py把整个流程串起来。# review_agent.py import argparse import os from config import LLMConfig from local_rules import run_local_rules from llm_client import LLMClient SYSTEM_PROMPT 你是一名高级代码审查工程师擅长发现代码中的逻辑缺陷、安全隐患、性能问题和可维护性问题。 请基于用户提供的代码给出简洁、可执行的改进建议。 要求 1. 按严重程度排序先列严重问题。 2. 每条问题给出文件名、行号如果可知、原因、修复建议。 3. 如果代码本身质量很高可以明确说明。 4. 不要泛泛而谈必须给出具体修改建议。 def build_user_prompt(file_path: str, local_issues: list) - str: with open(file_path, r, encodingutf-8) as f: code f.read() local_issue_text \n.join( f- [{issue[severity]}] {issue[id]}: {issue[message]} for issue in local_issues ) return ( f请审查以下代码文件{file_path}\n\n f本地规则扫描结果\n{local_issue_text}\n\n f代码内容\n\n{code}\n ) def main(): parser argparse.ArgumentParser(descriptionAI 代码审查 Agent) parser.add_argument(file, help待审查的代码文件路径) parser.add_argument(--base-url, defaultNone, helpOpenAI 兼容接口地址) parser.add_argument(--api-key, defaultNone, helpAPI Key) parser.add_argument(--model, defaultNone, help模型名称) args parser.parse_args() file_path args.file if not os.path.exists(file_path): print(f文件不存在{file_path}) return config LLMConfig( base_urlargs.base_url or os.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyargs.api_key or os.getenv(LLM_API_KEY, ), modelargs.model or os.getenv(LLM_MODEL, your-model-name), ) local_issues run_local_rules(file_path) print( * 60) print(本地规则扫描结果) print( * 60) if local_issues: for issue in local_issues: print(f[{issue[severity]}] {issue[id]}: {issue[message]}) else: print(未发现本地规则匹配的问题。) print() print( * 60) print(AI 审查结果) print( * 60) client LLMClient(config) user_prompt build_user_prompt(file_path, local_issues) try: result client.chat(SYSTEM_PROMPT, user_prompt) print(result) except Exception as e: print(f调用 LLM 接口失败{e}) print(请检查 base_url、api_key、model 配置以及网络环境。) if __name__ __main__: main()4.8 准备一个待审查的示例文件# sample.py import sqlite3 def update_user_email(user_id, email): password admin123 conn sqlite3.connect(user.db) cursor conn.cursor() # TODO: 这里需要补充参数校验 cursor.execute( UPDATE users SET email ? WHERE id ?, (email, user_id), ) conn.commit() conn.close() print(update success) def delete_all(): conn sqlite3.connect(user.db) cursor conn.cursor() cursor.execute(DELETE FROM users WHERE 11) conn.commit() conn.close()4.9 运行与验证export LLM_BASE_URLhttps://your-api.example.com/v1 export LLM_API_KEYyour-api-key export LLM_MODELyour-model-name python review_agent.py sample.py预期输出会分成两部分本地规则扫描结果和 AI 审查结果。本地规则会稳定报告RULE-001TODO、RULE-002硬编码密码、RULE-003print 调试、RULE-004危险删除。AI 审查会从数据库连接未关闭、空值校验缺失、事务未处理等角度给出更细致的建议。你可能发现AI 的建议并非每条都合理也会遗漏一些上下文。这恰恰是真实 AI 工程实践的常态AI 输出需要人工判断规则和测试才是底线。5. 实战延伸AI 编程助手在真实项目中的使用思路除了自己写 Agent直接使用 AI 编程助手也能显著提升效率。关键是掌握“怎么提问”。5.1 用提示词模板生成业务代码以 Spring Boot 项目为例一个能用的提示词不只是“写个注册接口”而是带约束的版本你是这个项目的后端开发者。 请用 Spring Boot 3 实现一个用户注册接口技术栈为 spring-boot-starter-web mybatis-plus mysql。 需求 1. Controller 路径为 /api/user/register请求方法 POST。 2. 入参包含 username、password、email 三个字段使用 DTO 对象接收。 3. 用户名唯一密码使用 BCrypt 加密后保存。 4. 返回统一 JSON 结构 ResultT成功返回 code200失败返回具体错误码。 5. 需要校验字段非空和邮箱格式。 请给出 Controller、Service、ServiceImpl、Mapper、DTO 的完整代码并补充一个单元测试示例。 输出时标注每个类的完整路径。这样做的好处是角色、技术栈、需求、输出结构都明确AI 生成的代码才有落地的可能。5.2 用 AI 生成单元测试AI 写单元测试比写业务代码更合适因为测试的输入输出是确定的。请为以下方法编写 JUnit 5 单元测试使用 Mockito 模拟外部依赖。 要求 1. 覆盖正常流程、参数为空、内部异常三个场景。 2. 断言必须验证返回值而不是只验证方法被调用。 3. 测试类命名遵循 class 名 Test 后缀。 方法代码如下生成之后不要直接信跑一次测试再看覆盖率再决定补不补。5.3 用 AI 解释和重构遗留代码遇到一段没人能看懂的旧代码可以把整段代码发给 AI请解释下面这段老代码的业务意图说明它潜在的风险并给出重构建议。 要求 1. 先用三句话概括这段代码在做什么。 2. 指出可能存在的 bug 和异常分支。 3. 给出重构后的 Java 代码保持对外接口行为不变。这种场景下AI 的“开放性解释”很有价值但重构结果必须靠测试兜底。老代码动一层就可能导致线上故障不要允许 AI 直接改生产代码。6. 常见问题与排查思路在实际使用 AI 编程工具的过程中高频问题主要集中在配置、上下文和输出质量上。问题现象常见原因解决思路调用 API 返回 401api_key 错误或无效检查环境变量、密钥权限确认服务是否在有效期内返回 404base_url 或接口路径错误确认接口是否为 OpenAI 兼容格式检查/chat/completions路径请求超时网络不稳定、模型负载过高、超时时间太短在配置中增加超时时间业务系统里建议加重试和降级生成的代码能编译但运行报错上下文缺失、技术栈版本理解错误把完整报错、依赖版本、项目结构一起发给 AI生成的代码逻辑看似正常但结果错误AI 幻觉以单元测试为准把生成代码和边界测试一起跑一遍IDE 插件一直转圈不输出插件与 IDE 版本不兼容、代理配置异常升级 IDE/插件版本检查网络和代理配置本地模型推理速度慢显存不足、模型过大换小模型或量化版本必要时使用云端 API排查时我习惯从两条链路入手配置链路环境变量、API key、接口地址、模型名是否都正确。执行链路先跑通一个最小请求确认调用没问题再叠加复杂功能。7. 最佳实践让 AI 成为可靠的生产力工具7.1 把 AI 当“实习生”而不是“权威专家”AI 写代码的能力在提升但它的可靠性还远没有到“免检”程度。正确的心态是把它当成一个执行速度极快但有概率出错的实习生。凡是它产出内容都必须经过编译、测试、人工 review 三道关卡。在实际项目里我会把 AI 生成的代码分为三类可直接使用脚手架、工具类、单元测试模板、注释生成。需人工修改业务 CRUD、权限控制、复杂 SQL。禁止 AI 直接处理生产环境脚本、数据迁移、删除操作、安全敏感逻辑。7.2 代码审查与安全边界AI 辅助开发不能变成“无人审查开发”。建议团队约定所有提交必须经过人工 Code ReviewAI 生成的代码要标记来源。涉及数据库删除、生产数据更新、第三方支付的代码不允许直接由 AI 生成并合入。把本地规则扫描类似我们上面的local_rules.py接入 CI先把确定性问题截住再交给大模型做开放性检查。7.3 数据隐私与合规千万不要把公司核心代码、客户数据、内部账号信息随意粘贴到外部 AI 服务中。建议敏感项目优先使用本地模型或私有化部署方案。使用外部 API 时先脱敏、再提交。在 IDE 插件中关闭自动发送代码的选项或者使用不允许上传代码的模式。有条件的团队在网关层做审计日志记录哪些代码片段被发送到了外部模型。7.4 性能与成本控制AI 工具不是免费的。模型调用会带来两个成本时间成本和资金成本。工程上可以这样做给不同任务分配不同模型简单补全用轻量模型复杂推理用强模型。设置合理的max_tokens和超时时间避免模型无限输出。在 Agent 链路里加入本地规则预筛确定性规则能解决的问题不要浪费大模型调用。对调用做流量控制和缓存相同代码片段不重复请求。7.5 日志、可观测性与增量接入如果团队要落地 AI 辅助工具建议从低风险场景开始小范围试运行而不是一次性让所有人在生产代码里使用。需要记录的数据包括调用了哪个模型、传了多少 token、耗时多久。AI 输出的代码是否被修改后合入修改比例是多少。是否因为 AI 输出引入了线上问题根因是什么。这些数据收集一段时间后你就能判断自己的 AI 使用方式是否真的提升了效率而不是只是“看起来热闹”。8. 总结AI 不会取代你但会重塑工作方式回到开头的 POV 视频。你真的会被 AI 取代吗我的答案是短期内不会但你的工作内容一定会变。过去一个初级开发者可能要花半小时写一个 CRUD 接口现在 AI 十几秒就能生成你要做的是理解需求、约束边界、审查代码、写出可靠的测试。这种情况下会写代码只是基础能力理解系统、控制风险、验证结果才是真正的护城河。如果你已经接触过 AI 编程下一步可以从这几个方向深入把提示词工程系统化总结一套适合自己项目的提示词模板库。学习 LangChain、Spring AI 这类 Agent 开发框架把模型调用和工作流结合起来。研究 RAG检索增强生成让 AI 基于仓库代码回答问题而不是凭“记忆”胡说。在团队里搭建一套 AI 代码审查基础设施从确定性规则开始逐步加入模型能力。动手永远是消除焦虑的最好方式。与其刷一条“AI 取代工作”的视频焦虑三分钟不如打开终端把今天这个代码审查 Agent 跑起来。当你真正理解 AI 能做什么、不能做什么之后你在这个行业里的位置会比 AI 生成的任何代码都更稳。