1 月 16 日，亞馬遜副總裁兼 CTO Werner Vogels 發(fā)布了一篇名為《分布式計算宣言》的文章，為人們揭示 24 年前的亞馬遜研發(fā)團隊，是如何在業(yè)務(wù)發(fā)展、架構(gòu)迭代面對巨大阻力時，思考引入 SOA 架構(gòu)和分布式思想，完成自我“革命”的。讀罷令人感嘆，每一個開發(fā)者都希望獲得成就感，去做一些真正有創(chuàng)造力的工作，做一些 24 年后仍然令 CTO 引以為豪，并轉(zhuǎn)述給百萬開發(fā)者的工作，而不是把時間和精力消耗在寫千篇一律又無法復(fù)用的“膠水”代碼，或是在越來越復(fù)雜軟件棧面前，疲于奔命地寫業(yè)務(wù)流程并盡量減少 Bug。

更加不堪的是，有時僅僅是因為同一項目的兩個成員使用的庫版本不同，我們就不得不消耗大量的精力去解決沖突。當(dāng)然，那些成功的團隊和開發(fā)者往往也處理過同樣的問題，但這種成就感的到來未免門檻過高。

不過，在太平洋時間 12 月 1 日的 re:Invent 大會上，Werner 展示了另一種可能 —— 一名開發(fā)者可以把精力放在更有價值的工作，而不必重復(fù)低效的勞動，在一系列 Serverless 工具的幫助下，一些代碼可以少寫，因為未來你可能再也不需要寫它們了。如果我們拋開它們作為商業(yè)軟件的盈利屬性來看，這恐怕是自云原生理念普及以來，最能利好開發(fā)者的產(chǎn)品發(fā)布。

自動化創(chuàng)建狀態(tài)機和工作流，并徹底干掉“膠水”代碼

對有限狀態(tài)機最簡單的理解是“if……else……”，但代入到負(fù)責(zé)研發(fā)場景里時，要實現(xiàn)有限狀態(tài)機可不那么簡單。

英國衛(wèi)報是世界最大的英文媒體之一，在全球擁有幾十萬訂閱用戶，每周至少要為 60000 名用戶準(zhǔn)時送達(dá)訂閱信息。不管支撐英國衛(wèi)報的軟件系統(tǒng)是如何構(gòu)建的，可以確定的是，這里一度存在相當(dāng)多的技術(shù)問題 —— 衛(wèi)報的高級開發(fā)經(jīng)理 Paul Brown 曾在采訪中提到，衛(wèi)報主數(shù)據(jù)庫系統(tǒng)和所有第三方系統(tǒng)之間的數(shù)據(jù)流編排非常困難，且系統(tǒng)之間相互依賴，一個系統(tǒng)出問題就會產(chǎn)生連鎖反應(yīng)。如何編排所有分布式系統(tǒng)，保證報紙的正確、及時交付，變成了一個棘手問題。

馬修國際旗下的一家子公司 SGK 遇到的則是另一個技術(shù)問題——他們要為甲方交付 ETL 管道，但是需要每天至少刷新兩次輸出數(shù)據(jù)，因此要跨多個數(shù)據(jù)庫進行數(shù)據(jù)管理和復(fù)制；其交付數(shù)據(jù)的業(yè)務(wù)規(guī)則在不斷更新；需要集成來自 10 多個不同數(shù)據(jù)源的輸入數(shù)據(jù)。每個數(shù)據(jù)源大概有 1–20K 行，85 列。如何搭建 ETL 管道，又變成了一個棘手問題。

這兩種問題有一個共性，單純用狀態(tài)機做一個訂閱流程或是 ETL 或許不難，但放在具體場景中則要考慮太多因素，且要承擔(dān)系統(tǒng)維護的責(zé)任。Amazon Step Functions 最初誕生時，就是為了解決類似的問題，通過可視化拖動云服務(wù)的方式，構(gòu)建事件驅(qū)動的工作流 —— 你當(dāng)然可以選擇從頭 coding，但也可以拖一拖搞定這個事。

這聽起來很性感，但實際能支撐的并發(fā)工作復(fù)雜有限，一次有效的最大并發(fā)數(shù)僅為 40，另外僅接受 JSON 數(shù)組作為輸入源，整體還是比較受限的。本次re:Invent發(fā)布的 AmazonStepFunctionsDistributedMap 重點搞定了并發(fā)問題，從 40 提升到 10000，讓 Step Functions 真正變得通用。下圖為新老 Distributed Map 的一些關(guān)鍵數(shù)據(jù)對比：

在 Keynote 中，Werner Vogels 多次以“異步”、“事件驅(qū)動”等關(guān)鍵詞來描述 Amazon Step Functions Distributed Map 的設(shè)計理念，但對于開發(fā)者來說，可能更吸引的人是，如果你已經(jīng)會寫 ETL ，那就可以少做一些重復(fù)工作，多去考慮一些能給業(yè)務(wù)、技術(shù)架構(gòu)帶來增量的研發(fā)工作。

除了煩人的業(yè)務(wù)流程外，另一個降低研發(fā)效率的工作是寫“膠水”代碼。所謂“膠水”代碼，就是指互不兼容的模塊間（接口不同、語言不同等），需要寫一些代碼做連接才能正常工作。這類代碼對業(yè)務(wù)沒有任何價值，純粹是軟件工程的副產(chǎn)品。

相信 Werner Vogels 和亞馬遜云科技是看到了對這一問題的反饋，所以才發(fā)布了 Amazon EventBridge Pipes 這一產(chǎn)品 —— 它是 Amazon EventBridge 的一項新功能，提供針對生產(chǎn)者、消費者的點對點流程，自動完成模塊集成，不需要編寫“膠水”代碼。

這個點對點流程的創(chuàng)建，需要重點考慮事件源、事件目標(biāo)兩個主要問題。

事件源發(fā)布時，Amazon EventBridge Pipes 支持以下服務(wù)作為事件源：Amazon DynamoDB、Amazon Kinesis、Amazon MSK 、Apache Kafka、Amazon SQS（標(biāo)準(zhǔn)和 FIFO）和 Amazon MQ（均用于 ActiveMQ 和 RabbitMQ）等。

事件目標(biāo)則包括：AWS Lambda、Amazon API Gateway、Amazon SNS、Amazon SQS 和 AWS Step Functions 等。

盡管現(xiàn)在在行業(yè)內(nèi)的應(yīng)用情況有待檢驗，但 Amazon Step Functions Distributed Map 和 Amazon EventBridge Pipes 實際傳達(dá)了一種趨勢：類似的服務(wù)在未來幾年可能會越來越多，越來越成熟，告別低價值代碼這件事是絕對靠譜的，云原生時代開發(fā)者的技術(shù)棧需要做相應(yīng)的調(diào)整。

如果在未來，我們可以不用處理經(jīng)常見到的業(yè)務(wù)流程或 ETL 流程，也不用寫“膠水”代碼，那將有大量的時間可以來思考業(yè)務(wù)、架構(gòu)及流程本身的合理性。

避免更糟糕的時間浪費

如本文開頭所提，比起寫一段 ETL 代碼，或是寫一段模塊集成代碼，更糟糕的是，將時間消耗在協(xié)作問題而非技術(shù)問題上。

這年頭各企業(yè)的業(yè)務(wù)壓力永遠(yuǎn)越來越大，需求能三天上線就不會拖到一周，大部分時間里可能不會有工程設(shè)計這個概念，中間遇到的各種協(xié)作問題只能是“在起飛的過程中換輪胎”。

所以當(dāng) Werner Vogels 在本次 re:Invent 上發(fā)布 Amazon CodeCatalyst 時，臺下的掌聲十分熱烈。

Amazon CodeCatalyst 的功能包括：

• 項目資源藍(lán)圖——不僅是新項目的腳手架，還包括支持軟件交付和部署所需的資源
• 統(tǒng)一開發(fā)環(huán)境，保持項目組環(huán)境一致
• 管理 issue、pr、部署跟蹤等
• CI/CD
• 顯示項目儀表板
• 通過一封電子郵件即可邀請他人就項目進行協(xié)作
• 統(tǒng)一搜索，跨用戶、問題、代碼和其他項目資源檢索內(nèi)容

這里的資源藍(lán)圖包括啟動代碼、示例代碼和云服務(wù)相關(guān)配置的最佳實踐，其他幾項也都是軟件研發(fā)項目管理的必需品。另外一大特色在于 CodeCatalyst 本身集成的第三方工具是高度靈活的，是不是要用 GitHub 和 Jira，完全和團隊的習(xí)慣有關(guān)。Werner Vogels 說，可視化是亞馬遜云科技提供服務(wù)的一大特點，而大部分開發(fā)者應(yīng)該也認(rèn)為可視化是個讓人十分心安的標(biāo)簽。

Serverless 是所有構(gòu)想的核心

回過頭看，無論是 Amazon Step Functions Distributed Map 還是 Amazon EventBridge Pipes， 其核心始終是 Serverless，是 Lambda 這一產(chǎn)品本身。

Lambda 在 2014 年的發(fā)布，雖然展示了亞馬遜云科技對 Serverless 愿景理念的深度洞察，但不可否認(rèn)的是，當(dāng)時的 Serverless 技術(shù)仍存在問題。直到本次 re:Invent，Serverless 的冷啟動速度得到大幅優(yōu)化，大數(shù)據(jù)核心產(chǎn)品全面 Serverless 化完成，才宣告 Serverless 技術(shù)發(fā)展的又一里程碑到來，云產(chǎn)品全面 Serverless 化只余時間問題。

而 Serverless 從技術(shù)、產(chǎn)品兩個方面的成熟，也直接為以上發(fā)布鋪平了道路。試想如果這些產(chǎn)品不是圍繞 Serverless 技術(shù)來進行設(shè)計的，那么所有構(gòu)想都將成為災(zāi)難 —— 沒人能夠忍受自動化創(chuàng)建業(yè)務(wù)流程的同時，還要關(guān)心服務(wù)器的配置問題。

這不只是在說 Serverless 技術(shù)好不好用，也是在說創(chuàng)新的門檻到底是高是低 —— 如果你有了一個創(chuàng)意，Serverless 是最簡潔的實現(xiàn)和驗證手段，降低 Serverless 的使用門檻，就是在降低企業(yè)內(nèi)的創(chuàng)新門檻。而亞馬遜是一家尤其關(guān)注創(chuàng)新的企業(yè)，因此，Application Composer 應(yīng)運而生。

Application Composer 的特點，在于可以幫助生成部署就緒的項目，例如 IaC 定義文件和 Lambda 函數(shù)代碼腳手架。

在傳統(tǒng)開發(fā)工作里，配置 Serverless 服務(wù)需要理解 IaC （基礎(chǔ)設(shè)施即代碼）的概念，并寫一些機器可讀的定義文件。這個概念作進一步延展，就變成了“基礎(chǔ)設(shè)施可編程”，聽起來是比較嚇人的。

Application Composer 無疑大大降低了開發(fā)者內(nèi)心對 Serverless 技術(shù)的畏懼程度，某種程度上也就是加速了企業(yè)的創(chuàng)新速度 —— 當(dāng)然，這也需要企業(yè)充分理解云理念，并對云原生相關(guān)技術(shù)有相對成熟的運用經(jīng)驗。

3D 世界的構(gòu)建正成為主流

在 Keynote 的末尾，抬頭看路，Werner Vogels 給出一個大膽判斷：未來 3D 會像視頻一樣普及。

去年，亞馬遜發(fā)布具有 3A 游戲開發(fā)能力的開源游戲引擎 Open 3D Engine（O3DE）。O3DE 的核心特色是高度靈活的模塊化功能，適合做 3A 級網(wǎng)游，完全免費，支持到位、更新簡單。保證模塊化功能的核心是帶有源碼和資源的 Gems 系統(tǒng)，不需要的功能可以完全不編譯，極大提升了靈活性。

因此在發(fā)布后，O3DE 立即引起了熱議。

究其根本，O3DE 其實是亞馬遜的 Lumberyard 的繼承者，Lumberyard 引擎是 2016 年亞馬遜與德國著名引擎技術(shù)開發(fā)商 Crytek 達(dá)成的一項交易，彼時深陷財務(wù)危機的 Crytek 以具體數(shù)字不詳（傳聞為 5000 萬 -7500 萬美元）的價格向亞馬遜完整授權(quán)了 CryEngine 的所有代碼，而 Lumberyard 便是 CryEngine 經(jīng)過修改的免費版本。

到去年年底，開放 3D 基金會 (O3DF) 宣布推出 O3DE 的第一個穩(wěn)定版本，這是一個 Apache2.0 許可的多平臺 3D 引擎，可讓開發(fā)人員構(gòu)建 AAA 級游戲、用于視頻制作的電影級 3D 世界，以及不受許可費或商業(yè)條款影響的非游戲使用案例模擬。

而本次 re:Invent 上的最后一個發(fā)布，也與 3D 有關(guān) —— Amazon SimSpace Weaver。Amazon SimSpace Weaver 是一種全新的完全托管仿真服務(wù)，可幫助用戶在云中部署大規(guī)模空間模擬。借助 SimSpace Weaver，用戶可以創(chuàng)建具有數(shù)百萬個對象的無縫虛擬世界，這些對象可以實時相互交互，而無需管理后端基礎(chǔ)設(shè)施。

結(jié)合去年發(fā)布的 Amazon IoT TwinMaker 來看，當(dāng)下的 3D 技術(shù)脫胎于游戲，但已不止于游戲，以 SimSpace Weaver 為例，數(shù)百萬個對象，已經(jīng)對以智慧城市為典型的行業(yè)應(yīng)用產(chǎn)生實際助推作用。

對智慧城市的建設(shè)仍然只是未來暢想的第一步，計算的未來在于對物理世界的極致模擬。當(dāng)下的“綠色科技”，對于全世界都是一個挑戰(zhàn)，那么應(yīng)該如何最高效地應(yīng)用技術(shù)手段達(dá)成“碳中和”？量子計算或許是關(guān)鍵一環(huán)。Werner 以八年前他在夏威夷和 Terraformation 公司的討論作為案例來解釋這一問題。

大規(guī)模種植林木是實現(xiàn)“碳中和”的直接手段，但如何高效經(jīng)濟地種植出一座森林，則是個復(fù)雜問題。模擬仿真，可以讓我們這座森林未來的狀態(tài)、規(guī)模、效用以及內(nèi)部生態(tài)系統(tǒng)的變化有更明確的認(rèn)知，但整體計算量將是恐怖的，量子計算機比經(jīng)典計算機更適合這種仿真需求。

如果將問題遷移到生命科學(xué)、材料科學(xué)，全面深入分子結(jié)構(gòu)，計算量將以指數(shù)級增長，可能會迅速超過行業(yè)的算力儲備，量子計算機的優(yōu)勢會變得更加明顯。這也是為什么量子計算能成為當(dāng)今學(xué)術(shù)研究的主流 —— 我們可以通過量子計算機徹底迭代計算能力和模擬能力，而不是通過算法研究做有限的迭代和逼近。

Werner 在演講的最后以量子計算為核心，展望了將物理世界數(shù)字化的可能與前景。他提及亞馬遜云科技量子計算中心學(xué)者、世界知名的量子信息科學(xué)先驅(qū)人物 John Preskill 在 Youtube 已有許多優(yōu)質(zhì)視頻發(fā)布，闡述了利用量子計算來解決行業(yè)難題的思路和方法，并熱情地推薦大家也去了解了解。

這樣看來，盡管量子計算如今仍處于研究的早期階段，但應(yīng)用思路已經(jīng)具備，前景是明朗的。從研發(fā)基礎(chǔ)設(shè)施到 3D 仿真 ，再到量子計算，形成了一條清晰明朗的未來科技演進之路。

這是本次 re:Invent 帶給我們的另一重驚喜。

與開發(fā)者一起構(gòu)建未來

亞馬遜云科技 Heroes 項目是社區(qū)最重要的組成部分之一，該項目表彰了全球充滿活力的亞馬遜云科技專家群體，他們對知識分享的熱情在社區(qū)中產(chǎn)生了真正的影響。

亞馬遜云科技的 Heroes 能夠以各種方式分享知識，包括通過社交媒體、博客文章、開源項目、視頻和論壇進行在線分享，或親自參加會議、研討會和用戶組活動。

在此次 re:Invent 2022 大會中，Heroes 的身影無處不在。Werner Vogels 博士也在 Keynote 演講中提到：“對于開發(fā)者而言，除了可以在亞馬遜云科技為了幫助開發(fā)者成長提供的 500+ 精心打造的課程中進行學(xué)習(xí)外，向你身邊的技術(shù)專家請教也會是一個很好的方式。”

亞馬遜云科技今年也重大發(fā)布了中國開發(fā)者官網(wǎng)，提供一站式平臺，幫助開發(fā)者學(xué)習(xí)成長及交流并鏈接全球技術(shù)資源，助力開發(fā)者使用亞馬遜云科技獲得成功，與開發(fā)者一起構(gòu)建未來。

在亞馬遜云科技開發(fā)者社區(qū)官網(wǎng)，我們發(fā)布了關(guān)于本次 re:Invent 更全面的信息資訊。

者 | Asim Shrestha

譯者 | 核子可樂

策劃 | 冬梅

《企業(yè)級 Agents 開發(fā)實戰(zhàn)營》重磅上線，10 周帶你進行工具、對話及多模態(tài)等不同類型 Agents 工程化開發(fā)實戰(zhàn)！

編者按：ChatGPT 在編程時的使用已經(jīng)非常廣泛。近日，一支國外技術(shù)團隊在利用 ChatGPT 生成代碼進行開發(fā)時遇到了嚴(yán)重的問題，導(dǎo)致了他們的訂閱功能崩潰，并且給業(yè)務(wù)帶來了重大損失。盡管 ChatGPT 等 AI 工具在編程領(lǐng)域具有潛力，但它們并不總是能夠提供完美或適用于特定場景的解決方案。在這種情況下，如果技術(shù)團隊過于依賴這些工具，并在時間壓力下被迫做出決策，那最終的結(jié)果往往都是不樂觀的。

本文作者正是上述團隊中的一名軟件工程師，也是 Reworkd 的聯(lián)合創(chuàng)始人。Reworkd 是一家 YC S23 公司，從網(wǎng)絡(luò)中提取結(jié)構(gòu)化數(shù)據(jù)。他們還制作了智能化分析問題的工具 AgentGPT。以下內(nèi)容由 InfoQ 整理并翻譯。

作者聲明：首先強調(diào)一點，本文提及的作法問題很大，本可避免。但一切都是時間緊迫之下匆忙行動下的后果。請大家在閱讀時多多諒解，嘴下留情。

雖然系統(tǒng)仍在運行，但訂閱功能卻掛掉了……或者說是死而不僵……

去年 5 月，我們首次嘗試靠自己的初創(chuàng)業(yè)務(wù)賺錢。我們的期望不高，因此在發(fā)布后不到一個小時就迎來第一位客戶時，我們感到萬分驚喜。那是個奇跡般的時刻，我們向用戶表達(dá)了謝意。而且考慮到之前的準(zhǔn)備工作花了整整兩個晚上，所以我們信心滿滿地上床休息了。

第二天早上醒來時，我們收到 40 多條用戶投訴的郵件通知。看似靠譜的系統(tǒng)似乎在一夜之間崩潰決堤，而問題只有一個——用戶無法訂閱。我們根本不知道是怎么搞的。

我們的貨幣化之路

先介紹一點業(yè)務(wù)背景。今年 5 月 YC 第 23 賽季正式啟動，我們也不太確定產(chǎn)品發(fā)布之后該怎么盈利。我們的 YC 團隊合伙人 Dalton 建議一切以付費用戶為中心，并提出應(yīng)該將我們預(yù)先想好的月費數(shù)字翻個倍。最終（雖然很不情愿），我們定下了每月 40 美元的價格。會議結(jié)束之后，我們立即著手設(shè)計商業(yè)模式。我們的項目最初采用全棧 NextJS，但后來打算將所有內(nèi)容遷移至 Python/FastAPI。在 ChatGPT 的幫助下，我們順利完成了工作，實現(xiàn)了 stripe 的全面集成……問題爆發(fā)后，我們又沖刺了整整五天時間，那也是我們整個月內(nèi)最夜不能寐的五個日夜。

在這五天里，我們既難以入睡、又很害怕醒來——因為每天起床，我們都會收到好幾十封投訴郵件。哪怕如今事情過去，我也不禁會想這次的問題讓我們失去了多少客戶。

按照每天 50 封郵件、每周 5 天、每位訂戶 40 美元的數(shù)字來計算，意味著單是在愿意表達(dá)意見的這部分用戶中就出現(xiàn)了 1 萬美元的銷售損失。而且請大家注意，愿意發(fā)聲的永遠(yuǎn)只是一小部分。我們每天都會準(zhǔn)時回復(fù)這些郵件。大家會抱怨點擊訂閱時加載圖標(biāo)沒完沒了地旋轉(zhuǎn)，而我們則會嘗試開設(shè)新賬戶來親自驗證。在我們這邊訂閱流程順利進行，于是一切在摸不著頭腦之下繼續(xù)保持原樣。我們用盡了種種辦法，但根本無法重現(xiàn)這個問題。更奇怪的是，在進入上班時間之后，幾乎就不再新增任何投訴了。

價值上萬美元的幻覺

單從感受出發(fā)，從發(fā)現(xiàn)問題到真正解決問題的那段前列時光就像是過去了好幾個月。在這五天當(dāng)中，我們收到了無數(shù)電子郵件、數(shù)百條監(jiān)控日志、跟 stripe 工程師們在 discord 上隨時交流。最終在花了幾個小時盯著 5 個關(guān)鍵文件后，我們終于搞清了真相。線索就在以下截屏當(dāng)中，感興趣的朋友可以先別急著下翻，試試能不能自行找到答案。

如果沒找到也不要緊，其中的罪魁禍?zhǔn)拙褪窍旅孢@行看似無辜的代碼。這行代碼也讓我們遭遇到人生中最折磨的一個禮拜，并讓我們確確實實損失掉了上萬美元。一起來看這第 56 行：

事情是這樣的：作為后端遷移的一部分，我們將數(shù)據(jù)庫模型從 Prisma/Typescript 轉(zhuǎn)換為 Python/SQLAlchemy。整個過程非常繁瑣，而我們發(fā)現(xiàn) ChatGPT 在執(zhí)行這類轉(zhuǎn)換時表現(xiàn)相當(dāng)出色，于是我們在整個遷移過程中幾乎隨時都在使用它。

我們復(fù)制粘貼了它生成的代碼，發(fā)現(xiàn)一切運行良好；之后又在生產(chǎn)中進行測試，結(jié)果也同樣有效。于是我們興高采烈地推進，卻忘記了此時我們?nèi)栽谑褂?Next API 進行數(shù)據(jù)庫插入，且 Python 代碼只負(fù)責(zé)從數(shù)據(jù)庫中讀取。我們第一次開始在 Python 中實際插入數(shù)據(jù)庫記錄是在訂閱功能的實現(xiàn)階段，雖然我們?yōu)榇耸謩觿?chuàng)建了全新的 SQLAlchemy 模型，但最終卻仍然照搬了 ChatGPT 為原有模型編寫的舊格式代碼。當(dāng)時的我們根本沒意識到，所有模型當(dāng)中的 ID 生成方式都已經(jīng)出了問題。

Bug 圍剿行動

第 56 行中的問題在于，我們只是傳入了一條硬編碼的 ID 字符串，而非使用函數(shù)或 lambda 來為我們的記錄生成 UUID。也就是說，對于我們后端中的任何給定實例，一旦單個新用戶訂閱并使用此 ID，其他用戶就無法再次執(zhí)行訂閱流程，因為這會導(dǎo)致唯一 ID 沖突。但受我們后端設(shè)置的影響，這個問題被嚴(yán)嚴(yán)實實地隱蔽了起來。

我們在亞馬遜云科技上運行有 8 項 ECS 任務(wù)，它們?nèi)歼\行著我們后端的 5 個實例（這確實只能算過渡性方案，但我們手頭正好有不少亞馬遜積分，換作是各位肯定也會照此辦理）。也就是說任何單一用戶都面對著包含 40 個唯一 ID 的資源池，也是他們能夠成功訂閱的最高上限。

工作日期間之所以一切運轉(zhuǎn)良好，就是因為我們的日均提交次數(shù)大概在 10 到 20 次（當(dāng)然是直接提交至主服務(wù)器），進而觸發(fā)新的后端部署操作，從而為我們提供 40 個可供客戶使用的新 ID。然而到了晚間，當(dāng)我們不再執(zhí)行提交，這些服務(wù)器上的可用 ID 就會被快速耗盡，并導(dǎo)致所有后續(xù)訂閱遭遇 ID 沖突。用戶雖然剛開始有 40 個服務(wù)器訂閱 ID，但這個數(shù)字在漫漫長夜中很快歸零。在最終解決了這個問題后，我們感到如釋重負(fù)。

在發(fā)現(xiàn)問題并迅速提出修復(fù)方案之后，我們終于能夠踏踏實實睡覺、不用擔(dān)心第二天被用戶們罵醒了（也不盡然，期間我們還出過其他好幾次事故，但這就是另外的故事了）。

總結(jié)

回想起來，無論那五天過得有多么煎熬，都將成為我們永遠(yuǎn)無法忘懷的一段創(chuàng)業(yè)經(jīng)歷。如今的我們終于能以輕松的心態(tài)回顧那段日子，調(diào)侃說我們本該多做點測試、也不該貿(mào)然照搬 ChatGPT 生成的代碼，更需要在提交之前多加考量。

但畢竟這就是人生，這就是從無到有的創(chuàng)業(yè)體驗。

參考鏈接：

https://web.archive.org/web/20240609213809/https://asim.bearblog.dev/how-a-single-chatgpt-mistake-cost-us-10000/

原文鏈接：聯(lián)創(chuàng)用ChatGPT寫的一行代碼讓公司損失上萬美元！網(wǎng)友：老板自己寫的，找不到人背鍋了_生成式 AI_InfoQ精選文章

便是不學(xué)編程或者初學(xué)編程的小白，對于報錯“error”“！！”都是司空見慣了，常見來自系統(tǒng)的錯誤提示音……

如果這一切都發(fā)生在我們學(xué)習(xí)Python的時候，該咋辦？

秉持這個想法我去扇貝小組里找了編程大神黃老師！

面對著大神·黃的質(zhì)疑”你有沒有好好聽課！“

花蛤自慚形穢QWQ……以下是來自黃大神的應(yīng)對答疑。

TypeError：類型錯誤，對象用來表示值的類型非預(yù)期類型時發(fā)生的錯誤

1.不同類型變量之間的操作

錯誤案例：

print('abc' + 18)

報錯提示：

TypeError: can only concatenate str (not "int") to str

原因分析：上面代碼中 'abc' 是字符串，而 18是整型，強制將二者相加導(dǎo)致出錯。

正確代碼：

print('abc' + str(18))

2.函數(shù)傳入?yún)?shù)類型/個數(shù)錯誤

錯誤案例：

t=[1, 2, 3]
for i in range(t):
print(i)

報錯提示：

TypeError: 'list' object cannot be interpreted as an integer

原因分析：上面代碼中 range()函數(shù)期望的入?yún)⑹钦?integer)，但卻給的入?yún)榱斜?list)，因此會報錯。

正確代碼：

t=3
for i in range(t):
print(i)

3.非函數(shù)卻以函數(shù)來調(diào)用

錯誤案例：

t=('a', 'b', 'c')
t()

報錯提示：

TypeError: 'tuple' object is not callable

原因分析：上面代碼中 t 是元組，卻加了 () 進行函數(shù)調(diào)用，導(dǎo)致報錯。

正確代碼：

t=('a', 'b', 'c')
t

AttributeError：屬性錯誤，特性引用和賦值失敗時會引發(fā)屬性錯誤

錯誤案例：

import random
print(random.Randint(1, 10))

報錯提示：

AttributeError: module 'random' has no attribute 'Randint'

原因分析：random 模塊沒有 Randint方法（大小寫）。

正確代碼：

import random
print(random.randint(1, 10))

NameError：試圖訪問的變量名不存在

錯誤案例：

print(x)

報錯提示：

NameError: name 'x' is not defined

原因分析：要先給變量賦值，然后才能使用它。

正確代碼：

x=1
print(x)

SyntaxError：語法錯誤，代碼形式錯誤

錯誤案例：

def func()
pass

報錯提示：

SyntaxError: invalid syntax

原因分析：def 后面忘記加冒號 ':'。

正確代碼：

def func():
pass

KeyError：在讀取字典中的 key 和 value 時，如果 key不存在，就會觸發(fā) KeyError 錯誤

錯誤案例：

dic={'a':1,'b':2,'c':3}
print(dic['d'])

報錯提示：

KeyError: 'd'

原因分析：dic 字典沒有鍵 'd'。

正確代碼：

dic={'a':1,'b':2,'c':3}
print(dic['a'])

IndexError：索引錯誤，使用的索引不存在，常索引超出序列范圍，序列中沒有此索引(index)

錯誤案例：

l=[1,2,3,4]
print(l[4])

報錯提示：

IndexError: list index out of range

原因分析：索引 4超出列表索引范圍。

正確代碼：

l=[1,2,3,4]
print(l[1])

IndentationError：代碼縮進錯誤

錯誤案例：

if True:
print(1)

報錯提示：

IndentationError: expected an indented block

原因分析：縮進有誤，Python 的縮進非常嚴(yán)格，行首多個空格，少個空格都會報錯。

正確代碼：

if True:

print(1)

更多問題請在評論區(qū)留言問我吧~