🏊‍♂️

如果可以，想办法用上ChatGPT、Google Genmini这些AI工具。不管是工作还是学习，与国内的几个AI大模型相比，差距真的巨大，这不是崇洋媚外，我相信国内大模型会有赶超的那一天，但现在看来，还没到那个时候，没有特别有依据的实验验证，只是从体感来说，至少提前半年甚至一年以上。 所以，使用相较于国内前沿的工具，无形之中就像是打了信息差，在各方面都会比别人领先一些，可能你和别人是同一个任务，但是，你的效率和产出都会比别人好上很多，而这仅仅是因为工具的不同而已，绝无其他。 AI的发展是极为迅速的，这个都是显而易见的，从2023年，开始有这种对话式的问答交流，获取想要的资讯，或者说让AI帮忙完成一些文本上的修改任务。 那时文言一心还没有上线，自己看到一些网站提供了这种功能，然后180元大洋买断了，结果时不时就网页打不开，好像一段时间，就在换域名。现在想起来，当时这种平台，自己好像也没有用来干嘛，无非就是翻译一篇短文、检查下写的文章的错别字等，后来，文言一心上线了，kimi，豆包等都纷纷出现，然后，注意力就转移了，这个买断的平台就没再去打开过了。 在使用AI的过程中，但印象中，较为深刻的，还是第一次知道和使用 Deepseek ，看到那个思考过程，极为惊艳。在 2025 年年初爆火，后来，只是后来人多了之后，总是因为使用人数太多，服务器资源不足，每次要用一下，经常是没有成功的，这是其一，第二个原因，就是人多了之后，数据被污染得太多了，回答的质量直线下降。然后，转到了豆包AI。 公司的微信文章，也只是根据公开的平台资料，让它按我提供的模板生成，这部分的工作，之前预估是两天的工作量，我半天就搞定了。在我看来，实在是没有什么必要深究一字一句，只要把表达的东西，传达到位，以及不要显得太过于AI味，就可以了，时间更应该花在高价值上的事情。 第一次使用超能模式，就知道这个又升级了，这个超能模式，可以抓取平台，只要你提供账号和密码，完全可以帮你做平台系统的测试，当时我第一次使用，都惊呆了。 后来，我就尝试让它登录公网的平台，让它对每个功能都测试，把暴露的问题，整理成表格给我，我在逐一检查，是否真实有效。 可以说，豆包是我用过的相对满意的一款AI工具了，至少2025年是这样的。可以说，为我的事情，提供了很大的帮助，但是，这一些，都在2026年爆火之后，戛然而止。 现在的问题是，使用超能模式，经常被告知当前功能使用爆火，要等几分钟才行。我是没有那么多耐心的，偶尔一两次才行，多了之后，可能要找替代品了。 恰逢和朋友交流最近基于AI开发的一些事情，说到很多公司都完全是面向AI开发了，大家都称之为“氛围编程”，就是不适应代码交流了，直接就是自然语言，把需求描述清楚，让AI完成项目的代码开发。 而选择的则是Google提供的IDE工具Google Antigravity，中文名是反重力，完全就是一键生成全部的代码，还自行调试，编译，运行，出现问题，还自行修复，就是到你手上的时候，已经成品了。 我想起之前使用 dev0 工具，尝试开发一键发文的工具，就是一篇文章，可以同时发布到不同的平台，比如微信公众号、掘金、博客园等，当时，用起来觉得很一般，以为这个方式还不够成熟，接着，也听说豆包提供的TACE插件，都以为，只是能局部支持，而不是整个项目都全部提供，就在这块上面，没有多去关注。 但是，真正使用起Google Antigravity之后，我心里只觉得，程序员被替代，真的不是痴人说梦。真的，这个时代真的要来了。 真的，完全可以使用自然语言完成整个项目的代码开发，我是不会Java后端开发的，但是，不影响我把之前在 dev0 工具开发的项目，我直接把项目在Google Antigravity打开，然后，让它根据需求，把这个项目重构，重构后的项目，真的是删除很多错误的代码，错误的功能，错误的编程语言选择，比如之前的前端代码里，有.vue文件的，又有.rect，显得不伦不类的，这次就完全重构，完全基于Vue3框架来开发。 接着，Java后端的代码也重构，搭配前端项目一起，把项目的架构都梳理清楚了。然后，项目也运行成功了。 我知道，真的太让我惊叹了。 如果我要创业，完全可以几个人组成小公司，完全基于这个Google Antigravity来开发项目，至于代码泄漏等问题，小公司完全就是利益至上，先赚到钱再说，管你什么核心技术泄漏，让Google去爬取了。 这一点大公司完全是不能做的，就是AI这些走的第三方的服务器，他们肯定是先读取到你项目的全部代码，才能给你提供建议，而这个过程，意味着你项目的全部源码，都被第三方公司获取了，这个就是代码泄漏风险，这也是这个氛围编程，无法那么快推进的原因。 如果你要私有化部署的话，成本是一方面，再者，你成本再高，能比大模型母公司高吗？花的钱越多，意味着功能越强大，如果投入钱搞私有化部署，效果和公网提供的一对比，心里落差极大，这种情况下，真的能坚持使用私有化部署的大模型吗？估计真的忍不了一点。 当前ini 帮我处理一个因为网络代理，导致在 Mac 电脑上使用VSCode 访问Ubuntu系统的工具，一直失败的问题。 然后，各种权限都给它了，就一直执行脚本处理，直到解决了为止。类似就是龙虾这个托管电脑。 可以说，AI工具，用得比较多的是豆包、deekseep、kmini、纳米AI，这些或多或少，都使用过，频次较高，其他的就不提及了。 只能说AI会发展越来越快，我始终相信，国内的AI工具迟早有一天会超过国外，但是，不是现在，现在来看，还是有很大的差距的，所以，我的看法是，如果可以，真的要赶紧用上Google Genmini和 ChatGPT，真的最少要比国内的AI工具，至少超半年以上。 很多编程的问题，让豆包和Deekseep排查的时候，明明提供的是同一份信息，但是得出的结果千差万别，Gmini 直接指出了问题出在哪里，一招就命中要害，但是豆包、deekseep提供的方案还是差的太多太多了。 我的三观真的刷新了，我第一次见到，给出的答案，是如此直接而有效。 正是在使用 Gmini 的这一段时间，我反复喂给它我的全部信息，让它给我诊断，以及提供发展路径，很多东西说的还是很有道理的。而且，少了很多献媚的措词，至少，让我发现了一个快十年来，一直被我忽视的一个特别主要的一个点，这个点就是所有问题的根源，而我一直以来，都没有注意到。 打一点这种信息差和时间差，你会比国内没有用这款AI工具的，远超半年甚至一年以上，效果更高，掌握的信息更为准确，何乐而不为。

1. 前言 基于 Oracle VM VirtualBox 虚拟机安装的 Ubuntu 系统，主要用于 C++ 嵌入式项目开发，最开始只是分配了 40G 硬盘内存。现在项目分支过多，加上项目一些插件、依赖库，导致现在系统硬盘内存不够了，经常提示只剩 1G 内存。想到一直这样下去也不是办法，只能先看下怎么清理大文件，然后，再怎么给 Ubuntu 系统扩容。 2. 使用 baobab 工具检索大文件 在 Ubuntu 系统终端，使用以下命令安装 Baobab 工具并打开： // 安装 sudo apt install baobab -y // 启动 baobab Baobab 会扫描分区，然后通过颜色，来区分哪些文件是占内存最大的，并且排在最前，这个时候，你就可以看下一些比如.cache、.vscode、.lingma等占空间很大的文件，就可以考虑清空了。 但这只是用来优化一下内存而已，真正起到作用，还是要 VirtualBox 虚拟机扩容。 3. 在 VirtualBox 虚拟机扩容至 80G 考虑到办公电脑一般硬盘都很大的，所以，多分配一些内存问题不大，关闭虚拟机之后，在 管理 - 工具 - 虚拟介质管理 - 属性，然后把下面的滑块，滑到 80G 的大小位置。 4. 在 Ubuntu 系统安装 gparted 图形化分区工具 在虚拟机上扩容到 80G 后，到 Ubuntu 系统里，你就会发现，还是会提示剩余空间不足的问题，原因是虽然扩容了，但是这个空间没有真正使用起来，就需要安装 gparted 分区工具来处理： ...

前面已经对 “做好，而不是做完” 的问题进行了分析并提供了解决方案。 现在，我们来分析和总结 “项目月末统计及时完成率，出现人人达标的情况” 这一问题，希望能梳理出有价值的见解。 那就从源头开始，最开始，我们计划通过 “任务及时达成率” 来反映项目成员的工作情况，期望从中能发现一些问题并起到督促的作用。 打算通过一定的约束力、紧迫感，促使大家及时完成手头上的工作，为此制定的规则是： 每个月未及时达标的任务不可超过 2 条，超过则需赞助部门经费 50 元。 项目总负责人也不例外，同样需要赞助 50 元。 之所以这样设计，是因为能让项目总负责人与项目成员站在同一战线上，有助于避免形成对立，降低工作开展的阻力。 然而，历经一年有余，除了最开始有一两个项目成员未达标并缴纳了赞助费用外，此后很长时间都是人人达标的状态。 这从正态分布上来说，就显得不切实际。因为，很少有人能保证所有任务都及时完成。而且，月月如此。 为什么会出现这种情况呢？后来我分析了一下，原因是，我们对任务变更没有进行有效管控，插入需求的频率过高。为什么插入需求的频率会过高呢？因为项目业务需要根据客户反馈及时调整，第一时间响应客户需求。例如： 突然有客户反馈紧急需求，希望快速响应； 当前线上存在之前疏忽的功能细节，需要及时完善和补充； 有客户询盘并表达合作意向，但对某个功能不太满意，需要及时给出优化方案以推进合作。 这些情况都会破坏之前制定好的项目计划和正在执行的任务。此时，无论是项目总负责人还是项目负责人，往往没有深究是否应该变更，而是默认允许变更。 只要产品、后端、前端、运维等任何一方出现需求问题或任务执行未及时达成，影响后续关联任务，就会出现任务变更的情况。 此时，很多人要么不具备分辨能力，要么贪图省事，不愿花心思去辨别是否真的应该允许变更，而是一概通过变更申请。 要解决这个问题，首先应从减少插入需求入手。但对于研发工作而言，如果完全不允许插入需求和任务变更，就显得过于僵硬和死板。市场在实时变化，响应时间的早晚可能导致截然不同的结果。因此，对于紧急、关键的需求，肯定要及时响应。 然而，如果总是允许插入需求，项目计划就容易失控。久而久之，项目成员会产生一种心态，反正最后都要变更计划，今天做完还是明天做完有什么区别呢？ 这种思想一旦萌生就很难消除，必须从根源上、从制度上解决。 项目负责人要引导项目成员主动思考是否可以通过其他方式解决延期风险，而不是通过变更影响后续任务。例如，可以提高事情优先级、提升工作效率、适当加班等。这样才能以目标为导向，锻炼应对不利情况的能力。 当然，如果插入的需求需要较长的开发周期，自然需要变更任务计划，并同步更新。这一观点我在之前的文章《项目需求变更时如何处理》中也提到过。坦白讲，就是要在 “插入需求” 和 “任务变更” 之间取得一个平衡点。 这实际上，还是回到了项目计划和里程碑的目的。**正如我在之前多篇文章中提到的，项目计划的目的是提供一个方向和时间节点，就像大海中的灯塔，引导大家朝着同一个方向前进。**如果张三往东走，李四往西走，王五往南走，工作就无法有效开展。 其次，项目负责人和项目成员在面对任务变更和各种突发事件时，应该充分发挥自己的智慧，制定有效的策略，就像行军打仗、摆兵布阵一样，明确先做什么、后做什么，如何争取资源，如何与其他成员和上级领导协调沟通，以确保在规定时间内达成目标。 如果某个项目成员反馈任务需要变更（例如前端因为后端接口问题导致任务受阻，申请延长任务时间），项目负责人需要了解事情的前因后果，而不是仅凭这个项目成员的一面之词。这就需要把相关项目成员（如后端）叫来一起沟通，了解问题所在及解决方案，可能出现的情况包括： 后端接口没有问题，只是两人对需求的理解有误，这种情况不需要变更； 后端接口有问题，但前端可以先开发界面，最后一两天再联调，这种情况不一定需要变更； 后端接口真的有问题，但前端对延长时间的理解有误，可能存在故意拉长时间的情况； 后端接口真的有问题，追溯起来是因为对需求的理解不一致，这种情况可以总结经验，下次在需求层面多做分解和沟通； 后端接口真的有问题，前端提出的延长时间合理，符合常规理解，可以同意变更。 可以看到，有些任务只是看起来需要变更，有些任务只是看起来需要延长时间，实际上不一定如此。 归根结底，就是项目负责人在执行上出现了问题，为什么没有做到位呢？换位思考，我在带一个项目，里面有关系好的，关系不好的，关系好的呢，肯定是适当通融，关系不好的呢，不想得罪对方，这是人之常情。 每个人的角色不一样，所掌握的话语权和资源也不尽相同，面对同样的一个人或者一件事，在你看来，很容易处理，但其他人就会觉得很难，不同的立场，面对的阻力就会发生变化。 所以，要为项目负责人的执行背书，从源头梳理，制定《项目管理规章制度》，特别是任务变更的规定，然后，组织项目负责人讨论会议，对这份《项目管理规章制度》里的每一条规定，都反复讨论和敲定，有什么问题，当场提出来，现场就解决对方的顾虑和疑惑，能够达成共识。 只有达成共识，项目负责人执行起来就会从被动变为主动。 然后，再把这个《项目管理规章制度》在部门里发布和告知。 之后，项目负责人在执行的时候，就照着规定行事，不用顾及对方的感受，直接按规矩办事，实事求是，如果对方反应很激烈，那也不用项目负责人去解决，只需要把这种对立情绪向上反馈，由项目总负责人、部门去解决，不用有心理负担。 说到底，就是要给项目负责人做这个事情的正当性，而不是把压力完全由项目负责人承担，从源头贯彻理念，而不是处于模棱两可的状态，规定个12345，有问题解决问题，直到大家都没有异议，那么执行起来，就不会有那么多阻力。 谁没做到位，直接提出来，到底是什么原因，是制度的不完善，还是人的问题，制度不完善，继续完善制度，人的问题，就解决人的问题。 最后，要提的一点是，任务变更固然是一个问题，但这都是基于 “目标如期达成存在很大风险” 这个主要矛盾延伸的，先明白了这一点，再去抓任务变更这个事情，才不会舍本逐末。

为什么写这篇文章 去年七八月份，我第一次知道 PBL 教学法。在了解相关概念后，发现与我一直以来倡导的学习技能的方法高度契合。 就好像我基于反复实践而积累形成的经验主义，最终遇到了与之对应的理论知识，从实践结合理论，形成了高度统一性。 但不久之后，我因为没有对此做系统性的总结，就忘记这个方法的名字了。 这次趁开始学习 C++ 嵌入式软件开发，我打算把所有思路都梳理清楚，把这套亲测有效的学习方法分享出来。 我最开始学 Java，后来做 Android 开发，2018 年转型学习前端 Vue，并参与前端项目开发。同时，开始参与产品原型设计和项目管理的工作。 2020 年因为技术的发展演变，以及项目成本方面的考虑，转为使用 Flutter 开发 APP。 算下来，应该是有不下五次转型的经历，有些太细碎的，就没提了。 这些转型经历，让我深刻认识到快速学习一项技能的重要性。 当然，这个问题在开始转型学习前端 Vue 就有想过了，只是当时没能找到规律。 转型前端开发工程师 我开始转型学习前端 Vue 框架，当时的学习思路是这样的，我在 W3school 这个网站里找到了 JavaScript、HTML、CSS 这三部分的教程，然后从 HTML 开始，把上面的例子利用周末的时间全都敲了一遍。 然后，通过自己整理成文章，发布到简书上面去。 因为 W3school 网站虽然有在线编译器，可以让你运行显示代码效果，但是你要是重温的话，就必须每次都点一下。 在我看来，真的太麻烦了，索性就把全部的知识点都敲了一遍，然后把效果截图到文章里。 然而，我并没有看完全部的教程内容，就直接参与到项目中，去开发具体的功能了。 哪里不会，就通过官方文档寻找答案，或者网上找其他人实现的类似案例。 看代码是怎么实现的，依葫芦画瓢，别管到底能不能看懂，先搬过来运行看看效果。 如果是成功实现了功能，那就再深入看下代码，这里提一下，深入看下代码的意思，不是让你把全部代码背后的底层原理，都理解得清清楚楚。 只需要知道当前用到的代码，是什么意思就行了，也不用把关联的相关知识都学了，没有多大的意义，等以后用到再学就行。 比如 JavaScript 里的 Math 对象，它的方法那么多，常用的就那几个，你就没必要现在花时间去记住，就当工具书，有个印象，后面真用到，再查一下就行。 只学当下用到的，其他的一概不学。 如果没能实现功能，就再找，实在找不到，就问其他同事，大概是怎么实现的，自己再回去捣鼓，千万不能有那种要是我去问同事或者领导，会不会被人看不起，自己技术很菜的心理。 因为你本来就不是做这个的，你只是新手，你都愿意学习了，已经很不错了，其他人没理由这样觉得，反而你要是一个人在座位上钻牛角尖，功能没有如期交付，反而给其他人留下了不好的印象。 我没有花几个月时间先学完所有理论知识，而是在项目中遇到什么问题，就去学习什么知识，学完马上用到项目中。 基于这个方法，我很快就能独立负责前端 Vue 项目开发的工作了。 转型 Flutter 开发工程师 2020 年，我开始学习 Flutter 开发，完全零基础，部门里就我带着另一个同事负责这个 APP 的开发工作，这一次和转向前端 Vue 开发工作不同，我连官网文档都没看过，就直接上手敲代码实现功能。 ...

《触不可及》这部电影，真的很不错。它讲的就是两个完全不是一个世界的人，碰到一起互相救赎的故事。 我真的看过好多好多次了。每次重温都觉得时间过得太快，怎么一下子就看完了。在我心里，这片子简直无可挑剔。剧情、笑点、音乐、演技、深度，反正我是基本上挑不出任何毛病。 电影一开场就特别有意思。它用的是穿插的手法，菲利普和德里斯在路上飙车，还被法国警察追。当时我就很好奇，他们为什么要飙车，难道是罪犯吗？ 接着又演了一出紧急送医的戏，博取警察同情才逃脱。这一下更让人觉得他们像非法分子，结果后面才开始正序讲故事，太会吊人胃口了。 而且，这电影的笑点实在是太多了，几乎全程都有能让你笑出来的点。 因为看太多次了，好多细节都是慢慢攒下来的。 比如德里斯第一次学护理菲利普的时候，上衣纽扣都没扣对，肉眼可见的手忙脚乱。吃饭的时候，他不知道盯着啥看，居然把东西送到菲利普眼睛上了。那时候还能看到他的衣领被毛衣盖住了，特别真实。 还有一次，德里斯跑过来告状，让菲利普管管他的女儿。结果，菲利普关注点完全跑偏，问他 “你正在画画？”。 菲利普给笔友回信写诗，德里斯插一嘴 “太无聊了” ，菲利普就瞥了他一眼，那眼神真的绝了。 在飞机上遇到颠簸，菲利普故意说飞机破了个大洞，德里斯惊呼完蛋了。结果，菲利普慢悠悠地说 “能认识你我很开心”，就好像临终遗言一样，笑死人了。 看弹幕的时候，好多人说德里斯像姆巴佩。我真的觉得一点都不像。他明明更像巴洛特利或者坎特，不过坎特太矮了，还是巴洛特利最像。就是那个留下 “思考人生” 名场面的球员，抢断形成单刀，然后突然犹豫减速，最后错失机会的那个，真的越看越像。 聊完角色外形，再说说演员。 我之前一直搞错了饰演菲利普的演员。总以为是达斯汀・霍夫曼，还老把他和《教父》《闻香识女人》里的阿尔・帕西诺联系在了一起。 这也难怪，两个人长得真的有点像，甚至个头都差不多，而且都是传奇演员。 第一次知道达斯汀・霍夫曼，可能就是通过《毕业生》这部电影，最后的名场面太经典了，主角逃婚出来一起私奔，但当时好像台词说完了，导演一直不喊卡，演员不知道怎么办，只能一脸茫然和局促。 而这种感觉正好让人看起来，是对未来生活的迷茫、不知所措，这也成了电影史上的名场面。 但后来我查资料的时候突然意识到，这部电影里饰演菲利普的并不是达斯汀・霍夫曼，而是弗朗索瓦・克鲁塞。 我当时还纳闷，《触不可及》质量不差啊，纵使达斯汀・霍夫曼佳作无数，也不至于提都不提一下这部电影吧？ 后来才发现，是我搞错人了，我才是那个小丑，但话说回来，这两个人长得也太像了吧。 而弗朗索瓦・克鲁塞的演技，我真的认为，已经到了炉火纯青、出神入化的地步。 好几个地方，他说台词时的微表情，感染力强到不行，真的让人动容。 比如他说起过世的妻子时，眼睛里一下子就有泪光了，脸部肌肉还因为太激动微微颤动，然后说出那句： “我真正的残疾不是在轮椅上，而是失去她 / 而是活在一个没有她的世界。” 还有电影最后，德里斯偷偷安排他和笔友见面。他转向窗外看向德里斯的时候，脸上又感激又开心又有点惭愧，各种情绪混在一起。 真的能感觉到他的内心波动，就好像他站在你面前一样真实。 除了剧情、笑点和演技，这电影的音乐也一点不逊色于电影本身，真的能担得起任何褒义之词。 说实话，配乐做得好真的能 1+1>2，给电影加太多分了。 德里斯无家可归，在外面游荡了一夜，黎明的时候朝着远处走。这时响起《Una Mattina》的 BGM，琴键一敲，那些音符就像汽水灌进耳朵里，无数个气泡在耳膜上跳动，太有感觉了。 还有德里斯第一次去菲利普家的时候，背景音乐是《Ave Maria》。歌声随着转场忽高忽低，像摄人心魄的音浪穿过脑海，印象特别深。不过后来音乐突然被关掉，真的有点让人措手不及。 有时候一个画面配一段音乐，真的是相得益彰、浑然天成。就像在心里种下一个锚点，把当时那种独特的情绪都记下来了。 以后只要听到这段旋律，就能想起当时的心境。 聊完这些表层的亮点，其实这电影最核心的是双向救赎。 我一直觉得生活就该野一点。德里斯就是这样，开得起玩笑，率性而为，开心最重要，他就像一个能量满满的太阳。 而菲利普本来是极限运动爱好者，失去妻子后又全身瘫痪，生活早就变得阴暗无光了。德里斯的出现，就是他生命里唯一的亮光，让他从泥潭里爬了出来。 菲利普最需要的根本不是同情，而是平等的对待。这是对人格的尊重，也只有这样，他才能真正接受自己的现状。 本来这就是两个人的双向奔赴，菲利普的变化肯定是最大的。 从德里斯那里，他没有得到那种让人反感的同情心，还被推着做了好多事。比如给笔友打电话、抽烟喝酒烫头发，慢慢找回了生命的乐趣。 德里斯也有转变，不过他的变化更多是自己想通了，而不是菲利普直接帮他的。比如受到艺术的熏陶，他变得有礼貌了。以前遇到邻居堵路可能直接上手了，后来从菲利普家出门，看到邻居堵在路中间，居然会礼貌敲窗和平交涉。 最后应聘速运公司的时候，还能和面试官聊起音乐、画作，这在以前根本想都不敢想。至于照顾母亲和弟弟妹妹的责任，其实德里斯本来就有，只是以前不知道怎么表达。 我觉得真正让他改变的，是看到了菲利普的处境。 家财万贯，什么都不缺，却全身瘫痪，成了残疾人。相比之下，他虽然没钱，但身体健康，已经幸福太多了。就是因为这个认知，他才开始学会珍惜当下的生活。 其实想想也是，就算是亿万富翁，也有得不到的东西。我们这些普通人，真的没必要抱怨太多，更该珍惜身边那些最贵重的人和事。 总结下来就是，一个有钱没健康，一个没钱但健康。两个看起来根本不可能有交集的人，在某个时刻遇到了一起，还从对方身上看到了生命的另一种可能。 这也正好解答了片名 “触不可及” 的意思。不是真的碰不到，而是以前觉得遥不可及的救赎和理解，最后在彼此的陪伴里，都实现了。 说完这些，我本来想说这电影已经完美到没话说了，但还是想吹毛求疵一下。 德里斯的转变里，来自菲利普的直接影响好像确实有点少。除了艺术熏陶，好像没什么更具体的互动能让这份 “双向救赎” 更对称。不过这也就是个极小的遗憾，完全不影响整体观感。 ...