# Claude Codes New INTENT.MD, What is It? · 中英对照逐字稿

- 原节目：Rob Shocks
- 英文原始来源：https://www.youtube.com/watch?v=LoMOPj-lO8U
- 中文译制版入口：https://www.bilibili.com/video/BV16MtE6oEUP
- 时长：00:16:21
- 方法与限制：英文来自已验证的原始节目 transcript/caption；中文由 Codex 逐段翻译，未做逐字人工校对，公开引用前请回到英文原文与音频复核。

## 中英对照逐字稿

### [00:00:00–00:00:28]

**EN**  So, this is Boris Journey, and he's the creator of our friend Claude Code, and these guys have just released their AI native SDLC playbook. So, if this is a new concept to you, SDLC is the software development life cycle. Typically, in a human workflow, it looks something like this. You plan, you design, you build it, you test it, you deploy it, and put it into production, depending on what type of an app it is, and then you need to look at maintenance. And then you go right back to the start for the next

**中文**  这是 Boris Cherny，他是我们熟悉的 Claude Code 的创造者；他们刚刚发布了 AI-native SDLC playbook。如果你对这个概念还不熟，SDLC 就是软件开发生命周期。在典型的人类工作流里，它大致是这样：你规划、设计、构建、测试、部署，并按应用类型把它放进生产环境，然后还要做维护。接着你再回到起点，处理下一个

### [00:00:26–00:00:55]

**EN**  feature, bug, or release. So, this new document from Anthropic is all about how the team there, including Boris, work in terms of their new AI native software development life cycle. So, let's give it a rapid breakdown. So, the big idea here is code is no longer the bottleneck, it's your process. So, before agents came along, this is pretty much how an SDLC looked. We had the planning stage, design, build, test, deploy, and maintain. The part that took the longest and was typically the most

**中文**  功能、缺陷或发布。Anthropic 这份新文档讲的是他们团队——包括 Boris——如何按新的 AI-native 软件开发生命周期工作。我们来做一次快速拆解。核心想法是：代码已经不再是瓶颈，瓶颈是你的流程。在 agent 出现之前，SDLC 差不多就是这样：规划、设计、构建、测试、部署、维护。其中耗时最长、通常也最

### [00:00:52–00:01:21]

**EN**  expensive was the build stage. But, that all changed with agents. This part here has been squashed down to this part here. Look at all this time here we've reclaimed. So, essentially, what Anthropic are saying we've done great to shrink this, we're two times faster, but how do we improve all these other steps with agents as well? So, traditionally, in our planning stage, we would sit down, gather requirements, create PRDs, have workshops, talk to stakeholders, pulling it all together. In this new

**中文**  昂贵的是构建阶段。但 agent 改变了这一点。原来的构建阶段被压成了现在这么短的一段。你看，我们收回了这么多时间。所以 Anthropic 实际上是在说：我们把这一段压缩得很成功，已经快了两倍，但怎样用 agent 把其余步骤也一起改进？传统上，规划阶段我们会坐下来收集需求、写 PRD、开工作坊、和利益相关者谈话，再把材料拼在一起。而在这个新

### [00:01:20–00:01:50]

**EN**  world, we start by getting the agents to interview us about the feature, the bug, or the product that we're building in order to build up context. I use my own discovery skill called switch dimension discovery, you could use Realm me from Matt Pocock, or you could use something like requirements discovery from Cursor. So, what you want to do is make sure the agent asks you repeated questions until it has a complete understanding of the feature you're building or the bug you're trying to solve. You're dumping as much of your experience, domain experience, and context into this

**中文**  世界里，我们先让 agent 就我们正在做的功能、缺陷或产品来采访我们，以便积累上下文。我用的是自己的 discovery skill，叫 Switch Dimension discovery；你也可以用 Matt Pocock 的 Realm me，或 Cursor 里类似 requirements discovery 的东西。关键是让 agent 反复提问，直到它完整理解你要做的功能或要修的缺陷。你要把自己的经验、领域经验和上下文尽量倒进这次

### [00:01:47–00:02:16]

**EN**  conversation. So, the agent synthesizes pain points straight from the sources, and then captures them in this intent.md file, which is human-readable and machine-actionable. So, Anthropic is formalizing this idea around an intent.md file. So, in the traditional SDLC, the idea passed to a backlog of user entries, user stories, story points, ownership transfers, handoff. What we're talking about in the AI-native world is the originator of the

**中文**  对话里。于是 agent 直接从这些来源里综合痛点，再把它们写进 intent.md 文件；这份文件既是人能读的，也是机器可执行的。所以 Anthropic 正在把 intent.md 这个想法正式化。在传统 SDLC 里，想法会进入 backlog、用户故事、story points，所有权会转移、会交接。而在 AI-native 世界里，我们说的是：意图的 originator

### [00:02:14–00:02:42]

**EN**  issue, the feature, the product, whatever, brainstorms with Claude and writes the result down as the intent.md. So, for each one of these steps as we move through, we're going to be developing what's called an artifact chain. First, we start with an intent.md file, then we're going to have a spec, etc., as we go through the steps. That's building the artifact chain. So, in your project using Cursor, Claude, Code, Codex, whatever you want, you're just creating a folder called intent, and within that, that's where you're going

**中文**  ——无论是问题、功能还是产品——和 Claude 一起头脑风暴，再把结果写成 intent.md。我们往下走的每一步，都会形成所谓的 artifact chain。先从 intent.md 开始，然后会有 spec，再往后还有别的文件。这就是在建立 artifact chain。在你的项目里，不管你用 Cursor、Claude Code、Codex 还是别的工具，你只要建一个叫 intent 的文件夹，然后把

### [00:02:40–00:03:08]

**EN**  to save your intent.md file. So, in my planning stage here, I might have a chat with my agent about adding dark mode as a feature, and I talk about what I want, how I want it to operate, and then we go and create an intent.md file from that. Then, I get the agent to save that as the intent.md file in the intent folder as proposed by Anthropic. And of course, with any of these artifacts, your team can do whatever they want in terms of a workflow. I think what's important here

**中文**  intent.md 保存在里面。所以在我的规划阶段，我可能会和 agent 聊给产品加 dark mode：我想要什么、希望它怎么工作，然后据此生成一份 intent.md。接着我让 agent 按 Anthropic 的建议，把文件存进 intent 文件夹。当然，这些 artifact 在团队工作流里可以按你们自己的方式处理。我认为重要的是

### [00:03:06–00:03:35]

**EN**  is that you start to standardize it and not chop and change it too often. That way, the team, the agents, the skills, all work on the same workflow, and you can grow from there. Now, once that intent.md file is created, it doesn't stop there. It's It's suggested that the originator of the intent goes back over what the agent has written to correct anything and make sure that both of them are happy. Now, the person that creates this intent.md file is called the originator, and that doesn't have to be a specialist on the team. That can be

**中文**  你开始把它标准化，并且不要改得太勤。这样团队、agent、skill 都在同一套工作流上工作，才能继续往上长。intent.md 写完并不是结束。建议是：意图的 originator 再回头核对 agent 写的内容，纠正任何误解，确保双方都认可。创建这份 intent.md 的人叫 originator，这个人不一定是团队里的专家。可以是

### [00:03:33–00:04:02]

**EN**  anybody who wants to create the intent. It could be a customer who's putting in a bug request. It could be a product manager who has an idea for a feature. It could be a developer who wants to capture a process improvement. So, you might have your own intent capture skill that produces something similar to this. What you might do over time as you're collecting more forms of intent, you might prefix the name of the intent before your intent.md file. This is something I've been doing myself and

**中文**  任何想创建意图的人。可以是提交缺陷请求的客户，可以是有功能想法的产品经理，也可以是想记录一次流程改进的开发者。所以你可能有自己的 intent capture skill，产出类似这样的文件。随着你收集到更多形式的意图，你可能会在 intent.md 前面加上意图名称作为前缀。这是我自己一直在做、也在

### [00:04:00–00:04:29]

**EN**  teach on my course. I call it discovery, not intent, but again, it's the same idea. So, the intent really can be captured by anyone. Could be a developer, uh a customer submitting a bug. They're basically just dropping their thoughts into this intent.md file. But then it is the product owner that should review these in the form of a backlog. These could simply be ordered files in a markdown file. All these ideas could be captured in Notion or Linear and then organized by either a product owner or in some cases I'll

**中文**  课程里教的做法。我把它叫 discovery，不叫 intent，但想法是一样的。所以意图其实可以由任何人捕获。可以是开发者，也可以是提交缺陷的客户。他们基本上只是把自己的想法写进这份 intent.md。但随后应当由 product owner 以 backlog 的形式来审这些内容。它们可以只是 markdown 里按顺序排好的文件。这些想法也可以进 Notion 或 Linear，再由 product owner 来组织；有时我也会

### [00:04:26–00:04:53]

**EN**  actually use my agents to triage the backlog of issues. You can see they can assign tags like front-end, smaller large tasks, whether it's a feature, and even the priority level. So then we're moving from the intent artifact to the spec artifact. Anthropic is suggesting that once the intent is committed or signed off in some way that you create a hook or a process that the spec is automatically generate. So, Anthropic

**中文**  直接用 agent 给问题 backlog 做分流。你可以看到它们会打上标签，比如前端、任务大小、是不是功能，以及优先级。然后我们从 intent artifact 走到 spec artifact。Anthropic 的建议是：一旦 intent 被提交或以某种方式签字确认，你就建一个 hook 或流程，让 spec 自动生成。所以 Anthropic

### [00:04:50–00:05:19]

**EN**  gives us a sample prompt we might use to take our intent and turn it into a spec. They're not giving us specific skills here, but we could certainly create a skill around this. So, essentially, read the attached intent.md and produce a requirements and design spec. Apply skills available to you to plan and conform to brand guidelines and then document the spec fully in spec.md. Depending on your workflow, your organization, you could just use the vanilla plan mode within Cursor or

**中文**  给了一个示例 prompt，用来把 intent 转成 spec。他们并没有在这里给出具体 skill，但我们完全可以围绕这个做成 skill。本质上就是：阅读附上的 intent.md，产出一份 requirements and design spec；应用你可用的 skill，让计划符合品牌规范，再把 spec 完整写成 spec.md。按你的工作流和组织，你可以直接用 Cursor、

### [00:05:16–00:05:45]

**EN**  Claude Code or Codex or you could just go and create a skill that creates bespoke specs specific to how your team likes to work. There really isn't a one-size-fits-all here. Now, when that spec is created, it could just be through a vanilla agent or you might also have a set of guidelines or policies or even skills that make sure that style guides are applied and however the spec is generated is based on the best practices of your

**中文**  Claude Code 或 Codex 里的原版 plan mode，也可以做一个 skill，专门生成符合你们团队习惯的 spec。这里真的没有一刀切。spec 生成之后，它可能只是普通 agent 写出来的；你也可以有一套指南、政策，甚至 skill，确保 style guide 被应用，并且 spec 的生成方式符合你们

### [00:05:44–00:06:13]

**EN**  organization. This might be in an agents.md file. It could be encoded into a set of skills. You want to make sure that those skills and policies are adhered to in your governance considerations for when the spec is being generated. And that applies to all of the artifacts in this chain. A quick diversion to talk about our sponsor, Neon. If you're using agents heavily in your SDLC, I highly recommend you check them out. I've been using Neon for years for all my database needs. I've talked

**中文**  组织的最佳实践。这可能写在 agents.md 里，也可能编码进一组 skill。你要确保这些 skill 和政策，在 spec 生成时作为治理约束被遵守。而这适用于这条链上的所有 artifact。这里稍微岔开，讲一下赞助商 Neon。如果你在 SDLC 里大量使用 agent，我非常建议你看看他们。我用 Neon 做数据库已经很多年了。我讲过

### [00:06:10–00:06:39]

**EN**  loads about how Neon is ideal for agent workflows with their awesome branching feature. What I love about Neon is they're totally agent first. So, in all my agents, here's an example of Cursor. I've got their MCP and the CLI and their set of skills plugged in. So, I never even have to touch the dashboard. The agent knows what to do with all their services. If you haven't checked in on Neon lately, it's now a full-fledged platform. It has managed better auth

**中文**  很多次 Neon 为什么适合 agent 工作流，尤其是他们的 branching 功能。我喜欢 Neon 的地方在于它完全是 agent first。所以在我所有的 agent 里——以 Cursor 为例——我接好了他们的 MCP、CLI 和那套 skill。我甚至不用碰 dashboard。agent 知道该怎么用他们的服务。如果你最近没看过 Neon，它现在已经是一个完整平台。它内置了托管的 Better Auth，

### [00:06:37–00:07:05]

**EN**  included, which links to your database. You've also got long-running functions with no timeouts, S3 compatible object storage for all your files in your projects. If you're building projects and working with agents, I highly recommend Neon for an easy life. Channel subscribers can check them out via the link in the description down below. So, let's get back to the SDLC. So, next up, we're moving into build mode. So, it starts essentially by the engineer involved in the process pulling in the

**中文**  并且和你的数据库连在一起。你还有无超时的长时运行函数，以及项目文件用的 S3 兼容对象存储。如果你在做项目、并且和 agent 一起工作，我非常建议用 Neon，会轻松很多。频道订阅者可以通过简介里的链接去看。好，我们回到 SDLC。接下来进入构建模式。这一步本质上是：参与流程的工程师把

### [00:07:03–00:07:32]

**EN**  intent and the spec and feeding it into Cloud Code either in or in Cursor in plan mode or something like that. Basically, feeding the intent and the spec. So, what we get then is a plan.md file. So, what Anthropic are suggesting is you interrogate the plan by asking what changes could break. Essentially, you want to get to a point where if you were just to hand over this plan.md file to an engineer, they could go and implement the changes without reference

**中文**  intent 和 spec 拉进来，喂给 Claude Code，或者在 Cursor 里用 plan mode，诸如此类。基本上就是把 intent 和 spec 喂进去。然后我们得到一份 plan.md。Anthropic 的建议是：你要质询这份计划，问它哪些改动可能弄坏现有系统。本质上，你要达到这样一个点：如果只把这份 plan.md 交给一位工程师，他不需要再去参考

### [00:07:29–00:07:57]

**EN**  to the intent or spec documents. Now, that's actually an important point because we're not going to have one agent carry out all of these different stages in the software development life cycle. We're going to have a context window. We're going to have a thread of conversations. Independent agents, sub-agents are going to handle this process. So, in that world, and here's just an example from one of my own workflows, you've got multiple different agents working on the problem. You want to hand off your planning, your intent

**中文**  intent 或 spec 文档，就能实现这些改动。这一点其实很重要，因为我们不会让同一个 agent 跑完软件开发生命周期的所有阶段。我们会有一个 context window，会有一段对话线程。独立的 agent、sub-agent 会分别处理这个过程。所以在那个世界里——这里只是我自己工作流的一个例子——你会有多个不同的 agent 同时处理问题。你要把规划、intent

### [00:07:55–00:08:24]

**EN**  as documents to each one, so it can start from scratch without an understanding of the previous conversation that happened. So, when the engineer is happy, they go and proceed with the plan. You've probably seen 50 ways to write a plan, but essentially what Anthropic are saying is you break it down into the files that need to be changed, the order of work or type of to-do list, any kind of risks, constraints, and then proof. So, you want some kind of success criteria and checks inevitably to make

**中文**  作为文档交给每一个 agent，让它从零开始，而不需要理解之前发生过的对话。工程师满意之后，再按计划推进。写计划的方法你大概见过五十种，但 Anthropic 说的本质是：拆成需要改的文件、工作顺序或某种待办清单、各类风险与约束，然后是 proof。所以你需要某种成功标准和检查，最终用来

### [00:08:22–00:08:49]

**EN**  sure that the work was done correctly. This could come in a deterministic form of linting and tests. A big part of the process in an enterprise company is going to be governance. So, what Anthropic suggests is that you're saving versions of your plan, your intent, your spec.md, who touches them, and how they are evolved. Companies I've worked with find this part particularly hard, but it's But, it's really important if you want to track the leading and lag indicators for your projects and really

**中文**  确认工作确实做对了。这可以是确定性的 lint 和测试。对企业来说，流程里很大一块会是治理。所以 Anthropic 建议：你要保存 plan、intent、spec.md 的版本，谁动过它们，以及它们如何演化。我合作过的公司觉得这部分特别难，但它确实很重要，如果你想追踪项目的领先指标和滞后指标，并且真正

### [00:08:47–00:09:16]

**EN**  prove out your Dora metrics or see how effective AI actually is becoming in your workflows. So, in terms of making your build mode fast, Anthropic suggests you use auto mode. It really does depend though on your own organization. What I suggest is that when you've got a locked-down environment that you're working in, that you actually start to work in the repository with a set of dialed-in permissions, and that you're ex- secting them as you go. Once you've built up a policy of what's fair use,

**中文**  证明你的 DORA 指标，或看清 AI 在工作流里到底有多有效。说到让构建模式变快，Anthropic 建议使用 auto mode。不过这非常取决于你自己的组织。我的建议是：当你处在一个已经锁好的环境里，你实际上是在仓库里用一套调好的权限工作，并且一边做一边检查它们。一旦你建立起公平使用政策、

### [00:09:14–00:09:44]

**EN**  what tools the agents can access, what web sources, what packages they're pulling, and you lock that down in terms of cursor or cloud permissions, you're going to be able to have your agents move a lot faster without you involved. There are a lot of elements in making sure auto mode runs smoothly and you've got a tight blast radius for your agent. Not for the context of this video, but hopefully I'll cover more on that again. The team also suggests work trees, so you can have multiple agents work on multiple things at the same time. If that's completely over your head, I've

**中文**  agent 能用哪些工具、能访问哪些网页来源、能拉哪些包，并且把这些锁进 Cursor 或 Claude 的权限里，你的 agent 就能在你不介入的情况下快很多。要让 auto mode 跑得顺，并且把 agent 的 blast radius 收紧，里面还有很多要素。这期视频不展开，希望以后再讲。团队也建议用 worktree，这样多个 agent 可以同时做多件事。如果这对你完全陌生，我

### [00:09:42–00:10:10]

**EN**  got a full video on my channel covering Git and Git worktrees if you're just getting used to them when it comes to working with agents. So, a big part of keeping this process autonomous, keeping things updated, and keeping things on rail are the usage of hooks. So, as an example, in the build phase, we might update the plan once the implementation is complete. We might block the agent from working on certain folders or prevent it from operating an NPM package that we haven't signed off on yet. Linting has been around for a

**中文**  频道里有一期完整视频讲 Git 和 Git worktree，适合你刚开始和 agent 一起用这些东西。让这个过程保持自主、保持更新、保持不脱轨，很大一块靠的是 hooks。举例来说，在构建阶段，我们可能在实现完成后更新 plan；我们可能阻止 agent 改某些文件夹，或阻止它操作尚未签字批准的 npm 包。Linting 已经存在

### [00:10:09–00:10:38]

**EN**  long time. It's essentially a deterministic or a coded way of running through our code or our documents and checking that certain criteria are there or not there. Or that we're matching a particular syntax. It's going to run through the files, the tests will pass or not. It's going to be a binary yes or no. Something you'll get in a good agent harness is the ability to run subagents. So, once the plan is in place, this is actually baked into Cursor Cloud Code Codex. It divides the plan into various different tasks that can be done independently. And if some are in

**中文**  很久了。它本质上是一种确定性的、写成代码的方式，用来扫过我们的代码或文档，检查某些条件在不在，或者我们是否符合某种语法。它会扫文件，测试会通过或不通过。结果是二元的：是或否。一套好的 agent harness 还会让你跑 sub-agent。所以计划一旦就绪——这其实已经内建在 Cursor、Claude Code、Codex 里——它会把计划拆成可以独立完成的不同任务。如果有些任务可以

### [00:10:36–00:11:06]

**EN**  parallel, it can use worktrees. So, we end up having multiple agents and subagents working on the build step. So, after we're finished building, we move into the test phase. In the traditional software development life cycle, this can be a step that really holds things up. I might have finished a piece of work, pushed it into development, and then I have to wait a couple of days for a tester to come along or a QA. Then there's some changes, feedback, etc. The whole cycle takes quite a lot of time. In the AI software development life cycle, we want the agent to do as much

**中文**  并行，它就可以用 worktree。于是我们会有多个 agent 和 sub-agent 一起做构建。构建结束后，我们进入测试阶段。在传统软件开发生命周期里，这一步经常把事情卡住。我可能已经做完一块工作、推进到开发环境，然后还要等几天，才有测试人员或 QA 过来。接着是修改、反馈，诸如此类。整个循环会花很多时间。在 AI 软件开发生命周期里，我们希望 agent 在人类工程师或 QA 靠近之前，尽量多做

### [00:11:04–00:11:34]

**EN**  testing as possible before a human engineer or QA gets near it. Now, sorry if this diagram diverges a little bit from Anthropic we're talking about, but this is the workflow I've been teaching on my course at Switch Dimension, which is really similar. So, essentially, once we finish the build step here, we move into testing, linting, end-to-end review. The agent write tests to make sure nothing is breaking when developed and make sure those tests pass. It's going to lint and build the project to make sure there's no errors. And if you're advanced enough and you're using

**中文**  测试。抱歉，如果这张图和我们正在讲的 Anthropic 方案略有偏差；但这是我在 Switch Dimension 课程里教的工作流，其实非常接近。本质上，构建步骤结束后，我们进入测试、lint、端到端审查。agent 会写测试，确保开发时没有东西被弄坏，并让这些测试通过。它会 lint 并构建项目，确保没有错误。如果你足够进阶，并且在用

### [00:11:32–00:12:01]

**EN**  something like Playwright, Test-Driven Development, Cursor Browser, you can actually get the agent to test the software and take screenshots. This is actually something that Cursor Cloud agents do really well. They'll actually spin up a server and test the software for you and give you a screen recording. So, theoretically, once the testing is complete and it's fairly rigorous, it's going to save you a whole lot of time when it comes to the human review stage. Anthropic also suggests that you apply evals to any skill change or any model

**中文**  Playwright、测试驱动开发、Cursor Browser 这类工具，你甚至可以让 agent 去测软件并截图。这其实是 Cursor Cloud agent 很擅长的事：它们会拉起一个服务器，替你测软件，再给你一段屏幕录像。所以从理论上说，测试一旦完成而且足够严格，就会在人类审查阶段给你省下大量时间。Anthropic 还建议：任何 skill 变更或任何模型

### [00:11:59–00:12:28]

**EN**  upgrade. Now, this really is optimizing, but the idea is that you have continuous evaluations in your continuous integration. So, basically, you might collect collect 20 or so issues or things that you might have solved in the code base. You have a set of expected outcomes for those, and whenever you have a new model, a new scale, or a new fundamental change to how you do your work, you can run this to see if your software development life cycle regresses or not. So, now we're getting to the deploy stage. Essentially, we've done our human review. We're going to

**中文**  升级，都要跑 evals。这已经是在做优化了，但想法是：在持续集成里做持续评估。所以你可能收集大约 20 个曾经在代码库里解决过的问题或事项，为它们准备一组期望结果；每当你换新模型、新 skill，或对工作方式做了根本性改动，你就可以跑这套评估，看软件开发生命周期有没有回退。现在我们进入部署阶段。本质上，人类审查已经做完。接下来我们会

### [00:12:26–00:12:55]

**EN**  get the agent to merge or we're going to get it to create a pull request to the main repository based on whatever changes it made. So, essentially, we have a development branch, we have a production branch, and our agent is after making some changes on its own branch or in a work tree. So, it's made something called a pull request where it's saying, "Hey, I made some changes. I want you to take a look at them, and if you're happy, you can go and add them into the main code base." So, Anthropic is suggesting as part of your continuous integration or whenever a pull request is made that you get Claude to jump in

**中文**  让 agent 去合并，或者让它根据自己做的改动，向主仓库创建 pull request。所以本质上我们有开发分支、有生产分支，而我们的 agent 刚刚在自己的分支或 worktree 上做了一些改动。于是它创建了一个叫 pull request 的东西，意思是：嘿，我做了一些改动，希望你看一眼；如果你满意，就可以把它们加进主代码库。所以 Anthropic 建议：作为持续集成的一部分，或者每当有 pull request 被创建，你就让 Claude 介入

### [00:12:53–00:13:21]

**EN**  and review it against your policies and your security protocols. And all this is done asynchronously. Now, the agent might have its own comments on this PR saying it doesn't accept it or it wants some changes made in and and in Anthropic's SDLC, you've got a separate instance of Claude code reviewing those comments. And of course, it might have different policies based on what agents.md, what skills.md, what hooks, what linting it has in place. In terms of governance, you might even have a

**中文**  对照你的政策和安全协议做审查。而且这一切都是异步完成的。现在，agent 可能自己在这个 PR 上留言，说它不接受，或要求做一些修改；而在 Anthropic 的 SDLC 里，会有另一个独立的 Claude Code 实例去处理这些评论。当然，它依据的政策可能来自 agents.md、skills.md、hooks，以及已经就位的 linting。在治理方面，你甚至可能有一个

### [00:13:19–00:13:49]

**EN**  hook in place here that would block deployment unless a specific permission has been granted, unless a specific person approves, or a release gate is met. Here's an example of a set of permissions that might be used as part of that stage. So, once the pull request is complete, you have another agent that runs the security, the CI preview. This could be deterministic with some form of linting and gate checking, as well as just having an agent like cursor, bug bot, or Claude security review come in

**中文**  hook 卡在这里：除非授予了特定权限、除非特定的人批准、或除非满足 release gate，否则就阻止部署。这里有一套可能用在这个阶段的权限示例。所以 pull request 完成后，你会有另一个 agent 去跑安全检查和 CI preview。这可以是确定性的，靠某种 lint 和门控检查；也可以再让 Cursor Bugbot 或 Claude security review 这类 agent 进来

### [00:13:47–00:14:16]

**EN**  and check for any errors. And that finally brings us to the maintenance step. So, I think this is where the workflow gets really aspirational. So, we look at our whole workflow here. We've moved to planning, design, building, testing, deploying, and now we've reached maintenance. So, at this point, either our issue is fixed or our feature is built and it's sitting within the codebase. So, in a traditional software development life cycle, maintenance can be a reactive phase. You're out for lunch, you're on call, or maybe it's 3:00 a.m. in the morning and

**中文**  检查有没有错误。这最后把我们带到维护步骤。我认为工作流在这里变得相当有雄心。我们看整条工作流：已经走过规划、设计、构建、测试、部署，现在到了维护。到了这一点，要么问题已经修好，要么功能已经做完，并且坐落在代码库里。在传统软件开发生命周期里，维护可以是一个被动阶段。你在吃午饭、你在 on-call，或者凌晨三点，

### [00:14:14–00:14:44]

**EN**  you get an alert to say that your server has fallen over. A ticket is sitting in a backlog and it gets completely ignored because there's just too much in the backlog. In the AISDLC, a breach, a new ticket, a channel message in Slack, or some kind of a schedule invokes Claude without any kind of a person involved to perform maintenance. Claude asynchronously goes ahead and diagnoses and acts on that in And in this case, it's generating its

**中文**  你收到告警说服务器挂了。一张工单躺在 backlog 里，因为积压太多而被彻底忽略。在 AI SDLC 里，一次越界、一张新工单、一条 Slack 频道消息，或某种定时任务，会在没有人介入的情况下唤醒 Claude 去做维护。Claude 异步地去诊断并采取行动；在这个例子里，它会生成自己的

### [00:14:41–00:15:10]

**EN**  own intent.md file based on the logs that it's discovered or whatever ticket or message it's been sent. Now, how this works in practicality is you might decide that you have certain metrics that you want to uphold to. So, maybe in your testing, a page falls over or your API rate limit rapidly increases. That might trigger an agent to go and diagnose, create an intent, to diagnose a problem, and offer a set of suggestions, but all before you've even got to your computer. So, the whole premise of this document is we're moving

**中文**  intent.md，依据它发现的日志，或它收到的工单、消息。落到实践里，你可能会决定要守住某些指标。比如测试里某个页面挂了，或 API 速率限制突然飙升。这可能触发一个 agent 去诊断、创建一份 intent、诊断问题，并给出一组建议，而这一切发生在你还没坐到电脑前。所以这份文档的整个前提是：我们正在从

### [00:15:08–00:15:37]

**EN**  past agents just being involved in the build step to being employed in the whole software development life cycle. How can we start to reduce the amount of human time involved in each one of these steps, but importantly keeping humans in the loop for the important review steps. It depends on your workflow and your need and your team, but you can have as many humans involved in each step or agents or purely just agents on their own if there's low criticality. I've worked in a lot of companies and I've

**中文**  agent 只参与构建步骤，走向让它们进入整条软件开发生命周期。我们怎样开始减少每一步里的人类时间，同时又在重要的审查步骤上把人留在回路里。这取决于你的工作流、需求和团队：每一步可以有很多人参与，也可以有 agent 参与，如果关键性很低，甚至可以几乎只靠 agent。我在很多公司工作过，也和

### [00:15:36–00:16:05]

**EN**  worked with a lot of companies with their AI SDLC and the thing is there really is no one size fits all. If you're using something like superpowers or B mad or you've developed your own version of this, I wouldn't throw it completely out the window to adopt what Anthropic is doing here. There are so many different ways to approach this from loops to graph engineering, fully automated loops, large orchestrated systems all the way to civilization engineering. I'd love to hear how you're working your

**中文**  很多公司一起做过他们的 AI SDLC，事实是：真的没有一刀切。如果你已经在用 Superpowers 或 BMAD，或已经发展出自己的版本，我不会为了采用 Anthropic 这一套就把原来的全部扔掉。接近这件事的方式非常多，从 loops 到 graph engineering，从全自动闭环、大型编排系统，一直到 civilization engineering。我很想听听你们是怎样做

### [00:16:04–00:16:21]

**EN**  software development life cycle even if it's a simple as plan mode or complete vibe code yolo. If you want to learn how to make yourself or your development team AI native in terms of software development life cycle, highly recommend you check out switch dimension. You can sign up the waitlist there for the next cohort. Thanks so much for your time guys. I'll see you next week.

**中文**  软件开发生命周期的，哪怕简单到只用 plan mode，或完全 vibe code、YOLO。如果你想学习如何让自己或开发团队在软件开发生命周期上变成 AI-native，非常建议去看 Switch Dimension。你可以在那里登记下一期的 waitlist。非常感谢大家抽出时间。下周见。