V2EX › Ketteiron 的所有回复 › 第 8 页 / 共 38 页

V2EX = way to explore

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

For Existing Member Sign In

1 ... 4 5 6 7 8 9 10 11 12 13 ... 38

❮

❯

3 月 16 日

回复了 tty0 创建的主题 › 生活 › (续 3)家里人要我回家乡做一场法事, 私闯民宅...

你做得不够绝，亲戚会认为一切的不幸是你的“不听话”“不尊重”导致的，会变本加厉的做更多的事。
除了搬远、断绝不必要联系以外没有办法。
我讨厌迷信的最大一点就是通常会裹挟亲情，迷信者听不进去任何客观道理，只看立场。你的立场远离他们，他们便来折腾你了。

3 月 13 日

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

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

3 月 13 日

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

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

3 月 13 日

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

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

3 月 12 日

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

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

3 月 12 日

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

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

3 月 10 日

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

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

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

3 月 10 日

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

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

3 月 10 日

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

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

3 月 6 日

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

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

3 月 4 日

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

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

3 月 3 日

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

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

3 月 2 日

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

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

3 月 2 日

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

我去，初音未来！

3 月 1 日

回复了 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 。

1 ... 4 5 6 7 8 9 10 11 12 13 ... 38

❮

❯