V2EX › sentinelK 的所有回复 › 第 15 页 / 共 85 页

V2EX = way to explore

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

For Existing Member Sign In

1 ... 11 12 13 14 15 16 17 18 19 20 ... 85

❮

❯

2 月 3 日

回复了 Nexora 创建的主题 › 投资 › 沪深 300 指数能不能买

短线看确实没有关系。中长期看有一定关系。
建议在分批建仓这种宽基指数以外，可以针对性的投一两个行业 ETF 。这样可以增加一定的盈利概率。

另外，高股息的类似“红利 ETF”，也可以作为对冲进行一定量的购买进行防守。

2 月 2 日

回复了 cat55 创建的主题 › NAS › 经过此次飞牛的漏洞，搞不懂为什么都喜欢直接把服务公网暴露出去

@cat55 你看，这个问题就在于此。

1 、飞牛 OS 、穿透收费产品本身在产品定义上，是有安全机制的，但已失效数月。
2 、他是否有明确告知用户飞牛 OS 的设备不能外网访问，或外网访问的危险性？
3 、飞牛在整个生态中是否牟利？又是否基于利益的原因阻止用户止损？

你这样说话，和劝遭性侵受害者多穿点，命案受害人早点回家有什么区别？

2 月 2 日

回复了 cat55 创建的主题 › NAS › 经过此次飞牛的漏洞，搞不懂为什么都喜欢直接把服务公网暴露出去

@cat55 哦，你意思是说，飞牛 OS 自身没有任何安全机制。以及他家的收费穿透服务也没有任何防御机制。

2 月 2 日

回复了 cat55 创建的主题 › NAS › 经过此次飞牛的漏洞，搞不懂为什么都喜欢直接把服务公网暴露出去

哦对了，门锁厂家还有窃贼一键通服务哦，用户你只要交钱，即便你的大门开在天上，飞牛也可以一键送贼到家。

2 月 2 日

回复了 cat55 创建的主题 › NAS › 经过此次飞牛的漏洞，搞不懂为什么都喜欢直接把服务公网暴露出去

@diudiuu 关键是已经几个月了压根就锁不上。还要告诉用户已经锁了，结实着呢。

2 月 2 日

回复了 cat55 创建的主题 › NAS › 经过此次飞牛的漏洞，搞不懂为什么都喜欢直接把服务公网暴露出去

是，我也不太懂为何你们要把家里大门暴露出去。
进贼了怪我门锁干什么，明明是你们要把家里大门暴露到外界的。

外面装个防盗门不好吗？

1 月 30 日

回复了 chtcrack 创建的主题 › 职场话题 › 当卷王掌握了 vibe coding 会如何?

卷王又不是卷在生产力。

他们体现的是 on call 能力，向上管理能力，以及执行力。
领导让他们改，他们就改，无论时间、地点、理由。

1 月 30 日

回复了 cnguu 创建的主题 › 程序员 › 现在 vibe coding 的人多不多？

如果公司提供，那么你的 KPI 其实是计算了 AI 赋能之后的。相当于你理论上应该完成更多的工作。
如果公司不提供，你自购就可以利用你的生产力和公司 KPI 之间的差偷偷划水。

里外里，想不到任何不用 AI Coding 的理由。

1 月 30 日

回复了 apacheinsky 创建的主题 › 程序员 › 如果没有 AI 低代码会自己死掉吗

@jchnxu 这个不冲突，商业逻辑和技术产品力，这二者其实是完全不同的维度，不互相影响，也不成线性关系。
对他们感兴趣的人群也是不同的。

情绪价值是商业逻辑中很重要的一环，这毋庸置疑。
但是低代码的商业逻辑真的存在吗？或者说真跑的通吗？估计每个人有每个人的预判和思路。
毕竟“低代码”这个名词的解释权都很混乱，甚至设计个 OA 工单流转都敢叫低代码。

当然，我个人的视角，只是我个人作为技术从业者的主观好恶。

1 月 30 日

回复了 pixio 创建的主题 › 职场话题 › [血泪教训] 仲裁被律师带节奏， 2N 变成 N+1.5 的惨痛经历

所以经济类纠纷，律师都是按照赔偿比例收费的。这就避免了律师利益方向和事主不同的问题。

1 月 29 日

回复了 FH0 创建的主题 › 程序员 › Claude 模型很喜欢说：你说的对

1 、在表达方式上，监督学习的结果一定是讨好审核者的。
2 、因为大语言模型是统计学，所以讨好使用者和你最终得到的结果是否“降智”没有特别相干的关系，可以尝试多提供一些上文，从而排除一些错误的局部最优。

1 月 29 日

回复了 abellis 创建的主题 › 程序员 › 在没有技术背景的情况下， Rust 这种无错误编译后才能运行的语言在 ai coding 逐渐成为主流的情况下是否更能保证应用的完整性，更适合 vibe coding？

程序错误 ≠ 编译报错
不需编译 ≠ 运行前无法检查错误

1 月 29 日

回复了 apacheinsky 创建的主题 › 程序员 › 如果没有 AI 低代码会自己死掉吗

VibeCoding 同理，他只能降低参与门槛，但不能降低软件工程行业的门槛。

因为软件工程的商业价值从来不是“写代码”本身。
餐馆后厨的商业价值也从来不是“做饭”。

1 月 29 日

回复了 apacheinsky 创建的主题 › 程序员 › 如果没有 AI 低代码会自己死掉吗

如果假定低代码这个产物客观合理。

我个人理解是这二者，在技术领域上不冲突。但是商业模式上冲突。
技术领域这二者是完全的反面。一个是精准的逻辑组合，一个是概率的模糊生成。

商业上二者完全冲突。低代码的本质就是降低业务的数字化门槛，让业务人员更多的参与程序的制定。
VibeCoding 恰巧也是这个商业定位。

至于说你标题的问题，在我看来，低代码一直就不具备实际的技术合理性，是一种满足企业领导对软件掌控力诞生的伪概念和伪产品。

1 月 29 日

回复了 ion1ze 创建的主题 › ☕Vibe Coding🤖 › VibeCoding 前后端应该放一个仓库吗

是否在一个仓库，和能不能共享上下文，在绝大多数情况下无关。

所以在一个仓库和不在一个仓库均有道理。

1 月 29 日

回复了 AoEiuV020JP 创建的主题 › GitHub Copilot › copilot premium request 在燃烧

举个例子，比如 agent 模式生成了一次代码，然后调用 console 编译，未通过，他会尝试修复一次，然后再编译。

这个过程，从文档的描述上看，算两次请求。对于 opus ，也就是消耗 6 额度。

1 月 29 日

回复了 AoEiuV020JP 创建的主题 › GitHub Copilot › copilot premium request 在燃烧

应该是跟 https://docs.github.com/zh/copilot/concepts/billing/copilot-requests 中，对于 Copilot coding agent 的描述有关。

对于 agent 模式的计费是，“each real-time steering comment”。

如果你的 agent 在频繁的更改代码，就会频繁的扣 request 额度。

1 月 28 日

回复了 Tom7 创建的主题 › 程序员 › 突然想到一个问题，现在有 ai 了，那么 oracle 的 Java 团队等其他语言团队，后续更新会使用 ai 去创新或优化吗

其实不冲突的。
工程执行层面的演进，并不会阻碍设计的前进。
执行的演进有可能影响设计的偏好，也有可能衍生另外一个方向的设计模式与逻辑，但不会影响设计本身的上限。

类似的演变在其他工程学领域已经经历很多次了。

比如建筑工程领域，施工从红砖>砖混>钢混的演进。
比如汽车工程领域，从燃油车>轻混车>重混、纯电车的演进。

他们都没有影响建筑、车辆设计的上限。
但也确实诞生了新的设计模式。

1 月 28 日

回复了 fxxkgw 创建的主题 › 生活 › 又一个被菠菜搞得家破的同学。。

我理解，赌博游戏本身其实没有如此大的诱惑。本质上就是总预期负一点的概率游戏。只要三观正确就一定不会沉沦。

但真正恶心的，是围绕在赌博生态周边的吸血鬼。比如高利贷、中介、乃至托和千。这些才是真正让人家破人亡的恶魔。

1 ... 11 12 13 14 15 16 17 18 19 20 ... 85

❮

❯