翻译｜林绮蓓 编辑｜蔡芳芳 “我已经很久没好好看过代码了。在 AI 编程工具越来越强的今天，这句话开始成为一些开发者描述自己工作方式的方式。
需求交给 Agent，代码由它生成，测试和审查还可以交给其他 Agent。软件似乎从来没有这么容易做出来过。
但另一种情况也越来越常见：项目启动得很快，做了几轮后却很难继续。 Agent 悄悄换掉原有部署脚本，同一个功能在代码库里被实现了五遍；一旦需要大幅调整架构，它往往选择继续打补丁。
开发者拥有了大量能运行的代码，却未必还看得清系统究竟是怎么搭起来的。在首席架构师 Carlos Kelkboom 看来，问题已经延伸到人与人的协作。
开发者遇到问题越来越习惯先问 Agent，PR 下的讨论逐渐减少，与用户沟通、理解产品需求、反复思考架构的过程也更容易被跳过。代码可以更快生成，但一个项目为什么做、为谁做、以后怎样演进，仍需要有人作出判断。
在 Patrick Akil 主持的这期播客中，Carlos 分享了五条颇为反常识的 Agent 编程原则： 第一，亲自搭建代码骨架 ，提前确定目录、关键文件和函数签名； 第二，禁止主 Agent 直接修改代码和文件 ，充分理解需求后才启动执行 Agent； 第三，生成的代码看不懂就扔 ，执行结果隔离在 Git Worktree 中，一旦发现偏离预期结构，就直接舍弃重来； 第四，尽可能让 Agent 一次性完成较大任务 ，避免反复修改导致代码不断打补丁； 第五，让多个 Agent 并行探索不同方案 ，例如三个 Agent 分别开发，再由第四个 Agent 比较结果，只合并好的部分。两人的分歧也贯穿了整场对话。
Patrick 更看重工具能否尽快做出有用的东西，Carlos 则反复追问：开发者从中学到了什么？如果代码越来越便宜，工程判断、代码审查和初级工程师的培养该如何改变？
讨论最终从编程实践延伸到未来编程语言、AI 泡沫，以及一个更根本的问题：当 Agent 能写越来越多的代码，人类工程师还应该把时间花在哪里？太长不看版： Patrick：软件工程这几年最值得警惕的变化是什么？
Carlos： 开发者越来越习惯与 Agent 一起工作，却减少了与同事、用户的交流。 PR 里的讨论变少了，产品意识也可能因此被削弱。
能很快做出一个演示，和真正理解用户、把软件长期做好，是两回事。 Patrick：Agent 随时能回答问题，为什么还要花时间找人讨论？
Carlos： 因为即时答案也会改变思考习惯。 Agent 回答得快，还可能顺着你的预期说；人与人的讨论慢一些，却能带来不同经验、质疑和反馈。
学习不只是得到答案，还要留出时间自己消化。 Patrick：为什么你坚持先搭代码骨架，再让 Agent 动手？
Carlos： Agent 擅长迅速找到一条实现路径，却未必顾得上新代码与整体架构的关系。我会先建目录、文件和关键接口，明确模块职责。
否则，代码重复、“上帝对象”和莫名其妙的新脚本都可能出现。能不能把方向交代清楚，是我认为拉开 Agent 工程师效率差距的关键。
Patrick：不熟悉一门语言，也能先搭出合理的骨架吗？ Carlos： 可以先研究成熟的开源项目，让 Agent 对比设计模式、解释取舍，再自己动手写些注释和初步结构，反复讨论。
关键不是让它替你作出所有决定，而是借助它培养自己的判断力。 Patrick：为什么你的主 Agent 被禁止写代码、修改文件？
Carlos： 我希望它先专心理解我在问什么，而不是听到问题就急着实现。我让主 Agent 负责对话、检索和确认意图，用多个模型辅助评分；只有当它对理解我的目标有超过 90% 的把握时，才向我提出启动执行 Agent 的建议。
Patrick：Agent 写完代码，你怎么审？发现不对又怎么办？
Carlos： 先看是否符合我预先设定的结构。如果打开代码就认不出那些应该存在的东西，我宁可扔掉重做。
我会在执行一两个小时后就暂停检查 Worktree；出了问题，就回到对话里查清是骨架、需求还是上下文信息相互冲突，再开新会话重试。 Patrick：为什么主张“代码便宜了，就应该经常推倒重来”？
Carlos： 因为在我的经验里，Agent 对一次性完成较大任务比较擅长，对已有代码反复大改却不太擅长。既然生成代码的成本降低了，就可以并行探索不同方案，甚至让三个 Agent 分别开发、第四个 Agent 评估，不必为了保住已有代码而不断叠加补丁。
Patrick：如果人人都能靠 AI 写软件，还需要专业工程师吗？ Carlos： 更需要工程判断。
资深工程师要先厘清产品目标、架构、部署方式和安全边界，也要帮助新手学习这些取舍。我担心的一种情况是，我们培养了一代很会使用 Agent、却缺少独立开发能力的人。
Patrick：AI 生成的代码越来越多，代码审查应该看什么？ Carlos： 除了最终 Diff，还应看前期需求和架构决策、每次提交如何推进方案，以及实际增加了哪些复杂性。
可以借助静态分析、变异测试和新的可视化方式，但团队围绕 PR 的讨论不能因此消失。 Patrick：你怎么看 AI 的未来？
这轮热潮会不会是泡沫？ Carlos： 要分开看。
AlphaFold、医学和材料科学等方向的突破让我觉得像魔法；LLM 在编程上的价值也很大，但巨额投入与产业承诺是否都能兑现，我有疑问。与此同时，权力向大型科技公司集中，以及 AI 是否真的缩小机会差距，也令我担忧。
开发者开始只和 AI 说话了 Patrick：今天的嘉宾是 Carlos Kelkboom，他是我认识的最出色的工程师之一。 Carlos 你觉得跟几年前比，软件工程最大的变化是什么？
Carlos： 首先，我观察到一个我不喜欢的现象：开发越来越像一个人的工作，同事之间的合作越来越少。过去大家重视拉取请求（PR，Pull Request），相互协作，也会在自己和同事的 PR 下交流意见；现在这样的交流越来越少，甚至有人说 PR 以后可能会消失。
现在你经常和智能体一起工作，却不再和团队一起工作。这是我观察到的趋势，也是我认为很危险的一件事。
Patrick： 你觉得为什么会这样？我有个猜测，可能和我们在 Reddit、YouTube 上看到的情况有关。
那里有很多独立开发者，往往是他们最先尝试新技术。当然，这也可能只是我的信息茧房，不知道这个观察是否准确。
那么，在规模更大的企业里，开发团队依然有很多人，大家既要和 AI Agent 协作，也要和同事协作，实际情况又是怎样的？ Carlos： 我有个好处，就是完全不用社交媒体。
我连 Reddit 账号都没有，LinkedIn 也只是拿来和你联系。我不太关注社交媒体上的讨论，但我读很多东西，包括文章和白皮书，也跟很多公司和员工交流，所以我的印象不完全来自网上的展示。
我认为快速做出个东西却不收尾，和认真做一款希望能长期使用的产品，完全是两回事，这就像是马拉松和短跑的区别。一个人独立做项目，往往差最后一口劲把它真正做完；把东西放到社交媒体或 YouTube 上展示，和真正完成产品，也是不一样的。
比如，现在网上经常有人展示自己如何快速“做出”一款游戏。我之所以给“做出”加引号，是因为游戏开发最大的难点其实在于倾听玩家的反馈，并把游戏设计做好。
这些事情当然也可以借助 AI Agent 不断迭代，但开发者仍然需要与外界交流。与人沟通本来就是最难的事情之一，而现在，开发者可以待在自己的小圈子里，不怎么与外界交流，就能独自做出很多看得见的成果。
这反而进一步强化了这种倾向。但开发软件时，始终需要想清楚两个问题：为什么要做这个软件？
它是为谁而做的？所以我才说， 产品意识正变得越来越重要，但它恰恰也是当下被削弱得最厉害的东西。
Patrick：你 思考 过怎么解决这个问题吗？以我自己的经历来说，以前我觉得开始最难；有人说自己 启动 了很多项目却没做完，我一直不理解，因为我总是在有把握能完成时才开始。
而现在，开始一件事对我来说从未如此容易。 Carlos： 是的。
Patrick： 我用的工具有额度限制，界面上还有一个进度条。每到周末或者月底，我就总想着尽量把额度用满。
甚至临睡前还会琢磨：要不做个游戏？我确实做过一些游戏，后来甚至还搭了一套能自动生成游戏的 Harness，让其他人也能用它来制作游戏，相当于在游戏开发之上又加了一层工具。
我会试着解决一些自己预想未来可能出现的问题，看看最终能做出什么。但往往做到这一步就停下了，没有再往前推进：既没有把项目打磨到足够稳定，也没有真正完成，更没有把它做成可以出售的产品。
我启动过很多项目，但真正做完的没几个。 Carlos： 不过，这种情况以前就有。
我自己就做过大概五个编译器，每个都动手写了，也都差不多快完成了，但真正称得上做完的只有一个。软件开发一直如此：有了一个有意思的想法，想顺便学点东西，于是开始动手，最后却不一定能做完。
现在的区别在于，你得先想清楚为什么要启动这个项目。是为了学习？
为了试验 AI Agent？还是为了真正做出一款产品？
我觉得，现在开发者需要对自己做一件事的目的有更明确的认识。一旦目标清晰了，你刚才说的那种困扰也就没那么严重了。
如果你只是想玩一玩、找点乐趣，那你其实已经达到目的了。但如果你是想以此创办一家公司，那就必须把东西真正做完。
Patrick： 说到这种情况，我发现自己和 AI Agent 好像也困在了一个小圈子里。遇到问题时，我第一反应往往是去问 Agent，而不是找你这样的同事交流。
至少在我身边，这种工作方式已经很常见了。你觉得，开发者该怎么跳出这个圈子，更多地与其他人交流、协作？
Carlos： 这个问题我已经想了很久。我觉得我们一起工作的方式、做软件的方式，恐怕都要改变。
开源已经发展了这么多年，我觉得现在还得多办聚会，多分享经验，围绕具体项目共同工作。最好能够组织小组，成员愿意互相看看彼此的产品、提提意见。
大家得重新走到一起，我们需要真正聚在一起合作。虽然待在自己的圈子里更容易，也得想办法降低门槛，让你更容易找到对你的项目感兴趣的人。
这也意味着我们需要更开放一点，不要害怕把想法讲出来。人们常说点子不值钱；放到全世界来看，点子也许确实不稀缺；可对想到它的人来说，它很珍贵，也很私人。
分享想法时，人们可能担心被别人抢先实现，也担心自己的想法不够成熟。要消除这种顾虑，就需要一个包容、愿意互相支持的社区。
我想到一个例子：最近推出的《魔兽世界 Forever》，不知道你有没有听说过。人们在测试版里问一句“这个设置怎么关”这样很基础的问题，也会有四五个人来帮你。
做软件的人需要这样的互助氛围。 Patrick：但我看到的趋势是大家都会选择去问自己的智能体，似乎没必要问人了。
有些人本来就不愿意回答那些他们觉得太简单的问题。我甚至听过一句话：“先问你的智能体，再来问我。
这话有些好笑，却也让人感到不安。我感觉大家比过去更容易怀疑自己的能力，即使智能体可能把人带偏，或者让人看不到全局，大家也更倾向于依赖智能体指路；从学习的角度看，只和智能体交流，学到的东西可能不如和人讨论时多。
Carlos： 是的，问人确实慢，因为你无法立刻得到答案。智能体则能立即回应，而且往往倾向于给出你希望听到的答案。
你可以同时问几个模型，让它们互相质疑，或者设计一套对抗式的流程，多少能缓解这个问题。但这会带来一个更深的变化：你会越来越习惯只和这些立刻回答的机器交谈，不再留时间给自己安静地想。
那些纷乱的念头，本来得在经过一段时间的沉淀，才能慢慢理清，从而让你生出新想法，或者让你发现原来还有另一条路可以尝试。等会儿我们可以聊聊我具体怎么用智能体写软件，但创造力这件事值得我们先讨论。
John Cleese 讲过创造力的开放模式和封闭模式：进入开放模式，首先得进入一种开放、平静的心理状态；什么都不做，让纷乱的想法逐渐沉淀，才有可能真正放开思路。可社交媒体、AI 和智能体却持续提供新的信息。
我们几乎没有时间坐下来，闭上眼睛，整理自己的想法。 Patrick：这有什么坏处？
我有问题只要向智能体提问，马上就能得到答案，紧接着处理下一个问题，一路往前赶。我一直觉得做软件就是要快。
有了智能体，我们推进得更快；虽然也更容易出现故障，但修起来也快。速度在我看来还是很重要的。
如果我不坐下来想清楚自己在做什么，那我会失去什么？ Carlos： 我认为代价是学到的东西变少了。
知识需要经过思考和消化，才能真正被掌握。让智能体直接生成代码，自己不一定学到了什么。
以前认真学过、如今会用智能体的人，会比未掌握基础、仅依赖智能体的人更有优势。工程实践的乐趣，本来就在于不断学习：进入陌生领域，读一份新规范，学一门语言，试一个新框架。
JavaScript 为什么会有那么多框架？也是因为做框架的人一路从别人那里学到了东西。
而要真正做到这一点，必须给自己时间去消化。 Patrick：那我学习怎么操作智能体，学习相关领域知识、为智能体准备的各类配置和说明文件，以及不断出现的智能体工作框架的新功能，从长远看，这也算学习吗？
Carlos： 当然算。先搭骨架再让 AI 写代码，效率可能差 10 倍 Patrick：那你从智能体身上学到的最重要的一点是什么？
具体工作时，你又是怎么把它用好的？ Carlos： 这其实是两个不同的问题。
先说我是怎么与 Agent 协作的吧。现在，我会先亲自搭好代码骨架：建立目录结构和文件，在文件里写一些注释，有时还会提前写好类名、函数名或函数签名。
这些内容不需要特别规范，写个大概就行。关键是通过这些准备工作，明确告诉 Agent 我想要怎样实现，让它按照我设定的方向去写代码。
因为我发现，Agent 很擅长沿着一条路径快速解决问题，甚至可以说是暴力求解，但它经常忽略这些代码该如何融入应用的其他部分。结果就是代码重复、模块内聚性差，甚至出现“上帝对象”（God Object）等问题。
这些都是我们不希望看到的，因为它们会让代码越来越缺乏灵活性。所以，我现在都会亲自搭建这套骨架。
这个过程可能花 20 分钟、半小时，有时甚至要一个小时。比如开发编译器时，我会先规划目录结构，写一个词法分析器（Lexer），再写一点语言规范。
我还会提前设计好抽象语法树（AST）如何转换为中间表示（IR），并通过目录和文件结构体现这些设计，再用我想实现的语言写出大量示例。有了这些准备，Agent 就能非常出色地生成符合我要求的编译器。
Patrick： 因为你提前搭好了代码骨架？ Carlos： 对，没错。
我也试过完全不做这些准备，直接让 Agent 从头到尾自己写。结果做上一两个月，就会明显感觉越来越难推进：Agent 的速度变慢了，生成的东西也越来越不符合预期，有些功能开始出问题。
打开代码文件时，你甚至已经认不出自己的应用了，完全不知道中间发生了什么。这种情况我遇到过很多次。
比如，项目原本有一个部署脚本，但不知道为什么，Agent 突然决定不再使用它，反而另外创建了好几个脚本，最后谁也不知道这些脚本到底是干什么的。所以， 不要跳过前期的结构设计，而且必须非常明确地告诉 Agent 你希望它做什么。
我认为，这种能力可能就是区分 10 倍效率和 100 倍效率的 Agent 工程师的关键。 Patrick： 但要做到这种有意识的设计，我得依靠过去积累的经验。
我对项目结构确实有自己的判断，不过主要限于那些我熟悉、亲手实践过的编程语言。如果现在让我做一件完全没做过的事，比如开发编译器，我该怎样培养这种能力和品味，才能判断什么样的代码骨架才是好的？
Carlos： 好问题。在智能体出现之前，你会怎么做？
Patrick：我会向有经验的人请教。我过去不喜欢从零启动项目，工作里接触的大多是已经启动的项目。
有了现成约定，我通常能高效开展工作；可让自己从头建立项目约定，我没怎么尝试过。我会找那些擅长做这件事的人，一起做，问他们哪些决定最重要。
因为没有亲手反复做过，这些经验也没有真正的内化。但是现在再遇到这种事，我大概会先问智能体。
如果还是卡住了，也依然会找人帮忙。 Carlos： 如果是现在，我会这样做：面对一门完全陌生的语言或一个新领域，我先去找做得不错的开源项目，下载后研究。
如果你更愿意待在“智能体的小圈子”里，也可以让它对照几个项目，找出值得学的做法。用 Claude 之类的工具，还可以准备一些“追问我”“教教我”这样的技能：让它讲清这些项目的基础，哪里做得好、为什么好，哪里有问题。
花上一两天，你对好的、坏的做法多少会有感觉。然后我通常会出去拿杯咖啡，坐下来独立思考，整理刚学到的内容。
遇到不明白的地方，再回去提问，之后继续思考。只有当我对想做的事有了比较清楚的感觉，才会从很小的概念验证开始，搭一个骨架，请智能体评估：这样搭可行吗？
能同时解决刚才提到的两个问题吗？就这样来回琢磨，直到心里感觉对方有了底，才让它动手实现。
这些年我学到的一点，就是不要贪图马上看到成果的那一下快感。 Patrick： 照我的理解，如果我没有先搭建骨架，智能体就会自行决定代码结构。
它能积极完成眼前的任务，却未必能充分考虑结构是否合理。 Carlos： 没错，而且它也不管你将来想要什么，只顾着把你眼下提出的要求硬做出来。
Patrick： 可软件以后总是会变的。你是这个意思吗？
Carlos： 做软件，唯一不变的就是变化。就拿编译器来说，没人会写完一个编译器就觉得大功告成了，它总会不断演进。
可能需要增加新的语言特性，也可能要调整优化方式。举个我自己的例子。
我曾经开发过一个编译器，最初只实现了一套很简单的列表机制，后来想进一步扩展它。当时我已经和 Agent 一起开发了大约一个月，而且用的是一门我不太熟悉的编程语言。
最后，我让 Agent 回过头来检查列表功能，结果它告诉我：同一个列表功能竟然被重复实现了五次。如果只是让 Agent 一路埋头写代码，就很容易出现这种情况。
后面当然可以通过不断迭代来清理和重构代码，但前提是，你得先能识别出问题在哪里。 Patrick：对，这恰恰是我觉得最难的地方。
我很喜欢你刚才提到的方法：先看看开源社区里有哪些现成的实现，了解好的设计模式，再让 Agent 帮你解释这些东西，让自己真正理解其中的原理。你可以不断向 Agent 追问，直到把自己好奇的问题彻底弄明白，再消化吸收这些知识，然后才开始动手。
我觉得自己平时还没有充分利用这种方式，但以后如果要用一门不熟悉的语言开发项目，我想试着这样来设计代码骨架。毕竟我掌握的编程语言没你多。
如果我不熟悉一门语言，能不能先通过和 Agent 讨论来完成这些准备？这样开始是否可行？
你会有什么建议？ Carlos： 当然可以。
你可以先问它：“这门语言最重要的理念是什么？能不能拿我熟悉的语言来类比讲讲？
比如你会 C#，想学 Go，就问：“我会 C#。要写出符合 Go 语言惯例的代码，我需要改掉哪些习惯？
两门语言差在哪儿？我现在的写法哪里不对？
然后自己先写点东西，哪怕只是几段注释和一个很粗的结构，写错也没关系。智能体可以帮你改。
先请它看看你搭的架子，它通常会直接指出这里不对、那里不对，然后你再提出质疑，和它继续讨论。 Patrick： 你觉得现在还有必要学习编程语言吗？
Carlos： 我觉得，我们可能很快就需要一门全新的编程语言了。我知道很多人都这么说，但我确实认为，编程本身有几个根本性的东西需要改变。
首先，我认为应该彻底抛弃堆内存（Heap）。我们不再需要指针、动态内存分配，以及围绕它们建立的那一整套机制。
我希望未来的编程语言具有很强的确定性，而且可以分为三个层次。第一层是人类编写的代码，可以把自然语言和某种结构化语言结合起来。
甚至不需要太复杂的语法，也许只要有一个 component 关键字，再加上组件名称就够了。然后在组件内部，通过缩进和类似 Markdown 的写法，描述这个组件应该完成什么任务。
第二层是某种中间表示，可以是图表、视频，也可以是其他直观的视觉或音频形式。 Agent 会通过这些形式，向你解释它理解的目标是什么。
开发者则可以通过语音或其他方式提出质疑、进一步明确要求，再把这些反馈转化回第一层的描述。最后一层才是真正运行在机器上的程序表示。
我认为，这一层应该抛开传统编程中许多沿用至今的假设。具体来说， while 语句和其他循环都应该有明确的执行边界，还可以采用 Actor 模型。
我们应该真正摆脱堆内存，重新采用基于记录（Record）的数据结构，或者过去被称为 Plex 的那种结构。最终，我们需要重新获得一种能力：能够清楚地推理自己的机器上究竟在运行什么，而不是像现在这样，面对大量难以预测的程序行为。
Patrick： 你之所以强调确定性，主要是因为现在的程序存在太多不可预测的行为吗？ Carlos： 对，但还有一个原因：如果采用这样的运行时，性能也会非常高。
另外，现在的计算系统其实有些割裂。比如，为 GPU 编写程序和为 CPU 编写程序，往往需要采用完全不同的方式。
CPU 针对分支预测、数据预取等做了大量复杂优化，而 GPU 的计算模型相对直接，也更具有确定性。你分配一块内存，填入数据，再在上面执行一些计算，整个过程就完成了。
按照这种模型，不需要那些围绕堆内存和动态分配建立起来的复杂机制。要让 GPU 适应 CPU 的那套编程方式很难，我也不认为这是正确的方向。
我觉得我们应该反过来，让 CPU 向 GPU 那种更具确定性的计算方式靠拢，同时保留 CPU 所需的不同计算能力。这样，我们就能更充分地利用 SIMD（单指令多数据）等能力，也能支持不同的数据结构。
比如需要处理图结构时，就可以把它映射到合适的表示形式上。这就是我认为未来编程语言需要具备的核心特征：高度确定性。
我刚才可能还没解释清楚，为什么确定性这么重要。想象一下，你把一颗卫星送上太空，它的内存容量是有限的。
如果程序运行时还在不断进行堆内存分配，就可能出现内存不足异常，或者空指针异常。你肯定不希望卫星在太空中遇到这些问题。
而现在，软件正在越来越多地应用于机器人、卫星、机器学习等领域，我们需要尽可能确保程序的运行行为是可预测的。如果一台设备只有 2GB 内存，你就应该能够明确知道，这个应用在任何情况下都不会超出这个限制。
所以我才认为，我们不能再继续依赖动态内存分配了。 Patrick：我觉得这可能也是为什么，至少在卫星这类场景里，很多人会选择 Rust。
因为我理解，Rust 能让开发者尽可能在早期发现这类问题。 Carlos： Rust 还有一套规范，通过限制可使用的语言特性，让程序行为更具确定性。
不过，真要靠人手写，确实挺费劲，至少我自己的体验是这样。 Patrick：那你试过让 Agent 写 Rust 吗？
Carlos： 试过。写起来比很多其他语言慢一些，但也挺有意思。
Agent 其实很擅长写 Rust，只是它们拆分代码的方式往往不符合我的预期。而且，我一直觉得 Rust 代码后期很难修改。
一段 Rust 代码只要能正常运行，我就不太想再碰它了，觉得这样就算完成了。相比之下，其他语言重构起来要容易得多。
当然，这只是我个人使用 Rust 的感受。我并不想劝大家放弃这门语言。
Rust 是一门设计得很出色的语言，拥有很多现代编程语言应该具备的特性，比如可辨识联合类型（Discriminated Unions）等。但在我看来，借用检查器（Borrow Checker）本质上是为了管理堆内存中的数据。
如果我们彻底取消堆内存，也就不再需要借用检查器了。想象一下，如果有一条记录（Record），它在内存中的位置是固定的，而且从程序启动开始，所有数据就已经安排好了。
这样，你只需要知道记录的起始位置，再通过偏移量定位各个字段，就能非常快速地访问数据。 Patrick： 有意思。
那你设想的这种新语言，最终会是一门统一的语言吗？大家会逐渐收敛到同一种语言上吗？
Carlos： 这正是我提出三层结构的原因。我认为最终生成的代码，以及底层运行时，可以是统一的，但中间各层基本上都可以像插件一样自由替换。
甚至可能发展到这样一种程度：每个人只需要和自己的 Agent 对话，就能定义出一门属于自己的编程语言。 Patrick：不过，这又让我想到一个问题。
我在想办法提高 Agent 的工作效率时，经常遇到一个难题，其实人与人之间、不同团队之间，甚至组织的不同层级之间也一样：大家如何使用同一套语言交流？比如我说“组件”，在 Agent 的语境里究竟是什么意思？
是自定义 Agent、本地 Agent，还是主 Agent 下面的子 Agent？不同的人可能有完全不同的理解。
如何建立共同语言，一直是个难题。而按照你设想的未来，每个人都可能有自己的编程语言和交互方式。
那大家又该如何建立一套彼此都能理解的共同语言？ Carlos： 这可是个价值百万美元的问题。
说说我自己的看法吧。回到二十年前，如果我要开发一套 CRM 系统，大家其实不会一直争论“客户”到底是什么，因为数据模式（Schema）已经明确规定了“客户”的定义。
真正困难的是，怎样形成这套 Schema，以及之后如何让它不断演进。但在某个阶段，这套 Schema 就是大家对“客户”的共同定义。
所以，最难的是先达成一个初步共识，再在此基础上不断迭代。如果我没理解错你的问题，我觉得我们应该从比现在简单得多的东西开始。
比如，哪怕一开始只规定“客户有一个 ID”，大家也能立即达成共识：没错，客户当然需要一个 ID。然后我们就可以在此基础上逐步完善。
数据建模已经为我们提供了很多现成的方法。比如星型模型，或者分别从销售和营销的角度建立客户模型。
我们可以有不同类型的模型，满足不同的需求。但关键在于，共识不应该只是某个时间点上确定下来的东西，我们还需要就它未来如何演进达成共识。
过去软件开发的速度比较慢，人们更关注眼前要做什么，而不是系统今后如何演进。这也是为什么我觉得，今天的敏捷开发已经不像它原本应该有的那样敏捷了。
这个问题我们之前讨论过很多次，我觉得敏捷开发在某种程度上已经偏离了初衷。而现在有了 Agent，我们或许可以重新回到敏捷开发最初的理念：先从一个简单的起点出发，然后快速迭代、不断演进。
Patrick：这个观点很有意思。 AI 让代码不值钱了，但工程经验越来越重要 Patrick： 我们聊了这么久 Agent 辅助编程，我还真没想到，提前搭建代码骨架竟然是这么关键的一步。
因为至少在我身边，有些人的工作方式完全不同。他们会说：“我已经很久没看过代码了。
他们觉得最高效的做法，就是让 Agent 包办所有事情，自己根本不用看代码。最后要么请其他人审查 Agent 生成的代码，要么让多个 Agent 进行对抗式审查或盲审。
这些人一直在摸索、调整自己的工作方式，希望即使不亲自阅读代码，也能保持很高的效率。但显然，你不是这么做的。
Carlos： 确实不是。而且说实话，我甚至不太理解这么做有什么乐趣。
当然，如果你是在开发一款准备拿去卖的产品，想靠它赚钱，需要尽快推向市场，那我能理解。可如果只是为了自己做点东西，我就不明白了。
你让 Agent 去干活，自己出门逛个街、看场电影，回来看到 Agent 交付的成果，就觉得很满足？我实在体会不到这有什么乐趣。
Patrick： 拿我自己来说吧，有时候我想要的就是最终结果。我未必在乎这个结果是怎么实现的，代码写成什么样，或者将来好不好维护。
我只是想得到那个东西。 Carlos： 可你刚才不是还说，自己启动了很多项目，却没几个真正做完的吗？
那这两件事怎么解释？ Patrick： 因为有时候，我确实没能得到最初想要的结果。
我可能突然想到一个问题，琢磨该怎么解决，然后就让 Agent 花一整晚去研究。我觉得这种习惯也和工具的使用额度有关。
我每周都有一定的额度，如果没用完，就总觉得浪费了自己花钱买来的东西，有种错过了什么的感觉。所以我总想着尽量把额度用足，尤其现在，我觉得以后可能还会更贵。
于是，一遇到什么问题，我就想：不如先扔给 Agent 试试，看看它能做出什么。然后我再去探索、研究它生成的东西。
有时候虽然没达到最初预想的目标，但我至少学到了一些东西，或者摸索出一些组织任务、使用 Agent 的新方法，也算有所收获。这就是我现在的工作方式。
举个例子。有一次，公司给了我们一天的创新探索时间，可以自由做任何想做的项目，我就利用那一天搭了一套能够生成