说出来可能你们都不相信，其实我是一个“行为艺术家” ... 

我从小到大坚持的就一个目标，那就是“把我自己的想法都实现了！”，我自己的能做的就自己做了，自己做不到的就忽悠能做的帮我！之前是忽悠基友，后面是404的小伙。这个期间诞生不少好玩有趣的东西，有的东西到现在看还是可用的经典！人到中年，很容易“想当年”！可惜当年被我忽悠过的基友很多可能都已经不在网络安全这个行业了，404的小伙伴也换了一波又一波，不过也留下了“面向黑哥编程”的各种传奇...

大模型时代已来，所有的东西都将或已被重塑，当然包括当年被我忽悠过的基友，所谓“君子之交淡如水”，很多时候多年前的老友很多都已经转移了方向，虽然都保留着微信好友，但是平时的交流基本可以算是非常少了，而前段时间我惊喜的发现多年的基友因为大模型又重新发起一波交流讨论。看起来大家对新技术的追求，还是刻在骨子里的！这也说明大模型时代，对大家的影响是全方面的，无论你转移到了哪个领域，我们都回归到了的同一个点，你就是大模型时代，我们能用大模型技术干点什么！

“大模型AI时代，有时候其实就差拥抱的意识或者态度” 这个算是我在2024年不停的研究尝试并“苦口婆心”推荐大模型各种应用后最大的感受！很多时候，你只看或者只听黑哥忽悠还是不够的，需要自己真实的落地去尝试，才能给带来真真切切的感受！

但凡听黑哥忽悠并实践一波的我估计都会很认同这些观点，如果你非不认同，我觉得你也应该去实践一波然后过来打黑哥的脸～～

当然忽悠的同时，也得自我怀疑，自我否定，才是真正的“行为艺术”

[当你拥有了超能力后，你需要的可能是脑子]

这里说的“超能力”，当然也包括“钞能力”，虽然我还没有怎么体验过，不过一般看影视剧里暴富后都是非常“空虚”，可能就是这种感觉！在2024年我吹得很多的估计就是Cursor了，当然还包括这一类的AI编程的能力，换句话说在现在大模型AI时代，编码成为了人人都有可能掌控的“超能力”，就好像黑哥在朋友圈里发：

「8年后终于看到了新希望，大模型时代应该是“产品经理”的时代！」

在我之前的尝试，都是很小的需求，对于现有大模型的编程能力来说那都属于“基操”，作为一个自诩的“行为艺术家”，那肯定不能满足这种情况！我决定去尝试下AI编码的“极限”在哪里！其实有这个想法的时候，一开始突然发现自己也“空虚”了，一下找不到好的“点子” ...

[先做个垃圾出来]

这个是之前网上看到的一个图，这个对于当年依靠“整就牛”者三个字“火爆”知乎的我来说，很有共鸣，先干起来再说！于是我把目光锁定在我刚入手的Mate70Pro及Mac Mini M4乞丐版上，入手Mate70Pro的目的就是为了纯血鸿蒙系统（鸿蒙Next）及国产手机AI的体验，入手Mac Mini M4乞丐版就是为了本地跑大模型的极致性价比，而他们有个共同点就是大模型AI的应用，所以为什么不在鸿蒙Next系统上开发一个对应的大模型应用的APP呢？看起来这是一个非常选择去尝试我的“行为艺术”，因为对于我来说完全是0基础的鸿蒙Next APP开发经验到底能做到什么程度对我自己而言还是非常期待的！

本着先干起来的原则，与其纠结那么多，不如就做一个通过调用部署在Mac Mini M4上的ollama、LM Studio的API大模型的鸿蒙Next手机客户端APP吧！

[大模型时代，办法总比困难多]

选择纯血鸿蒙系统开发还有一个原因，就是网上有一大波的觉得鸿蒙系统可能会再到诺基亚、手机windows等系统的覆辙，因为确实开发者生态，然后我个人认为时代不一样了，很多的游戏规则开始发射变化，当然这个观点不是完全没有根据，我必须承认从发布后入手Mate70Pro到现在还是备用机，核心还是在于微信，可以说微信这种头部的APP是制约一个新系统的非常大的坎！当然这些头部的应用我是无能为力，但是在新的小而美的APP来说，我一直认为大模型时代应该会毫无压力～

所以我觉得Huawei应该把核心重点放在AI发现上，包括AI在手机端的应用（小艺）、大模型开发鸿蒙Next APP等上面。不过目前我个人看到的还是不太够，我在动手之前搜索了下互联网基本上没有看到应用AI编程来做鸿蒙开发的视频或者文章，所以我接下第一步就是去官方网站注册并下载安装开发环境：

DevEco Studio

https://developer.huawei.com/ 

安装还是没有啥困难的，我用的Mac x86版本（因为我的iMac还是i9系列的），不过在使用过程中，其实比较困扰我的其实是“环境变量”的配置，因为SDK及对应的一些工具，你默认安装DevEco Studio后发现在你的终端是执行不来的，比如hdc（这个其实就相当于安卓里的adb，最开始我还在想Huawei回不回直接兼容adb 结果证明我想多了～），再比如ohpm，这个是ohpm 是HarmonyOS三方库的包管理工具（相当于nodejs中的npm），是不是有点浓浓的“山寨”味！可能是为了完全的“自主可控”，其实这些东西在某种程度也影响到了我后续的开发实践！

我当时遇到这些问题的时候，找了好久，也看了不是开发者社区的，其实很多答案都不可靠，因为鸿蒙这个开发体系实际上已经搞了好多年了，开发环境也是迭代了很多版本，很多的路径都变了，你甚至都找不到ohpm的路径，即使在DevEco Studio的设置里你也看不到，其实在DevEco Studio集成了这些东西，我这里的一手经验就是不用去管这些环境变量，你需要的直接在DevEco Studio提供的 Terminal 里直接执行对应命令就好了！

当然你有洁癖非要在系统终端里，那你设置好环境变量就好，不过如果你有开发洁癖，可能不太适合我接下要说的基于大模型的开发。

可能有的人会想接下来是不是应该去学习下语法了？怎么可能，如果要重新学习那我这个行为艺术就没啥意义了，要的就是0基础，刺激～～

不过在正式开始之前，我得找大模型确定下，他知道不知道鸿蒙系统开发语言，随手问了下ChatGPT及Claude答案是肯定的，那就没有啥后顾之忧了，直接打开Cursor开干！

[办法总比困难多之跨IDE编程]

我最开始的尝试是直接在Cursor的COMPOSER窗口（这里我需要强调下，我开发里基本上99%都在COMPOSER里完成）里，输入我的提示词：帮我使用ArkTS开发一个类似于ChatGPT的程序，调用远程服务器的ollama API （大体是这样吧），然后就开始狂写代码了，如果不出意外，那这个肯定是跑不起来的！因为对于一个app工程来说除了代码，还是还有很多其他的文件，这个时候你要做的其实是打开DevEco Studio，新建一个项目，空项目就行

然后连接手机run起来就行（注意要签名就是要华为注册下需要实名），当然你也可以选择去尝试使用模拟器，不过我不太喜欢用模拟器直接上用真机，恭喜你！你可以跟2胡同学一样去申请一个鸿蒙开发者证书了～～～

如果你不满足，那我们继续，这个时候就应该Cursor上场了，加载刚才DevEco Studio生成的那个项目的目录，还是直接的套路直接上COMPOSER，这里得加入 @codebase （注：这个@codebase的技巧，非常重要，当你觉得Cursor的代码出现问题的时候记得来那么一下），生成的代码无脑点“Accept all”就行

然后切换到DevEco Studio点run，对无脑run起来，不出意外的话肯定会爆错：

你可以不用纠结这些错误，看不懂也没事，直接cp出来（选择红色的错误即可）在Cursor的COMPOSER框里输入这些错误即可

还是无脑的“Accept all”，然后切回DevEco run，一般情况还会出现新的错误，无脑重复前面动作就行，直到成功run起来就行！

但是功能不正常，不用在意无脑告诉Cursor就行：

一看是api用错了，他直接修复了另外一个点是模型加载也不对，因为这个是写这篇文章临时做的demo演示就直接手工加了个模型，实际上我的成品app里是支持模型list的。

整个过程其实就是重复上面的这些流程，整个过程不只是在编译窗口出现错误的提示，还有一些是本身功能出现了错误，就好像上面提到的api用错了的，你直接描叙就好。另外一点在整个项目进行中Cursor的写的代码也会在考虑日志里进行调试，你需要做的直接把日志cp给cursor就行，当然可能你遇到一些不好描叙问题，尤其是UI上的，这种时候你可以直接截图发给Cursor就行（Cursor支持图片）都是在COMPOSER窗口 ...

所以我们回顾一下在整个“跨IDE编程”的过程中，DevEco Studio起的作用就是第一个生成一个空APP的基本架构，然后就是run，一旦出现错误就cp这些错误或者日志提供给Cursor。所以在大模型AI时代的跨IDE编程基本就是这个套路，这个套路对iOS、安卓开发也是一样的，当然未来做到自动兼容，其实也是可以的，现在很多趋势其实就是直接自动运行变异比如Cline套路，不过现在这些对专用编译的IDE环境支持还是不够的。

[办法总比困难多之ArkTS语法错误]

从上面的演示看到的几个错误就是非常代表性的错误，基本可以贯穿到整个项目的过程，这个核心原因跟上面提到的ohpm等是一样的，ArkTS源于TypeScript，然后又做了很多“约束”，按之前黑哥尔“大模型是集体经验主义”的理解，生成的代码肯定是按TypeScript的格式走，甚至写代码的时候生成都是ts文件，而不是ets文件，当然ts文件鸿蒙也是认的，但是有很多的语法必须按ArkTS的方式来，要不然你run的时候就会报错，就这个语法兼容的问题haiwei官方还出了一个：

从TypeScript到ArkTS的适配指导

https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V13/typescript-to-arkts-migration-V13

我当时其实是没有关注到这个东西的，因为我不管是ArkTS还是TypeScript我之前都没接触过，都是通过上面无脑cp错误丢给Cursor让他自己修改，这个时候可能就要考验你的耐心了，可能会出现很长一段时间重复动作，然后你的代码也就越改越多，而且有的时候还会因为一个简单的错误让你整个项目面目全非，这个时候你可能需要随时关注主线功能。

在这个过程中很多错误其实都是一模一样的问题，我觉得应该让模型直接总结，所以在前期没实现一个功能我都会让大模型自动总结语法记录到txt文件（这里建议用txt，如果是md可能出现代码等问题截断），这个你直接在Cursor里写提示词就行了，在COMPOSER对话里：“帮我总结下遇到的ArkTS语法错误，保持到ArkTS.txt 使用txt格式不用md格式”。

然后你就会积累整理出一个ArkTS语法规范，放到Cursor的@Notepad里，每次问题比较多时候在Cursor的COMPOSER对话@ 这个语法就行，当然你也可以写到 .cursorrules 里也行。

不过当我写这个文章的时候我还没有尝试 .cursorrules这种高级手法，追求的就是一个沉浸式无脑死循环看Cursor怎么虐带我～～～ 当然我这里还有一些小的tips 可以发挥下DevEco Studio的剩余加载，因为有的很简单的语法错误，IDE都会提供一个自动提示并自动fix的方案

你需要做的是，如果你在无脑cp错误的时候，点下错误，然后找到对应代码那个“灯泡”图标，如果有fix的这种，点fix all就行，这样你可以少去不少Cursor的token或者死循环机会！，当然你是在DevEco Studio里修改的代码，回到Cursor里建议来个 @Codebase 更新下，要不然很可能下一个需求你这个错误又被Cursor恢复了！

[办法总比困难多之版本控制]

前面提到了大模型时代0基础开发就是沉浸式无脑在两个IDE之间无脑“Accept all”+“run” ，这样导致的一个结果是因为太过沉浸可能导致代码面目全非，而且可能影响到之前已经测试ok了的基本功能，这个时候你需要的就是版本控制了，这个时候我估计很多人就会说用git了，嗯git肯定是一个好办法，也是非常主流的方法，但是对于我这种0基础的小白来说，学git是不可能学的，当然现在cursor支持你可以直接用自然语言描叙也能搞，可惜我个人对git存在比较深的成见，到现在也就会个git clone ，那怎么办呢？其实我的土办法非常简单，直接在把项目文件夹压缩一下就行，然后改个标识个版本号就行：

如果发现觉得Cusor把项目代码改得面目全非了，就直接把项目目录删除，然后点击前面备份的zip解压就行，唯一你要做的可能需要关闭DevEco Studio创新加载下项目，要不然可能编译出错！当然cursor里你最好得 @codebase下，关闭下那些乱生成的新文件窗口。

这里我比较建议，你完成一个比较稳定的功能后就备份一下！

[办法总比困难多之提示词约束与代码重构]

当你的程序开发功能越来越多，修复的bug越来越多的时候，慢慢你会发现莫名其妙的代码也越来越多，这是因为大模型在处理bug修复时候，可能会忘记了你原始的功能诉求，而只聚焦到错误本身，或者大模型有很多种备选的方案处理，比如你调用的组件是系统自带的还是其他的，调用的图标是系统自带的还是生成等，然后当你的项目越来越复杂，修正一个bug可以在a.ets里修改，也可以在b.ets里修改，那一不留神无脑点，可能就会导致的整个架构都变了，还有一些修正代码会莫名其妙删除一些正常的代码尤其是那种常量的定义等，这个时候你可以需要的就是“约束”，比如在提示词了来一个：请尽量使用系统只带组件、保持现有功能及架构、聚焦到错误修改不要改动其他功能及代码 等等类似的约束，当然这个可能需要你能基本看得懂每个代码实现的什么功能，虽然ArkTS等0基础，但是TS也是脱胎于JS，我对JS还是比较了解的，这点可能不太符合我开篇0基础的人设～～ 丢人了～～

这个也在于你的APP足够复杂的时候，可能会出现这些问题，在我做到1.6版本的时候，有个文件在修正错误的时候一度达到了3000行代码，这个时候你会发现一个错误丢给Cursor修正的时候，就会出现bug越改越多，错误越来越多的真正的死循环，这个事情要考虑的酒是代码重构，当然这里可以分两种情况，如果只涉及到一个文件，代码量还不算太多，但是你觉得Cursor帮你搞太复杂了，这个时候你可以直接告诉Cursor：“你搞得太复杂了，直接帮我充够，简洁实现。” 是的 跟小柯（Cursor）对话很多时候就是那么朴实无华，不用顾忌一些莫名其妙的感受！

然后另外一种情况就是上面提到的，文件代码太多了，结构太复杂这个时候就需要重新架构，对于后续的开发是非常有帮助的，要不然你会陷入无休止的死循环中，根本搞不下去。具体到我那个项目里当时所有大模型的API调用都放在了一个文件里 ChatService.ets里，随着我增加的API及功能越来越多，逻辑就非常复杂，当时我想支持Function Calling功能基本上是做不下去的，因为涉及的逻辑还是很复杂的，而且你单一文件太大，理论上对于Cursor通过RAG等方式确定代码位置，准确度可能越来越低，所以这个时候有必要把每个API调用拆分独立的模块。

这个时候你可以也会有我在朋友圈那样的感叹：

「AI编程时代，可能产品经理之外还得需要架构师，因为经过我实战体验，随着项目功能越来越多，代码越来愈多，屎山代码也对应越来越多，如果没有好的架构，很难再持续开发新的功能！！」

那么我们的极限到此为止了吗？黑哥尔告诉过我们：大模型是个博士！对于我这种小的项目，重构也改算不上多大的难事！直接告诉Cursor让他帮你干就行了，不过这里我让他直接开干之前我让他做了方案去尝试下，演练一下，跟之前生成总结ArkTS语法的txt一样，在COMPOSER对话里：“@codebase 我需要重构这个项目，你有什么好的建议方案，生成保持到xx.md中”。

其实我这里想给大家重复我之前早就告诉过大家：“Cursor不仅仅是一个写代码的IDE”， 当你觉得方案不错了，你直接在在COMPOSER对话里：“@xx.md 按这个方案帮我优化项目 @codebase ”（涉及到多文件修改的时候带上@codebase准没错）

当然这个技巧也可以用到新功能开发，比如我在做function calling开发的时候，tools系统涉及到整个项目的多个关键代码文件，就是先让Cursor做方案后再按方案设计写代码的，效果还是不错的，不过到了更加复杂的项目那还得看开发者的水平，这其实就是极限了。

在设计方案的时候，有一个小的技巧就是使用@web 让大模型去搜索类似的项目的架构，当然你可以直接提供对应项目的代码给他学习参考，直接把URL丢Cursor就行！

[办法总比困难多之项目合并]

在做完上面演示的基本Chat功能后，立马就有了新的需求，果然还是得先做个垃圾出来，然后就会想着去优化这个垃圾，丰富一些功能！这个需求就是语音输入的需求，我当时想着用OpenAI的API来做，不过当时体验纯血鸿蒙的小艺同学，感觉他语音效果很不错，于是想着可能有现成的SDK啥的调用，于是在官方给出的演示程序中找到了一个demo程序

https://gitee.com/harmonyos_samples/core-speech-kit-sample-code-ark-ts-kit-asrdemo/ 

简单下载后直接DevEco Studio加载run测试基本功能是可以运行的，但是按钮特别多，而且先得点击“CreateEngine”，进行能力初始化，然后再点击“startRecording”，开始识别，于是还是得使用Cursor先对这个项目进行简化

然后把对应的代码cp到我们的项目结构下，然后告诉Cursor帮你调用实现语音输入的功能即可！（这种需要整体调用记得@codebase），不过使用测试这个语音效果肯定是不如小艺的，小艺有个识别后自动纠错的功能，这个目前是不具备的，不过对于我这个项目来说基本足够了！另外这个语音输入因为是直接CP过来的代码，在后续的修改了最好不要让Cursor的修改到这部分代码，要不然会出现很多莫名其妙的问题，尤其是线程相关的问题！（这个时候如果你发现不是你代码的问题你可能需要重启下手机）

可以看出来，在我这个“行为艺术”行动中，标准还是很低的，就是我真机能跑就行！

[项目功能介绍]

前面说了那么多，好像还没有整体描述下我这个项目都做了啥

1、API的支持

* Ollama * LM Sudio * Gemini * Nvidia* DeepSeek* Grok

至于为什么是这些API因为他们基本都有免费额度使用，这里体系下Grok的API比较坑，你获取模型list都算使用额度，我的项目是需要启动加载这些API支持的模型list，每次启动就会消费Grok的额度，所以我啥事都没干，免费额度就用完了！最好的方法就是直接定义支持的模型就行。当然LM Sudio、Ollama不存在额度问题，得先加载模型list比较通用

2、支持语音识别输入

3、支持多模型选择对话、支持上下文关联连续对话

4、支持场景提示词（这个就是提示词工程，国内平台一般管这个就称呼为“智能体”）

可以编辑场景、创建场景、是否支持工具等

5、目前LM Sudio支持Function Calling的工具

做了三个工具做演示：获取当前日期/时间、md5hash编码、ZoomEye查询

为什么是LM Sudio 因为他兼容OpenAI Function Calling的API格式，ollama兼容没有那么好！当然现在这个工具的支持会影响到上下文关联等问题，核心主要还是提示词太混乱，然后本地大模型本身能力的问题，因为这里涉及到工具需要提示词+场景的提示词+历史对话的提示词，这个问题估计不太好解决，只能降低标准了！

为了方便直观感受还是看演示视频吧

当然这个距离真正能发布的产品其实还是比较粗糙的，不过到目前为止这些功能对于我来说已经是够用了! 还有一个问题就是我留意到社区很多人有个疑问：就是纯AI开发的项目，后期怎么维护呢？其实在我这个项目里，我觉得还是很好维护的，不用去关注具体的代码，去关注本身的功能及bug修复即可（当然注意约束，不要瞎改），最后这个代码对于有洁癖的程序员或者开发者来说肯定是不忍直视的，我记得前段时间我卧底在一个开发者群里，看到一哥们做直播演示都是手动写代码，而不是我这种纯提示词，忍不住问了下他。他的回答就是说他有洁癖，AI写的还不如他自己直接写...

而很多开发高手基本上都有洁癖的！

最后

至于这个项目的代码就不发了，核心还是得自己动手体验，全程我都没写过一行的代码，不过其间因为代码错误实在Cursor现在修复不了我就删除了几行代码 ...

所以大模型时代不是取代，而是让更多的可能变成现实。

你需要就是“Accept”[拥抱AI]，然后“Run”起来[整就牛] ！