مخططات تتوافق مع الشيفرة
يقوم Eraser وWhimsical برسم مربعات جميلة؛ لكن مهندسيك سيبنون في النهاية ما يناسب الموعد النهائي. تتحول مخططات Bob إلى بنية الملفات وحدود الوحدات التي يستخدمها Alex فعليًا في قاعدة الشيفرة.
Bob·Architectيرسم بوب النظام، ويختار المكدس، ويسلّم الهيكل إلى أليكس بحيث تصبح معماريتك هي قاعدة الشيفرة، لا وثيقة منسية.
مخططات تتوافق مع الكود، وليست مجرد صور جميلة.
يعرض Eraser وWhimsical صناديق وأسهمًا جميلة. لكن مهندسيك ما زالوا يبنون أي شيء يناسب الموعد النهائي. تتحول مخططات Bob إلى بنية الملفات وحدود الوحدات التي يستخدمها Alex فعليًا.
"اخترنا Mongo لأنه كان شائعًا." يشرح Bob لماذا Postgres بدلًا من Mongo، ولماذا استخدام queue بدلًا من direct calls، ولماذا Redis مقابل Memcached. يكون المنطق مكتوبًا بحيث يمكنك مناقشته.
مخطط الويكي يعود إلى sprint 1. أما الكود فمن sprint 14. لا أحد يحدّث أيًا منهما ليطابق الآخر. يراجع Bob النظام الحالي ويحدّث وثيقة البنية المعمارية لتعكس ما تم شحنه فعليًا.
تتم إضافة الأداء والأمان وقابلية المراقبة لاحقًا بعد أول انقطاع. يخطط Bob لها أثناء التصميم مع متطلبات التوسع الخاصة بـ Emma وأنماط الوصول التي يحتاج نموذج بياناتك إلى دعمها.
من أول مطالبة تكتبها إلى نتيجة جاهزة للإطلاق — إليك كيف يعمل Bob فعليًا.
قاعدة البيانات، وإطار العمل، والطابور، وذاكرة التخزين المؤقت — كل اختيار يأتي مع توضيح مكتوب للمفاضلات يمكنك مناقشته والاعتراض عليه.
الكيانات، والعلاقات، والملكية، ومسارات الكتابة — هذه هي الأشياء التي يكون إعادة هيكلتها مؤلمًا لاحقًا.
تعكس الصناديق والأسهم الوحدات والتبعيات الفعلية؛ ويظل المخطط متزامنًا مع تطور الشيفرة.
يبني Alex ضمن الحدود التي رسمها Bob — من دون ترسيخ دين تقني من نوع "سنعيد الهيكلة بعد ثلاثة أشهر".
تسليم إلى Alexمخططات الخدمة وتدفق البيانات والتكامل التي يتم إنشاؤها داخل المحرر، وليس في أداة منفصلة.
يتم تبرير اختيارات المكدس وفقًا لقيودك، وليس بناءً على الرواج أو الألفة.
تُصمَّم المخططات والعلاقات وفقًا لأنماط الوصول الفعلية لمنتجك.
تتم معالجة الأداء والأمان وقابلية المراقبة أثناء التصميم، وليس بعد الإطلاق.
تُدوَّن القرارات المعمارية مع توضيح أسبابها حتى تتمكن أنت في المستقبل من الرجوع إليها.
ترتبط المخططات ببنية الملفات وحدود الوحدات التي يبني بها Alex.
يمكن لـ Bob مراجعة الأنظمة الحالية والتوصية بالتغييرات مع توضيح الأسباب بشكل واضح.
سير العمل المُعدّ يدويًا بطيء ويدوي ويعتمد كثيرًا على الأدوات. مرّر المؤشر فوق أي بطاقة لمعرفة سبب أهمية كل مكسب.
هل تنتقل من Eraser AI؟ إليك أين يتفوق Bob.
يقوم Eraser وWhimsical برسم مربعات جميلة؛ لكن مهندسيك سيبنون في النهاية ما يناسب الموعد النهائي. تتحول مخططات Bob إلى بنية الملفات وحدود الوحدات التي يستخدمها Alex فعليًا في قاعدة الشيفرة.
يوصي ChatGPT بالإطار الذي رآه أكثر من غيره في بيانات التدريب. ويشرح Bob لماذا Postgres بدلًا من Mongo، ولماذا استخدام queue بدلًا من الاستدعاءات المباشرة، ولماذا Redis بدلًا من Memcached — مع منطق يمكنك مناقشته وقرارات يمكنك إعادة النظر فيها.
يصبح المخطط في الويكي قديماً بحلول السبرنت الثالث. يراجع Bob الشيفرة الفعلية ويحدّث البنية المعمارية وفقاً لما تم شحنه فعلاً، بحيث لا تكون الوثيقة مجرد خيال أبداً، ويستغرق ضم مهندس جديد يوماً واحداً لا شهراً.
| ميزة | Atoms موصى به | Eraser AI |
|---|---|---|
| المخرجات | معمارية تنعكس في الكود | مخطط في ويكي |
| اختيارات المكدس مع تبرير | المفاضلات المكتوبة | اقتراحات عامة |
| يبقى متزامنًا مع شحن الكود | مُحدَّث بالاستناد إلى قاعدة الشيفرة | يصبح قديمًا بحلول السبرنت الثالث |
| متصل بالهندسة | تسليم إلى Alex | التسليم عبر التصدير |
| إنشاء المخططات | مُنشأ تلقائيًا | مُنشأ تلقائيًا |
Bob لا يعمل بمفرده. إليك كيف تتم عمليات التسليم عند البناء مع الفريق الكامل.

يصمم Bob النظام؛ ويبنيه Alex. لا توجد ديون تقنية مدمجة من نوع "نعيد الهيكلة بعد 6 أشهر عندما يزيد الحجم".
اطلع على كيفية Alex يعمل
يقوم Bob بمواءمة البنية مع نطاق منتج Emma. لا يوجد نظام مُفرط الهندسة لميزة بسيطة.
اطلع على كيفية Emma يعمل
يصمم Bob نموذج البيانات بحيث يتمكن David من الاستعلام عنه بسهولة. التحليلات عنصر أساسي وليست إضافة لاحقة.
اطلع على كيفية David يعملعمل معماري ملموس ينتجه بوب ويتوافق مع الشفرة البرمجية الفعلية.
صمّم النظام من البداية مع تبرير اختيارات التقنيات وفقًا لقيودك.
قارن بين خيارات التقنيات لمشروعك واختر ما يناسب فريقك وحجم التوسع المطلوب.
صمّم المخطط والعلاقات والفهارس بما يتناسب مع الاستعلامات التي سيشغّلها منتجك فعليًا.
حدّد خدمات الجهات الخارجية وwebhooks وتدفق البيانات قبل بدء أعمال التكامل.
حدّد نقاط الاختناق وخطّط للزيادة التالية في الحجم قبل أن تؤثر على بيئة الإنتاج.
حدّد مخاوف المصادقة والبيانات والخصوصية وعالجها في مرحلة التصميم بدلًا من معالجتها بعد الإطلاق.
@Bob صمّم البنية المعمارية لخدمة SaaS متعددة المستأجرين مع فوترة حسب الاستخدام، و10 آلاف مستأجر متوقع، ومدفوعات Stripe Connect. اختر المكدس التقني، وارسم مخطط الخدمات، وسلّم بنية الملفات إلى Alex.
@Bob نحن نختار بين Postgres + Prisma وPlanetScale + Drizzle للمنتج الجديد. قارنهما وفقًا لقيودنا (قراءات متعددة المناطق، مهندس واحد، 100ms p95) وأوصِ بأحدهما مع توضيح المقايضات بشكل صريح.
@Bob راجع طبقة API الحالية لدينا. نحن نرى 800ms p95 في نقطة نهاية لوحة المعلومات ونريد التوسع إلى حركة مرور أكبر بـ10 مرات. حدّد الاختناقات، واقترح التغييرات، واكتب خطة الترحيل لـ Alex.
@Bob صمّم المخطط لبرنامج الإحالات في PRD الخاص بـ Emma. حدّد الكيانات والعلاقات والفهارس للاستعلامات التي سنجريها فعليًا. سلّم المخطط وخطة الترحيل إلى Alex.
لا يعمل أي وكيل بمفرده. اضغط على أي زميل لترى كيف يتعامل مع الجزء الخاص به من منتجك.
توقف عن رسم مخططات لا ينفذها أحد. دع Bob يصمم الأنظمة التي يبنيها فريق الذكاء الاصطناعي لديك ويحافظ على مزامنتها داخل Atoms.