半投入的 Vibe 程序员日志

Source: Dev.to

第5季准备与 AI 辅助编码

旁注： 第5季将在 下周 开始！剧集将在星期四发布——就像我们这里的冒险一样。
前往 YouTube 频道，点个赞、留个评论、发个表情，并点击 订阅。免费且能帮助更多人一起发现我们的冒险！

为什么我在使用 AI

在为即将到来的季节构建应用时，我一直把 AI 当作伙伴。它的优势在于：

• 随时可用 —— 不必为每一个随机需要记住的东西翻阅文档。
• 快速 —— 往往比手动搜索更快。
• 出于好奇 —— 关于 AI 替代软件工程师的热议层出不穷。这是真的吗？最好的办法就是亲自尝试。

（我们应该找时间聊聊公开构建和这种学习方式的价值… 💡💡💡）

我的 “半投入” Vibe‑Coder 方法

我并不是把需求 直接扔 给模型，让它生成所有代码。
相反，我会：

1. 自己写一半的代码，再让模型补写另一半。
2. 将模型当作 思维碰撞的对象 与 探索工具。

我还有一份软件开发的日常工作，所以一些观察也来源于此。

观察几周的编码经历

1. 过度自由 = 过度抓脑袋

Season 5 的项目是一个 游戏，涉及几个基本模式：

• 游戏 事件循环
• 屏幕 绘制逻辑
• 加载与保存

我并没有写完整的需求文档——业余爱好者往往先搭几个基础，弄出可运行的东西，然后再添加功能。

当我说，“我在考虑做一个 Breakout‑clone 游戏”时，LLM 直接跳到一个 Pygame 主循环，并在窗口里 直接初始化游戏。

我不得不阻止它：

“嘿，直接进入游戏前加个 主菜单，用户体验会不会更好？”

模型立刻加入了主菜单实现，但随后我又得提醒它我仍然只有一个 空的项目结构：

• 代码文件放在哪里？
• 美术资源放在哪里？
• 如何使用配置文件而不是硬编码变量？
• 那 自动化测试 怎么办？

要点： 你不能把人类开发者完全剔除。AI 为了取悦用户，跳过了让项目可维护的设计思考。它的表现更像是一个全新的初级开发者。

你会在几乎没有指导的情况下，让刚毕业的新人去负责关键任务的应用吗？如果不会，为什么要相信 AI 能做到？

2. “简单” 任务可能演变成长时间迭代

我让我的副驾驶帮我写一个小函数，用来做我不想手动完成的三角函数计算。

结果： 经过 六次迭代，我们得到的代码虽然能运行，但并不完全正确。我们花了几个小时争论它的工作原理，我还在想到底消耗了多少 token。

我的 “省时” vibe‑coding 提示实际上 花了更多时间，比手动解决还慢。

这不是一次性事件；我一次又一次遇到同样的瓶颈。

3. 模型爱说（很多）

当我请求一行代码时，模型总觉得必须解释背后的全部历史。即使我要求简洁，它仍会加入额外的阐述。

在 每次调用的 token 计费 的环境下，这种冗长既不划算，又让人觉得有点可疑。如果你在卖 token，肯定想把每次调用的产出压到极限。

4. 真实世界的重构痛点

在工作中，我被要求重构一个 1000 行的 Python 模块。 “vibe‑coding” 的红灯非常明显：

结论

• 仍然需要人为判断。 AI 可以加速某些任务，但它常常跳过保持代码可维护性的关键设计和架构决策。
• 注意 token 成本。 冗长的回复会迅速耗尽预算。
• 将 AI 视为合作伙伴，而非替代品。 把它当作需要你指导的初级开发者，而不是完全自主的编码者。

接下来怎么办？

• 继续开发 Season 5 游戏，但在让模型编写代码之前 加强设计阶段。
• 保持一份 项目结构检查清单（资产、配置、测试等文件夹），提醒 AI 各文件应放置的位置。
• 设置 token 限额，并在可能的情况下要求简洁回答。

编码愉快，周四见，敬请期待下一集！ 🎮🚀

Source: …

认知复杂度计算器

背景

代码可以运行——输出与输入相匹配。如果一个从未接触过编码的人看到这段代码，他们会感到兴奋（这也是故事的核心：业务高管看到它运行后，对我们交付的速度感到非常激动）。

然而，这个模块是我们预期将成为 一系列用例 的 第一个用例，每个用例都需要一个定制版本来接入整体应用框架。

在当前状态下，这段代码 无法作为另一个开发者构建新用例的示例。

想一想： 新的需求出现，需要构建第二个用例。开发者会怎么做？
看看第一个！ 他们将花费数天时间去理清这堆意大利面条般的代码。

预期的反驳

1. “初级开发者类比是特性，而不是缺陷”

Blink，你应该扩展规模，拥有一百名初级开发者为你效劳，而你是架构师！

这在表面上听起来很有说服力、很鼓舞人心，但它与我们听到的炒作并不相符。我刚刷新了 LinkedIn 动态，前面三条都是人们声称 AI 代理已经 结束了软件工程。

• 问题： 我们是被赋能还是被毁灭？
• 答案： 不可能两者兼而有之。

2. “Vibe Coding 与 Agentic 工作流” 的差距

Blink，你就是做错了。这些问题的出现是因为你没有使用 $SOME_FRAMEWORK 或 $SOME_MODEL。

当有人承诺只要再加 一个东西 就能获得“所有好处”时，我会高度怀疑。这感觉像是永无止境的“你还需要再加一样东西”推销——很像金字塔骗局。

3. “Ensloppification” 是人类纪律问题

Blink，你完全可以用 AI 治愈 ensloppification，只要提示它生成干净的代码……

核心问题

AI 被宣传为 任何人 都能构建应用的方式，而且 任何人 都在使用它，无论技能水平如何。

• 人类责任： 开发者最终对代码质量负责。
• 现实情况： 许多开发者尚未意识到这一点，他们会交付看起来不错、能正常运行、甚至还能产生收入的应用——但这些应用存在 bug、不安全且危险。

真实案例

几周前，有人 “vibe‑coded” 了一个平台，在 4 天内 达到 150 万用户。三天后，整个生产数据库被访问并泄露（API 密钥、电子邮件、私信）。

我们在传统软件工程中已经很难阻止恶意行为者。这个 vibe‑to‑production 模式等于把钥匙留在门把手上。

结束语

我对新技术感到兴奋——这也是我从事这个行业的主要原因。我 不 感兴趣的是 不负责任地使用 新技术。我们的星球已经有足够多的问题了，别再毁掉支撑它运行的软件。

我只请求一点 谨慎和深思。

这要求太多了吗？