我对AI的看法

在这个AI能瞬间生成一切的时代，“亲手制作”反而成了一种奢侈。

---

最近一年，我写代码的场景大概是“描述需求—AI生成—验证&修改”。在最近工作的项目中用这种方法跑demo后，遇到了一些问题：

• 我写的代码，自己都不太愿意看，因为“反正AI可以马上生成，费那个劲看做什么？功能需要更改就再生成一版好了。”
• 即使需要看，时间成本也很高，因为我得通过阅读代码来理解函数调用逻辑，读不同函数的注释再拼凑起整体功能，就像玩魂游拼凑剧情一样烧脑。
• 看完之后，可能想要的实现方式和AI写的不一样，需要大改动。

在这些原因背后，其实有一个本质问题：工程级别的代码架构不是“一拍脑袋”就能 vibe code 出来的东西。AI生成的内容，存在需求确认和理解上的鸿沟，也缺乏对未来拓展性的考量。因此，一旦需求变更或需要修改，就像是在一个地基都没打好的矮楼上叠高层，最后造出来的东西一定经不起推敲，未来的开发只会越来越麻烦。

我为了这个项目代码可靠，做了什么？

首先我去看了官方文档。从理论层面来说，我缺乏RAG流程的基本认知；而具体到“如何实现”，我也缺乏对llamaindex框架的了解。通过官方提供的简单demo，我在理论上了解到RAG大致可以分为两个部分：Data Ingestion 和 Retriever。再往下，数据如何预处理、如何分块、如何打标签（metadata）并向量化，以及有哪些不同的检索方法……这些可以在了解完基础框架后慢慢补充。

在跟着demo一步步操作时，因为代码量很少，我对其中每行代码都可以无痛地查阅文档来理解它的含义。我觉得“无痛”在这里很重要，因为它可以用一种低负担的方式启动，毕竟只需要应付少量的代码，不会给自己太大压力。当真的开始阅读后，哪怕遇到新的问题，也不会产生“我需要理解好多东西”的畏难感受了。

在理解了RAG的步骤，以及llamaindex提供了什么方法实现之后，根据我的输入数据的特点，我重新设计了一版RAG流程，包含了数据预处理、Data Ingestion和Retriever查询。我首先建立好了代码框架的层级，拆分出公共模块（比如data loader作为统一的读文件入口，以应对未来输入数据类型的增加），再按功能将不同的步骤放在独立的文件夹内。对于每个文件，我在里面写好了会用到的方法，包括方法名、输入输出和方法的描述。到这里，都是我用自己的脑子在操作，只让AI做一些简单的问答和代码解释。

# 举个例子
def get_weather(city:str -> weather:str):
    """查询城市的天气。（功能描述由我来写）"""

    # 这里就交给AI来写！
    pass

到了这一步，我才放心让AI帮我写代码。我让Claude帮我实现每个方法，再由我自己进行测试（顺便学习了一下怎么用vscode给python代码写测试）。我可以确保在每个方法写完时，我能理解AI写了什么、它的功能是否是我想要的，并且在出问题时，我能明确知道该改哪里、怎么改。

我学会了什么

这次经历再一次印证了“问题分解”的强大力量。

• AI写的内容不可靠，那就由人工拆分成更小的问题让它解决；
• 一次吃不透太多的内容（理论/代码），那就从更简单的问题入手来学习；
• 从基础的原型入手，确保拓展性，在未来逐步完善。

真是一条至理名言啊！

目前我对AI的印象和一年多前一样：模型还没进化到（或者说Harness还没进化到）能够轻易处理复杂架构，因此在该动脑子的时候还得动脑子。但如果能靠AI提高速度/效率/质量，也要放心大胆地去用。总之，多尝试，才能知道适不适合。

这也引出了下一个感悟：时刻保持自己的脑子清醒，毕竟我才是Harness的驾驶员啊！懂得越多，越知道何时应该用AI、何时不能用AI，更重要的是，怎么用AI。

最后：慢下来，会比较快。当你忘记progress的时候，progress也许会以最快的方式出现，甚至快到你意想不到。

“亲手制作”的奢侈

我和朋友也聊起过这件事情，但他只是觉得“我的代码能跑就行啊，哪里出了问题就让AI debug就好了”。但我觉得还是很不一样！

• 我坚定地认为，随着代码规模扩大，AI写的代码一定会遇到问题，或迟或早。而由我（与AI一起）来设计，一定程度上能规避这种问题，至少不会像纯vibe coding的东西那样不可靠；
• 最重要的是，自己写东西会！很！爽！

我其实是加班写的代码，但完全没有人催我，是我自己想写。那天是周六，我中午12点多到公司，一直写到晚上9点，完全没有感觉到时间流逝，只是沉浸在“我要如何设计代码框架，才能在面临未来新功能变更的时候，我可以改动最少的代码”之类的问题里。

晚上回去的时候，也感觉浑身轻松，解决了一件大事情，并且做得还蛮不错的！换成用AI写代码，哪怕实现了相同的结果、甚至更好，也不会给我这样的爽感。

可为什么这是一种奢侈呢？

• 首先，花时间找资料、学习、理解需求、设计，要花很多时间和脑细胞，完全没有“给我做XXX”然后拿到一份代码来得快；
• 我需要更多的前置知识（例如python语法、设计模式）来“知道我在做什么”。这些知识是我过去的教育积累起来的，甚至无法像第一点一样仅仅用时间来衡量成本差异。对一个没有接受过编码教育的人来说，甚至不会考虑到这些问题；
• 老板可能根本不在乎你用什么方式实现、代码的可维护性是否好，只希望看到成果。这也不难理解为什么会有那么多草台班子的“💩山”代码了。
• 加速！用AI就是要加速！在“3秒钟做出一个APP”、“我用AI赚了100万”刷屏时，还鼓吹要自己手写代码，也太慢、太不合群、太不够刺激了。

所以我也完全能理解朋友的观点了，但谁说享受“老式”编程的快感、在维护旧代码时可以不用翻“💩山”，不算一种奢侈呢？也许下个月他就会羡慕我咯～

---