SuperDaniel313 最近的时间轴更新 SuperDaniel313 最近的时间轴更新 |
SuperDaniel313吐槽是表，解局是里。职场咨询，找我。 V2EX 第 369668 号会员，加入于 2018-12-11 16:54:05 +08:00今日活跃度排名 265 |
github.com/SuperDaniel-cn/anbao-scripts
| 产品经理靠 AI 用 Rust+Bevy ECS 搓出了一个开箱即用、跨平台、高并发桌面自动化工具，能一键发布多平台视频
1 分享创造 • SuperDaniel313 • 11 小时 45 分钟前 • 最后回复来自 SuperDaniel313
|
12 |
| 婴儿好物推荐——奶爸们都看过来 生活 • SuperDaniel313 • 174 天前 • 最后回复来自 SuperDaniel313 | 30 |
| 产品经理学习资料推荐 产品经理茶话会 • SuperDaniel313 • 96 天前 • 最后回复来自 SuperDaniel313 | 4 |
SuperDaniel313 最近回复了
11 小时 35 分钟前 回复了 chrischris 创建的主题 › 问与答 › 自媒体发展真诚请教 |
11 小时 45 分钟前 回复了 SuperDaniel313 创建的主题 › 分享创造 › 产品经理靠 AI 用 Rust+Bevy ECS 搓出了一个开箱即用、跨平台、高并发桌面自动化工具，能一键发布多平台视频 |
@ciovwx #11 🥳感谢支持，已经安排上了，9 万次额度到位
15 小时 42 分钟前 回复了 SuperDaniel313 创建的主题 › 分享创造 › 产品经理靠 AI 用 Rust+Bevy ECS 搓出了一个开箱即用、跨平台、高并发桌面自动化工具，能一键发布多平台视频 |
@ccpp132 #3 游戏何尝不是软件，游戏可以看作并发要求高到极致的软件。
刚开始 Gemini 给我推荐的时候，我感觉也是在扯犊子，但真正去了解 ECS 的架构之后，我才发现 Gemini 是真的牛逼。这种高并发的架构抽象出来看，是一个为高并发而生的、数据驱动的、可并行化的事件调度框架，只是因为游戏引擎而出名，但不止于游戏。感兴趣的话可以多和 Gemini 交流一下。项目写完我已经忘了当时为何觉得 ECS 牛逼了
但 ecs 用起来，比我自己手搓的并发机制确实牛逼很多，当时我也是问 Gemini 有没有现成的并发库，然后逐步了解过去的。
刚开始 Gemini 给我推荐的时候，我感觉也是在扯犊子，但真正去了解 ECS 的架构之后，我才发现 Gemini 是真的牛逼。这种高并发的架构抽象出来看，是一个为高并发而生的、数据驱动的、可并行化的事件调度框架，只是因为游戏引擎而出名，但不止于游戏。感兴趣的话可以多和 Gemini 交流一下。项目写完我已经忘了当时为何觉得 ECS 牛逼了
但 ecs 用起来，比我自己手搓的并发机制确实牛逼很多，当时我也是问 Gemini 有没有现成的并发库，然后逐步了解过去的。15 小时 48 分钟前 回复了 SuperDaniel313 创建的主题 › 分享创造 › 产品经理靠 AI 用 Rust+Bevy ECS 搓出了一个开箱即用、跨平台、高并发桌面自动化工具，能一键发布多平台视频 |
@chunhuitrue #6 mcp 的方案我有看过，从商业项目角度来看：不能开箱即用、使用门槛高、不能并发，这三个问题中的前两个没解决的话，很难规模化。
15 小时 51 分钟前 回复了 SuperDaniel313 创建的主题 › 分享创造 › 产品经理靠 AI 用 Rust+Bevy ECS 搓出了一个开箱即用、跨平台、高并发桌面自动化工具，能一键发布多平台视频 |
@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 真能代替你了，那下岗也不远了。
这个过程很难用三言两语就讲明白，有机会再开篇幅单独分享吧。不过之前在别的帖子里有过讨论，你可以看看。现阶段 AI 确实有被吹过头，让人误以为只需要一句话丢给 AI 就能得到想要的结果。以我这些年干产品的经历来看，能把需求描述清楚是一项非常稀缺的能力，这个能力可以用 AI 进行测试。
总结一句话：当你觉得傻逼老板一句话下来就想当场把项目直接端上来的时候，AI 何尝不是这样看待你的需求
---
原贴： https://www.v2ex.com/t/1167888
LLM 不是烧 token 的问题，是稳定性的问题。
如果你是想 LLM 能像实习生一样，多教几次就能熟练、稳定的执行指令，现阶段不可能啊。LLM 参与自动化任务本身就是最大的不稳定因素，这和自动化要求的稳定相违背的，更别提高效了。
LLM 要反复试错才能解决问题，这在编码领域已经充分验证了呀，一句话丢给 LLM ，等会来看项目已经是一坨屎了，只有时刻盯着才能把项目写出来。只能提效，如果稳定性稍差，反而降效。
业务场景如果要引入自动化往往已经是稳定的业务流，在追求高效了。这不是探索性质的任务。
比如你当前的困境是网页元素变动导致脚本失效，想引入 LLM 来做代替。
这个方案我尝试过，纯脚本或者纯 LLM 都有各自缺点，混合型是不错的路子，比如脚本无法继续的时候，调 LLM 出来救场。LLM 此时的作用是拟人进行高级决策判断。想法蛮好的，但只要用过几次就知道，理想和现实的差距还是蛮大的，最终我放弃集成了。
业务问题就用业务方式解决，技术还没到这个阶段的时候，引入这种不完善的技术反而让业务开展充满阻碍。
LLM 在当下这个场景里，快速编码是更具备价值的能力，你的脚本失效，如果往常需要更多时间来编码，现在用 LLM 只需要自己定位问题，想好解决思路，然后让 LLM 编码，你来快速交付。这样就能更大程度的发挥业务价值，否则 LLM 真能代替你了，那下岗也不远了。
16 小时 1 分钟前 回复了 SuperDaniel313 创建的主题 › 分享创造 › 产品经理靠 AI 用 Rust+Bevy ECS 搓出了一个开箱即用、跨平台、高并发桌面自动化工具，能一键发布多平台视频 |
@Armyh #5 感谢支持，已经为你的账户增加 10 万次运行额度了哦
13 天前 回复了 laminux29 创建的主题 › 微信 › 请问微信小程序的支付功能，如何监控可用性？ |
@laminux29 #2 办公室斗争我不感兴趣；
“可行性最高，且花费最小的方法” 解决了什么问题呢？听下来，监控支付健康程度也没什么意义，或者有你们内部意义？或者就是为了监控而监控？
除非想白嫖员工，不然花钱买个微信更快呀。为啥工作的事情一定要用员工自己的私人资产来解决呢？
还有一个，技术上自动化跑软件不是问题，但定时付款 1 分，我想微信的风控应该不会呆到这种地步能让人这样来自动化吧？异常行为我记得会被微信踢下线的。
技术解决不了所有问题，特别是人的问题
“可行性最高，且花费最小的方法” 解决了什么问题呢？听下来，监控支付健康程度也没什么意义，或者有你们内部意义？或者就是为了监控而监控？
除非想白嫖员工，不然花钱买个微信更快呀。为啥工作的事情一定要用员工自己的私人资产来解决呢？
还有一个，技术上自动化跑软件不是问题，但定时付款 1 分，我想微信的风控应该不会呆到这种地步能让人这样来自动化吧？异常行为我记得会被微信踢下线的。
技术解决不了所有问题，特别是人的问题
13 天前 回复了 laminux29 创建的主题 › 微信 › 请问微信小程序的支付功能，如何监控可用性？ |
这种纯业务问题何苦用技术来解决，这个时候就该找老大，让老大去向上反馈，让商务来沟通；
如果你就是老大就去劝老板考虑这个合作关系；
如果你们公司非人家不可，那就临时安排人，记录支付失败的客诉，然后去找对方诉苦，看看能不能用事实打动人家来改进，顺便也让老板知道业务真实数据；
监控支付成功率能让对方改动吗？
还是能通过技术手段让客户在这个方式不可用的时候避开这个支付渠道？
从业务的角度看，没理由这样监控支付健康状况啊，如果能改变，那应该抓紧变，如果不能变，那知道这个渠道会失败也没意义呀。
如果你就是老大就去劝老板考虑这个合作关系；
如果你们公司非人家不可，那就临时安排人，记录支付失败的客诉，然后去找对方诉苦，看看能不能用事实打动人家来改进，顺便也让老板知道业务真实数据；
监控支付成功率能让对方改动吗？
还是能通过技术手段让客户在这个方式不可用的时候避开这个支付渠道？
从业务的角度看，没理由这样监控支付健康状况啊，如果能改变，那应该抓紧变，如果不能变，那知道这个渠道会失败也没意义呀。
15 天前 回复了 Sh1xin 创建的主题 › 程序员 › 各位有使用 LLM 操作浏览器完成业务自动化的 MCP 方案吗 |
@Sh1xin #8 LLM 不是烧 token 的问题，是稳定性的问题。
如果你是想 LLM 能像实习生一样，多教几次就能熟练、稳定的执行指令，现阶段不可能啊。LLM 参与自动化任务本身就是最大的不稳定因素，这和自动化要求的稳定相违背的，更别提高效了。
LLM 要反复试错才能解决问题，这在编码领域已经充分验证了呀，一句话丢给 LLM ，等会来看项目已经是一坨屎了，只有时刻盯着才能把项目写出来。只能提效，如果稳定性稍差，反而降效。
业务场景如果要引入自动化往往已经是稳定的业务流，在追求高效了。这不是探索性质的任务。
比如你当前的困境是网页元素变动导致脚本失效，想引入 LLM 来做代替。
这个方案我尝试过，纯脚本或者纯 LLM 都有各自缺点，混合型是不错的路子，比如脚本无法继续的时候，调 LLM 出来救场。LLM 此时的作用是拟人进行高级决策判断。想法蛮好的，但只要用过几次就知道，理想和现实的差距还是蛮大的，最终我放弃集成了。
业务问题就用业务方式解决，技术还没到这个阶段的时候，引入这种不完善的技术反而让业务开展充满阻碍。
LLM 在当下这个场景里，快速编码是更具备价值的能力，你的脚本失效，如果往常需要更多时间来编码，现在用 LLM 只需要自己定位问题，想好解决思路，然后让 LLM 编码，你来快速交付。这样就能更大程度的发挥业务价值，否则 LLM 真能代替你了，那下岗也不远了。
如果你是想 LLM 能像实习生一样，多教几次就能熟练、稳定的执行指令，现阶段不可能啊。LLM 参与自动化任务本身就是最大的不稳定因素，这和自动化要求的稳定相违背的，更别提高效了。
LLM 要反复试错才能解决问题，这在编码领域已经充分验证了呀，一句话丢给 LLM ，等会来看项目已经是一坨屎了，只有时刻盯着才能把项目写出来。只能提效，如果稳定性稍差，反而降效。
业务场景如果要引入自动化往往已经是稳定的业务流，在追求高效了。这不是探索性质的任务。
比如你当前的困境是网页元素变动导致脚本失效，想引入 LLM 来做代替。
这个方案我尝试过，纯脚本或者纯 LLM 都有各自缺点，混合型是不错的路子，比如脚本无法继续的时候，调 LLM 出来救场。LLM 此时的作用是拟人进行高级决策判断。想法蛮好的，但只要用过几次就知道，理想和现实的差距还是蛮大的，最终我放弃集成了。
业务问题就用业务方式解决，技术还没到这个阶段的时候，引入这种不完善的技术反而让业务开展充满阻碍。
LLM 在当下这个场景里，快速编码是更具备价值的能力，你的脚本失效，如果往常需要更多时间来编码，现在用 LLM 只需要自己定位问题，想好解决思路，然后让 LLM 编码，你来快速交付。这样就能更大程度的发挥业务价值，否则 LLM 真能代替你了，那下岗也不远了。
15 天前 回复了 Sh1xin 创建的主题 › 程序员 › 各位有使用 LLM 操作浏览器完成业务自动化的 MCP 方案吗 |
https://github.com/SuperDaniel-cn/anbao-scripts
来试试吗？我刚发的版
MCP 我尝试集成过了，拿来玩儿是没问题，但是想拿来干活基本上不可能。自动化脚本的一大特点就是要求稳定性，AI 这个阶段谈稳定性太早了。
换一个思路，用 AI 来编码，然后快速出脚本，这样稳定性和效率就可以兼得了。
来试试吗？我刚发的版
MCP 我尝试集成过了，拿来玩儿是没问题，但是想拿来干活基本上不可能。自动化脚本的一大特点就是要求稳定性，AI 这个阶段谈稳定性太早了。
换一个思路，用 AI 来编码，然后快速出脚本，这样稳定性和效率就可以兼得了。
Select Language