ฝึกพูดภาษาอังกฤษด้วยเทคนิค Shadowing จากวิดีโอ: I Looked Into How Devs Are Actually Using AI

เลือกโหมดฝึก

แต่ละโหมดจะเปิดห้องฝึกแบบเต็มจอ

270 ประโยค

หากประโยคสั้นหรือยาวเกินไป กดที่ Edit เพื่อปรับแก้

So as developers, we've been promised a lot.

Over the past two years, we've heard the same story said a thousand different ways.

With AI, you're going to become a 10x developer.

You're going to be able to get so much more done.

And now I got to be honest, on my side projects, oh, I feel it.

I'm seeing gains that blow past 10x.

But my side projects aren't exactly representative of the industry.

But even within the industry, everyone seems to be getting different results.

I have dev friends in just about every part of it, the big AI labs, the Silicon Valley startup that just raised $5 or $50 million,

as well as enterprise, banks, defense, healthcare, what have you.

And what I've noticed is just how different their experience with AI is.

Stripping out any of the red tape, when they're all allowed to use all the same models, all the same harnesses on the code bases,

some are seeing smaller gains, up to 2x, if that.

Whereas on the other hand, take a look at Lauren here.

She has shipped 2 ,000 good PRs in a real production code base in a single month.

So I wanted to find out why.

Not how she was able to ship all that

because that's a whole video on that tweet that you can go ahead and watch.

But why is there such a big gap in the benefits that devs are seeing from AI?

So I read through everything I could get my hands on.

And one of the best stories I found, they took 50 different teams in the same company working on

existing systems with a normal mix of software engineers from junior to senior and gave them all the same AI tools.

Well, except for a few.

And a bunch of those teams saw less than 3x improvements, whereas some other teams saw over 10x improvements.

And there are very clear reasons why that we can replicate and do ourselves.

But before we get into that, a quick word from today's sponsor.

GrockBot, which I've found to be one of the easiest ways to really utilize AI in

so many different facets of my life.

Whether it's personal, Like I need it to shop for a two to four terabyte SSD

that has a Thunderbolt port

or I have it to research on what developers are talking about on X or what they're watching on YouTube.

But it's also very helpful when it comes to engineering.

Now I created a fresh engineer bot here, connected it to my GitHub and I'm going to have it take a look at my Jetty repo,

look at the PRs and tell me what each one is about and which ones are highest priority at the moment.

And as that works, I want to talk a little bit more about it.

One of the best quality of life things about GrokBot are the connections.

Take a look at all of the connections you can give your GrokBot.

If you're like me, you have it hooked up to Cloud Flare, Vercel, Google Sheets, PostHogX, Convex, as well as GitHub and Origin.

And for the engineering tasks, it actually uses cursor cloud agents.

So not only are those really good cloud agents, but also it means I can control everything from whatever device I'm using,

whether it be my phone, my laptop, or my desktop.

And after just a few minutes, there we have it.

The most urgent PRs in that repo are 81, 80, 85, and GitHub says they all merge cleanly.

So what I'm going to do is go ahead and merge the three most urgent PRs,

and then I'll take a look at the rest and see if I want those to be merged right now as well.

So if any of these tasks are something that you're interested in automating, or you're like me and you have thousands of unread emails,

well try out GrokBot at the link in the description, or just go to jetty .2 slash

Now, I know I already showed you this Lauren example, but she's not the only one shipping at these high rates.

You have Anthropic completely rebuilding their Git because Git couldn't handle their throughput of roughly 30 ,000 merges a day.

And these aren't even close to the only two examples.

They're just the most notable ones.

So if the labs are shipping like this, why can't normal companies?

Well, they kind of can.

And no, it is not by just throwing money at it.

I know that's the first thing everybody's going to say, because of course, it's going to cost money.

And these AI labs have infinite compute, and they're also heavily incentivized to ship with AI.

I get all that, but money is not the deciding factor.

What I mean is that if your company just started throwing money at a bunch of inference and tokens,

you're not going to be seeing these insane results.

There are a lot of other more crucial factors at play here, which is exactly what I went looking for.

I went through study after study, listen to stories from all these different companies reading all these different reports

and what i found was exactly the same as what i

was hearing from my friends the results are all over the place

i mean i saw anywhere from negative 19 increased output to you know 2x and above

but the story i mentioned earlier is what really caught my

eye to reiterate 50 ordinary teams in the same company working

on existing systems not building something from the ground up with a normal mix of junior

and senior software engineers with the results they saw being anywhere from under 3x

we don't know how low all the way to over 10x we don't know exactly how high

but that's the rough range from 3x to 10x and the company

that did that was amazon and i know okay they have money this

that and the other but there are countless there are countless companies

that have you know three developers on hand

and they're just throwing ai like crazy and they are shipping just as much as the examples I just gave you.

But that's never the example that people want to see.

They want to see it in an actual team environment that isn't just a startup, but a more established company.

And the only one that's giving these studies and these stories out to all of us, well, it's Amazon.

But they didn't just wake up one day and think, let's just throw AI at 50 teams.

It actually only started with one team.

So I want to lay the groundwork of how everything happened because it's important.

And they started it with a bedrock team, which makes a whole lot of sense considering,

well, that's the service that hosts Claude and GPT for AWS customers.

But they needed a whole new inference data plane.

To build this out, what they had estimated was they needed 30 people in 18 months to do it.

Instead, they took six engineers, gave them Kiro, which is their in -house codex or Claude alternative, and built it in two and a half months.

Which sounds insane, and it is, don't get me wrong, but it's a little bit less insane once you realize who did it.

The six engineers were some of the best in the entire company, people who already knew distributed systems and LLM architecture inside and out,

and two of which being distinguished software engineers.

So Amazon tried it again, but this time on Prime Video with a different six software engineers,

again using Kiro, and they gave them a 10 -day sprint.

And based on what they got done in that 10 -day sprint,

the project estimate that they were working on dropped from getting done in 90 weeks to only 24 weeks.

But something very important to note here, a senior engineer had spent three weeks before this even started writing out small,

detailed, well -scoped tasks for them to just be able to churn out.

And then we get to the actual 50 -team test.

Amazon Stores, which is Amazon .com and the physical stores, they ran this real test.

The 50 teams, the existing systems, the mix of junior to senior software engineers,

and just let them go wild using AI tools, Kiro to be exact.

And then they just kind of sat back and watched.

100

All throughout 2025, they weren't looking at the amount of commits coming through.

101

What they were looking at was how many things made it into production.

102

And this is where we get the number where half of

103

them actually came in under 3x the median was about 4 .5x, and with some teams being over 10x.

104

So how, with all of those variables in the same company, existing systems, mix of engineers, why is there such a discrepancy here?

105

Well, it's actually pretty straightforward.

106

So the teams that came in under 3x, they just took Kiro and just kind of sprinkled Kiro

107

and some of the other tools that we have on top of their existing way of working.

108

Any habits that they had in, you know, coming from previous sprints, they just, they didn't change anything other than plugging Kiro in.

109

That's the wrong way to do things.

110

I mean, they still saw results in that lower half, apparently up to three X, but the teams that did really well,

111

fundamentally changed how they worked.

112

And we know this because Amazon interviewed all of them

113

and their takeaways were five habits and they call them habits instead of like hacks or tricks or whatever,

114

because it, it truly does need to become a habit.

115

You need to change the way you used to work into the way you're now going to work with AI moving forward.

116

And the first habit of these teams that saw this success, they wrote everything down.

117

Everything that was over in Slack, in their head, in the code review comments,

118

and everywhere else, they took that and put it into their skills file, put it into their steering files,

119

gave it to the AI as context one way or another for it to have access to.

120

But not only that.

121

Every single time the agent did something wrong, they didn't just, you know,

122

type a bunch of cuss words at it because spoiler alert, AI isn't alive.

123

You as the human need to take responsibility.

124

They thought to themselves, what did I not tell it?

125

Like, what did I do wrong for it to come up with this conclusion, which is not at all what I was asking?

126

Like, how can I make this process better.

127

And then as the models began to improve throughout 2025, they started removing rules because maybe I don't need to be

128

so explicit with some things or give it these rules because the models are getting better.

129

And that is an overall trend

130

that we have seen over the past one to two years is that is you don't need as many rules.

131

And by me saying that is also not a rule.

132

It's just something I've personally experienced.

133

Obviously people love, you know, the skills repose, the P -Stack, the Matt Pocock skills, all of those things.

134

I'm not saying those are useless by any stretch of the imagination, especially not P -Stack.

135

That's something that y 'all should absolutely go look into.

136

But what I'm saying is that the more rules you have, the more context it has, you may just be blowing out the context.

137

And what's nice about actually today than when this story took place is

138

that you can connect your AI agent to all of these things.

139

You can have it connected to C.

140

all of the comments in the code review.

141

You can have it connected to Slack, certain channels in Slack, so you can see all of those notes that you have written down.

142

You don't necessarily have to pull it anymore from all of these different areas and give it,

143

you know, put into the skills file or what have you,

144

as long as you direct it and connect it to where it can get that information, as long as it's not in your head.

145

And the second habit or thing that happened here is that all of the good teams got slower first.

146

They noticed their productivity slipped at the very beginning.

147

But again, that's because they are building out the process.

148

They are building MCP servers for the AI agent so it can connect to everything that it needs to connect to.

149

They're fixing error messages so the model could tell exactly what broke.

150

They're even restructuring the entire code base so the AI agent could navigate it better, which I have thought about making an entire video on this

151

of how to actually restructure your entire code base from pre -AI era to now with AI era.

152

If that's of interest to you, just let me know.

153

And some teams even went as far as changing languages.

154

They went from maybe

155

Python or JavaScript to obviously the superior TypeScript or Rust

156

because you have the type checking

157

and you have the compilers yelling at the agents for you

158

so you don't have to do all of the back and forth.

159

I have talked about this ad nauseum in my past videos, there is a little asterisk there that may,

160

I will be going over in the next video or two, by the way.

161

So stay tuned for that.

162

I know two video plugs in a row.

163

I'm sorry.

164

The third habit was they didn't babysit the agents.

165

Listen, if you're going back and forth with, you know, a single agent or a couple agents all day where you are,

166

you know, responding to it every 30 seconds or minute, exactly when it is finished with a single task,

167

you're never going to see the four or five, six X improvement because you're the bottleneck.

168

You only have so much time in the day.

169

What the frontier teams did, they actually only wrote one to 2 % of their code by hand.

170

And for everything else, they would run agents that were looping for hours.

171

And obviously they would run multiple at once working on their own things, which is much more common nowadays.

172

You have to remember that this study, this deal happened in 2025.

173

It was a whole lot less common at that point to be looping, having an agent loop for hours.

174

For example, Ralph loop, if you remember that.

175

I'm pretty sure that happened in 2026.

176

It's been a long year.

177

A lot has happened.

178

So the way they got there is

179

that they were able to set it up and more or less ask the agent to keep going,

180

check its own work, and then come back to me after everything has compiled, ran, all tests are passed,

181

which means that it's going and it's building and it's compiling and it's fixing those errors.

182

And then that'll have new errors and it's fixing those errors.

183

And you get the idea.

184

This is actually kind of Lauren's whole thing too with P -Stack.

185

The idea there is to get like one agent that you, you build up to where you really trust it.

186

And only then do you start stacking them in parallel.

187

The fourth habit here is that they write the spec before the code.

188

Now this is more or less plan mode.

189

I don't really use plan mode anymore.

190

I use it for the first time the other day in a very long time, but the idea of it is still sound.

191

It's, you don't want to just give the AI a vague prompt.

192

And then once the code comes back and however it's implemented,

193

then you're arguing with it about the implementation and about the code and about changing it here,

194

there and whatever, you want a clear picture to give to the AI of what you actually mean.

195

This doesn't mean a whole entire spec list like this for every single thing you want.

196

I actually think that's overkill and that actually makes it worse.

197

You don't need to over -engineer your prompts, but you still need to be specific with your prompts,

198

even if they are smaller now than they were before.

199

This also derives from the fact that Amazon engineers, I think have always done spec -driven development, which is also built into their tool, Kiro.

200

And also it saves money to go back

201

and forth in regards to a document in plain English than trying to go through all of these diffs

202

that the AI had already generated of all of this code and then trying to make the changes then.

203

So not only is that the worst way to go about it, but it's also the more expensive way to go about it.

204

And the fifth and final habit

205

that they came to the conclusion of the 10x teams within Amazon is implementing something that everybody should already have implemented.

206

Tests, linters, integration tests, performance tests, security tests, this whole entire pipeline,

207

which is what I encouraged every single open source repository out there to build themselves

208

if they want to continue taking external contributions because it just makes everything so much easier in the age of AI.

209

Well, the material is built out properly, not only because you know you should do this

210

but the better it is the higher the roi like the roi is there now more than ever before

211

because that is one of the elements that lets the agent continue to loop

212

and test beyond the compiler beyond the type checks things of

213

that nature i guess that's included in there

214

but to run all of these tests

215

and run through the entire pipeline until it fixes is all of the mistakes that these tests in the pipeline find.

216

And something interesting that they do is mocking out all of their services locally on their own laptop.

217

So that way they can have a quick feedback loop with deterministic responses.

218

Because it lets the agent do everything locally.

219

Doing everything on your laptop without having to spin up a bunch of other services

220

and connect to cloud services makes everything a lot faster.

221

Because when you have a faster feedback loop, the more loops an agent can go through quickly

222

and then the more loops that agent can go through in theory

223

and in practice that we found the better the output so

224

that that's the gap they all had the same tools it's just

225

that you know the under 3x teams they didn't lay the groundwork

226

they didn't write down the context they didn't have the pipeline in place

227

and the tests in place

228

and everything in place in order to remove themselves from the loop but what's craziest about all of this, which I mentioned the fact,

229

but I really want to point it out here, is that all of this happened in 2025.

230

Opus 4 .5 was released on November 24th of 2025, at the end of the year.

231

All of this happened pre -Opus 4 .5.

232

This is with models like Claude 3 .7, 4 .0, 4 .1, which if you use these models,

233

you were keenly aware of just how bad they were relative to models today.

234

I mean, you'd ask 3 .7 to make a small refactor somewhere in a single file,

235

then it would come back with 20 changes that you didn't want from every corner of your code base.

236

Imagine what the output of these teams looks like now with the models we have today.

237

Oh, which reminds me, they're actually doing a new test in 2026.

238

That's what 2026 is about for Amazon is how do we scale this out to more

239

and more teams to the next 2000 teams instead of 50 teams.

240

And oh boy, I can't wait to see the results on

241

that one because if you have the right systems in place like the good teams at amazon do

242

and you follow all

243

that i laid out in this video models do greatly improve how much

244

you can get done as well as the entire ecosystem being built around

245

it i mean i hesitate to say this

246

because i feel like it's just common sense

247

but i know some people are on the outside of you know coding with ai

248

and things of that nature so i'm going to say it anyway the amount of progress we have made from 2025,

249

a year ago, when this story was taking place to today in terms of models

250

and harnesses and other tools in the entire ecosystem and how they can all be connected.

251

And also just how the models work.

252

It is a night and day difference.

253

So if some of these teams are seeing 10X back then, I can only imagine what they're getting done today.

254

So if you're sitting around wondering, you know, where are all these 10X devs that we were promised, they're here.

255

You're just not going to see it

256

if you were solely relying on the model and giving in minimal effort into using it.

257

It's the same idea, the same concept of working by yourself building something and working with a team building something.

258

Those are two completely different systems and rules

259

that you have to play by in order to optimize

260

and be useful from how your code base is structured to how your tasks are structured to how everything ties in together.

261

The other layer to that is AI agents.

262

But that's all I got for you today.

263

I hope you enjoyed the video.

264

Hope you learned something.

265

Hope you can take something away from this and apply it into your own development lifecycle.

266

Or maybe you just want to sit here and watch more videos.

267

If that's the case, well, there's a couple on screen that YouTube thinks you'll like.

268

So give them a shot.

269

Maybe you will.

270

But anyway, I will see you in the next one.

ดาวน์โหลดแอป

ทุกอย่างที่ต้องใช้เพื่อพูดได้คล่อง

AI ให้คะแนนการออกเสียงให้คะแนนทุกประโยค

ฝึก IPAเชี่ยวชาญทุกเสียง

คำศัพท์สร้างคลังคำของคุณ

เกมคำศัพท์เล่นไปเรียนไป

สแกน QR

Download on theApp Store Get it onGoogle Play

FOR YOU

วิดีโอแนะนำ

484 ประโยค

SoftBank CEO Masayoshi Son: Superintelligence, AI Investing, and the Future of Robotics

Daily ConversationUniversity StudentsWorking Adults

198 ประโยค

Jack Dorsey’s New Dessa AI Voice Sounds Scary Human

Daily ConversationUniversity StudentsWorking Adults

232 ประโยค

Seinfeld's Genius Advice for Success in the AI Age

Daily ConversationUniversity StudentsWorking Adults

678 ประโยค

So I tried Matt's skills...

Daily ConversationUniversity StudentsWorking Adults

คำศัพท์และข้อสังเกตด้านการพูดสำหรับบทเรียนนี้

บทเรียนฝึกพูดนี้ใช้วิดีโอ “I Looked Into How Devs Are Actually Using AI” เป็นสื่อ วิดีโอนี้มี 270 ประโยค และ 3681 คำ สำหรับฝึกพูดตาม ช่วงที่มีเสียงพูดยาว 18:34 ผู้พูดพูดเร็ว ประมาณ 198 คำต่อนาที จึงมีการเชื่อมเสียงและลดเสียงค่อนข้างมาก 86% ของคำอยู่ใน 3,000 คำที่ใช้บ่อยที่สุดในภาษาอังกฤษ ส่วนที่เหลือควรดูไว้ก่อนเริ่มฝึก

คำศัพท์สำคัญในวิดีโอนี้

คำที่ควรเรียนรู้ 15 คำจากวิดีโอ พร้อมคำอ่านและความหมาย:

คำศัพท์	คำอ่าน	ความหมาย
loop คำนาม	/luːp/	บ่วง
connect คำกริยา	/kəˈnɛkt/	เชื่อม, ต่อ
habit คำนาม	/ˈhæb.ɪt/	นิสัย
cloud คำนาม	/ˈklaʊ̯d/	เมฆ
output คำนาม	/ˈaʊtpʊt/	เอาท์พุต
insane คำคุณศัพท์	/ɪnˈseɪn/	บ้า
laptop คำนาม	/ˈlæp.tɑp/	คอมพิวเตอร์วางตัก, แล็ปท็อป
urgent คำคุณศัพท์	/ˈɜː.d͡ʒənt/	ด่วน
plug คำนาม	/plʌɡ/	ปลั๊ก, เต้าเสียบ
ecosystem คำนาม	/ˈikoʊˌsɪstəm/	ระบบนิเวศ
necessarily คำกริยาวิเศษณ์	/ˌnɛs.əˈsɛɹ.ə.li/	ต้อง
relative คำนาม	/ˈɹɛl.ə.tɪv/	ญาติ, ญาติพี่น้อง
argue คำกริยา	/ˈɑɹ.ɡju/	เถียง, ถก
server คำนาม	/ˈsɝvɚ/	เซิร์ฟเวอร์
encourage คำกริยา	/ɪnˈkʌɹ.ɪd͡ʒ/	ให้กำลังใจ, ส่งเสริม

กริยาวลีที่คุณจะได้ยิน

คำศัพท์	คำอ่าน	ความหมาย
go back คำกริยา		กลับไป
come back คำกริยา		กลับมา
try out คำกริยา		ลอง
wake up คำกริยา	/ˌweɪk ˈʌp/	ตื่น, ตื่นนอน

ประโยคที่ควรฝึกพูดซ้ำ

ประโยคสั้น ๆ ที่สมบูรณ์จากวิดีโอ ซึ่งนำไปใช้ในบทสนทนาประจำวันได้:

They thought to themselves, what did I not tell it?
It's just something I've personally experienced.
I don't really use plan mode anymore.

ไวยากรณ์ในวิดีโอนี้

โครงสร้างที่ผู้พูดใช้บ่อยที่สุด พร้อมคำพูดจริงจากวิดีโอ:

โครงสร้าง	ในวิดีโอ
Present perfect have/has + กริยาช่อง 3 — เหตุการณ์ในอดีตที่ยังเกี่ยวข้องกับปัจจุบัน	we've been promised · we've heard · I've noticed
Passive voice be + กริยาช่อง 3 — เน้นสิ่งที่เกิดขึ้น ไม่ใช่ผู้กระทำ	we've been promised · be merged · being distinguished
Relative clauses who / which + อนุประโยค — ข้อมูลเพิ่มเติมเกี่ยวกับคนหรือสิ่งของ	here, which is · team, which makes · Kiro, which is

การออกเสียงที่ควรระวัง

ผู้พูดใช้รูปย่อและรูปลดเสียง 68 ครั้ง เช่น you're, don't, they're ให้พูดแบบสั้นตามที่ได้ยิน

เสียง “sh” และ “zh”: conclusion /kənˈkluːʒən/, contribution /ˌkɑntɹɪˈbjuʃən/, implementation /ˌɪmplɪmənˈteɪʃən/, crucial /ˈkɹuː.ʃəl/, imagination /ɪˌmæd͡ʒəˈneɪʃən/
คำยาว — ลงเสียงหนักให้ถูกพยางค์: developer /dɪˈvɛləpɚ/, ecosystem /ˈikoʊˌsɪstəm/, necessarily /ˌnɛs.əˈsɛɹ.ə.li/, superior /sʊˈpɪɹ.i.ɚ/, architecture /ˈɑː.kɪˌtɛk.t͡ʃə/

เสียงที่คนไทยมักออกเสียงยาก:

เสียงท้ายคำ — ออกเสียงให้ครบ ไม่เปลี่ยนเป็นตัวสะกดแบบไทย: merge /mɝd͡ʒ/, whereas /(h)wɛɹˈæz/, countless /ˈkaʊntləs/, harness /ˈhɑɹ.nəs/, relative /ˈɹɛl.ə.tɪv/
/v/ — ไม่ใช่ /w/ ให้ฟันบนแตะริมฝีปากล่าง: developer /dɪˈvɛləpɚ/, relative /ˈɹɛl.ə.tɪv/, server /ˈsɝvɚ/, productivity /ˌpɹɒdʌkˈtɪvəti/, variable [ˈvæɹ.i.ə.bl̩]
/z/ — เสียงก้อง ไม่ใช่ /s/: whereas /(h)wɛɹˈæz/, enterprise /ˈɛntəˌpɹaɪz/, regards /ɹɪˈɡɑɹdz/, nowadays /ˈnaʊ.ə.deɪz/, hesitate /ˈhɛz.ə.teɪt/

วิธีฝึกกับวิดีโอนี้

ฟังวิดีโอให้จบหนึ่งรอบโดยยังไม่ต้องพูด แล้วจดคำที่ยังไม่รู้จัก
เริ่มที่ความเร็ว 0.75× พูดตามทีละประโยค แล้วกลับไปใช้ความเร็วปกติเมื่อเริ่มคล่อง
อัดเสียงตัวเองแล้วเทียบกับต้นฉบับ โดยสังเกตคำอย่าง loop, connect, habit เป็นพิเศษ

เทคนิค Shadowing คืออะไร?

Shadowing เป็นเทคนิคการเรียนรู้ภาษาที่ได้รับการรับรองทางวิทยาศาสตร์ พัฒนาขึ้นสำหรับการฝึกนักแปลมืออาชีพ วิธีการนี้เรียบง่ายแต่ทรงพลัง: คุณฟังเสียงภาษาอังกฤษจากเจ้าของภาษาและพูดตามทันที — เหมือนเงาที่ตามผู้พูดด้วยช่วงเวลาห่าง 1-2 วินาที การวิจัยแสดงว่าเทคนิคนี้ปรับปรุงความแม่นยำในการออกเสียง ทำนองเสียง จังหวะ การเชื่อมเสียง การฟังเข้าใจ และความคล่องแคล่วในการพูดได้อย่างมีนัยสำคัญ

เทคนิค shadowing: อ่านคู่มือฉบับเต็มทีละขั้นตอน →

ฝึกพูดภาษาอังกฤษด้วยเทคนิค Shadowing จากวิดีโอ: I Looked Into How Devs Are Actually Using AI

เลือกโหมดฝึก

ดาวน์โหลดแอป

How to Build an AI Agent for Every Part of Your Life

How AI is helping brands identify consumer trends faster

AI Destroyed My Profession

How AI Empowers Tech Leaders Siwei Shen

We Let $200 GPT-Pro Think for 7 Days on Unsolved Math

What AI Can Never Replace w/ Megan Kobzej | Cloud English Podcast Episode 91

Inside the secret race to build artificial intelligence | The Gray Area

Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic

SoftBank CEO Masayoshi Son: Superintelligence, AI Investing, and the Future of Robotics

Jack Dorsey’s New Dessa AI Voice Sounds Scary Human

Seinfeld's Genius Advice for Success in the AI Age

So I tried Matt's skills...

คำศัพท์และข้อสังเกตด้านการพูดสำหรับบทเรียนนี้

คำศัพท์สำคัญในวิดีโอนี้

กริยาวลีที่คุณจะได้ยิน

ประโยคที่ควรฝึกพูดซ้ำ

ไวยากรณ์ในวิดีโอนี้

การออกเสียงที่ควรระวัง

วิธีฝึกกับวิดีโอนี้

เทคนิค Shadowing คืออะไร?