From a40adac6830670c40c760de11b2fb2571ed99965 Mon Sep 17 00:00:00 2001 From: sanbuphy Date: Thu, 26 Feb 2026 05:34:19 +0800 Subject: [PATCH] feat(i18n): complete English translation for stage-0 and stage-1 core content - Translate stage-1/1.0-finding-great-idea (Find Great Ideas) - Translate stage-1/1.2-building-prototype (Build Product Prototypes) - Translate stage-1/1.4-complete-project-practice (Complete Project Practice) - Translate appendix-a-product-thinking (Product Thinking and Solution Design) - Translate appendix-b-common-errors (What to Do When You Encounter Errors) - Update sidebar links for English locale - Fix image paths to use relative references to zh-cn images - Update internal links from /en/ to /zh-cn/ for untranslated appendix content --- docs/.vitepress/config.mjs | 83 ++- docs/en/stage-0/index.md | 10 +- .../stage-1/1.0-finding-great-idea/index.md | 543 ++++++++++++++++++ .../1.1-introduction-to-ai-ide/index.md | 8 +- .../stage-1/1.2-building-prototype/index.md | 505 ++++++++++++++++ .../1.4-complete-project-practice/index.md | 291 ++++++++++ .../appendix-a-product-thinking/index.md | 327 +++++++++++ .../stage-1/appendix-b-common-errors/index.md | 325 +++++++++++ .../1.1-introduction-to-ai-ide/index.md | 8 +- 9 files changed, 2083 insertions(+), 17 deletions(-) create mode 100644 docs/en/stage-1/1.0-finding-great-idea/index.md create mode 100644 docs/en/stage-1/1.2-building-prototype/index.md create mode 100644 docs/en/stage-1/1.4-complete-project-practice/index.md create mode 100644 docs/en/stage-1/appendix-a-product-thinking/index.md create mode 100644 docs/en/stage-1/appendix-b-common-errors/index.md diff --git a/docs/.vitepress/config.mjs b/docs/.vitepress/config.mjs index f3d9a84..848c35f 100644 --- a/docs/.vitepress/config.mjs +++ b/docs/.vitepress/config.mjs @@ -251,11 +251,11 @@ const productManagerSidebarEn = [ }, { text: 'AI Industry Application Scenarios (B-end)', - link: '/en/stage-1/appendix-industry-scenarios/' + link: '/zh-cn/stage-1/appendix-industry-scenarios/' }, { text: 'AI Consumer Scenarios Inspiration (C-end)', - link: '/en/stage-1/appendix-c-consumer-scenarios/' + link: '/zh-cn/stage-1/appendix-c-consumer-scenarios/' } ] }, @@ -269,11 +269,11 @@ const productManagerSidebarEn = [ }, { text: 'Comparison of Seven AI Programming Tools', - link: '/en/stage-1/appendix-articles/example0-1/vibe-coding-tools-snake-game-tutorial' + link: '/zh-cn/stage-1/appendix-articles/example0-1/vibe-coding-tools-snake-game-tutorial' }, { text: 'Design Websites with Agents', - link: '/en/stage-1/appendix-articles/example0-2/vibe-coding-tools-build-website-with-ai-coding-and-design-agents' + link: '/zh-cn/stage-1/appendix-articles/example0-2/vibe-coding-tools-build-website-with-ai-coding-and-design-agents' } ] } @@ -1023,6 +1023,21 @@ export default defineConfig({ // 多语言配置 - 使用 cn/en-us/ja 结构 locales: { + // 根路径 — 仅用于 404 页面兜底,实际首页由 docs/index.md 自动重定向 + root: { + label: '简体中文', + lang: 'zh-CN', + link: '/zh-cn/', + themeConfig: { + ...commonThemeConfig, + notFound: { + title: '页面未找到', + quote: '你访问的页面不存在,可能已被移动或删除。', + linkText: '返回首页', + linkUrl: '/zh-cn/' + } + } + }, // 中文 'zh-cn': { label: '简体中文', @@ -1038,6 +1053,12 @@ export default defineConfig({ ), themeConfig: { ...commonThemeConfig, + notFound: { + title: '页面未找到', + quote: '你访问的页面不存在,可能已被移动或删除。', + linkText: '返回首页', + linkUrl: '/zh-cn/' + }, outline: { level: [1, 6], label: '页面导航' @@ -1771,6 +1792,12 @@ export default defineConfig({ ), themeConfig: { ...commonThemeConfig, + notFound: { + title: 'Page Not Found', + quote: 'The page you are looking for does not exist or has been moved.', + linkText: 'Take me home', + linkUrl: '/en/' + }, outline: { level: [1, 6], label: 'On this page' @@ -1816,6 +1843,12 @@ export default defineConfig({ ), themeConfig: { ...commonThemeConfig, + notFound: { + title: 'ページが見つかりません', + quote: 'お探しのページは存在しないか、移動された可能性があります。', + linkText: 'ホームに戻る', + linkUrl: '/ja-jp/' + }, outline: { level: [1, 6], label: 'このページの目次' @@ -1854,6 +1887,12 @@ export default defineConfig({ ), themeConfig: { ...commonThemeConfig, + notFound: { + title: '頁面未找到', + quote: '你訪問的頁面不存在,可能已被移動或刪除。', + linkText: '返回首頁', + linkUrl: '/zh-tw/' + }, outline: { level: [1, 6], label: '頁面導航' @@ -1891,6 +1930,12 @@ export default defineConfig({ ), themeConfig: { ...commonThemeConfig, + notFound: { + title: '페이지를 찾을 수 없습니다', + quote: '찾고 있는 페이지가 존재하지 않거나 이동되었을 수 있습니다.', + linkText: '홈으로 돌아가기', + linkUrl: '/ko-kr/' + }, outline: { level: [1, 6], label: '페이지 탐색' @@ -1925,6 +1970,12 @@ export default defineConfig({ ), themeConfig: { ...commonThemeConfig, + notFound: { + title: 'Página no encontrada', + quote: 'La página que buscas no existe o ha sido movida.', + linkText: 'Volver al inicio', + linkUrl: '/es-es/' + }, outline: { level: [1, 6], label: 'Navegación de página' @@ -1962,6 +2013,12 @@ export default defineConfig({ ), themeConfig: { ...commonThemeConfig, + notFound: { + title: 'Page non trouvée', + quote: 'La page que vous recherchez n\'existe pas ou a été déplacée.', + linkText: 'Retour à l\'accueil', + linkUrl: '/fr-fr/' + }, outline: { level: [1, 6], label: 'Navigation de page' @@ -1996,6 +2053,12 @@ export default defineConfig({ ), themeConfig: { ...commonThemeConfig, + notFound: { + title: 'Seite nicht gefunden', + quote: 'Die gesuchte Seite existiert nicht oder wurde verschoben.', + linkText: 'Zurück zur Startseite', + linkUrl: '/de-de/' + }, outline: { level: [1, 6], label: 'Seitennavigation' @@ -2030,6 +2093,12 @@ export default defineConfig({ ), themeConfig: { ...commonThemeConfig, + notFound: { + title: 'الصفحة غير موجودة', + quote: 'الصفحة التي تبحث عنها غير موجودة أو تم نقلها.', + linkText: 'العودة إلى الرئيسية', + linkUrl: '/ar-sa/' + }, outline: { level: [1, 6], label: 'تنقل الصفحة' @@ -2067,6 +2136,12 @@ export default defineConfig({ ), themeConfig: { ...commonThemeConfig, + notFound: { + title: 'Không tìm thấy trang', + quote: 'Trang bạn đang tìm kiếm không tồn tại hoặc đã được di chuyển.', + linkText: 'Về trang chủ', + linkUrl: '/vi-vn/' + }, outline: { level: [1, 6], label: 'Điều hướng trang' diff --git a/docs/en/stage-0/index.md b/docs/en/stage-0/index.md index b6158ea..ec13257 100644 --- a/docs/en/stage-0/index.md +++ b/docs/en/stage-0/index.md @@ -29,27 +29,27 @@ Master the Vibe Coding workflow, learn to deconstruct requirements, and independ diff --git a/docs/en/stage-1/1.0-finding-great-idea/index.md b/docs/en/stage-1/1.0-finding-great-idea/index.md new file mode 100644 index 0000000..e98ac60 --- /dev/null +++ b/docs/en/stage-1/1.0-finding-great-idea/index.md @@ -0,0 +1,543 @@ +--- +title: 'Finding Great Ideas - From User Needs to Willingness to Pay' +description: 'Learn how to discover business opportunities from daily pain points, master systematic methodology for needs analysis, and transform ordinary ideas into product concepts that users are willing to pay for.' +--- + + + +# Beginner Level 2: Finding Great Ideas + +## Chapter Overview + + + +Previously, we learned how to build things with AI IDE, but there's a more fundamental question: What to build? + +Many people start by thinking "let's make an AI tool" or "let's create a social platform," only to find that nobody uses what they build. Where's the problem? They didn't find real needs. + +The harsher reality is: Many products solve problems, but users still won't pay for them. + +In this chapter, through Xiao Ming's story, we'll learn how to find product directions worth pursuing. + +After completing this chapter, you'll have a complete methodology for finding ideas and 3 validated product concepts. + + + + +
+ + + +
+ +## Step 1: Establish Criteria — What Makes Users Willing to Pay + +::: warning Why is this chapter important? + +Some might find it strange: "Isn't this a course teaching Vibe Coding? Why learn 'finding needs' first? Can't we just start coding?" + +Indeed, many programming courses on the market teach you to build projects directly: make a Todo List, a calculator, a personal blog... These projects can help you get familiar with syntax and tools, but the problem is: + +Wrong direction, the deeper you go, the more wrong you become. + +Imagine: +- You spend two weeks building a "calendar management system," but there are already 100 better ones on the market +- You make a "calorie photo calculator," but users uninstall it after one use +- You create a "personal expense tracker," but even you can't be bothered to use it + +After completing these projects, can you put them on your resume? Probably not, because they don't solve real problems or create real value. + +The harsher truth is: since we're investing time in learning, why not aim for better results? + +Since Vibe Coding lets us quickly turn ideas into products, we should learn to find ideas worth building. Train yourself in the most practical way — not by making "practice projects," but by making "products people want to use." + +That's why we need to learn "finding great ideas" first. + +--- + +**In my opinion**, time is precious. **If you're going to do something, do it right**, otherwise why not just play? As a responsibility, I'll do my best to support you in achieving excellence. + +Even if no one believes you can do well, I'll steadfastly hope for your success. You've chosen vibecoding to build products, so let's see how far you can go! + +::: + + +--- + +## Opening: The Story of Independent Developer Xiao Ming + +Xiao Ming is a programmer with three years of experience. One day he suddenly thought: why not make a fitness APP to help users create workout plans and record training data? This idea excited him — he finally found a project he could work on. + +Over the next year, Xiao Ming poured almost all his spare time into it. He built a fully-featured APP — course modules, check-in systems, community features, data analysis — everything it should have. The interface looked pretty good too, at least he thought so. + +On launch day, Xiao Ming was full of anticipation. He spent quite a bit on promotion, and in the first month, 50,000 people downloaded it. Looks like a good start, right? + +But problems soon emerged. After downloading, users would uninstall after one use. The 7-day retention was only 5%. He added some paid features, but almost no users were willing to pay. What frustrated him more was that mature products like Keep, Bohe Health, and FitTime had more complete features and better content — why would users switch to his APP? + +After a year, Xiao Ming lost 200,000 yuan. + +He sat in front of his computer, looking at the dismal data in the backend, with only one question in his mind: My APP is pretty good, why does nobody use it? Even more, why won't anyone pay for it? + + + +Xiao Ming's failure wasn't because his technology was bad, nor because the product was poorly made. Honestly, his APP had comprehensive features and a nice interface. + +**The problem was at the starting point.** + +He never asked the most basic question: Do users really need this? + +He saw the fitness APP market was huge, Keep was valued at hundreds of millions, and thought this was a great opportunity. But he didn't clarify a few things: Why do users need another fitness APP? Compared to Keep, what's my differentiation? Are users willing to pay for this? + +**Wrong direction, the deeper you go, the more wrong you become.** He spent a year making a wrong direction increasingly perfect, only to move further from success. + + +::: tip What we'll do in this chapter + +In this chapter, let's help Xiao Ming review what happened. Let's see where his problem really was, and then together find product directions that people are actually willing to pay for. + +We'll proceed in three steps: + +**Act 1: Find Real Needs** — First understand what kind of needs users are willing to pay for + +**Act 2: Dig Out Great Ideas** — Learn to mine valuable business opportunities from ordinary ideas + +**Act 3: AI Dialogue Refinement** — Use AI to turn ideas into actionable product plans + +::: + +--- + +## Act 1: Finding Real Needs + +Xiao Ming was frustrated but didn't give up. He started reflecting on a question: What kind of needs are users actually willing to pay for? + +### Xiao Ming's Confusion: Why Won't Users Pay? + +He went to find a few friends who had used his APP, wanting to hear their honest thoughts. + +Friend A said: "Your APP is pretty good, but I'm already using Keep. Why would I switch?" + +Friend B said: "You want me to record every workout — that's too much trouble. I'm too lazy to do that." + +Friend C was more direct: "The free features are enough. Why would I pay?" + +These answers made Xiao Ming suddenly understand where the problem was. + +**First problem: Users won't switch because existing solutions are already good enough.** Mature products like Keep already have comprehensive features, and users have formed habits. The switching cost is high. Why would users switch to your similar product? + +**Second problem: Users aren't willing to change habits.** Recording workouts is too troublesome for users. If a product requires users to change more than 3 habits, it will likely fail. + +**Third problem: Too many free alternatives.** Your features are too generic with no unique value. Users can't find a reason to pay. + +### What is a Real Need? + +Xiao Ming started studying successful products that make users willing to pay. He found a common point: these products don't solve "I think it's useful" needs, but needs that users are willing to pay for, willing to change behavior for, and willing to endure inconvenience for. + +In other words, **real needs are voted on by users with their feet, not dreamed up by product managers.** + +### Case Studies: Products That Make Users Pay + +Xiao Ming studied several successful cases, trying to understand what pain points they really captured. + +#### Meicai: Let Small Restaurant Owners Sleep Better + +On the surface, what Meicai does is simple: help restaurants buy vegetables. But if you think carefully, why would restaurant owners use it? + +Because small restaurant owners have to get up at 4 AM every day to go to wholesale markets. It's exhausting, and they often get cheated. What Meicai does isn't simple "e-commerce selling vegetables" — it restructured the entire supply chain, letting small restaurant owners sleep better. + +The more painful the pain point, the stronger the willingness to pay. The time and energy saved is more valuable than the money saved on vegetables. + +#### Xiaohongshu: Solving Choice Paralysis + +On the surface, Xiaohongshu is "sharing overseas shopping experiences." But why are users willing to spend time reading notes on it? + +Because facing a sea of products, users don't know what's worth buying and what isn't. They need someone they trust to help them filter, save time, and avoid pitfalls. + +What Xiaohongshu really solves are two deep pain points: choice paralysis and lack of trust. Users are willing to pay for "saving time" and "avoiding pitfalls" — that's why Xiaohongshu succeeded. + +--- + +After seeing these cases, Xiao Ming had an important discovery. + +Users never pay for "features" — they pay for "solving fear" and "eliminating anxiety." Meicai solves small restaurant owners' fear of the hardship of early morning procurement. Xiaohongshu solves users' fear of buying the wrong things. + +**Fear drives payment. Anxiety drives action.** + +### Three Layers of Needs: Pain Points, Delight Points, Itch Points + +Xiao Ming researched further and found that user needs can be divided into three types: + +::: tip Pain Point — Fear Driven + +**Essence:** Problems users are currently experiencing that make them feel pain, anxiety, or inconvenience. Not solving them causes significant discomfort, or even threatens survival or safety. + +**Examples:** +- Diabetics don't know how many carbs will spike their blood sugar (Fear: Health threat) +- Small restaurant owners get up at 4 AM to go to wholesale markets (Fear: Survival hardship) + +**Key:** Users are willing to pay for this because not solving it is "very painful." + +::: + +::: tip Delight Point — Instant Gratification + +**Essence:** Users have a need that can be immediately satisfied, producing instant pleasure. + +**Examples:** +- Food delivery in 30 minutes (Instant satisfaction of hunger) +- One-click generation of beautiful PPT (Time-saving and effort-saving delight) + +**Key:** Making users "delighted" is key to retention, but as a standalone payment point it's weak. +::: + +::: tip Itch Point — Virtual Self + +**Essence:** Users want to become better, cooler, more refined, but it's not necessary. Satisfying it makes them happy; not satisfying it is fine too. + +**Examples:** +- Recording how much water you drink each day (Imagined disciplined life) +- Using AI to add artistic filters to photos (Imagined artistic taste) + +**Key:** Users have weak willingness to pay for "itch points" because not solving it doesn't matter. + +::: + +What's the correct priority ranking? A good suggestion is: Pain Points > Delight Points > Itch Points + +Why? + +1. **Pain points are survival needs:** Not solving them means death (or great discomfort). Users have to pay. They're "painkillers." +2. **Delight points are instant rewards:** Make users delighted, and they'll come. They're "heroin" (in the positive sense of addictive mechanisms). +3. **Itch points are desire satisfaction:** Nice to have, easiest to cut. They're "vitamins" or "luxury goods." + +**Key Insight:** Many product managers make the mistake of marketing itch point products using pain point methods. + +For example: "Recording water intake will make you healthier" — drinking water is indeed healthy, but not recording it won't make you unhealthy. This is packaging an itch point as a pain point. Users won't buy it. + +### 5-Step Method to Validate Real Needs + +Xiao Ming thought: **When I have an idea, how do I quickly judge if it's worth investing in?** + +He learned the 5-step judgment method commonly used by product managers (detailed content in Appendix A): + +1. **Step 1: Talk directly with real users to understand their current approach** + + Find 10 target users. Ask them: "How do you currently solve this problem?" If users are already using some method, the problem really exists. If users say they don't need to solve it, it might not be a real need. + +2. **Step 2: Analyze users' existing alternatives and find your advantages** + + Users might currently use other products, Excel, rely on memory, or just endure without solving. You need to figure out the drawbacks of these solutions. Your product needs to be much better than them for users to switch. + +3. **Step 3: Test if users are willing to pay for your product** + + Do pre-sales or collect deposits. Count the percentage of users willing to pay deposits (earning money early indicates correct need): + - Over 10%: Need is real, worth investing + - 5% to 10%: Need exists but needs refinement + - Below 5%: Need might not be valid + +4. **Step 4: Estimate how big this market is and if it can make money** + + Calculate three numbers: Total target users × Willingness to pay × Average transaction value. Multiply them to get market size. If the market is too small, it might not be worth doing. + +5. **Step 5: Think about what moat your product has to prevent copying** + + Consider these barriers: Technical difficulty, network effects, brand, cost advantages. These can help you maintain competitiveness long-term. + +**Act Summary: Xiao Ming's Takeaways** + +1. **Standards for Real Needs** + - The most important standard is users are willing to pay. + - Users are willing to change behavior for it. + - Without a solution, users would suffer significant loss. + +2. **Avoid Fake Needs** + - Itch points aren't pain points; they can't be treated as real needs. + - Markets that are too small can't support a business model. + - Solutions more complex than the problem will be abandoned by users. + +3. **Priority Ranking** + - The real priority is: Pain Points > Delight Points > Itch Points. + +**Act Output** +- I understand what real needs are. +- I've mastered the three-layer classification of needs: pain points, delight points, itch points. +- I've learned the 5-step judgment method to validate needs. + +--- + +## Act 2: Digging Out Great Ideas + +Xiao Ming now knows what real needs are, but he still doesn't know where to start. He can't just imagine a need out of thin air, right? + +He decided to start from what he knows best — the people and things around him. + +### Start from Yourself: Xiao Ming's Sister + +Xiao Ming thought of his sister. She just had a baby and keeps complaining about having no time to exercise. She can't lose the belly fat and is very anxious about it. + +One day Xiao Ming asked her: "How are you currently solving the fitness problem?" + +His sister sighed and said: "I follow Keep, but those exercises aren't suitable for postpartum bodies. After doing them, my lower back hurts even more. Go to a gym? No one to help watch the baby. Hire a personal trainer? One session costs 300-500 yuan, too expensive. Exercise blindly on my own? I'm afraid of getting injured." + +After hearing this, Xiao Ming felt this might be the real need he was looking for. + +His sister's troubles are actually quite specific: Fragmented time, needs to care for the baby, no uninterrupted time for exercise; Physical limitations, diastasis recti, pelvic floor muscle laxity, can't do intense exercise; Psychological anxiety, body shape changed, worried husband will dislike it, socially insecure; Information is too chaotic, too much information online, don't know what exercises are suitable for postpartum; And loneliness, no one understands their situation, lack of peer support. + +These are all real pain points, not "nice to have" itch points. + +--- + +### Horizontal Segmentation: Needs of Different User Groups + +Xiao Ming realized that the "fitness APP" idea was too broad. He wanted to help everyone exercise, but the problem is, everyone's needs are different. + +He did a horizontal segmentation, dividing "people who want to exercise" into several categories (detailed method in Appendix B): + +Fitness muscle-building crowd needs precise protein intake calculation, manual recording is too troublesome, their willingness to pay is high, pursuing efficiency. Diabetics must strictly control carbs, but it's hard to estimate when eating out, this is a rigid need, willing to pay, high repurchase rate. Postpartum moms want to recover their figure but don't have time to calculate, need simple solutions, time-sensitive, need one-stop service. Food delivery crowd eats takeout every day not knowing how many calories consumed, this is a high-frequency scenario, but medium willingness to pay. Graduate exam students need efficient study tools but don't know what to use, this is a rigid need, but low average transaction value. + +Xiao Ming chose the "postpartum moms" group. Why? + +First, he himself is a user — his sister is a postpartum mom, so he naturally understands this group's pain points. Second, the pain point is very painful — postpartum recovery anxiety is real, not a "nice to have" itch point. Third, strong willingness to pay — moms are willing to spend money to recover their figure. Fourth, relatively less competition — there's no product specifically for postpartum moms on the market. + +::: tip Product Manager's Segmentation Logic + +Why is segmenting user groups so important? + +Because generic tools are hard to win. Big platforms have already occupied the "generic" market, and it's hard for you to surpass them in features. Specific user groups have more painful needs — postpartum moms' need for exercise is a rigid need, while regular exercisers just think "it would be nice." Serving a small group well is easier than pleasing everyone to build reputation. Specific user groups' pain points are more concrete, and they're more willing to pay for solutions. + +::: + +--- + +### Vertical Deep Dive: Complete User Scenarios + +After finding the user group, Xiao Ming didn't stop at the single function of "postpartum exercise." He wanted to understand users' complete scenarios more deeply (detailed method in Appendix C). + +He observed his sister's day. + +6 AM, the baby just fell asleep, sister has 30 minutes free. She wants to exercise but fears waking the baby, and doesn't know what movements are safe. + +10 AM, sister is holding the baby to sleep, her lower back is sore. She wants to do some recovery exercises but her hands are occupied. + +3 PM, baby is sleeping, sister wants to exercise. But her body is tired, doesn't know if she can still do it. + +8 PM, sister finally has time but is very anxious. Looking at herself in the mirror, feeling like life is over, secretly crying while looking at old photos. + +Xiao Ming discovered that his sister's pain point isn't "no fitness courses" but "fear and anxiety about postpartum recovery." + +--- + +::: info Product Manager's Scenario Thinking + +Many people think pain points are just functional requirements, but they're not. Pain points are emotions in scenarios plus willingness to pay. + +When postpartum moms face their changed bodies in the mirror, the real pain point isn't "not knowing how to exercise" but fear — worrying about not recovering well, leaving sequelae; Anxiety — looking at themselves in the mirror, feeling like life is over; Helplessness — not knowing where to start, no one to guide; Loneliness — others give birth easily, but I have to recover for so long. + +Good product design solves emotions, not just functions. Behind emotions is the user's motivation to pay. + +::: + +--- + +### Value Reconstruction: From "Fitness APP" to "Postpartum Mom Recovery Assistant" + +Based on the above analysis, Xiao Ming redesigned this product. + +::: tip Reconstructed Product Concept: "Postpartum Mom Recovery Assistant" + +**Core Positioning:** Not just a fitness tool, but a "personal rehabilitation coach + psychological supporter" for postpartum moms + +**Core Features:** +1. **Fragmented Training:** + - Each session only needs 10-15 minutes + - Can exercise when baby is sleeping + - Provides movements that "can be done while holding the baby" + +2. **Postpartum-Specific Courses:** + - Graded by postpartum stage (0-3 months, 3-6 months, 6+ months) + - Specialized training for diastasis recti, pelvic floor muscle repair + - Every movement has "postpartum precautions" reminders + +3. **AI Movement Correction:** + - Phone camera recognizes movements + - Real-time reminders like "knees too bent," "back should be straight" + - Avoid injury from incorrect movements + +4. **Psychological Support Community:** + - Private community only for postpartum moms + - Share recovery progress, encourage each other + - Professional psychological counselors on board + +5. **Personalized Plans:** + - Customized based on delivery method (natural/C-section), physical condition + - Considers special needs during breastfeeding + +**Business Model:** +- Basic courses free +- Advanced courses: 99 yuan/month (includes AI movement correction, personalized plans) +- One-on-one coaching: 299 yuan/month (online guidance) +- Community membership: 199 yuan/year (includes psychological support, expert Q&A) + +**Competitive Barriers:** +- Professionalism: Partnership with postpartum recovery institutions, medical endorsement +- Community stickiness: Postpartum moms' emotional connections are strong +- Data accumulation: More user body data means more precise plans + +**Market Size:** +- China has about 10 million newborns annually +- Postpartum recovery market is about 50 billion yuan +- Target: Serve 1% of postpartum moms = 100,000 users +- ARPU (Average Revenue Per User): 500 yuan/year +- Potential revenue: 50 million yuan/year + +::: + +Comparing the original idea with the reconstructed concept: + +| Dimension | Original Idea | Reconstructed | +|------|---------|--------| +| Target Users | All fitness groups (broad) | Postpartum moms (precise) | +| Pain Point Solved | Recording workouts (itch point) | Postpartum recovery anxiety (pain point) | +| Competitive Barrier | Technology (easily copied) | Professionalism + Community + Data | +| Willingness to Pay | Low (many free alternatives) | High (rigid need + emotional value) | +| Expansion Space | Limited | Can expand to pregnancy, pre-pregnancy | + +**This is the evolution from "a feature" to "a product people pay for."** + +--- + +### More Examples: From Ordinary Ideas to Great Ideas + +Xiao Ming found this method very useful. He used the same method to analyze several other examples, wanting to see if this method is universally applicable (detailed cases in Appendix D). + +#### Example 1: From "Calorie Measurement" to "Diabetics Eat with Peace of Mind" + +The ordinary idea is photo recognition of food calories, helping people who want to lose weight control their diet. But the problem is there are already mature products like Bohe Health and MyFitnessPal on the market. + +Xiao Ming did a horizontal segmentation and found the diabetic group interesting: They must strictly control carbs, but it's hard to estimate when eating out. Deep diving into their scenarios: Before meals, don't know if this dish can be eaten, worried about blood sugar spikes; During meals, need real-time reminders "how many carbs you've already had"; After meals, need to record blood sugar changes to see the relationship with diet. + +The reconstructed product is called "Diabetics Eat with Peace of Mind," positioned as a "dietary safety assistant" for diabetics. + +--- + +#### Example 2: From "News Assistant" to "Investment Research Intelligence Officer" + +The ordinary idea is aggregating news from various platforms, saving the trouble of opening them one by one. But Toutiao, Tencent News, etc., already do this well. + +Xiao Ming horizontally segmented and found the investment research group: They need to track industry dynamics, but information is scattered; Need to quickly filter valuable information from massive news; Need to correlate news with stock price movements. + +The reconstructed product is called "Investment Research Intelligence Officer," positioned as an "intelligent assistant for investment researchers." + +--- + +## Act 3: AI Dialogue Refinement + +After finding the direction, Xiao Ming didn't rush to code. He knew that a good idea also needs a clear execution plan. + +He decided to use AI to help him refine the product concept. + +### Using AI to Refine Product Concepts + +Xiao Ming opened ChatGPT and entered the following prompt: + +``` +I want to create a "Postpartum Mom Recovery Assistant" product. +Target users: Postpartum moms within 1 year +Core pain point: Want to recover figure but no time, don't know how to exercise safely +Main features: +1. Fragmented training (10-15 minutes per session) +2. Postpartum-specific courses +3. AI movement correction +4. Psychological support community + +Please help me refine: +1. Is this product concept complete? What's missing? +2. What should be the MVP (Minimum Viable Product) features? +3. What are the potential risks and challenges? +4. How to validate market demand? +``` + +AI gave detailed suggestions: + +**1. Product Concept Completeness Analysis:** +- Missing: User acquisition channels, retention mechanisms, monetization path +- Suggestion: Add referral mechanism, achievement system, tiered membership + +**2. MVP Features:** +- Core: 10 postpartum recovery courses + simple movement guidance +- Don't need: AI movement correction (high technical difficulty, can be added later) +- Don't need: Community (need user base first) + +**3. Potential Risks:** +- Medical compliance risk: Postpartum recovery involves medical knowledge +- User trust: Why would users trust your courses? +- Competition: Keep might add postpartum features + +**4. Market Validation Methods:** +- Create a landing page, collect interested users' emails +- Interview 20 postpartum moms, understand their real needs +- Pre-sell course packages, test willingness to pay + +### Using AI to Generate Business Plans + +Xiao Ming continued to ask AI: + +``` +Based on the above analysis, please help me generate a simple business plan, including: +1. Product positioning and target users +2. Core features and MVP scope +3. Business model and monetization path +4. Market validation plan +5. Risk assessment and countermeasures +``` + +AI generated a structured business plan that Xiao Ming could directly use to communicate with potential partners or investors. + +--- + +## Summary: The Complete Methodology for Finding Great Ideas + +Through Xiao Ming's story, we learned a complete methodology: + +### 1. Establish Judgment Criteria +- Real needs = Users willing to pay + willing to change behavior + significant loss without solution +- Priority: Pain points > Delight points > Itch points + +### 2. Discover Pain Points +- Start from yourself and people around you +- Horizontal segmentation: Find specific user groups +- Vertical deep dive: Understand complete user scenarios + +### 3. Validate Needs +- Talk to real users +- Analyze existing alternatives +- Test willingness to pay +- Estimate market size +- Consider competitive barriers + +### 4. Refine Product Concept +- Use AI to help refine ideas +- Define MVP scope +- Develop business plan +- Plan market validation + +### Key Takeaways + +1. **Direction is more important than effort** — Wrong direction, the more you do, the more wrong +2. **Real needs are voted by users** — Not imagined by product managers +3. **Segmentation is key** — Serving a small group well is better than pleasing everyone poorly +4. **Validate early** — Don't invest heavily before validating demand +5. **AI is your assistant** — Use AI to refine ideas, but the final judgment is yours + +--- + +In the next chapter, we'll take our validated ideas and start learning how to use AI IDE to turn them into interactive product prototypes. diff --git a/docs/en/stage-1/1.1-introduction-to-ai-ide/index.md b/docs/en/stage-1/1.1-introduction-to-ai-ide/index.md index 0059bf5..07d67ba 100644 --- a/docs/en/stage-1/1.1-introduction-to-ai-ide/index.md +++ b/docs/en/stage-1/1.1-introduction-to-ai-ide/index.md @@ -244,8 +244,8 @@ China version download: https://www.trae.cn/ ##### Trae Pricing and Usage Options -::: info 💡 Version Selection Tips -- If you're primarily using it in China, we recommend choosing the China version for more stable network access and support for domestic large models +::: info 💡 Version Selection Tips (CN Version Recommended for Beginners) +- **For beginners, we strongly recommend downloading the China version (CN version, trae.cn)** — it currently provides a better overall experience and is free to use, with no overseas network required - If you need to use overseas models like GPT-5 and your network conditions allow it, you can choose the international version - If you already have a third-party model API Key, connecting third-party models gives you flexible cost control ::: @@ -256,11 +256,11 @@ China version download: https://www.trae.cn/ Regarding Trae's costs and usage options, here are several choices: -- **China Version (Recommended)**: Basic usage is free, but due to high user volume, you may need to wait in a queue. +- **China Version CN (Strongly Recommended)**: Basic usage is free, and it currently provides a better overall experience than the international version — ideal for beginners. Due to high user volume, you may occasionally need to wait in a queue. - **International Version**: Subscription costs about $3 per month, giving access to overseas models like GPT-5, but requires overseas network access. - **Third-party Model Integration**: If you already have a Token API from a domestic large model provider (such as DeepSeek, Tongyi Qianwen, Kimi, etc.), you can connect these APIs through Trae's third-party model configuration. Major cloud service providers (such as Alibaba Cloud, Tencent Cloud, Baidu Cloud, etc.) typically offer Coding Plan subscriptions that let you use their large model APIs at more favorable prices. This way you can freely choose your preferred model while controlling costs. -We recommend beginners start with the free China version. If you encounter queuing issues or need more stable service, consider connecting a third-party model and purchasing the corresponding cloud provider's Coding Plan. +We recommend beginners start with the free China CN version (download: https://www.trae.cn/), which currently offers a better experience and is completely free. If you encounter queuing issues or need more stable service, consider connecting a third-party model and purchasing the corresponding cloud provider's Coding Plan. #### 4.1.3 Trae Interface Overview diff --git a/docs/en/stage-1/1.2-building-prototype/index.md b/docs/en/stage-1/1.2-building-prototype/index.md new file mode 100644 index 0000000..ed9c632 --- /dev/null +++ b/docs/en/stage-1/1.2-building-prototype/index.md @@ -0,0 +1,505 @@ +--- +title: 'Building Prototypes - From Business Analysis to Multi-page Product Prototype Implementation' +description: 'Experience the complete loop from business analysis to multi-page product prototype implementation. Learn how to ask business questions, break down requirements, use AI IDE to generate single-page and multi-page applications, and beautify and test prototypes.' +--- + + + +# Beginner Level 3: Building Prototypes + +## Chapter Overview + + + +In the previous chapter, we learned how to find great ideas — starting from user needs to find directions people are willing to pay for. But finding direction is just the first step. What really tests a product manager is: how to turn vague needs into usable products. + +This chapter solves a real problem: Your boss gives you a vague but high-pressure task: "Use AI to improve the efficiency of publishing products to e-commerce platforms" — how do you turn this into a usable product prototype? + +Unlike building Snake or calculators before, real business can't just imagine features: + +1. Clarify pain points: Talk to operations, dig out the real pain points from the vague "improve efficiency" +2. Prioritize: Among many problems, solve the most painful one first, don't try to do everything at once +3. Quick validation: Use AI IDE to build a single-page prototype first, then expand to multi-page after it works +4. Make something usable: Finally deliver an e-commerce material workbench that can be demonstrated and operated + +We'll learn the transition from making toys to making applications, and learn to empathize and think about customers' real needs. + + + +::: info Note +This chapter may contain some business terminology. If you don't understand something, you can ask AI for an explanation. +::: + +
+ + + +
+ +## 1. Define Requirements Before Coding + +In previous tutorials, we used AI IDE to easily generate Snake and various mini-games, but these are just toy projects that can't be applied in work and life. If we want AI capabilities to truly serve everyone, we should combine vibe coding with real life and work scenarios. + +In the last chapter, we learned how to find great ideas that people are willing to pay for, but finding direction is just the beginning. When actually building products, you'll discover: there's a huge gap between knowing "what to do" and knowing "how to do it." + +This gap is the concretization of requirements. + +For example, in classes or personal projects, we often start with the simplest executable features: + +- "Make a kanban board, list the tasks." +- "Help me make a drawing tool." +- "Help me make a software that can collect questionnaires." + +These are often just a tool, a feature module, not even a clear business problem. More critically, these ideas are often just "you think it's useful," not "users really need it." + +In enterprise projects or startup projects, product managers and engineers often start from larger business propositions. For example, let's assume such a scenario: + + +
Business Scenario:
+
+

You are an e-commerce operations product manager at a store. Your boss gave you a vague but high-pressure proposition:

+

"Now everyone on WeChat is using AI to make images and copy, it looks pretty simple. Help me set this up so we can be more efficient when listing new products on Douyin e-commerce."

+
+
+ +At this point you might think: "Boss, you're dreaming again!" However, such vague one-sentence decisions are very common in actual work, even more frequent than your weekly bubble tea orders. Therefore, to be a qualified workplace worker (I'd rather you be the CEO of an emerging startup), we must learn how to transition from making tools for personal use to making real product prototypes. + +Since we've learned AI IDE, you think about it and this requirement is actually quite simple — just let AI give a prompt based on this, throw it to the Agent and we're done, right? + +``` +Please refer to my requirements xxxx, +Help me design an e-commerce material workbench, +Including generation and management functions for product descriptions, images, videos, and other materials. +``` + +If you excitedly convert this requirement directly into a prototype and send it to your boss — congratulations, this quarter's bonus is cancelled! + +**Why is this? This is the core pain point we need to solve:** + +Previously when learning AI IDE, we made toy projects for personal use like Snake and calculators — simple features, you know what you want, make it for yourself. But **real business scenarios are completely different**: + +- **You're not the user**: The boss wants "improved efficiency," but you don't know how operations works daily or where they're stuck; +- **AI doesn't understand business either**: You throw a vague requirement to AI, it can only guess based on general knowledge. What it makes looks right but actually doesn't work; +- **Good ideas ≠ good products**: You think "adding an AI generation feature" is cool, but users might not need it at all, or it's more troublesome than before. + +**That's why we must learn "from thinking of ideas to understanding users"** Only when your creativity truly solves others' problems, ask questions and deeply understand the business, can you make something truly valuable. (Good ideas are even more important than good technology) + +### 1.1 From Imagination to Reality: Learn to Ask Business Questions + +::: info First, let's clarify: What are requirements? What is business? + +**Requirements** are what users really want, the troubles they encounter, the problems they want to solve. For example, "The boss wants me to list products faster" — this is a requirement. + +**Business** is what users actually do every day, their way of working. For example, what e-commerce operations does daily: listing products, changing prices, making images, looking at data... these are all business. + +**Why care about business?** +Because if you don't understand the business, the tools you make might be "look good but nobody uses them." Only by truly understanding how users work daily and where they're stuck can you make something that really helps them. + +::: + +From the simplest perspective, you can first ask yourself a few questions: + +- The boss says "**improve efficiency a bit**" — what does that specifically mean? **Do it faster**? **Spend less money**? **Sell more goods**? +- How are products currently listed? **Where is it not smooth**? +- How many **new products** need to be done daily? How many **images** and how much **text** per product? +- In current work, **which task is most troublesome**, **most unwanted**? + +But these are all guessed questions. We need to ask the frontline Douyin e-commerce business people directly, "Where are your difficulties and concerns?" Get more accurate answers through communication: + +::: info Real Business Interview Results + +We asked people doing e-commerce operations, and they mentioned these troubles: + +**1. Too many things, too scattered** +- One person manages several stores, each store has many products to handle; +- Busy all day: **listing new products**, **changing prices**, **making images**, **looking at data** — one thing not finished before another starts. + +**2. Content creation isn't done once, but iteratively** +- First use **manufacturer-provided images**, **previously used materials** or **reference images found online**, quickly **list** products to test; +- Spend a little money on promotion, **see if anyone buys**; +- Only for **products that sell well** will they seriously make images, write details, shoot videos. + +::: +After interviewing the business side, we feel passionate because now we can truly make a product prototype that perfectly fits the business! — Wrong again. If we try to "satisfy all demands at once," the product will be very large and hard to implement within the course timeframe. Therefore, we need to further organize and converge, finding the real core pain points. + +### 1.2 From Divergence to Convergence: Lock in Core Business Pain Points and Features + +::: info Why "converge"? What is a "pain point"? + +**Many problems, but which one to do first?** + +Users might tell you a bunch of problems: A is troublesome, B is troublesome, C is troublesome... But if you try to solve all problems at once, you might end up doing nothing well. So you need to **converge** — from a pile of problems, pick the **most painful, most urgent, most solvable** one to start with. + +**What is a pain point?** +It's the specific problem users **find most annoying, most time-consuming, most want to solve**. Not "I think it's useful," but what users **complain about every day, find painful every time they do it**. + +::: + +Through the interview above, we found operations has many problems: interrupted rhythm by activities, managing multiple stores, busy going back and forth between listing/pricing/images/data... + +If we try to "solve all these problems," we'll end up with a **comprehensive but hard-to-use tool**. + +Let's categorize these problems (you can have AI help), roughly three types: + +1. **Rhythm problems**: When to list, when to adjust prices; +2. **Efficiency problems**: How to manage multiple stores and products simultaneously; +3. **Content problems**: How to quickly create product images and copy. + +For our course, the most suitable to solve first is **the 3rd type: content creation problems**. But "quickly create content" is still a bit abstract. Let's ask the business side specifically where they're stuck: + +::: info Business Side Says: Two Most Painful Parts of Content Creation + +**Pain 1: Batch creating images and copy is too much effort** +- Materials scattered everywhere: cloud drives, WeChat records, platform backends... **finding them is a hassle**; +- Need to list many products at once, **no time to carefully craft each one**, can only throw something together; +- Requirements aren't high, **presentable and listable is fine**, doesn't need to be fancy. + +**Pain 2: Good solutions can't be saved for reuse** +- Previously made good titles and layouts, **can't find them next time**; +- Solutions scattered in chat history, old product links; +- When needed, have to **dig through everything, copy-paste and edit for ages**; +- Lacking a tool that can **collect, manage, and directly apply**. + +::: + +Based on these two pain points, we want to make a simple little tool: **Help operations batch create images and copy, and save good solutions for direct reuse next time**. + +It only does two things (you can have AI help refine, remember to keep deleting features based on business feedback): + +::: info Feature 1: Batch Generate E-commerce Product Images and Copy + +**What does this do?** +Give the system some product information, and it automatically generates product images and text that can be used for listing on e-commerce platforms (like Douyin, Taobao). + +**Input** +| Type | Content | +|------|------| +| Product Information | Name, category, brand, material, size, color, etc. | +| Product Images | White background or simple scene images | +| Reference Images | Screenshots of previously best-selling products or reference links | +| Import Method | Batch import via Excel, or fill in directly on the page | + +**Output (Generated E-commerce Materials)** +- **Product Main Image**: Product display image with text selling points (first image users see when scrolling) +- **Product Title**: Keyword combination that can be searched +- **Selling Point Copy**: 1-2 sentences to attract buyers +- All are **finished products that can be listed with minor edits** + +**Effect** +- Before: Every product had to start from scratch making images and writing copy +- After: Throw a batch of products into the system, generate drafts, then pick and edit + +::: + +::: info Feature 2: Save Good Solutions as Templates + +**Input** +| Type | Content | +|------|------| +| Complete Set | Main image + Title + Copy | + +**Output** +| Function | Description | +|------|------| +| Apply | Use template to auto-generate for new products | +| Edit | Directly modify title, modify copy | +| Manage | Name, tag (like "men's bag template", "promotion title"), easy to find | + +**Effect** +1. Import new product +2. Choose: Let system generate by default, or **use my saved template** +3. System automatically applies template style, outputs new images and copy + +::: + +--- + +**Review what we just did:** + +1. **Asked questions first**: Didn't start building directly, but first asked operations "what annoys you most"; +2. **Found pain points**: Discovered their most painful parts are "making images and copy is too much effort" and "good solutions can't be saved"; +3. **Converged scope**: Not making a comprehensive platform, just these two features: "batch generate images and copy + save templates". + +**Why is this important?** + +Many beginners' misconception about product building is: more features is better. But what users really need is **to solve the most painful problem**. Making a bunch of features that don't work well is worse than making one or two features that really help users. + +**Core of Product and Business Thinking:** +- Don't think for yourself "I think users need what" +- Ask users "What do you do every day? Where is it most painful?" +- From a pile of problems **converge** to the most painful, most solvable one +- First make a **minimum viable** version, then slowly iterate + +This is what we need to figure out before writing code. Code is just a tool; **understanding users and finding the right problem** is the first step. + +
+ + + +
+ +## 2. Generate Prototype in 10 Minutes: Let AI IDE Implement "Core Gameplay" + +::: info Programming Plan Suggestion +If you feel the current IDE isn't smart enough, or you run out of quota quickly, you can buy a **programming Plan**. Preview in advance by referring to [this article](../../stage-2/backend/2.6-modern-cli/extra7/) for programming with Claude. +::: + +Thinking is good, but don't overthink. Let's control excessive reflection and try making a prototype starting from a single page. + +### 2.1 First Step: Tell AI What You Want in Plain Language + +When starting out, don't pursue perfect prompts. Begin with your most natural expression. Just like describing requirements to a colleague, tell AI in plain language what you want to do, then let AI help you optimize it into a more professional expression. + +#### 2.1.1 Start from Verbal Description (Recommended for Beginners) + +First describe your idea in your own words, even if it's rough, that's fine: + +``` +I want to make a tool that helps e-commerce operations automatically generate product main images and copy. +Operations usually have to manually make images and write copy one by one, which is very troublesome. +My idea is: they upload product information, the system automatically generates a batch of drafts, +operations pick the good ones and make minor edits before using. + +First make the simplest version: one page, fill in product info on the left, +display generated results on the right. Can upload images, can fill in text, +after generation show main image preview and copy. +``` + +Next, send this text to AI (like ChatGPT, Claude, etc.) and let it help you expand. AI usually helps you add details you didn't consider, organizes your ideas more clearly, and finally generates a prompt suitable for sending to AI IDE. + +You can say this to AI: +``` +Help me expand the above idea, organize it into a clear business logic document, +then generate a prompt suitable for sending to AI IDE (like Cursor, Trae), +for generating single-page application prototype code. +``` + +AI will return a structured requirement and corresponding prompt. You check it yourself, delete unnecessary features, and after confirming it's correct, use it to generate code. + +The benefit of doing this: verbal descriptions are the most authentic ideas, but might miss some important details. When AI helps you expand, it might ask "do you want to support batch upload?" — questions you didn't think of, helping you further validate. You can choose to keep or delete impractical features based on feedback, and through repeated modifications determine the first version prompt to give AI. + +#### 2.1.2 Skip the Expansion Step: Directly Throw Your Organized Business Document to AI + +If you've already organized the business logic document in previous chapters (like a requirements description written in plain language), you can directly use the format below to send to AI IDE, skipping the intermediate step of having AI expand. Suitable when requirements are already clear and you want to start coding directly: + +``` +Help me implement a single-page application based on business logic, for validating core gameplay functionality. + +Business logic reference: +1. Help operations batch generate first version of image and text drafts: +- **Input (supports direct upload and batch import of materials):** + - Product basic info: name, category, brand, material, size, color, applicable人群, etc.; + - Product images: white background / simple scene images; + - Each generation supports uploading additional historical bestseller screenshots or reference links, allowing for reference materials; + - Supports batch import via Excel, or online entry/upload on the page. + - Supports specifying on the page whether to save product materials to the material library for next time use +- **Output (content that can be directly listed or listed with minor edits):** + - Each product gets one "presentable, containing basic selling points" main image draft; + - One "reasonably structured, containing core keywords" title + 1-2 sentences of selling point copy. +- **Expected usage change:** + From starting from scratch for each batch of products to throwing a batch of products into the system, taking the system-generated drafts for filtering and minor adjustments. + +First make the first feature, the second feature (template library) will be added later. +``` + +#### 2.1.3 Programmer's Approach (Advanced): Let AI Help You Write "Prompts for Prompts" + +If you want more fine-grained control over the code generation process, you can first have AI (like ChatGPT) generate a prompt specifically for AI IDE based on your requirements: + +``` +Based on the idea below, help me write a prompt for a coding Agent, +I need to use this prompt to generate code. + +[Paste your business logic description here] + +Requirements: +1. The prompt should include clear page layout descriptions +2. Clarify data structures and interaction logic +3. Specify tech stack (like React + Tailwind) +4. List core functionality points to implement +``` + +Usually AI will generate a structured prompt like below: +![](../../../zh-cn/stage-1/1.2-building-prototype/images/index-2026-01-14-14-25-56.png) + +You can slightly modify this prompt, then send it to AI IDE to generate code. + +### 2.2 Second Step: Let AI IDE Directly Generate Code + +#### 2.2.1 Preparation: Understand AI IDE Basic Operations + +If you're not yet familiar with the basic usage of AI IDE (like Cursor, Trae, Windsurf, etc.), it's recommended to first check the [IDE Basics Tutorial](/zh-cn/appendix/2-development-tools/ide-basics/) in the appendix to understand how to: +- Create new projects +- Dialogue with AI Agent +- Understand AI's code generation process + +#### 2.2.2 Start Generating Code + +At this point you've obtained the initial prompt. Let's use the first prompt style as an example, letting AI help us generate code. First create a window and corresponding folder, open the folder (initialize a new project in your favorite folder location): +![](../../../zh-cn/stage-1/1.2-building-prototype/images/index-2026-01-14-14-28-44.png) +![](../../../zh-cn/stage-1/1.2-building-prototype/images/index-2026-01-14-14-30-00.png) + +In the sidebar, select a model you like (recommend gemini, gpt, glm, kimi, minimax, etc.), enter the prompt obtained in the first step: +![](../../../zh-cn/stage-1/1.2-building-prototype/images/index-2026-01-14-14-31-41.png) + +After clicking generate, we'll see a familiar process. AI will plan the project's directory structure, necessary files, and give initial content for each file based on the prompt. + +::: warning Special Note: AI Might Stop and Wait for Your Confirmation +During generation, AI Agent often **stops to wait for your input or confirmation**, for example: +- Asking if you want to continue to the next step +- Having you press Enter to confirm an operation +- Asking about your choice for a technical detail + +**If you see AI isn't moving, first check the dialogue interface to see if it's waiting for your reply.** Many beginners think AI is thinking, but it actually stopped waiting for you long ago. Reply actively or press Enter, and AI will continue working. +::: + +At this point, don't forget to press Enter to confirm information (otherwise it will be stuck waiting; some AI IDEs don't have this issue): +![](../../../zh-cn/stage-1/1.2-building-prototype/images/index-2026-01-14-14-33-03.png) + +If you encounter the following scenario, this means a service has already started locally. You need to click skip, otherwise it will stay on this interface (if nothing appears after code generation finishes, you need to actively say "help me start this project"): +![](../../../zh-cn/stage-1/1.2-building-prototype/images/index-2026-01-14-14-38-11.png) + +::: info Scenario Explanation +**Scenario Explanation**: You used `npm create vite@latest` to create a React + TypeScript project (easy-vibe-web). After creation, the computer will automatically "run" this webpage, making it convenient for you to see the effect immediately. + +**Local Service**: Can be understood as your computer temporarily opening a webpage display window, running only on your own computer, others can't access it. +::: + +--- + +**🎉 Congratulations! You've completed the first version of your prototype!** + +Now you can see the running effect in the browser. Next, we'll expand based on this foundation. + +
+ + + +
+ +## 3. Multi-page Expansion: From Single Function to Complete Application + +The single-page prototype has validated the core gameplay. Now we need to expand it into a complete application. + +### 3.1 Analyze Current Prototype's Shortcomings + +Reviewing our single-page prototype, we'll find some obvious issues: + +1. **No navigation**: Users can only see one page, can't switch between different functions +2. **No data persistence**: Refresh the page and all data is gone +3. **No error handling**: If something goes wrong, users don't know what happened +4. **No user feedback**: No prompts after operations, users don't know if they succeeded + +### 3.2 Design Multi-page Structure + +Based on the business requirements we analyzed earlier, we need the following pages: + +1. **Homepage/Dashboard**: Display task list, quick actions +2. **Product Management**: Add, edit, delete products +3. **Generation Page**: Core functionality - generate images and copy +4. **Template Library**: Save and manage templates +5. **Settings**: User preferences, API configuration + +### 3.3 Let AI IDE Help You Expand + +You can tell AI IDE: + +``` +Now I need to expand this single-page application into a multi-page application. +Please help me: +1. Add routing to support switching between pages +2. Create the following pages: + - Homepage: Display task list + - Product Management: CRUD operations for products + - Generation Page: The existing single-page functionality + - Template Library: Save and manage templates +3. Add navigation bar for page switching +``` + +AI IDE will help you complete these expansions. You just need to confirm and adjust. + +
+ + + +
+ +## 4. Beautification and Optimization: Make the Prototype More Professional + +A working prototype is just the first step. To make it impressive, we need to beautify and optimize. + +### 4.1 UI Beautification + +Tell AI IDE: + +``` +Please help me beautify this application: +1. Use a consistent color scheme +2. Add appropriate spacing and alignment +3. Improve button and form styles +4. Add hover effects and transitions +5. Ensure responsive design for different screen sizes +``` + +### 4.2 UX Optimization + +``` +Please help me improve the user experience: +1. Add loading states for all async operations +2. Add success/error notifications +3. Add confirmation dialogs for destructive actions +4. Improve form validation and error messages +5. Add keyboard shortcuts for common actions +``` + +### 4.3 Performance Optimization + +``` +Please help me optimize performance: +1. Lazy load images +2. Implement pagination for long lists +3. Add debouncing for search inputs +4. Optimize bundle size +``` + +--- + +## Summary + +In this chapter, we learned: + +1. **Requirements Analysis**: How to extract real pain points from vague business requirements +2. **Single-page Validation**: Quickly validate core functionality with AI IDE +3. **Multi-page Expansion**: Expand from single function to complete application +4. **Beautification and Optimization**: Make prototypes more professional and user-friendly + +**Key Takeaways:** + +- Don't start coding immediately — understand requirements first +- Start with the simplest version — validate before expanding +- Let AI help you — but you make the final decisions +- Iterate based on feedback — keep improving + +In the next chapter, we'll learn how to integrate real AI capabilities into our prototype. diff --git a/docs/en/stage-1/1.4-complete-project-practice/index.md b/docs/en/stage-1/1.4-complete-project-practice/index.md new file mode 100644 index 0000000..6171795 --- /dev/null +++ b/docs/en/stage-1/1.4-complete-project-practice/index.md @@ -0,0 +1,291 @@ +--- +title: 'Complete Project Practice - From Demo to Production-Grade Prototype' +description: 'Move beyond the Demo stage, learn how to complete product flows, build realistic simulated data, iterate quickly through feedback, and finally complete a presentable, interactive AI product prototype.' +--- + + + +# Beginner Level 5: Complete Project Practice + +## Chapter Overview + + + +In the previous chapter, we integrated AI capabilities. The Demo runs, but it's still far from a real "product": Refresh the page and data is gone, errors cause white screens, the list only has "test data 1, test data 2", users can't undo mistakes... + +This chapter will fill all these gaps: We'll complete the product's full flow, use AI to generate realistic business data to replace fake data, add error handling and user feedback, and finally polish a presentable prototype that can be demonstrated to others. + +This is the final chapter of the beginner stage. After completing this step, you'll have transformed from "can't program at all" to "can independently build AI product prototypes". + + + +
+ + + +
+ +## 1. Reject "Happy Path": Complete Core Flows + +Many beginners building prototypes often only do the "Happy Path" (the ideal path): User clicks -> API responds successfully -> Display result. +But in the real world, things often don't go that smoothly. To make your prototype look like a real product, you need to consider these "hidden" elements. + +### 1.1 Add "Waiting" and "Feedback" + +When users click "Generate Copy", AI often needs several seconds to respond. If the interface shows no reaction, users will think the program is broken. +**You need to let AI IDE help you add Loading states:** + +> Prompt example: +> "When I click the generate button, please change the button to 'Generating...' and make it unclickable, while showing a loading animation in the right area. Only restore to normal after the API returns results." + +### 1.2 Handle "Failures" and "Exceptions" + +API Keys can expire, networks can disconnect. +**You need to let AI IDE help you handle errors:** + +> Prompt example: +> "If the API request fails, don't just log an error in the console. Please pop up a red notification (Toast) at the top of the page telling the user 'Generation failed, please try again later', and allow users to click generate again." + +### 1.3 Conversation History Persistence + +During interaction with AI, we need to save conversation content so users can review history and continue previous conversations. At this stage, we won't introduce a database yet. We can choose from these lightweight solutions: + +**Storage Options:** + +| Option | Use Case | Characteristics | +| ------ | -------- | --------------- | +| **LocalStorage** | Pure frontend projects, user data saved in browser | Simple implementation, survives refresh, can't sync across devices | +| **JSON Files** | Local prototypes, data stored as files | Clear structure, easy debugging, manually editable | +| **TXT Files** | Simplest solution, quickly record text content | Free format, good compatibility | + +**Conversation Content Example:** +Saved conversation history typically includes: + +```json +[ + { + "role": "user", + "content": "Help me generate Douyin e-commerce copy for a Bluetooth headset", + "timestamp": "2026-01-20 10:30:00" + }, + { + "role": "assistant", + "content": "【Bluetooth Headset Product Copy】\n\n🎧 Say goodbye to lag, immersive music experience\n\nLadies! This Bluetooth headset is absolutely amazing👇\n\n✅ 40dB active noise cancellation, instantly enter music world\n✅ 30 hours ultra-long battery life, one week commute without charging\n✅ Crystal clear calls like face-to-face, can chat even on noisy subway\n✅ Semi-in-ear design, comfortable for long wear\n\n💰 Limited time offer, click the link below to get yours!", + "timestamp": "2026-01-20 10:30:05" + } +] +``` + +**Implementation Prompt:** + +> "Please help me implement conversation history saving functionality. Support saving user and AI conversation records as JSON files (or use LocalStorage). Automatically load historical conversations when entering the page, support viewing and deleting individual conversation records." + +
+ + + +
+ +## 2. Inject Soul: Simulate Real Data (Mock Data) + +An empty page can't impress anyone. Imagine showing your "E-commerce Material Workbench" to others, but the history is empty, or just has one line "test / test / test". +To make the demo effect best, we need to "fake" some realistic data to make your prototype look like a real product that's been running for six months. + +### 2.1 Let AI Help You Design Data Structures + +We don't need to think about what each field should be called ourselves (like whether it's `name` or `title`). This can be completely left to AI. + +You just need to tell AI your **business scenario**: + +> **Prompt Example:** +> "I'm building a **Douyin e-commerce material workbench** prototype. +> Please help me design a JSON data structure to describe a 'product task'. +> This task should include: product basic info (name, category), input materials (image links), and AI generated results (title, copy, poster image). +> Please give me a JSON example directly." + +AI will automatically help you conceive fields like `productName`, `generatedContent` based on your description. + +### 2.2 Let AI Batch Produce "Realistic" Data + +After having the data structure, the next step is letting AI help you "fill in the blanks" and generate a batch of realistic-looking data. + +**Prompt Techniques:** +You can't just tell AI "help me generate data". You need to tell it **business background** and **content requirements** like assigning tasks to an intern: + +- **Business Background**: Tell AI we're doing "Douyin e-commerce", so product titles should be eye-catching (like "slimming miracle", "students must-have"), copy should be conversational. +- **Image Requirements**: To make the prototype look good, images shouldn't be black-and-white placeholders. Best to use random colorful landscapes or product photos. + +> **Prompt Example:** +> "Based on the structure just designed, please help me generate 10 realistic mock data entries. +> (Note: Doesn't have to be JSON format. If you're writing frontend, have it generate JavaScript arrays directly; if using Python, have it generate Lists.) +> +> **Business Scenario Requirements:** +> +> 1. Assume this is a general merchandise store, products cover 'women's clothing', 'electronics', 'beauty' three categories. +> 2. **Generated titles and copy should be very 'Douyin style'**: Like titles should include Emoji (🔥, ✨), copy should use phrases like 'absolutely amazing', 'tested and works great'. +> 3. **Image fields**: Please uniformly use the format `https://picsum.photos/seed/{random_id}/300/400` to ensure each image is different." + +**Generated Mock Data Example:** + +```javascript +export const mockProductTasks = [ + { + id: 'task_001', + name: 'Summer French Vintage Floral Dress', + status: 'completed', + input: { + category: 'Women\'s Clothing', + features: ['Waist-cinching', 'Slimming', 'Elegant'], + originalImage: 'https://picsum.photos/seed/dress_input/300/400' + }, + output: { + generatedTitle: '✨Looks great on everyone! This French floral dress is absolutely amazing🔥', + generatedCopy: + 'Ladies! This dress is so slimming! The waist design is incredible, put it on and instantly have a waistline. Fabric is very breathable, not stuffy at all in summer. Perfect for dates and shopping! 👗', + generatedPosterImage: 'https://picsum.photos/seed/dress_output/300/400' + }, + createdAt: '2026-01-20T10:00:00Z' + }, + { + id: 'task_002', + name: 'Super Strong Noise Cancelling Bluetooth Headset Pro', + status: 'completed', + input: { + category: 'Electronics', + features: ['Noise cancelling', 'Ultra-long battery', 'Low latency'], + originalImage: 'https://picsum.photos/seed/tech_input/300/400' + }, + output: { + generatedTitle: '🎧 Finally found it! This headset\'s noise cancelling is so strong! 🔇', + generatedCopy: + 'Put it on and the world instantly goes quiet. Sound quality is excellent, listening to music is like being there live. Battery life is impressive too, charge once use for a week! Students must-have!', + generatedPosterImage: 'https://picsum.photos/seed/tech_output/300/400' + }, + createdAt: '2026-01-21T14:30:00Z' + } + // ... more data +] +``` + +### 2.3 (Advanced) Use LocalStorage for "Fake CRUD" + +If you want the "mock data" just generated to not only be viewable but also deletable and editable, and even have newly created tasks persist after page refresh, you can combine with `LocalStorage`. + +> **Prompt Example:** +> "Please help me implement a data storage feature. +> +> 1. Prioritize reading data from `localStorage`. +> 2. If `localStorage` is empty, initialize with the mock data just generated and store them in `localStorage`. +> 3. Also help me write `addProductTask` and `deleteProductTask` functions, each operation should synchronously update `localStorage`." + +Through this step, your prototype has "memory", and user experience is almost indistinguishable from a real product. + +
+ + + +
+ +## 3. Collect Feedback and Quick Iteration + +Building behind closed doors won't produce good products. Now your prototype has "core functionality" + "complete flows" + "demo data", it's time to show it to others. + +### 3.1 Who to Test? How to Test? + +- **Find friends/colleagues**: They don't need to understand technology, just let them try using it. +- **Observe, don't guide**: Don't say "click here", instead watch where they would click. If they can't find a button, the design has problems. +- **"Wizard of Oz" Method**: If your AI isn't connected yet, you can manually modify data in the backend (or database) to simulate AI returns, first validating whether users need this feature. + +### 3.2 Facing Bugs and Complaints + +- **Layout issues**: Might be messy at different screen sizes. + - **Action**: Screenshot and send to AI IDE -> "It's messed up at this screen width, help me fix it." +- **Awkward operations**: "This flow is too complicated." + - **Action**: Tell the suggestion to AI IDE -> "Users think upload-then-generate is too slow, can we change to one-click generate?" +- **New requirements**: "If only it had this feature." + - **Action**: Evaluate if it's core. If yes, have AI quickly implement a simplified version. + +**Remember: At this stage, AI is your best modification assistant. You just need to discover problems; leave code modifications to it.** + +
+ + + +
+ +## 4. Graduation Project: Complete Your "Final Design" + +Congratulations! You've completed the entire process from "requirements" to "prototype" to "AI integration". Now it's time to showcase your final results. + +**This final project is no longer limited to the "E-commerce Material Workbench"**. You need to combine your own interests or industry background to create a unique AI product prototype. + +### Topic Selection and Requirements + +You need to choose a scenario closest to your interests from **Industry Scenario References**, or conceive a completely new scenario based on your own ideas. + +**The project must comprehensively apply everything learned in previous lessons:** + +1. **Prototype Construction**: Use frontend technology to build beautiful, easy-to-use interfaces. +2. **Requirement Control**: Don't aim for comprehensive, but ensure core functionality logic is complete. +3. **API Integration**: Connect to real AI models (LLM/VLM, etc.), giving the application real intelligence. +4. **Implement a Playable Application**: Not just static pages, but a dynamic application with data flow and interactive feedback. + +### Project Deliverables + +Finally, you need to submit two things: + +1. **A Complete Prototype Application**: Deployed online or runnable locally, with complete usage flows. +2. **30-Second Demo Video**: Record a video briefly introducing your application scenario and demonstrating core functionality in action. + + + + +

+ This is Stage 1's final battle. Please check your work against this list: +

+ +
Core Functionality Self-Check
+
    +
  • +
  • +
  • +
  • +
+ +
Deliverables Preparation
+
    +
  • +
  • +
+
+ +## Next Steps + +After completing the final project, you now have the ability to "independently develop AI application prototypes." +In the upcoming Stage 2, we'll dive into more complex full-stack development, learning how to turn this prototype into a truly deployable commercial-grade application with database and user systems. + +See you in the next stage! diff --git a/docs/en/stage-1/appendix-a-product-thinking/index.md b/docs/en/stage-1/appendix-a-product-thinking/index.md new file mode 100644 index 0000000..7cb157c --- /dev/null +++ b/docs/en/stage-1/appendix-a-product-thinking/index.md @@ -0,0 +1,327 @@ +--- +title: 'Product Thinking and Solution Design' +description: 'Learn how to transition from building AI tools to thinking, judging, and polishing an AI application with sense. Master the core concepts and practical methods of product thinking.' +--- + + + +# Product Thinking and Solution Design + +## Chapter Overview + + + +In previous chapters, you've learned how to build various small tools in z.ai and local AI IDEs, and tried using Trae to handle engineering issues like environment configuration and dependency installation. You now have the ability to move ideas from browser to local projects. + +Next, we need to shift our focus from "can it be built" to "what exactly should be built that's worth building". + +This lesson will systematically discuss: +- What counts as an "idea" and what makes a "good idea" +- How to judge whether a product direction is worth investing in +- How to use a repeatable process to turn vague inspiration into clear application solutions + +Core Goal: Upgrade from being able to build tools to being able to create AI applications that people actually use and create real value. + + + +
+ + + +
+ +## What You Will Learn + +In summary, you will learn the basics of building an application: where ideas come from → how ideas become applications → how applications go from usable to great → how to use AI in applications → how to find users after completion. + +1. I want to build an application, where do reliable ideas come from? +2. Once I have an idea, how do I break it down into something that can be built? +3. After building it, how do I judge and polish it into a "good application"? +4. At which step and how do I reasonably use AI to amplify value? +5. After having an application, how do I find the first batch of real users from zero? + +# 1. I Want to Build an Application, Where Do Reliable Ideas Come From? + +Many people, when mentioning building an application, their first reaction is: I need to think of a creative idea that's memorable enough. So they browse rankings every day, read reports, study various hot products, staring at others' success stories, hoping one day they'll encounter a particularly unique idea. + +But the reality is, many people actually have no ideas at all, just anxious because they don't have ideas; some set a very high threshold from the start: if it's not interesting enough, don't start, thinking ordinary equals failure. But when you really walk a stretch of the road, you'll find that applications that can go far and steady are mostly not thought up in some late night brainstorm, but grow bit by bit in specific life scenarios, around real problems. + +So, this chapter wants to solve a starting point problem: **How can I have an idea? Is this idea reliable? Is it worth your time and energy to turn it into a real application?** + +## 1.1 What is an Idea + +Let's start with a most basic but often overlooked question: what exactly counts as an idea. + +In daily conversation, what people often call an idea is often a very subjective excitement. You might see a video on the street and instantly think this direction is so cool, so a sentence pops up in your mind: I can make something similar too. Or at a party chat, everyone complains about a product being hard to use, and you casually add: if only there was something that could automatically handle all this for me. At this moment, you do have a hazy thought, but it's still far from something that can be made. + +Here, let's set a slightly more rigorous standard for ourselves. Only when a thought meets at least the following things, do we call it an idea: + +First, **it must target a clear type of user**. Not vaguely saying everyone, but being able to clearly say who this is mainly for. Is it college students, workplace newcomers, parents with kids, or independent developers, e-commerce merchants, small business owners. Different people care about completely different things in the same matter. If you haven't even determined the crowd, then all subsequent judgments will be floating in the air. + +Second, **it needs to be rooted in a specific scenario**. When is this application used by users, is it on the morning commute subway, during work breaks, before sleep, or on weekends when organizing materials. Even seemingly abstract tools, like notes and task management, if you observe carefully, the part that's actually used frequently is definitely tied very tightly to certain scenarios. + +Third, **it needs to help users complete a clear task**. The task doesn't have to be big, but it needs to be expressible. Like organizing the day's to-do list, condensing a long article into a few key points, generating a structured meeting minute for a meeting, or generating a feasible route for a city weekend trip. The more specifically you can state the task, the easier it will be to design features and evaluate value later. + +Fourth, **it provides a better approach or tool than the current situation**. How did users originally complete this task, was it by memory, paper notes, Excel, screenshot collections, or switching back and forth between different applications. If you can provide a clearly more effortless, more stable, more pleasant way, then this idea truly starts to have value. + +![](../../../zh-cn/stage-1/appendix-a-product-thinking/images/image1.png) + +If you can't think clearly about the above, it doesn't matter. Now is the AI era, you can organize the above content into a complete prompt, then write your thoughts, target users and usage scenarios together, and hand it to a large model to help you complete and refine. Treat the model as an always-online product partner, repeatedly dialogue, question, modify, and you can turn a vague concept into something concrete. + +## 1.2 Ideas and User Needs: The First Line of Defense Against Self-Indulgence + +Many people, when building an application for the first time, most easily fall into the trap of self-indulgence. Self-indulgence means you're incredibly excited about your own creative idea, thinking this is a world-disrupting direction, but when you explain it to ordinary users, their reaction is often calm, even somewhat confused, just politely nodding and saying "sounds pretty good." However, after the product launches, they neither download nor use it long-term. + +To avoid this situation, you must separate ideas from user needs. + +Let's first talk about what **user needs** are. It can be summarized in a relatively simple sentence: in a specific scenario, **the various costs users hope to reduce, or various values they hope to increase, to achieve a certain goal.** The costs here include not just money, but also time, energy, mental burden, risk of making mistakes, and even social pressure. For example, a newcomer just entering the workplace might be willing to spend money on a set of templates, just to be less nervous during their first report; a parent with children might be willing to pay a bit more, as long as they can guarantee half an hour for themselves every day. + +Understanding this, you'll find that **pure coolness doesn't constitute a need.** Many creative ideas are indeed novel enough, but if it doesn't make users more effortless, more at ease, more confident on some specific goal, then it's hard to support a truly sustainable application. + +There's an often-overlooked gap between ideas and needs. **Ideas represent your subjective judgment rather than data support** - what you think is fun, interesting, looks avant-garde. Needs represent what users are actually experiencing and what they're worrying about. You might think an automatic poetry generation feature is very cool, but for most users, a tool that can save them ten minutes a day on repetitive organizing work might be more attractive. Unless you're like Jobs or have very good design aesthetic level, making everyone think "automatic poetry generation feature" is very cool and spontaneously want to follow you, but this has certain difficulty. + +When judging a thought, there's a simple way to distinguish whether it's more like a **real need or a fake need**. A clear characteristic of real needs is that even without your application now, users are actively trying to solve this problem. Even if the current approach is clumsy, they're still willing to spend time, energy, even money to fill this gap. For example, some people write their own scripts just to reduce some repetitive labor for themselves. In these scenarios, if you can provide a friendlier, more universal solution, there's often an opportunity to stand firm. + +The typical situation of fake needs is exactly the opposite. If you don't actively bring it up, most people won't realize that's a problem, and won't even feel it must be solved. The usage scenarios you describe exist more in your imagination than in users' daily lives. After hearing your introduction, they'll just think this thing is good, quite interesting, but won't pay, and might even turn around and forget. Such ideas are okay for writing stories, but very dangerous for making products. + +![](../../../zh-cn/stage-1/appendix-a-product-thinking/images/image2.png) + +So, **the first line of defense against self-indulgence is understanding user needs.** From the beginning, you need to force yourself to answer a seemingly simple but very critical question: besides myself, who else is seriously worrying about this matter. You can go to forums, communities, comment sections, or directly ask a few people around you who might become users. If you rarely hear complaints with real emotion like "I get stuck on this every time" or "the current approach is really too troublesome," then it means this idea is still some distance from real needs. + +## 1.3 Why Good Ideas Are Good Ideas + +Not all ideas have the same fate. Some ideas, even if you only spend a few days making a rough but working version, will naturally attract a small group of real users who are willing to stay and patiently give you feedback. Other ideas, even if you desperately pile on features, spend money on ads, and do a lot of promotion on various platforms, can only briefly pile up some data through external force, and soon return to silence. + +The most essential difference behind this is whether the idea itself has stepped on some key problem point. + +**A good idea naturally welcomes growth**: Even appearing in a very crude form, with only a few simple buttons, as long as it can solve a specific small trouble for users, it can achieve a certain degree of natural growth. For example, a small tool that can quickly convert speech to text, at first might just be a webpage with a few simple buttons, but as long as the recognition quality is good enough and the function conversion is particularly natural, many people will be willing to forward the link to friends, because this simply saves them time. + +**A bad idea is often destined from the start to rely on external force to drive**. Even if your appearance is particularly good, the core displays particularly high-end, you need to keep pushing, keep shouting, keep explaining, but once your recruitment action slows down, usage data will slide straight down. You keep throwing resources in, pulling partnerships, doing activities, but always feel like you're going against the current. The problem isn't that you didn't execute well enough, but that the point itself didn't hit a real enough pain point. + +Of course, the above situations aren't absolute. For example, in early markets, users might not realize value has some lag. For example, when there are competing products, we also need to consider appearance, operation difficulty, brand characteristics, etc., but these are deeper content, not considered for now. + +So, when we discuss whether to continue investing in an idea, what we should really focus on isn't how flashy the creativity itself is, but whether it can naturally grow a path from problem to solution. We make ideas not just to prove to others how creative we are, but to find a valuable starting point, along which we can slowly polish a small tool into a truly useful application. + +Choice is more important than effort. + +## 1.4 Where Good Ideas Come From: Four Sources and Specific Examples + +Many people, when mentioning thinking of ideas, the picture that comes to mind is a person stuck at a desk, staring at the ceiling, hoping one day inspiration will suddenly fall and hit them. Real good ideas, however, mostly don't come this way. They more often come from small observations in life, repeated questions in communities, piles of complaints on the internet, and being sifted out bit by bit from existing products. + +These four sources below, if you're willing to seriously do them, are easy to dig out directions you can start with. + +![](../../../zh-cn/stage-1/appendix-a-product-thinking/images/image3.png) + +### Love Your Own Life + +A very simple but effective principle is: **the more participatory you are in life, the easier it is to discover problems, and the more capable you are of judging what problems are worth solving.** So-called participatory means you're not watching others live through a screen, but personally experiencing, trying, and making mistakes. The more seriously you treat your hobbies, the more likely they'll become fertile ground for ideas to grow. + +For example, if you particularly love raising cats, a day you live with a cat yourself often has more information value than scrolling through a hundred "cat raising tips." You'll know where cats are most likely to knock things over, remember what time every day they're most active, in which situations they're most easily stressed, and personally experience details like cleaning litter boxes, brushing fur, trimming nails, and vet visits. **Every slightly unsmooth experience is actually a potential product clue.** + +Like taking photos of your cat: many people have encountered the situation where you're holding your phone up, but the cat just won't look at the lens, either lowering its head to lick paws or staring at some other corner. Could there be a small tool that makes your phone or tablet screen show an automatically moving red dot, feather, or bug animation, specifically attracting the cat's attention? When you press the photo button, it automatically waves around near the front camera, "tricking" the cat's gaze toward the lens, and conveniently takes several consecutive shots, helping you pick out the clear and good-looking one. Thinking one step further, this app could also record which color and movement trajectory each cat is most interested in, next time automatically using its "exclusive" teasing mode to increase success rate. + +![](../../../zh-cn/stage-1/appendix-a-product-thinking/images/image4.png) + +If you enjoy makeup or skincare, every bottle on your cabinet represents a lot of trial and error and decision-making. You might already be used to taking photos of each makeup look with your phone album, but every time you look back, you have to recall bit by bit which lipstick and which eyeshadow palette you used that day. Could these pieces of information be systematically recorded to create your own makeup look collection? The app could even help you count which makeup looks you use most in what occasions, which combinations perform best in photos, so you don't have to think from scratch every time you choose makeup. + +More specifically, many people have this scenario: morning time is tight, you open the album wanting to find "that successful commuter makeup from last time," but after scrolling for ages, you still can't remember which products you actually used. Could there be a small feature where after taking a makeup photo, you just casually say to your phone: "Today is interview makeup, used #01 orange-brown eyeshadow palette and bean paste color lipstick," and the app automatically recognizes and generates a "makeup recipe" bound to the photo? Next time you just search "interview," "orange-brown eyeshadow," "bean paste," and you can instantly see all related makeup looks, and even automatically generate a "today only show commuter-suitable, five-minute-complete makeup" recommendation list. Those few minutes you save every morning are actually a very specific "solved problem." + +If you like city walks or various forms of slow travel, you might already be piecing together your experience with various tools: map software recording routes, notes listing cafes to visit, photos and thoughts scattered in albums. Could there be an app that combines routes, check-in points, photos, and text into a walking log with timeline and story? Even further, share your route with friends with one click, letting them walk out different versions in the same city. + +You could also dig into a more daily detail: many people during city walks have the frustration of "feeling this corner is beautiful in the moment, but completely unable to find that spot on the map after going home." Could there be a super lightweight feature: when you walk to a corner that feels right, just hold down your earphone button and say "mark this, it's a road suitable for date walks," and the app instantly drops a voice-tagged marker at your current location, automatically recording time, weather, and noise level. Later, you or your friends, just by opening this city's map, can see these "pedestrian-tested atmosphere points": where's good for spacing out alone, where's good for night views, where's good for walking and chatting with friends. Those small intersections that would have been "forgotten after walking past" slowly grow into a textured city experience database. + +These examples actually want to illustrate just one thing: **you need to love your life, life is your best source of ideas.** Every confusion encountered, temporary workarounds invented, those places you feel are a bit troublesome but have been tolerating - as long as you're willing to look a bit more, ask whether it's possible to use a small tool to change it a bit, they all have the potential to become future product prototypes. + +### Dig From Your Crowd Assets + +So-called crowd assets, simply put, are a group of people you can already reach. It could be your readers, communities you operate, your company's internal colleague group, or an interest community you've long participated in. As long as you have channels to **stably hear what some people are talking about, worrying about, and expecting every day**, then you have a big advantage over someone starting completely from scratch. + +Take a very common example. If you're an organizer of a designer community, what you can see in the group every day is actually an extremely precious pool of needs. Some complain about clients always revising drafts repeatedly, some are dissatisfied with certain material websites' charging methods, some feel wasting too much time adjusting between different size specifications. Behind every complaint hides a potential product clue. For example, you could make a simple size adaptation tool that generates one design into various common platform size ratios with one click; or make a small tool that can save and reuse common components, helping designers complete repetitive work with less time. + +If you're in an exam preparation community, the group might long be filled with similar topics: today's state isn't good, the plan was delayed again, what materials to read more efficiently, how to persist in check-ins. You don't need to imagine out of thin air, just observe for a while, organize the several common difficulties repeatedly mentioned by everyone, and you can roughly outline the initial functional direction of a learning application: like more reasonable goal breakdown, more humanized check-in feedback, more realistic progress visualization. + +In these scenarios, you don't have to try to make a big and comprehensive product for everyone from the start. You just need to admit one thing: this small circle of people in your hands is your best starting point. The deeper you understand them, the more you know those spoken and unspoken small annoyances in their real lives, the more opportunity you have to make something truly used. + +### Dig Needs From Public Spaces + +Even if you temporarily don't have any community or reader group of your own, don't worry at all. Every day countless people on the internet are loudly telling their difficulties and dissatisfaction on various platforms. These voices in public spaces are themselves a huge treasure trove, just that most people never seriously listen. + +You can select several platforms related to industries you're interested in, regularly search for keywords with emotional colors. For example, **so annoying, any recommendations, how to solve, really troublesome, any better way.** Then patiently look through those posts and comments, focusing on two types of information. + +One type is certain problems being mentioned repeatedly over a long period. For example, in job hunting sections, every so often someone comes to ask how to write a resume, how to prepare self-introduction, how to follow up on interview results; in parent groups, confusion about complementary food combinations, sleep schedule adjustment, and parent-child communication repeatedly appears; in small merchant exchange communities, everyone might always be worrying about inventory management, cash flow, and employee scheduling. These long-existing repeated problems are systematic pain points repeatedly exposed by an industry. + +The other type is in certain scenarios, users are barely coping in very clumsy ways. For example, some people write all to-do items on paper, then take photos to upload to the cloud; some copy and paste back and forth between different applications, just to convert content from one format to another; some manually organize data from different channels into one table. In these places, as long as you observe carefully, you'll find many small cuts that can be proceduralized and toolized. + +Digging for needs in public spaces is actually training an ability: turning yourself from a bystander into a catcher. When you habitually search these keywords, habitually record cases, your brain will slowly accumulate a set of sensitivity to real problems, this sensitivity will help you again and again in your subsequent product design process. + +--- + +Please complete the following assignments based on the above content: + +1. Please use any large language model, for your previous idea, let AI reference the Double Diamond model to give divergent results, you need to select a feasible solution from the divergent results. +2. Based on the idea you came up with before, use the breakdown refinement method to get more specific executable content. Similar to: "Provide users with a web tool that lets them upload a text-only PDF of no more than 20 pages, and get an editable text with clear paragraph structure and preserved heading hierarchy within 10 seconds, supporting one-click copy and download as .txt." +3. Based on the refined idea, try to draw your application on a whiteboard. The application needs to focus on two parts: how the UI should be designed, and what features there should be, where each feature is located. + +# 3. After Building, How to Judge and Polish into a Good Application + +When you finally build the first version and put it into the real world for people to use, you'll enter a completely different stage. All previous discussions were still at the idea and design level, and now, the product will be tested by real usage scenarios for the first time. You'll see where users click wrong, where they hesitate, where they get stuck, and also see where they proceed surprisingly smoothly, even unexpectedly lingering a few extra seconds in some corner. These details are far more honest than all your imaginations about the product in your mind. + +This chapter wants to solve a core problem: when an application has already been built, and even has a batch of early users using it, how to judge how far it is from a good application, and how to use this information from real usage to polish it step by step. + +## 3.1 What is a Good Application: 4 Core Characteristics + +To judge whether an application is good, you can't just look at how much you like it yourself, nor just look at download numbers or one or two days of usage count, but look at whether it has some more fundamental, more stable characteristics. Simply speaking, refer to the following characteristics: + +### Good Applications Bring Concrete Value + +The most direct characteristic of a good application is that it can let people get some real benefit in some scenario. This benefit doesn't have to be grand, nor does it need to be packaged in profound language, but must be specific enough that you can clearly say: **what exactly did it help users do less, how much time did it save, or what did it make less error-prone.** + +![](../../../zh-cn/stage-1/appendix-a-product-thinking/images/image14.png) + +For example, a simple meeting minutes tool, if it can automatically generate a structured meeting minute after uploading a recording or directly recording during a meeting, and clearly list action items, responsible persons, and deadlines, then what it saves users is not just typing time, but the entire mental effort from recording, organizing, screening to formatted output. You can very clearly say that this tool probably saves one person twenty minutes per meeting. And if the entire team has ten such meetings every week, then the total time saved is very considerable. + +Another example is a seemingly unremarkable image compression tool, if it can compress a batch of images to one-third of their original size while keeping differences almost invisible to the naked eye, while ensuring one-click export, folder structure not messed up, and naming rules unified, then the value it brings is not just hard drive space savings, but also faster transmission, smoother uploads, and fewer errors when interfacing with other systems. This seemingly ordinary concrete value is often much more reliable than a vague "efficiency improvement." + +So, when you say your application has value, it's best to break the value into one or two specific scenarios, explain in language ordinary people can understand: your application makes what users originally needed to spend how long, do how much manual work, bear how much risk, become more effortless. + +### Users Can Get Started Easily, Almost Without Needing Instructions + +Another easily underestimated but extremely important characteristic is that **good applications usually don't need much explanation.** When users open it for the first time, they can intuitively know roughly where to start, what will happen when clicking what, the largest button usually does the most core thing, the most important entrance is placed in a truly important position, not hidden in the third layer of the menu. + +You can imagine a new user who just downloaded your application, they might have opened it casually while queuing, on the bus, or in a coffee shop. The network signal might not be very good at the time, and they don't have patience to read any long instructions. The confusion time they can tolerate is often only a few seconds. If in these few seconds they don't see any clear guidance, don't know what to do next, it's easy to just close it and never come back. + +So, when you feel the product logic is smooth yourself, it's best to find someone who has never seen your application, let them explore from scratch without you speaking. You just observe where they pause, where they hesitate, when they show that "what is this" expression. If users are blocked by various splash screen popups, complex options, and account binding right when entering, it's hard to seriously experience the value you truly want to provide. + +**Being easy to get started is essentially a form of respect for user costs from the product.** You're acknowledging one thing: no one has an obligation to spend time studying your application. + +### In High-Frequency or Key Scenarios, Users Naturally Think of You + +Good applications often have a stable usage rhythm, either high-frequency or key. **High-frequency means it integrates into users' daily lives, for example, messaging apps opened several times a day**, commuting tools used every day to and from work, check-in apps recorded daily. Key means even if not used every day, once encountering certain scenarios, users will think of you first, like tax filing tools, renovation budget calculators, interview question management tools, visa document checklist assistants. + +You can ask yourself a few questions: when exactly and in what situation will users use you; if they miss you, will they really feel inconvenience; in similar scenarios, what method are they currently using to get by. If there's an alternative, even if very troublesome, but already habituated, then what you need to do is not just feature parity, but make them feel that switching to you is indeed more worthwhile. + +A common misconception is directly binding usage frequency with application quality. Actually, it's not necessary. For example, making annual reports, processing certain documents, making a large transfer - these things themselves aren't high frequency, but once they happen, for users, they're among the most important things at the moment. **If your application can handle this type of key scenario steadily, quickly, and with confidence, then it can also be called a good application.** + +**What really needs vigilance is that type where users neither use you frequently nor actively think of you at any key moment**, and even if your application disappeared from their phone, they'd only vaguely remember having installed such a thing months later when clearing memory. This situation often indicates your application hasn't deeply bound with any real scenario, just piled some weak presence at the functional level. + +### Altruism + +Many people when starting to make products, simultaneously calculating several things in their minds: how to charge after building, how to raise prices, how to make users pay for a bit more usage, how to lock data to prevent users from migrating away. Business calculations themselves aren't problematic, but if the thinking completely revolves around these from the start, it's easy to make applications full of wariness at first glance: asking for various permissions right away,花样收费点 everywhere, feature design clearly not for letting users smoothly complete tasks, but trying to guide users to some payment button. + +In contrast, truly good applications all carry a relatively simple altruism. It indeed thinks clearly about how to survive, and also sets reasonable charging methods, but when designing paths and experiences, the priority is always: **how to make it easier for users to smoothly complete this matter, not how to add a step to create extra obstacles.** You'll see it uses more user-friendly methods in many places, like giving clear prompts at key steps, not overly setting barriers for export and migration, letting you experience at least some real value before charging. + +This altruism is often reflected in some tiny design details. For example, that form field doesn't randomly ask for a bunch of data unrelated to the task just to collect more information, the tutorial sequence is designed around the goal users want to complete, not around feature modules themselves. You can feel this application is seriously helping you accomplish one thing, not treating you as an object to be squeezed. + +There's another important point: **good applications don't have to be big applications. They can be very small, only serving one type of person, one scenario, one task**, but doing it very well in that small piece. For example, specifically helping designers export drafts to formats required by print shops, or specifically helping freelancers organize personal project cases - these ranges aren't large, but the value inside isn't small at all. + +## 3.2 Insight into Needs: Maslow's Hierarchy of Needs Theory + +![](../../../zh-cn/stage-1/appendix-a-product-thinking/images/image16.png) + +Before making an application, many people jump directly to the functional level thinking: can something more be done here, should a button be added there. What truly determines whether an application can survive is which level of human needs you've stepped on, and how accurately you've stepped. + +The reason Maslow's hierarchy of needs theory is repeatedly mentioned in so many fields isn't because it's very rigorous, but because it provides a sufficiently usable observation framework. You don't need to treat it as a strict psychological conclusion, just treat it as a simple framework: helping you hang users' various motivations on several relatively clear levels, convenient for you to judge which type of need your application is satisfying. The more needs you can satisfy, the better the application. + +Maslow's hierarchy of needs theory is usually divided into five levels, from bottom to top: physiological needs, safety needs, belonging and love, esteem needs, self-actualization. + +### Physiological and Survival-Related Needs + +This level is most basic, directly related to eating, sleeping, survival state itself. Sounds like it might be far from internet products, but actually quite a few applications play a role at this level. + +For example, food delivery, grocery shopping, errand running, hotel booking, ride-hailing - these typical home and travel services are essentially helping users solve most basic problems like eating, going out, and resting with lower time costs. Another example is fitness tracking, sleep monitoring, diet check-ins - although appearing more health management-oriented, for many people, they're trying to maintain a body state that won't spiral out of control, which can also be seen as an extension of the physiological and survival level. + +If your application works at this level, one characteristic is: **users will be particularly sensitive to stability, reliability, and predictability.** Food delivery not arriving, ride-hailing not getting a car for a long time, hotel booking information errors - the emotional reactions brought by these problems will be very strong, because these problems directly interrupt the basic rhythm of life. + +### Safety and Certainty Needs + +Safety needs include physical-level safety, as well as economic, information, and psychological security. + +Many tool-type applications actually mainly work at this safety level. For example, accounting, asset management, insurance assistants, contract template tools, password managers, backup tools, privacy protection tools, cloud drive sync, data recovery. The core promise of these applications is often: help you reduce error probability, help you have backup plans when things go wrong, or at least let you have confidence. + +A typical type is various anti-loss, anti-forget, anti-error small tools: schedule reminders, medication reminders, important document expiration reminders, key node memos. This type of application even if it only reminds you a few times a day, as long as it saves you once or twice at critical moments, it will quickly be classified by you as a must-keep type of tool. + +When designing this type of product, you can ask one more question: **what type of risk exactly are you helping users reduce, is it financial, time, relationship**, or compliance and legal. If even you can't explain clearly, then users will find it hard to truly trust you. + +### Belonging, Connection, and Being Seen + +Going up another level is the need for belonging and love. Simply put, I don't want to be alone, I want to be connected with certain people. This level is the home base for social, community, and interest group applications. + +Moments, group chats, interest forums, hobby communities, online book clubs, guilds in games, even some tools centered around specific identities, like new parent groups, international student mutual aid, industry internal anonymous complaint platforms - essentially all provide some sense of belonging: there's a group of people similar to me, we're looking at similar topics, complaining about similar difficulties, sharing similar experiences. + +Some tools appear to be functional applications on the surface, but what truly retains users is often this level of need. For example, in accounting apps where everyone shares their saving progress, ranking and check-in circles in running apps, mutual supervision groups in learning apps. These seemingly value-added social modules are actually letting users bind your application with their own group identity. + +If your application tries to stand at this level, having content alone isn't enough, you need to think about: **why would users feel this is their own people, are they willing to leave traces here, have some slight but real interaction with others.** Otherwise, what you're making is just a one-way broadcast tool. + +### Esteem, Self-Worth, and Achievement + +Going up another level is esteem and self-esteem needs. People don't just want to be accepted, at some stage they'll start caring: am I considered a pretty good person here, have I been seen, recognized, does anyone know about the things I've accomplished. + +Large amounts of check-ins, badges, leaderboards, titles, achievement systems are actually playing a role at this level. Learning apps give you a title after completing certain course hours, exercise apps give you a certificate after reaching goals, creation platforms give authors different level identity markers, communities have obvious highlighting for quality content authors. + +A common mistake here is thinking that adding a bunch of badges, points, and titles will stimulate users. What users want isn't flashy decorations, but that my real effort is recorded and taken seriously. If your achievement system is completely disconnected from users' real investment, like getting a "senior" title with just a few random clicks, then this incentive will quickly fail, even make people feel cheap. + +So at this level, the key isn't whether you've made an incentive system, but: **has your application provided a stage where users can accumulate, letting them clearly see their change from beginner to proficient**, and at key nodes, giving them a ritual sense that "this step is worth remembering." + +### Self-Actualization and Self-Transcendence + +The top of the pyramid points to what kind of person I want to become, and what part of myself I want to contribute. This sounds abstract, but when it falls into specific scenarios, it often has very practical manifestations. + +For example, creation tools: writing, painting, music production, video editing, programming project management - on the surface they're providing technical capabilities, but behind they're承接 users' desire to create something of their own. Another example is some long-term learning platforms, career planning tools, habit formation tools - they serve not just single skills, but some longer-term self-growth goals. + +There's another type: the need to make others better. Many people use knowledge sharing platforms, Q&A communities, public welfare applications, collaborative creation tools not just to earn some points or traffic, but because when helping others and pushing a project forward, there's a feeling that I'm doing something meaningful, which also belongs to self-actualization. + +When your application truly touches this level, it often has a very strong stickiness: even if the interface isn't the prettiest, features aren't necessarily the most complete, users will still stay here, because **it has established a deeper connection with who I am and what kind of things I'm doing.** + +A benefit of treating Maslow's pyramid as a product perspective is that it can help you avoid two common biases. + +**The first bias is only staring at some wrong level.** For example, you're making a tool to help users safely store files, essentially standing at the safety level, but you blindly imitate social products, piling various likes, comments, leaderboards on the interface, resulting in neither grabbing social product users' mindshare nor making people who just want a reliable storage tool feel you're not doing your job. + +**The second bias is ignoring the sequence between levels.** When a person can't even get the most basic stable usage experience guaranteed, it's hard to seriously pursue self-actualization here. For example, if the app crashes frequently and data is occasionally lost, no matter how many badges and growth curves you give, users won't genuinely invest. Conversely, if you do solidly at the basic level, then gradually stack higher-level value, users will more easily follow you up. + +In actual design, you can self-check like this: + +- First ask yourself: which level is my application mainly and most core satisfying, only allowed to choose one level +- Then ask: above this core level, do I have opportunity to naturally extend to the next level, not hard-sticking a concept on +- Finally, take a look: in those levels lower than my target level, do I have obvious shortcomings, even dragging users down + +When you can answer these questions clearly, your understanding of what users really want is no longer just staying at the vague level of "feeling they might like it," which helps you make better applications. + +## 3.3 Classify by User Type: Differences Between C-End and B-End Applications + +After an application is built, you'll quickly discover another important thing: facing ordinary individual users versus facing enterprise or institutional users are two completely different games. They both look like users, but care about completely different priorities. + +- C-End (Consumer End): refers to "consumer end," the core is ordinary individual users. + For example, WeChat, Douyin, Meituan food delivery that we use daily - the users of these Apps are individual persons one by one. This type of scenario serving individuals is C-End business. +- B-End (Business End): refers to "enterprise end," the core is enterprise, institution, or organization users. + For example, DingTalk (enterprise collaboration tool) used in companies, financial software (like Yonyou, Kingdee), POS systems in retail stores - the users of these products are enterprise employees, teams, or entire organizations, serving enterprises' operation, management, production and other needs. This type of scenario serving organizations is B-End business. + +### C-End Applications: Facing Ordinary People's Lives, Emotions, and Habits + +C-End applications face individual users, embedded in everyone's daily life. Common types include content, tools, entertainment, social, learning, etc. + +![](../../../zh-cn/stage-1/appendix-a-product-thinking/images/image17.png) + +Content applications, like news reading, short video platforms, podcast tools. Their core task is usually to screen out content users are interested in from massive information within limited time. Also need to ensure there's constantly new things attracting users back. + +Tool applications, like accounting, to-do items, file management, calendar scheduling. They often provide a handier solution than the original way on some specific task, belonging to one of the infrastructure users use daily. + +Entertainment applications, including games, light interaction, fun small tools. They provide users with emotional relaxation and pleasure. The standard for measuring good or not is more about whether users are willing to continuously spend time on it. + +Social applications revolve around connection and interaction between people. Learning applications revolve around improvement of some ability, like vocabulary memorization, question practice, reading check-ins, course management. + +Although these applications have different types, they have several common concerns. + +**First, user growth.** That is, how to let more people try your application for the first time. This involves channels, communication copy, user incentives, but the premise is always: you first need to have a clear enough usage scenario. Otherwise, even the most powerful growth methods can only bring a wave of short-term curiosity. + +**Second, retention and return visits.** Not about whether people have come, but whether they're willing to stay and come back. A content application, if it can't guarantee continuously producing content users are interested in, will soon be replaced; a tool application, if it doesn't help users truly complete tasks in several key uses, it's also hard to establish long-term usage habits. You can judge how many people have truly incorporated you into their life rhythm by observing retention on day 1, day 7, and day 30. + +**Third, conversion and payment.** Why users are willing to pay usually isn't because you made the free version very bad, but because after they've already obtained some value from you, they see that paid features can bring higher-level convenience. For example, higher usage quotas, stronger collaboration capabilities, more professional templates, more stable performance. + +**Fourth, shareability and spread.** Many C-End products can quickly spread because they naturally have sharing attributes during use. For example, generating an image, a video, a piece of text - users themselves need to send the result to others to complete their own goals. In this process, as long as you make brand exposure natural and not annoying, you can gain some word-of-mouth spread. diff --git a/docs/en/stage-1/appendix-b-common-errors/index.md b/docs/en/stage-1/appendix-b-common-errors/index.md new file mode 100644 index 0000000..a76e72f --- /dev/null +++ b/docs/en/stage-1/appendix-b-common-errors/index.md @@ -0,0 +1,325 @@ +--- +title: 'What to Do When You Encounter Errors While Coding - A Practical Guide to Asking AI with Screenshots' +description: 'Learn how to efficiently ask AI to solve various error problems during development. Master the standard process of screenshotting, describing, and locating problems, making AI your debugging assistant.' +--- + + + +# What to Do When You Encounter Errors While Coding + +## Chapter Overview + + + +In the AI era, the way we troubleshoot errors has changed. + +You don't need to memorize all error types, you don't need to become a debugging expert, and you don't even need to understand what the error means. + +You only need to learn one thing: how to ask AI. + +This chapter will teach you a troubleshooting process from simple to advanced: + +1. Step 1: Ask directly: Describe the phenomenon + screenshot, ask in one sentence +2. Step 2: Add information: If it can't be solved, open F12 to add key information + +After mastering this process, you'll be able to solve 90% of errors yourself. + + + +::: info Note +All methods in this chapter are based on actual experience with AI IDEs like Cursor/Trae/Claude, and can be directly applied to daily development. +::: + +
+ + + +
+ +## 1. Core Mindset: Screenshot and Ask AI + +::: warning Why is this chapter important? + +Many beginners' first reaction when encountering errors is: +- Panic and start randomly modifying code +- Spend half an hour searching "how to solve xxx error" +- Try to understand what the error means yourself +- Debug alone until late at night + +These are all wasting time. + +In the AI era, debugging has become a very simple matter: + +``` +See error → Screenshot → Ask AI → Do what AI says +``` + +You don't need to understand the error, you don't need to know how to debug, you don't even need to know where the problem is. + +You only need to learn how to ask. + +::: + +### 1.1 The Simplest Way to Ask + +No complex templates needed, choose from two methods: + +**Method 1: Describe the phenomenon** + +Format: What you just did, what happened now + +``` +I just modified the login page code, now the page is blank, what should I do? +``` + +**Method 2: Screenshot** + +Directly screenshot the current page or error message + +``` +[Screenshot] + +How to solve this error? +``` + +**Best method: Description + Screenshot** + +``` +I just modified the login page code, now the page is blank. + +[Screenshot] + +What should I do? +``` + +**Remember: Describe the context clearly, add a screenshot, and AI can help you solve the problem faster.** + +### 1.2 How to Explain the Problem Clearly + +Many beginners know they need to ask, but don't know how to say it. Actually, you only need to explain three things: + +**1. What you just did** + +``` +I just clicked the save button +I just modified the login page code +I just refreshed the page +``` + +**2. What you see now** + +``` +Now the page is blank +Now the button has no response when clicked +Now it shows an error message +``` + +**3. What effect you want to achieve** + +``` +I want the data to save successfully +I want the page to display normally +I want a prompt to pop up after clicking the button +``` + +**Complete example:** + +``` +I just clicked the save button, now the page shows "Save failed" error. + +[Screenshot] + +I want the form data to save to the database successfully, what should I do? +``` + +**Key principles:** +- Use plain language, no technical jargon needed +- Speak in chronological order: what you did first, then what happened +- State your expectations so AI knows what you want + +## 2. Step 1: Describe the Phenomenon Directly and Ask + +When encountering a problem, don't rush to open F12. First describe the phenomenon directly, screenshot the current page, and show it to AI. + +Many times, AI can directly give a solution after seeing the screenshot. + +### 2.1 How to Describe Common Phenomena + +::: tip Just describe directly + +**Page is blank** +``` +The page opens blank, what should I do? + +[Screenshot] +``` + +**Button click has no response** +``` +Clicking this button has no response, help me check. + +[Screenshot] +``` + +**Data won't save** +``` +Clicked save, data didn't save, what should I do? + +[Screenshot] +``` + +**Style displays incorrectly** +``` +This button position is off, how to adjust? + +[Screenshot] +``` + +**API error** +``` +Calling the API resulted in an error, help me check. + +[Screenshot] +``` + +::: + +### 2.2 If AI Solves It Directly + +Congratulations, problem solved! Just modify according to what AI says. + +### 2.3 If AI Says "Need More Information" + +Then you need to open F12 and add key information. Read on. + +## 3. Step 2: Add Key Information + +When AI says it needs more information, open F12 and screenshot the corresponding content based on the problem type. + +### 3.1 When to Add Information + +AI might reply like this: +- "Please open Console to see if there are any errors" +- "Screenshot the Network panel for me to see" +- "Need to see the specific error message" + +At this point, add screenshots according to the guidance below. + +### 3.2 Add Console Information (Page Blank/Error) + +::: tip Operation steps + +**Step 1: Press F12 to open Developer Tools** + +On Mac it's `Cmd+Option+I`, or right-click the page and select "Inspect". + +**Step 2: Switch to Console tab** + +**Step 3: Screenshot the red error message** + +**Step 4: Send to AI** + +``` +Console error is as follows: + +[Screenshot] +``` + +::: + +### 3.3 Add Network Information (Data Issues/API Errors) + +::: tip Operation steps + +**Step 1: Press F12 to open Developer Tools** + +**Step 2: Switch to Network tab** + +**Step 3: Perform the operation again** (click save/refresh page) + +**Step 4: Find the corresponding request and screenshot** + +- Look at URL and status code +- Look at Payload (parameters passed) +- Look at Response (returned result) + +**Step 5: Send to AI** + +``` +Network information is as follows: + +Request: [Screenshot 1] +Parameters: [Screenshot 2] +Response: [Screenshot 3] +``` + +::: + +### 3.4 Add Elements Information (Style Issues) + +::: tip Operation steps + +**Step 1: Right-click element → "Inspect"** + +Developer Tools will automatically locate that element. + +**Step 2: Screenshot the Styles panel** + +**Step 3: Send to AI** + +``` +Element styles are as follows: + +[Screenshot] +``` + +::: + +## 4. Step 3: Iterate Until Solved + +### 4.1 Inefficient Approaches + +These approaches will waste your time: + +- Panic when seeing an error and start randomly modifying code +- Spend half an hour searching for error solutions +- Try to understand the meaning of every error yourself +- Debug alone until late at night + +### 4.2 Efficient Approaches + +Follow this process: + +- First describe the phenomenon directly and screenshot to ask +- When AI says it needs more information, open F12 to add +- Modify code according to suggestions +- After modifying, test; if problem persists, continue screenshotting and asking + +## 5. Summary: Complete Process + +``` +Encounter problem + ↓ +Describe phenomenon directly + screenshot + ↓ +Send to AI: "What should I do?" + ↓ +AI solves directly? + ↓ Yes +Do what AI says + ↓ +Test if solved + ↓ + ↓ No / AI needs more information +Open F12, add key information + ↓ +Send to AI again + ↓ +Repeat until solved +``` diff --git a/docs/zh-cn/stage-1/1.1-introduction-to-ai-ide/index.md b/docs/zh-cn/stage-1/1.1-introduction-to-ai-ide/index.md index 57e4158..c32b56d 100644 --- a/docs/zh-cn/stage-1/1.1-introduction-to-ai-ide/index.md +++ b/docs/zh-cn/stage-1/1.1-introduction-to-ai-ide/index.md @@ -244,8 +244,8 @@ Trae 分为国际版和中国版。国际版需要能够访问海外网络,但 ##### Trae 定价与使用方式 -::: info 💡 版本选择提示 -- 如果你主要在国内使用,建议优先选择国内版,网络访问更稳定,且支持国产大模型 +::: info 💡 版本选择提示(零基础推荐 CN 版) +- **零基础入门强烈推荐下载中国版(CN 版,trae.cn)**,目前使用体验更好,且基础功能免费,无需海外网络 - 如果你需要使用 GPT-5 等海外模型,且网络条件允许,可以选择国际版 - 如果已有第三方模型的 API Key,接入第三方模型可以灵活控制成本 ::: @@ -256,11 +256,11 @@ Trae 分为国际版和中国版。国际版需要能够访问海外网络,但 关于 Trae 的费用和使用方式,有以下几个选项可供选择: -- **国内版(推荐)**:基础使用是免费的,但由于用户较多可能需要排队等待。 +- **国内版 CN 版(强烈推荐)**:基础使用免费,目前整体使用效果优于国际版,非常适合零基础入门。由于用户较多可能偶尔需要排队等待。 - **国际版**:订阅价格大约为每月 3 美元左右,可以访问 GPT-5 等海外模型,但需要能够访问海外网络。 - **第三方模型接入**:如果你已经有国内大模型的 Token API(如 DeepSeek、通义千问、Kimi 等),可以通过 Trae 的第三方模型配置功能将这些 API 接入使用。各大云服务厂商(如阿里云、腾讯云、百度云等)通常提供 Coding Plan 订阅计划,购买后可以以更优惠的价格使用其大模型 API。这样你可以自由选择自己喜欢的模型,同时控制使用成本。 -建议初学者从国内版免费版开始体验,如果遇到排队问题或需要更稳定的服务,可以考虑接入第三方模型并购买对应云厂商的 Coding Plan 计划。 +建议初学者从国内 CN 版免费版开始体验(下载地址:https://www.trae.cn/ ),目前 CN 版的使用效果更好且完全免费。如果遇到排队问题或需要更稳定的服务,可以考虑接入第三方模型并购买对应云厂商的 Coding Plan 计划。 #### 4.1.3 Trae 界面简介