Published on 2025-08-06

AI辅助编程测试总结：从实验到实践的探索

在过去的一段时间里，我进行了一系列关于AI辅助编程的测试，旨在探索在严格约束下AI在软件开发中的应用效果。以下是我对这些测试的总结性文章，涵盖了测试的目标、结论、开发流程、模型选择、AI幻觉的应用以及一些实用建议。我希望这篇文章能为对AI辅助编程感兴趣的读者提供有价值的参考和启发。

1. 测试目标与结论

测试目标

本次测试的目标是评估在严格约束下AI辅助编程的效果，并与较为自由的vibe coding（一种强调直觉和创造力的编程方式）进行对比。通过构建一个博客系统，希望了解这种模式下AI在实际开发中的表现，特别是在时间成本、代码质量和开发效率方面的影响。

测试结论

时间成本：整个开发过程耗时约20小时。（20小时包含一些需求的梳理，和技术栈的探索，比如数据写入是基于数据库函数还是supabase js-sdk的调研等。）
模型使用成本：使用AI模型的成本约为7美元。（windsurf约消耗240credits）
成果：通过构建一个功能包含用户认证、标签、分类系统，支持文章创建、修改、删除，基于Supabase（Postgres数据库）的博客系统。

超出预期的原因：

代码质量：AI生成的代码质量高于预期。主观评估显著高于需求描述，AI生成代码的范式，特别是在数据库操作和API设计方面。
开发速度：我之前没有开发过完整的blog系统，无法直接量化对比。但20小时的时间交付了功能相对完善的产品，速度上我认为是很不错的。这主要得益于（1）AI创建代码速度快于人工；（2）生成代码可用率高。

未来计划：

基于本次测试的成功经验，我计划将严格约束下AI辅助编程作为未来开发的主要模式。
后续将尝试通过优化任务分解粒度和改进代码审核流程进一步提升开发效率。

2. 严格约束下AI的开发流程

2.1 业务抽象与任务分解

在开始开发之前，首先将博客系统的业务需求抽象为三个层次，希望与业务解耦：

数据库层（DB）：负责数据存储和查询。
API层：负责处理业务逻辑和数据交互。
视图层（UI）：负责用户界面的展示和交互。

基于此，我以读写分离为基本原则，将开发任务分解为一系列基本原语（primitive），例如：

在DB层创建函数或视图，写入或查询数据。
在API层创建接口，接口或读取数据，或写入数据。
在视图层使用类比为post/get的方式调用API。（因为我使用的solidjs，所以使用的action/query来进行读写分离）

这种分解方式使得每个任务都足够聚焦，便于AI理解和执行。

2.2 约束与代码规则

为了确保AI生成的代码符合项目需求和个人偏好，我为不同类型的原语设置了相应的约束和代码规则（我相信这部分工作很有可能被简化）：

DB层：SQL查询必须遵循性能优化原则、RLS原则、CURD原则等；
API层：API设计的基本原则（例如参数类型、返回类型、代码风格等），以及API的代码片段示例；
视图层： action和query的基本原则，以及对应的代码片段示例示例。
system：要求AI对返回的代码，以资深工程师的角度，详细介绍代码的逻辑。

2.3 代码审核环节

对AI生成的代码，我进行了逐行审核，具体步骤包括：

理解代码：阅读AI提供的代码解释，确保理解其逻辑。
对比约束：将代码与预设的约束和代码规则进行对比，确保一致性。
功能测试：在本地环境中运行代码，验证其功能是否符合预期。

2.4 TDD？后置测试的考量

在本次测试中，我选择不采用TDD（测试驱动开发）方法，而是使用后置测试。原因如下：

测试用例的正确性：AI生成的测试用例可能存在错误，依赖这些用例进行开发可能导致误导。
效率考量：后置测试允许我先快速生成代码，再集中进行测试和调试，提高了开发效率。不过，本次测试没有进行单元测试。仅做了简单的功能测试。

2.5 异步等待时间的管理

AI处理任务的等待时间是一个需要管理的环节。我采用以下策略来优化时间利用：

任务储备：提前准备多个简单任务，形成任务列表。
非阻塞执行：在AI执行一个任务时，继续维护任务列表和文档。
阻塞审核：当AI完成任务后，我暂停其他工作，专注于代码审核。

这种方式确保了AI执行时的等待时间被有效利用，同时保证了代码审核的质量。我个人强烈建议不要并行处理多个任务，因为：

多任务可能会带来代码重构，影响彼此间的任务执行，进一步“污染”上下文；
有的方案采用git分支的方式进行多任务并行，但这里合并代码的成本不容忽视；
多任务的切换，会造成较大的心智负担。

3. 模型选择与成本分析

3.1 模型选择

在众多AI模型中，我选择了Sonnet4作为主要开发助手，原因如下：

生成效果：Sonnet4的代码生成质量最接近我的预期，特别是在复杂逻辑和设计模式的应用上。
机会成本：尽管Sonnet4的价格较高（每1000 tokens输入0.3美元，输出0.015美元），但其高准确率减少了后续修改和调试的时间成本，整体上更经济。
其他模型主观评估（完全主观使用观点）：
- gemini 2.5 pro：效果接近sonnet4，但有时过于激进；
- kimi k2: 效果超出预期，且价格便宜，但我使用过程中发现了超出我预期的幻觉，而sonnet4并没有这种幻觉；
- qwen3 coder：效果超出预期，价格也很便宜，但上下文处理时，如k2一样产生了一些sonnet4没有的幻觉；
- gpt4.1: 超长的上下文理解能力，速度也很快，性价比高，但实际效果不稳定，不知道是哪里我没有处理好。

3.2 上下文控制

为了提高AI的理解准确性，我采取了以下上下文控制策略：

单任务单会话：为每个简单任务开启一个新的会话，避免上下文压缩和混淆。
上下文量限制：每个会话的上下文上限为20k tokens，确保AI专注于当前任务。

3.3 MCP

通过MCP自动注入上下文，其中最主要的是查询文档的context7，其次是postgres数据库表结构的mcp。其中context7效果很好，下面是一些细节：

文档整合：在prompt的末尾添加use context7，实现mcp自动对相关技术栈的文档注入上下文；
上下文上限：文档注入的规模设定10k tokens的上限，避免信息过载。

3.4 AI使用边界

最后，但并不是不重要，我明确了其使用边界：

适合任务：具体、简单的任务，如生成SQL查询、API接口等。
不适合任务：宽泛的需求描述，如“实现一个博客系统”，这类任务需要人工进行细化分解。这种不适合的任务，我尝试让AI给出方案和建议，然后基于建议形成具体的简单任务。

4. AI幻觉的适度应用

4.1 幻觉的潜在价值

在测试中，我发现AI的“幻觉”（即生成未明确要求的内容）有时能带来意想不到的好处：

设计优化：例如，在设计supabase API调用DB时，AI“幻觉”生成了一个db函数，简化了API的调用逻辑，提高了代码的可维护性。这是在任务执行过程中的方案创新，尽管偏离了我的严格约束，但结果是可以接受的。

4.2 避免设计模糊

尽管幻觉有时有益，但过度依赖幻觉可能导致代码偏离预期。因此，我采取以下措施减少设计模糊：

详细设计规范：在任务指令中明确API的参数、返回值和错误处理。
预设代码模板：为常见任务提供代码模板，减少AI的自由发挥空间。

5. 其他实用建议

5.1 IDE选择

在测试过程中和之前的经验，我尝试过多种IDE和编辑器，包括VS Code、Cursor Pro、Windsurf Pro和Zed。基于这些经验，我推荐：

Windsurf Pro：价格实惠（15美元/月），支持AI代码补全，每月500次请求。是除了github copilot最便宜的订阅。但其上下文管理能力略胜一筹（个人观点）。为尽可能表示中立，此处不提供我的推广链接；）
Zed：启动速度快，上下文不压缩，完全开源，非vs code 开源修改的IDE。订阅费用20美元/月。

建议：选择一个IDE后，尽量避免频繁切换，以免浪费时间在熟悉新工具上。在这点上，我感觉我消耗了过多的时间和精力。

5.2 Claude Code

如果有条件，我强烈推荐使用Claude Code，因为：

性价比高：Claude Code 使用sonnet4的性价比相对较高（对比第三方的IDE)；
上下文管理：支持更长的上下文，推测上下文不压缩。

6. 总结与展望

通过本次测试，我认为严格约束、代码逐行审核的AI辅助开发流程是我后续使用AI编程的基本方式，我也将其推荐给朋友们。与之相对应的需求描述、不审核代码，由AI自由发挥的模式（很多人称之为vibe coding），我个人并不推荐，无论是MVP的创建，还是可持续项目的迭代，都是当前大模型应用水平下远远不能达到的情况。

本文仅是个人评估的结果和一些观点。下一步会在进一步实践中不断完善，形成一个最佳实践，并将全部细节分享。

感谢您的阅读。