目录

又是被豆包指挥干事的一天

上周末,我通过与豆包交互,开始着手搭建我的个人博客网站,也就是你现在看见的这个,但在搭建的过程中,我发现了一个有趣的现象,

我大概可能似乎被豆包指挥了,我一步一步给它试错,踩雷,然后它高兴的排除了一个又一个错误答案,最终告诉了我一个100%不会报错的正确答案。

初试

事情的经过是这样的,我搭建的博客需要结合Github Pages,完成基于Github的自动托管。在这个过程中,需要用到Github的 workflow。 最开始,豆包是这样给我推荐配置的自动部署脚本:

/images/202604/image.png
deploy.yml

我将脚本推送到Github执行时,执行结果显示了一个 Unexpected value 'workflow_dispatch' 错误,随后我将这个错误反馈给豆包,然后豆包告诉我,我的格式写错了。

拜托,你让我这样写的好不好,我根本不会写这个,我连这个错误的都写不出来。

好吧,它居然学会“赖账”了,这样看来,AI还是不要像人的好。

豆包在经过我的错误反馈后,终于意识到 workflow_dispatch 位置不对。

/images/202604/image-1.png
修正workflow_dispatch格式

是的,就是在图中,豆包用手指重点指出的位置,它给我的第一版缩进不对,和on对齐了,正确的应该是和push对齐。

看在它使用了表情包的份上,我原谅它这次赖账了。

惊讶

随后,我又想给博客加个评论系统,因为涉及到 clientSecret,这需要保密,所以需要用到 Github 的环境变量,豆包推荐我如下配置:

关于保密clientSecret这点,也是我主动询问豆包的,它没有主动告知我,否则就可能将这类秘钥放到公共仓库了。其实Github也不会允许这类私钥推送到仓库中。

/images/202604/image-2.png
错误的环境变量配置

豆包仍然很贴心的为我指出了需要在 deploy.yml 文件中的何处添加变量,但可惜是错的,并没有成功替换变量,我又将结果反馈给了豆包,豆包告诉我说是我将 env 加错了位置,让我按照下图改正:

/images/202604/image-7.png
正确配置

好吧,豆包仍然解决了问题,但为什么都是我的问题啊,这让我突然想起网上的一句话,“有人在为你遮风挡雨,不要问风雨是怎么来的”。

问题到这里并没有解决,在博客的 toml 配置文件中引用变量时,根本不支持变量值嵌套双引号,我又将这个提示告诉豆包,各位看官老爷,你看看它的态度是多么离谱啊,它好像永远站在了正确的那一块格子上,把我踢来踢去的。

/images/202604/image-4.png
解决双引号问题

不过结果还是错的,然后豆包告诉我:“config.toml 根本不支持在配置里写 {{ getenv }} 模板语法!”,是的,它用上了加粗以及感叹号,拜托,这都是我的词好吧。

/images/202604/image-5.png
错误的参数变量解决方案

好在它给了我另一个解决方案,告诉我可以使用 hugo 的命令参数注入,但这仍然不对,因为 hugo 根本没有 --params 这个参数,好吧,这个雷又炸了,我灰头土脸的将这个错误告诉了豆包:

/images/202604/image-6.png
终极方案

是的,豆包的字典里没有错误二字,永远都是完美。我单方面宣布,豆包在乐观性这块完胜人类。

这次交互后,豆包终于实现了它的承诺,给了我一份可用的配置。

总结

这就是我这周末和豆包斗智斗勇的全貌了,尽管过程曲折,但仍然能够看出,豆包确实解决了我的很多问题。

虽然它总是以为自己很聪明,给出的答案都是100%、绝对正确以及简单安全的形容词,但我想这可能还是豆包的系统提示词中,含有了这类提示词。

归根结底,这仍然是一场人与人的交锋,与普通应用不同的是,这次的开发者们拿上了名为AI的指挥棒,开始向人们展示着他们的魔法。