- 主题:我觉得各位马龙真的要考虑下自己的饭碗了
【 在 lvsoft 的大作中提到: 】
: 我的建议,这个世界上只有一个ai,叫gpt4。
: 其他的都没有一用的价值,包括gpt3.5在内。(除非你的目的是找人聊天逗你玩)
: 然后,即使是gpt4,也有一段适应的过程,要掌握它的正确的使用方法。我一开始用gpt4也是很看不起的,觉得这货有啥用,给我吐一堆车轱辘话,而且它说的我都知道,浪费我时间。直到后来有人教了我正确的使用姿势,我现在对gpt4的观点是彻底改观的。
: ...................
软件工程还是毕竟复杂, 工程问题, 法律法规问题。
首先, 是工程问题, 你以为一个码农是吭哧吭哧把协议全部搞懂了,然后一行一行代码去coding,
显然, 这是一个外行的一厢情愿, 正常的工程流程也是自顶向下, 可行性分析, 架构分析,
效率和实现成本, 是否使用开源。 在法律法规层面还需要有法律基础, 尤其是开源代码的使用,
是否会引入法律问题, 别等着收了几千万的律师函才抓瞎。
因此, 你讨论的实现环节, 不过是工程过程中的一小部分,
即使是这一小部分的劳动成果, 还需要资深的程序员和架构师去评估。
因此, chatgpt在这个过程, 能够成为一个不错的助手是没有问题的, 但终究还是一个没有灵魂的工具。
当然, 替代低端的码工是没有什么悬念。
当然, 也不能排除有一天, 有专用的gpt出现, 只要给它提出各种软件工程的限制, 它依然能寻找到一个项目最优解。但软件渗透到各个行业的方方面面, 这么复杂的东西, 目前也还是离目标很远。
--
修改:poggy FROM 124.126.3.*
FROM 124.126.3.*
还是会提效很多,原来需要10个人,过两年可能只需要3个人就够了;现在写前端页面基本能写出来,就是自己调布局之类的;写常见的功能,增删改查、测试用例应该也没问题
【 在 z16166 的大作中提到: 】
: 所以你咋得出码农要被chatgpt搞掉饭碗的结论
: 代码是个精确的东西,稍微错点,就得不到正确的结果
: 现阶段chatgpt生成的代码有不少地方还需要码农去发现并纠正,或者指示chagpt自己纠正/逐步求精,而且有些东西它纠正不了就瞎说
: ...................
--
FROM 111.194.209.*
你在说啥?法律法规问题跟软件工程,跟码农有个屁的关系?你是码农么基本的逻辑都不讲?一个工程当然是复杂的,软件工程只是其中的一部分。你把软件工程泛化到整个工程来论证复杂性,那不如聊聊怎么招人怎么管人怎么搞钱好了,毕竟这些也都是会严重影响工程的支撑因素。
其次,你以为我对法律问题缺乏理解?早在十几年前我就用我们在intel里开发的系统中遇到的开源协议引起的法律问题,启发和指导了一个法律系的学生的硕士毕业论文。别觉得就你看到了这一点好不好。
最后,你是觉得这些问题ai搞不定还是咋的?ai做不了架构设计?ai不能提出法律建议,不能站在法律的角度去做开源模块的选型?别搞笑了行不。ai的问题是目前它的智力还不太够,但它可是什么都懂,论知识面它比谁都要资深。
【 在 poggy 的大作中提到: 】
:
: 软件工程还是毕竟复杂, 工程问题, 法律法规问题。
: 首先, 是工程问题, 你以为一个码农是吭哧吭哧把协议全部搞懂了,然后一行一行代码去coding,
: ...................
--
修改:lvsoft FROM 113.111.168.*
FROM 113.111.168.*
不要冤枉他,他不是不懂装懂,他是真的不知道自己会不会,答的对不对,甚至他都没有对错这个概念
【 在 chylli 的大作中提到: 】
: chatgpt最大的问题是它不会他不说不会,他是乱答一气
:
--
FROM 1.81.222.*
【 在 lvsoft 的大作中提到: 】
: 你在说啥?法律法规问题跟软件工程,跟码农有个屁的关系?你是码农么基本的逻辑都不讲?一个工程当然是复杂的,软件工程只是其中的一部分。你把软件工程泛化到整个工程来论证复杂性,那不如聊聊怎么招人怎么管人怎么搞钱好了,毕竟这些也都是会严重影响工程的支撑因素。
: 其次,你以为我对法律问题缺乏理解?早在十几年前我就用我们在intel里开发的系统中遇到的开源协议引起的法律问题,启发和指导了一个法律系的学生的硕士毕业论文。别觉得就你看到了这一点好不好。
: 最后,你是觉得这些问题ai搞不定还是咋的?ai做不了架构设计?ai不能提出法律建议,不能站在法律的角度去做开源模块的选型?别搞笑了行不。ai的问题是目前它的智力还不太够,但它可是什么都懂,论知识面它比谁都要资深。
: ...................
其实, 这里说复杂的原因是, 不是AI能不能处理复杂,
而是另一个原因, AI不知道自己能不能处理复杂。
面对分烦复杂的问题, AI显然能够一通答, 问题是解决的质量本身还得需要人评判。
举个例子, 以前给CPU写程序也是个很麻烦复杂的事情,
需要操控CPU里面一堆寄存器单元, 然后还要处理堆栈的压入,弹出,
控制和移动CPU指示代码和数据的指针, 出一个小差错, CPU就挂了, 到了后来,
编译器横空出世,那些计算机程序员一大堆的工作似乎一下子被编译器给取代了。
可是, 从后面的发展来看程序员对CPU越来越透明了, 出现了一大堆高级语言程序员,
他们甚至不知道, 寄存器是何物, 但不影响他们做一个程序员写代码让CPU工作。
而编译器的发展, 也并没让编程工作萎缩, 反倒随着程序语言的复杂度和能力的提升,
创造出来数以万计的更多需求, 使得计算机不再局限于数学物理和工程计算, 反倒渗透
到了各个行业的方方面面。
因此, 我的观点是AI, 就像只能的编译器, 只能让程序员们提升处理复杂问题的能力,
从而让计算机的应用提升一个更高的台阶, 需求只会随着计算机程序的处理能力爆发性增长,
对码农的需求只会多, 不会少, 只不过, 码农的工作重心也会发生变化,
就像初代放弃CPU指令, 寄存器操控的码农,更多的要去关注复杂度本身。
--
FROM 124.126.3.*
挖个坟,我觉得Claude 3.5比GPT4生成代码能力强多了
【 在 lvsoft 的大作中提到: 】
: 我的建议,这个世界上只有一个ai,叫gpt4。
: 其他的都没有一用的价值,包括gpt3.5在内。(除非你的目的是找人聊天逗你玩)
: 然后,即使是gpt4,也有一段适应的过程,要掌握它的正确的使用方法。我一开始用gpt4也是很看不起的,觉得这货有啥用,给我吐一堆车轱辘话,而且它说的我都知道,浪费我时间。直到后来有人教了我正确的使用姿势,我现在对gpt4的观点是彻底改观的。
: ...................
--
FROM 114.248.219.193
确实,只要ai的理解能力到了一定程度,把需求转换成面向人的代码就多此一举了
--
FROM 120.245.130.*
大专生和二本经常这样。
我们的大专和二本经常百度到csdn,复制一段代码,直接贴到ide里,然后编译,如果不通过就继续搜索、粘贴、编译,根本不会去看那段代码干了啥,更不要说看懂和修改了。
不排除这样水平的码农天天认为自己被替代。
【 在 z16166 的大作中提到: 】
: 所以你咋得出码农要被chatgpt搞掉饭碗的结论
: 代码是个精确的东西,稍微错点,就得不到正确的结果
: 现阶段chatgpt生成的代码有不少地方还需要码农去发现并纠正,或者指示chagpt自己纠正/逐步求精,而且有些东西它纠正不了就瞎说
: ...................
--
FROM 112.96.54.*
试试4o,不一样的感受。
【 在 z16166 的大作中提到: 】
:
: 一看你就是天天不用chagpt的
:
: 我这两天让chatgpt 3.5写了几个pfx证书相关的windows代码,经常是编译不过去,或者参数不正确,或者瞎扯,得手动改
#发自zSMTH@BKL-AL20
--
FROM 112.64.61.*
贴个之前用coze写的代码的例子(gpt4),各位可以试试找找它的bug在哪里(人工搞不定的话,可以喂给AI找bug试试)
我下的提示指令是两句话:
1、可否实现一个C++模板类,该类实现LRU缓存的功能,能指定最大缓存的消息个数,以及需要淘汰的时间间隔TTL。
2、请给这个类加上读写锁。
#include <unordered_map>
#include <chrono>
#include <utility>
#include <shared_mutex>
template<typename Key, typename Value>
class LRUCache {
public:
LRUCache(size_t max_size, long long ttl) : _max_size(max_size), _ttl(ttl) {}
void put(const Key& key, const Value& value) {
std::unique_lock<std::shared_timed_mutex> lock(_mutex);
auto now = std::chrono::system_clock::now();
auto item = _cache.find(key);
if (item != _cache.end()) {
_lru_list.erase(item->second.second);
_cache.erase(item);
}
_lru_list.push_front(key);
_cache[key] = {std::make_pair(value, now), _lru_list.begin()};
if (_cache.size() > _max_size) {
auto last = _lru_list.end();
last--;
_cache.erase(*last);
_lru_list.pop_back();
}
remove_expired(now);
}
std::pair<bool, Value> get(const Key& key) {
std::shared_lock<std::shared_timed_mutex> lock(_mutex);
auto item = _cache.find(key);
if (item == _cache.end()) {
return std::make_pair(false, Value());
}
auto now = std::chrono::system_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::seconds>(now - item->second.first.second).count();
if (duration > _ttl) {
lock.unlock(); // Need to unlock here since remove_expired() requires unique_lock
std::unique_lock<std::shared_timed_mutex> ulock(_mutex);
_lru_list.erase(item->second.second);
_cache.erase(item);
return std::make_pair(false, Value());
}
// To modify the list, we need to upgrade to unique lock
lock.unlock();
std::unique_lock<std::shared_timed_mutex> ulock(_mutex);
_lru_list.erase(item->second.second);
_lru_list.push_front(key);
item->second.second = _lru_list.begin();
return std::make_pair(true, item->second.first.first);
}
private:
size_t _max_size;
long long _ttl; // seconds
std::list<Key> _lru_list;
std::unordered_map<Key, std::pair<std::pair<Value, std::chrono::time_point<std::chrono::system_clock>>, typename std::list<Key>::iterator>> _cache;
mutable std::shared_timed_mutex _mutex;
void remove_expired(const std::chrono::time_point<std::chrono::system_clock>& now) {
for (auto it = _lru_list.rbegin(); it != _lru_list.rend();) {
auto cache_it = _cache.find(*it);
if (cache_it != _cache.end()) {
auto duration = std::chrono::duration_cast<std::chrono::seconds>(now - cache_it->second.first.second).count();
if (duration > _ttl) {
_cache.erase(cache_it);
it = std::list<Key>::reverse_iterator(_lru_list.erase(std::next(it).base()));
} else {
++it;
}
} else {
++it;
}
}
}
};
【 在 misskiss 的大作中提到: 】
: 试试4o,不一样的感受。
:
: #发自zSMTH@BKL-AL20
--
FROM 221.218.161.*