周末项目，就是继续优化OpenReserch的GUI部分。本来准备改造mdx编辑器的预览效果的，但是这一块确实要改动的部分挺多的。我以前经常套用astro的框架，所以确实有点把不依赖于现有框架的细节问题想的少了。这挺难为Claude Code的，所以折腾了几个来回后，大概可以有下图这么个意思，当当然后面的组件架构，我需要停下来想一下的。
一个小插曲是，Claude Code喜欢加入一些页面测试环节，这一次，在我没注意的时候，把一篇内容的数据替换成测试数据了。还好，备份的信息都在，我就直接手动修改数据库数据恢复了。
然后，在恢复过程中，发现了后台数据保存上的一个冗余，然后没经过太多大脑思考，下意识的就让Claude Code改架构了。改到一半，我回过味来了，一方面是恰恰是这种冗余让我刚刚很轻松的手动恢复了数据，另一方面，我要的是运行正常的能出结果的工具就可以了，这样的冗余真的有必要改吗？
又一个因为自己“完美主义幻想”影响了执行的典型案例。
可是，修改的过程中，数据库结构已经改了，我也没有回头路了，因为回退代码也不能完全回到以前了。
于是，改到一半，熟悉的提示来了。
8月20号以前Claude Code还会在快触碰limit时提醒一下，现在直接突然出现，立刻生效。还好因为中午吃饭和午睡的时间打断了进度，关小黑屋的时间也就不到一个小时，正好写篇文章“批判”它。
在这个“项目”之前，我用Cursor或者Claude生成代码一般是两种方式：先做一个最小化的MVP，然后逐步改造；或者先让GPT、Gemini或者Claude出设计方案，然后让Cursor或者Claude Code负责执行。
然而，很有意思的是，目前还在用的工具中，全部都是第一种方式实现的。
但是OpenResearch这个项目有一点点不一样：
首先它有一个纯前端的部分，我画了一个草图让Gemini的Deep Think（那个号称奥赛金牌一天只能用五次的模型）将草图变成设计文档，然后交给Claude Code按照设计分阶段实现，也就是在github代码仓下面的ui目录；
第二步，我让Gemini Cli对纯前端的MVP部分生成了一份架构描述文档（这方面，Gemini Cli就是比Claude Code好一点）；
第三步，我把这个架构描述文档再给到Deep Think，再把我完整的前后台想法告诉了它，再去生成设计文档；
第四步，把设计文档交给Claude Code实现，这个过程我进行了好几次反复迭代，不断根据Claude Code会遇到的问题去修改架构，回到Deep Think出文档，再实现，再修改，大的推倒重来应该不下五次；
我一度以为上面的方式会失败，然后坐等下一代模型更新，但是，归结于运气，居然基本正常，而且CloudFlare后台兼容性不错，维护成本也很低，对于生成内容的“二次开发”非常有利。当然还可以有一个完整的后台选择是Supabase，但维护量还是显著的高了。
以上的过程引到了第一个问题：Cursor，Claude Code这些工具的出现，是不是降低了程序开发的门槛？我的答案跟不少十年以上的程序员是一样的，持否定态度，当然，肯定不是出于保守（显然，我一点都不保守）。
过去一年多时间里，我展示了太多一键生成可视化，网站，小工具的例子，这些毫无疑问都是大幅降低程序开发门槛的。但是一旦涉及到稍微复杂点的交互，门槛就大幅提高了，一个AI生成的项目的成功与否最终的决定因素还是在人：人的判断力和过程监督能力。
是的，我认为Deep Think是现在最“聪明”的模型，它生成的设计方案，Claude Code就是可以实现，不至于“崩掉”，但是在交付设计方案给到Claude Code之前，给出“好”这个判断的是“我”这个人，凭借的是那些不会在训练数据里出现的失败经验和教训；
而在执行环节里，我其实经常让Claude Code自动化批量作业，但其实这个时间我没闲着，几乎全过程“监控”着，一旦发现不对了（访问过多的项目文件，采用不必要的执行方式），我都会打断，调整它，这个动作跟Karpathy前段时间在X上说的做法是差不多的，这同样来自于人出于经验教训这些训练不到的数据的“自信”。
所以，我一直认为AI会彻底颠覆“软件工程”（那个我已经讨厌了超过二十年的东西），但是绝不会取代程序员。AI只是新时代的程序语言，以自然语言的方式表达。
第二个问题，工作方式。在另一个副本任务里，Gemini Cli刷掉了15亿的input token，终于完成了我的一个新想法的第一步（重新评估后，我觉得token耗费量可以降到小几个亿。但是我在得到一个相对完整的结果之前，是不会确定优化方向的。没有GPT-4，DeepSeek根本不可能只用五百多万美金的GPU时间成本训练出来V3）。这期间，没有让Gemini Cli生成一行代码，它交付给我的是结构化的信息处理结果。
这是程序吗？当然，所有跟数字世界打交道的，都是程序。
然而，在这个过程中，它也经常发生错误，经常跑偏方向，我需要停下来，帮它校准好方向后再继续前进，甚至在这个过程中还要不断的手动修复“灾难现场”。
正如我们自己写的每一行代码，每一段程序，每一个项目一样，从来就是bug到处飞的。可是我们依然慢慢习惯了尽可能用程序来解决自己工作和兴趣爱好中遇到的各种问题，它让我们变好了。
所以，AI Coding还是以前的代码本身吗？当然不是，它是我们解决一切数字世界问题的工作台。它经常给你“aha”时刻，经常制造“车祸现场”，但与它一起工作，就是我们的终极答案，当然，也是我们最大的挑战。
那么，AI时代是不是不能选计算机专业了？
也许答案恰恰相反，我甚至冒出了一个想法，也许以后PhD（Doctor of Philosophy），就该被改名成CSD（Doctor of Computer Science）。
因为，计算机科学教给我们的不是如何写代码，恰恰相反，程序语言是这个学科里最不重要的部分，真正重要的是，系统是如何运行的，算法如何被用来解决实际世界中的问题的，人，是如何从“不设限”的尝试里不断制造灾难并修复灾难的。
正好，Claude Code解禁了，继续我的周末项目，OpenResearch，最早的时候我想做Research，如今，我觉得只有“Open”是重要的，不仅仅是开放代码，因为代码就是“垃圾”，一文不值。真正需要Open的，永远是自己。