V2EX › sentinelK 的所有回复 › 第 2 页 / 共 66 页

V2EX = way to explore

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

现在注册

已注册用户请登录

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

❮

❯

100 天前

回复了 daifee 创建的主题 › 职场话题 › web 前端开发的发展方向

从应用软件开发角度讲，未来一定是广度优于深度的。

1 、因为 AI 导致的生产力爆发，基建肯定会越来越完善，到时候应用层面的技术深度就是空中楼阁。
2 、广度高，才能更合理的设计前端架构（大前端等）。
3 、技术深度的价值本身跨行业适用度不足。
4 、随着前端设备的性能进步（无论是 toB 还是 toC ），几乎没有业务场景可以支撑前端的深度技术展开。

100 天前

回复了 fqy12300 创建的主题 › 程序员 › 大厂的小程序是用什么框架开发的？

原生。第三方服务（比如腾讯旗下给环球做的小程序）才会尝试跨平台方案。

btw：
如果只是重视动效上的“丝滑”，这其实是 UI 设计的功劳，和技术栈关系几乎没有。
原生的优势主要还是体现在稳定与兼容性上。

100 天前

回复了 luolink 创建的主题 › 程序员 › AI 提效？拉倒吧，我累得要死

另外，你使用 AI 提效，减轻工作量，和“卖课”有什么关系？

如果你认为“卖课”的内容都能够干扰你对于使用工具的理解的话，楼主我建议你需要先学习信息检索。学会根据信息的渠道、内容风格来预估置信度，从而合理分配自己的精力。

100 天前

回复了 luolink 创建的主题 › 程序员 › AI 提效？拉倒吧，我累得要死

那楼主上班是徒步吗？骑车、买票、开车哪个不都有学习成本？

我个人理解只要整体收益是正的，工具就值得去使用。更何况大语言模型的收益是指数级的。

101 天前

回复了 wKong753900 创建的主题 › 程序员 › 有没有也是后端+架构+管理层的 v 友呀？

@wKong753900 原谅我说话比较直。作为一个公司的前端负责人，我是一直参与一线代码开发的。

当然，我们公司小，人力不够充沛是很重要的一个方面。
但更重要的是，我认为只有真的一直在一线开发，你才能真的感受到程序架构和企业生产运转的契合度如何。

在我理解看来很多细节是从宏观视角很难精准评估的。
比如最近通过一个小的 git 冲突自动合并导致的部门甩锅冲突，我也在思考 git 的管理方式是不是要再细化。

从类似 Github 风格的“功能驱动”分支逻辑改的再老派一些。
以及比如最近在思考 Hybird 的结构是不是再“web 化”一点，方便目前的公司结构做 C/S 、B/S 共存等等。

101 天前

回复了 wKong753900 创建的主题 › 程序员 › 有没有也是后端+架构+管理层的 v 友呀？

@wKong753900 那你写代码犯法么？你写一行 hello world ，你直接被开除出管理层？

101 天前

回复了 red13 创建的主题 › 程序员 › 如果你觉得自身具备商业价值，你会如何展现呢？

反过来也如此。如今很多企业，被天使投资。

你认为天使投资人是认可企业的使命，还是认为以后会有冤大头接盘？

101 天前

回复了 wKong753900 创建的主题 › 程序员 › 有没有也是后端+架构+管理层的 v 友呀？

如果你是恩佐·法拉利，你会焦虑现在的智驾么？

你不是软件开发的赛道，你纠结别人的生产工具干什么？

101 天前

回复了 red13 创建的主题 › 程序员 › 如果你觉得自身具备商业价值，你会如何展现呢？

没有固定方法论。
比如你如何解释 NFT 的商业价值？从我的视角看 NFT 就是“远红外纳米量子水杯”的赛博版本。

但一个丑猴子图片的“NFT 拥有权”就可以卖几十万美金。

101 天前

回复了 llej 创建的主题 › 程序员 › 如何实现模块化加载的前端和后端代码？

@llej 那不是应该从 Git 管理的角度入手吗。每个用户是不同的 Git 分支。否则你如何做后续支持？每次支持难道你都要“手动删除文件夹”到和用户环境一致的程度吗

101 天前

回复了 llej 创建的主题 › 程序员 › 如何实现模块化加载的前端和后端代码？

所以楼主说的和 jar 、dll 的引用，以及 js 的 import 有啥区别？
楼主的意思是不想改配置？

那你直接把你项目 src 中的某个文件夹、dll 、jar 直接删了不就行了……
直接删了，IDE 直接标红，就满足了楼主说的“如果包之间有依赖但对应的包被移除了则编译时应该报错”

101 天前

回复了 kingpo 创建的主题 › 程序员 › 利用 AI 辅助编程有什么高效方式减少迭代的次数？

1 、拆解问题。把一个大问题，细化拆解成小问题，小问题要明确突出矛盾点。

2 、及时中断。一旦有符合自己需要的结果，就先保存结果。然后重新开始对话。

3 、尽量降低对既有代码的干扰。不要为了一个新功能推翻旧功能的设计，除非必须。

102 天前

回复了 Qinnn 创建的主题 › 程序员 › Anthropic Claude Sonnet 4 上下文 token 数提升至 100 万，提升了五倍

@Seck 这个“重点”其实是可以的。只要你给的上下文确实是有一个合理的最优解方向。因为从广义上讲，正确的上下文越大，其结果就越贴近于使用者的需求。

比如，之前的 GPT3.5 ，基于其上下文能力，你只能问一些语法等非业务问题。
但目前就可以问功能、问模块。

上下文再大一些可以问程序架构设计、跨项目的接口合理性规划等。这是一个循序渐进的过程。
所以上下文的扩展，其实是对使用者，以及周边配套程序（类似 Copilot 的搜索、 @workspace 功能）的上下文设计能力提出了更高的要求而已。

更大的上下文总是好的。

102 天前

回复了 rcj6056 创建的主题 › 程序员 › 关于占座位小程序的问题请教

@Kirkcong 我理解楼主应该是共享办公的管理方，或者是主打流动办公的公司（类似微软、苹果部分实行的 Hot-desking 模式）。

即便如此大规模的企业都没有“扫码定位/占座”这种奇葩的定义。
更让我差异的是，这种明显增加工作量的“反工具”，但还有人对这种产品定义叫好。

102 天前

回复了 rcj6056 创建的主题 › 程序员 › 关于占座位小程序的问题请教

@MrDream 哦，你也知道要 IM ，那你现实中要群发你的位置的时候你是怎么做的？同事又是怎么知道“要去领办公用品”的？

也就是你的 IM 是个薛定谔 IM ，能通知领东西，能发信息，就是不能发位置。

102 天前

回复了 Qinnn 创建的主题 › 程序员 › Anthropic Claude Sonnet 4 上下文 token 数提升至 100 万，提升了五倍

在其他因素均不变的情况下肯定有影响，因为更大的上下文，逻辑链路就更长，最优解的统计学优势就更不明显。
但反之，上下文的质量如果很高，那么结果应该会更好。

相当于是降低了下限，提高了上限。

102 天前

回复了 rcj6056 创建的主题 › 程序员 › 关于占座位小程序的问题请教

@MrDream 找人就更可笑了。
现实中，你是如何知晓你的亲朋的位置的呢？是你的家人每到一个地方都扫一个二维码“占座”吗？

102 天前

回复了 rcj6056 创建的主题 › 程序员 › 关于占座位小程序的问题请教

比如，你能不能接受恶意占位？
能不能接受爽约？
可不可以预约？
如何提示既有的使用人已经到期？
如何确保预约人坐在正确的座位上？

102 天前

回复了 rcj6056 创建的主题 › 程序员 › 关于占座位小程序的问题请教

这个产品设计真的奇葩。
占座小程序的最终服务人群是还没到场的人，还是已经到场的人？

如果是还没到场的人，已经占座的人有什么义务扫码告知？
如果服务的是到场的人，人拿书、电脑就直接占了，有什么扫码的必要？

除非改成全线上。也就是工位只接受远程预约。而且工位自身要有占用标识
那这个成本就高了，不是“查询位置、扫码占位”这么简单了。

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

❮

❯