【九年回归！不吐不快！】

f1ybee

47人浏览 · 2026-03-27 22:48:02

f1ybee · 2026-03-27 22:48:02 发布

我用 AI 写了半年代码，有些话不吐不快

——AI 编程助手深度评测：哪些场景真香，哪些场景别信它

去年年底，我把 AI 编程助手正式纳入日常开发工作流。
半年后的今天，我想说一些真实的、不那么“营销号”的感受。

一、我用了哪些工具

过去半年，我主要用了三款工具，各有侧重：

Cursor（主力）
最接近“沉浸式编程”的体验。它的 Composer 模式能直接理解整个项目结构，跨文件修改、自动修复依赖问题，用久了会形成一种“被托着走”的依赖感。
GitHub Copilot（对比）
依然是补全类工具的标杆。虽然不如 Cursor 激进，但胜在稳定、无感，尤其适合日常的“行内补全”和写重复性代码。
国内工具（偶尔使用）
通义灵码、CodeGeeX 等，在中文注释生成、对接国内 API 文档时有一定优势，但整体能力仍有差距，更多作为备选。

二、真正提效的场景

AI 编程助手不是万能药，但在以下几个场景，它确实让我从“搬砖”里解放了出来。

✅ 样板代码生成

写 CRUD、配置文件、DTO 这类机械代码，AI 几乎零错误。
比如下面这段 FastAPI 的 CRUD 代码，我只写了一个注释，剩下的全是 Cursor 补全：

# 生成用户表的 CRUD 接口
@router.post("/users")
def create_user(user: UserCreate, db: Session = Depends(get_db)):
    db_user = User(**user.dict())
    db.add(db_user)
    db.commit()
    db.refresh(db_user)
    return db_user

过去写这种代码要 5 分钟，现在 10 秒，而且不用反复查文档。

✅ 写注释和文档

把一段代码丢给 AI，让它生成 docstring 或注释，比自己写快得多，而且格式统一。

# 输入：一个排序算法
def quicksort(arr):
    if len(arr) <= 1:
        return arr
    pivot = arr[len(arr) // 2]
    left = [x for x in arr if x < pivot]
    middle = [x for x in arr if x == pivot]
    right = [x for x in arr if x > pivot]
    return quicksort(left) + middle + quicksort(right)

# AI 生成的注释
"""
使用快速排序算法对数组进行排序。
参数:
    arr (list): 待排序的列表，元素应为可比较类型。
返回:
    list: 升序排列后的新列表。
"""

✅ 单元测试生成

写测试是件很“正确但枯燥”的事，AI 尤其擅长。
把函数丢给 Cursor，它能生成覆盖正常路径、边界条件、异常情况的测试用例。

# 被测函数
def divide(a: float, b: float) -> float:
    if b == 0:
        raise ValueError("除数不能为0")
    return a / b

# AI 生成的测试
def test_divide():
    assert divide(10, 2) == 5.0
    assert divide(5, 2) == 2.5
    assert divide(-6, 3) == -2.0
    with pytest.raises(ValueError):
        divide(10, 0)

✅ 跨语言/框架的快速翻译

把一段 Python 代码转成 Go，或者把 Vue2 语法转成 Vue3，AI 表现得像一个“双语工程师”。

比如我想把一段 Flask 代码改成 FastAPI，直接把代码贴进去，加一句“改成 FastAPI 风格”，几秒就得到可运行版本。

三、踩过的坑

如果只看到上面的“真香”，那我会觉得自己在骗人。这半年，我也踩了不少坑。

❌ 过度依赖导致对代码失去理解

最可怕的一次是，我在修复一个线上 Bug 时，习惯性地把报错信息贴给 AI，让它修。它给出了修改建议，我直接合了进去。
结果导致另一个模块出了更严重的错误。

问题：我根本没读懂那个模块的逻辑，只是机械地“让 AI 帮我修”。
应对：现在我会强制自己先理解报错的代码上下文，再让 AI 生成候选方案，然后我自己选。

❌ 生成代码有隐蔽 Bug

有一次 AI 帮我生成了一个多线程处理脚本，跑测试没问题，上线后偶发死锁。
仔细排查后发现，它用了 threading.Lock()，但逻辑里有两处锁嵌套顺序不一致。

# AI 生成的代码（简化版）
def task():
    with lock1:
        with lock2:
            # do something

另一处却是：

def other_task():
    with lock2:
        with lock1:
            # do something

这种死锁风险在单测中很难暴露，但真实并发下就会触发。
应对：AI 生成的并发代码、状态管理、复杂业务逻辑，必须人工 review，不能信任。

❌ 对复杂业务逻辑基本没用

AI 在处理“多表联查 + 权限校验 + 业务状态机”这类逻辑时，几乎没法直接生成可用代码。
它给出的方案往往过于简单，忽略边界条件，或者根本不符合当前项目的领域设计。

应对：复杂逻辑我坚持手写。AI 只用来帮我写其中的工具函数、数据转换、或是生成测试数据。

❌ 上下文窗口限制的困扰

Cursor 的 Composer 虽然能理解多个文件，但当代码量超过一定规模（比如几千行），它就开始“失忆”。
经常出现：修改 A 文件时忘了 B 文件中的依赖，导致生成代码不完整。

应对：尽量把大任务拆成小任务，每次只让 AI 处理一个独立功能，避免跨模块大改。

四、我的最终工作流

半年下来，我形成了一套相对稳定的工作流。核心原则就一句话：

AI 是副驾驶，不是驾驶员。

我的工作流大致如下（文字版）：

1. 需求分析 / 架构设计 → 我自己（AI 不参与）
2. 技术方案确认 → 我自己
3. 写测试 → AI 帮我生成基础用例，我补充边界
4. 写业务逻辑 → 
   - 重复性代码（CRUD、DTO、配置）→ AI 写
   - 复杂业务逻辑 → 我手写，AI 负责补全/优化局部片段
5. 写注释/文档 → AI 写，我润色
6. 代码 Review → 我重点看 AI 生成的部分，尤其是并发、事务、边界条件
7. 提交前自查 → 我手动跑一遍关键路径

简单来说：决策我做，执行 AI 做；核心逻辑我写，脚手架 AI 搭。