Lucups

@catazshadow 有很多约定俗成的细节是不需要语言描述的，有很多场景其实人们并不关心怎么实现的，实现可能有 ABCD 很多种，人们只要结果，并不需要一定要用 A 方式实现。

可能在你看来 prompt 与代码的关系是文件与压缩包的关系，文件不能被无限压缩，但其实两者的关系并非如此。
AI 也并非单纯地凭借 prompt ，还有 mcp 、skills 、你的代码上下文等很多方面提供信息，所以大多数场景下只要你的 prompt 不是太简略，信息熵是足够的。

@SkyEcho 老罗还是做了几款不错的产品的

我主要做后端，我现在 90% 以上的代码都是 AI 写的。

不过我也能理解一些后端同学不愿意使用 AI 辅助写代码，毕竟前端出问题了有后端兜底，后端出问题了就真出问题了.....

我觉得矮大紧倒没有编造，可能是记忆模糊+夸大了。

你找到的资料中就有下面这些描述：

“由于它暴露了皮肤的瑕疵，人们有点讨厌这种光。”
“但宫殿里的客人们不仅害怕在刺眼的电灯下显得丑陋，更担心电灯泡损害健康。”

所以当时应该是有白金汉宫里的一些人反对用电灯这一说的，只不过以讹传讹，最后又被矮大紧夸大了而已。娱乐圈节目，又不是严肃的历史研究，没必要这么较真。

@mytsing520 互联网服务跟电信业务不是一码事， @S179276SP 说的是互联网服务。

人家那边做个网站、APP 是不需要备案或者行政审批的，包括 HK 。

我的观点是看场景。

对于典型的 CRUD 业务型代码，其实并不太适合大量使用 lambda ，因为这类代码需求变化频繁，经常会引入提前终止、复杂分支或状态控制。

之前还在写 Java 的时候，团队里有新人把 lambda 当成 for 循环来用。功能实现没有问题，但一旦需求出现需要提前终止遍历的情况，就只能把整段 lambda 重构回 for 循环，整体的可维护性和扩展性都比较差。

我就改过好几次这种需求，恶心坏了。

反过来，在大数据或流式数据处理场景下，如果不用 lambda / Stream 这种函数式抽象，代码的表达能力和可扩展性基本是无法接受的。

逻辑就这样

屏蔽广告就别想了...

广告是互联网的基石，头部的那些互联网大厂，没有几家广告收入不占大头的。