V2EX › Ketteiron 的所有回复 › 第 1 页 / 共 30 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 30

❮

❯

1 天前

回复了 blueeon 创建的主题 › 程序员 › 为什么放弃了 RAG？ RAG 的六大难题

@YanSeven #22 知识图谱化召回率非常高，这肯定是有价值的。对于知识密集型行业效果很好，例如医疗、法律、历史、地理等等，至于像企业内部知识库等场景或许划不来，烧掉的 token 实在太多了。
有没有价值还是得看资料的质量如何，garbage in, garbage out

1 天前

回复了 blueeon 创建的主题 › 程序员 › 为什么放弃了 RAG？ RAG 的六大难题

@zhengfan2016 #6 这是用户画像系统+推荐系统。
RAG 主要是节约成本的前提下为 AI 提供合理的上下文，但目前向量搜索的命中率实在扯淡，很长一段时间直到现在，这种模式一般是用来骗投资的，没多少现实意义。
最合理的还得是 Agentic RAG + 深度预处理，将资料完全数字化，让 AI 整理、打标签、抽样、归纳、建立依赖关系，当需要检索时让 AI 自主决定调取什么资料。
OP 的方案本质上也是深度预处理的一种，比知识图谱化省钱，但其正确性由文档本身的结构化程度决定

1 天前

回复了 finiking 创建的主题 › 程序员 › 看看这个 AI 设计稿导出代码（React/Vue/ Swift ...）的还原度咋样？

@tlerbao #3 主要是大公司分责明确，如果没有固化的设计图，出事了谁来承担这部分的责任呢？
小公司的话现在确实不需要设计图了，直接修改代码的效率和准确率都更高，但在大公司的流程管理上，目前的设计职责很难分给开发人员或者产品经理。AI 提升了写一次性代码的效率，但还没很好地提升管理/组织效率。

1 天前

回复了 CHTuring 创建的主题 › 程序员 › 2026 年做企业官网，前端友好的技术栈是哪些呢？

@CHTuring #11 Payload/Sanity 类似方案的 schema as code 更加现代化。
不过 Payload 是全程掌控代码，Sanity 的后端服务由 SaaS 服务提供。
单论`好用`，我感觉所有 CMS 框架都不好用，手搓一个最好用。不过这里面破事太多了，愿意花钱就上 Sanity ，自部署上 Payload

2 天前

回复了 CHTuring 创建的主题 › 程序员 › 2026 年做企业官网，前端友好的技术栈是哪些呢？

投一票 astro ，官网用 next.js 有点大炮打蚊子

2 天前

回复了 jackOff 创建的主题 › 问与答 › 话说国产 agent 里面哪个编程能力最强最稳定

cursor 没有限制国内充值手段，支付宝就能买

4 天前

回复了 SuperDaFu 创建的主题 › OpenClaw › 发现很多人都与 openclaw 的态度怎么感觉是在嘲笑

> 很多人觉得让 Agent 自动跑很蠢、费钱。我想问，难道现在还有人坚持“古法编程”吗？
能用中文重新解释一遍这跳跃的逻辑吗？我实在没看懂。

openclaw 目前的定位很明确，就是一个电子玩具，还达不到生产力工具的水平。

4 天前

回复了 crocoBaby 创建的主题 › 程序员 › 想要重构屎山老项目,有成功实践的老哥分享一下经验嘛?

老 ui 框架无法适配 vue3 ，基本上要换掉大部分依赖项。
如果用组合式，这个难度基本上等于从零编写一个新项目。如果延续选项式，那没有重构的意义。

4 天前

回复了 burnsby 创建的主题 › 程序员 › Antigravity 为啥能这么垃圾啊？

Antigravity 至少落后 Cursor 两个代差，这个完成度在 2024 年只能说勉强能用，在 2026 年纯粹是靠着一帮白嫖用户撑起用户量。

8 天前

回复了 magicfield 创建的主题 › 程序员 › Agent 在传统企业的尝试与阻碍

良好的数字化是 AI 落地的前提，Garbage In, Garbage Out 是永恒不变的真理。

10 天前

回复了 programMrxu 创建的主题 › 程序员 › electron 什么时候可以支持 ts 呢。

@programMrxu #6 我猜你需要的是 electron-vite

11 天前

回复了 XIVN1987 创建的主题 › Python › Python 3.15 将引入一个很方便的语法： Unpacking in Comprehensions

@june4 #5 行不通，js 的 flat 只会对真正的数组进行操作，会使用类似 Array.isArray() 的判断，但 py 会产生歧义
在 py 里，字符串是无限递归的可迭代对象，如果要保持旧有设计就无法拍平，因此只能在一些工具函数里进行操作，硬编码一些判断
而 *L for L in lists 并非是用来解决二维数组拍平的，它解决的是无法在推导式中解包的设计缺陷。

12 天前

回复了 DragonX 创建的主题 › 生活 › 我目前听过最离谱的天价彩礼

@chitanda #44 没有区别。越穷的地方彩礼越高是有原因的，他们在大量陋习上花了大量金钱，同样指望"彩礼"这种陋习收回成本，不然根本活不下去，那么单方面承担彩礼的男方就是目前大量农村陋习的实际支持者。
当男方对 18 万 28 万 38 万 …… 说 yes 的时候，他实际上是用实际行动支持人口买卖以及对大量腐朽、未开化、反人类的文化续存做出贡献。

12 天前

回复了 mqnu00 创建的主题 › 初音未来 › 米库打油~

我去，初音未来！

14 天前

回复了 Chuckle 创建的主题 › 程序员 › Skill、MCP 等等 AI 外围工具，本质是 markdown 小作文吗

本质是 string | (args) => string | Promise<string>，静态文本或者生成动态文本的副作用函数

2 月 28 日

回复了 YanSeven 创建的主题 › 程序员 › 一些复杂的任务的 prompt 对经验和能力的要求感觉不比 coding 低

@catazshadow #2 不需要等量。你的想法大概是想要输出一千行完美的代码，需要等量的完美自然语言描述作为输入，但实际上利用 agent/mcp/skill 大概只需要十分之一甚至更少，它们负责补充 prompt 、编程式地提供上下文信息，在一个较低的损耗下实现所谓的等量。
这需要一个共识，即自然语言本身能够元编程，AI 在编程上的发展证实了这一点。
OP 的疑惑在于本质复杂度是无法通过偶然复杂度进行消除，它们是编程这个概念本身的最小复杂度无法以任何手段进行删减，但 AI 确实能够减少达到最小复杂度所需的时间/精力，这是两码事。

2 月 27 日

回复了 0x114514 创建的主题 › 程序员 › 同事的离谱代码让我想发疯

@avenger #19 上司都带头拉屎了，说这些有啥用。缺的不是解决办法，因为所有解决办法都没用，除非能开掉造成这些现象的开发者，因为不开掉它们绝对无法维护好 CI 。

2 月 18 日

回复了 w568w 创建的主题 › 问与答 › OSS 相比传统的文件系统有什么优势？

按量付费和可靠性。
自行实现的初始成本较高，光是 RAID 和异地容灾有几个小厂能做，即使能做，要付出的时间以及要踩的坑太多了。
除非达到 PB 级别，不然自建 FS 没太大优势，是个无底洞。
此外 cloudflare R2 是一个更现代化的选择，所有云厂商的 OSS 服务只能用屎山来形容。

1 2 3 4 5 6 7 8 9 10 ... 30

❮

❯