 |
LucupsV2EX 第 41582 号会员，加入于 2013-07-03 20:32:51 +08:00 |
crowall.com
Lucups 最近回复了
2 天前 回复了 Chatterleys 创建的主题 › 程序员 › 公司版的 apple 开发者账号续费成本有点高呀，要不要退了 |
公司版的不是 199 美刀一千多一年吗？
688 的是个人版的吧？
688 的是个人版的吧？
2 月 28 日 回复了 YanSeven 创建的主题 › 程序员 › 一些复杂的任务的 prompt 对经验和能力的要求感觉不比 coding 低 |
@catazshadow 有很多约定俗成的细节是不需要语言描述的，有很多场景其实人们并不关心怎么实现的，实现可能有 ABCD 很多种，人们只要结果，并不需要一定要用 A 方式实现。
可能在你看来 prompt 与代码的关系是文件与压缩包的关系，文件不能被无限压缩，但其实两者的关系并非如此。
AI 也并非单纯地凭借 prompt ，还有 mcp 、skills 、你的代码上下文等很多方面提供信息，所以大多数场景下只要你的 prompt 不是太简略，信息熵是足够的。
可能在你看来 prompt 与代码的关系是文件与压缩包的关系，文件不能被无限压缩，但其实两者的关系并非如此。
AI 也并非单纯地凭借 prompt ，还有 mcp 、skills 、你的代码上下文等很多方面提供信息，所以大多数场景下只要你的 prompt 不是太简略，信息熵是足够的。
2 月 27 日 回复了 Lucups 创建的主题 › 分享发现 › 罗永浩的 TNT 如果有现在的 AI 加持，会不会火爆？ |
@SkyEcho 老罗还是做了几款不错的产品的
2 月 26 日 回复了 Qcui 创建的主题 › 职场话题 › 为什么后端同学普遍不愿意使用 AI 辅助写代码 |
我主要做后端，我现在 90% 以上的代码都是 AI 写的。
不过我也能理解一些后端同学不愿意使用 AI 辅助写代码，毕竟前端出问题了有后端兜底，后端出问题了就真出问题了.....
不过我也能理解一些后端同学不愿意使用 AI 辅助写代码，毕竟前端出问题了有后端兜底，后端出问题了就真出问题了.....
2 月 26 日 回复了 fengwq 创建的主题 › 分享发现 › 高晓松好像编造了一段历史：白金汉宫反对用电 |
我觉得矮大紧倒没有编造，可能是记忆模糊+夸大了。
你找到的资料中就有下面这些描述：
“由于它暴露了皮肤的瑕疵，人们有点讨厌这种光。”
“但宫殿里的客人们不仅害怕在刺眼的电灯下显得丑陋，更担心电灯泡损害健康。”
所以当时应该是有白金汉宫里的一些人反对用电灯这一说的，只不过以讹传讹，最后又被矮大紧夸大了而已。娱乐圈节目，又不是严肃的历史研究，没必要这么较真。
你找到的资料中就有下面这些描述：
“由于它暴露了皮肤的瑕疵，人们有点讨厌这种光。”
“但宫殿里的客人们不仅害怕在刺眼的电灯下显得丑陋，更担心电灯泡损害健康。”
所以当时应该是有白金汉宫里的一些人反对用电灯这一说的，只不过以讹传讹，最后又被矮大紧夸大了而已。娱乐圈节目，又不是严肃的历史研究，没必要这么较真。
2 月 9 日 回复了 MindMindMax 创建的主题 › 程序员 › 中国境内合法合规经营您的业务，必备手续/许可证参考 |
1 月 13 日 回复了 ngduncent 创建的主题 › 程序员 › 2026 年了 竟然还有程序员接受不了 lambda |
我的观点是看场景。
对于典型的 CRUD 业务型代码，其实并不太适合大量使用 lambda ，因为这类代码需求变化频繁，经常会引入提前终止、复杂分支或状态控制。
之前还在写 Java 的时候，团队里有新人把 lambda 当成 for 循环来用。功能实现没有问题，但一旦需求出现需要提前终止遍历的情况，就只能把整段 lambda 重构回 for 循环，整体的可维护性和扩展性都比较差。
我就改过好几次这种需求，恶心坏了。
反过来，在大数据或流式数据处理场景下，如果不用 lambda / Stream 这种函数式抽象，代码的表达能力和可扩展性基本是无法接受的。
对于典型的 CRUD 业务型代码，其实并不太适合大量使用 lambda ，因为这类代码需求变化频繁，经常会引入提前终止、复杂分支或状态控制。
之前还在写 Java 的时候，团队里有新人把 lambda 当成 for 循环来用。功能实现没有问题，但一旦需求出现需要提前终止遍历的情况，就只能把整段 lambda 重构回 for 循环，整体的可维护性和扩展性都比较差。
我就改过好几次这种需求，恶心坏了。
反过来，在大数据或流式数据处理场景下，如果不用 lambda / Stream 这种函数式抽象，代码的表达能力和可扩展性基本是无法接受的。
Select Language