AI as Software Architect assistant by Avraham Poupko (#GSAS24)
### 章节 1:引言与皮诺曹的错觉 📝 **本节摘要**: > 演讲者 Abraham 以“皮诺曹”为喻,指出当前 AI 虽然能通过语言交流,却如同以为自己即将变成真人的木偶,产生了一种“智能即将来临”的错觉。他提到准备 AI 主题演讲的困难在于技术的快速迭代,并分享了利用 Gemini 备课的...
Category: AI📝 本节摘要:
演讲者 Abraham 以“皮诺曹”为喻,指出当前 AI 虽然能通过语言交流,却如同以为自己即将变成真人的木偶,产生了一种“智能即将来临”的错觉。他提到准备 AI 主题演讲的困难在于技术的快速迭代,并分享了利用 Gemini 备课的经历。特别令他警惕的是,AI 在回答中使用了“仍然(still)”一词来描述人类专家的不可或缺性,这让他再次联想到渴望取代人类的皮诺曹。
[原文] [YGI]: perfect so Abraham it's all yours okay
[译文] [YGI]: 太好了,那么 Abraham,舞台交给你了,好吗?
[原文] [Abraham]: thank you thank you ygi it's been an amazing day thank you thank you very much um sometimes when talking about AI llms there's this feeling this notion that we hear from people that real intelligence is is just around the corner it's going to happen it's inevitable it's it's here and the truth is even the llms themselves sometimes think that uh does anybody recognize this quote tomorrow I seize to be a puppet and I become a boy like you and all the other boys where's this from,
[译文] [Abraham]: 谢谢,谢谢你 YGI,这是美妙的一天,非常感谢。有时候当我们谈论 AI 和大语言模型(LLMs)时,会有这样一种感觉,或者说我们听到人们有这样一种观念,认为“真正的智能”指日可待,它即将发生,它是不可避免的,它已经到了。而事实是,甚至 LLM 自己有时候也这么认为。有人认得这句话吗?“明天我将不再是个木偶,我将成为一个像你和其他男孩一样的真男孩。” 这句话出自哪里?
[原文] [Abraham]: Pinocchio right and Pinocchio as soon as the lonely Carpenter jepetto paints a mouth and he starts talking words he's convinced that he's just one step away from being a real boy because he could talk and if you could talk then you're you're almost there practically you're just you're about to be a uh a real boy uh and he discovers uh that it takes quite a bit of pain and adventure and excitement and the road to becoming a real boy is is not all that not all that simple,
[译文] [Abraham]: 皮诺曹,对吧。皮诺曹在孤独的木匠杰佩托(Geppetto)刚给他画上嘴巴、他开始说话的那一刻,就确信自己离成为一个真正的男孩只有一步之遥了。因为他能说话,如果你能说话,那你几乎就已经到了,实际上你马上就要成为一个……真正的男孩了。但他后来发现,这一过程需要经历相当多的痛苦、冒险和刺激,成为真正男孩的道路并不是……并不是那么简单。
[原文] [Abraham]: uh one of the things that a challenge when preparing a talk about about AI is to as you're preparing to talk you want to say something that'll still be relevant in a year or in a month or in a week or will still be relevant by the time you give the talk so you're preparing the talk but as the world doesn't stop and wait for you to prepare your talk the the world goes on,
[译文] [Abraham]: 准备关于 AI 的演讲时,挑战之一在于,当你准备演讲时,你想说一些在一年后、一个月后、甚至一周后仍然相关的东西,或者至少在你发表演讲时仍然相关的东西。所以你在准备演讲,但世界不会停下来等你准备,世界在继续前进。
[原文] [Abraham]: uh so rather than tell you about what AI is going to do or how it's going to be which I'll do some of but it'll be very tentative I'm going to tell you about my journey my journey throughout a i and what I've learned along the way and where I am some mistakes I've made and some good things I've done and I will make some predictions about the future just because I can uh and there's no shame anymore in admitting that AI helped you put put a talk together everybody does it I do it too and I'm going to be showing some prompts during the uh during the talk,
[译文] [Abraham]: 所以,与其告诉你们 AI 将要做什么或它将会变成什么样——虽然我会涉及一些,但这将是非常试验性的——我打算告诉你们我的旅程,我在 AI 领域的旅程,我沿途学到了什么,我现在处于什么位置,我犯过的一些错误和我做过的一些好事。我会对未来做一些预测,仅仅是因为我可以。承认 AI 帮助你整理了演讲内容不再是什么丢脸的事了,每个人都这么做,我也这么做,我会在演讲中展示一些提示词(prompts)。
[原文] [Abraham]: so I'm preparing a talk for a conference that will explore if and how generative AI can replace a software architect what interest points that you suggest I mention and I work with Gemini and Gemini gave me some interesting ideas and I'm going to use them it said explore the potential for collaboration between human Architects and AI systems I'll do that consider questions related to accountability bias transparency highlight areas where human expertise and judgment are still indispensable,
[译文] [Abraham]: 所以(我在提示词中写道):我正在为一个会议准备演讲,探讨生成式 AI 是否以及如何取代软件架构师,你建议我提及哪些兴趣点?我用的是 Gemini,Gemini 给了我一些有趣的想法,我会用到它们。它说:探讨人类架构师与 AI 系统之间协作的潜力——我会这么做的;考虑与问责制、偏见、透明度相关的问题;强调人类专业知识和判断力仍然(still)是不可或缺的领域。
[原文] [Abraham]: and that still really got me what does that still mean right it's it's as though it's the Pinocchio talking right that means I I'll give you that for now you're you're indispensable but it might not tomorrow I cease to be a puppet and I'll be a real boy
[译文] [Abraham]: 那个“仍然(still)”真的触动了我。那个“仍然”意味着什么?对吧,这就好像是皮诺曹在说话,对吧?那意味着:我现在暂时承认你是不可或缺的,但也可能不是——“明天我将不再是个木偶,我将成为一个真正的男孩。”
这是为您整理的第2章内容。本章主要阐述了本次演讲的结构框架,更重要的是,演讲者重新定义了架构师的“核心资产”,将“人”置于比书籍和AI更高的维度。
📝 本节摘要:
Abraham 概述了演讲的四大板块:个人介绍、AI/LLM 背景、架构师的角色定义,以及人机协作的案例研究。在介绍自己时,他强调架构师最宝贵的资源并非工具,而是其他人——那些聪明、多样且慷慨的同行。他将架构师的知识库划分为三个层级:最重要的“人”、沉淀下来的“书籍与文章”,以及最新加入的“LLM”。他将此次探索定义为一段学习如何将 LLM 纳入其资源库的旅程。
[原文] [Abraham]: and this we're going to do today in the talk I'm going to tell you a bit about how I am who I am and why this is interesting to me I'm going to give you some background on AI and llms from my particular perspective and then I want to talk about what it is that an architect does because if I'm going on a journey and the two partners in Journey are me and the llm I want to explore what is me and what is the llm and then I could talk about a case study case study will be about 20 minutes I'll show some examples of how I and the llm or the llm and I cooperated to do something interesting and summary and if we end on time then maybe we'll even have time for a question or two,
[译文] [Abraham]: 这就是我们今天在演讲中要做的事情。我会告诉你们一点关于我是谁、以及为什么这对我来说很有趣;我会从我个人的独特视角给你们一些关于 AI 和 LLM 的背景知识;然后我想谈谈架构师到底是做什么的,因为如果我要踏上一段旅程,而这段旅程的两个伙伴是我和 LLM,我想先探索一下什么是“我”,什么是“LLM”;然后我会谈一个案例研究,案例研究大约 20 分钟,我会展示一些我和 LLM、或者说 LLM 和我如何合作做一些有趣事情的例子;最后是总结,如果我们准时结束,也许我们甚至还有时间回答一两个问题。
[原文] [Abraham]: so who am I I'm an architect I've been architect for for many decades and I am interested fascinated I like teaching and learning about how people create uh software and as an architect my best resource by far that um that is better than any other resource available to me my my best resource is other people other people the people around me they're smart they're funny they're curious they're diverse they're experienced they know all kinds of things and and they're generous with their time and I learn a lot from them and they are the ones that help me become a good and ultimately a better architect that's one resource,
[译文] [Abraham]: 那么,我是谁?我是一名架构师,我已经做了几十年的架构师了。我有兴趣,甚至可以说着迷于——我喜欢教学和学习人们是如何创造软件的。作为一名架构师,我目前为止最好的资源——这比任何其他我可以获得的资源都要好——我最好的资源是其他人。其他人,我周围的人,他们聪明、风趣、好奇、多样化、经验丰富,他们知道各种各样的事情,而且他们对自己的时间很慷慨。我从他们那里学到了很多,正是他们帮助我成为一个好的、并最终成为一个更好的架构师。那是第一类资源。
[原文] [Abraham]: another resource is all the knowledge that has been gathered by software Architects all the books all the Articles all the blogs and then a third re resource that recently joined this journey is the llms and I'm trying to work with the llm as a resource for me as an architect to help me make me into a better architect and that is my journey so we're going to talk a bit about Ai and lln what is an architect and then we'll combine them into a a case study or some examples,
[译文] [Abraham]: 另一类资源是所有由软件架构师们收集的知识:所有的书、所有的文章、所有的博客。然后,最近加入这段旅程的第三类资源是 LLM(大语言模型)。我正在尝试将 LLM 作为一个资源来与我协作,作为一名架构师,让它帮助我成为一个更好的架构师。这就是我的旅程。所以,我们将谈论一点 AI 和 LLM,谈论什么是架构师,然后我们将把它们结合到一个案例研究或一些例子中。
这是为您整理的第3章内容。本章梳理了从机械计算到现代AI的历史脉络,重点探讨了“机器能否思考”这一核心命题的演变。
📝 本节摘要:
Abraham 回顾了计算科学的起源,从查尔斯·巴贝奇设计的差分机与分析机,到艾达·洛夫莱斯编写的第一个程序——她天才地意识到状态机不仅能响应运动,还能实现算法。演讲者将这一技术突破与同时期关于“人造人”(如皮诺曹)的文学想象联系起来。随后,他对比了生物与机器在能量转换上的本质区别:人类能将能量转化为“思想”,而传统机器只能转化为“功”。最后,他指出图灵测试在当代的讽刺性反转:判断依据不再是机器是否足够聪明,而是它是否“足够愚蠢”以至于像个人类。
[原文] [Abraham]: so some background on AI llms we know all this stuff I'm just giving it from my perspective the journey somewhere starts about in the 1860s with the differential engine the analytical engine um made by uh designed it's not made designed by a fellow named Charles babage on the right side of the screen we see the computer that helped solve the uh Enigma codes
[译文] [Abraham]: 所以,先来点关于 AI 和 LLM 的背景知识——我们要知道这些东西,我只是从我的角度来阐述。这段旅程大约开始于 19 世纪 60 年代,始于差分机(Differential Engine)和分析机(Analytical Engine)……由一个名叫查尔斯·巴贝奇(Charles Babbage)的人设计——不是制造,是设计。在屏幕右侧,我们可以看到帮助破解恩尼格玛(Enigma)密码的计算机。
[原文] [Abraham]: and one of the people that starts this journey uh this this differential engine analytical engine is a machine that knows how to do calculations in a mechanical way and one of the important people in in the uh analytical engine is somebody by the name of AD LEL lady Lovel and uh this this might be considered the first program it's sometimes known as a endix G so lady love lace or AA love lace translated Charles babbage's work from French to English and in the appendix she wrote an example of how to use the analytical engine to calculate bruli numbers and that is considered the first computer
[译文] [Abraham]: 开启这段旅程的人之一……这个差分机、分析机是一种知道如何以机械方式进行计算的机器。而在分析机方面,最重要的人物之一是一位名叫 Ada Lovelace(艾达·洛夫莱斯)的人,即 Lovelace 夫人。这可能被认为是第一个程序,有时被称为“附录 G”(Appendix G)。Lady Lovelace 或 Ada Lovelace 将查尔斯·巴贝奇的著作从法语翻译成英语,并在附录中写了一个关于如何使用分析机计算伯努利数(Bernoulli numbers)的例子,这被认为是第一段计算机……
[原文] [Abraham]: program it's an instruction on how to use the differential the the analytical engine in order to compute uh bruli bruli numbers and very often the uh Genius of babage and love La is considered she wrote a program for a computer that didn't exist in a language that didn't exist for an operating system that didn't exist it's considered a feat of abstraction the differential engine even though Charles babage designed it he couldn't build one
[译文] [Abraham]: ……程序。它是一条关于如何使用差分……分析机来计算伯努利数的指令。通常,巴贝奇和 Lovelace 的天才之处被认为在于:她为一个不存在的计算机、用一种不存在的语言、为了一个不存在的操作系统编写了一个程序。这被认为是一种抽象的壮举。尽管查尔斯·巴贝奇设计了差分机,但他无法制造出一台。
[原文] [Abraham]: because he couldn't find a Miller that was able to make gears in the quality that he needed to drive his machine the machine was only Built by a group of students in the in the British museum towards the year 2000 it took 120 years for this machine uh to be built but there's something else an important important uh achievement of ADA lovelies before Charles babage people knew about State machines State machines were driven by motion and
[译文] [Abraham]: 因为他找不到一个铣工能制造出他驱动机器所需质量的齿轮。这台机器直到接近 2000 年才由大英博物馆的一群学生建造出来。这台机器花了 120 年才建成。但这还有别的东西,Ada Lovelace 的一个非常非常重要的成就。在查尔斯·巴贝奇之前,人们就知道状态机(State Machines)。状态机由运动驱动,并且……
[原文] [Abraham]: typically counted a clock is a state machine now watch a clock is driven by a pendulum the pendulum swings you count you count minutes seconds hours days months even years a typewriter is a is a kind of a state machine a there were looms weaving that knew how to do elaborate patterns based on state machine they knew State machines a a love la realized that motion can drive a state machine and that the state machine can Implement an algorithm and to us that seems obvious
[译文] [Abraham]: ……通常用于计数。时钟就是一个状态机。看,时钟由钟摆驱动,钟摆摆动,你计数——你计算分钟、秒、小时、天、月甚至年。打字机也是一种状态机。还有织布机,它们知道如何基于状态机编织复杂的图案。他们了解状态机。Ada Lovelace 意识到,运动可以驱动状态机,而状态机可以实现算法。这对我们来说似乎显而易见。
[原文] [Abraham]: but then that was the Breakthrough the Breakthrough that enabled all of computer science until today the state machine that could Implement an algorithm and it's about the same time that stories about manmade thinking objects started coming onto the scene stories like Pinocchio and Frankenstein and uh the the the gollum of Prague and later on the Tin Man from The Wizard of AZ people are exploring what could some what would a man-made man do be what
[译文] [Abraham]: 但在当时,那是突破,是开启了直到今天的所有计算机科学的突破——即可以实现算法的状态机。也就是在大约同一时间,关于人造思维物体的故事开始出现在舞台上。像《皮诺曹》、《弗兰肯斯坦》,还有布拉格的《戈勒姆》(Golem),以及后来的《绿野仙踪》中的铁皮人。人们在探索,一个人造的人会做什么?是什么?
[原文] [Abraham]: would it look like what would be the dangers or opportunities in uh in such a thing and a lot of these stories are of course dystopian just like today we have stories in movies about Ai and what will happen uh with AI and the modern data center one that one that embeds uh an llm or an AI system is really just the state machine a state machine with memory exactly 50 years um before the 50 years ago want to look at the energy equation before the uh the um AI came on
[译文] [Abraham]: 它看起来会像什么?这样东西会有什么危险或机遇?当然,很多这类故事都是反乌托邦的,就像今天我们在电影中有关于 AI 的故事,以及 AI 会发生什么。而现代数据中心,那个嵌入了 LLM 或 AI 系统的数据中心,实际上只是一个状态机,一个带有内存的状态机。正好在 50 年前……或者说看看 AI 出现之前的能量方程。
[原文] [Abraham]: board animals and humans and machines knew how to convert energy into work and as a matter of fact in the equation we we equate energy and work the units are the same calories Jewels watts are all units of energy and energy and work a lot of the energy today is carb based energy and it's the human that knows how to convert energy into articulated thought no machine knows how to do that machines and humans convert energy into work humans know how to convert like
[译文] [Abraham]: 动物、人类和机器知道如何将能量转化为“功”(work)。事实上,在方程中,我们将能量和功等同起来,单位是一样的:卡路里、焦耳、瓦特都是能量的单位。而能量和功……今天很多能量是基于碳水化合物的能量,只有人类知道如何将能量转化为清晰的“思想”。没有机器知道如何做到这一点。机器和人类将能量转化为功,但人类知道如何转化……就像……
[原文] [Abraham]: this high school student she eats cheeseburgers and she does her homework and that is a uh uh that is a human kind of activity um the data center now knows how to take energy and convert it into thought but we don't yet understand the written by an AI engine she will say the paper is too good to have been written by a human being the paper must have been written by a GPT that means not is it as good as a human it's too good so the touring test became not one of is it
[译文] [Abraham]: ……这位高中生,她吃芝士汉堡,然后她做作业,这是一种人类活动。数据中心现在知道如何获取能量并将其转化为“思想”,但我们还不理解……(话题转换到图灵测试)如果现在有人看到一篇由 AI 引擎写的论文,她会说:“这篇论文写得太好了,不可能是人类写的。这篇论文一定是 GPT 写的。”这意味着,问题不再是“它和人类一样好吗”,而是“它太好了”。所以图灵测试变成了……
[原文] [Abraham]: good enough but is it stupid enough and uh he ends by making some interesting remarks we may hope I don't know why he uses the word hope here we may hope that machines will eventually compete with men again that word he means compete with people uh in touring's time you know men we compete with people in all purely intellectual fields and then he says we could only see a short distance ahead but we can see plenty there that needs to be done again I don't know why
[译文] [Abraham]: ……不再是“它是否足够好”,而是“它是否足够愚蠢”。最后他(图灵)做了一些有趣的评论:“我们可以希望”——我不知道他为什么在这里用“希望”这个词——“我们可以希望机器最终能在所有纯智力领域与人竞争”。他又用了“男人(men)”这个词,也就是人的意思,你知道在图灵那个时代……接着他说:“我们只能看到前方很短的距离,但我们可以看到那里有很多事情需要做。”
[原文] [Abraham]: needs to be done but it will be done and after the touring test then other questions started coming up can AI have be Consciousness Can it have can it be conscious can it be conscientious can it be original will it take all our jobs will it take over the world I don't know the answer to those questions I'm not going to answer them today for today's talk I want to focus a bit on what abilities do we have that machines do not have
[译文] [Abraham]: 同样,我不知道为什么是“需要做”,但它终将被完成。在图灵测试之后,其他问题开始浮现:AI 能有意识吗?它能是有良知的吗?它能是原创的吗?它会抢走我们所有的工作吗?它会接管世界吗?我不知道这些问题的答案,我今天也不打算回答它们。在今天的演讲中,我想重点谈谈我们拥有而机器目前尚不具备的能力。
📝 本节摘要:
Abraham 使用一把吉他(或其图片)作为隐喻,指出乐器本身不是音乐,产生音乐需要“乐器+演奏者”。他解释了 LLM 的本质是基于文本权重的概率模型,而人类拥有基于遗传、文化和独特经验的“世界模型”。他引用《木偶奇遇记》中蓝仙女的要求——“勇敢、诚实、慷慨”,论证了 LLM 无法具备这些特质,尤其是“慷慨”,因为慷慨的前提是拥有有限的资源(如人类的时间),而 AI 并不受此限制。最后,他批评了 AI 使用“我们”或“我们的社会”这类群体认同词汇的荒谬性。
[原文] [Abraham]: object this is not music in order for this to be music to inspire somebody to make somebody moved or cry or feel emotional I need at the very very least an instrument and a musician if I don't have an instrument in a musician this is some sort of representation or abstraction of Music there are some people that know how to think or experience this as music but most of us don't know how to do it even this is not music it's a picture of somebody playing a guitar this is music this is really really music the instrument is my mey player and the or my player and it knows how to play music that's human
[译文] [Abraham]: (指着物体)这不是音乐。为了让它成为音乐,为了去激励某人,让某人感动、哭泣或产生情绪,我最起码需要一件乐器和一个音乐家。如果我没有乐器和音乐家,这只是音乐的某种表象或抽象。有些人知道如何将其思考或体验为音乐,但我们大多数人不知道怎么做。甚至这个(指图片)也不是音乐,这是一张某人弹吉他的照片。这(指实际演奏)才是音乐,这才是真正的音乐。乐器是我的……演奏者,或者说我的播放器,它知道如何演奏音乐。那是人类(的特质)。
[原文] [Abraham]: llms are interested in the relationship between texts between text words and they're weighted relationships that means an apple has a relationship to fruit and to red and to tree and they're all weighted and this is very very uh oversimplified of course a real uh a real map in an llm is huge is huge and one of the things about this model is even though it's a model of relationships between words it works astonishing well astonishingly well draw droppingly well but it's just relationships between words
[译文] [Abraham]: LLM 关注的是文本之间的关系,是文本词汇之间的关系,它们是加权关系(weighted relationships)。这意味着“苹果”与“水果”、“红色”和“树”都有关系,而且它们都是加权的。当然,这非常非常简化……LLM 中的真实映射是巨大的,巨大的。关于这个模型的一件事是,尽管它只是一个词汇之间关系的模型,但它运作得惊人地好,令人惊叹地好,好得让人下巴掉下来。但它仅仅是词汇之间的关系。
[原文] [Abraham]: now why written language written language has many many advantages uh first of all there's a lot of it computers are quite good at written language computers are the best at binary numbers zeros and ones they're okay at decimal numbers they're reasonably good at Unicode or asky but once it comes to to audio sound computers already are still struggling computers are good there's a lot less context in written langu so if I say a simple sentence like I'm happy to be here so everybody knows abam was standing on the stage on October 14th in Barcelona giving a talk about Ai and he was happy to be here and you know the context
[译文] [Abraham]: 那么,为什么是书面语言?书面语言有很多很多优势。首先,它的量很大。计算机非常擅长处理书面语言。计算机最擅长二进制数(0和1),它们处理十进制数还可以,处理 Unicode 或 ASCII 也相当不错,但一旦涉及到音频声音,计算机就已经在挣扎了。计算机擅长(书面语言的另一个原因是):书面语言中的语境要少得多。所以如果我说一个简单的句子,比如“我很高兴来到这里”,大家都知道 Abraham 在 10 月 14 日站在巴塞罗那的舞台上发表关于 AI 的演讲,他很高兴来到这里,你们知道这个语境。
[原文] [Abraham]: if we write the sentence in a text I am happy to be here then you have to immediately ask the question who said it and when and in what context and where was he standing when he said it so written Corpus has that context if you read a statement if you read a statement I'm happy to be here in a book you'd say this is not interesting I need to know who said it in where and when and it's there and it lasts a long time it lasts a lot longer than written texts
[译文] [Abraham]: 如果我们在文本中写下这句话“我很高兴来到这里”,那你必须立刻问这个问题:谁说的?什么时候说的?在什么语境下?他说这话时站在哪里?书面语料库包含这种语境。如果你读到一个陈述,如果你在一本书里读到“我很高兴来到这里”,你会说这没意思,我需要知道是谁在何时何地说的。它就在那里,而且它持续很长时间,比(口语)文本持续的时间长得多。
[原文] [Abraham]: if I compare the llms to the human I'll see the following the llm the engine at large has its structure it has the text that trained it it has the prompts and the information that come in the information might be the rag it has other tools that it might have access to the calculator or the Google Maps or the uh worldwide web and its output is text simplified model of an llm
[译文] [Abraham]: 如果我把 LLM 和人类做比较,我会看到以下情况:LLM,作为一个整体引擎,有它的结构,有训练它的文本,有输入的提示词(prompts)和信息——这些信息可能是 RAG(检索增强生成);它还有它可以访问的其他工具,比如计算器、谷歌地图或万维网;而它的输出是文本。这是 LLM 的简化模型。
[原文] [Abraham]: now a model of me for by way of example so I am comprised by my genetics my culture and my experiences that's who I am and that's what makes me pretty unique because I doubt there's anybody else in the crowd that has my genetics my culture and my uh experience so I'm I'm a unique kind of person my inputs are all the things that happen to me and my thoughts and my outputs are my thoughts and my actions and then I'm able to do something and that's what makes me very very different than uh uh in llm and my world model is not text based my world model is all kinds of things based I don't even know what the word is
[译文] [Abraham]: 现在,以我为例,这是我的模型。我是由我的遗传基因、我的文化和我的经历组成的。这就是我,这也是让我变得相当独特的原因,因为我怀疑人群中还有其他人拥有我的基因、我的文化和我的经历。所以我是一个独特的人。我的输入是所有发生在我身上的事情和我的思想,我的输出是我的思想和我的行动,然后我能够做一些事情。这就是让我与 LLM 非常非常不同的地方。我的世界模型不是基于文本的,我的世界模型是基于各种各样事物的,我甚至不知道那个词该叫什么。
[原文] [Abraham]: and I use tools too my my genetics is about as long as 2 million years old we have genetic material that's very very ancient my culture is probably as old as language and uh my experiences are mine they're as long as I have been living and as long as I will live now if I compare Now llm versus the human I might notice the fact that llms they're cheap they're fast they're scalable you can make one you could make many humans are expensive relatively they are very reactive llms will only answer a question if asked I have never had an llm just send me an email saying you know I was thinking about what we said yesterday I have a question for you
[译文] [Abraham]: 而且我也使用工具。我的基因大约有 200 万年的历史,我们拥有的遗传物质非常非常古老;我的文化可能和语言一样古老;而我的经历是属于我的,只要我活着,它就一直存在。现在,如果我比较 LLM 和人类,我可能会注意到:LLM 便宜、快速、可扩展,你可以制造一个,也可以制造很多。人类相对昂贵。LLM 非常被动(reactive),它们只有被问到时才会回答问题。我从来没遇到过一个 LLM 主动给我发邮件说:“你知道吗,我在思考我们昨天说的话,我有个问题想问你。”
[原文] [Abraham]: they are not they they're they're reactive they're risk averse because they operate based on weights... I understand I'm able to take knowledge and apply it into new context I'm able to take knowledge and apply it into new ways and because of that I know how to take general knowledge and apply it to a very very specific uh situation so I know how to be specific
[译文] [Abraham]: 它们是被动的。它们是规避风险的,因为它们基于权重运作……(人类不同),我理解事物,我能够获取知识并将其应用到新的语境中,我能够获取知识并以新的方式应用它。正因为如此,我知道如何获取通用知识并将其应用到一个非常非常具体的情境中。所以我知道如何变得“具体”。
[原文] [Abraham]: the Blue Fairy tells Pinocchio if you are to become a real boy you must be brave true and generous the ultimate generous generosity you can only be generous if you have a limited resource people that are not resource constrained can't be generous because they're not resource constrained my most constrained resource is my time probably for many of you too so if you're giving somebody time and attention you're being generous with a resource that is non-renewable that is that is very rapidly uh depleting and you can become a real boy
[译文] [Abraham]: 蓝仙女告诉皮诺曹:“如果你想成为一个真正的男孩,你必须勇敢、诚实和慷慨。” 终极的慷慨……你只有在拥有有限资源的情况下才能是慷慨的。没有资源约束的人无法表现出慷慨,因为他们不受资源限制。我最受限的资源是我的时间,对你们许多人来说可能也是。所以,如果你给予某人时间和关注,你就是在慷慨地使用一种不可再生的、正在非常迅速地耗尽的资源。这样你才能成为一个真正的男孩。
[原文] [Abraham]: and I know Architects and programmers and many many others that have clearly been touched by the Blue Fairy and they are brave true and generous I haven't yet seen an llm that knows how to be brave true and and generous... I know llms that know how to emulate or simulate kind speech as a matter of fact they sometimes overdo it a little and a life of service and compassion only means something if you have a life
[译文] [Abraham]: 我认识一些架构师、程序员和许多其他人,他们显然被蓝仙女点化过,他们勇敢、诚实且慷慨。我还没有见过一个知道如何勇敢、诚实和慷慨的 LLM……我知道有些 LLM 懂得如何模仿或模拟友善的言辞,事实上它们有时做得有点过头了。但“服务和同情的生活”只有当你拥有生命时才有意义。
[原文] [Abraham]: so I want to talk briefly about group identity I know how to use the word we or our or us and I know how to use it correctly when I say we I don't mean a group of individuals I mean an aggregate of individuals that thinks or does something and I have not seen often the llm use the word we and when the llm does use the word we it I it bothers me
[译文] [Abraham]: 所以我想简短谈谈群体认同(group identity)。我知道如何使用“我们”、“我们的”或“咱们”这些词,而且我知道如何正确使用。当我说“我们”时,我指的不是一群个体,而是指一个思考或行动的个体集合。我很少看到 LLM 使用“我们”这个词,而当 LLM 真的使用“我们”时,这让我很困扰。
[原文] [Abraham]: this is a conversation I had with Claude on a totally different subject... and I said when you say our society what do you mean by the word our you're in an llm you don't belong to a society and again that's the Pinocchio coming out he thinks e it she I don't know what the pronoun is but the the llm thinks that it belongs to a society and it has the right of using Collective words it doesn't and as we've all experienced oh I'm sorry as an as an AI language model I don't belong to any society so that's about group identity
[译文] [Abraham]: 这是我和 Claude 在一个完全不同的话题上的对话……我说:“当你说‘我们的社会’时,你用‘我们的’这个词是什么意思?你是个 LLM,你不属于一个社会。” 再一次,那是皮诺曹的本性显露出来了。他、它、她——我不知道代词该用哪个——但 LLM 认为它属于一个社会,并且有权使用集体词汇。它没有。正如我们都经历过的,(它会回复): “哦,我很抱歉,作为一个 AI 语言模型,我不属于任何社会。” 好的,关于群体认同就说到这里。
📝 本节摘要:
在了解了 LLM 的本质后,Abraham 转而探讨“我”作为架构师的定义。他指出,架构师不仅要掌握技术,更要关注人、组织与商业领域,维护系统的“概念完整性”,。他强调,架构师最大的权力往往不在于做具体决定,而在于“决定谁来做决定”。随后,他引用 Eoin Woods 和 Nick Rozanski 的理论,将架构师的生命周期概括为三个高度迭代的阶段:思考(分析)、绘制(表达)和捍卫(沟通)。这一过程要求架构师同时具备分析能力、绘图技巧以及修辞与共情能力,且在面对错误时应选择学习而非辩解,,。
[原文] [Abraham]: sorry what does an architect do cuz now I know what an llm is but now I don't know what i is so let's talk a bit about what what I do and there are many many things that an architect does but what's common to them is that they have some wider picture a picture that involves technology and involves people and involves domains and involves organizations and involves problems
[译文] [Abraham]: 抱歉,架构师到底是做什么的?因为现在我知道 LLM 是什么了,但我反而不知道“我”是什么了。所以让我们聊聊我是做什么的。架构师做很多很多事情,但它们的共同点是:他们拥有一张更宏大的图景——这张图景涉及技术,涉及人,涉及领域,涉及组织,也涉及问题。
[原文] [Abraham]: and one of the things that an architect does is he maintains or she maintains some sort of conceptual Integrity some sort of holistic viewing and they try to see the future and they try to Mentor other Architects but if I dive in a little and this is a very very partial list the architect before they architected a single project they have to understand the patterns and the practice and I use the word understand deliberately here they have to understand or they have to go to this conference to Gess or to other conferences and learn what architecture
[译文] [Abraham]: 架构师做的一件事是,他或她要维护某种概念完整性(Conceptual Integrity),某种整体性的视角。他们试图预见未来,试图指导其他架构师。但如果我深入一点——这是一个非常非常局部的清单——架构师在架构任何一个项目之前,必须先理解模式和实践。我在这里特意使用了“理解”这个词。他们必须理解,或者他们必须去参加这个会议,去 GSAS 或者其他会议,去学习什么是架构。
[原文] [Abraham]: consider the options and the trade-offs and you decide and you act and you correct and even this is grossly grossly oversimplified uh because Andrew did an adequate job more than adequate job of of describing it to us but the thing is and that's the point that I learned from Andrew's talk is there's a lot of power and authority and responsibility not in deciding but in deciding who gets to decide and deciding that there is a decision to be made
[译文] [Abraham]: ……考虑选项和权衡,然后你做决定,你行动,你修正。甚至这也还是被极度、极度简化了。Andrew 已经做了足够好的、甚至超出足够好的工作来向我们描述它。但关键在于——这也是我从 Andrew 的演讲中学到的一点——巨大的权力、权威和责任,不在于“做决定”,而在于“决定由谁来做决定”,以及“决定有一个决定需要被做出”。
[原文] [Abraham]: and the architect that does that carries a lot in her hands she's doing a great deal of of of influence impact on the project now what does the S software architect have it's a lot I'm not going to go through the whole list but the software architect if she's good she has communication abilities she understands General versus specific intuitively deeply she has a lot of knowledge and experience all the Architects I know learned learned a lot they have contextual awareness they will never take a law or they shouldn't take a law a rule or a practice and implement it out of context
[译文] [Abraham]: 做到这一点的架构师手中掌握着很多东西,她对项目施加了巨大的影响。那么软件架构师拥有什么?很多东西。我不打算把整个清单过一遍,但如果一个软件架构师是优秀的,她拥有沟通能力;她直觉地、深刻地理解“通用”与“具体”的区别;她拥有大量的知识和经验——我认识的所有架构师都学到了很多东西;他们拥有语境意识(contextual awareness),他们绝不会——或者说不应该——拿来一条定律、规则或实践,然后在脱离语境的情况下实施它。
[原文] [Abraham]: they understand trust trust means I know how to behave in a way that will inspire you to trust me and if you trust me you will trust my artifacts you will trust my advice you'll trust my decisions and I know how to give other people trust and trust them and trust their integrity... mistakes if we're good Architects we don't defend them we don't apologize we don't defend we learn we learn what we can learn and we move on
[译文] [Abraham]: 他们理解信任。信任意味着我知道如何行事才能激发你对我的信任;如果你信任我,你就会信任我的工件(artifacts),你会信任我的建议,你会信任我的决定。而且我也知道如何给予他人信任,信任他们,信任他们的正直……(关于)错误,如果我们是优秀的架构师,我们不会为错误辩护。我们不道歉(指无意义的道歉),我们不辩解,我们学习,我们学到我们能学到的,然后我们继续前进。
[原文] [Abraham]: now this is an idea I took from Owen's book on software architecture systems about the simplified and partial life cycle of an architect there's a great book written maybe 10 12 years ago software architecture systems by Owen and Owen woods and rosanski right and um the first thing the architect does is they think this is when the project starts before this started the architect learned and thought and went to the lectures and went to the workshops and became an architect now the architect starts so the first thing she does is she thinks she analyzes she studies the domain they don't write a single diagram yet they they think in their head and this happens in the shower in the car and you input all the information you start creating a mental model
[译文] [Abraham]: 这是一个我从 Owen(注:应为 Eoin Woods)关于软件架构系统的书中借用的概念,关于架构师的简化和部分生命周期。有一本很棒的书,大约写于 10 到 12 年前,叫《软件系统架构》(Software Systems Architecture),作者是 Eoin Woods 和 Nick Rozanski。架构师做的第一件事是“思考”。这是项目启动的时候。在启动之前,架构师已经学习、思考、参加讲座、参加研讨会并成为了架构师。现在项目开始了,所以她做的第一件事是思考,她分析,她研究领域。他们还不会画任何一张图,他们在脑海中思考。这发生在淋浴时、车里。你输入所有信息,你开始建立一个心智模型。
[原文] [Abraham]: the second part is you now have to create a representation you have to draw something you draw something on the Whiteboard you draw something in the Vio in the draw. in the mermaid in viio sorry in the in the mermaid or in the draw. once you've thought it out and put a partial model because all Marshals all models are partial you then defend the architecture and present and explain it and and to argue about it and discuss it and your ultimate output if you did all the stages is some agreement some understanding some shared model
[译文] [Abraham]: 第二部分是你现在必须创建一个表象(representation)。你必须画点什么。你在白板上画,你在 Visio 里画,在 Draw.io 里画,在 Mermaid 里画——抱歉,是在 Mermaid 或 Draw.io 里。一旦你想清楚了并建立了一个局部模型——因为所有的模型都是局部的——接下来你要“捍卫”架构,去展示它,解释它,去辩论它,讨论它。如果你完成了所有阶段,你的最终输出是某种达成的一致,某种理解,某种共享模型。
[原文] [Abraham]: now this is highly highly iterative and I for matter for reasons of convenience I put it in three distinct stages but it's not distinct it's always happening all the time we're thinking and drawing and presenting and thinking and drawing and presenting and we're doing them all at once so it's not three chronological stages or three stages in time rather it's three parts of the the architect's life cycle and it has three different skill sets in order to do it we need to think and the skill is needed there are thinking skills analytical skills listening skills abstraction skills we need to draw so we need our drawing skills and we need to draw the appropriate drawing and then we have to defend our skills and that calls on our rhetorical skills and our empathetic skills
[译文] [Abraham]: 这其实是高度、高度迭代的。为了方便起见,我把它分成了三个明显的阶段,但它们并不是截然分开的。它一直在发生,我们思考、绘制、展示,再思考、绘制、展示,我们同时也都在做这些事。所以这不是三个按时间顺序的阶段,而是架构师生命周期的三个部分。并且为了做到这一点,它需要三种不同的技能组合:我们需要思考,所需的技能是思维技能、分析技能、倾听技能、抽象技能;我们需要绘制,所以我们需要绘图技能,我们需要画出恰当的图;然后我们需要捍卫我们的观点,这需要调用我们的修辞技能和共情技能。
📝 本节摘要:
Abraham 进入案例研究环节,但他并没有演示如何用 AI 画图,而是关注如何用它辅助“思考”和“分析”。他演示了一个具体场景:输入一条模糊的需求“系统应能处理大量用户”,让 Claude 识别其中的歧义。Claude 敏锐地指出这可能指“并发用户”或“注册用户总数”。更有趣的是,在询问如何解决该歧义时,Claude 给出了一个令团队分裂的建议——“设计同时处理两种情况的架构以降低风险”。这一“意外”的建议引发了关于敏捷与成本的激烈讨论。
[原文] [Abraham]: so now I spoke about in llm llm knows how to do a lot of stuff with a lot of words I spoke the architect the architect makes lots of mistakes and tries to create a model tries to create a cohesive contextual or or conceptual Integrity now I want to dive into the case study and that will be until the end of the talk and then we'll take some questions perhaps so first of all I want to focus I'm not going to focus on drawing we heard great talks about that and it's hard for me to say something new there so I'm going to talk about the other extremes about using an llm to Aid with the thinking or the learning or the listening or the analysis of the domain and to use Us in llm with presenting and defending and explaining and teaching and and listening that's where I have uh made some my unique contribution to this uh to this discussion or where I have had some some interesting results or I've learned something
[译文] [Abraham]: 刚才我谈到了 LLM,LLM 懂得如何用大量的词汇做很多事情;我也谈到了架构师,架构师会犯很多错误,并试图建立模型,试图创造一种连贯的语境或概念完整性。现在我想深入探讨案例研究,这将持续到演讲结束,然后我们或许可以回答一些问题。首先我想强调,我不打算关注“绘图”,关于这一点我们已经听到了很多精彩的演讲,我很难在那方面说出什么新意。所以我打算谈谈另一个极端:利用 LLM 来辅助“思考”、“学习”、“倾听”或“领域分析”,以及利用 LLM 来进行“展示”、“辩护”、“解释”、“教学”和“倾听”。这是我对这个讨论做出一些独特贡献的地方,也是我获得一些有趣结果或学到东西的地方。
[原文] [Abraham]: and one thing I need to do is detect ambiguities I need to detect ambiguities in my own outputs and I need to detect ambiguities in other outputs and a lot of the bad assumptions that we make are bad assumptions about ambiguities we read something read something that said what I meant it to say but it didn't it had it was ambiguous and I just forced my convenient or my default interpretation on the text
[译文] [Abraham]: 我需要做的一件事是“识别歧义”。我需要识别我自己输出中的歧义,也需要识别他人输出中的歧义。我们所做的很多糟糕的假设,都是关于歧义的糟糕假设。我们读到某些东西,以为它表达了我认为它要表达的意思,但实际上并非如此,它是模棱两可的,而我只是将我方便的、或者默认的解释强加给了文本。
[原文] [Abraham]: so here's an example I'm an architect that is designing a system that and the basic requirements are da da the system should be able to handle a large number of users can you identify any ambiguities in the above requirements this is not rag this is pure pure llm uh Avail publicly available llm can you identify any ambiguities in the above requirements and Claude says the requirement the system should be able to handle a large number of users has an ambiguity do you mean concurrency or do you mean total users
[译文] [Abraham]: 这是一个例子。我是一名架构师,正在设计一个系统,基本需求是……(略)……“系统应该能够处理大量用户(a large number of users)”。(提示词问):你能识别上述需求中的任何歧义吗?这不是 RAG(检索增强生成),这是纯粹的、纯粹的 LLM,公开可用的 LLM。Claude 回答说:需求“系统应该能够处理大量用户”存在歧义。你的意思是“并发(concurrency)”还是“总用户数(total users)”?
[原文] [Abraham]: another ambiguity that came out was the fact that the large of the word the words the the statement a large number of users is quite meaningless unless you have unless you have context but I'm want to focus so do you mean a large number of users at the same time or do you mean a large a number of users at the in the database perfectly good ambiguity
[译文] [Abraham]: 另一个出现的歧义是,“大量用户”这个说法实际上毫无意义,除非你有语境。但我想聚焦于此:你的意思是“同一时间的大量用户”,还是指“数据库中的大量用户”?这是一个非常完美的歧义识别。
[原文] [Abraham]: so I need help resolving the ambiguity once we have an ambiguity and we've identified it the next stage is to try to resolve an ambiguity I was given the ambiguous requirement the system should be able to handle a large number of users what is a what is a reasonable way for determining which interpretation to adopt and why so gather additional information that's a good one do some performance metrics and then it gave me something surprising and whenever an llm gives you something surprising it's a moment of pure delight or of some Delight because uh it it people surprise us all the time and we expect that but llms when they surprise us it's surprising
[译文] [Abraham]: 所以我需要帮助来解决这个歧义。一旦我们要么有了歧义并识别了它,下一个阶段就是尝试解决歧义。(我问):我收到了模糊的需求“系统应该能够处理大量用户”,确定采用哪种解释的合理方法是什么?为什么?它回答:收集更多信息——这是个好建议;做一些性能指标分析。然后,它给了我一些令人惊讶的东西。每当 LLM 给你一些令人惊讶的东西时,那是一个纯粹喜悦的时刻,或者是某种喜悦,因为……人类总是让我们惊讶,我们对此有预期,但当 LLM 让我们惊讶时,那是真的令人惊讶。
[原文] [Abraham]: so it says Identify potential bottlenecks consider which interpretation presents the bigger risk for the project if unsure it might be wise to design the architecture to handle both scenarios to some degree
[译文] [Abraham]: 它说:识别潜在瓶颈;考虑哪种解释给项目带来更大的风险;如果不确定,“设计能够某种程度上同时处理这两种情况的架构可能是明智的”。
[原文] [Abraham]: now I brought this to the team and I said team we have an ambiguity here we could do one or the other and we could try to gather more information and it gave me a lot more I'm not bringing it all or we could do both and the team divided into two factions one group said that is the most stupid un agile thing that we have ever heard if you have an ambiguous requirement to just go ahead and do both that is the most expensive way possible to resolve an ambiguity
[译文] [Abraham]: 我把这个带到了团队面前,我说:“团队,我们这里有个歧义。我们可以选这个或那个,我们也可以尝试收集更多信息——它给了我很多建议,我没全部列出来——或者我们可以‘两个都做’。” 团队分裂成了两派。一派说:“那是我们听过的最愚蠢、最不敏捷(un-agile)的事情。如果你有一个模糊的需求,却直接去把两个都做了,那是解决歧义最昂贵的方式。”
[原文] [Abraham]: and the other group said hey actually that makes a lot lot of sense if it's not too expensive start implementing both and actually maybe both are true maybe you have a concurrency and a large number of users requirements uh maybe both are true an ambiguous requirement doesn't always mean one or the other it might actually mean the system should be able to support a large number of users at the same time and over time but this was an example and now I'm not going to let the the llm decide for me how to resolve an ambiguity that that violates everything about professional account but I would let the llm help me decide so here's a cool example about resolving ambiguities
[译文] [Abraham]: 而另一派说:“嘿,实际上这非常有道理。如果不是太贵的话,开始同时实现两者。而且实际上也许两者都是真的,也许你既有并发需求,也有大量用户总数的需求。一个模糊的需求并不总是意味着‘非此即彼’,它可能实际上意味着系统应该能够在同一时间支持大量用户,并且在长期内支持大量用户。” 但这只是一个例子。我不会让 LLM 替我决定如何解决歧义,那违反了职业责任的所有原则,但我会让 LLM 帮助我做决定。这就是关于解决歧义的一个很酷的例子。
📝 本节摘要:
Abraham 探讨了架构设计的核心——权衡(Trade-offs)。他以经典的“消息队列 vs 直接通信”为例,向 LLM 寻求建议。虽然 LLM 提供了准确但通用的对比,甚至按惯例提出了“混合方案”,但它未能主动提出关键的上下文问题。Abraham 指出 LLM 忽略了“团队意愿”这一重要的人为因素。为了获取更有趣的视角,他进行了一项大胆的实验:让 LLM 模拟领域驱动设计(DDD)之父 Eric Evans 与音乐家贝多芬之间的辩论。结果令人惊叹,LLM 成功运用了“管弦乐队”的隐喻来阐述松耦合的概念。
[原文] [Abraham]: now I want to talk about trade-offs and this is an example that that appears in many many architect books and articles Neil had uh had mentioned this example in his talk I have I'm working cyber security say and I have a microservices based system so I have microservices one micros service collects the traffic and it talks to all kinds of other microservices that do different things on the traffic and I'm debating between a message or direct messaging option and a message cue option classical uh trade-off question and the answer is the only answer is it depends
[译文] [Abraham]: 现在我想谈谈权衡(trade-offs)。这是一个出现在许多许多架构书籍和文章中的例子,Neil 在他的演讲中也提到了这个例子。假设我在做网络安全方面的工作,我有一个基于微服务的系统。所以我有一些微服务,一个微服务负责收集流量,它与各种对流量进行不同处理的其他微服务进行通信。我在“直接消息传递”选项和“消息队列”选项之间犹豫不决。这是一个经典的权衡问题,而答案——唯一的答案是:视情况而定(It depends)。
[原文] [Abraham]: it depends on a lot of things it depends on the particulars of the project that you are working on the particulars of the team the particulars of the requirements it depends but what I need from the llm is help thinking about the tradeoffs and I wrote a long long long prompt and it the ultimate the question was I'm debating between using a message CU to communicate between the various Services uh between using a message CU to communicate between the various services or using direct communication to communicate between the two can you help clarify the trade-offs along with Arguments for each option and it did and it did an excellent job
[译文] [Abraham]: 它取决于很多事情。它取决于你正在处理的项目的细节、团队的细节、需求的细节。这得视情况而定。但我需要 LLM 帮助我思考这些权衡。所以我写了一个很长很长很长的提示词,最后的问题是:“我在使用消息队列在各种服务之间通信,还是使用直接通信在两者之间通信这两种方式之间犹豫不决。你能帮我阐明权衡点以及每个选项的论据吗?”它做到了,而且做得非常出色。
[原文] [Abraham]: but no matter how much more detail I gave again this is not rag so maybe rag would be different no matter how much more detail I gave the trade-offs didn't become better it was the same trade-offs that you read in the standard books about trade-offs it's useful it was very useful and it was correct so message CU based communication the pros and this is the same stuff that that Neil Neil Ford mentioned his talk the coupling scalability load balancing asynchronous procy and persistence and the cons increased complexity potential for latency you have eventual consistency that is correct this is all correct there's nothing wrong here and it gave me some good arguments
[译文] [Abraham]: 但是,无论我提供了多少细节——再次强调,这不是 RAG(检索增强生成),也许 RAG 会有所不同——无论我提供了多少细节,权衡分析并没有变得更好。它依然是你在标准书籍中读到的那些关于权衡的内容。这很有用,非常有用,而且它是正确的。关于基于消息队列的通信,其优点——这也是 Neil Ford 在他的演讲中提到的——包括解耦、可扩展性、负载均衡、异步处理和持久性;缺点则是增加了复杂性、潜在的延迟、最终一致性问题。这是正确的,这全都是正确的,这里没有任何错误,它还给了我一些很好的论据。
[原文] [Abraham]: now direct communication that's the other option the pros are Simplicity lower latency stronger consistency it's easier to debug and it really is and it has tighter coupling talked about the different types of coupling it's less uh failure resilient and it might overwhelm and it has some arguments and of course this is a thing that Claude tends to do other llms tend to do it as well if you present two options it suggests the hybrid option it has to suggest the hybrid option it almost like it went to uh to to mediating school or something like that and the win-win uh the win-win option comes up a
[译文] [Abraham]: 然后是直接通信,那是另一个选项。优点是简单、低延迟、更强的一致性、更容易调试——确实如此;缺点是有更紧密的耦合——它谈到了不同类型的耦合——故障恢复能力较差,可能会导致系统过载。它给出了一些论据。当然,这是 Claude 倾向于做的事情,其他 LLM 也倾向于这样做:如果你提出两个选项,它会建议“混合选项”。它必须建议混合选项,就好像它去过调解学校或者类似的什么地方,那个“双赢”选项总是会出现。
[原文] [Abraham]: now it didn't ask me any questions so I'm going to the llm to the Claud and I say why didn't you ask any questions ask me some questions in order to help me resolve the ambiguity if I would have presented it to an architect before answering anything she would have said here are some questions that you need to think so I asked forur the questions what further data or information would you suggest I acquire in order to arrive at a good decision this is me talking to the llm and the Claude tells me gather more traffic patterns this is good performance requirements scalability needs reli reliability fa tolerance consistency requirements operational considerations compliance and security budget constraints future road maps specific use cases existing architecture data characteristics recovery and backup requirements it gave me a real real good list
[译文] [Abraham]: 但是,它没有问我任何问题。所以我去找 LLM,找 Claude,我说:“你为什么不问任何问题?问我一些问题来帮助我解决歧义。” 如果我把这个问题呈现给一位架构师,在回答任何事情之前,她会说:“你需要思考这些问题。” 所以我要求它提问:“为了做出好的决定,你建议我获取哪些进一步的数据或信息?”这是我在跟 LLM 说话。Claude 告诉我:收集更多流量模式——这很好;性能需求、可扩展性需求、可靠性、容错性、一致性需求、运维考量、合规与安全、预算限制、未来路线图、具体用例、现有架构、数据特征、恢复和备份需求。它给了我一份真正、真正好的清单。
[原文] [Abraham]: it missed one important thing but that's okay an architect a human architect could have missed it missed missed it as well it didn't tell me what does the team want what does the team feel what do your friends input what do other people think is a good idea now had I gone to any architect friend and I say hey friend I'm debating between between this and the other thing what are some of the trade-offs so the architect friends would have told to me well you have to think about uh scalability and uh data characteristics and recovery and security what does your team want to do and that's not the consideration but it's a consideration and good Architects know that
[译文] [Abraham]: 它漏掉了一件重要的事情,但这没关系,一位架构师,一位人类架构师也可能会漏掉它。它没有告诉我:团队想要什么?团队感觉如何?你的朋友们有什么输入?其他人认为什么是好主意?现在,如果我去找任何一位架构师朋友,我说:“嘿朋友,我在这件事和那件事之间犹豫,有哪些权衡?” 架构师朋友会告诉我:“嗯,你得考虑可扩展性、数据特征、恢复和安全……但你的团队想做什么?” 这虽然不是(技术上的)考量因素,但这确实是一个考量因素,优秀的架构师知道这一点。
[原文] [Abraham]: then I said you know Eric Evans I wish he could give me some insight here he's too busy I and and lud lud bovin happens to be dead so I would like one side to be represented by Eric Evans the pioneer of DDD and the other to be presented by ludc Bon Boven the great composer can you do that and now I want to see how they will talk about system architecture direct messaging versus message q and Eric Evans who represents message Q based architector he starts giving me the pros it allows for loose coupling between Services much like different actions of an orchestra can play independently at harmonized
[译文] [Abraham]: 然后我说,你知道 Eric Evans 吗?我希望他能给我一些见解,但他太忙了。而路德……路德维希·凡·贝多芬恰好已经去世了。所以我想要一方由 DDD(领域驱动设计)的先驱 Eric Evans 代表,另一方由伟大的作曲家路德维希·凡·贝多芬代表。你能做到吗?现在我想看看他们将如何谈论系统架构、直接消息传递与消息队列。代表基于消息队列架构的 Eric Evans 开始给我列举优点:“它允许服务之间的松耦合,就像管弦乐队的不同声部可以独立演奏但又保持和谐一样……”
[原文] [Abraham]: it's amazing to me that a language model is able to do metaphor because metaphor usually requires understanding of the real world but I guess if you read enough metaphors then you know how to do metaphor you know how to at least simulate metaphor and um it's more resilient to failures and a secur pattern it's it's good Eric Evans really gave me some classical Eric Evans stuff but generic... beov he speaks he is German Evans while your approach has Merit I prefer the direct synchronous communication between
[译文] [Abraham]: 让我惊讶的是,语言模型竟然能使用隐喻,因为隐喻通常需要对真实世界的理解。但我猜如果你读了足够多的隐喻,你就知道如何使用隐喻,或者至少知道如何模拟隐喻。它说:“……它对故障更有弹性,是一种安全模式。” 这很好。Eric Evans 真的给了我一些经典的 Eric Evans 风格的内容,虽然很通用……(然后是)贝多芬,他说话了,他是德国人:“Evans,虽然你的方法有其优点,但我更喜欢直接的同步通信……”
📝 本节摘要:
Abraham 进行了一项极具创意的实验:利用 LLM 组建一个“虚拟智囊团”,成员包括 Diana Montalion、Matthew Skelton(《Team Topologies》作者)、Melvin Conway(康威定律提出者)和 Peter Drucker(现代管理学之父)。他们围绕“如何为消息队列系统组织团队”这一议题展开讨论。
讨论中,Skelton 提议使用“流对齐团队(Stream-aligned teams)”,Conway 质疑共享服务(如事件总线)的处理,Skelton 则建议设立“复杂子系统团队”。Abraham 特别赞同 Diana 提出的“思想交叉授粉(cross-pollination)”观点。最终,LLM 生成了一份包含具体团队划分(如流量收集队、协议验证队)的一页纸报告。Abraham 认为,尽管建议略显通用,但这不仅是一份高质量的总结,更是一个极佳的起点。
[原文] [Abraham]: consultants or maybe you have to uh befriend them at a conference or something so I tried I'm experimenting around a think tank and I used the llm to help me set up the think tank I'm not showing it for for a lack of time and I'm I'm then asking it set up a think tank or panel with Diana monleon some of us know Diana Matthew Skelton the guy from Team topologies Melvin Conway Conway's law Peter duer the art of business management to discuss the best way to organize the team in order to build the system the system again is the system of uh message Q
[译文] [Abraham]: (通常你需要聘请)顾问,或者你得在会议上和他们交朋友之类的。所以我试了一下,我在试验一个“智囊团”,我用 LLM 来帮我建立这个智囊团。因为时间关系我就不展示建立过程了。我要求它建立一个智囊团或小组,成员包括:Diana Montalion(我们中有些人认识 Diana);Matthew Skelton(《团队拓扑》Team Topologies 的作者);Melvin Conway(康威定律);Peter Drucker(商业管理艺术)。让他们讨论为了构建这个系统——也就是那个消息队列系统——组织团队的最佳方式。
[原文] [Abraham]: again I got a great Think Tank they came up with some interesting stuff nothing surprising nothing controversial and nothing specific but it was useful anyway and it was a pleasure to read because it reads really well one of the things about the llms because they're good with words they really really great in an easy to read to read way
[译文] [Abraham]: 再一次,我得到了一个很棒的智囊团。他们提出了一些有趣的东西,没什么令人惊讶的,没什么有争议的,也没什么特别具体的,但这无论如何都很有用。而且读起来很令人愉悦,因为它的可读性真的很好。关于 LLM 的一点是,因为它们擅长文字,它们真的非常擅长以一种易于阅读的方式(输出)。
[原文] [Abraham]: so Melvin Conway organizations Design Systems that mirror their communication structures skeleton we we propose organizing teams based on the nature of the work and the cognitive load Diana monthly own we should consider not just the technical architecture but also the business goals anybody that has read enough of the stuff written and said by and about these people knows this but if you don't this is very useful
[译文] [Abraham]: 那么,Melvin Conway 说:“组织设计的系统会通过其通信结构反映出来。” Skelton 说:“我们建议根据工作的性质和认知负荷(cognitive load)来组织团队。” Diana Montalion 说:“我们不仅应该考虑技术架构,还应该考虑业务目标。” 任何读过足够多这些人写的书或关于他们内容的人都知道这些,但如果你不知道,这非常有用。
[原文] [Abraham]: and Peter duer teams should be organized to maximize Effectiveness and Innovation with a focus on results rather than process cuz he is results focused and then Matthew Skelton proposes to start with stream aligned team because that's what team topologies does and then Melvin Conway asks the good question when you have stream aligned teams what do you do about the shared service such as the event bus so Matthew Skelton has a complicated subsystem team to manage the event bus again he wrote that in his book so that's what he says
[译文] [Abraham]: 然后 Peter Drucker 说:“团队的组织方式应能最大化有效性和创新,重点关注结果而非流程。”——因为他是注重结果的。接着 Matthew Skelton 提议从“流对齐团队(stream-aligned team)”开始,因为那是《团队拓扑》的核心内容。然后 Melvin Conway 问了一个好问题:“当你有流对齐团队时,你如何处理像事件总线(event bus)这样的共享服务?” 于是 Matthew Skelton 提出用一个“复杂子系统团队(complicated subsystem team)”来管理事件总线。这也是他在书中写过的,所以他就这么说了。
[原文] [Abraham]: Diana monthly on each team should know how their part contributes to the overall system goals Peter Ducker it's crucial that each team has clear objectives aligned with the overall project goals they should have the autonomy to decide how to achieve these objectives promoting Innovation and efficiency again classic drer it's all stuff
[译文] [Abraham]: Diana Montalion 说:“每个团队都应该知道他们的部分如何为整体系统目标做出贡献。” Peter Drucker 说:“每个团队都有与整体项目目标一致的清晰目标是至关重要的;他们应该有权决定如何实现这些目标,从而促进创新和效率。” 又是经典的 Drucker 风格,都是这些内容。
[原文] [Abraham]: Melvin Conway then asks how do we ensure that this team structure doesn't create silos that might impede system integration and Matthew Skelton says you have defined interactions Diana mlon this is a statement that I strongly strongly agree with I've heard it from her many times create opportunities for cross-pollination of ideas that's what she contributes to the think tank and it is absolutely true and anybody that manages teams in in addition to the silos or into the team topologies create lots and lots of opportunities for people to talk they could be formal and they could be informal
[译文] [Abraham]: Melvin Conway 接着问:“我们如何确保这种团队结构不会制造可能阻碍系统集成的孤岛(silos)?” Matthew Skelton 说:“你要有已定义的交互模式。” Diana Montalion 说——这是我非常非常赞同的一句话,我听她说过很多次——“创造思想交叉授粉(cross-pollination)的机会。” 这就是她对智囊团的贡献,这绝对是正确的。任何管理团队的人,除了关注孤岛或团队拓扑之外,都要创造很多很多让人们交谈的机会,可以是正式的,也可以是非正式的。
[原文] [Abraham]: Peter duer of course teams need to be able to quickly understand and adapt to changing priorities totally irrelevant to the discussion at hand and it's totally true but that's what happens sometimes in think TKS people say what's expected of them
[译文] [Abraham]: Peter Drucker 当然说:“团队需要能够快速理解并适应不断变化的优先级。” 这与手头的讨论完全无关,虽然它是完全正确的。但这有时候就是智囊团里会发生的事,人们说着人们期望他们说的话。
[原文] [Abraham]: this is Melvin Conway again I don't think he would have said it thank you all now this is a great statement it really is a good good helpful summary again I couldn't get anything specific to my problem at hand but as a statement it's I couldn't have worded it better
[译文] [Abraham]: 这是 Melvin Conway 再次发言——我不认为(真正的他)会这么说——“谢谢大家。” 这是一个很棒的陈述,真的真的是一个很好、很有帮助的总结。虽然我无法得到针对我手头问题的具体方案,但作为一个陈述,我无法措辞得更好了。
[原文] [Abraham]: thank you all to summarize it seems we're proposing a structure of stream aligned themed for core Services supported by platform and enabling teams with a focus on clear objectives autonomy and adaptability we're emphasizing the importance of understanding the whole system clear communication and regular reassessment of Team structures had somebody given me a pile of books about architecture and say write two paragraphs that summarize everything that you need to take into account I couldn't have written a better paragraph It's a good paragraph
[译文] [Abraham]: (LLM 总结道):谢谢大家。总结一下,我们似乎在提议一种结构:核心服务采用流对齐团队,辅以平台团队和赋能团队(enabling teams),重点关注清晰的目标、自主性和适应性。我们强调理解整个系统、清晰沟通和定期重新评估团队结构的重要性。如果有人给我一堆关于架构的书,说“写两段话总结你需要考虑的一切”,我也写不出比这更好的一段话了。这是一段很好的话。
[原文] [Abraham]: the the of course the the devil is in the details H and it would be very very hard to implement such such a thing but that's we do hard stuff uh and again I couldn't get it to be something specific so the think tank needs to write a one-page report combining and summing up the report the approaches and it gives me a one-page approach and it gives me stream align traffic collection and here it this get it does get specific to the problem at hand again just by analyzing the texts
[译文] [Abraham]: 当然,魔鬼在细节中,实施这样的事情会非常非常困难,但这就是我们做的——我们做困难的事情。而且再说一次,我没法让它变得特别具体。所以我让智囊团写一份一页纸的报告,结合并总结这些方法。它给了我一份一页纸的方法,它给了我“流对齐的流量收集(团队)”。在这里,它确实变得针对手头的问题了,仅仅是通过分析文本。
[原文] [Abraham]: I imagine the traffic collection team the segmentation an Anis team the protocol validation team the IP validation team this approach combines technical Precision flexibility emphasizes both the autonomy of the individual teams again some generic text but it's it's pretty good and has the key principles and the key principles are key principles that really I could not have written them better myself and they are good uh principles
[译文] [Abraham]: 我设想了流量收集团队、分段分析团队、协议验证团队、IP 验证团队。这种方法结合了技术精度和灵活性,既强调各个团队的自主性……又是一些通用的文本,但这相当不错,并且包含了关键原则。这些关键原则真的是我也无法写得更好的原则,它们是很好的原则。
[原文] [Abraham]: so that's that that I spoke a bit about myself gave some background in llms I tried to think what an architect does an architect has understanding an architect knows how to take general knowledge a lot of it and apply it to a very specific case the case study showed how we could use the power of the llm as a tool in order to try to gain some things that are relevant to the problem at hand and again I'm still on the journey it's still happening
[译文] [Abraham]: 好的,就是这样。我谈了一点关于我自己的事,给了一些关于 LLM 的背景知识。我试着思考架构师是做什么的:架构师拥有理解力,架构师知道如何获取大量通用知识并将其应用到一个非常具体的案例中。案例研究展示了我们如何利用 LLM 的力量作为工具,试图获得一些与手头问题相关的东西。再说一次,我仍然在旅途中,它仍在发生。
📝 本节摘要:
在总结部分,Abraham 再次强调 LLM 只是工具,拥有知识但缺乏深度理解,而架构师的核心价值在于“理解”。他播放了《玩具总动员》中巴斯光年发现自己只是个玩具的片段,幽默地比喻了当 AI 试图教导人类“真实世界”时给人的荒谬感。最后,他引用哲学家亨利·柏格森的名言,指出架构师是在不断的行动中定义自我的。在问答环节,面对关于“推荐哪个 LLM”的提问,他坚决回答“不推荐特定一个”,建议大家尝试所有模型,并始终保持怀疑与验证的态度。
[原文] [Abraham]: so summary we aim to use appropriate tools with skill and precision llms are tools they could make us more efficient and effective in certain parts of the process as Jackie said llms have a lot of knowledge Architects have deep understanding or at least they should have deep
[译文] [Abraham]: 所以总结一下,我们的目标是以技巧和精确度使用适当的工具。LLM 是工具,它们可以使我们在流程的某些部分更高效、更有效。正如 Jackie 所说,LLM 拥有大量知识,而架构师拥有深刻的理解,或者至少他们应该拥有深刻的理解。
[原文] [Buzz Lightyear (Clip)]: Galaxy Emperor Zerg has been secretly building a weapon with a destructive capacity to annihilate an entire planet I alone have information that reveals this weapon only we and you my friend are responsible for delaying my Rendevous Star Command you are ah toy you weren't the real bz light you're you're you're an acent figure you are a child PL thing you are a sad strange little man and you have my pity farewell
[译文] [巴斯光年 (片段)]: “银河皇帝扎克一直在秘密建造一种具有毁灭整个行星能力的武器。只有我掌握揭露这种武器的信息。只有我们……而你,我的朋友,你要负责推迟我与星际总部的汇合……” (伍迪回应): “你是个……玩具!你不是真正的巴斯光年!你是个……动作玩偶!你是孩子的玩物!你是一个悲伤、奇怪的小人,我同情你。再见。”
[原文] [Abraham]: oh yeah well good ritten shelone and yeah sometimes sometimes that's how I feel when when talking to the llms and the llms start teaching me what the real world is about and what what I need to do know
[译文] [Abraham]: “哦,好吧,走好不送……” 是的,有时候,有时候那就是我的感觉——当我和 LLM 交谈,而 LLM 开始教我真实世界是怎么回事,以及我需要做什么、知道什么的时候。
[原文] [Abraham]: I I also know some stuff Henry Louie bergon was one of the early analytical philosophers and he says it is then right to say that what we do depends on who we are but it's also necessary to add that what we are or that we are what we do and that we are creating ourselves continually and that is very very true it's true about Architects we do what we are and we are what we do and that's highly iterative and that's part of our humanity
[译文] [Abraham]: 我也知道一些东西。亨利-路易·柏格森(Henri-Louis Bergson)是早期的分析哲学家之一,他说:“那么说‘我们做什么取决于我们是谁’是正确的,但也有必要补充说‘我们就是我们所做的’(what we are is what we do),并且我们正在不断地创造自己。” 这非常非常正确。这对架构师来说是真的:我们做我们所是的,我们是我们所做的,这是高度迭代的,这也是我们人性的一部分。
[原文] [Abraham]: and this is certainly not the end there's still a long way to go so so thank you thank you everybody very much here is a uh a partial list of the books that I had used uh to learn uh and and to prepare for this talk... thank you Yi thank you everybody this has been a great day for a great conference and uh thank you
[译文] [Abraham]: 这当然不是终点,还有很长的路要走。所以,谢谢,非常感谢大家。这是我为了学习和准备这次演讲所使用的部分书籍清单……谢谢你 YGI,谢谢大家,这是很棒的会议中很棒的一天,谢谢你们。
[原文] [YGI]: do we have time for a question so just one minute for one question um surprisingly there were like several questions that were applied by you while you were on stage as I was speaking so probably it was an AI assistant that you have um but one question that I would like to to ask and with this we we close the day any recommendation for using any particular AI llm CL Gemini LGBT when using it for software architecture related topics
[译文] [YGI]: 我们有时间提问吗?只有一分钟,提一个问题。令人惊讶的是,有好几个问题你在台上演讲时就已经回答了,可能你有一个 AI 助手吧……但我想问一个问题,我们用这个问题来结束这一天:在处理软件架构相关主题时,对于使用特定的 AI 或 LLM——比如 Claude、Gemini、ChatGPT——有什么推荐吗?
[原文] [Abraham]: no no try them all the question was is there any recommendation for a particular AI or llm um the answer is a resounding no because they're changing and they're changing very fast so you might recommend Gemini and then chat GPT 4 will come out so you'll recommend chat gp4 so it's a bad idea to recommend a particular AI or llm experiment with all of them and be skeptical of anything they tell you you have to validate
[译文] [Abraham]: 不,不,把它们都试一遍。问题是“有没有推荐特定的 AI 或 LLM”,答案是一个响亮的“不”。因为它们在变,而且变非常快。你可能推荐了 Gemini,然后 ChatGPT 4 出来了,你又会推荐 ChatGPT 4。所以推荐特定的 AI 或 LLM 是个坏主意。试验所有的模型,并且对它们告诉你的任何事情保持怀疑,你必须去验证。