# The 9-Step Loop That Turns Claude Code Into a Senior Engineer
**作者**: 0xMorty
**日期**: 2026-06-15T10:35:44.000Z
**来源**: [https://x.com/0xMortyx/status/2066469702075920794](https://x.com/0xMortyx/status/2066469702075920794)
---
Most developers use Claude Code like a junior who needs constant supervision. They type a request, watch it edit a file, eyeball the result, type the next request. It works. But it's not what Claude Code is for.
Follow my Substack to get fresh AI alpha: substack.com/@0xMortyx
A senior engineer doesn't work that way. They understand the codebase first, make a plan, write the change, test it, review it against the team's standards, and only then ship. That entire sequence can be built into Claude Code as a repeatable 9-step loop using its actual primitives: plan mode, subagents, hooks, CLAUDE.md, and slash commands.
Set this up once and every task runs through the same disciplined pipeline. Here are the 9 steps.
## The difference isn't the model. It's the loop around it.
Claude Code ships with the exact primitives a disciplined workflow needs: a planning mode that thinks before touching code, subagents that work in isolated context windows, and hooks that run deterministically every single time. The gap between a junior-tier and a senior-tier setup is just whether you've wired these together into a loop.
## 1. Explore Before Touching Anything
A senior engineer reads the codebase first. So should your agent.
Explore subagent
The junior move is to start editing immediately. The senior move is to understand the codebase first. Claude Code has a built-in Explore subagent that reads your code in read-only mode, in its own context window, without cluttering your main session or risking changes.
Start every non-trivial task by sending Claude to explore the relevant area. It comes back understanding how things actually fit together, instead of guessing.
```
START WITH EXPLORATION
# let the Explore subagent map the territory first
"Explore how authentication works across this codebase.
Map the files involved, the data flow, and anything that
looks fragile. Don't change anything yet."
```
> ✓ The agent now understands the code before it writes a single line
## 2. Make a Plan in Plan Mode
Decide the approach before any code gets written.
Plan mode
Plan mode lets Claude think through the full approach without executing anything. It produces a step-by-step plan you can read, correct, and approve before a single file changes. This is where you catch a bad approach for free, instead of after it's half-built.
The senior habit: never let it build until you've seen the plan and agreed with it.
```
PLAN MODE
# enter plan mode, then ask for the approach
"In plan mode: lay out exactly how you'd add rate limiting
to the API. List the files you'll touch, the order, and the
risks. Wait for my approval before writing code."
# you review, adjust, approve, then it builds
```
> ✓ You approve the approach before any code exists to throw away
## 3. Put Your Standards in CLAUDE.md
Your conventions, written once, read every session.
CLAUDE.md
CLAUDE.md is the agent's constitution for your repo. It reads this file every session to anchor your conventions, commands, and patterns. A senior engineer knows the team's standards by heart, and this is how you give your agent the same baseline.
```
CLAUDE.md // PROJECT ROOT
# Project Standards
## Conventions
- TypeScript strict mode, no `any`
- Functions over classes where possible
- Every new function gets a test
## Commands
- Test: `npm run test`
- Lint: `npm run lint`
- Build: `npm run build`
## Rules
- Never edit files in /generated
- Match the existing file's style before adding code
- If unsure about an approach, ask before building
```
> Important nuance:CLAUDE.md instructions are advisory. Claude follows them most of the time, but not with 100% reliability. For rules that absolutely cannot be broken, you need Step 5 (hooks), which are deterministic. CLAUDE.md sets the defaults; hooks enforce the non-negotiables.
> ✓ Every session starts with your conventions already loaded
## 4. Build the Change in Small, Reviewable Pieces
Senior engineers ship small. So should the agent.
main session
With the plan approved and standards loaded, the build step is almost boring, which is the point. Instruct the agent to implement the approved plan in small, self-contained pieces rather than one giant diff. Smaller changes are easier to verify and easier to roll back if something's wrong.
```
BUILD INSTRUCTION
"Implement step 1 of the approved plan only. Keep the change
small and self-contained. Follow the conventions in CLAUDE.md.
Stop after step 1 so I can verify before you continue."
```
> ✓ Changes arrive in pieces you can actually review, not one giant dump
## 5. Enforce the Non-Negotiables With Hooks
The senior move: make the important rules impossible to skip.
hooks
This is the step that separates a real senior setup from a polished junior one. Hooks are shell commands that fire at specific points in Claude Code's lifecycle, and unlike CLAUDE.md, they run deterministically every single time. "Always run the linter after editing." "Never let a commit through with failing tests." These become guarantees, not suggestions.
```
EXAMPLE HOOK // RUN LINT + TESTS AFTER EVERY EDIT
# .claude/settings.json (PostToolUse hook)
{
"hooks": {
"PostToolUse": [{
"matcher": "Edit|Write",
"command": "npm run lint && npm run test"
}]
}
}
# now the checks run automatically after every code change
# Claude can't "forget", the hook fires 100% of the time
```
> ✓ Your critical rules now run automatically, no exceptions
## 6. Make It Prove the Change Works
No "looks good to me." Tests, every time.
tests + hooks
A senior engineer doesn't trust code that hasn't been tested, including their own. Instruct the agent to write tests for every change and run them. Combined with the Step 5 hook, the test suite runs automatically, so "it works" means the tests actually passed, not that the diff looked plausible.
```
TEST INSTRUCTION
"Write tests that cover this change, including the edge case
where the token is expired. Run the full suite and show me
the results. If anything fails, fix it before continuing."
```
> ✓ "Done" means the tests passed, not that the code looked fine
## 7. Have a Second Agent Review the First
The senior move: a fresh pair of eyes that didn't write the code.
review subagent
Code review works because the reviewer didn't write the code. You can replicate this: spin up a review subagent with a clean context window whose only job is to critique the change. Because it has its own context and a critic's mandate, it catches things the builder rationalized past.
```
REVIEW SUBAGENT
"Launch a review subagent. Its job: review the diff I just
made as a skeptical senior engineer. Check for security
issues, missed edge cases, and anything that violates
CLAUDE.md. Report problems, do not fix them yet."
```
> ✓ A clean-context critic catches what the builder talked itself past
## 8, Fix What the Review Found, Then Re-Check
The loop closes here. Fix, re-test, re-review until clean.
the loop
This is what makes it a loop instead of a line. The review surfaces issues, the agent fixes them, and then the checks and review run again on the fixed version. You don't move forward until the change comes back clean. This is exactly how a senior engineer handles review comments.
```
CLOSE THE LOOP
"Address every issue the reviewer raised. After fixing,
re-run the tests AND launch the review subagent again on
the updated diff. Repeat until the review comes back clean.
Show me the final review verdict."
```
> ✓ Issues get fixed and re-verified, not just acknowledged
9. Ship It With a Slash Command
Wrap the whole loop into one reusable command.
slash command
Once the change is clean, ship it: a clear commit, a PR with a real description. The senior touch is to turn this entire 9-step loop into a custom slash command so you never reassemble it by hand. Save the workflow once and trigger the whole pipeline with one command.
```
.claude/commands/ship.md // YOUR WHOLE LOOP, ONE COMMAND
# /ship : run the full senior-engineer loop
1. Explore the relevant code (Explore subagent)
2. Plan the approach and wait for my approval
3. Build per CLAUDE.md, in small pieces
4. Write + run tests (hooks enforce this)
5. Launch a review subagent on the diff
6. Fix issues, re-test, re-review until clean
7. Commit with a clear message and open a PR
```
> ✓ The entire loop now runs from one command: /ship
## Why This Actually Works
None of these steps are tricks. They're the same discipline a senior engineer applies on every task, mapped onto the primitives Claude Code already ships with. The model was always capable. What was missing was the loop around it.
- Exploration means it understands before it edits, like a senior reading the code first
- Plan mode means bad approaches die before they cost you anything
- CLAUDE.md plus hooks means your standards are loaded and the critical ones are enforced
- Tests plus an independent review means "done" is earned, not claimed
- The slash command means you set this up once and run it forever
> The honest takeaway:This won't make Claude Code infallible, nothing does. But the gap between "junior who needs watching" and "senior you can trust with a task" isn't a better model. It's whether you've built the loop. Build it once and every task runs through it.
## 相关链接
- [0xMorty](https://x.com/0xMortyx)
- [@0xMortyx](https://x.com/0xMortyx)
- [53K](https://x.com/0xMortyx/status/2066469702075920794/analytics)
- [substack.com/](https://substack.com/@0xmorty)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [6:35 PM · Jun 15, 2026](https://x.com/0xMortyx/status/2066469702075920794)
- [53.4K Views](https://x.com/0xMortyx/status/2066469702075920794/analytics)
- [View quotes](https://x.com/0xMortyx/status/2066469702075920794/quotes)
---
*导出时间: 2026/6/16 13:29:41*
---
## 中文翻译
# 将 Claude Code 变身为高级工程师的 9 步循环
**作者**: 0xMorty
**日期**: 2026-06-15T10:35:44.000Z
**来源**: [https://x.com/0xMortyx/status/2066469702075920794](https://x.com/0xMortyx/status/2066469702075920794)
---
大多数开发者使用 Claude Code 的方式就像对待一个需要持续监督的初级工程师。他们输入指令，看着它编辑文件，粗略地检查结果，再输入下一条指令。这确实能用。但这并不是 Claude Code 的真正用途。
关注我的 Substack 获取最新 AI 干货：substack.com/@0xMortyx
高级工程师的工作方式并非如此。他们先理解代码库，制定计划，编写变更，进行测试，对照团队标准进行审查，最后才发布。这整个序列可以通过 Claude Code 自带的“原语”构建成一个可重复的 9 步循环：计划模式、子代理、钩子、CLAUDE.md 和斜杠命令。
只需设置一次，每个任务都会经过同样的严苛流程。以下是这 9 个步骤。
## 关键不在于模型。而在于围绕它的循环。
Claude Code 恰好具备了构建严苛工作流所需的原语：在触碰代码前先思考的计划模式、在隔离上下文窗口中工作的子代理，以及每次都会确定性运行的钩子。初级配置和高级配置之间的差距仅仅在于你是否将这些组件串联成了一个循环。
## 1. 在触碰任何东西之前先探索
高级工程师会先阅读代码库。你的代理也应该如此。
Explore 子代理
初级做法是直接开始编辑。高级做法是先理解代码库。Claude Code 内置的 Explore 子代理会在只读模式下、在其独立的上下文窗口中阅读你的代码，既不会弄乱主会话，也不会冒修改的风险。
在开始任何非平凡任务时，先让 Claude 去探索相关区域。它会带着对代码实际结构的理解回来，而不是靠猜。
```
从探索开始
# 让 Explore 子代理先绘制版图
"Explore how authentication works across this codebase.
Map the files involved, the data flow, and anything that
looks fragile. Don't change anything yet."
```
> ✓ 代理在写入一行代码前就已经理解了代码
## 2. 在计划模式下制定计划
在编写任何代码之前先确定方法。
计划模式
计划模式让 Claude 能在不执行任何操作的情况下思考完整的方法。它会生成一份分步计划，供你在任何文件变更之前阅读、修正和批准。在这里，你可以零成本地发现糟糕的方案，而不是在做到一半时才意识到。
高级习惯：绝不让它在未获批准的情况下开始构建。
```
计划模式
# 进入计划模式，然后询问方案
"In plan mode: lay out exactly how you'd add rate limiting
to the API. List the files you'll touch, the order, and the
risks. Wait for my approval before writing code."
# 你审查、调整、批准，然后它才开始构建
```
> ✓ 在任何需要废弃的代码出现之前，你就批准了方案
## 3. 将你的标准写入 CLAUDE.md
你的约定，写一次，每次会话都读。
CLAUDE.md
CLAUDE.md 是代理针对你仓库的“根本大法”。它在每次会话中都会读取此文件，以锚定你的约定、命令和模式。高级工程师将团队标准烂熟于心，而这是你赋予代理同样基准线的方法。
```
CLAUDE.md // 项目根目录
# Project Standards
## Conventions
- TypeScript strict mode, no `any`
- Functions over classes where possible
- Every new function gets a test
## Commands
- Test: `npm run test`
- Lint: `npm run lint`
- Build: `npm run build`
## Rules
- Never edit files in /generated
- Match the existing file's style before adding code
- If unsure about an approach, ask before building
```
> 重要细节：CLAUDE.md 的指令只是建议性的。Claude 大多时候会遵循，但并非 100% 可靠。对于那些绝对不能打破的规则，你需要第 5 步（钩子），它们是确定性的。CLAUDE.md 设定默认值；钩子强制执行不可协商的规则。
> ✓ 每次会话开始时，你的约定就已经加载完毕
## 4. 以小块、可审查的片段构建变更
高级工程师提交的增量很小。代理也应如此。
主会话
随着计划获批、标准加载，构建步骤几乎变得枯燥乏味——这恰恰是目的所在。指示代理按照批准的计划，以小块、自包含的片段来实现，而不是一次性搞出一个巨大的差异（diff）。较小的变更更容易验证，出错时也更容易回滚。
```
构建指令
"Implement step 1 of the approved plan only. Keep the change
small and self-contained. Follow the conventions in CLAUDE.md.
Stop after step 1 so I can verify before you continue."
```
> ✓ 变更以你真正能审查的碎片形式到来，而不是一个巨大的堆砌
## 5. 用钩子强制执行不可协商的规则
高级做法：让重要规则无法被跳过。
钩子
这一步是区分真正的高级配置与“修饰过的初级配置”的关键。钩子是在 Claude Code 生命周期特定时刻触发的 shell 命令，与 CLAUDE.md 不同，它们每次都会确定性地运行。“编辑后始终运行 Linter。”“绝不提交测试失败的代码。”这些变成了保证，而非建议。
```
钩子示例 // 每次编辑后运行 LINT + TEST
# .claude/settings.json (PostToolUse hook)
{
"hooks": {
"PostToolUse": [{
"matcher": "Edit|Write",
"command": "npm run lint && npm run test"
}]
}
}
# 现在检查会在每次代码变更后自动运行
# Claude 无法“忘记”，钩子 100% 会触发
```
> ✓ 你的关键规则现在自动运行，无一例外
## 6. 让它证明变更有效
不要说“看着没问题”。每次都要测试。
测试 + 钩子
高级工程师不信任未经测试的代码，包括他们自己写的。指示代理为每次变更编写测试并运行它们。结合第 5 步的钩子，测试套件会自动运行，所以“能用”意味着测试真的通过了，而不是仅仅看着差异（diff）似乎合理。
```
测试指令
"Write tests that cover this change, including the edge case
where the token is expired. Run the full suite and show me
the results. If anything fails, fix it before continuing."
```
> ✓ “完成”意味着测试通过，而不是代码看起来没问题
## 7. 让第二个代理审查第一个
高级做法：一双没有写过代码的新鲜眼睛。
审查子代理
代码审查之所以有效，是因为审查者没有编写该代码。你可以复制这一点：启动一个审查子代理，它拥有干净的上下文窗口，唯一的工作就是批评变更。因为它有自己的上下文和批评者的职责，它能发现构建者合理化掉的问题。
```
审查子代理
"Launch a review subagent. Its job: review the diff I just
made as a skeptical senior engineer. Check for security
issues, missed edge cases, and anything that violates
CLAUDE.md. Report problems, do not fix them yet."
```
> ✓ 一个拥有干净上下文的批评者能发现构建者自己绕过的问题
## 8. 修复审查发现的问题，然后重新检查
循环在此闭合。修复、重新测试、重新审查，直到干净。
循环
这就是它之所以成为循环而非直线的原因。审查发现问题，代理修复它们，然后检查和审查再次运行于修复后的版本。直到变更变得干净之前，你不会向前推进。这正是高级工程师处理审查意见的方式。
```
闭合循环
"Address every issue the reviewer raised. After fixing,
re-run the tests AND launch the review subagent again on
the updated diff. Repeat until the review comes back clean.
Show me the final review verdict."
```
> ✓ 问题得到修复和重新验证，而不仅仅是被确认
9. 用斜杠命令发布它
将整个循环打包成一个可重用的命令。
斜杠命令
一旦变更干净了，就发布它：一个清晰的提交，一个带有真实描述的 PR。高级的做法是将整个 9 步循环变成一个自定义的斜杠命令，这样你就永远不需要手动重新组装它。保存一次工作流，然后用一条命令触发整个流水线。
```
.claude/commands/ship.md // 你的整个循环，一条命令
# /ship : 运行完整的高级工程师循环
1. Explore the relevant code (Explore subagent)
2. Plan the approach and wait for my approval
3. Build per CLAUDE.md, in small pieces
4. Write + run tests (hooks enforce this)
5. Launch a review subagent on the diff
6. Fix issues, re-test, re-review until clean
7. Commit with a clear message and open a PR
```
> ✓ 整个循环现在由一条命令运行：/ship
## 为什么这真的有效
这些步骤中没有一个是花招。它们只是高级工程师在每个任务上应用的同样纪律，被映射到了 Claude Code 已有的原语上。模型一直都有这个能力。缺失的是围绕它的循环。
- 探索意味着它在编辑前先理解，就像高级工程师先阅读代码一样
- 计划模式意味着糟糕的方案在造成损失前就被扼杀
- CLAUDE.md 加上钩子意味着你的标准已加载，且关键规则被强制执行
- 测试加上独立审查意味着“完成”是赢来的，不是声称的
- 斜杠命令意味着你设置一次，就能永久运行
> 诚实的总结：这不会让 Claude Code 变得万无一失，没有什么能。但是，“需要被监视的初级人员”和“可以信任交付任务的高级人员”之间的差距，不在于更好的模型。而在于你是否构建了这个循环。构建一次，每个任务都会通过它运行。
## 相关链接
- [0xMorty](https://x.com/0xMortyx)
- [@0xMortyx](https://x.com/0xMortyx)
- [53K](https://x.com/0xMortyx/status/2066469702075920794/analytics)
- [substack.com/](https://substack.com/@0xmorty)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [6:35 PM · Jun 15, 2026](https://x.com/0xMortyx/status/2066469702075920794)
- [53.4K Views](https://x.com/0xMortyx/status/2066469702075920794/analytics)
- [View quotes](https://x.com/0xMortyx/status/2066469702075920794/quotes)
---
*导出时间: 2026/6/16 13:29:41*