跟讀練習: Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic - 通過影片學習英語口語

選擇練習模式

每種模式都會開啟全屏練習室。

286 句

如果句子過短或過長，請點選 Edit 進行調整。

I had some technical difficulties during my talk this morning.

So I ran back home and I'm just going to record it from my computer instead.

So hi everyone.

I'm Lydia.

I work on the clock code team at Anthropic and the models have gotten really good lately.

So we have Opus 5 .5, which is my favorite daily driver.

And earlier this week, we also launched Fable 5 .2.

And these models are extremely good at long running tasks and understanding your code base.

And especially Fable was also really good at verifying its own output.

But as these models get better, the way that we work with them in Cloud Code also changes.

So earlier this year, I don't know if you remember, but sessions kind of used to look like this.

So we'd use a model like Opus 4 .5, which honestly for its time was really good.

I really enjoyed working with Opus 4 .5.

But compared to today, it would just stop a lot earlier.

So it would just run for shorter amounts of time.

And we'd also keep correcting it.

We'd keep reminding it to do things, add things like importance, exclamation mark, all these things to our CloudMD file.

And also features like auto mode didn't exist yet.

So we were either approving everything manually or taking the riskier approach with dangerously skip remission.

So we were still very much in the loop as humans.

But as these models got better at taking on bigger tasks, our sessions also changed.

So nowadays, at least at Anthropic, our sessions look more like this.

So we're running dozens of sessions at the same time, running for hours, verifying their own results along the way,

and we even have sessions orchestrate other sessions.

So whereas we used to be in the loop for almost every step

and running one or just a couple sessions at a time, we've now essentially become managers for dozens of sessions.

We also get a lot more done, though.

Now, you may have seen our blog post in October about

how Enthropic went from about 2 ,500 changes a day in May to more than 30 ,000 a day in September.

But this also means that we as developers just have to rethink on what we're focused on instead.

So if you think about our best practices from earlier this year, it was mainly about steering sessions,

approving commands, saying no to certain things or restricting what

Cloud could do, checking the output and also starting the sessions.

So everywhere that we now step out of that loop, something else has to take over.

And this is either the model, the harness, or the environment that it's running in.

So if we are not in a loop to approve every command and we're running so many sessions at the same time,

how can we make sure that the code it's writing is still high quality?

And most importantly, if these sessions are running for hours without our supervision, how can we make sure that they're running safely?

So let's go through that by taking this old session

and seeing what we have to change to get to that end result that I showed earlier.

Well, first of all, let's use the actual defaults we start sessions in nowadays.

So that's not really something you should think about.

So let's update the model here from Opus 4 .5 to Opus 5 .5 and change the manual permission to auto mode.

And Opus 5 .5 is a lot better at understanding your intent and understanding your code base.

So we really don't have to steer it as much anymore mid -session.

And you also no longer have to approve every command

because we started making auto mode the default permission mode back in August.

Now being better at understanding your intent and your code base also means

that we have to rethink the instructions we have in our code base.

So if you followed our best practices from earlier this year you may still have things like important

or never do this exclamation mark all these things in your cloud MD file

but with today's models you really don't need that

and it can actually make the model go off track

so you end up with more tool calls and overall a worse results

so nowadays your cloud md file should only include the things

that cloud cannot see from your code

so for example maybe you have a service that's still using some legacy source somewhere

but it's not directly referenced in the code that's still good to keep in there

but everything else like what stack you're on

or where to look you really don't need that anymore

and we actually have a command for this called dr prompt audit

which makes it really easy to optimize your environment for a specific model.

So if you're on Opus 5 .5 here and you run this command,

it will automatically check your CloudMD and your skills to see what the new model no longer needs.

Now auto mode is a permission mode

that runs a separate classifier on pretty much everything that isn't just reading or editing files in your project.

So it automatically allows commands that it knows are safe, like running tests or installing dependencies, but still blocks commands where it's unsure whether they're safe

and normally that's pretty good normally that's kind of you know what we want

but for example here

if we ask it to ship something to staging

we would have just you know approved the push to our deploy repo

but by default auto mode only trusts this folder and this repo

so it would block that command

so we're back in the loop now the defaults should be good in most cases

but if you still notice that you have to approve a lot of commands, even in auto mode.

The first thing to look at is settings here because you can configure auto mode in your own settings, just in plain English.

And this is what gets sent to the classifier, which then decides whether to reject or allow certain commands.

So here we can just write which repos, buckets, domains we trust and what it should always allow or never do.

Okay, so honestly, this was pretty easy by just using today's defaults, we've already gotten rid of most of our in the loop stuff

because the model took over the steering

and auto mode took over all the approving so getting out of the loop is easy.

But the harder question now is how do we make sure it's okay that we're not there anymore?

So first is keeping it safe, and then also verification.

So let's start with keeping it safe, because everything so far, so upgrading the model and using auto mode, it's just working with a model.

And in most cases, it does what you tell it to do, but that's not a guarantee.

So in a study we published back in August, we tested auto mode versus real people in the loop,

and only about 14 % of people caught a clearly dangerous command.

AutoMode blocked 89 % of them, so it is a lot better at it than we were.

But about 1 in 10 of those commands still went through.

So if you do want the guarantee, you can only enforce that in the harness.

And this is where some of our older best practices still matters, and that's permission.

So, for example, if you have a deny rule for a specific tool call in your project,

clot code looks at this rule before the automo classifier even looks at it in fact

if a tool call matches a deny rule the classifier never even sees it

so having deny rules is still the best way to make sure clot actually never does something

but then how do you know what needs to be a

rule in your project versus what the model can just know

because they've gotten so good at it i think it kind of just comes down to

if clot gets this wrong once can i take it back so if it writes the wrong code, you can still revert that.

100

So you can still leave that to the model.

101

But if it throws away our uncommitted changes

102

or it reads a key that's now in your transcript and you don't want that, that should still be a rule.

103

So for example, let's say that we just never want Claude reading our .end file.

104

Now by default, Automode is fine with this.

105

So it would have just approved it.

106

So if you want to make sure that Claude can never read this file, you should just add a deny rule

107

and then commands like cat cannot open this file either

108

but it's not always that straightforward because sometimes certain commands can have side effects

109

so for example let's say

110

that npm test here a very normal command it's just a test

111

so automote runs it that's fine but

112

when the script is running it runs code

113

that you didn't write like your dependencies

114

or maybe clod runs a script real quick

115

that it wrote just to quickly check something so

116

if one of those scripts is compromised it could just open

117

that same end file or your ssh keys

118

and send those to a server you've never heard of right

119

and even if we were still there as humans approving everything honestly we would have just clicked allow

120

because there's nothing to say no to it's just part of the script

121

that in this example case npm test runs and permissions only decide

122

if a tool call runs but they cannot limit what it can reach once it's running

123

so we want to make sure that these kinds of scripts can still run

124

because this is just part of you know how cloud can check its own work running tests

125

so we cannot just block npm tests

126

but we want to limit its side effects

127

so really we just want to limit the environment

128

that it's running in so if you're running it locally

129

or on your own machine you can run commands like

130

that in a sandbox so then you have control over

131

which files in a command it can read

132

which folders it can write to which hosts it can reach

133

and the operating system enforces that also this also applies to everything that command then starts so any child processes

134

so on its own that deny rule got checked by claude before the command runs

135

but all it sees there is npm test so it doesn't see

136

which files that scripts ends up opening but with the sandbox on

137

that same rule gets passed on to the operating system

138

so now when when

139

that dependency tries to open our end file the operating system just doesn't let it

140

and by default it can still read most of your machine

141

so you'd want to add another rule for your ssh keys

142

if you care about that um and it also cannot reach a host

143

that wasn't approved but the sandbox only covers the shell commands

144

that cloud runs and whatever those start but claude's own files your mcp servers

145

and all of your hooks still run outside of it

146

so the rest of your session still runs on your own machine

147

and everything that's on there

148

so ideally you want this whole thing to run somewhere where none of

149

that is even there in the first place and

150

that is a cloud session

151

because there it gets its own machine with a fresh copy of a repo

152

and this runs even when we close our laptop

153

which is definitely something you want for these longer running sessions

154

that run for hours so in this case this automatically gets rid of the end file issue

155

because it's not in git and neither are my ssh keys

156

or our github token and if it still needs an api key uh you can add

157

that as a network secret where it will it will tell you like hey

158

i'm missing an api key mid -session um

159

so it can use it without actually ever sending it to the model

160

and by default also in a cloud session network access is limited to things like package registries and github

161

so you have to explicitly add those domains to your environment for claw to to reach other hosts okay

162

so with a cloud session we can run these long running sessions even with our laptop closed

163

and it keeps us safe

164

because it runs in its own environment now it's still good to remember

165

that this machine is disposable but the things that leave it aren't

166

so a commit that pushed or a message it sent through a connector

167

so we still run it in auto mode with our deny rules just commit it into the repo

168

so they come along so it could still catch things like a force push

169

or a secret and a commit all that kind of stuff

170

and beyond just safety we also need to make sure

171

that Claude is actually working on the right thing

172

so next is verification

173

and the nice thing about being in a loop uh like we kind of knew the work was good

174

because we'd already kind of seen every change we'd proved everything

175

but now if claude works for hours in the background we don't have

176

that anymore and we're not really going to read every file at the end either

177

so you know say

178

that we ask it to move our auth to a new

179

api well claude is very good at understanding what we want

180

but there are still a lot of small decisions

181

that it has to make along the way

182

so with the exact same problems you know one run might move it over

183

but leave the old api in there or one might move it

184

but only for new logins and another one might move it

185

but log everyone out and these all look pretty reasonable

186

but it really helps to set up these verification points along the way

187

so claude keeps verifying its own results and those can be anything

188

that comes back as a pass or fail

189

so tests a build a screenshot whatever you have

190

so now we just want to make sure that we review these verification points.

191

They're a lot shorter to review than if we just had to, you know, review the whole change at the end.

192

So that's pretty reasonable.

193

So if one of these runs would still log everyone out, it doesn't get past that first check,

194

and then it just has to find another way.

195

And there's a couple ways to set this up.

196

The easiest one is, of course, just in your prompt.

197

So, you know, you say what done looks like

198

and ask it to split that into tasks so they have their own tests.

199

And I also like to ask it to show the actual output

200

because you weren't there to see it but again prompting is not a guarantee

201

that a model will do it so for the ones

202

that have to run guaranteed run i would use hooks

203

which are just you know scripts that cloud code runs at a specific point

204

and those give you a lot of control because you decide

205

when they run and what they run and what they check

206

so for example every time it edits a file

207

we can run our linter every time

208

it wants to mark a task as complete we can run the tests for what it changed um

209

so you know if it touch our off code or something.

210

It has to pass the off tests.

211

And when it wants to finish the whole session, we can just run the entire test suite.

212

And if one of those fails, it goes, oh, that's still broken.

213

It goes back until it passes.

214

So it fixes it.

215

Now, just one thing, when a test fails, by default, most tools that exit with a one exit code.

216

But with a one, that task by Cloud Code just gets marked as completed anyway.

217

So make sure that your scripts exit with a two exit code

218

because that's what actually sends cloud back to fix it

219

so okay now we have one session that i'm pretty comfortable with leaving alone

220

so now we can start with a few more of those

221

because they've all got their own machine

222

so they're you know not all working in the same folder

223

and we don't really have to think about work trees too much ourselves anymore

224

but then we still start every session ourselves

225

and we review every one of them

226

and honestly this is already a pretty good place to be

227

we are still fully in control over what gets started and

228

when we call a task done

229

but even there um you know we're still the ones kicking off every session

230

and we're still in the loop for all of them

231

so i think the most important thing to have in place here now is your ci

232

because all of these sessions eventually open a pr

233

and your ci runs the same checks on every one of them no matter how

234

that session was set up or you know what claude decided to do along the way.

235

And if you turn on autofix, we have like CI autofix,

236

Cloud can also see when one of those checks fails and then go back to fix it.

237

So you're not the one spending your review on things that, you know, a check could have already caught.

238

And for some of them, you can even turn on merge when ready.

239

So then GitHub merges the PR once all of the checks have passed.

240

So you're not in the loop to review.

241

But again, that's not the default.

242

And that really depends on how risky the changes

243

so for example on our team every pr gets reviewed by cloud first

244

so not by the session that wrote it

245

so it comes with a fresh context

246

and also a separate group of agents to just double check every bug it finds

247

and then how much we review ourselves just depends on the risk

248

so smaller changes like docs or copy they don't need a person so once the automated checks are green

249

we're pretty good to go.

250

Maybe ordinary product changes just need one reviewer, and then risky changes might need two.

251

Now, ultimately, kind of where we see things going, and we're already kind of doing more of that adnthropic,

252

is that you're not really starting all of those sessions yourself either.

253

Because if you're anything like me, I'm terrible at context switching, so having to manage so many sessions at the same time doesn't always go well.

254

So instead, you just have one main session that's your orchestrator

255

and you can already see this in things like cloud code projects

256

which is still in beta but you just tell it what it needs to be done

257

and the orchestrator splits it up and then starts other sessions for each task

258

and it keeps track of what comes back so it automatically starts

259

and verifies these threads which are just new sessions

260

so instead of talking to eight sessions you're just talking to one

261

and the main session doesn't write the code itself

262

so there you want a model that's really good at deciding what to do

263

and judging what comes back a model like fable and

264

if something comes back that isn't actually done it just you know sends it back

265

so until it's actually done and passes everything

266

and the threads need a model that's good at actually doing the work like opus 55

267

and you can set those separately so you know one model for the main session

268

and then another one for the threads and another benefit is

269

that with this setup with cloud code projects specifically we don't manage context anymore that's all done automatically for us

270

so we no longer have to think about you know

271

when to compact or clear all of that stuff okay so

272

if you look back at those old best practices they're all still there but they've just moved

273

so the model sears it now um auto mode approves your deny rules

274

and the environment restrict what's possible your test your hooks

275

and your ci check set and then ultimately cloud can just start them as well

276

so almost everything we used to do ourselves is now either the model the harness

277

or the environments and we're really just here to start

278

that first one and to just review what comes out so

279

if you want to try this in your own setup

280

i would say just take one thing

281

that's way bigger than you normally give claude make sure your ci actually catches the things you care about

282

and then spend a bit of time just configuring your environment like it's network access it's secret

283

and it's you know setup script and then start in the cloud

284

and see where your sessions get stuck and where you're still in the loop

285

because that's the next thing to hand over to claude

286

i also highly recommend checking out our best practices in the docs as well thank you so much

下載應用

流利口語所需的一切

AI 發音評分逐句打分

音標練習掌握每個音

詞彙學習建立你的詞庫

詞彙遊戲邊玩邊學

掃碼

Download on theApp Store Get it onGoogle Play

同頻道

Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar

Daily ConversationUniversity StudentsWorking Adults

The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory

Business EnglishUniversity StudentsWorking Adults

What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI

Daily ConversationUniversity StudentsWorking Adults

Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley

Business EnglishInterview EnglishUniversity Students

Why Software Factories Fail

Daily ConversationUniversity StudentsWorking Adults

How I deleted 95% of my agent skills and got better results — Nick Nisi, WorkOS

Business EnglishUniversity StudentsWorking Adults

Beyond Code Coverage: Functionality Testing with Playwright — Marlene Mhangami, Microsoft

Business EnglishUniversity StudentsWorking Adults

"Software Fundamentals Matter More Than Ever" — Matt Pocock

Business EnglishUniversity StudentsWorking Adults

Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic

Business EnglishUniversity StudentsWorking Adults

FOR YOU

本課的詞彙與口語要點

這節口語課以影片“Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic”為素材。影片中反覆出現的詞有：session, model, command, code, cloud。這段影片共有 286 個句子、3581 個單詞可供跟讀。講話部分時長為 17:31。說話人語速較快，每分鐘約 204 個詞，會出現較多連讀和弱讀。 86% 的單詞屬於英語最常用的 3,000 詞，其餘的詞建議在練習前先學一下。

影片中的重點詞彙

影片中 15 個值得學習的單詞，附發音和釋義：

單詞	發音	釋義
cloud 名詞	/ˈklaʊ̯d/	йүн, 雲 /雲
loop 名詞	/luːp/	圈, 環 /環
approve 動詞	/əˈpɹuːv/	批准, 贊成 /贊成
default 名詞	/dɪˈfɔlt/	違約 /違約, 暴雷
script 名詞	/skɹɪpt/	文章
deny 動詞	/dəˈnaɪ/	否認 /否認, 否定
guarantee 名詞	/ˌɡæɹ.ənˈtiː/	保證 /保證
exit 名詞	/ˈɛɡzət/	離開 /離開, 退場 /退場
verify 動詞	/ˈvɛɹɪfaɪ/	校驗 /校驗, 驗證 /驗證
thread 名詞	/ˈθɹɛd/	線 /線
output 名詞	/ˈaʊtpʊt/	輸出 /輸出
hook 名詞	/hʊk/	鉤 /鉤, 鉤子 /鉤子
nowadays 副詞	/ˈnaʊ.ə.deɪz/	現在 /現在, 現今 /現今
setup 名詞	/ˈsɛtʌp/	陷害
folder 名詞	/ˈfoʊldɚ/	卷宗, 資料夾 /資料夾

影片中出現的短語動詞

單詞	發音	釋義
come back 動詞		回來 /回來, 返回
take over 動詞		接管, 接手
go through 動詞		通過 /通過
check out 動詞		退房
come along 動詞		陪伴, 陪同
come out 動詞	/ˌkʌm ˈaʊt/	出, 出來 /出來
end up 動詞		到達
go back 動詞		回去, 返回

影片中的語法

說話人最常用的結構，並附上影片中的原話：

結構	影片中的用法
“used to” used to + 動詞 — 過去的習慣或狀態，現在已不再如此	used to look · used to be · used to do
現在完成時 have/has + 過去分詞 — 過去發生但與現在仍有關聯的事	have gotten · we've now essentially become · we've already gotten
被動語態 be + 過去分詞 — 強調發生了什麼，而不是誰做的	is compromised · wasn't approved · was set

需要注意的發音

說話人用了 63 次縮略和弱讀形式，例如 we're, don't, you're。請按聽到的簡短形式來說。

“th” 音: thread /ˈθɹɛd/, rethink /ɹiːˈθɪŋk/, auth /ɔːθ/
“sh” 和 “zh” 音: verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, essentially /ɪˈsɛnʃəli/, shell /ʃɛl/, instruction /ɪnˈstɹʌkʃən/, supervision /ˌs(j)uːpəˈvɪʒən/
長單詞——注意重音位置: verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, dependency /dɪˈpɛndənsi/, essentially /ɪˈsɛnʃəli/, ordinary /ˈɔɹdɪnɛɹi/, difficulty /ˈdɪfɪkəlti/

中文母語者容易讀錯的音：

/v/ — 不要讀成 /w/，上齒輕觸下唇: approve /əˈpɹuːv/, verify /ˈvɛɹɪfaɪ/, verification /ˌvɛ.ɹə.fɪˈkeɪ.ʃən/, server /ˈsɝvɚ/, versus /ˈvɝsəs/
詞尾子音 — 要讀清楚，後面不要加母音: cloud /ˈklaʊ̯d/, loop /luːp/, approve /əˈpɹuːv/, default /dɪˈfɔlt/, script /skɹɪpt/
/r/ 和 /l/ 的區別: importantly /ɪmˈpɔɹ.tənt.li/, separately /ˈsɛp.ɹət.li/

如何用這段影片練習

先完整聽一遍影片，不要開口，記下不認識的單詞。
先用 0.75 倍速逐句跟讀，熟練之後再回到正常速度。
錄下自己的聲音並與原聲對比，特別注意 cloud, loop, approve 這類單詞。

什麼是跟讀法？

跟讀法 (Shadowing) 是一種有科學依據的語言學習技巧，最初開發用於專業口譯員的培訓，並由多語言者Alexander Arguelles博士普及。這個方法簡單而強大：您在聽英語母語原聲的同時立即大聲重複——就像是一個延遲1-2秒緊跟說話者的影子。與被動聽力或語法練習不同，跟讀法強迫您的大腦和口腔肌肉同時處理並模模擬實的講話模式。研究表明它能顯著提高發音準確性，語調，節奏，連讀，聽力理解和口語流利度——使其成為雅思口語備考和真實英語交流最有效的方法之一。

影子跟讀法: 閱讀完整分步指南 →

跟讀練習: Rethinking Claude Code Best Practices — Lydia Hallie, Anthropic - 通過影片學習英語口語

選擇練習模式

下載應用

同頻道

Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar

The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory

What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI

Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley

Why Software Factories Fail

How I deleted 95% of my agent skills and got better results — Nick Nisi, WorkOS

Beyond Code Coverage: Functionality Testing with Playwright — Marlene Mhangami, Microsoft

"Software Fundamentals Matter More Than Ever" — Matt Pocock

Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic

推薦影片

How Anthropic uses Claude in Product Management

Armchair Architects: Resiliency in the Cloud – Core Patterns

Did Anthropic Kill Git?

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

Claude Code Is Wasting Tokens... Microsoft Built a Fix

Sec Growth DataScience staff meeting Sep 14 2022

I Looked Into How Devs Are Actually Using AI

What's New in Zephyr 4.5?

9 Insane Claude Mods I Already Can't live Without

We've got separation of concerns wrong

The last real programmers are dying out...

本課的詞彙與口語要點

影片中的重點詞彙

影片中出現的短語動詞

影片中的語法

需要注意的發音

如何用這段影片練習

什麼是跟讀法？