AI 编程实战：Copilot、Cursor 与代码大模型—

让 AI 补一个函数很方便，把一段改动放心合进去却需要更多判断：需求有没有理解错，测试覆盖了什么，生成代码是否沿用了项目约定？这篇围绕这些具体问题讨论工具使用、上下文准备和代码审查。效率是否提高，要结合任务完成时间和返工成本来衡量。

前置阅读：建议先读 Prompt 工程实战、AI Agent 开发实战。

三种形态：补全、对话、Agent

① 行内补全（Copilot 模式）：写代码时灰字建议，Tab 接受。适合：样板代码（构造函数、getter）、测试用例骨架、你本就知道要写什么的场景。这是最成熟的形态——成本低、干扰小、天天用。

② 对话式（Chat/Composer 模式）：描述需求，生成整个函数/文件。适合：新功能起草、不熟悉的库/框架（「用 SQLAlchemy 写个带事务的仓储层」）、正则/脚本类一次性代码。关键在描述质量——见下文上下文工程。

③ Agent 模式（自动改代码跑测试）：给目标，AI 自己读代码、改多文件、跑测试、修错误。适合：跨文件重构、写测试、修 lint。风险也最大——必须小步走 + 人工审查每个 diff，让它一口气「重构整个模块」是事故配方。

我的使用配比：补全 70%、对话 25%、Agent 5%——越自主的模式用得越谨慎。

上下文工程：AI 写不好代码，八成是上下文没给够

代码大模型和聊天模型的核心差异：它极度依赖上下文——你打开的文件、选中的代码、项目的结构。用好它的本质是「管理它能看到的上下文」：

# 差的提示
帮我写个缓存

# 好的提示
基于当前文件（cache.py），给 LLM 推理函数加一个 Redis 缓存：
- key：prompt 的 md5
- TTL：3600 秒，带 ±300 秒随机抖动防雪崩
- 缓存命中时记录 metrics.hit
- 参考已有的 _get_redis() 连接函数

要点：指定参考文件（「参考 _get_redis」让它复用现有模式而非另造）、明确约束（TTL 抖动这种工程细节它不知道你的习惯）、给出验收（「要能过 pytest」）。在 Cursor 里这对应 @ 引用文件/目录；项目级的 .cursorrules / CLAUDE.md 文件写清项目约定（「我们用 uv 管理依赖」「测试用 pytest 不用 unittest」）——一次编写，全程生效。

人机分工：AI 起草，人做法官

健康的分工边界：

环节	谁主导	说明
需求与设计	人	AI 不理解业务权衡
代码起草	AI	样板、常见模式、测试骨架
边界与异常	人	AI 写的「快乐路径」很溜，边界处理常缺
代码审查	人	每个 diff 都要过眼看
测试验证	共同	AI 写测试，人验证测试真的有效

AI 代码的三个高频暗伤（审查清单）：① 边界缺失（空列表/None/超时的处理「忘记」写）；② 安全漏洞（SQL 拼接、密钥硬编码、路径穿越——它学的是公开代码，公开代码平均水平不高）；③ 依赖幻觉（编造不存在的 API 或参数——不流行的库幻觉率更高）。

防退化纪律：肌肉不能废

用 AI 编程一年后的自测：关掉它，你还能写吗？我给自己定的纪律：

核心算法自己写——业务的关键路径（模型训练循环、数据管道核心）手写保持手感，AI 只写周边。
每个 diff 读懂再提交——看不懂的代码不进仓库，这不是洁癖：半夜报警时你要改的是这些代码。
用 AI 学习而不是替代学习：让它解释不懂的代码（「这段正则什么意思」）、对比方案（「这个用 asyncio 和多进程各怎么写，优劣」）——把它当随叫随到的导师，而不只是代写。

对初学者的特别提醒：先用基本功再用加速器——我见过实习生让 AI 写全部代码，三个月后丧失了独立写函数的能力。AI 是杠杆，放大的是你已有的判断力。

踩坑排查

现象	原因	解法
生成的代码调不存在的 API	依赖幻觉	让它「基于官方文档」/贴文档进上下文；用流行库的主流 API
代码能跑但风格不符项目	没给项目约定	项目级 rules 文件 + 引用现有文件
Agent 模式越改越乱	任务太大	拆成小任务逐个验收；git 小步提交可回滚
测试全绿但逻辑错	AI 写了「过测试的代码」而非正确代码	人审查测试断言是否真的验证行为
敏感信息进 prompt	代码里的密钥被发给云端	配置忽略文件（.cursorignore）；密钥走环境变量

练习

选一个你熟的模块，让 AI 重写它，然后逐行对比——它的版本在哪三个地方比你的差？
写一份项目级 rules 文件（技术栈、测试框架、代码风格、禁止事项），对比写之前之后 AI 输出的差异。
用 Agent 模式完成一个跨文件任务（如「给所有 API 端点加请求日志」），小步验收每个 diff。
安全审查练习：让 AI 写一个「用户登录接口」，然后专门审查它的 SQL 处理和密码存储——找出至少两个安全问题。

面试常问

Q：AI 编程工具对工程师能力要求的变化？ 三个能力升值：需求澄清（把模糊业务变成精确规格的能力——AI 越强这个越值钱）、代码审查（快速判断生成代码的正确性和风险）、系统设计（AI 写组件，人做架构）。两个能力贬值：语法记忆、样板代码速度。结论：工程师的核心从「写代码」转向「定义问题 + 验收方案」——ML 系统设计能力比手速更保值。

Q：怎么评估团队引入 AI 编程的效果？ 别信「感觉快了」。可测的维度：交付周期（需求到上线）、代码审查发现的问题类型变化（样板错误减少、设计问题占比上升）、测试覆盖率变化、线上缺陷率（关键——速度不能以质量换）。DORA 指标框架直接可用。警惕「速度幻觉」：写代码快了但返工多了，净收益可能是负的。

Q：AI 生成代码的安全风险与治理？ 风险：引入漏洞模式（注入、弱加密）、依赖幻觉引入恶意包（「slopsquatting」——注册 AI 常幻觉的包名投毒）、许可证污染（生成代码可能复述 GPL 代码）、代码外泄（企业代码进 prompt 到云端）。治理：生成代码强制 SAST 扫描、依赖安装前人工确认包名、企业版工具（代码不出域/不训练）、许可证扫描进 CI。

Q：代码大模型和通用 LLM 的技术差异？ 训练数据配比（代码 30~50%）、FIM（fill-in-the-middle，中间补全——行内补全的关键训练目标）、长上下文（跨文件理解）、工具集成（能跑代码验证自己的输出）。评估也不同：HumanEval/SWE-bench 的可执行评估比文本相似度可靠——代码是少数「对错可以自动判定」的生成任务。

Q：什么任务不适合 AI 编程？ 新颖算法实现（训练数据里没有的模式，它会硬凑出「看起来对」的错代码）、强业务逻辑（它不知道你的业务约束）、安全关键代码（密码学、鉴权——错的代价太大）、遗留系统的潜规则（文档没有、口口相传的坑）。共性：「对错的标准不在公开代码里」的任务，AI 都靠不住。

AI 编程实战：Copilot、Cursor 与代码大模型——把 AI 变成结对程序员