JustYY | 小赖子

再一次被英国的牙齿治疗所震惊: 自费让娃第一次洗牙

2026-09-17 18:29:28

都说英国看牙贵，在英格兰生活久了本以为已经习惯，这次带孩子第一次私人洗牙，55英镑一次、预约还要先付30英镑订金，还是让我再次感叹英国牙科的价格。本文结合我们一家在英国看牙的经历，聊聊NHS牙科并非所有项目都免费、儿童NHS正畸等待两年多、刷牙和口腔卫生对戴牙套的影响，以及公司牙科保险到底值不值得把孩子也加进去。

都说英国的牙医贵，在这里生活久了，我以为自己已经习惯了。结果，这次带大娃第一次洗牙，还是忍不住又感慨了一番：小孩子洗一次牙，55英镑，预约的时候就得先交30英镑订金。

NHS牙科并不等于全民免费

先说清楚，英国各地的牙科政策并不完全一样，这里说的是我们生活的英格兰。NHS牙科并不等于全民免费，成年人即使接受的是有临床需要的治疗，通常也要付费，符合豁免条件的除外。未满18岁，或者未满19岁且仍接受全日制教育的孩子，则可以免费接受NHS牙科检查和治疗；自己选择的私人项目不在这个免费范围内。NHS收费说明、免费治疗资格对此有具体解释。

公司牙科保险能报销多少

我目前通过公司买了牙科保险，只加了我和媳妇两个人，每个月大概十几英镑。按照我们现在的保险方案和报销经历，平时的NHS检查、补牙等费用，上传收据后基本可以全额报销。不过，洗牙就不能全部报了：我自己一次20分钟的洗牙收费77英镑，保险报销50英镑，剩下27英镑还是得自己掏。

等了两年多的牙套，还得先过刷牙这一关

这次带两个娃去做每半年一次的例行检查，牙医提醒他们要认真刷牙。检查时已经发现了牙垢，牙龈也有些发炎，说明平时刷牙还没有刷到位。 [caption id="attachment_72942" align="alignnone" width="2048"] 每6个月得牙齿检查，虽然有时候牙齿拿着装备在牙齿敲敲敲也就一两分钟，但是检查 费用也得20几英镑了。[/caption] 偏偏大娃这个月底就有一个等了两年多的NHS正畸预约。好不容易排到，牙医却提醒：如果口腔卫生没有改善，转诊过去的正畸牙医可能不会开始给他戴牙套。 这一下，刷牙就直接关系到月底的预约能不能顺利推进了。 NHS可以为符合条件的孩子提供免费正畸治疗，但也不是所有孩子想戴牙套都能免费做，是否符合条件需要由正畸医生评估。等待时间也因地区和服务安排而异。我们家这一等就是两年多，确实等得够久，但不能把这个时间当成所有地方的统一标准。NHS正畸说明也提到，转诊后可能需要面对较长的等待名单。

我和媳妇当年也经历过

听到牙医对孩子的提醒，我还真不好意思只批评娃，因为我和媳妇以前也经历过类似的事情。 当年住在Sheffield的时候，我们想做牙齿矫正，也不是一提出就能马上开始。那时候同样是刷牙没有做好，口腔卫生还没达到要求。后来搬到剑桥，又经历了一两年，牙医才觉得可以开始。 所以，这件事我们自己算是有过教训。排到了预约，牙齿和牙龈的状态也得过关，不能以为等待结束了，后面的事情就都能按计划进行。 牙套：在英国整牙也不是件容易的事 – 说说分期付款在英国整牙的计划

孩子第一次洗牙，55英镑

检查的时候，我顺便问牙医，孩子这种情况是不是可以洗一次牙。牙医表示可以，也推荐做。于是我就给大娃约了第一次洗牙。小娃大概是担心会疼，不太愿意，这次就暂时没有约。 牙医知道娃是第一次洗牙，所以特别耐心，先给他介绍了一下整个洗牙的过程，以及过程中会用到的工具。还特意告诉他哪些声音和感觉是正常的，让他不用紧张，如果中途觉得不舒服，随时都可以举手示意停下来。这样一番解释之后，娃明显放松了不少，第一次洗牙也算顺顺利利地完成了。我事后和娃说，感谢配合，我事先就很担心娃觉得疼不配合，然后55英镑就这么浪费了。 洗牙结束后，牙医还特意叮嘱娃以后一定要认真刷牙，并让他拿着镜子，现场指出哪些地方的牙龈已经有些发炎。牙医解释说，这些问题主要就是因为平时刷牙不到位，牙菌斑长期堆积造成的。 看了一下诊所的收费，小孩子确实比大人便宜一些，但也只是相对便宜。儿童一次55英镑，预约时先付30英镑订金；成人20分钟77英镑，30分钟则已经要100英镑了。 我记得前两年，30分钟的洗牙也就七十多英镑。如今同样按30分钟算，价格已经到了三位数。看着前后价格的变化，实在很有感触：工资涨起来慢吞吞，日常开销涨起来倒是毫不客气。 [caption id="attachment_72943" align="alignnone" width="1152"] 娃的第一次洗牙，他说刚开始有点疼。我说，疼说明发炎了。[/caption]

洗牙不一定都要自费

这里也补充一句，洗牙不能一概归为“美容项目，所以NHS不管”。如果牙科专业人员判断洁治有临床需要，是可以通过NHS提供的；没有临床需要、自己选择的私人洁牙，则需要自费。我们这次预约的是私人洁牙，费用是诊所的报价，并不代表所有儿童洗牙都必须自费。NHS关于洁治的说明写得比较明确。

一年110英镑，要不要给孩子加保险

这次给娃洗牙的口腔卫生师，也就是dental hygienist，建议他每六个月来洗一次。按目前一次55英镑的价格算，一年就是110英镑。当然，这是她给孩子的建议，具体间隔还是要根据个人的口腔情况来定。 这么一算，我打算年底再看一下公司的牙科保险，研究一下把孩子加进去要多交多少钱。之前没有加，主要是因为他们的NHS检查、补牙等项目本来就免费；现在多了私人洗牙这笔开销，就值得重新算一算。 不过，这笔账也不能只看“新增保费有没有低于110英镑”。还得看儿童洗牙到底能报多少、每年能报几次，以及有没有其他限制。真正该比较的，是新增的全年保费和预计实际能报销的金额。如果算下来划算，再考虑把娃加进去。 至于眼下，比研究保险更紧要的，还是让孩子把每天的牙刷认真刷好。月底的正畸预约已经等了两年多，可别好不容易排到了，又因为口腔卫生不过关，把开始治疗的时间继续往后推。 以后再催娃刷牙，我脑子里大概会同时浮现两个数字：洗一次牙55英镑，等一次正畸预约两年多。钱花出去心疼，时间等过去，也一样心疼。

朋友圈的相关评论

牙医真是暴利 20分钟就要55英镑 （成人是78）两三年就涨了50%。 感觉得把娃也加到我的牙医保险上[微笑] 你儿子带牙箍了吗？那个更贵[流泪]儿子矫正牙齿，老爸真心要出血[流泪] 我家是个老人多的小区，牙医诊所根本没有NH S位子，只能看自费，regular check 就是£55、就是看一眼😂😂，不过好处是家长注册自费，未成年的小孩免费看（治疗不算） 我做个牙周预防45分钟800多欧 微软英国不管家属吗？爱尔兰是管的，配偶和未成年子女 Reply 咪笨猫：是的，NHS 检查 不到1分钟也得20几英镑。真是抢钱。 Reply 三木：花钱可以加的，就是从公司那个benefits funds里扣 Reply JOE刘石磊：哦？我还以为国内很便宜。。听说很多老外到国内看病啥的。 Reply 务农的费雷尔：目前感觉他们不是这个料。。[Lol] Reply justyy币圈老OG：这种公立保险不报，我有买了附加险 牙齿治疗这么贵，牙医应该挣老钱了。 [caption id="attachment_72948" align="alignnone" width="603"] 朋友圈吐槽整牙费用太贵了。[/caption] [show_posts keyword="牙齿"] [show_file file="/var/www/wp-post-common/justyy.com/teeth.php"]

从拖拽控件到指挥 AI: 代码写得更快了, 程序员成长得更快了吗?

2026-09-16 23:51:54

从 VB、Delphi 的拖拽式开发，到同时指挥多个 AI Agent，软件开发的方式正在改变。本文回顾 RAD 的便捷，探讨 AI 编程带来的效率提升，以及代码理解、人工审核和经验积累面临的新挑战：代码写得更快了，程序员是否也成长得更快？

把这两张图放在一起，多少有点感慨。一张是熟悉的 Visual Basic 窗体设计器，另一张是对着 AI Agent 输入一句“Fix this shit.”。从拖拽按钮、双击编写事件，到描述需求、等待 AI 修改代码，开发软件的方式，已经变了很多。 [caption id="attachment_72933" align="alignnone" width="640"] Visual Basic 窗体设计器[/caption] 那时候，把按钮拖进窗口，再双击写几行代码，一个小程序就有了模样。

怀念 VB 和 Delphi 的年代

以前开发桌面应用时，RAD 是个很让人兴奋的概念。Rapid Application Development，快速应用开发。提到它，我首先想到的就是 VB 和 Delphi：拖一个按钮，放一个文本框，调整属性，再补上事件处理逻辑，界面和功能就在同一个 IDE 里串起来了。 所见即所得，反馈直接。看着一个空白窗口慢慢变成能用的软件，那种成就感非常具体。当时真觉得这技术牛，学会了，似乎可以用上一辈子。 也许你听过这样一句程序员之间的调侃：“聪明的程序员用 Delphi，真正的程序员用 C++。”这句话一半是在夸工具带来的效率，一半是程序员之间对技术功底的较劲。玩笑归玩笑，衡量一个程序员的水平，终究要看他能否把问题想清楚、把软件做可靠。到了 AI 时代，这个段子或许还可以续上一句：“聪明的程序员让 AI 帮忙写代码，成熟的程序员知道哪些事情必须自己判断。”工具可以替我们完成越来越多的工作，但对结果的理解和责任，仍然需要自己承担。

VB6 的便捷与技术迁移的代价

尤其是 VB6，在语言的易用性、GUI 设计和开发环境之间，找到了一个很舒服的平衡。做一个小工具，不必先搭起庞大的工程体系，就能很快进入真正解决问题的阶段。 后来微软把开发重心转向 .NET，VB6 的 IDE 也在 2008 年结束了支持。不过，开发工具停止支持和旧程序不能运行是两回事，VB6 的核心运行库至今仍在受支持的 Windows 版本中获得有限支持。微软的 VB6 支持说明 我能理解老开发者对这次转向的失落。.NET 有自己的技术价值，但对已经用 VB6 把事情做得很好的人来说，迁移意味着重新学习、改造代码、适应另一套生态。平台往前走了，个人过去投入的时间，却未必能原封不动地带过去。我怀念的，正是那种工具顺手、复杂度适中、打开就能干活的感觉。

一门技术，真能用一辈子吗？

如今再看，所谓“一门技术吃一辈子”，大概只能算当年的美好愿望。尤其是 JavaScript 和 Node.js 周围的工具生态，框架、构建工具、依赖管理，各种封装一层套一层。隔一阵子就冒出几个陌生名字，很容易让人产生一种错觉：我还没把上一套弄明白，下一套就来接班了。当然，有新框架出现，不等于手上的旧框架立即失效；追不追新，本来就应该由项目需要决定。

AI 会让 RAD 过时吗？

这两年 AI 兴起以后，我又有一种感觉：以前那么重要的“拖拖拽拽”，似乎没有那么重要了。 想想也合理。可视化设计器主要是给人用的，它把写界面的工作变成了直观的操作。AI 则可以直接生成界面代码、布局和事件逻辑，不必先拿起鼠标，把按钮从工具箱拖到窗体上。原本需要工程师亲手完成的步骤，现在可以交给模型。 不过，把这件事说成“AI 淘汰了 RAD”，就有点过头了。严格来说，RAD 是强调快速原型、迭代和用户反馈的开发方法，拖拽控件只是其中一种常见的工具体验。IBM 对 RAD 的介绍 而且，Delphi 所在的 RAD Studio 仍然在发展，可视化设计工具也在加入 AI 能力。RAD Studio 官方介绍 从这个角度看，AI 反而可以把快速做原型、拿到反馈、继续修改的过程再加快一些。 AI 不需要靠拖拽来生成界面，人仍然需要看见结果、试用产品、判断交互是否合理。一个表单的代码能自动生成，不代表表单该让用户填什么、哪里容易误操作，也已经自动想清楚了。

从拖拽控件到指挥多个 Agent

[caption id="attachment_72934" align="alignnone" width="2048"] GPT-6 Astra 与 AI Agent 开发界面[/caption] 从亲手拖一个按钮，到给 Agent 布置一个任务，工程师与工具的相处方式变了。 现在的日常，已经变成了开着 GPT-6 Astra，做起 prompt engineering：交代需求，补充背景，说明约束，然后等上十来二十分钟，看看 Agent 交回来的结果。 等待期间，还可以同时开几个线程，指导多个 Agent：一个实现功能，一个排查问题，另一个审查改动。自己则在不同任务之间切换，回答问题、纠正方向、检查结果。以前主要盯着自己正在写的函数，现在还得盯着几个任务之间的关系，以及它们有没有把同一个需求理解成不同的意思。 图里那句“Fix this shit.”很有喜感，也很符合程序员面对问题时的心情。但真要把事情做好，后面往往还得补一堆背景：哪里错了，预期是什么，哪些行为必须保留，怎样才算修好了。模型越能干，把这些条件讲清楚就越重要，否则它可能很高效地把事情做偏。

AI 写代码之后，谁来理解和审核？

代码产出确实快了。不过，交回来的代码越来越多，也会带来一个问题：人还看得过来吗？

比汇编好懂，还远远不够

我有时会想，AI 生成的代码就算难懂，至少也比汇编语言好懂吧。但仔细想想，这个标准实在有点低。看懂一行高级语言的语法，和理解整个系统为什么这样设计，完全是两种难度。函数名都认识，逻辑也能顺着读下来，却不一定知道这个改动会影响哪些边界条件。 当然，AI 代码也并非注定难读。能要求它实现功能，也应该要求它保持简单、少引入无必要的抽象，并解释关键取舍。不能因为代码生成便宜了，就默认维护它的人也有无限的时间。

Human in the loop 不能只剩点击批准

我想，以后的代码审核，越来越多会先交给 AI 做一轮：检查常见错误，梳理改动路径，寻找遗漏的测试，再由工程师按风险深入审查。涉及权限、安全、数据完整性和关键业务规则的地方，更需要有人真正理解并负责。 但“AI 写，再让 AI 审”也不能自动变成正确性的保证。两个 Agent 可能都接受了同一个错误前提；如果一开始把需求理解错了，代码和测试甚至可以一起错得很一致。 因此，human in the loop 不能省，而且这个“人在环中”必须有实质内容。工程师要有足够的上下文和时间，能够质疑实现、要求证据，也能够否决改动。如果每天面对的代码量翻了好几倍，审查时间却没有变化，最后很容易只剩下一个点击“批准”的动作。

效率提高了，人的成长却没有同步

这也引出了我最近更在意的一件事：工作产出增加了，从工作中获得的成就感和经验，却没有同比增加。 以前亲手解决一个问题，要查资料、试方案、踩坑、调试，最后找到原因。过程有时很烦，但那些错误和弯路，会变成自己的经验。现在 AI 很快给出了一个可用的结果，我也能看懂它的解释，可“看懂了”距离“下次自己能独立判断”，中间仍然有一段路。 同时指导五个 Agent，可以让五项任务向前推进，却不会让我以五倍的速度吸收其中的知识。任务之间切换得越频繁，有时越容易只记住结论，来不及消化原因。

给理解留出时间

当然，这不意味着必须把所有代码重新手写一遍，才算学到了东西。AI 也可以帮助学习：让它比较两个方案，解释一个边界条件，带着自己复现一次故障。关键是给理解留出时间，自己也要作出判断，再用实际结果检验判断。否则，就很容易把“项目完成了”误当成“这些能力我已经掌握了”。 回头看 VB 和 Delphi 的那个窗口，我怀念的还有一种很清楚的联系：我做了什么，程序就发生了什么变化，我也知道自己从中学到了什么。今天这种联系变得间接了，成就感也需要重新寻找——把问题定义清楚、识别错误的方案、让几个 Agent 的成果组成一个可靠的系统，同样需要工程能力。 工具更新得再快，我还是希望每做完一个项目，除了多出一个能跑的程序，也能多留下几件自己真正弄懂的事。 [show_file file="/var/www/wp-post-common/justyy.com/ai.php"] [show_posts keyword="程序设计"] 英文：From Drag-and-Drop to Directing AI: Faster Coding, but Are We Growing as Developers?

汽车轮胎补气小记: 那个总是先报警的左后轮

2026-09-15 23:02:43

汽车左后轮每隔两三个月就会触发胎压报警，让我体验了家用充气泵的折腾和加油站补气的便利。本文记录这段养车日常，也聊聊几个容易想当然的胎压误区：40 PSI 并非通用标准，胎压也不是越高越好。面对反复掉压，除了按车辆推荐值补气，更应该及时查清原因。

左后轮又报警了

前不久，车子的仪表盘又提示左后轮胎压过低。我拿出之前在 Amazon 买的便携式充气泵，蹲在车旁给轮胎补气。既然工具都拿出来了，我通常会把四个轮胎一起检查、一起充，之前习惯把充气泵上的数值设在40左右。打完以后，仪表盘上四个轮胎都显示2.7，看着整整齐齐，心里也踏实。 可是，过了一段时间，左后轮又报警了。 观察了几次，我怀疑这个轮胎有些慢漏气。目前大概每隔两三个月，它的胎压就会比其他三个低一些，低到触发报警。每次补完气暂时恢复正常，过些日子，同样的问题又会出现。 我看后面两个轮胎也磨得差不多了，原本打算明年车检之前去车行一起换掉。今年做英国的 MOT 年检时，我已经换了前面两个轮胎，因为去年年检时就收到过磨损提醒。不过，后轮到底还能用多久，还是得看实际检查结果；反复掉压的问题，也应该先查清楚。

在家打气，最纠结的是拆接口

在家自己打气，方便之处是不用专门出门，麻烦之处是四个轮胎折腾下来，往往也要十来分钟。 最让我纠结的，是充气泵那个需要旋转拧紧的接口。接上时要一圈圈拧，充好后还得反方向一圈圈拧下来。每次拆接口，总能听见“嘶”的一声，心里马上开始算账：刚刚辛辛苦苦充进去的气，是不是又跑掉了一些？ 尤其是看到四个胎压数字不一样就想调整的人，最容易卡在这里：补一点，拆下来，听见漏气声，又想接回去确认一下。原本只是打个气，最后倒像是在跟小数点较劲。

加油站的充气设备更省事

相比之下，加油站的充气设备用起来爽快得多。有些加油站除了加油，还提供洗车、吸尘和轮胎充气服务。我见过的充气收费大约是两三英镑用五分钟，具体要看站点。它们的接口连接起来很方便，补气也快，充完拔下来干脆利落，不用像家里的接口那样反复旋转。

胎压不能凭感觉，也不是越高越好

至于胎压该打多少，我以前的想法很简单：看到机器上20到40的范围，就把40当成了上限，觉得充高一点，既可能省油，又能让那个慢漏气的轮胎多撑一段时间。

以车辆推荐胎压为准

这个想法需要纠正。充气设备上的范围，不能当成所有汽车通用的安全胎压范围。具体应该打多少，要看车门框、油箱盖内侧的胎压标签，或者车辆说明书，还要区分轮胎规格和载重情况。前后轮的推荐值也未必相同，不能为了让数字整齐，就一律打成一样。从我提到的读数推测，充气泵用的应该是 PSI，仪表盘用的则是 bar；40 PSI 约等于2.76 bar，两个数字实际上很接近。参考：米其林胎压说明

低胎压和高胎压都有代价

胎压不足确实会增加油耗，也会加快轮胎磨损。但不能由此推导出“胎压越高越好”。长期低胎压行驶会使轮胎过度变形、发热，严重时甚至可能爆胎；胎压过高则容易加剧胎面中央的磨损，影响操控表现。更合适的做法，是在冷胎状态下按照厂家建议检查和调整，不能靠额外多充气来补偿漏气。参考：米其林轮胎充气指南

反复报警，应该先查清原因

胎压报警也不能简单理解成“只是偏离了一点预设范围，不急着处理”。不同车辆的报警逻辑有所不同，报警并不等于轮胎马上会爆，但也不能据此认为还能放心开很久。发现报警后，应在安全的地方停车检查，确认实际胎压和轮胎状况；平时也应该定期检查，不必等到仪表盘提醒才想起来补气。参考：米其林胎压监测系统说明 至于我的左后轮，反复比其他轮胎掉压更快，就值得尽快让车行查一查。可能是扎了小钉子，也可能是气门嘴或轮毂与轮胎之间的密封出了问题，单凭“两三个月才报警一次”，还判断不了具体原因。既然还怀疑后轮磨损较多，就更应该把漏气和磨损一起检查，不能只按明年的年检日期安排。参考：米其林胎压下降原因 家里的充气泵依然很实用，加油时顺手补气也确实省事。只是下一次蹲在车旁，比起纠结拆接口时那一声“嘶”，更值得先确认的，是这条轮胎究竟为什么总在掉压。 [caption id="attachment_72924" align="alignnone" width="2048"] 为了省几英镑，DIY，但是这个充气的速度有点慢。[/caption] [show_file file="/var/www/wp-post-common/justyy.com/car-insurance.php"] [show_posts keyword="轮胎"]

代码交给 AI 以后, 程序员还需要什么能力?

2026-09-09 23:25:57

从聊天到动手：AI 把不可思议变成了日常 From Chat to Action: AI Is Making the Extraordinary Ordinary 三年前惊叹它会聊天，如今 AI 已经能看、能听、能行动 Three Years Ago, AI Could Chat. Now It Can See, Hear, and Act 当 AI 有了“眼睛、耳朵和手脚”，程序员的工作变了 AI Has Eyes, Ears, and Hands—And Programming Is Changing 昨天的 AI 奇迹，今天的理所当然 Yesterday’s AI Miracles Are Today’s Expectations 从复制粘贴到交代任务：程序员与 AI 的三年 From Copy and Paste to Delegating Tasks: Three Years with AI 代码交给 AI 以后，程序员还需要什么能力？ When AI Writes the Code, What Skills Do Developers Still Need? 以后的编程语言是英语？事情没那么简单 Is English the Next Programming Language? It’s Not That Simple 从 ChatGPT 到 AI 智能体：变化比想象中更快 From ChatGPT to AI Agents: Faster Than We Imagined 翻看三年多前的视频，才发现当时让我们惊叹的 ChatGPT 对话能力，如今早已成为日常。从文字聊天到能看、能听、能调用工具执行任务，AI 正在改变软件开发的方式。随着 Vibe Coding 和 Harness Engineering 的发展，程序员可以将更多编码工作交给 AI，而清晰表达需求、阅读代码、理解业务和验证结果的能力，也变得更加重要。

从聊天到动手：AI 正在把昨天的不可思议变成今天的日常

最近翻到一段三年多前的视频，里面的我们还在惊叹 ChatGPT 居然能这样聊天。再看三年前的视频，连 AI 回复时一个字一个字往外蹦的速度，都明显没有现在快。当时我们还会盯着屏幕，耐心等它把话说完，觉得这种边生成、边显示的过程很神奇。如今，回复更快了，能完成的任务也复杂得多，我们却开始嫌它思考太久、执行太慢。人的适应能力就是这么强：技术不断进步，我们的期待也跟着水涨船高，曾经让人惊叹的体验，很快就变成了习以为常的标准。 [video_links] https://www.youtube.com/watch?v=garlKUEw1oA https://www.bilibili.com/video/BV1U7Ya6dE6d/ https://x.com/doctorzlai/status/2097787493303132295 https://www.facebook.com/reel/2286365265485326 https://www.threads.com/@doctorlai/post/DdFJHvqlwO0 https://mp.weixin.qq.com/s/AEROXgN2ywe5GM3CabgkNQ https://weibo.com/1858482220/RhoyKktvL https://www.xiaohongshu.com/explore/6aa1c4f90000000011034765?xsec_token=YBzuIAKY7pihIWdkWQN75biZ6gVBs0e1sOBYjVZpLsn0M=&xsec_source=pc_creatormng https://www.instagram.com/p/DdFJnjdAamr/ https://weixin.qq.com/sph/AvVCzre9g [/video_links] 你问一个问题，它能像模像样地回答；你让它解释代码，它能逐行分析；你让它写个函数，它也能给出一段实现。那时我已经觉得，这东西会改变世界。 现在回头看，那个阶段的体验竟然显得有些朴素了。当时的惊叹完全可以理解，只是后来的变化，比想象中还快。

从 Stack Overflow 到直接问 AI

以前程序员遇到问题，通常先搜索，再去 Stack Overflow 找答案，翻文档、看讨论，从几个页面里拼出一个适合自己的解决方案。Copy & Paste 当然只是玩笑式的概括，真正费时间的，往往是判断哪个答案适用，以及怎样把它改成自己需要的样子。 ChatGPT 把其中不少步骤压缩成了一轮对话。它可以根据问题整理资料、解释概念、给出示例，我们还可以继续追问。这种不用在一堆网页之间来回切换的体验，当时已经足够让人兴奋。 只是那时，大多数时候它负责“说”，我们负责“做”。它给出命令，我们复制到终端；它生成代码，我们粘贴到编辑器；运行报错以后，再把错误信息贴回去。

AI 开始拥有“眼睛”“耳朵”和“手脚”

没过多久，AI 的能力就从文字对话扩展到了看、听和行动。它开始能“看”图片、截图和视频，理解其中的内容；能“听”语音，识别我们说的话，并通过语音交流；还可以借助工具调用，读取文件、修改代码、执行命令，再根据运行结果继续调整。 当然，这些“眼睛”“耳朵”和“手脚”是比喻。背后是多模态理解、语音交互，以及连接外部系统的工具与执行环境。不同模型和产品具备的能力也不完全一样。 MCP（Model Context Protocol，模型上下文协议）为连接数据源和工具提供了统一方式，让 AI 更容易与外部系统配合工作。它像是连接“手脚”的标准接口之一，而不是让 AI 获得所有这些能力的来源。 这样的变化很直接：以前我需要把看到的问题打成文字，把 AI 给出的代码和命令搬到电脑里执行；现在可以直接给它一张截图、一段语音，或一个明确的任务，让它在授权范围内完成分析、修改、运行和检查。 聊天框还是那个聊天框，背后却已经多了感知信息和采取行动的能力。 参考：Anthropic：Introducing the Model Context Protocol

从解释编程题，到参与前沿数学研究

与此同时，模型本身的能力也在继续增长，甚至开始触及前沿数学研究。 2026 年 9 月 8 日，OpenAI 宣布其内部 AI 系统给出了 Navier–Stokes 存在性与光滑性问题的一项证明。这个问题涉及三维流体运动是否可能在有限时间内出现奇异性，相关研究可以追溯到 1934 年，后来被列为千禧年数学难题之一。 按照公告，约一万个智能体参与了找到结果的协作组，在约 88 小时后得到解答；GPT-6 Astra 又参与了约 17 小时的 Lean 形式化与验证。 参考：OpenAI：On the Navier–Stokes Millennium Prize Problem

令人震撼，也需要把事实说准确

这里需要说准确：提出证明的是比 Astra 更强的内部系统，不能简化成“在 ChatGPT 里问了一句，Astra 就解出了百年难题”。 而且，截至本文写作时，克雷数学研究所的页面仍将该问题列在未解决问题中。公司发布证明、形式化验证与数学界充分审查和认可，是需要区分的事情。 参考：克雷数学研究所：千禧年数学难题 即便保留这些必要的区别，这件事仍然令人震撼。三年多前，我们还在为 AI 能解释一道编程题而惊叹，如今已经需要认真讨论它在重大数学研究中扮演什么角色。

从 Vibe Coding 到 Harness Engineering

回到程序员的日常，变化同样明显。

用自然语言把想法做出来

Vibe coding 所代表的体验，是用自然语言描述想法，让 AI 先做出来，再通过不断反馈调整结果。做原型、写小工具时，这种方式尤其直观：很多过去要逐行实现的东西，现在可以先说清楚，再让 AI 生成。 不过，能快速做出一个演示，和能长期维护一个可靠的软件，仍然有距离。

让 AI 持续、可靠地完成任务

这也是 harness engineering 值得关注的原因。它是一种工程思路：为 AI 准备合适的工作环境、上下文、工具、约束和反馈机制，让它能够持续、可靠地完成任务。 OpenAI 在一篇工程文章中介绍，他们曾实验性地用 Codex 构建一个产品，代码全部由智能体生成，而工程师负责定义目标、设计环境和建立反馈循环。 参考：OpenAI：Harness engineering 这让我越来越觉得，在不少开发任务里，程序员确实已经可以把大量手动编码交给 AI。不过，要说“现在程序员基本不需要写代码了”，还是太笼统。不同项目的复杂度、历史包袱和可靠性要求，差别很大。 我们花在敲代码上的时间可能减少了，花在定义问题、审查结果和判断取舍上的精力，却未必会减少。

以后的编程语言是英语？

我有时会开玩笑说，以后的编程语言是英语。 更准确一点，是自然语言。英语可以，中文也可以。过去，我们需要把需求翻译成编程语言；现在，越来越多的翻译和实现工作可以交给 AI。 但“只需要提需求”这句话，很容易让人低估提需求本身的难度。

把需求说清楚，本身就是能力

“帮我优化这个服务”，听起来很清楚，其实什么都没说清楚。

• 是降低平均延迟，还是改善 P99？
• 是提高吞吐量，还是减少成本？
• 允许改变接口吗？
• 可以牺牲多少准确性？
• 怎样判断这次改动真的有效？

这些问题没有答案，AI 再会写代码，也可能非常高效地朝错误的方向前进。

代码可以交给 AI，判断力仍然需要自己练

阅读代码的能力

你可以不亲手写每一行，但需要能在关键位置检查逻辑、追踪数据流、识别不合理的假设。 测试也很重要，但测试通过只能说明它通过了这些测试，不能自动证明需求理解正确。

领域知识

Domain expertise，也就是领域知识，同样重要。了解业务规则、数据含义和实际使用场景，才能判断一个看起来漂亮的实现是否真的解决了问题。 有些错误不会报异常，甚至性能很好，只是结果根本不是用户需要的。

软件工程能力

软件工程能力也不会因为代码生成变容易而失去价值。架构、接口、可维护性、可观测性、发布和回滚，都需要有人认真考虑。代码产出越快，这些约束越需要跟得上。 因此，把 AI 用好，正在成为一种新的能力。这不只是记住几个好用的提示词，还包括拆解任务、提供上下文、定义验收标准，以及在 AI 给出答案时，知道应该相信什么、检查什么、继续追问什么。

昨天的不可思议，正在成为今天的默认要求

AI 最让我感慨的，是它不断改变我们对“正常”的认识。 第一次看到它写出能运行的代码，会觉得不可思议。用上一段时间以后，就开始嫌它为什么没有顺便写好测试。等它能自己修改、测试、修复，又会期待它直接交付完整功能。 曾经的惊喜，很快就变成了默认要求。昨天还觉得不可能的事情，一旦实现，我们适应得比自己想象中更快。 三年多前，我看着 ChatGPT 的回答，觉得它会改变世界。现在再看那段视频，我依然认同当时的判断，只是对“改变”有了更具体的体会。 它已经进入我们的工作流程，改变了从一个想法到一个可运行成果之间的距离。 而我也需要不断调整自己：少把能力等同于亲手写了多少代码，多问问自己，能不能发现真正值得解决的问题，把它讲清楚，并判断最后交付的东西是否经得起检验。 [show_file file="/var/www/wp-post-common/justyy.com/software-engineer.php"] [show_posts keyword="人工智能"] 英文：When AI Writes the Code, What Skills Do Developers Still Need?

京东Joybuy在英国越来越火: 从中国零食到宇树机器人都能买

2026-09-08 21:42:19

京东邀请码：SBJG45 首单10英镑省3英镑。

Joybuy登陆英国后：便宜、方便、优惠多，我媳妇已经快买上瘾了 京东Joybuy在英国越来越火：从中国零食到宇树机器人都能买 Joybuy英国使用体验：价格便宜、配送快，就是纸箱太多 从Amazon到Joybuy：英国网购正在多一个强劲选择 Joybuy登陆英国后，我家的快递明显变多了 Joybuy英国体验：优惠券、签到积分、低价会员，确实很会“拿捏”用户 京东Joybuy进入英国及部分欧洲市场后迅速受到不少消费者欢迎。中国零食、饮料、日用品甚至电器都能方便购买，再加上签到积分、优惠券、本地仓配送和低价会员服务，整体体验颇具竞争力。相比Amazon和TEMU，Joybuy既有价格优势，又更贴近日常消费需求。不过频繁购物也带来了一个很现实的问题：家里的纸箱越来越多了。

再说京东JoyBuy: 可以打卡积点还可以买宇树机器人

今年京东 Joybuy 登陆英国以及法国等部分欧洲国家后，确实很快就火了起来。 虽然也有人批评，说 Joybuy 这样的电商平台会冲击本地实体零售行业，但我对此倒不是特别在意。对普通消费者来说，购物更方便、价格更便宜，本身就是好事，而且有竞争总比没有竞争强。至少可以让一些当地中超也感受到点压力，省得东西卖得又贵，质量还参差不齐。 很久以前我甚至听说过，有无良中超遇到蛋糕表面长毛了，直接把上面那一层刮掉继续卖。真假暂且不论，但这些年来我对英国一些中超的购物体验确实一般，尤其是退货，经常比较麻烦。 相比之下，Joybuy 的体验就简单多了。 我媳妇最近用得特别频繁，基本上属于“三天一大买，两天一小买”。尤其是中国零食，在上面买特别方便。像东方树叶这种零卡饮料，她基本都是一箱一箱地往家里搬。 上次她更夸张，一口气买了五箱、每箱 24 瓶的矿泉水——因为每单最多只能买五箱。 [caption id="attachment_72890" align="alignnone" width="1152"] Joybuy上的矿泉水和泡面，屯粮/隔几天就去露营了。[/caption] 京东邀请码：SBJG45 首单10英镑省3英镑。 送货小哥估计当场就后悔接这一单了。 他得从货车里一箱一箱搬到我家门口，搬到最后还开玩笑地说： “这是世界上最后的水了吧？” 最近英国政府也一直建议民众准备一些应急饮用水和食物，以防极端天气或者其他突发情况。我估计我媳妇看到这种新闻以后，很快又要有所行动了。

京东打卡积点抵现

Joybuy 的 App 里面还有一个我觉得设计得挺聪明的功能：每日签到赚积分。 而且还可以设置手机提醒。 最关键的是，这些积分不是那种看起来很多、实际上不知道能干什么的虚拟数字，而是真的可以直接抵现金。 这一下签到就有动力了。 从产品设计的角度来看，我觉得这一招其实很妙：每天签到，可以增加用户打开 App 的频率和用户黏性；而一旦账户里攒了一些积分，很多人又会产生一种“这些积分不用掉好像亏了”的心理。 比如我媳妇就是这样。 [caption id="attachment_72891" align="alignnone" width="945"] Joybuy每日提醒打卡积点/抵现[/caption] [caption id="attachment_72892" align="alignnone" width="945"] Joybuy积点历史[/caption] 而且我发现 Joybuy 和 TEMU 有点类似，经常会给你发各种 Voucher，比如满 £40 减 £5、满 £60 减 £20之类的。有时候刚下完一单，又给你送新的券，感觉永远都用不完。 于是你本来觉得： “这次买完了，最近应该不用买了。” 结果第二天打开 App： “咦？又有一张券。” 然后又开始凑单。 不过 Joybuy 和 TEMU 对我来说有一个很大的区别。 Joybuy 上买的东西，大多数至少都是正常生活中会消耗掉的东西，比如吃的、喝的、日用品，所以即使买得频繁，也不太容易买一堆完全没用的东西。 TEMU 就不一样了。 前两年我在 TEMU 上买过不少“有的没的”。下单的时候觉得特别便宜，几镑钱一个，看着很划算，但买回来以后才发现，要么根本用不上，要么质量比较一般。 单看每一件都没多少钱，但加起来其实就是乱花钱。 Joybuy 现在卖的东西也越来越杂，不只是食品和日用品，连电器都有。 比如今年夏天天气特别热的时候，Joybuy 上连空调都卖，而且有一段时间直接卖断货了。 我今天刷 App 的时候，甚至发现上面已经可以买宇树机器人了，而且居然还能隔天送到。 [caption id="attachment_72893" align="alignnone" width="945"] Joybuy上可以买宇树机器人，价格不便宜啊[/caption] 这基本也能说明 Joybuy 在英国已经铺了不少本地仓储，否则这种配送速度很难做到。

Joybuy Plus会员服务

Joybuy 现在还推出了类似 Amazon Prime 的会员订阅服务。 月费 £3.99，年费只要 £19.99。算下来一个月还不到 £2。 会员最直接的好处就是免运费，另外还有一些 Member Only Deals。 本来 Joybuy 凑到一定金额也可以免运费，但有会员以后，就不用为了免运费硬凑单了。 比如突然想吃一包零食，直接买一包也可以送上门。 从这个角度看，£19.99 一年的价格确实挺划算。 再对比一下 Amazon Prime：目前英国年费大约 £95，月费 £8.99。 当然 Prime 除了配送，还有 Prime Video 等其他服务，但如果单纯从“买东西”这个角度来说，我现在觉得 Amazon 最大的优势还是 Next Day Delivery，以及商品种类特别全。 问题是，Amazon 上很多中国商品价格其实并没有什么优势。 比如一件普通 T-shirt，在 Amazon 上可能就要 £20 左右，而类似的东西在 TEMU 或 Joybuy 上，几镑钱就可能买到。 当然，质量未必完全一样，但价格差距确实很明显。 目前我对 Joybuy 最大的吐槽，反而不是商品或者配送，而是： 纸箱实在太多了。 每次送货过来，不管买的是什么，都感觉特别喜欢“大箱子套小箱子”。 拆快递的时候挺爽，拆完以后看着家里那一大堆纸箱，就开始头疼。 每次处理纸箱都得拆开、压平，再塞进回收箱。 有时候我都忍不住想： Joybuy 这么豪横的吗？ 纸箱不要钱？ 要是在国内，这么多纸箱估计早就有人收走卖钱了。 不过从消费者角度来说，目前 Joybuy 在英国的体验整体还是挺不错的：价格有竞争力，中国商品丰富，配送快，退货相对方便，再加上签到积分、优惠券和低价会员这些运营手段，确实很容易让人形成使用习惯。 至少从我媳妇的使用频率来看，Joybuy 的这套打法显然已经成功了。 至于我们家接下来最大的问题，大概不是“还要不要买”，而是： [bctt tweet="这些纸箱到底往哪儿放。"] [show_posts keyword="joybuy"] 京东邀请码：SBJG45 首单10英镑省3英镑。