你不需要初级程序员来写代码，但还是应该雇佣他们。

至少从一年前开始，你就不需要因为编程技能而招聘初级开发人员了。

For at least a year now you do not need to hire junior developers for their coding skills.

如果我们停止招聘初级开发人员，我们就永远不会拥有我们正在寻找的那种架构师原型。

If we stop hiring junior developers we will never have this archetype of an architect that we are looking for.

无论是产品经理、项目经理，还是团队负责人，在这种情况下，团队都是由智能体组成的。

Both a product manager, project manager, a team lead where the team is agents in that case.

我们真正要培养的技能不是多任务处理，而是多智能体监控，这样你就能指挥一个智能体团队。我并不是幻想你能管理成千上万个智能体，但也许你能管理六到十个。

The real skill that we're trying to build is the ability to not multitask but multi monitor agents so you will be able to command a team of agents And I'm not in in under any sort of fantasy that you can manage thousands of agents, but you can manage six to 10 maybe.

《AI原生开发者》是一档面向开发者和工程负责人的播客，内容聚焦前沿AI和智能体编程。

The AI native dev is a podcast for developers and engineering leads at the cutting edge AI and agentic coding.

每周，主持人盖伊·帕贾尼和我，西蒙·梅普尔，都会与AI领域最激动人心的声音对话，探讨当今开发者面临的最大问题。

Join your hosts, Guy Pajani, and me, Simon Maple, every week as we chat with the most exciting voices in AI and tackle the biggest questions facing developers today.

这里是《AI原生开发者》。

This is the AI native dev.

昨天，你还在写代码。

Yesterday, you were writing code.

今天，你在给智能体下指令。

Today, you're prompting agents.

明天，你就要运营一家软件工厂了。

Tomorrow, you'll be running a software factory.

智能体编程发展太快，快得让人措手不及。

Agentic coding is moving fast enough to give anyone whiplash.

今年六月，AI DevCon 伦敦站门票售罄。

This June, AI DevCon London sold out.

数百名开发者、工程负责人和副总裁齐聚一堂，聆听来自 Anthropic、OpenAI、Netlify 和 GitHub 的演讲者，他们拨开炒作迷雾，直击真正有效的方法。

Hundreds of developers, engineering leads, and VPs packed in to hear speakers from Anthropic, OpenAI, Netlify, and GitHub cut through the hype and get to what actually works.

今年十一月，我们将把它带回纽约，规模更大，气势更足，汇聚了真正在构建智能体未来的人们。

This November, we're bringing it back to New York, bigger, bolder, and full of people actually building the agentic future.

三天时间，真实演讲、真实工具、真实答案，无论你是在指挥智能体、构建循环本身、领导团队，还是制定战略。

Three days of real talks, real tools, real answers, whether you're directing the agents, building the loops themselves, leading the teams, or setting the strategy.

我们的早鸟优惠将于9月30日截止，所以请务必在涨价前锁定你的席位。

Our early bird pricing ends on September 30, so make sure you lock in your place before prices increase.

作为播客听众，你可以使用促销代码pod 15享受15%的票价折扣。

As a podcast listener, you can get 15% off your ticket using promo code pod 15.

我们准备了很多内容，非常期待在纽约见到你。

We have so much planned, and we can't wait to have you join us in New York.

大家好，欢迎收听《AI原生开发者》的又一期节目。

Hello, and welcome to another episode of the AI native dev.

我是西蒙·梅普尔。

My name is Simon Maple.

我是本期的主持人，今天和我一起的是Ran Aroussi，Automaze和MUXI的创始人。

I'm your host for this episode, and joining me is Ran Aroussi, the founder of Automaze and MUXI.

在今天的节目中，我们将讨论一些重要话题，比如可传授知识与经验知识的区别。

On today's episode, we're gonna be covering major topics such as the difference between teachable knowledge and earned knowledge.

如今初级开发者缺乏这种经验知识，他们该如何获取这些信息呢？

And where junior developers today lack that earned knowledge, how can they gain that information?

此外，我们还会聊到智能体工作流程。

Also, we're going to be talking about the agent workflow.

那么，“代理工作流”这个词本身是不是有点自相矛盾？

And is the term agent workflow an oxymoron in itself?

我们怎么才能在工作流中保持这种确定性呢？

How do we get that determinism to remain in a workflow?

最后，我们要聊聊律师事务所的模式，以及它如何适用于软件开发机构。

And finally, we're going to talk about the law firm model and how that applies to software development agencies.

我们是需要更多地考虑那种律师事务所的财富分配模式，还是应该坚持我们熟悉的SaaS模式呢？

Do we need to think more about that law firm model of distribution of wealth, or should we stick to that SaaS model that we're familiar with?

欢迎来到本期节目，Ran。

Welcome to the episode, Ran.

很高兴你能来。

It's a pleasure to have you.

非常感谢你邀请我。

Thank you very much for having me.

Ran是Automaze和MUXI的创始人，也是yfinance的创建者。

And Ran is the founder of Automaze and MUXI and the creator of yfinance.

跟我们聊聊这些事情吧。

Tell us a little bit about some of those things.

说起来，我的开发生涯开始于三十五年前，说起来有点不好意思。

So my developer journey started thirty five years ago, I'm sad to say.

是的，在那段时间里，我几乎在科技相关的各个行业都工作过，担任过团队负责人、首席技术官、首席执行官。

And, yeah, throughout that time, I've been working pretty much in any tech adjacent industry as a team lead, CTO, CEO.

我对开源真正的热爱始于九十年代末，那时我意识到，我们之前为了一个数据库不得不筹集数百万美元，而现在这一切都可以免费实现。

And my real love journey with open source started in the late, late nineties where I realized that one of my startups that we had to raise millions of dollars for just to have a database can now happen for free.

所以每次……

So every time that...

从那时起，每当我开发的东西不是我的商业机密，我都会乐意把它变成开源库。

Since then, every time that I develop something that is not like my business secret sauce, I happily turned it into an open source library.

其中就包括yfinance，它一下子就火了起来。

One of those indeed was yfinance and it just took off.

这真的很了不起。

I mean, it's quite amazing.

这一切都始于……

It all started when...

我现在还在做这个，但以前我更多地投入在算法交易上，而且我以此为生了一段时间，实际上成绩很不错，我也对此非常满意。

I'm still doing that, but I used to be a lot more invested into algorithmic trading and I've done this for a living for a while and actually with great results and was very happy about that.

我需要一个免费可用且非常Python化的数据源，以便下载市场数据。

And I needed a data source that was free available and very Pythonic so I can use it for downloading market data.

于是我就决定利用yfinance。

And I just decided to leech on yfinance.

我创建了这个库，它真的火了起来。

And I created this library and it really took off.

而如今，我得到的，我想最新的数字是每月大约2500万到3000万次下载，这太疯狂了。

And these days I'm getting, I think the latest number is about 25,000,000 to 30,000,000 downloads every month, which is insane.

我记得就在几年前，我还吹嘘每月有60万次下载。

And I remember just a few years ago, I boasted about having 600,000 downloads every month.

所以这真的很疯狂。

So it's quite insane.

而且这个数字还在不断增长，因为事实证明，每次你让AI写任何跟市场数据相关的东西，它都会用到这个库。

And this number keeps accumulating because it turns out that every time you ask AI to write anything related to market data, it uses that.

所以我觉得这就是过去一年真正增长的原因之一。

So I assume that is part of the real growth over the past year.

那是不是有一段时间，雅虎真的把他们的API给关掉了？

And wasn't there a time when actually Yahoo dropped their API for that?

他们从来没有关掉过API。

They never dropped their API.

这个库的工作方式不是靠爬虫，而是使用雅虎财经的官方API。

So the way the library works is not by scraping or it's using the official Yahoo Finance API.

只是他们非常努力地不想公开文档，但实际上是公开可用的。

It's just that they're trying really hard not to document it anywhere, but it is publicly available.

其实我收到过一封停止函，但当我指出这是公开API后，他们就说，好吧，抱歉，我们搞错了。

Actually got a cease and desist that after I pointed them to, hey, this is a public API, they said, okay, sorry, we're in.

然后他们就撤回了。

And they backed off.

所以我猜他们甚至不是雅虎雇的。

So I assume they weren't even hired by Yahoo.

他们只是想争取雅虎成为客户之类的。

They were just trying to land them as a client or something.

不过，是的，这绝对不是唯一一个这么做的库。

But, yeah, this is definitely not the only library that does this.

我只是觉得它做得很好，而且接口在API方面非常Pythonic，也非常简单，这是我很看重的。

Just think that it's doing it really well and that the interface is, API wise, is very Pythonic and very simple, which is something that I really believe in.

让我们减少你需要的代码行数。

Let's cut the number of code lines that you need to have.

是的，在过去，我不知道，四五年里，我经营着一家叫Automaze的软件开发公司，就像你提到的，我们倾向于做……

And yeah, over the past, I don't know, four or five years, I'm running a software development company called Automaze, as you mentioned, and we tend to kind of do...

现在叫FDEs，但我们倾向于让我们的开发团队融入初创公司和其他组织。

Now it's called FDEs, but we tend to embed ourselves into startups and different organizations with our development team.

我有点像公司的灵魂人物。

I act as kind of the the the spirit of the company.

我帮忙做产品规格，因为我过去几十年的经验是……

I help, with the specking of the product because my experience, over the past few decades is...

既在产品方面，也在技术方面，所以我算是能说这两种语言。

Has been both in product and in tech, so I kind of walk and untalk the the two languages.

我有一个很棒的团队，分散在欧洲各地，他们负责实际的开发工作。

And I have a great team that's scattered all around Europe that does the actual development.

我最近的一个得意项目，虽然代码库变得非常庞大，但使用量远不如yfinance，那就是MUXI，正如你提到的。这是我对AI部署方式的一种不同看法，就是把智能体作为基本单元，给它们自己的应用服务器，这样你就不需要写一堆代码来搭建智能体平台，直接部署就行。

And one of my most recent pet project that turned into a behemoth of a code base, although it's not nearly as used as as yfinance, is MUXI, as you mentioned, which is a different take on how I think AI should be deployed, which is having agents as primitive, give them their own application server, and make sure that you don't have to code your way into having an agentic platform, but just deploy.

所以它在部署方式上有点像Docker。

So it's kind of like a docker in terms of how you deploy.

就像MUXI的pull、push，你拉取一个formation，那就是整个配置。

It's like MUXI pull, push, you pull a formation, which is the entire setup.

所以，是的，

So yeah,

formation是一个……

a formation is a unit of...

就是一组代理的集合。

It's like collection of agents.

对吧？

Is that correct?

对。

Yes.

所以在最上面……

So at the top of the...

一个formation就是……

A formation is is...

它不只是代理的集合，还包括我所说的“霸主”，嗯。

It's not just a collection of agents, but it also includes what I call the overlord Mhmm.

就是那个决定整个formation性格的协调者，而代理本身就像是小兵，因为我不想记住该跟哪个代理说话。

Kind of the orchestrator that decides of the formation's personality, and of the agents themselves are sort of minions because I didn't want the experience of having to remember which agent I need to talk to.

这个是管邮件的。

This one does email.

这个擅长写作，我就想直接跟Jarvis说，让它去管理它需要的那些代理。

This one is a good writer, and I just wanted to talk to Jarvis and have it manage whatever agents it needs.

所以一个formation基本上就是告诉你，好，我要用哪些模型？

So a formation basically tells you, okay, which models am I going to use?

还有，我有没有基于角色的访问控制，这些背景信息是什么？

What are the back of whether or not I have role based access management?

它允许什么类型的记忆……

What type of a memory allow...

允许做什么？

Allowance to do?

我给它数据库。

I give the database.

这是组织级部署，我要用带各种扩展的Postgres，还是就我自己用，用我的SQL就行？

Is this an organizational deployment where I'm gonna use Postgres with all different types of extension or just for me and I'm just gonna use my SQL?

而且这些都是配置文件。

And it's all configuration files.

所以完全不涉及代码。

So there's no code involved.

所有内容都在YAML文件中，格式就是我所说的代理编排模式。

Everything is in YAML files in the format that I call the agent formation schema.

它同样是完全开源的，可以在agentformations.org上获取。

It's again fully open source, available in agentformations.org.

是的，它让你能够定义文档的核心，也就是它能做什么、工具、每个代理能访问的领域知识，而且它有一个非常精细的记忆结构，区分了偏好、记忆、决策、声明、工作记忆、缓冲记忆、情景记忆和近期记忆。

And yeah, it allows you to define both the, obviously the soul of the document, what it can do, the tools, the domain knowledge for every agent access to, it has a very elaborate memory structure where it differentiates between preferences, memories, decisions, claims, working memory, buffer memory, episodic memory, recent memory.

所以这是一种层次分明的记忆类型，因为我想要做的是模仿……

So it's a very layered type of memory because of what I'm trying to do is mimic how the...

我在这里真的很哲学化，因为我想要做的是模仿人脑在处理记忆时的工作方式。

I'm I'm really philosophical here because what I'm trying to do is mimic how the human brain works when it comes to memories.

有一种误解，认为观察和记录就是记忆。

There's the misconception that we're observation and logging is memory.

我不这么认为。

I don't think so.

我觉得知识的提炼和回忆才是记忆，因为我们可能记不住这里说的每一个字，但我们会记住要点。

I think that distillation of of knowledge and recall is the memory because we might not remember every single word that was said here, but we're going to have the takeaways.

我们会记住结论和达成一致的事情。

We're going to remember conclusions and things that we've agreed on.

我认为智能体记忆就应该这样运作。

And I think that's how agentic memory needs to work.

所以这些都整合在一起了。

So it's all bundled in.

你不用担心这个。

You don't have to worry about it.

你不需要……

You don't have to...

你只需要配置好你的智能体AI能做什么，你想从注册表中移除哪些工具。

You just need to essentially configure what your agentic AI can do, which tools do you want to remove from the registry.

如果你用Stripe MCP，那里有上百万个工具，但你只需要三个，所以没必要占用那么多内存。

You know, you're using Stripe MCP with a million tools over there, and you only need three, so there's no reason to hog the memory.

就告诉它，好的。

Just tell, okay.

这些就是我在这个应用里真正用到的两三个工具。

These are the only two or three tools that I actually use in this application.

它不会把其他工具都加载到内存里。

It's not gonna load any of the other ones into memory.

所以是的，这个设计考虑得很周全，是基于我自己在打造类似贾维斯这样的助手过程中遇到的需求。

So yeah, it's very well thought out based on the needs that I've encountered both in my own personal kind of Jarvis journey.

还有我们在部署时观察到的组织情况，我们实际上在美国成立了一家独立公司，专门在组织层面部署智能体AI。

And what I noticed with organizations that we've deployed, we actually created a separate company in The US for deploying agentic AI at the organizational level.

所以，简单来说就是这样。

So yeah, that's in a gist.

简单来说。

In a gist.

其中一个有趣的地方就是，那种所谓的操作指令，就像是为某个组织形态准备的。

And one of the interesting things there is the kind of like operating instructions as it were for a formation.

我觉得它们可以回顾那些指令，然后说，实际上，我想根据过去做事的方式来改变我自己的指令。

I believe they can kind of like retrospectively look at those instructions and say, actually, I want to change my own instructions based on historic kind of like how things have been done.

但关键的一点是，我认为这需要人的参与，说，对，我批准这个，或者我不批准那个。

One of the key things though there is I believe that requires a human interaction to say, actually, yeah, I do approve this or I don't approve that.

你觉得今天我们应该在哪里划清界限，是让系统完全自主，能够自我修复、调整和优化，还是仍然需要我们提供监督？

Where do you kind of like feel today we should draw the line between pure autonomy, where things can essentially self heal, fix, tune themselves versus requiring us to still provide an overview.

而且这条线今天是技术上的，还是我们需要自己划定的信任或文化上的界限？

And is that line more a technical line today, or is that more of a trust or culture line that we need to draw for ourselves?

我其实觉得这更多是信任的问题。

I actually think that it's more of a trust line.

我认为技术上你可以创建一个完全自主的系统。

I think that technically you can create a fully autonomous system.

我昨天正好在聊这个。

And I was actually talking about this yesterday.

我觉得AI可能会产生幻觉。

I think that, you know, with AI, it can hallucinate.

所以第一道防线就是确保它有最新的信息，知道怎么不仅存储信息，还能检索到正确的信息，这不仅仅是...

So the first line of defense is make sure that it has up to date information, that it knows how to not only store it, but retrieve the right information, which is not on...

总是只靠上下文。

Always just contextual.

它需要有那里的关系图谱。

It needs to have the graph of relationships there.

但即便如此，我们拿编程代理举个例子。

But even then, let's take a coding agent for example.

你给它一个目标，如果你不打算在任何时候介入，说，好的，试五次之后，或者两小时之后，不管你怎么设定阈值，回来找我，说做不了，让我帮你摆脱困境。

So you're giving it a goal and if you're not going to intervene at any point and saying, okay, after five tries, after two hours, whatever it is that you set as a threshold, come back to me and say, can't do it and let me help you get unstuck.

如果你不这样做，代理要么会生成垃圾代码，要么会烧掉很高的token费用，因为它会一直尝试，或者它们会伪造测试结果，只是为了通过测试。

If you don't do that, agents will either create slop or run a very high token bill because it's just gonna keep trying or they're gonna fake the tests just to have the test passed.

让测试快点通过。

Get the test screened quick.

没错。

Exactly.

不惜一切代价。

By any means.

我们都见过AI写的代码，注释里写着‘这里以后需要修改’之类的。

And we've all seen code with the comments by the AI, this need to be changed later to dot dot dot.

为了建立信任，我觉得人类仍然需要参与规划和确认阶段。

In order to have that trust, think that the human still needs to be in the planning and in the confirmation stage.

所以你需要明确，什么叫‘完成’？

So you need to, what is the definition of done?

我要达到什么目标？

What am I trying to achieve?

在制定规格的这两个步骤中，你需要参与，而且在……也需要在场。

And you need to be there in these two steps in the speccing, and you need to be there in the...

就是确保它真的做到了。

Just making sure that it actually happened.

其他所有事情，你都可以给系统设置不同的约束，这样你就不需要再看代码了，因为如果你设置了足够的约束，比如‘好的，……’

Everything else you can put on different constraints on the system where you don't really have to look at the code anymore because if you put enough constraints that says, okay, the...

我们需要达到这样的代码分析水平，而且这需要……

We need to achieve this level of code profiling, and this need...

我们需要达到这样的测试数量和回归测试数量。

We need to achieve these amount of tests and regression tests.

你设定各种约束条件，只要所有检查都通过，代码质量自然就是好的。

And you put all sorts of constraints that by definition, the code quality is good if everything is green.

至于代码好不好看，反正你以后也不会再看它，所以无所谓。

The fact that whether or not it's pretty or not, you're not gonna look at it anyway in the future, so it doesn't matter.

重要的是代码要高效，并且能被AI维护。

What matters is that it's efficient and that that it's maintainable by the AI.

你可以通过各种规则和约束来解决这个问题。

And you can solve this with all sorts of rules and constraints.

所以我觉得，让AI做所有事情，技术上没什么大障碍，但更多的是质量保证和信任的问题。

So I don't think there's a lot of technical constraints for us to let AI do everything, but I think it's more of a quality assurance and trust.

而且

And

回到MUXI，你提到你有几种改进方案的方法。

going back to MUXI, you mentioned that you have several ways of improving a formation.

一种是方案持续学习，并生成一个供人类审阅的文件。

One is formation keeps learning and creates a file that is ready for the human to review.

所以它不会自动更新自己，而是会生成一个新版本，以git格式等待你查看差异，如果你批准，就部署那个版本，比如1.1。

So it will never kind of auto update itself, but it will create a new version of itself and it will wait for you in a git format and you can look at the diff and if you approve it then you deploy a version whatever it is point one.

我觉得你就是这么做的。

And that's how I feel that you do it.

我甚至没有允许完全自主运行的选项。

I haven't even allowed a flag of having it fully autonomous.

我只是不相信，在一个需要信任的系统中，你可以容忍不稳定。

I just don't believe that in a system that you need to trust, you can have flakiness.

有些系统，关乎健康，关乎生死或巨额资金。

You know, some systems, it's it's health, it's gonna be life or a lot of money.

所以，是的，你只需要投入时间。

And so, yeah, you just put put in the time Yeah.

去审查它。

To review it.

这其实很有意思，因为对我们Tessl来说，我们有自己的软件工厂，我们会查看每一个生成的拉取请求，即使从问题到拉取请求几乎是端到端的，测试、代码生成这些方面都是自动化的。

It's very interesting actually because, I mean for us at Tessl, have our own software factory that we look at every single pull request that is generated, even though it's pretty much end to end from issue to pull request, automated in terms of the testing, cogeneration, things like that.

我们确保验证和核实所有进入生产环境的内容。

We make sure we validate and verify everything that goes through to production.

但对于我们自己的……

But for our own...

对于我们的一些内部工具，比如我们自己的暗工厂，我们允许完全自主地从问题一直到合并的拉取请求，而不需要……

For some of our internal tools, for example, our own dark factory, we allow fully autonomous going from issue all the way through to to, you know, a pull request that gets merged without...

它被合并了。

It's merged.

好的。

Okay.

而且我认为对于内部来说，很大程度上是信任，还有关键性。

And and I think for the internal, a lot of it is trust, lot of it is criticality as well.

问题是谁会先发现这个问题？

And it's a case of who's gonna find this first?

是我们发现，还是用户发现，然后影响到你的品牌或数据，诸如此类的事情？

Is it us, Or is it going to be a user that actually then affects your brand or your data, those types of things?

在某些情况下，我们实际上有维护代理在运行。

And in some cases, we actually have maintenance agents that will run.

他们会观察暗工厂的运行情况，观察代理的运行情况，创建问题，解决问题，合并这些问题，而我们甚至根本不知道这些问题被创建或合并了。

They will observe how the dark factory is running, how agents are running, create issues, resolve, merge those issues, and we don't even realize those issues are being created or or merged at all.

这确实是一个令人不安的世界，但几乎就像是在非关键系统中逐步推进，直到我们真正进入生产环境，然后说，好吧，我们离在生产的次要关键部分实际做到这一点还有多远？

And it's it's a it's a scary world to live in, but it's almost like progression in small steps in non critical systems first, till we actually then go to production and say, right, how close are we to actually doing this in lesser critical parts of production?

我认为这将是一个渐进的文化变革。

And it's gonna be a gradual cultural change, I think.

确实如此，我同意你的看法，如果这是关键任务并且是品牌的一部分，我们希望有人类参与其中。

It is, and I agree with you that if it's mission critical and it's part of your brand, want to have humans in the loop.

是的，人类的角色将会转变。

And yeah, the role of humans would shift.

就算到今年年底还有几个月，情况也会发生变化。

Even in the few months that we have till the end of this year, it will change.

这个角色会转变，可能会缩小，但我觉得不会消失。

And the role will move and may maybe diminish, but I don't think it's gonna be removed.

不会的。

No.

有意思的是，我们也有自己的软件工厂，我们有一个类似Sentry的功能，叫ladybug，它能在生产环境中自动捕获bug，自动生成诊断，并且已经有一个PR在等着我们处理。

And it's funny because we we also have obviously our own software factory, and we have this Sentry like feature we call ladybug that catches bugs in while they're still in production even, automatically a diagnosis created and there's a PR waiting for us on the other side.

有了这个工具真的很棒，早上醒来就能看到PR。

And it's been really fun to have this tool and just wake up to PRs.

对，这尤其在凌晨三点特别重要，你不会希望一个迷迷糊糊、还没喝咖啡的人去诊断问题。

And that's, yeah, it's particularly important in the 3AM, you know, you don't get some groggy human who's like, you know, just waking up with pre coffee trying to diagnose something.

等他们醒来查看PR的时候，问题已经被完全诊断，根本原因分析也完成了，所有东西都准备好了，就等他们审查。

By the time they have woken up to look at a pull request, it's already been fully diagnosed, RCA, they've got everything waiting for them that they have to review.

对于这种会造成经济损失的故障，这太重要了。

And, you know, for these type of outages that will cost money, that's so important.

确实如此。

It is.

再看看几周前OpenAI和Hugging Face遭遇的攻击事件。

And look at the OpenAI Hugging Face breach that happened a few weeks ago.

如果我没记错的话，大概有17000次攻击尝试之类的。

If I recall correctly, it was like 17,000 hacking attempts or something like that.

一个人坐在日志前面，端着一杯咖啡，根本不可能处理完这些，因为等他们看完那17000条日志，可能又变成170万条了。

There's no way a human, you know, sitting in front of logs with a cup of coffee can work through this because by the time they go through the 17,000 log items, it's gonna be a 170 times log items.

所以你必须得有这些系统来帮你处理这些事情。

So you have to have those systems in place to to actually do this for you.

大家好。

Hey, everyone.

我叫Sahil，是Tessl的工程师之一。

My name is Sahil, and I'm one of the engineers here at Tessl.

我将于9月16号和17号在纽约和波士顿，跟大家聊聊我们在Tessl是怎么构建软件工厂的，以及在AI原生的世界里，工程工作是什么样的。

I'm gonna be in New York and in Boston on the sixteenth and seventeenth of September talking about how we've built our software factory here at Tessl and what engineering looks like in an AI native world.

我会深入讲讲我们构建的那些组件，它们为什么存在、为什么有用，我们一路走来犯过的错误，还有我们早期关注的那些指标，其实后来并没有帮到我们，以及那些真正起作用的指标。

I'm gonna be diving in to the components that we've built out, why they're there, why they're useful, the mistakes that we've made along the way, the sort of metrics that we focused on early that actually didn't end up helping us, and the ones that actually did.

还有那些最终塑造了我们今天这个工厂的各种特点和功能。

And all the different quirks and features that ended up building out the factory that we have today.

这次会更实际地看看我们Tessl这里的工厂，讲一些具体的运作方式，以及我们为什么做出某些决定。

This is gonna be a much more practical look into the factory that we have here at Tessl and some of the specifics on how it works and why we made some of the decisions that we did.

去tessl.io/events看看吧，希望到时候能见到大家。

Go to tessl.io/events, and I hope to see you all there.

那么，Ran，你也写了不少书吧。

Now, Ran, you've also created a number of books.

我其实没有……

I've not...

除了博客文章，我算不上什么作者。

I'm not an author other than blog posts.

我觉得那不是真的。

I don't think that That's a lie.

不过我也算不上真正的作者。

Not that I'm really an author from that.

但我特别喜欢的一句话是关于智能体系统的，说它们其实根本不具备真正智能体应有的任何特性。

But one of the one of the quotes that I really loved is in and around how agentic systems have zero of the properties that would actually make them agentic.

跟我们讲讲这个吧，还有大多数团队在思考或构建智能体系统时，最容易搞错的是什么？

Tell us a little bit about that, and what what is it that most teams get wrong when thinking about something that is being agentic or building something that's agentic?

对，我把这个分成两个概念。

Right, so I separate this into two terms.

一个是自动化，一个是完全智能体，后者意味着自主和主动，就像你团队里多了一个人，除了你设定的限制外，你无法控制它。

There's automations, there's fully agentic, which means autonomous and proactive, and it's just another person on your team that you have no control over other than the gates you've set in.

而我看到的大多数东西，要么是自动化，要么是加了点AI的自动化。

And most of what I see is either automations or automation with AI sprinkled in.

我觉得有个误解，就是“智能体工作流”这个词本身有点自相矛盾。

And I think there's a misconception that agentic workflow, the term itself is kind of an oxymoron.

原因在于，如果是工作流，那你就已经给AI规定了路线或路径，它就没法自己做决定了。

And the reason is that if it's a workflow, then you've already given the road or the path that the AI needs to work in, so it doesn't get to make its own decisions.

我觉得现在大家的关注点主要都在这里。

And I think that that's where a lot of the focus is on right now.

大多数做AI和智能体相关的人，其实都在关注这个。

Most people who are doing AI and agentic stuff, this is actually what they're focusing on.

他们并不是在真正创造那种能自己思考、自己产生想法的实体。

They're not focusing on actually creating this entity that can actually think and and and come up with ideas for itself.

而那些真正多走一步的人，都被AI的能力惊艳到了。

And the few people who actually went that extra mile are amazed by how capable AI can be.

这也没关系，我不是在贬低谁，因为大多数场景下你确实需要工作流，不需要那种智能体自动化之类的东西。

And it's fine because, I'm not dissing anyone because for most use cases you do need workflow, you don't need the agentic automation and all of that stuff.

如果是确定性的流程，你根本不需要AI。

If it's deterministic, you don't need AI.

如果是确定性流程但有些模糊的部分，比如某个步骤需要AI来写邮件，那这就是一个工作流，里面加了些AI，像N8N早就这么做了。

If it's deterministic with some fuzzy bits like, okay, need AI in this step to write the email, yeah, then it's a a it's a workflow with AI sprinkled in, you know, tools like N8N did that a while ago.

这不像OpenClaw或Hermes那样，是一个活生生的、能自主决策的实体。

It's not like a full living, breathing entity that just like OpenClaw or Hermes or anything like that, that just decides on its own.

对，所以这就是我的看法。

And yeah, so that would be my take on it.

我觉得如果你在考虑是否要完全采用智能体自动化，先想想你是否真的需要它，或者你……

I think that if you're thinking whether or not you should go fully agentic and autonomous, first think of whether or not you either...

你的组织是否真的需要这个。

You even need that in the organization.

很多业务流程是完全确定性的，所以……

A lot of business operations are fully deterministic, So you...

很多地方用了AI，但其实根本不该用，只是在浪费钱。

There's a lot of AI that's being used in places that shouldn't be used and it's just costing you money.

一个简单的脚本就能搞定……

Where a simple script...

我见过太多次用AI来解析字符串，其实简单的正则表达式就能完成。

The the number of times I've seen AI try being used to parse strings where simple regs can just do the work.

更快，更便宜。

Faster, cheaper.

更快、更便宜，基本上免费，这真是……

Faster, cheaper, literally free, you know, which is...

所以，挺可惜的。

So yeah, it's a shame.

现在Automaze有一个四阶段的阶梯式方法，从我认为的“无电脑纯理解”到更完整的“架构师模式”。

Now Automaze has this four phase ladder approach from, I think it's no computer pure understanding to more of a full architect mode.

首先，跟我们简单介绍一下这个，然后我想深入聊聊。

First of all, tell us a little bit about that, and then I'd love to dig in a little bit.

是的，我们意识到，至少从一年前开始，你不需要雇佣初级开发人员来写代码。

Yeah, so we came to realization that for at least a year now you do not need to hire junior developers for their coding skills.

你不需要他们做这个。

You don't need them for that.

如果我们停止雇佣初级开发人员，我们就永远不会拥有我们一直在寻找的那种架构师。

Now if we stop hiring junior developers we will never have this archetype of an architect that we are looking for.

架构师是——我不知道这个词会不会流行起来——但就是那种既懂产品又懂技术的人。

And an architect is, I don't know if this is a term that's gonna catch on, but it is someone that walks both understand the the product.

所以它既是产品经理、项目经理，又是团队负责人，只不过在这种情况下，团队是由智能体组成的。

So it's both a product manager, project manager, and, a team lead where the team is, agents in in that case.

所以我们的运作模式是分成小组，每个小组里有资深开发者，也就是架构师，负责管理这些智能体，还有一位面向客户的交付经理。

So we work in an operation where we have pods and that pod has the senior developer, it's kind of the architect, manage these agents, and client facing individual which is the delivery manager.

他们负责和客户沟通。

And they kind of work with the client.

一个对外，一个对内。

One is working externally, one is working internally.

初级开发者就像学徒一样，跟着学习，就像文艺复兴时期，学徒跟着绘画大师，学习门道，到处摸索，有时候还能接到自己的项目，然后完成它。

And the junior developers are there as apprentices for, they're kind of joining along, like in the Renaissance days you had the apprentice and they would join the master painter and kind of learn the rope and dabble around and sometimes would get their own project and he just finished this up.

所以我们真正要培养的技能不是多任务处理，而是同时监控多个智能体。

So this is the real skill that we're trying to build is the ability to not multitask, but multi monitor agents.

这样你就能指挥一个智能体团队了。

So you will be able to command a team of agents.

我并不是幻想你能管理成千上万个智能体，但管理六到十个也许是可以的。

And I'm not in under any sort of fantasy that you can manage thousands of agents, but you can manage six to 10 maybe.

但你需要……

But you need to...

这又回到了工作流程本身。

That goes back to workflow itself.

你需要知道如何制定产品规格。

You need to know how to spec products.

你需要了解哪些是代理能做的，哪些不能，并在开发软件时充当他们的导师。

You need to know what agents are capable of and we're not capable of and be their mentor when it's time to develop a software.

在关键时刻把关，比如：这个产品能上线了吗？

Be at the gate where, okay, is it ready for production?

我是否设置了正确的流程，比如当PR准备好时，我希望能立即创建一个环境，让整个系统运行起来，并执行端到端测试。

Did I put in the right workflows where when the PR is ready, I wanna immediately create an environment where the full system is up and end to end test run.

所以你需要学习这类东西。

And so you need to learn these types of things.

而且我觉得这些不是光靠读编程书就能学会的。

And these are things that I don't think you can learn from reading programming books.

而且……

And...

这挺有意思的，从工作流程的角度来看，有很多新东西。你知道，我们这些有经验的开发者需要重新调整自己的操作方式。

That's what's kind of interesting, where there is so much new from the point of a workflow, from the point of you know, we as experienced developers are needing to reprogram ourselves in terms of how we operate.

对于初级开发者来说，他们更容易适应不同的工作流程，因为他们没有过去多年积累下来的那种习惯，比如我得坐下来，先做详细设计，再写代码，然后再做……

From a junior developer point of view, it's gonna be easier for them to snap into a different workflow because they don't have the baggage of many, many years gone by of, alright, I need to sit down, do these deep designs, then code, then do...

然后等等等等。

And blah blah blah.

但从初级开发者的角度来看，他们当然不太理解更复杂的架构和设计。

But from the junior developer side, of course, they don't truly understand, you know, the more complex architectures, complex designs.

对。

Yep.

当他们凌晨三点醒来去解决问题时，这可能是针对有经验的开发者，他们知道当AWS出问题时会发生什么，影响是什么，以及如何修复。

When they wake up at three in the morning to to solve something, this could be, you know, for experienced developers, they understand what happens when AWS goes out, what the implications are, and how to go around fixing that.

你觉得有点像……

What would you say are kinda like...

你觉得初级开发者和资深开发者，也就是更有经验的开发者，是怎么适应这种新的开发工作流程的？

How are you seeing both junior developers and senior developers, more experienced developers, snap into this new model of development workflow?

对哪一方来说有哪些劣势？

Where are the disadvantages for either?

我觉得他们必须合作，因为你刚才举的例子，这些都是积累出来的经验。

I think that they have to work together because of the examples that you've given, this is earned experience.

这个没法加速。

You cannot accelerate that.

你必须亲身经历，才能理解一台双核CPU的机器到底能承受多大的负载。

You have to be there and you have to understand the consequences of, you know, just how much load can a two vCPUs machine can handle.

这不是靠算就能算出来的，因为你的应用和我的应用不一样，和你以前做过的那个应用也不一样。

Okay, this is not something you can math your way around because your application differs from my application or that other application that you've worked on in the past.

所以，你需要有这种……

So, you need to have this...

这就是积累出来的经验。

It is earned experience.

这段时间是没法压缩的，但如果能带一个初级开发，以前初级开发要三到四年才能达到中级水平，七到八年才能成为高级开发。

There's no way of condensing that time, but if we can take a junior developer, it used to take junior developer like three to four years to become like a good level of mid level developer and seven to eight to become a senior developer.

我觉得我们可以压缩这个过程，但不可能压缩到零，也不可能压缩到一年，大概两年吧，一个初级开发——我相信你也有这种经验。

I think we can compress this, but not to zero and not to a year, probably to a two year where a junior developer, and I'm sure you have this experience.

我相信你现在看到的初级开发，他们来了一年后的价值，比五年前来了一年的初级开发要高得多。

I'm sure you're seeing a lot more value from junior developers when they're here a year versus junior developers that were after a year, like five years ago.

因为他们能产出更多。

Because they can produce a lot more.

他们可以，怎么说呢，少去烦高级开发，因为他们真的能用智能体来，比如，带我看看这个问题，带我看看这个函数，为什么它会这样？

They can, for lack of a better term, nag the senior developer less because they can actually use agents to, okay, walk me through this problem, walk me through this function, why is this doing that?

然后带着更成熟的问题去找高级开发帮忙。

And then come more baked with the questions ready to the senior developers for help.

我觉得这正是学徒和导师关系的本质，他们必须在一起待一段时间，初级开发才能准备好独立带团队。

And I think that that's exactly the role of an apprentice and a mentor kind of relationship that they have to be together for a while before the junior is ready to of just start their own pod.

我也不急着让他们独立带团队。

And I'm not in any rush to give them their own pod.

我觉得如果他们要花一两年时间，那也没问题。

I mean, I think that if it's going to take them a year or two, that's fine.

以前要五年，所以我们现在挺好的。

It used to take five, so we're fine.

我很喜欢这个说法，你把它叫做可传授的知识和靠经验获得的知识，对吧？

And I love that, I think you call it teachable knowledge and earned knowledge, right?

而且我觉得，就像你说的，可传授的知识以后会被大幅压缩。

And I guess that is something that is, as you mentioned, teachable knowledge being heavily compressed going forward.

当我们看五年前靠经验获得的知识，现在要获得这些知识会难得多，因为很多东西都被拿走了。

When we look at what was earned knowledge five years ago, that's going to be so much harder to earn now because so many things are being taken away.

嗯，被拿走了，但很多东西都被自动化了，我们现在可以把事情交给智能体去做。

Well, taken away, but so many things being automated and and we can hand things over to an agent now.

你觉得以后在靠经验获得的知识方面会不会出现一个缺口，而这些知识又很重要？

Do you feel like going forward there's gonna be a gap here in earned knowledge where it's important to have that knowledge?

这些知识不是真正能传授的，而且我们也没法再通过经验获得了，因为很多都被交给智能体了。

It's not really teachable, and we can't earn it anymore because so much of that is being handed off to an agent.

那会不会有一个我们很难跨越的鸿沟？

Is there a gap there that we're going to struggle with?

我觉得是有的。

I think there is.

我对此没有好的解决办法，但不知道你怎么看，我们六年前搬到了英国，所以我和我妻子都换了新手机号，和过去二十年用的号码不一样了。

I don't have a good solution for that, but I don't know what about you, but we moved to The UK six years ago, So my wife and I both got new phone numbers different than the ones we had for the past twenty years.

我根本记不住她的号码。

And I don't know her number by heart.

我自己的号码也几乎记不住，因为拿到新号码的时候，直接就存进手机里了。

I barely know mine because we just, when we got her new number, it just went straight to my phone.

所以我的大脑根本没有机会去记它。

So my brain never had the opportunity to memorize it.

而且有了AI，我觉得我们就像在赛跑，看它能在我们忘记怎么做事之前帮我们做多少事，以及它能不能在痴呆症变得更普遍之前治好它。

And with AI, I think we're sort of in a race between how much it can do for us before we forget how to do it ourselves So whether or not it can cure dementia before it becomes a wider option than it already is.

所以，是的，我对此没有好的答案，但肯定会有一些事情你根本不需要知道，因为现在有了新的解决方案，而有些事情你可能得强迫自己去练习，只是为了给自己创造一种情境。

So yeah, I don't have a good answer for that, but definitely there will be things that you won't even need to know because there are new solutions for them now, and some things that you'll probably have to drill yourself into, just to create a situation for you.

这可能是一个部分解决方案，制造那些虚假警报。

And that might be a partial solution, create those false alarms.

每栋办公楼都有消防演习。

Every office building have fire drills.

所以显然你得这么做。

So you'll you'll have to you'll have to do these apparently.

随着这些新工作流程和团队适应了更智能化的代理工作流，进入软件工厂模式，你觉得你的团队在效率、效果，甚至交付时间方面提升了多少？

With these new workflows and our teams being adjusted into the kind of, you know, more agentic workflow leading into a software factory, how much would you say your teams have become more efficient, more effective from, you know, even a time of delivery point of view?

这其实很有意思，因为大约一年前我们很担心销售会怎么样。

It's actually very interesting because we were kind of weary about a year ago what would happen to our sales.

我们当时是按固定费用合作的。

Were working on a retainer basis.

现在因为AI的承诺，我们会更快完成事情。

Now we're just gonna finish things faster because of the AI promise.

那意味着我们客户的终身价值会降低。

And that would mean that we're gonna have less lifetime value of our clients.

这种情况并没有发生，因为虽然我们能缩短开发时间，比如概念验证，大概能减少80%的时间。

That didn't happen because while we are able to shorten the development time, probably a proof of concept, you can reduce it to up to like 80% of the time you can cut off.

但对于真正的生产级系统，可能只能减少三分之一的时间，因为还有很多测试和很多边缘情况需要测试。

But for a true production grade system, you can probably go down by a good one third of the time because there's still a lot of tests and so many edge cases that you have to test for.

所以我觉得大概能节省30%到40%的时间。

So I would say maybe 40 to 30% of the time you're able to cut.

但对我们来说，实际发生的是我们现在交付更多了。

But what happened for us at least that we just ship more now.

所以项目并没有结束，客户的那个愿望清单就直接继续，我们不断添加新功能。

So the project is not ending but all that bucket list that client had just goes straight on and we're just adding stuff.

那个积压的“我们可能有一天会做”的清单，现在变成现实了吗？

The backlog of, oh, we might get to it one day, is that becoming a reality now?

没错。

Exactly.

所以现在是不是预期功能和服务会便宜一些，还是说，你知道的？

So do expect to pay less for functionality and features now or is it, you know?

我想他们确实会这样，但因为我们本来就是按月收费的，所以是的，他们每个功能付的钱少了，但我们的定价模式没变。

I assume they do, but since we charge on the monthly retainer anyway, so yeah, they pay less per feature, but our pricing model hadn't changed.

所以我们的客户平均会跟我们合作三年。

So we have clients staying with us for three years on average.

是的，你的客户现在实际上得到的更多了。

Yeah, it's Your customers are actually getting more now.

他们得到的多得多。

They're getting a lot more.

和

The same as

和……其实我特别喜欢的是，我们很多客户，尤其是新客户，都是做那种“氛围编程”实验的，他们带着自己开发的应用来找我们。

the same as And what I actually like is a lot of our clients, especially with new clients that we get, these are vibe coder coding experiments, and they're coming to us with an app that they've developed.

不错。

Nice.

显然那离上线生产还差得远，但我其实挺喜欢这样的。

And obviously it's not anywhere near ready for going to production, but I actually like this.

有些人作为开发者或提供软件开发服务的机构会对此不满，但我其实很喜欢，因为我确切知道客户想要什么。

You know, some people resent that as a developer, as an agency that provides software development, but I actually like it because I know exactly what the client is after.

当然，我们得替换掉99%的代码，重新做所有东西，可能还要换技术栈之类的。

Sure, we're going to have to replace 99% of the code and redo everything, maybe change stacks or...

但没关系，只要你能在Claude里把你的想法做出来，哪怕看起来丑或者怎么样，我们就能从产品角度真正理解你的需求。

But it's fine as long as you can develop your vision in Claude even if it looks ugly or whatever it is, but we get a real sense of what you're after from a product perspective.

就算你只做几个模拟页面，也没问题，就是一些看起来像你想象中的应用的HTML页面。

Even if you just do mocks, that's fine, just a bunch of HTML pages that sort of look like the app you're imagining.

我真的很喜欢这一点，因为这样就不会有误解。

I actually like it because there's no misunderstanding there.

所以我非常喜欢这种方式。

So I actually like it very much.

这比光看规格说明要清晰多了，对吧？没错，就是这样。

More clarity than just speck or something Yeah, exactly.

对。

Flat

在

on the

Ran，我了解你，我不知道你现在是否还这样做，但你以前确实为每个新的Automaze客户担任FDE，现在还是这样吗？

Now Ran, I understand you, I don't know if you still do, you used to certainly act as an FDE for every new Automaze client, is that still the case today?

有些是。

Some.

有些是。

Some.

对，某种程度上是这样。

Yeah, it's true to some extent.

首先，告诉我们FDE的角色是什么？

First of all, tell us what is the role of an FDE?

其次，我想了解这如何扩展。

And then secondly, I'd love to understand how that scales.

你是否最终认为我需要放弃这个，需要扩大我的FDE团队？

Is that something, you know, you eventually think I need to give this up, need grow my FDE team.