weekly-002
记录一下这周看到的有趣的文章、作品
手搓GPU
https://jaso1024.com/mvidia/
手搓GPU的小游戏，复习大学课程
axios 供应链攻击的背后
从报道的内容来看，主要是通过钓鱼攻击，让 axios 的维护者下载安装木马软件后偷取密钥
具体来说，黑客组织建了一个 slack ，看起来很正经，领英的页面啥的也有。然后拉了 axios 的维护者进来开会，开会过程中说他可能少了个软件（可能是故意的画面不清晰？），让他下载安装。这个时候就中了木马
值得一提的是，用了 deepfake 技术，专门伪造了一个公司的管理人员和其他人员开会，搭配上精心维护的 slack ，看起来很正常，所以不会有怀疑
在AI帮助下，三个月时间创建了 sqlite 的辅助工具
https://lalitm.com/post/building-syntaqlite-ai/
作者（以下用我指代原作者）创建了sqlite 的辅助工具，包括 parser, formatter, validator, 和 language
相比于其他的工具，这个工具使用了 sqlite 自己的 tokenizer 和 Lemon生成的语法，因为 sqlite 本身的语法相当复杂，并且需要兼容多个版本的语法，需要有开关控制不同版本的 feature
对于 sqlite 的测试套件中的 39.6w 条语句，在解析接受度方面，一致表现的语句约为 99.7%
我经历了一次推倒重来的过程，第一次是完全交给AI进行编码，本人担当半个技术经理的角色，设计和实现由claude来完成。最后原作者发现他对代码实现完全不清楚，全是面条代码，函数散落各处，没有规律性，有的文件包括上千行的代码
把测试文件之外的代码丢掉后，我采取了完全不同的协作方式，prompt 类似于
：“我希望这样做的方式是，我希望掌控所有决策和方向，并告诉你该做什么。我不希望你制定计划，也不希望你独立行事。清楚了吗？”
这一次我主导了所有决定，审查了所有的改动，发现了问题就立刻修改，投入时间在 Linting, 验证，和重要的测试中用于自动检查AI输出的结果
我得到的收获和教训是
AI 提供的原型让人可以迈出第一步
对着实际的原型想问题，比在脑子里推敲更容易
AI 能够快速完成代码的编写
如果能够给出明确的指令，那么AI可以更快地完成，并且和项目中的其他部分保持风格一致，并给关键内容加上注释，这是项目中的“标准方言”(注：我觉得可能意味着项目中的最佳实践)但是标准方言对于项目中的小部分反而是有害的，需要反模式的部分最好由人自己编写
快速的编码也意味着快速的重构
对于 vibe coding 而言，持续的重构非常重要，不然很快项目就会超出你的掌控范围。当生成一大批代码后，作者都会回过头来自问：“这实现丑不丑？”。你的品味非常重要，因为你可以快速指导Ai按你的想法完成重构
AI 可以作为助教
- AI 可以将人一到两天的查询、阅读、理解时间，压缩到一次有针对性的对话中（为什么这样可行？）
- 对于项目中不熟悉的，遗忘的部分，也可以通过有针对性的对话快速掌握上下文
- “告诉我这个组件的情况” 用于了解组件表现
- “给我一个由浅入深的介绍” 用于加深了解
- “审计此软件包中的不安全使用” 用于查找问题
AI 可以让一个人创建更完整地项目
一个开源项目中，有一长串重要但不关键的功能
比如文档网站，对于作者项目而言就是 编辑器的扩展，多语言的绑定，playground。AI让这些工作实现的成本降低了很多
作为代价而言，
AI 有成瘾性
vide coding 和老虎机相似，你可能得到有用的东西，也可能啥用都没有。你会彻夜想着再做一次提示，即使不合适的任务也会想着“如果我这次用不同的说法”而继续用它，
在精力充沛时，可以给出精准的提示而获得高质量的产物。而疲惫时，模糊的提示会收获模糊的产物，这时候反复重复进行提示只是陷入了循环之中
AI 让人丢失对代码库心智模型的掌控
这里的心智模型指的不是程序的架构，不同组件怎么使用，而是什么东西放在哪？什么函数调用哪个函数这样日常的细节组合而成的工作系统。当失去了掌控后，会完全出现不知道问题出在了哪的问题
更深层次的问题是，如果你丢失了心智模型的掌控，那么你和AI的沟通效率就会降低。比如说，“让 FooClase 实现 X 功能” 比 “让做
Bar 功能的东西改成做 X 功能”更为清楚。这个时候 AI 得先了解 Bar 再了解 FooClass ，多加一步就多加了幻觉的概率工程师总是抱怨经理不懂代码实现，要求做一些不可能完成的事情。但是现在你成了那个经理
因此，我养成了在代码实现后立刻通读，并反问自己“如果是我会用什么不同的方式实现”的习惯来提升对代码库心智模型的掌控
AI 让人更慢做关键决策
因为重构很便宜，所以我总是说“稍后再处理这个问题”，但是由于代码库一直处于混沌的状态，所以推迟决策会让我思考的能力减弱
vibe coding 的时代，软件工程的基础规则依然适用：如果不设计清晰的架构，划分明确的边界，那么当需要清晰结构和明确边界时，你只能疲于处理bug
AI 缺少历史的上下文信息
代码现在这样设计是经历过演变的，我可以告诉你这个 API 用起来是什么感受，为什么这样设计而不是那样设计的原因
但是 AI 不行，所以对于相似的问题 AI 可能会重蹈覆辙，而你也会再付出一次成本。这个问题类似于失去了一位高级的工程师，他知道这个系统历史是怎么演进的，从而
能够指导团队中的其他成员避免重蹈覆辙理论上讲可以通过更新代码规范、设计文档来避免这些 case。在 AI 到来前，不这样做的原因是维护这些文档的成本非常高。AI到来后，AI可以帮助起草这些文档，但是由于需要人类的人工审核，所以这依然非常消耗时间
AI 的提供优点的部分也同样提供了缺点
当做一件我已经掌握的事情时，AI表现非常出色，因为我已经有了对应领域的上下文，我知道结果是什么样，我只需要验证Ai的输出和我的预期是一致的即可
当我做的事是我可以描述但不了解的时候，你需要更多的关注AI才能收获良好的输出。我可以从 AI 的输出中学到为什么这么设计，但是不能对AI提供的东西全盘接受，而是应该保持参与
当我做一件我不知道期望的效果是什么样的事情的时候，AI介于无用与有害之间。最明显的例子就是项目的结构。我花了数周时间跟着AI走进了死胡同，探索表面可行，实则弱不禁风的架构
但是仅有专业知识是不够的，即使我深入理解了一个问题，如果一个任务没有一个客观的答案，那么 AI 依然对于解决这个问题非常吃力。在实现上，测试可以通过，输出可以符合要求。但是设计没有一个标准答案：在 OOP 诞生几十年后依然有无尽的争论
具体来说，对于我这个项目的 public api 而言，我花了好几天的时间，修复那些有经验的工程师都会本能地避免，但是AI却搞得一团糟的事情。没有一个客观的测试证明这个接口确实好用，也不能证明这个接口设计确实解决了用户遇到的问题
总结
AI 具有难以想象的乘数效应。它能够给出特定技术问题的正确答案，但是它不知道其他人在用你的 API 的时候实际上是什么感受。如果你的设计依赖与 AI，那么你只会以前所未有的速度碰壁