AI 编程的多层次编程辅助策略

如果把 2022 年 6 月微软和 OpenAI 正式推出 Copilot 作为起点，AI 编程已经 3 年多了。

随着大模型的不断迭代升级，从 Copilot 到 IDE 下的 Cursor 入局，再到 CLI 模式下的 Claude Code，其可用性，准确度越来越好。

在提示词完整有效的前提下，很多功能，不管是前端，后端，算法，甚至是嵌入式都能「一把梭」。

在认知范围内，AI 编程成了一个很好用的工具。

我自己也在持续深入使用，以下为使用过程中不断迭代出来一些策略。

为什么是多层次辅助

用过很多种工具，每一种新的工具出来，都会试一下，也花了不少钱，但没有一种能解决所有的问题。

这就像家里的工具箱，螺丝刀、锤子、扳手各有各的用处。硬要用钳子拧螺丝，当然也能拧，但效率肯定不如螺丝刀。AI 编程工具也是一样的道理，不同的场景需要不同的工具，不同的任务需要不同的策略。

这些工具之间并不是互相替代的关系，而是互补的。我们可以在写代码的时候用 Cursor 的自动补全，遇到需要重构的地方切换到选中修改模式，碰到大块功能用 Claude Code 生成，真正棘手的问题再找 GPT5 帮忙。这种分层的使用方式，才是当前 AI 编程的较优解。

快速的自动补全

用得比较爽的还是自动补全功能。

为啥？

因为可以无脑 Tab，小范围的改动，看一眼是否符合预期就可以了，速度快。

用看起来比较高大上的词来说就是任务说明的比特量。

什么意思呢？假设我们要实现一个用户登录的验证逻辑。如果用自然语言描述，可能需要写："请帮我实现一个函数，接收用户名和密码，先检查用户名是否存在，然后验证密码是否正确，如果都通过就生成 token 返回，否则抛出相应的错误..."

但如果我们直接在代码里写：

def validate_login(username, password):
    # 检查用户是否存在
    user = User.query.filter_by(username=username).first()
    if not user:

写到这里，Cursor 基本就能理解你要干什么了，Tab 一按，后面的代码就出来了。这种方式的信息密度极高，而且是在正确的上下文位置，AI 理解起来更准确。

不过，自动补全也有坑的时候。有时候我们只是想换个行，它非要补全一大段；有时候我们在思考，它不停地弹建议打断思路。此时，我们可以在需要专注思考的时候就把它关了，需要快速实现的时候再打开。

还有个小技巧是写注释引导。比如我们要处理一个复杂的数据转换：

# 将嵌套的字典结构展平成列表
# 例如: {'a': {'b': 1, 'c': 2}} -> [('a.b', 1), ('a.c', 2)]
def flatten_dict(d, parent_key=''):

这种注释不是为了给人看的，主要是给 AI 看的。有了这个例子，AI 生成的代码准确率能提升一大截。

精准的选中修改

当代码已经写好，但需要调整的时候，选中修改就派上用场了。这个功能看起来简单，用好了却能大幅提升效率。

比如有一段用 for 循环写的代码：

result = []
for item in items:
    if item.status == 'active':
        result.append(item.name)

选中这段代码，告诉 AI："改成列表推导式"，立马就变成了：

result = [item.name for item in items if item.status == 'active']

或者有一个函数处理了太多逻辑，选中后说："拆分成多个小函数"，AI 就会帮我们重构。这种场景下，AI 的理解非常精准，因为上下文明确，任务单一。

我经常用选中修改来做这些事：

• 添加错误处理
• 优化性能瓶颈
• 调整代码风格
• 添加类型注解
• 生成单元测试

有个小点就是，选中修改的指令要尽量具体。比如「优化这段代码」就太模糊了，AI 可能会过度优化，把简单的代码搞得很复杂。但如果说「把这个嵌套循环改成使用 itertools」，结果就会精准很多。

大块的代码生成

当需要实现一个完整的功能模块时，Claude Code、Warp.dev 这类工具就该上场了。这一层的使用频率不如前两层高，但在特定场景下不可或缺。

什么时候用？通常是这些情况：

1. 实现标准化的功能模块

比如实现一个完整的 CRUD API、集成第三方服务、实现常见的算法等。这些功能有明确的模式可循，AI 生成的代码质量已经可以直接使用了。

2. 处理不熟悉的技术栈

最近我在写 Rust，说实话，ownership 和 lifetime 这些概念理解归理解，真写起来还是磕磕绊绊。这时候 Claude Code 就特别有用，虽然它不太愿意解释为什么这么写，但至少能给出能跑的代码，我可以在这个基础上学习和调整。

3. 生成一次性的工具代码

这是一个很常用的逻辑。以前写个临时用的小爬虫，怎么得也要半天，当字段多的时候，耗时更长了。现在不一样了，我会把地址，需要爬取的字段一次性给 AI， AI 会生成完整的代码，当出现问题时，如果能快速解决掉，就解决一下，如果不能，直接全部删了重新生成。

这可以叫做的「代码后稀缺时代」------代码不再是稀缺资源，我们可以为了一个临时需求生成大量代码，用完就扔。

当然，这种大块的代码，当提示词或者规则设定不那么好的时候，还是会一些坑会踩到，如：

代码品味问题：AI 生成的代码往往很"啰嗦"。明明可以用列表推导式一行搞定的，它偏要写个嵌套的 if-else；明明可以抽象成函数的，它偏要复制粘贴。每次用完都需要人工清理一遍。

过度防御性编程：AI 特别喜欢加 try-catch，有时候完全没必要的地方也要包一层。还喜欢做各种参数校验，即使在内部函数里也要检查一遍。

抽象层次混乱：有时候该抽象的不抽象，不该抽象的过度抽象。比如只用一次的逻辑非要包装成类，或者明明可以复用的代码却到处复制。

难题的深度求解

遇到真正棘手的问题时，就得请出 GPT5 深度思考模式 这种级别的模型了。速度很慢，但是往往能解决最关键的问题。

我印象最深的一次是在只有 8 MB 的嵌入式设备上增加一个小的文件系统，虽然官方有文档，但是语焉不详，在网上也没有找到可以参考的，再加上自己对于嵌入式开发不熟，折腾调试了两天，一直会挂，最后把全部上下文，包括在网上找的资料都扔给 GPT5，它分析了 2 分钟，最后发现是一个参数没有配置正确。

权衡与选择

说了这么多，实际使用中怎么选择呢？我的经验是这样的：

看任务复杂度：简单的补全用 Tab，局部修改用选中，完整功能用 Claude Code，复杂问题用 GPT5。这是基本原则。

看熟悉程度：熟悉的代码自己写配合自动补全更快；不熟悉的领域多依赖 AI 生成，但要仔细 review。

看代码生命周期：临时脚本随便让 AI 生成；核心业务代码要严格把关，宁可自己写也不能有隐患。

还有个重要的点是不要过度依赖。有人完全依赖 AI，自己基本不写代码了，甚至看也不看。短期看起来效率很高，但长期来说是有问题的：

1. 失去了对代码的掌控感，出问题不知道怎么改
2. 代码风格不统一，维护成本增加
3. 基础能力退化，离开 AI 就不会写代码了

AI 是辅助工具，不是替代品。核心逻辑还是要自己把握，AI 负责提高效率和处理繁琐的部分。

工具链协同

在实践中，这些工具不是孤立使用的，而是形成了一个工作流。我的典型工作流程是这样的：

1. 构思阶段：先在 ChatGPT 或 Gemini 上讨论设计思路，确定大方向。这个阶段主要是理清思路，设计数据架构，不涉及具体代码。

2. 框架搭建：用 Claude Code/WARP 生成基础框架和项目结构。这部分相对标准化，AI 生成的质量不错。

3. 核心实现：切换到 Cursor/Trae，自己写核心逻辑，配合自动补全提高效率。这部分需要精确控制，不能完全交给 AI。

4. 功能完善：需要添加的辅助功能、工具函数等，可以用 Claude Code/WARP 批量生成。

5. 优化调整：用选中修改功能做局部优化，比如性能优化、代码风格统一等。

6. 问题排查：遇到 bug 先自己调试，搞不定的再找 GPT5 帮忙分析。

这个流程不是固定的，根据具体情况会有调整。关键是要灵活，不要死板地只用一个工具。

使用中的常见陷阱

用了这么久 AI 编程，踩过不少坑，这里分享一些常见的陷阱：

1. 过度相信 AI 的输出

AI 生成的代码看起来很专业，但可能存在逻辑错误。特别是涉及业务逻辑的部分，AI 理解可能有偏差。一定要仔细 review，不能闭眼跑。

2. 忽视性能问题

AI 生成的代码通常能跑，但性能不一定好。比如该用字典的地方用了列表，该批量处理的地方用了循环。在性能敏感的场景要特别注意。

3. 安全漏洞

这个特别重要。AI 可能会生成有安全隐患的代码，比如 SQL 注入、XSS 漏洞等。涉及用户输入、数据库操作、文件操作的代码，一定要仔细检查。

4. 依赖混乱

AI 喜欢引入各种库来解决问题，有时候为了一个简单功能引入一个巨大的依赖。要评估是否真的需要，能用标准库解决的就不要引入第三方库。

5. 代码风格不一致

不同的 AI 工具，甚至同一个工具的不同时刻，生成的代码风格都可能不一样。如果不注意统一，代码库会变得很混乱。建议配置好 linter 和 formatter，生成后自动格式化。

提升 AI 编程效率的技巧

这里分享一些我常用的提升效率的小技巧：

1. 维护一个 context 文件

在项目根目录创建一个 CLAUDE.md/WARP.md 文件，写清楚项目的背景、技术栈、编码规范、常见模式等。每次让 AI 生成代码时都引用这个文件，能大幅提升生成质量。

2. 构建 prompt 模板

对于常见任务，准备好 prompt 模板。比如"基于以下接口定义生成 TypeScript 类型"、"为这个函数编写单元测试"等。模板能让指令更精确，减少来回调整。

3. 增量式开发

不要试图一次生成完整的功能，而是分步骤进行。先生成框架，再填充细节，最后优化。这样每一步都可控，出问题也容易定位。

4. 保存有用的代码片段

AI 生成的一些好的代码模式、工具函数，及时保存下来。下次遇到类似需求可以直接复用，或者作为 AI 的参考示例。

5. 学会正确提问

给 AI 的指令要具体、明确。不要说"帮我写个函数"，而要说"写一个函数，接收用户 ID 列表，批量查询用户信息，返回用户对象的字典，key 是用户 ID"。信息越具体，结果越准确。

6. 设置合理的预期

AI 不是魔法，它有能力边界。对于创造性的设计、复杂的业务逻辑、需要深度思考的算法，还是要靠人。AI 擅长的是模式化的、重复性的、有明确规范的任务。

写在最后

AI 编程工具的出现，确实极大地改变了我们写代码的方式。但它终究是工具，如何用好这个工具，还是要靠我们自己不断探索和实践。

我觉得现阶段最重要的是保持开放的心态，愿意尝试新工具、新方法，但同时也要保持批判性思维，不盲目依赖。每个人的编程习惯、项目特点都不一样，需要找到适合自己的使用方式。

这种多层次的策略不是固定的，随着工具的进化、个人能力的提升，策略也要不断调整。比如刚开始我很依赖 AI 生成完整代码，现在更多是用它来加速我自己的编码过程。

还有一点很重要：不要因为有了 AI 就停止学习。相反，AI 让我们有更多时间去学习更本质的东西------系统设计、算法思想、业务理解。这些是 AI 暂时还替代不了的，也是我们作为工程师的核心价值。

最后想说的是，我们正处在一个编程方式剧变的时代。三年前 Copilot 刚出来的时候，很多人还在质疑它的实用性；现在，不用 AI 辅助编程反而显得有点落伍了。这个变化速度会越来越快，保持学习、保持探索，才能不被时代抛下。

当然，工具再强大，代码背后的思考、设计、创造，还是属于我们的。AI 让我们从繁琐中解放出来，有更多精力去做真正有价值的事情。这大概就是技术进步的意义所在吧。

以上。