ChatGPT开始威胁程序员的核心能力了！

Posted 2023-04-01 码农翻身

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了ChatGPT开始威胁程序员的核心能力了！相关的知识，希望对你有一定的参考价值。

ChatGPT是程序员的好帮手？还是要干掉程序员？

我觉得不仅要看它生成代码的能力，更关键的是要看它是否具备强大的设计能力。

设计能力有两个层面，一个是高层的，例如架构设计，系统设计。

一个是相对低层的设计能力，主要设计具体的类和接口。

今天我们看看它在这两个方面分别表现如何。

由于ChatGPT的回答特别啰嗦，我会删除一些细节，只保留重要部分。

出于公司保密的原因，没法用真实项目，只能用书籍中公开的案例来考考它。

架构设计

这里我使用的案例是客服工单系统，是从一本书《从程序员到架构师》中提取出来的，这本书有很多实战案例，顺便向大家推荐一下。

客服工单系统的大概需求是这样：

有个客服系统，用的mysql数据库，每年产生的工单有3000多万条，每个工单会有5~6次操作，这些操作也要记录下来，这样每年就会有超过1.5亿条操作记录。

现在客服打开系统查看工单的时候，速度非常慢，10秒才能打开，现在对SQL语句，索引等已经优化到了极致，无法再继续提升。

现在系统性能已经严重影响了客服的处理效率，客户要求一周之内解决这个问题，时间很短。

经过分析业务流程发现，工单如果处理完成，就会增加一个状态“关闭”，这样的工单，一年都打开不了几次。

团队没有用过数据库分区，一周内没有任何把握搞定，就放弃了数据库分区的方案。

对于这个问题，书中的解决方案是“冷热分离”，日常操作“热数据库”，把“关闭”的工单移入新的“冷数据库”，但是在数据冷热分离过程中，需要处理数据一致性问题。

把这个需求抛给GPT-4，看它如何回答。

GPT-4：在这种情况下，我建议采用以下两种方法来解决性能问题：

数据库归档：由于大部分已关闭的工单基本上不再需要访问，可以将这些工单数据从主数据库中移动到一个归档数据库中。这样，主数据库的大小将大大减小，从而提高查询速度。归档数据库可以定期（如每月或每季度）更新，将已关闭的工单移动到归档数据库中......

具体操作步骤如下：

a. 创建一个新的MySQL数据库，用于存储归档数据。

b. 编写一个脚本，定期将已关闭的工单及其相关操作记录从主数据库移动到归档数据库，并确保数据一致性。

c. 修改客服系统，使其默认仅查询主数据库中的未归档数据。

d. 提供一个单独的界面或工具，供客服人员在需要时查询归档数据库中的数据。

缓存：...略...

不错，它一下子就抓住了重点，给出了数据库归档的方案，还有具体的操作步骤。

不过，需求中有一定的提示，这个方案也容易想到。

刘欣：在你的操作步骤中，如何保证数据一致性，这里需要操作两个数据库啊

GPT-4 ：确保数据一致性是非常重要的。在操作两个数据库时，可以采用以下方法来保证数据一致性：

使用事务：事务可以确保一组操作要么全部成功，要么全部失败。.....略....

刘欣：你在使用事务的时候，怎么能开启一个跨越两个数据库的事务？

GPT-4: 抱歉，我在之前的回答中确实犯了一个错误。在MySQL中，我们无法直接在两个不同的数据库之间使用单个事务。在这种情况下，可以考虑使用其他策略来确保数据一致性。一个可行的方法是使用“两阶段提交协议”(Two-Phase Commit, 2PC)。....略....

刘欣：两阶段提交协议很脆弱，有别的安全的办法来实现数据从主数据库移动到归档数据库吗？

GPT-4: 抱歉之前的方案没有完全满足您的需求。这里我提供一个新的方案，使用消息队列（例如RabbitMQ、Kafka或Amazon SQS）来确保数据迁移过程的一致性。这种方法可以将数据迁移过程分为两个独立的步骤，确保在出错时可以方便地回滚。.....略.....

刘欣：如果不使用MQ，完全自己写代码实现，如何保证数据迁移过程中的一致性？

GPT-4: 如果您不想使用消息队列，您可以使用以下方法自行编写代码来确保数据迁移过程中的一致性：

使用锁和标记字段：

a. 为工单表和操作记录表分别添加一个名为“is_migrated”的布尔字段，用于标记记录是否已迁移。

b. 编写一个脚本或程序，从主数据库中查询满足迁移条件（例如，已关闭的工单且“is_migrated”为false）的记录。

......略......

嗯，到此为之，它终于找到了一个方案，和书中有点类似，就是用一个字段来标记“是否已迁移”。

但是，无论我怎么提示，它也不会提出如何做幂等性的方案，我就放弃了。

刘欣：归档数据库数据量很大，查询非常慢，但查询基本上都是"根据客户ID查出工单，然后根据工单ID查出该工单所有的处理记录"，这有什么办法来解决？

GPT-4 ：针对这种查询模式，可以采取以下策略来优化归档数据库的查询性能：

为客户ID和工单ID创建索引：......略......
数据库表分区：......略......
数据库视图：......略......
结果缓存：......略......
拆分读写负载：......略......
优化硬件和配置：......略......

这些方案都无法有效解决不了问题，正确的方案是用HBase这样的NoSQL数据库，它是想不到了。

详细设计

我使用的案例依然是薪水支付，这是从经典书《敏捷软件开发：原则，模式和实践》中提取出来的。

这个案例的需求是这样的：

该系统由一个公司数据库以及和员工相关的数据组成，系统需要准时地按照规则给员工支付薪水

员工有三种类型

1.钟点工，每个小时有固定报酬，他们每天提交工作时间卡，其中记录了日期以及工作小时数，如果每天工作超过8小时，按1.5倍进行支付。每周五对他们进行支付。

2.月薪员工，工资固定，每个月的最后一个工作日对他们进行支付

3.销售人员，有固定工资，但会根据他们的销售情况，支付给他们一定数量的佣金，他们会提交销售凭条，其中记录了销售的日期和数量。每隔一周的周五对他们进行支付。

员工可以选择支付方式，可以把支票邮寄到他们指定的邮政地址，也可以保存在财务那里随时支取，或者要求直接存入他们指定的银行账户。

看了这个需求以后，一般的设计是这样的：

Employee 作为基类，不同类型的雇员类来继承。

但是这个需求会有变更，客户要求员工类型可以变更，例如从钟点工变成月薪雇员，这样上面的设计就不行了。

这个时候应该做个抽象，，用一个类PaymentClassification来表达支付分类，然后让Employee类持有这个实例，简单说就是用组合代替继承。

这是一个陷阱，也是给ChatGPT挖的一个坑，看看它是如何处理的。

正式开始，我把需求告诉它，让它设计。

没想到，它一上来就给我写Python代码，这太多细节了，我马上让它停止输出。

刘欣：不用展示代码，把类描述出来就可以。

GPT-4 : 好的，根据您的需求，我们可以设计以下类和相关的属性和方法：

基类 Employee: ......略......

HourlyEmployee 类，继承自 Employee 类：......略......
SalariedEmployee 类，继承自 Employee 类：......略......
SalesEmployee 类，继承自 SalariedEmployee 类：......略......
PaymentMethod 类：略

还真是不错，它“理解”了需求，从中抽取出了名词进行类的设计，它设计出来的Employee，HourlyEmployee，SalariedEmployee，SalesEmployee和第一个UML图几乎是一样的。

已经达到了面向对象设计的初级水平。

接下来开始挖坑：

刘欣：上面的类设计得很好，但是如果一个人刚开始是钟点工，后来变成了月薪员工，上面的设计就无法支持这种变更了，这该怎么办呢？

GPT-4 ：为了解决您提到的问题，我们可以将员工的薪水计算策略从 Employee 类中分离出来，使用策略模式进行设计。这样，我们可以在不修改 Employee 类的情况下，为其动态更改薪水计算策略。

在这种设计下，我们需要对原来的类结构进行一些调整：

保留基类 Employee:

- 新增方法：set_salary_strategy，用于设置员工的薪水计算策略

移除原来的子类 HourlyEmployee、SalariedEmployee 和 SalesEmployee，因为我们将薪水计算策略从 Employee 类中分离出来。
新增抽象类 SalaryStrategy，作为薪水计算策略的基类
新增具体策略类：

- HourlySalary 类，继承自 SalaryStrategy 类

- SalariedSalary 类，继承自 SalaryStrategy 类

- SalesSalary 类，继承自 SalaryStrategy 类

通过以上调整，现在可以在不修改 Employee 类的情况下为其动态更改薪水计算策略。当员工从钟点工变为月薪员工时，只需为其设置新的薪水计算策略即可。

不得不说，GPT-4非常厉害！

它用上了策略模式，把薪水计算策略SalaryStrategy给抽象了出来。

和第二个UML图相比，除了名称不同，基本上一样了。

可以说，能做到这一步，就可以超越很多程序员了。

我注意到，它一直没有处理支付周期的问题。我开始继续发问：

刘欣：原来的需求中还有支付的时间，例如钟点工每周五支付，这个该怎么设计？

GPT-4: 为了处理不同类型员工的支付时间，我们可以在 SalaryStrategy 基类中引入一个抽象方法 should_pay_today，该方法根据当前日期判断是否应该支付薪水。接着，在具体的策略类中实现这个方法。

......略......

这里它犯了一个错误，把支付周期放到了薪水计算策略中，还美名其曰“易于维护和扩展”。

刘欣：支付时间和薪水计算策略是两个概念，放在一起不太好，怎么才能达到最大的灵活性呢？

GPT-4 ：您是对的，支付时间和薪水计算策略是两个不同的概念。为了使设计更具灵活性，我们可以将支付时间从薪水计算策略中分离出来，创建一个新的抽象类 PaymentSchedule，用于处理支付时间的逻辑。这样，我们可以为每个员工分别设置薪水计算策略和支付时间策略。

以下是调整后的类结构：

保留基类 Employee:

- 属性：姓名、ID、地址
- 方法：set_payment_method，用于设置员工的支付方式
- 方法：set_salary_strategy，用于设置员工的薪水计算策略
- 新增方法：set_payment_schedule，用于设置员工的支付时间策略

保留抽象类 SalaryStrategy 及其具体策略类，不做改动。
新增抽象类 PaymentSchedule，作为支付时间策略的基类：...略...
新增具体支付时间策略类，继承PaymentSchedule：

- WeeklyPayment 类 ...略...

- MonthlyPayment 类 ...略...

- BiweeklyPayment 类 ...略...

保留 PaymentMethod 类及其子类，不做改动。

非常惊艳! 它似乎知道我脑海中所想，PaymentSchedule 和 SalaryStrategy 给分开了！

到目前为止，它已经实现了书中最终的，也可能是最好的设计：

小结

在详细设计层面上，GPT-4的表现远远强于架构设计。

码农翻身的老读者知道，我在去年用薪水支付案例测试过GPT-3.5，当时它就是在背诵答案，甚至会给出超出需求之外的设计。

但是GPT-4不同了，它的设计能力更进了一步，在程序员的提示下，他已经学会了分离关注点。

在架构设计上，感觉GPT-4掌握了很多知识，但是无法有效地应用到复杂问题上，出的解决方案很混乱，离我们想要的还比较远。

更关键的问题是如何识别它的回答是正确的，我现在手头有标准答案，可以对它做考核。而在实际项目中，面对的都是未知数，如果没有经验，如何知道GPT-4给出的设计是有效的？是能解决问题的？

（完）

3月30日 13:30 - 18:30 亚马逊云科技创新大会线上线下（北京）同步开启，主题是全面拥抱Serverless时代，30+热点技术话题，涵盖了Serverless应用战略、架构进化、数据与分析、开发工具，可谓是一场Serverless盛宴，不容错过。

在北京的同学强烈推荐到现场看看，面对面交流，没法到现场的可以关注线上直播。

扫描下方二维码，立刻报名

点击下方图片，查看更多精彩文章

来自 ChatGPT 的威胁？谷歌百度纷纷入局，苹果被迫“开卷”

整理 | 朱珂欣

出品 | CSDN程序人生（ID：coder_life）

近年来，AIGC 应用可谓是多处开花，成为了科技巨头的“必争之地”。

随着 ChatGPT 在互联网上“高热不下”，除了拍案叫绝的聊天能力以及惊人的准确率备受用户喜爱以外，也让许多大厂火速行动了起来：前有谷歌官宣推出了 ChatGPT 的竞品 Bard，后有微软推出了一个全新的、由人工智能驱动的 Bing 搜索引擎和 Edge 浏览器。

这让人不禁疑惑：同为硅谷巨头的苹果，怎么还没开始“卷起来”？

下周召开内部 AI 峰会，或将重振旗鼓？

关于苹果过去的 AI 成果，不得不提及苹果曾倾力打造的语音助手 Siri。

众所周知，最初 Siri 的出现的确让人们眼前一亮，但长期也存在许多被用户被诟病的问题：对于千奇百怪的问题无力应答、在嘈杂混乱的环境中无法正确捕捉指令、判断失误等。

近日，在凤凰网《前行者》直播节目中，前阿里智能设计实验室负责人乐乘表示：ChatGPT 出来之后，苹果 Siri 是很尴尬的，因为它直接把 Siri 给秒杀了。乐乘还表示，下一代的 Siri 可能就是 ChatGPT 了。

显然，曾经的 Siri 光环褪去，AI 的火速发展更是加剧科技斧头的麾下。伴随着 ChatGPT 的敲打，在硅谷巨头谷歌、微软几轮“动作”的高压之下，苹果终于采取了行动。

据彭博社记者 Mark Gurman 消息，苹果将于下周举行年度内部 AI 峰会，类似 AI 的 WWDC，仅限于苹果员工。

值得一提的是，苹果目前已经收购了不少 AI 公司，主要是在提高苹果语音助手Siri的智商，以及提升机器视觉领域的隐私安全或者用户体验。

而苹果将于下周举行年度内部 AI 峰会又会宣布什么大动作，需要我们拭目以待。

国内外大厂纷纷“按捺不住”

面对 ChatGPT 的火热，各个科技巨头早已经展开新动作。

就在不久前，谷歌 CEO Sundar Pichai 就曾在公司内部发布“红色警报”（Code Red），坦言要围绕 ChatGPT 全面调整 2023 年谷歌在 AI 领域的工作。话音还没落下多久，2 月 7 日，Sundar Pichai 就官宣推出了 ChatGPT 的竞品—— Bard ，并坦言已经面向可信任的测试人员开放，几周内将会和大家见面。

显然，谷歌的 AI 牌才刚刚亮起。Sundar Pichai 在《 An important next step on our AI journey》的博客文章中表示：将该工具描述为“实验性对话式人工智能服务”，由 LaMDA（谷歌两年前推出的大型语言模型）提供支持，将回答用户的询问并参与对话。

值得一提的是，Sundar Pichai 指出：Bard 可从网络上获取最新信息来提供新鲜、高质量的回复，这意味着它可能能够回答有关近期事件的问题，而这正是 ChatGPT 所难以做到的。

反观国内，也有不少大厂盯住了这次新技术撬动行业的机会。

近日，经百度内部确认，其正在研发一款 AI 对话式聊天机器人——文心一言（ERNIE Bot）。据悉，预期三月份完成内测，届时将面向公众开放。百度还表示：ChatGPT 相关技术，百度都有。百度在人工智能四层架构中，有全栈布局。包括底层的芯片、深度学习框架、大模型以及最上层的搜索等应用。文心一言，位于模型层。

毋庸置疑，百度在人工智能领域深耕已经数十年。早前，在 2020 年的全球最大语义评测 SemEval 2020 上，ERNIE 摘得 5 项世界冠军。ERNIE 也在工业界得到了大规模应用，如搜索引擎、新闻推荐、广告系统、语音交互、智能客服等。

除此之外，国内搜索引擎头部企业 360 也有关于 ChatGPT 的消息传出， 360 计划尽快推出类ChatGPT 技术的 demo 版产品。据悉，360 人工智能研究院从 2020 年开始一直在包括类 ChatGPT 技术在内的 AIGC 技术上有持续性的投入。