承上上一篇博客挖的坑：

其实一直都很想写博客扯一些东西的，主题的话大致脑子里分两类，一类是如今的“AI”热之下的生成式绘图、“Vibe Coding”等工具的看法…

去年国庆的时候就打算写这么一篇博客了，倒是写了也有不少内容但是没有写完就搁置了。如今“AI”发展速度之快使那篇的内容在现在看来很多都不必要再提及了，于是想了想干脆结合最近的感受，重新写这么一篇。

Part 1.

WTF IS “AI”

我觉得看到这篇文字的读者，在当今环境下，肯定不会把“AI”理解成别的含义。说实话，我一开始（甚至事实上一直以来）很不喜欢用“AI”这个词指代当前的机器学习领域的人工智能相关的成果。毕竟倒退二十年，“大屁股电脑”时代的中国象棋人机中的机器也被称为 AI，游戏开发过程中，NPC 的行为逻辑也被称为 AI，如此等等。“AI”之意“人工智能”本身指的是很宽泛的内容，而当机器学习相关尤其是大模型领域成果发展迅猛后，这个词也成为了新的 marketing 热词被推上风口，如此之热以至于被几乎所有人都接受了，当然甚至连“AGI”也成了新的时尚单品热词…

于是本文提到的“AI”指的自然是目前的香饽饽，也就是机器学习、生成式人工智能、LLM什么的了。事实上由于大家都开始这么叫，我也听习惯了，也不那么反感这种叫法了…颇有“哈基米”的意味。

至于一开始为什么想写这篇，目的自然也并不是吐槽这种词语含义演化，而是…

Fanboy vs Anti-AI

“AI”吹与“AI”黑的互相鄙视现象持续到大概一年前还相当常见，虽然显然不能认为这个现象目前不存在了，但想必这个现象在现在也没有太大的讨论意义了。不过作为这篇文章最初的写作动机，这里还是拿出来讨论一下。

其实最早看到这个论调的时候我还是很少接触和使用“AI”的状态。ChatGPT 还很难注册，国内还连“文心一言”都没发布，Stable Diffusion 还是效果（在现在看来）很惨的时代，但就已经能明显的观察到两个明显的阵营：“AI”吹和“No AI”，在绘画相关领域尤其显著。自然，字面理解而言，真正的艺术创作和随便输入一些描述而生成得到的产物，在艺术创作本身角度而言，后者显然是毫无价值的。我能够理解和认同这个想法，但“AI”技术就因此一文不值吗？

一个蛮容易想到的“折中说”观点是，应当将“AI”视为工具，辅助人们更好的进行“创作”。而让我亲自接受这个观点则需要从不同的方面试图理解事情本身。那我觉得，首要问题是：应当因为“AI”“没有灵魂”而拒绝/刻意规避使用“AI”吗？

这里面有两个很有意思的讨论点，一个是“没有灵魂”，一个是“规避使用AI”。我们暂且不谈前面那个“最重要”的，只谈后者的话，让我换个角度：如果要实施“No AI”这个 policy 的话…

Since when it count as “AI”?

来两道很没意思的题：

• 找规律：给定一个数列，1、2、3、4、5、（），请问括号内的值可能是什么？
• 找规律：给定一个数列，2、4、8、（）、32、64，请问括号内的值可能是什么？

尽管你大概知道括号里都填 114514 也是对的，但大家自然还是会认可这里的通常预期答案是 6 和 16。这两个问题非常简单，也因此是训练儿童观察和分析能力的题目常客，那么，如果一个程序能帮你解决这个问题，这算 “AI” 吗？

…算。尽管一开始就提到过，二十年前的“象棋人机”也可以是AI，但这个问题确实是个神经网络的初步问题。而这里提到这点的原因则是：目前很多人会根据能解决问题的难易程度来判断自己所用的东西到底算不算所谓的“AI”，而忽略了大家很可能早就在用“AI”技术的东西的事实。例如在“AI热”之前，机器翻译也基于语言模型，输入法候选词的智能推荐和纠错也是语言模型的应用，OCR则也是早就被大家接受的东西了（背后是神经网络/深度学习）。如果要拒绝使用所有AI产品的话，划定“AI”的界限就变得尤为困难，甚至容易不小心把自己限制成原始人…

Soulless

那么我觉得接下来就应该回到另一个讨论点了——“没有灵魂”。这点其实很容易让我联想到电子乐器/数字音乐合成器被发明的时期。这些数字乐器被批评为“并非真正的乐器”，其产生的音色也被很多届时的音乐家称为没有灵魂的恶魔¹。尽管现如今已经几乎见不到这样的评价了，但此类印象的关联甚至被持续的延申到了电子乐中（DOOM 配乐可能是个比较知名的例子）。

诚然，切换回“AI生成产物”的场景下，手工打造的产物和根据提示符生成出的东西存在的精力投入/心血付出确实是不同的，但至少这多少可以说明，工具的可用性并不取决于其制造期间的“含人量”。当然，这也是我决定尝试“以善用工具作为目的使用AI”的原因之一了。

Part 2.

能让自己接受“尝试以善用工具作为目的使用AI”的想法后，我自然也更多的主动开始尝试各类平台提供的相关服务——尽管使用过程非常克制，会主动频繁的手动进行事实核查（当然实践证明事实核查是必要的，大模型太擅长一本正经的胡说八道了）——但也不得不说，总体给我的使用体验是正面的：在提高对产出内容可信度的质疑程度的前提下，它所提供的信息对解决我所需解决的问题而言还是在大多情况下都很有帮助。尽管也同样是因为大模型幻觉的问题，我一直以来没有使用相比常规更激进的用法，直到后来有机会尝试所谓的“Vibe Coding”。

Vibe

在实际描述我的实践与感想之前，我觉得还是要先简要的吐槽一下 Vibe 这个词。

我甚至到现在都主观的觉得 Vibe 这个词在这个语境下会伴随一种贬义，比如调侃川建国的“vibe presidenting”。“我不关心写出来的代码是什么，也不需要关心。瞎搞反正是搞出来了”的感觉。这话放到现在可能立马要有人拿自己用 claude-code 或是 codex 之类的 agent 搓出来的可用工具来反驳——但不要忘记，Vibe Coding 一词诞生之时，现在已经不能更常见的“Tool calling/MCP”、“上下文工程”、“驾驭(Harness)工程”、“A2A”之类提高 LLM 产出代码可用与稳定性的实践方式还不存在。

当然我完全不反对用 LLM 写代码，后面也会详细讨论这件事情。显然 Vibe Coding 这个词在现今的实际讨论语境中反倒大多都不是以贬义形式存在的，只是单纯这个词（在这个语境下）的诞生多多少少还是给我了一种荒诞感。

Adopting LLM?

那么终于可以回到本文标题了。无论为了何种原因，我还是以一些不同的方式，在我的几个项目中不同程度的尝试了 LLM 辅助编程。小到单纯通过线上大模型对话来调研某个不熟悉的领域，大到尝试“Vibe”一整个项目。这篇文章不是“教你如何实践”性质的文章，所以也只是以感悟为主瞎扯些内容。为了提高和现如今的所谓 agentic 方向内容的相关性，这里也不再讨论特别保守的尝试内容了——也就是说，下面涉及到的项目都能在现今语境下符合“Vibe Coding”项目——虽然我还是不太能接受 Vibe 这个用词。

YOLO-style Vibing

不管我能不能接受，要想做出评价总要实际试试，于是我实际有两个项目是尝试真的放下脑子写的（虽然没有完全放下），分别是 一个 Steam 内置录屏快速导出工具 和 一个 Distrobox 应用快速导出工具 。从描述大概就可以知道这两个项目的实现难度其实都不大，现状而言这两个项目目前的状态也确实都是可用，实践大致步骤也都是给出初步调研结果（有一个甚至是让 LLM 来调研的，不过我有核查调研结果的准确性）后完全交给 LLM 施工的，不过当实际去看代码的时候就已经发现不少技术债了——并非不能解决，只是假设我们持续不关注现有代码的情况下完全以描述（用户）需求的形式继续添加新的功能的话，就像玩 Jenga 一样，迟早有塌掉的一天——彻底解决问题不亚于大规模甚至完整重写项目了。当然好在这两个项目目前已经达到了我原始的“能用”的目的，考虑到也没多少关注度，也就没有必要在继续维护下去了。

Copilot

尽管巨硬改名部给自己的 AI 玩意儿改名不知道改过多少次了，但我觉得 Copilot 是个很好的名字——严肃工程项目的维护一定需要人类介入，尽管它的本意大概是让 AI 当“副驾”，但哪怕是让 AI 当主驾，也应当有人坐在“副驾”位置上履行副驾职责。

我也有两个项目大概是近似这个性质的项目，一个是 适用于绿色便携式软件的文件格式关联管理工具，一个是 Notepad++ 跨平台替代项目 。这两个项目都是从项目初期开始，每一步都一定有人工介入的项目。项目调研和可行性分析、初始架构的设计、开发计划和实际的每一步实施都由人来确保质量，目前看来效果也确实还不错，虽说其间不乏 LLM 怎么做都做不到想要的效果，最后还是我手动下场几分钟解决实际问题的情况发生。

所以事实上“AI”编程在实操上能带来积极的效果这点，我觉得是没有太大问题的了，不过还是觉得有一些点需要进一步讨论。

Part 3.

反观一开始写这篇文章的初衷是“Fanboy”和“Anti AI”的对阵，但实际情况即便接纳 AI 的 用户群体也有不同的接纳程度。对于目前的“大方向”而言，也已经有不少人乐观的认为应该尽可能朝不需要人主动干预就能完成项目的方向发展了，并坚信现在用法所产生的技术债可以在很近的未来由 AI 自行解决。我无法预测未来的发展趋势，也不排斥此类观点，不过仍然想对目前的很多现象评论一二。

AI 编程解决了什么问题？

于是来再提一下上面提到的 Notepad++ 跨平台替代项目《菠萝记事本》 。这个项目是我大概四年前调研过的一个项目，发现 Scintilla 的 API 过于繁杂，要自己手搓这类软件就要消耗相当多的精力来编写繁杂无味的业务逻辑，于是决定放弃搁置。事实上，我觉得此类项目就是很适合使用“AI”的例子之一。它将开发者从乏味的重复劳动中解放出来，使得开发者可以用更多的精力掌控架构、确保质量。要说“没有所谓AI就没有《菠萝记事本》”的话也一点没错了。

当然，不仅仅是此类，在实际体验来看，代码评审和常见问题的辅助方面，“AI”解决方案也能提供相当的优势。代码评审可能帮助识别自己可能漏看或者漏想的点，而有了网络/浏览器等集成的“AI”工具在快速收集自己不熟悉的信息方面也能胜任。诚然，代码评审可能会是在口胡，信息汇总可能出现幻觉，但现有的完成度度量通常已经是很理想的程度了。事实核查是无论如何都无法省略的步骤，但大部分情况下也确实节省了大把的时间并提高了效率，不是么？

但是…

一票难求的 Coding Plan

…确实开始变得 working 的“AI”自然使得企业们对这块市场的态度变得狂热了起来——各大公司开始考核AI率致使每个人都不得不依赖“AI”，早就水涨船高的闪存和显卡价格变成了各类Coding Plan涨价且需要耍猴式营销的罪魁祸首。

说实话我到本文发布之时都没有购买过任何此类订阅²，因为上班用的话就是很奇怪的自费上班感，个人项目用的话为了几乎看不到盈利的项目花钱也很奇怪。《菠萝记事本》的开源打赏计划也就是因为这个原因而来——尝试至少为我的开放项目寻求资金方面的平衡。

当然，目前的情况而言，《菠萝记事本》也没有收到很多打赏，所以这个尝试本身也并不算成功。不过即便假设收到了很多打赏的话，按目前的各大plan的情况而言，想要抢购买到手也是个难事了。

全民养虾

各种 Plan 支持的场景一般有两个，一个显然是编码，另一个则是“养虾”。Clawd 在国外甚至国内的爆火总让我觉得有点莫名其妙。我觉得给 Agent 更多能力在恰当的场合能起到很好的作用，但 OpenClaw 的爆火反而让它比较存粹的本质变得有点奇怪。一个原本是给 coding agent 提供系统集成并接入 IM 软件的场景，反倒在各类山寨项目（ZeroClaw、Moltis、NanoClaw、LoongClaw 等等等等）演化成了近似聊天机器人的存在，反倒丢弃了本应该有的 coding agent 特性并减少了系统集成能力，不少用户部署的目的反而变成了饲养赛博猫娘，反倒成了一种变回“酒馆”的退化。

赛博猫娘的案例相当常见，抛开捏人设之类“酒馆”不可缺少的事情不谈，其中我最不理解的就是有人会喜欢就一些事情询问自己的赛博猫娘“你怎么看”。我们当真需要一个来自“AI”的对事件的“主观判断”吗？是在寻求不一样的观点还是在强化自身观点，或是真的将其作为了感情寄托吗？无论那种有一种说不出来的荒诞感。

“菠萝王朝”/三省六部制

另一个奇怪工程实践是所谓的“三省六部制”，分出若干 agent 扮演司礼监、内阁、督察院、兵户史礼工邢部的角色。也存在不少争议。有人确实使用近似的实践进行了一些略成规模项目的开发，但也少不了质疑的声音 。

我认为 subagent 是一个很实用的策略，可以应对上下文限制导致的信息丢失和模型能力弱化问题，但使用 subagent 的方式也应当以应对这个问题为基准，而非漫无目的的进行角色扮演。例如可以对项目进行 WBS 工作包性质的任务分解并以此基准进行开发和验收、对于零散信息的一次性 subagent 调研并返回结果给主 agent 做后续处理等。事实上目前的 agentic 工具实践都是为了解决这些问题才演进而来，例如现在几乎所有的 AI 工具都会以 TODO 工具跨会话跟进工作进展³，使用 AGENTS.md 记录与沉淀项目使用方式，自主控制何时交互式提问，何时 spawn subagent ，何时使用哪些额外的工具等。这些做法也就演化出了自己的名词，即上下文工程和驾驭工程——而目前没有任何实际的 AI 工具在采取“三省六部制”，想必也能从侧面说明其中的问题了⁴。

Part 4.

对于“AI”目前的其他问题，这篇文章是没有进行讨论的，例如各大厂开始追求超高的AI率、大型项目工作流完全AI化是否可行、伦理道德、是否造成了更多无意义的电力消耗导致全球变暖之类。至于为什么，则是因为作为AI洪水下的一根稻草，不管我认可还是否定，这都成了我不得不接触的技术。在它本身都还没完全搞清楚的了解之前，已经根本没有什么心思可以花在这些方面了…

于是，在 AI 的浪潮中，我会怎么办？

…我觉得我没有太多选择。我不是衣食无忧的欧洲人，所以不管是喜欢还是讨厌，我都会持续关注这方面技术的发展、做出尝试并评估。我觉得我对“AI”的接受程度算是 Mixed 的程度，我觉得它确实有用，但我也觉得目前的 AI 狂潮已经形成了一种吹过头的 hype。但无论如何我的想法都不重要，我能做的，大概就是，至少对我自己而言，做到符合自己认知的“合理使用”吧。

惯例：2026/4/21 0:08

• LLM
• 开源
• AI