通义灵码代码生成使用感受

最近使用了一段时间通义灵码，我是在idea中安装的通义灵码的插件来使用的，为的是能上下文理解我的代码，好能更合适的生成我需要的代码。
其实我并不是全栈工程师，确切的说我都不算web工程师，之前更多的是做windows平台的程序开发，最近想看看若依框架，正好看了个视频，介绍若依框架结合AI，讲的是使用通义灵码，就正好试一下。

试过生成SQL语句，通过给定要求，生成建表语句，生成多表联合查询语句，效果都很好，没有出现错误，在我并不很懂SQL和mybatis的情况下，很快能看懂语句的意思。试过优化HTML的式样，本身对css了解就很少，对vue更是不熟，填写了主要的界面元素，让通义灵码直接优化，说做好看一些，效果上肯定是比我自己写的要好看很多，但如果是有客户明确需求或有界面原型的，靠文字描述告诉通义灵码，让它精准生成css，就很难了，我还没发现怎么让通以灵码怎么直接看原型界面或图片。试过通过描述需求，让通义灵码生成适配微信小程序的uni-app界面代码，基本能够按描述生成所需的页面元素和关键函数，整体框架上是可以用的，问题是有些生成的函数在uni-app中并不能直接使用，或经过编译到微信小程序工程后一些样式不能直接使用，所以还得调bug。但对于我本身并不会写web程序来说，这样生成的代码还是比我从零开写，或从网上找些案例扒代码还是要快很多的，不清楚是不是对前端工程师来说，这个功能是否能提升开发效率。试过将遇到的编译错误通过通义灵码来修改，有些问题给出的解决方案很好很精准，有些修改方案并没有效。
就这几天的感受来说，整体上感觉通义灵码的代码生成还是很牛的，总结几点：
a.可以让我一个不会web开发，但懂编程思路的程序员，可以通过自然语言就实现了功能需求。
b.对知道如何写的代码，能实现不用逐行敲或VC代码，从而提升开发效率。
c.对界面的修改要求，没有好方法能够精确传递并实现。
d.对不确定的代码，可能产生更多查找生成代码中bug的工作量。
对于uni-app的代码，我没有使用VS code，而是使用的hbuilder，hbuilder中并没有通义灵码的插件，我是通过idea中的插件，自己提供上下文描述来生成代码的，不知道VS Code中通义灵码的生成效果是不是更好，比如是不是能更好的理解上下文，是不是能自动创建出新的页面文件等。

总结

### 文章总结
**标题：试用通义灵码插件的体验与总结**
**内容概述**：
本文作者作为一名非全栈工程师，主要以Windows平台程序开发为背景，近期尝试了使用通义灵码插件在IDEA中提升代码编写效率，特别关注于其在理解并自动生成代码方面的能力。通过多个实际场景（如SQL、HTML样式优化、uni-app界面代码生成以及编译错误修改）的测试，作者对该插件的性能和实用性进行了深入体验和评估。
**主要体验与发现**：
1. **SQL生成与优化**：
- 作者在不懂SQL和mybatis的情况下，通过通义灵码成功生成了建表及多表联合查询语句，效果佳且无误。

2. **HTML样式优化**：
- 尽管作者CSS和Vue基础薄弱，但通义灵码根据界面元素描述优化了HTML样式，效果显著提升。然而，对于精确满足客户需求或界面原型的设计，仅靠文字描述效果有限。
3. **uni-app界面代码生成**：
- 通过自然语言和需求描述，通义灵码能够生成基本的uni-app界面元素和关键函数，虽然部分生成代码需要进一步调试以适配微信小程序，但总体上大大加速了前端开发流程。
4. **编译错误自动修正**：
- 部分编译错误的自动修正方案有效且精准，但并非所有修改建议均可行，需要用户甄别。
**总结评价**：
- **优点**：
a. 实现了自然语言编程，非web背景程序员也能轻松完成功能需求实现。
b. 提升了已知代码的编写效率，减少重复性工作。

- **不足**：
c. 在精细界面设计需求传递上存在局限，难以达到像素级精确。
d. 生成代码的可靠性可能带来额外的调试工作量，尤其是针对不确定的代码情况。
**未来展望与疑问**：
- 作者好奇VS Code中通义灵码插件的使用体验，特别是关于上下文理解能力和自动生成新文件的能力是否更强。
**结语**：
通义灵码插件作为一款创新工具，在特定场景下显著提高了代码编写效率与便利性，尤其适合非全栈或从其他平台转来的开发者快速上手。然而，其生成的代码质量仍需在使用过程中细心验证和调整。