# How to Build a Software Factory with Claude Code That Ships Features While You Sleep
**作者**: Rahul
**日期**: 2026-05-25T08:46:22.000Z
**来源**: [https://x.com/sairahul1/status/2058832033628241931](https://x.com/sairahul1/status/2058832033628241931)
---
I thought I was using AI to code.
I was actually just typing faster.
Here is the difference — and the 7-agent system that changed everything.
Save this. It will save you months.
## THE PROBLEM NOBODY TALKS ABOUT
The loop that feels productive but isn't:
→ Ask Claude to build a feature → It generates code → Something breaks → Paste the error back → It patches it → Something else breaks → Ask again
Day 1: this feels like magic.
Day 30: you're spending more time supervising AI than you used to spend writing code.
Same logic appears in 3 different places.
Claude forgot the convention you set up two weeks ago.
New features break old ones.
Tests are missing or shallow.
You wake up and realize: the AI isn't failing.
Your workflow is.
The real problem is structural.
When you type "build this feature" into Claude Code, you're asking one AI session to be:
→ Product analyst → Architect → Backend engineer → Frontend engineer → Test engineer → Code reviewer
All at once.
In the same messy conversation.
Wrong assumptions in the plan become wrong database models.
Wrong database models become wrong APIs.
Wrong APIs become wrong UIs.
By the time you notice, the mistake has spread everywhere.
This is called vibe coding.
And it has a hard ceiling.
## THE SHIFT: FROM VIBE CODING TO A SOFTWARE FACTORY
What actually changes everything:
Real engineering teams don't work in one big conversation.
Different people own different jobs:
→ Someone clarifies the user problem → Someone thinks about architecture → Someone builds the API → Someone builds the UI → Someone thinks about edge cases → Someone reviews
When you collapse all of that into one AI session, mistakes compound silently.
The fix is to split the work across specialized agents.
Each agent gets: → One focused job → Its own clean context window → Only the tools it actually needs → Strict rules about what it cannot touch
The result: a software factory.
One developer + seven focused agents = a coordinated team.
Here are the seven agents that make it work.
## THE 7 AGENTS
## Agent 1: The Codebase Researcher
The biggest mistake developers make with AI?
Asking for code as the first move.
The AI accepts the prompt, makes guesses to fill the gaps, and starts generating.
That's when bad designs sneak in.
The Codebase Researcher fixes this.
Its only job: inspect the codebase and explain how things work — before a single line is written.
What it does: → Maps the relevant files and their roles → Documents existing patterns to follow → Finds similar features already built → Flags risks (timezone, multi-tenant, retry logic) → Lists what tests will need updating
What it cannot do: → Edit files (read-only access only) → Run any command that modifies state → Make assumptions — it asks instead
Tools: Read, Grep, Glob only.
The rule: explore before you build, every single time.
The Researcher runs first. Always.
## Agent 2: The Story Writer
Most features fail not because the code was wrong.
But because the problem was never clearly defined.
The Story Writer turns a rough feature idea into a real user story before any technical decisions are made.
Input it receives: → Your rough feature description → The Researcher's findings
What it produces:
One user story:"As a [role], I want [behaviour], so that [outcome]."
Acceptance criteria:Statements a test can verify directly. Happy path. Failure paths. Business rules.
Edge cases:Boundaries, retries, multi-tenant concerns.
Out of scope:What is explicitly NOT being built.
Open questions:Things it genuinely doesn't know — never guesses.
What it cannot do: → Invent business rules → Write any code or technical design → Move forward if something is genuinely unclear
Tools: Read only.
The rule: you read this story and approve it before anything else happens.
This is the human checkpoint that saves everything downstream.
## Agent 3: The Spec Writer
Once the story is approved, the Spec Writer turns it into a technical brief.
This is the blueprint every build agent follows.
Input it receives: → Your approved user story → The Researcher's findings → Your project's CLAUDE.md rules
What it produces:
→ Data model changes (fields, types, migrations) → Background flow / process flow → API changes (endpoints, request/response shapes) → Frontend changes (components, pages, hooks) → Tests required (success, failure, edge cases) → Risks and open questions → Every file that will change
What it cannot do: → Edit any file → Invent new infrastructure — calls it out explicitly instead → Skip tenant isolation or timezone concerns → Leave questions unanswered
Tools: Read, Grep, Glob only.
The rule: this brief is the second human checkpoint.
You read it and approve it before a single file is touched.
If you see "store IDs in memory" — that's your red flag.
Catch it now. Not after 10 files have been changed.
## Agent 4: The Backend Builder
Now the building starts.
The Backend Builder implements the backend half of the feature — and only the backend half.
Input it receives: → Approved technical brief → Researcher's findings → Your project's CLAUDE.md
What it builds: → API routes → Services and business logic → Database access and migrations → Background jobs → Unit tests for everything it writes
What it cannot do: → Touch React components, pages, or client-side hooks (that's Agent 5) → Invent new dependencies without instruction → Modify files outside agreed scope → Stop without running typecheck, lint, and the test suite
After finishing, it returns a summary: → Every file added or edited → Every existing helper or pattern reused → Any CLAUDE.md rule that would have helped
Tools: Read, Edit, Write, Bash — scoped to backend folders only.
The separation is the point.
Backend Builder cannot accidentally break the frontend. Ever.
## Agent 5: The Frontend Builder
The Frontend Builder implements the UI half — and only the UI half.
It reads the Backend Builder's summary first.
This matters.
It consumes the API exactly as the backend produced it.
It does not invent new endpoints.
If the API shape is wrong for the UI, it surfaces the mismatch as feedback — not as a patch.
Input it receives: → Approved technical brief → Researcher's findings → Backend Builder's summary (the API contract)
What it builds: → React components and pages → Client-side hooks and state → Loading and error states → Component and unit tests for everything it writes
What it cannot do: → Touch services, API routes, workers, or migrations (that's Agent 4) → Invent endpoints or response shapes → Add dependencies without instruction → Stop without running typecheck, lint, and the test suite
Tools: Read, Edit, Write, Bash — scoped to frontend folders only.
Two builders.
Two clean context windows.
Zero chance one breaks the other's work.
## Agent 6: The Test Verifier
Both builders wrote unit tests for their own code.
That's not enough.
The Test Verifier does one thing only: prove that the feature actually does what the user story said it should.
It writes acceptance tests.
Not unit tests.
Acceptance tests.
These test the feature from the outside — the way a real user would experience it.
Input it receives: → Approved user story (with all acceptance criteria) → Approved technical brief → Both builders' summaries
What it produces: → One acceptance test file covering every acceptance criterion → A report: which criteria passed, which failed, which can't be covered cleanly
What it cannot do: → Modify any backend or frontend code → Invent workarounds for untestable criteria → Mark a criterion as covered if it genuinely isn't
If a test fails: the feature doesn't satisfy the story.
It reports exactly which criterion failed.
It does not patch the code.
That goes back to the right builder.
Tools: Read, Edit, Write (test files only), Bash.
The rule: you don't have a feature until the acceptance tests pass.
## Agent 7: The Implementation Validator
This is the agent that catches everything everyone else missed.
The Validator compares the current implementation against the approved story and brief — and reports gaps.
It never fixes anything.
It just tells the truth.
Every check it runs, every time:
→ Acceptance criteria from the story not yet implemented → Failure paths with no test coverage → Security issues: missing auth checks, tenant isolation gaps, secrets in logs, raw errors exposed to clients → Files changed outside agreed scope → Patterns inconsistent with CLAUDE.md or existing code → Duplicate logic that should reuse existing helpers → Timezone or multi-tenant concerns from the brief that were quietly skipped
Output is always grouped by severity:
Critical — must fix before merge Important — should fix before merge Minor — opinion-based, reviewer's call
Every finding includes the file path and line number.
If there's nothing wrong, it says so plainly.
It doesn't invent issues to look thorough.
Tools: Read, Grep, Glob only.
This agent is why the factory is trustworthy.
A self-graded paper is worthless.
A validator that sees only what's on disk — not how it was written — is honest.
## HOW THE CHAIN RUNS
The full flow — one prompt starts it all:
You open Claude Code and type:
"Build invoice reminders for invoices unpaid for more than 7 days."
Here's what happens without you typing anything else:
Step 1 → Researcher maps your invoice, payment, and email code. Returns relevant files, existing patterns, risks.
Step 2 → Story Writer produces the user story and acceptance criteria.
⏸ PAUSE: You read and approve the story.
Step 3 → Spec Writer turns the approved story into a technical brief.
⏸ PAUSE: You read and approve the brief.(Catch that "store IDs in memory" mistake right here.)
Step 4 → Backend Builder implements the service, API route, BullMQ job, and unit tests. Returns: files changed, patterns reused, all tests green.
Step 5 → Frontend Builder reads the Backend Builder's API summary, builds the admin UI tile and reminder button, writes component tests. All tests green.
Step 6 → Test Verifier writes acceptance tests for all six acceptance criteria. Reports: 7 passing, 1 failing — manual trigger doesn't check tenant ownership.
Step 7 → Validator finds it. Reports as Critical with file path and line number.
→ Loop back to Backend Builder. Fix applied. All 8 acceptance tests pass. Validator runs again. Clean.
⏸ PAUSE: You review and open the PR.
Three human checkpoints.
Everything else runs on its own.
## THE FOUNDATION: BEFORE AGENTS WORK, YOU NEED THIS
CLAUDE.md — the memory that survives every session:
Every time you open Claude Code, it starts with zero memory.
CLAUDE.md fixes this.
It's a Markdown file at your repo root that loads automatically every session.
It's where permanent project facts live:
→ Your stack (Next.js App Router, Node.js, Prisma, BullMQ, Resend) → Your commands (npm run dev, npm test, npx prisma migrate dev) → Architecture rules ("Business logic lives in services. API routes stay thin.") → What not to do ("Do not add cron — use BullMQ. Do not log raw payment payloads.") → Pointers to deeper docs (docs/billing.md, docs/architecture.md)
Keep it 100-300 lines.
Every time AI makes a mistake that surprises you, ask: would a rule in CLAUDE.md have prevented this?
Add the rule.
In a few weeks, your CLAUDE.md becomes a record of every assumption the AI got wrong — and your sessions get noticeably better.
Context drift — the silent killer:
Most Claude Code sessions don't fail dramatically.
They drift.
A wrong assumption enters the context.
The model keeps building on top of it.
You ask Claude to build subscription management.
It designs: User → Subscription.
You remember: subscriptions belong to the company, not the user.
If you just say "no, subscriptions belong to companies" — Claude patches.
Now you have both user.subscriptionId and company.subscriptionId floating around.
Rule:
→ Small typo? Correct it inline. → Wrong architectural assumption? Throw the conversation away and start fresh with the right assumption baked into the first prompt.
A clean session with the right mental model beats a patched session every time.
## THE RESULTS: WHAT ACTUALLY CHANGES
Before the factory:
→ Vibe coding loop: prompt → generate → error → patch → repeat → Session context fills up with noise → Wrong assumptions compound into broken features → One engineer can only do one thing at a time → Every feature waits for the right person to be available
After the factory:
→ Structured chain: research → story → brief → build → verify → validate → Each agent gets a clean context window with only what it needs → Wrong assumptions get caught at the brief approval — not after 10 files → One engineer ships a complete vertical slice: backend, frontend, tests, validation → The team's best knowledge lives in the agents — not trapped in people
The real shift:
The payments specialist builds a payments-integration agent.
Now every engineer on the team can ship a feature that touches billing.
Without waiting.
Without a handoff.
The frontend lead's component patterns live in the frontend-builder agent.
The DevOps engineer's CI checks live in a hook.
The QA lead's edge cases live in the test-verifier rules.
Expert knowledge, shared as agents.
Not trapped in availability.
## HOW TO BUILD YOURS THIS WEEKEND
8-step setup checklist:
1. Install Claude Code → code.claude.com
2. Create the folder structure: → .claude/agents/ → .claude/skills/feature-factory/ → .claude/skills/build-with-tests/ → .claude/hooks/
3. Write your CLAUDE.md (100–300 lines: stack, commands, architecture rules, don't-do list)
4. Create the 7 agents using the /agents command in Claude Code. Describe each agent's role. Claude writes the file. You review and commit.
5. Create the feature-factory orchestrator skill. Ask Claude to write it — it reads your 7 agent files and wires the chain.
6. Create the build-with-tests skill. Describes how your team builds: match existing patterns, write tests alongside code, run typecheck at the end.
7. Add a pre-commit hook. Blocks commits that include .env, .key, .pem, or secrets.json files. Takes 5 minutes. Prevents disasters.
8. Run one real feature through the full chain. Pick something small. Watch where it stumbles. Add rules. The factory tunes itself.
Total time: 2–3 hours.
Then run a few features.
After 3–4, the factory knows your codebase.
You'll spend less time supervising.
More time deciding what to build next.
## THE 7 AGENTS — QUICK REFERENCE
→ Researcher — maps the code before anything is built (Read only) → Story Writer — turns idea into user story with acceptance criteria (Read only) → Spec Writer — turns story into technical brief (Read only) → Backend Builder — builds API, services, jobs, unit tests (backend folders only) → Frontend Builder — builds components, pages, hooks, UI tests (frontend folders only) → Test Verifier — writes acceptance tests against the user story (test files only) → Validator — compares implementation against story and brief, reports gaps (Read only)
3 human checkpoints:→ Approve the story → Approve the brief → Approve the PR
Everything else runs on its own.
Most developers using Claude Code are still vibe coding.
Prompting → generating → patching → hoping.
That's not wrong.
It's just a ceiling.
The factory doesn't remove you from the process.
It removes you from the parts that don't need you.
You stay in the loop where your judgment matters:
Is this the right problem? Is this the right design? Is this safe to ship?
The agents handle everything in between.
That's the difference between using AI as a faster keyboard —
and using AI as a coordinated team.
If this was useful:
→ Repost to share it with your network → Follow @sairahul1 for more breakdowns like this → Bookmark this — you'll want to reference the 7 agents
I write about AI, building products, and systems that work while you sleep.
## 相关链接
- [Rahul](https://x.com/sairahul1)
- [@sairahul1](https://x.com/sairahul1)
- [code.claude.com](https://code.claude.com/)
- [@sairahul1](https://x.com/@sairahul1)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:46 PM · May 25, 2026](https://x.com/sairahul1/status/2058832033628241931)
- [1M Views](https://x.com/sairahul1/status/2058832033628241931/analytics)
- [View quotes](https://x.com/sairahul1/status/2058832033628241931/quotes)
---
*导出时间: 2026/5/26 09:15:25*
---
## 中文翻译
# 如何利用 Claude Code 打造一个在你睡觉时也能交付功能的软件工厂
**作者**: Rahul
**日期**: 2026-05-25T08:46:22.000Z
**来源**: [https://x.com/sairahul1/status/2058832033628241931](https://x.com/sairahul1/status/2058832033628241931)
---
我以为我在用 AI 写代码。
实际上，我只是在打字打得更快了。
这就是区别——以及改变一切的 7 智能体系统。
收藏这篇文章。它会为你节省数月的时间。
## 没人谈论的真正问题
这个循环看起来很高效，实则不然：
→ 让 Claude 构建一个功能 → 它生成代码 → 出问题了 → 把错误贴回去 → 它打补丁 → 别的地方又坏了 → 再次询问
第 1 天：这感觉像魔法。
第 30 天：你花在监督 AI 上的时间比以前写代码的时间还多。
同样的逻辑出现在 3 个不同的地方。
Claude 忘记了你两周前设定的约定。
新功能破坏了旧功能。
测试缺失或流于表面。
你醒来意识到：AI 并没有失败。
是你的工作流失败了。
真正的问题在于结构。
当你在 Claude Code 中输入“构建这个功能”时，你是在要求一个 AI 会话同时扮演：
→ 产品分析师 → 架构师 → 后端工程师 → 前端工程师 → 测试工程师 → 代码审查员
全部同时进行。
在同一个混乱的对话中。
计划中的错误假设会变成错误的数据库模型。
错误的数据库模型会变成错误的 API。
错误的 API 会变成错误的 UI。
等到你发现时，错误已经到处蔓延。
这就叫做“氛围编程”。
而且它有一个无法突破的天花板。
## 转变：从“氛围编程”到“软件工厂”
真正能改变一切的是：
真正的工程团队不会在一个大对话里工作。
不同的人负责不同的工作：
→ 有人澄清用户问题 → 有人思考架构 → 有人构建 API → 有人构建 UI → 有人思考边缘情况 → 有人审查
当你把所有这些都折叠进一个 AI 会话时，错误会悄悄地复合叠加。
解决方法是将工作拆分给专门的智能体。
每个智能体获得：→ 一个专注的职责 → 自己独立的干净上下文窗口 → 只有它真正需要的工具 → 关于它不能触碰什么（内容）的严格规则
结果就是：一个软件工厂。
一名开发者 + 七个专注的智能体 = 一个协调的团队。
以下是让这一切运作的七个智能体。
## 7 大智能体
## 智能体 1：代码库研究员
开发者使用 AI 最大的错误是什么？
第一步就索要代码。
AI 接受提示词，进行猜测来填补空白，并开始生成。
这就是糟糕的设计混入的时候。
代码库研究员解决了这个问题。
它唯一的职责：在写下任何一行代码之前，检查代码库并解释其运作方式。
它的作用：→ 映射相关文件及其角色 → 记录要遵循的现有模式 → 查找已构建的类似功能 → 标记风险（时区、多租户、重试逻辑） → 列出需要更新的测试
它不能做的事情：→ 编辑文件（仅限只读访问）→ 运行任何修改状态的命令 → 做出假设——相反，它会提问
工具：仅限 Read、Grep、Glob。
规则：每次都要先探索再构建。
研究员首先运行。始终如此。
## 智能体 2：故事撰写人
大多数功能的失败不是因为代码错了。
而是因为问题从未被清晰地定义。
故事撰写人在做出任何技术决策之前，将粗糙的功能想法转化为真正的用户故事。
它接收的输入：→ 你粗糙的功能描述 → 研究员的发现
它产出的内容：
一个用户故事：“作为一个[角色]，我想要[行为]，以便[结果]。”
验收标准：测试可以直接验证的陈述。正常路径。失败路径。业务规则。
边缘情况：边界、重试、多租户关注点。
非范围内容：明确不构建的内容。
开放性问题：它真正不知道的事情——绝不猜测。
它不能做的事情：→ 发明业务规则 → 编写任何代码或技术设计 → 如果真的不清楚就继续推进
工具：仅限 Read。
规则：在发生其他任何事情之前，你要阅读并批准这个故事。
这是拯救后续一切的人工检查点。
## 智能体 3：规格说明撰写人
一旦故事被批准，规格说明撰写人就会将其转化为技术简报。
这是每个构建智能体遵循的蓝图。
它接收的输入：→ 你批准的用户故事 → 研究员的发现 → 你项目的 CLAUDE.md 规则
它产出的内容：
→ 数据模型变更（字段、类型、迁移）→ 后台流程/处理流程 → API 变更（端点、请求/响应形状）→ 前端变更（组件、页面、钩子）→ 所需测试（成功、失败、边缘情况）→ 风险和开放性问题 → 将要更改的每个文件
它不能做的事情：→ 编辑任何文件 → 发明新的基础设施——而是明确指出 → 跳过租户隔离或时区问题 → 留下未回答的问题
工具：仅限 Read、Grep、Glob。
规则：这个简报是第二个人工检查点。
你要阅读并批准它，然后才能触碰任何文件。
如果你看到“在内存中存储 ID”——那就是你的危险信号。
现在就抓住它。而不是在更改了 10 个文件之后。
## 智能体 4：后端构建者
现在构建开始了。
后端构建者实现功能的后端半部分——而且只是后端半部分。
它接收的输入：→ 批准的技术简报 → 研究员的发现 → 你项目的 CLAUDE.md
它构建的内容：→ API 路由 → 服务和业务逻辑 → 数据库访问和迁移 → 后台作业 → 它编写的所有内容的单元测试
它不能做的事情：→ 触碰 React 组件、页面或客户端钩子（那是智能体 5 的事）→ 未经指示发明新的依赖关系 → 修改约定范围之外的文件 → 在未运行类型检查、Lint 和测试套件的情况下停止
完成后，它返回一个摘要：→ 添加或编辑的每个文件 → 重用的每个现有辅助工具或模式 → 任何本会有所帮助的 CLAUDE.md 规则
工具：Read、Edit、Write、Bash——仅限于后端文件夹。
分离才是关键。
后端构建者永远不会意外破坏前端。
## 智能体 5：前端构建者
前端构建者实现 UI 半部分——而且只是 UI 半部分。
它首先阅读后端构建者的摘要。
这很重要。
它完全按照后端生成的样子消费 API。
它不会发明新的端点。
如果 API 形状对 UI 来说是错的，它会将不匹配作为反馈提出来——而不是打补丁。
它接收的输入：→ 批准的技术简报 → 研究员的发现 → 后端构建者的摘要（API 契约）
它构建的内容：→ React 组件和页面 → 客户端钩子和状态 → 加载和错误状态 → 它编写的所有内容的组件和单元测试
它不能做的事情：→ 触碰服务、API 路由、Worker 或迁移（那是智能体 4 的事）→ 发明端点或响应形状 → 未经指示添加依赖关系 → 在未运行类型检查、Lint 和测试套件的情况下停止
工具：Read、Edit、Write、Bash——仅限于前端文件夹。
两个构建者。
两个干净的上下文窗口。
一个破坏另一个工作的机会为零。
## 智能体 6：测试验证者
两个构建者都为自己的代码编写了单元测试。
这还不够。
测试验证者只做一件事：证明功能确实实现了用户故事所说的它应该做的事情。
它编写验收测试。
不是单元测试。
是验收测试。
这些测试是从外部测试功能——也就是真实用户体验它的方式。
它接收的输入：→ 批准的用户故事（包含所有验收标准）→ 批准的技术简报 → 两个构建者的摘要
它产出的内容：→ 一个涵盖每条验收标准的验收测试文件 → 一份报告：哪些标准通过了，哪些失败了，哪些无法清晰地覆盖
它不能做的事情：→ 修改任何后端或前端代码 → 为不可测试的标准发明变通方法 → 如果实际上没有覆盖，就标记某条标准为已覆盖
如果测试失败：功能不满足故事。
它准确报告哪个标准失败了。
它不给代码打补丁。
那会回退给正确的构建者。
工具：Read、Edit、Write（仅限测试文件）、Bash。
规则：在验收测试通过之前，你并没有完成功能。
## 智能体 7：实现验证者
这是捕捉其他所有人错过的所有内容的智能体。
验证者将当前的实现与批准的故事和简报进行比较——并报告差距。
它从不修复任何东西。
它只是说出真相。
它运行的每次检查，每一回：
→ 故事中尚未实现的验收标准 → 没有测试覆盖的失败路径 → 安全问题：缺少权限检查、租户隔离漏洞、日志中的密钥、暴露给客户端的原始错误 → 约定范围之外更改的文件 → 与 CLAUDE.md 或现有代码不一致的模式 → 应该重用现有辅助工具的重复逻辑 → 简报中悄悄跳过的时区或多租户问题
输出总是按严重程度分组：
严重——合并前必须修复 重要——合并前应该修复 轻微——基于观点，审查者决定
每个发现都包含文件路径和行号。
如果没有问题，它会坦率地说明。
它不会为了看起来彻底而发明问题。
工具：仅限 Read、Grep、Glob。
这个智能体是工厂值得信赖的原因。
自我评分的试卷毫无价值。
一个只看磁盘上内容——而不是怎么写——的验证者才是诚实的。
## 链条如何运行
完整的流程——一个提示词启动一切：
你打开 Claude Code 并输入：
“为未付款超过 7 天的发票构建发票提醒。”
不需要你再输入任何其他内容，就会发生以下事情：
第 1 步 → 研究员映射你的发票、支付和电子邮件代码。返回相关文件、现有模式、风险。
第 2 步 → 故事撰写人生成用户故事和验收标准。
⏸ 暂停：你阅读并批准故事。
第 3 步 → 规格说明撰写人将批准的故事转化为技术简报。
⏸ 暂停：你阅读并批准简报。（就在这里抓住“在内存中存储 ID”的错误。）
第 4 步 → 后端构建者实现服务、API 路由、BullMQ 作业和单元测试。返回：更改的文件、重用的模式、所有测试通过。
第 5 步 → 前端构建者阅读后端构建者的 API 摘要，构建管理 UI 磁贴和提醒按钮，编写组件测试。所有测试通过。
第 6 步 → 测试验证者为所有 6 条验收标准编写验收测试。报告：7 个通过，1 个失败——手动触发不检查租户所有权。
第 7 步 → 验证者发现了它。报告为严重并包含文件路径和行号。
→ 循环回到后端构建者。应用修复。所有 8 个验收测试通过。验证者再次运行。干净。
⏸ 暂停：你审查并打开 PR。
三个人工检查点。
其他一切都是自动运行的。
## 基础：在智能体工作之前，你需要这个
CLAUDE.md——在每个会话中存留的记忆：
每次你打开 Claude Code，它都从零记忆开始。
CLAUDE.md 解决了这个问题。
它是你仓库根目录下的一个 Markdown 文件，每个会话自动加载。
它是永久项目事实存在的地方：
→ 你的技术栈（Next.js App Router、Node.js、Prisma、BullMQ、Resend）→ 你的命令（npm run dev、npm test、npx prisma migrate dev）→ 架构规则（“业务逻辑存在于服务中。API 路由保持精简。”）→ 不要做的事情（“不要添加 cron——使用 BullMQ。不要记录原始支付负载。”）→ 指向更深层文档的指针（docs/billing.md、docs/architecture.md）
保持它在 100-300 行。
每次 AI 犯了一个让你感到惊讶的错误，问一下自己：CLAUDE.md 中的一条规则能不能防止这种情况？
添加这条规则。
几周内，你的 CLAUDE.md 就会成为记录每个 AI 犯错的假设的档案——而你的会话会明显变好。
上下文漂移——沉默的杀手：
大多数 Claude Code 会话不会戏剧性地失败。
它们会漂移。
一个错误的假设进入了上下文。
模型不断在其基础上构建。
你让 Claude 构建订阅管理。
它设计：用户 → 订阅。
你记起：订阅属于公司，而不是用户。
如果你只是说“不，订阅属于公司”——Claude 会打补丁。
现在你同时有了 user.subscriptionId 和 company.subscriptionId 到处浮动。
规则：
→ 小错别字？直接更正。→ 错误的架构假设？扔掉对话，并在第一个提示词中植入正确的假设，重新开始。
一个拥有正确思维模型的干净会话，每次都胜过一个打满补丁的会话。
## 结果：实际上改变了什么
在工厂之前：
→ 氛围编程循环：提示 → 生成 → 错误 → 补丁 → 重复 → 会话上下文中充满了噪音 → 错误的假设复合成破坏的功能 → 一名工程师一次只能做一件事 → 每个功能都要等合适的人有空
在工厂之后：
→ 结构化链条：研究 → 故事 → 简报 → 构建 → 验证 → 验证者 → 每个智能体获得一个只有它需要的干净上下文窗口 → 错误的假设在简报批准时被抓住——而不是在 10 个文件之后 → 一名工程师交付一个完整的垂直切片：后端、前端、测试、验证 → 团队最好的知识存在于智能体中——而不是被困在人身上
真正的转变：
支付专家构建了一个支付集成智能体。
现在团队中的每个工程师都可以交付触及账单的功能。
无需等待。
无需交接。
前端负责人的组件模式存在于前端构建者智能体中。
DevOps 工程师的 CI 检查存在于一个钩子中。
QA 负责人的边缘情况存在于测试验证者规则中。
专业知识，作为智能体共享。
不困于“是否有空”。
## 如何在这个周末建立你自己的工厂
8 步设置清单：
1. 安装 Claude Code → code.claude.com
2. 创建文件夹结构：→ .claude/agents/ → .claude/skills/feature-factory/ → .claude/skills/build-with-tests/ → .claude/hooks/
3. 编写你的 CLAUDE.md（100-300 行：技术栈、命令、架构规则、不要做的事列表）
4. 使用 Claude Code 中的 /agents 命令创建 7 个智能体。描述每个智能体的角色。Claude 编写文件。你审查并提交。
5. 创建 feature-factory 编排技能。让 Claude 编写它——它读取你的 7 个智能体文件并连接链条。
6. 创建 build-with-tests 技能。描述你的团队如何构建：匹配现有模式，与代码并行编写测试，在最后运行类型检查。
7. 添加一个预提交钩子。阻止包含 .env、.key、.pem 或 secrets.json 文件的提交。耗时 5 分钟。防止灾难。
8. 在完整链条中运行一个真实的功能。选一个小事。观察它在哪里跌倒。添加规则。工厂自我调整。
总时间：2-3 小时。
然后运行几个功能。
3-4 个之后，工厂就了解了你的代码库。
你会花更少的时间监督。
更多的时间决定接下来要构建什么。
## 7 大智能体——快速参考
→ 研究员——在构建任何内容之前映射代码库（仅限读取）→ 故事撰写人——将想法转化为带有验收标准的用户故事（仅限读取）