898 字
4 分钟
页面浏览--访问次数--
整了个mc模组,对ai编程有了新的理解

脑袋里突然冒出的想法#

前段时间,和朋友们一起玩我的世界整合包,按照我们向来的习惯,都是会加一个听歌模组进去一起听歌的,我们用的是 ALLmusic

coloryrAllMusic

效果很不错,就是总有笨比记不住这么简单的指令,所以我就想找找其他的替代品,

后面发现了 DangoMusic 这个项目

SorihikoDangoMusic

ui很好看,点歌也很方便,但是有一点我不满意

如果想要启用一起听歌,必须使用 Firebase ,而Firebase离国内最近的节点都在新加坡

我是无所谓,但服务器里可是有个直连国内都是生死局的卡比

这时我想到了之前使用的 ALLmusic,我就想,为什么不能把模组的多人同步这块改成和 ALLmusic 一样的服务器权威形式呢😀☝️

以我小学生一般的Java基础,不会的就顺便问问ai,貌似也不是什么困难的事情

顺带一提其实我找到了一个功能更加完善也更成熟的模组,叫 MuoniumPlayer

但我把人家看成收费模组了😇😇😇

最后基于 DangoMusic 项目,用ALLmusic的思路进行了修改

yisibuwangBuWangMusic

磕磕绊绊#

其实说起来挺丢脸,我的大学数学基本都是ai教的我,以前我在期末周用 Gemini 疯狂询问,让他出题或解释思路;对于编程,让ai分析项目,告诉你每个模块都有啥、干什么,怎么写比较好都能给你说的明明白白

对于ai编程,我认为在实际使用过程中遇到的许多问题都是可以用过约束和提示词来控制的

我见过周围的一些人使用ai来完成作业或是编程,但他们都是想到哪写到哪,什么信息都不给ai说,又盲目听信它,相信一直跟着他走就能找到目标,最后却在一条条长篇大论和公式化询问中搞的焦头烂额

我在一开始接触这方面的时候也是这样的

现在我一般习惯在执行这种可预见的长任务前,都预先写好要注意的实现的功能或效果,让ai自己生成一份文档,再根据情况修改后让他按任务或模块规划开发计划,最后再是开发;这样在实际工作前就能发现很多ai自己理解出现偏差或不符合自己心中的情况出现

flowchart TD
    A[输入目标] --> |提问确认需求| B[需求文档]
    B -->|修改需求| C[任务文档]
    C --> D[开始执行]

在使用过程中我发现 agent 对任务结果的影响也相当大

我一开始使用的dsh来完成任务,但发现有时候哪怕约束了,还是会出现做了开关和逻辑,却没有关联使用;或是自己自查发现有问题,却修了这个毁那个;但我在后续切换了codex后从来没遇到过类似的问题;

毕竟dsh还是正在成长的测试版,和codex这种已经面向C端的成熟agent不一样,而且我没有严格控制变量,没准是我自己的问题

对于功能的实现,要严格和它界定好,尽量一次加一个功能,一次测试好再继续,将功能模块解耦,专人干专事;不然维护到后面,可能会出现同一个功能,左一个实现,右一个实现的奇葩情况

整了个mc模组,对ai编程有了新的理解
https://www.yisibuwang.top/posts/2026-11-01-整了个mc模组对ai编程有了新的理解/
作者
不旺の博客
发布于
2026-11-07
许可协议
CC BY-NC-SA 4.0

分享文章

生成精美分享图或复制链接,与更多人分享本文。

继续阅读

沿着主题读

基于共同的标签与分类

换条路线

从其他文章中稳定抽取

评论

正在加载评论...