# How to Actually Vibe Code. 20 Rules That Help Users Who Just Get Errors
**作者**: Khairallah AL-Awady
**日期**: 2026-05-29T09:42:20.000Z
**来源**: [https://x.com/eng_khairallah1/status/2060295670595195279](https://x.com/eng_khairallah1/status/2060295670595195279)
---
Everyone wants to vibe code. Almost nobody does it well.
Save this :)
They open Claude Code or Cursor or Bolt, type "build me an app," get a mess of errors, and then post on Reddit that "vibe coding is overhyped."
No. Your prompting is underdeveloped. The tool works. You just do not know how to talk to it yet.
I have been vibe coding daily for months. I have shipped real products with real users without writing traditional code. I have also produced spectacular failures that made me want to throw my laptop into the ocean.
Both experiences taught me something. These are the 20 rules that came out of it.
Every single one of these is learned from a mistake I actually made. If you follow them, you will skip months of frustration and start building things that actually work.
# The Planning Rules (1-5)
These are the rules most beginners break before they even start building.
## Rule 1: Think Before You Prompt
This is the rule that would have saved me the most time if I had followed it from day one.
Before you type a single word into Claude Code, answer three questions on paper or in a notes app:
1. What exactly am I building?
2. Who is it for?
3. What does "done" look like?
If you cannot answer these clearly, you are not ready to start. You will end up in a loop of "no that is not what I meant" and "can you redo that differently" and eventually you will burn through your context window having accomplished nothing.
The people who vibe code fast do not type fast. They think clearly before they type anything.
## Rule 2: Use Plan Mode Before Act Mode. Always.
Claude Code has two modes. Plan Mode (Shift + Tab) is where Claude thinks, plans, and maps out the approach. Act Mode is where Claude actually writes code and creates files.
Never start in Act Mode.
Every failed project I have built started because I skipped planning and went straight to "build it." Every successful one started with a 5-10 minute planning conversation where Claude and I discussed the architecture, the tech stack, the folder structure, and the order of operations.
Plan Mode feels slow. It is not. It is the fastest thing you can do because it prevents you from building the wrong thing and having to start over.
## Rule 3: Describe the Outcome, Not the Code
You are not a programmer. Stop trying to talk like one.
Bad: "Create a React component with useState hooks and a handleSubmit function that posts to an API endpoint."
Good: "I need a signup form. It should have fields for name, email, and password. When someone submits it, their info should be saved to my Supabase database. Show a confirmation message after successful signup. Make it look clean and modern."
The second prompt gives Claude everything it needs without you pretending to know implementation details. Claude knows React. Claude knows hooks. Claude knows API endpoints. Let Claude make those decisions. Your job is to describe what the user sees and what happens when they interact with it.
## Rule 4: Give Claude a Reference, Not a Description
This is the rule that 10x'd the quality of my outputs.
Instead of describing what you want your app to look like, find an existing app or website that looks close to what you want. Screenshot it. Paste the screenshot directly into Claude Code.
"Make my landing page look like this. Same layout. Same spacing. Same general vibe. But with my content and my colors."
Visual references communicate more in one screenshot than you could write in fifty lines of description. Claude interprets screenshots remarkably well. Use this constantly.
## Rule 5: Decide Your Tech Stack Before Building
If you do not pick a stack, Claude will pick one for you. And it might not be the one you want.
For beginners, here is the stack I recommend. You do not need to understand what these do yet. Just tell Claude to use them:
- Next.js: the framework
- TypeScript: the language
- Tailwind CSS: the styling
- Supabase: the database and authentication
- Vercel: the deployment
Put this in your CLAUDE.md file and you will never have to specify it again. Claude will default to this stack for every project.
# The Building Rules (6-12)
These are the rules for when you are actually building. Follow them or suffer.
## Rule 6: One Feature at a Time. No Exceptions.
The number one mistake I see beginners make. They try to build the entire app in one prompt.
"Build me a social media scheduling app with login, dashboard, content calendar, analytics, multi-platform posting, team collaboration, and Stripe billing."
You will get garbage. Claude cannot hold that much complexity in a single pass and produce quality work.
Instead:
Session 1: Build the login and signup system Session 2: Build the dashboard layout Session 3: Build the content calendar Session 4: Build the posting feature for one platform Session 5: Add the next platform
Each feature gets its own conversation. Each conversation starts fresh. Each one builds on top of what already exists.
This is how real developers work. One feature at a time. Test it. Make sure it works. Then build the next one.
## Rule 7: Test After Every Change
After Claude makes any change, run your dev server and check the result in your browser before asking for the next thing.
npm run dev
Open localhost:3000. Look at what Claude built. Click every button. Fill every form. Check every page.
If something is wrong, fix it now. Do not stack three features on top of a broken foundation. The further you get from the break point, the harder it is to fix.
Build. Check. Fix. Then build the next thing.
## Rule 8: Use Screenshots for Visual Feedback
Something looks off? The spacing is weird? The button is too small? The colors clash?
Do not describe the problem in words. Take a screenshot. Circle the issue. Paste it into Claude Code. Say: "This spacing is off. The button should be bigger. This text is hard to read."
I cannot stress this enough. Visual feedback is the single most effective way to communicate design issues to Claude. Every time I tried to describe a visual problem in words, it took three rounds of back and forth. Every time I used a screenshot, it was fixed in one.
## Rule 9: Commit to Git After Every Working Feature
Before you start the next feature, save your progress:
"Commit everything to git with the message: added user signup and login"
If something breaks later - and it will - you can roll back to the last version that worked. Without git, one bad change can destroy hours of work with no way to recover.
Claude can handle the git commands for you. Just ask.
## Rule 10: When Claude Gets Stuck, Change the Angle
Sometimes Claude will loop. It will try the same fix three times. It will introduce new bugs while fixing old ones. The context window is getting cluttered with failed attempts.
When this happens, do not keep pushing. Stop. Try one of these:
1. /clear the conversation and start a fresh one with just the problem described
2. Simplify the task - break it into even smaller pieces
3. Show Claude a working example of what you want and ask it to replicate the approach
4. Explain the problem differently - sometimes rewording unlocks a different solution path
If you have explained something three times and Claude is still not getting it, the problem is not Claude. The problem is how you are framing the request. Change the frame.
## Rule 11: Use /compact When Conversations Get Long
Claude's output quality drops as the conversation gets longer. The context window fills up. Claude starts forgetting things from earlier. Responses get more generic.
The fix: type /compact periodically. This compresses the conversation history into a summary and frees up the context window. Fresh context equals better output.
I /compact after every major feature completion. It takes seconds and noticeably improves the quality of everything that follows.
## Rule 12: Tell Claude What NOT to Do
This is underrated. Claude loves to overengineer. It will add abstractions you did not ask for. It will create utility functions for things that only happen once. It will build elaborate error handling systems for your prototype.
Add these to your CLAUDE.md:
- Do not overengineer. Keep it simple.
- Do not add dependencies I did not ask for.
- Do not create abstractions for things that only happen once.
- Do not refactor working code unless I specifically ask.
- Ask me before making any architectural changes.
Constraints make Claude's output dramatically better. Without them, Claude tries to build enterprise software when you wanted a prototype.
# The Design Rules (13-16)
The difference between something that looks amateur and something that looks professional is entirely in these rules.
## Rule 13: Steal Designs Shamelessly
Find three websites whose design you love. Screenshot specific elements - the navigation bar from one, the hero section from another, the card layout from a third.
Feed these to Claude one at a time: "Make my nav look like this." "Make my cards look like this." "Use this color palette."
You are not copying their code. You are referencing their visual design. This is what real designers do - they reference existing work and adapt it for their context.
The result is 10x better than trying to describe a design from scratch.
## Rule 14: Mobile First. Always.
Add this to your CLAUDE.md and never think about it again:
"Always build mobile-responsive. Every component must look good on a phone screen first, then scale up to desktop."
Over half of all web traffic is mobile. If your app looks broken on a phone, it does not matter how good the desktop version is. Most beginners never check their app on mobile until it is too late and the whole layout needs to be rebuilt.
## Rule 15: Typography and Spacing Matter More Than Colors
Beginners obsess over color schemes. Professionals obsess over typography and whitespace.
Tell Claude: "Use generous spacing between sections. Large headings with clear hierarchy. Body text that is easy to read. Plenty of whitespace. The design should feel spacious, not cramped."
A site with perfect spacing and a simple color scheme looks professional. A site with beautiful colors and cramped spacing looks amateur.
## Rule 16: Ask Claude to Add Polish Last
After your feature is working and the layout is correct, do a final polish pass:
"Add subtle hover effects to all clickable elements. Add smooth transitions when elements appear. Make the loading states look clean. Add subtle shadows for depth. Make it feel polished and professional."
This final 10% of polish is what makes people say "this looks like a real product." It takes five minutes and makes a massive difference.
# The System Rules (17-20)
These are the rules that turn you from a person who vibe codes occasionally into someone who ships consistently.
## Rule 17: Create Your CLAUDE.md on Day One
If you take nothing else from this article, take this.
Create a file called CLAUDE.md in the root of every project. This is persistent instructions that Claude reads before every single session. It contains your tech stack, your coding preferences, your design standards, and every rule you have established.
Every time you correct Claude twice on the same thing, add a new rule to CLAUDE.md. This file gets smarter every session. After a few weeks, Claude follows your preferences without being told because the file tells it everything.
## Rule 18: One Conversation Per Feature. Fresh Context Every Time.
Never build login, then redesign the dashboard, then add a payment system in the same conversation.
Each feature gets its own conversation. Each conversation starts with Claude reading your CLAUDE.md and the current state of your project. The context is clean. The instructions are fresh. The output is better.
I tried doing everything in one conversation early on. The quality degraded after about 30 minutes. Separate conversations eliminated this problem completely.
## Rule 19: Keep a Build Log
Create a file called BUILDLOG.md. After every session, write three things:
1. What I built today
2. What went wrong and how I fixed it
3. What I want to build next
This serves two purposes. First, it helps you pick up exactly where you left off in the next session - you can paste it into Claude and it knows the full context. Second, it creates a record of your learning. After a month, you can see how much your prompting has improved.
## Rule 20: Ship Before It Is Perfect
The biggest trap in vibe coding is endless iteration. "Let me just fix this one more thing." "Let me just add this one more feature." "Let me just make this look a little better."
Stop.
If it works and it looks decent, ship it. Put it on the internet. Show it to real people. Get real feedback.
Real user feedback is worth infinitely more than another hour of polishing. Every successful product I built was embarrassing when I first shipped it. The users did not care about the things I was self-conscious about. They cared about things I had not even thought of.
Ship it. Then improve it based on what actual users tell you.
## Where to Start Right Now
If you have never vibe coded before, do this today:
1. Install Claude Code (type npm install -g @anthropic-ai/claude-code in your terminal)
2. Create a new project folder
3. Create your CLAUDE.md file with the tech stack and rules from this article
4. Open Claude Code in that folder
5. Start in Plan Mode
6. Describe a simple project - a personal portfolio page, a landing page, a simple tool
7. Build it feature by feature, following these 20 rules
You will have something live on the internet within 48 hours. I know because I have watched dozens of complete beginners do exactly this.
Most people will read these 20 rules and keep getting the same errors they have always gotten.
The ones who actually create their CLAUDE.md file and start following these rules today will ship their first product this week. Not next month. This week.
Follow me @eng_khairallah1 for more tools, workflows, and systems. No fluff. Just what works.
hope this was useful for you, Khairallah ❤️
## 相关链接
- [Khairallah AL-Awady](https://x.com/eng_khairallah1)
- [@eng_khairallah1](https://x.com/eng_khairallah1)
- [21K](https://x.com/eng_khairallah1/status/2060295670595195279/analytics)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [BUILDLOG.md](http://buildlog.md/)
- [@anthropic](https://x.com/@anthropic)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [@eng_khairallah1](https://x.com/@eng_khairallah1)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [5:42 PM · May 29, 2026](https://x.com/eng_khairallah1/status/2060295670595195279)
- [21.4K Views](https://x.com/eng_khairallah1/status/2060295670595195279/analytics)
- [View quotes](https://x.com/eng_khairallah1/status/2060295670595195279/quotes)
---
*导出时间: 2026/5/30 00:35:50*
---
## 中文翻译
# 如何真正实现“Vibe Code”（氛围编程）。20条帮助那些只报错的用户的规则
**作者**: Khairallah AL-Awady
**日期**: 2026-05-29T09:42:20.000Z
**来源**: [https://x.com/eng_khairallah1/status/2060295670595195279](https://x.com/eng_khairallah1/status/2060295670595195279)
---
每个人都想“氛围编程”。但几乎没人能做得好。
把这个保存下来 :)
他们打开 Claude Code、Cursor 或 Bolt，输入“给我做一个应用”，结果得到一堆乱七八糟的错误，然后在 Reddit 上发帖说“氛围编程被过度吹捧了”。
不，是你的提示词太不成熟了。工具本身是没问题的。你还不知道如何跟它对话。
这几个月我每天都在进行氛围编程。我在没有写传统代码的情况下，交付了拥有真实用户的真实产品。我也搞出过惨痛的失败，让我想把笔记本电脑扔进海里。
这两种经历都教会了我一些东西。以下是从中总结出的20条规则。
每一条规则都是从我实际犯过的错误中学来的。如果你遵循它们，你将省去数月的挫败感，并开始构建真正能用的东西。
# 规划规则 (1-5)
这是大多数初学者在开始构建之前就会打破的规则。
## 规则 1：在提示之前先思考
如果我从第一天起就遵循这条规则，这本来能为我节省最多时间。
在 Claude Code 里敲一个字之前，先在纸面上或笔记应用里回答三个问题：
1. 我到底在构建什么？
2. 它是给谁用的？
3. “完成”是什么样子的？
如果你无法清晰地回答这些问题，你还没有准备好开始。你最终会陷入“不，我不是这个意思”和“你能换个方式重做吗”的死循环，最终耗尽了上下文窗口却一事无成。
那些氛围编程速度快的人，打字并不快。他们在打字之前思路很清晰。
## 规则 2：在“行动模式”之前使用“计划模式”。永远如此。
Claude Code 有两种模式。计划模式（Shift + Tab）是 Claude 思考、规划并绘制蓝图的地方。行动模式是 Claude 实际编写代码和创建文件的地方。
永远不要从行动模式开始。
我构建的每一个失败项目，都是因为我跳过了规划环节，直接进入了“构建”阶段。每一个成功的项目，都是从一场 5-10 分钟的规划对话开始的，我和 Claude 在其中讨论架构、技术栈、文件夹结构和操作顺序。
计划模式感觉很慢。其实不然。这是你能做的最快的事情，因为它防止你构建错误的东西并不得不从头再来。
## 规则 3：描述结果，而不是代码
你不是一个程序员。别试着像程序员那样说话。
差：“创建一个带有 useState hooks 的 React 组件和一个 handleSubmit 函数，该函数将数据发送到 API 端点。”
好：“我需要一个注册表单。它应该包含姓名、邮箱和密码字段。当有人提交时，他们的信息应该保存到我的 Supabase 数据库中。成功注册后显示确认消息。让它看起来干净现代。”
第二个提示给了 Claude 它所需的一切，而无需你假装了解实现细节。Claude 懂 React。Claude 懂 hooks。Claude 懂 API 端点。让 Claude 去做这些决定。你的工作是描述用户看到什么以及他们与之交互时会发生什么。
## 规则 4：给 Claude 一个参考，而不是描述
这条规则让我的输出质量提升了10倍。
与其描述你希望应用长什么样，不如找一个看起来接近你想要的现有应用或网站。截图。直接把截图粘贴到 Claude Code 里。
“把我的落地页做成这样的。同样的布局。同样的间距。同样的整体氛围。但是用我的内容和颜色。”
视觉参考在一张截图中传达的信息，比你写五十行描述还要多。Claude 对截图的解析能力惊人。请经常使用这一招。
## 规则 5：在构建之前确定你的技术栈
如果你不选择一个技术栈，Claude 会替你选一个。而且可能不是你想要的那个。
对于初学者，以下是我推荐的技术栈。你现在还不需要懂这些是干什么的。只要告诉 Claude 用这些就行：
- Next.js：框架
- TypeScript：语言
- Tailwind CSS：样式
- Supabase：数据库和认证
- Vercel：部署
把这个放在你的 CLAUDE.md 文件里，你就再也不用指定它了。Claude 会默认在每个项目中使用这个技术栈。
# 构建规则 (6-12)
这些是当你实际进行构建时的规则。遵循它们，否则等着受苦。
## 规则 6：一次一个功能。没有例外。
这是我看到初学者犯的头号错误。他们试图在一个提示词里构建整个应用。
“给我做一个社交媒体调度应用，要有登录、仪表盘、内容日历、分析、多平台发布、团队协作和 Stripe 计费。”
你会得到一堆垃圾。Claude 无法在单次通过中容纳那么多的复杂性并产出高质量的工作。
相反地：
第1次会话：构建登录和注册系统
第2次会话：构建仪表盘布局
第3次会话：构建内容日历
第4次会话：构建针对一个平台的发布功能
第5次会话：添加下一个平台
每个功能都有自己的对话。每次对话都是全新的。每一个都建立在已有的基础之上。
这就是真正的开发者的工作方式。一次一个功能。测试它。确保它能工作。然后构建下一个。
## 规则 7：每次更改后都要测试
在 Claude 做出任何更改后，运行你的开发服务器并在浏览器中检查结果，然后再要求做下一件事。
npm run dev
打开 localhost:3000。看看 Claude 构建了什么。点击每一个按钮。填写每一个表单。检查每一个页面。
如果有什么不对，现在就修。不要在破碎的地基上堆叠三个功能。你离断点越远，修复就越难。
构建。检查。修复。然后构建下一件东西。
## 规则 8：使用截图进行视觉反馈
看着有些不对劲？间距很奇怪？按钮太小？颜色冲突？
不要用文字描述问题。截图。圈出问题点。粘贴到 Claude Code。说：“这个间距不对。按钮应该更大。这段文字很难读。”
我再怎么强调也不为过。视觉反馈是向 Claude 传达设计问题的最有效方式。每当我试图用文字描述视觉问题时，都要来回折腾三轮。每当我用截图时，一次就修好了。
## 规则 9：每完成一个可用功能就提交到 Git
在开始下一个功能之前，保存你的进度：
“把所有内容提交到 git，提交信息为：添加了用户注册和登录”
如果以后出问题了——这肯定会发生的——你可以回滚到最后一个可用的版本。没有 git，一个错误的更改可能会摧毁数小时的工作且无法恢复。
Claude 可以为你处理 git 命令。直接问它就行。
## 规则 10：当 Claude 卡住时，换个角度
有时 Claude 会陷入循环。它会尝试同样的修补三次。它会在修复旧 bug 的同时引入新 bug。上下文窗口被失败的尝试填满了。
发生这种情况时，不要继续死磕。停下来。尝试以下方法之一：
1. /clear 对话并开始一个新的对话，只描述问题
2. 简化任务——把它拆成更小的块
3. 向 Claude 展示你想要的东西的一个工作示例，并要求它复制这种方法
4. 换种方式解释问题——有时重新措辞会开启不同的解决路径
如果你解释了三次而 Claude 还是不懂，问题不在于 Claude。问题在于你构建请求的方式。换个框架。
## 规则 11：当对话变长时使用 /compact
随着对话变长，Claude 的输出质量会下降。上下文窗口被填满。Claude 开始忘记之前的事情。回复变得更笼统。
解决方法：定期输入 /compact。这会将对话历史压缩成摘要并释放上下文窗口。全新的上下文等于更好的输出。
我在每完成一个主要功能后都会 /compact。这只需要几秒钟，并能显著提高后续所有内容的质量。
## 规则 12：告诉 Claude 不要做什么
这被低估了。Claude 喜欢过度设计。它会添加你没要求的抽象层。它会为只发生一次的事情创建工具函数。它会为你的原型构建 elaborate 的错误处理系统。
把这些加到你的 CLAUDE.md：
- 不要过度设计。保持简单。
- 不要添加我没要求的依赖项。
- 不要为只发生一次的事情创建抽象。
- 除非我明确要求，否则不要重构可用的代码。
- 在做出任何架构更改之前先问我。
约束能让 Claude 的输出显著变好。没有它们，Claude 会试着构建企业级软件，而你只想要一个原型。
# 设计规则 (13-16)
看起来业余和专业之间的区别完全在于这些规则。
## 规则 13：无耻地剽窃设计
找三个你深爱其设计的网站。截取特定元素——一个的导航栏，另一个的首屏区域，第三个的卡片布局。
把这些逐个喂给 Claude：“把我的导航做成这样的。”“把我的卡片做成这样的。”“使用这个配色方案。”
你不是在复制他们的代码。你是在参考他们的视觉设计。这就是真正的设计师所做的——他们参考现有的作品并根据他们的语境进行调整。
结果比从头描述设计要好 10 倍。
## 规则 14：移动优先。永远如此。
把这个加到你的 CLAUDE.md，然后永远不要再为此操心：
“始终构建移动端响应式。每个组件必须先在手机屏幕上看起来好看，然后再扩展到桌面端。”
超过一半的网络流量来自移动端。如果你的应用在手机上看起来是坏的，桌面版再好也没用。大多数初学者从不检查移动端的应用，直到为时已晚，整个布局都需要重建。
## 规则 15：字体和间距比颜色更重要
初学者痴迷于配色方案。专业人士痴迷于字体和留白。
告诉 Claude：“在章节之间使用宽松的间距。具有清晰层级的大标题。易于阅读的正文。充足的留白。设计应该感觉宽敞，而不是拥挤。”
间距完美且配色简单的网站看起来很专业。颜色漂亮但间距拥挤的网站看起来很业余。
## 规则 16：最后要求 Claude 添加润色
在你的功能可用且布局正确之后，做最后的润色：
“给所有可点击元素添加微妙的悬停效果。元素出现时添加平滑过渡。让加载状态看起来干净。添加微妙的阴影以增加深度。让它感觉经过润色和专业。”
这最后的 10% 的润色是让人们说“这看起来像个真产品”的关键。只需五分钟，却能产生巨大的差异。
# 系统规则 (17-20)
这些规则能让你从偶尔氛围编程的人变成持续交付产品的人。
## 规则 17：在第一天创建你的 CLAUDE.md
如果你从这篇文章中只拿走一样东西，那就拿走这个。
在每个项目的根目录创建一个名为 CLAUDE.md 的文件。这是 Claude 在每次会话前读取的持久指令。它包含你的技术栈、你的编码偏好、你的设计标准以及你建立的每一条规则。
每次你在同一件事上纠正 Claude 两次时，就在 CLAUDE.md 中添加一条新规则。这个文件每过一次会话就会变得更聪明。几周后，Claude 会无需吩咐就遵循你的偏好，因为文件告诉了它一切。
## 规则 18：每个功能一个对话。每次都是全新上下文。
永远不要在同一对话中构建登录，然后重新设计仪表盘，再添加支付系统。
每个功能都有自己的对话。每次对话都以 Claude 读取你的 CLAUDE.md 和项目的当前状态开始。上下文是干净的。指令是全新的。输出是更好的。
我起初试着在一个对话里做所有事。大约 30 分钟后质量就下降了。分开的对话完全消除了这个问题。
## 规则 19：保留构建日志
创建一个名为 BUILDLOG.md 的文件。每次会话后，写三件事：
1. 我今天构建了什么
2. 出了什么错以及我如何修复的
3. 我接下来想构建什么
这有两个目的。首先，它帮你确切地在下次会话中从中断处继续——你可以把它粘贴给 Claude，它就知道完整的上下文。其次，它创建了你的学习记录。一个月后，你就能看到你的提示词水平提高了多少。
## 规则 20：在完美之前发布
氛围编程最大的陷阱是无休止的迭代。“让我再修复这一件事。”“让我再添加这一个功能。”“让我把这一处再弄得好看一点。”
停下。
如果它能用且看起来还行，就发布。放到互联网上。给真实的人看。获得真实的反馈。
真实的用户反馈比又一个小时的打磨要有价值无限倍。我构建的每一个成功产品在初次发布时都让我感到尴尬。用户并不在乎我那些自觉难堪的地方。他们在乎的是我甚至没想到的事情。
发布它。然后根据真实用户的反馈来改进它。
## 现在从哪里开始
如果你以前从未尝试过氛围编程，今天就这样做：
1. 安装 Claude Code（在终端输入 npm install -g @anthropic-ai/claude-code）
2. 创建一个新的项目文件夹
3. 用本文中的技术栈和规则创建你的 CLAUDE.md 文件
4. 在该文件夹中打开 Claude Code
5. 从计划模式开始
6. 描述一个简单的项目——一个个人作品集页面、一个落地页、一个简单的工具
7. 遵循这20条规则，逐个功能地构建
你将在 48 小时内让某个东西在互联网上活起来。我知道这一点，因为我看着几十个完全的初学者正是这样做的。
大多数人会阅读这 20 条规则，然后继续得到他们一直遇到的同样的错误。
那些真正创建了他们的 CLAUDE.md 文件并从今天开始遵循这些规则的人，将在本周发布他们的第一个产品。不是下个月。是本周。
关注我 @eng_khairallah1 以获取更多工具、工作流程和系统。没有废话。只有管用的东西。
希望这对你有用，Khairallah ❤️
## 相关链接
- [Khairallah AL-Awady](https://x.com/eng_khairallah1)
- [@eng_khairallah1](https://x.com/eng_khairallah1)
- [21K](https://x.com/eng_khairallah1/status/2060295670595195279/analytics)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [BUILDLOG.md](http://buildlog.md/)
- [@anthropic](https://x.com/@anthropic)
- [CLAUDE.md](http://claude.md/)
- [CLAUDE.md](http://claude.md/)
- [@eng_khairallah1](https://x.com/@eng_khairallah1)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [5:42 PM · May 29, 2026](https://x.com/eng_khairallah1/status/2060295670595195279)
- [21.4K Views](https://x.com/eng_khairallah1/status/2060295670595195279/analytics)
- [View quotes](https://x.com/eng_khairallah1/status/2060295670595195279/quotes)
---
*导出时间: 2026/5/30 00:35:50*