V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  SuperDaniel313  ›  全部回复第 1 页 / 共 13 页
回复总数  250
1  2  3  4  5  6  7  8  9  10 ... 13  
18 小时 50 分钟前
回复了 SuperDaniel313 创建的主题 产品经理茶话会 产品经理学习资料推荐
@bennyfu #5 来来来,最近刚好很空,加个 V https://i.imgur.com/duWRpIu.png ,c3VwZXJkYW5pZWxfY24=
@blushyes #9 https://i.imgur.com/duWRpIu.png 我只想借机吐槽 mac 的 UI 是依托答辩
咋说呢,Tdesign 看习惯了,感受上是一种“干练”、“够硬”,毕竟是腾讯为 B 端设计的风格,大量的后台业务都用这个 UI ,追求操作上的高效和信息传达准确。

Liquid Glass 的大圆角看起来很不“干脆”,不够“锐”。mac 更新之后,给我的感受真的很差劲。访达和启动台的 UI 看到真的想吐,各种为了大圆角过度出来的空间,显得臃肿、多余。我还是放大屏上看都嫌弃,14 寸小屏看了一眼,也拉跨。难以想象这种垃圾也能正式发布,苹果真的日落西山了。

回到主题,op 如果追求工具属性,建议换回或者换到 B 端风格,C 端应该在 UI 上好好打磨,B 端应该在 UE 上花点心思。比如直接抄一版 vscode 布局,让用户平滑过度过来。现在都是套壳,用户习惯已经养成了,搞新逻辑、新体验只会增加用户心智负担,没啥必要。

没仔细看,但有几点可以说说:
1. 没有 IDE 会在“编辑器设置”里放一个“会员与额度”,这个是账户下面的元素,和编辑器设置无关;
2. 顶部的 header 宽度不够我看着难受,不过可能是特色设计,因人而异;
3. 一般来说,会员权益是放在套餐下面的,你是什么等级的会员,享有什么样的会员权益;
4. 登录才能查看的数据,没登录就别放出来;
5. 每日签到的权益要放到最顶上,不然人家看到付费之后就不会再往下去看下面还有什么了;
6. 扣费的逻辑别放这么显眼,没对比价格,不知你的优势在哪里,但我看倍率能到 1:15 ,这个价格能对得起这份差距吗?
7. Pro 会员既然是推荐,那要把优势打出来,我喜欢去山姆是因为虽然大包装,但山姆会给我标小包单价,我一比就发现还是山姆划算,占便宜的心态让我总是囤大包装,用不完又浪费,但我就是忍不住,有便宜谁能忍住不占啊;
8. 右上角的“AI 未登录”,如果不是业务特色,那应该是笔误,看看有啥更好的文案没;
9. 以上是一个被淘汰的产品职业病犯了,看到啥就想说啥,没有梳理,有用的话欢迎采纳,看着聒噪的话,无视即可;
8 天前
回复了 kirieievk 创建的主题 Twitter x 怎么可以自动发帖
试试 RPA 吗?
自己手搓个脚本跑,模拟真人操作
https://github.com/SuperDaniel-cn/anbao-scripts
11 天前
回复了 HuPu 创建的主题 问与答 mac 上什么办法小红书双开?
试试我的项目吗?
支持多账号管理,还能一键发布多平台视频,也可以自己写脚本玩

https://docs.superdaniel.cn/
白嫖赛博菩萨 cloudflare 呀,静态第一首选;
绑卡之后可以白嫖 R2 对象存储,免流量费的;
page 部署个静态站就行,如果要逻辑,用 worker 就够了,非大陆效果比大陆好多了。
大陆也能用,至少不花钱就能用。
巧了,这不就是我么 https://i.imgur.com/duWRpIu.png
稍微复杂点的也能写,不用洗洗睡

产品经理靠 AI 用 Rust+Bevy ECS 搓出了一个开箱即用、跨平台、高并发桌面自动化工具,能一键发布多平台视频
https://www.v2ex.com/t/1171132
试试我的应用吗?

https://github.com/SuperDaniel-cn/anbao-scripts
https://i.imgur.com/io2SM1h.png 框架搭好了,要脚本的话可以自己往上加,目前支持的平台有:Bilibili 、抖音、快手、小红书、视频号。
@xiaomibaobao #15 🥳感谢支持,已经安排上了,8 万次额度到位
@codehz #13 https://i.imgur.com/duWRpIu.png 哈哈,是的,对我的项目来说,资源没有机制重要,没有渲染,没有大量 IO ,定位就是个人桌面自动化的一个容器,并不需要考虑资源问题,反而事件驱动对我来说很舒服。

再专业的我也不懂了,没深入学习过。这些都是干中学,AI 给我推,我看合适就缝合上去。从传统架构倒腾到 ECS 也非常有趣,上 ECS 之前原来那套手搓并发也能用,但就是有点怕,老觉得哪里会炸 https://i.imgur.com/Iy0taMy.png
30 天前
回复了 chrischris 创建的主题 问与答 自媒体发展真诚请教
@chrischris #28 好几个月过去了,哥们发财了吗?要试试我刚出炉的自媒体工具吗? https://i.imgur.com/duWRpIu.png https://www.v2ex.com/t/1171132
@ciovwx #11 🥳感谢支持,已经安排上了,9 万次额度到位
@ccpp132 #3 游戏何尝不是软件,游戏可以看作并发要求高到极致的软件。
刚开始 Gemini 给我推荐的时候,我感觉也是在扯犊子,但真正去了解 ECS 的架构之后,我才发现 Gemini 是真的牛逼。这种高并发的架构抽象出来看,是一个为高并发而生的、数据驱动的、可并行化的事件调度框架,只是因为游戏引擎而出名,但不止于游戏。感兴趣的话可以多和 Gemini 交流一下。项目写完我已经忘了当时为何觉得 ECS 牛逼了 https://i.imgur.com/ZveiiGy.png 但 ecs 用起来,比我自己手搓的并发机制确实牛逼很多,当时我也是问 Gemini 有没有现成的并发库,然后逐步了解过去的。
@chunhuitrue #6 mcp 的方案我有看过,从商业项目角度来看:不能开箱即用、使用门槛高、不能并发,这三个问题中的前两个没解决的话,很难规模化。
@livib #4
这个过程很难用三言两语就讲明白,有机会再开篇幅单独分享吧。不过之前在别的帖子里有过讨论,你可以看看。现阶段 AI 确实有被吹过头,让人误以为只需要一句话丢给 AI 就能得到想要的结果。以我这些年干产品的经历来看,能把需求描述清楚是一项非常稀缺的能力,这个能力可以用 AI 进行测试。

总结一句话:当你觉得傻逼老板一句话下来就想当场把项目直接端上来的时候,AI 何尝不是这样看待你的需求

---
原贴: https://www.v2ex.com/t/1167888

LLM 不是烧 token 的问题,是稳定性的问题。
如果你是想 LLM 能像实习生一样,多教几次就能熟练、稳定的执行指令,现阶段不可能啊。LLM 参与自动化任务本身就是最大的不稳定因素,这和自动化要求的稳定相违背的,更别提高效了。

LLM 要反复试错才能解决问题,这在编码领域已经充分验证了呀,一句话丢给 LLM ,等会来看项目已经是一坨屎了,只有时刻盯着才能把项目写出来。只能提效,如果稳定性稍差,反而降效。

业务场景如果要引入自动化往往已经是稳定的业务流,在追求高效了。这不是探索性质的任务。

比如你当前的困境是网页元素变动导致脚本失效,想引入 LLM 来做代替。

这个方案我尝试过,纯脚本或者纯 LLM 都有各自缺点,混合型是不错的路子,比如脚本无法继续的时候,调 LLM 出来救场。LLM 此时的作用是拟人进行高级决策判断。想法蛮好的,但只要用过几次就知道,理想和现实的差距还是蛮大的,最终我放弃集成了。

业务问题就用业务方式解决,技术还没到这个阶段的时候,引入这种不完善的技术反而让业务开展充满阻碍。

LLM 在当下这个场景里,快速编码是更具备价值的能力,你的脚本失效,如果往常需要更多时间来编码,现在用 LLM 只需要自己定位问题,想好解决思路,然后让 LLM 编码,你来快速交付。这样就能更大程度的发挥业务价值,否则 LLM 真能代替你了,那下岗也不远了。
@Armyh #5 感谢支持,已经为你的账户增加 10 万次运行额度了哦
@laminux29 #2 办公室斗争我不感兴趣;

“可行性最高,且花费最小的方法” 解决了什么问题呢?听下来,监控支付健康程度也没什么意义,或者有你们内部意义?或者就是为了监控而监控?

除非想白嫖员工,不然花钱买个微信更快呀。为啥工作的事情一定要用员工自己的私人资产来解决呢?

还有一个,技术上自动化跑软件不是问题,但定时付款 1 分,我想微信的风控应该不会呆到这种地步能让人这样来自动化吧?异常行为我记得会被微信踢下线的。

技术解决不了所有问题,特别是人的问题
这种纯业务问题何苦用技术来解决,这个时候就该找老大,让老大去向上反馈,让商务来沟通;
如果你就是老大就去劝老板考虑这个合作关系;
如果你们公司非人家不可,那就临时安排人,记录支付失败的客诉,然后去找对方诉苦,看看能不能用事实打动人家来改进,顺便也让老板知道业务真实数据;

监控支付成功率能让对方改动吗?
还是能通过技术手段让客户在这个方式不可用的时候避开这个支付渠道?

从业务的角度看,没理由这样监控支付健康状况啊,如果能改变,那应该抓紧变,如果不能变,那知道这个渠道会失败也没意义呀。
@Sh1xin #8 LLM 不是烧 token 的问题,是稳定性的问题。
如果你是想 LLM 能像实习生一样,多教几次就能熟练、稳定的执行指令,现阶段不可能啊。LLM 参与自动化任务本身就是最大的不稳定因素,这和自动化要求的稳定相违背的,更别提高效了。

LLM 要反复试错才能解决问题,这在编码领域已经充分验证了呀,一句话丢给 LLM ,等会来看项目已经是一坨屎了,只有时刻盯着才能把项目写出来。只能提效,如果稳定性稍差,反而降效。

业务场景如果要引入自动化往往已经是稳定的业务流,在追求高效了。这不是探索性质的任务。

比如你当前的困境是网页元素变动导致脚本失效,想引入 LLM 来做代替。

这个方案我尝试过,纯脚本或者纯 LLM 都有各自缺点,混合型是不错的路子,比如脚本无法继续的时候,调 LLM 出来救场。LLM 此时的作用是拟人进行高级决策判断。想法蛮好的,但只要用过几次就知道,理想和现实的差距还是蛮大的,最终我放弃集成了。

业务问题就用业务方式解决,技术还没到这个阶段的时候,引入这种不完善的技术反而让业务开展充满阻碍。

LLM 在当下这个场景里,快速编码是更具备价值的能力,你的脚本失效,如果往常需要更多时间来编码,现在用 LLM 只需要自己定位问题,想好解决思路,然后让 LLM 编码,你来快速交付。这样就能更大程度的发挥业务价值,否则 LLM 真能代替你了,那下岗也不远了。
https://github.com/SuperDaniel-cn/anbao-scripts

来试试吗?我刚发的版 https://i.imgur.com/duWRpIu.png
MCP 我尝试集成过了,拿来玩儿是没问题,但是想拿来干活基本上不可能。自动化脚本的一大特点就是要求稳定性,AI 这个阶段谈稳定性太早了。
换一个思路,用 AI 来编码,然后快速出脚本,这样稳定性和效率就可以兼得了。
1  2  3  4  5  6  7  8  9  10 ... 13  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   5929 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 02:34 · PVG 10:34 · LAX 18:34 · JFK 21:34
♥ Do have faith in what you're doing.