سلّم Artifact من Claude Code بحيث يتولى شخص مسؤولية ما تغيّر

Artifact في Claude Code مفيد، لكنه لا يصير تسليمًا إلا حين يعرف الفريق ما الذي تغيّر، ولماذا تغيّر، وما المطلوب بعد ذلك.

أتاحت Anthropic Artifacts في Claude Code، فصار بإمكان الفرق أن تشارك صفحات حية من جلسات البرمجة. هذا جيد، فهو يسهّل بدء المراجعة، لكنه لا يسهّل إنهاءها.

مشكلة أغلب الفرق في ملكية سير العمل. تولّد الفرق شيئًا، وتضع رابطه في إحدى القنوات، وتنتظر ملاحظات مفيدة. ثم يمتلئ النقاش بالتخمينات والتعليقات الجانبية وأسئلة كان على من أنشأ العمل أن يجيب عنها قبل المشاركة.

والعلاج سهل: عامل كل Artifact حي على أنه ملف قرار. استخدم تسليم Artifact الحي قبل أن تطلب المراجعة من أي شخص.

Artifact هو الشيء المعروض، والقرار هو الناتج

الخطأ أن يُعامل Artifact على أنه الناتج. Artifact هو الشيء المعروض، أما الناتج الفعلي فقرار مشترك: اعتماد، أو تعديل، أو اختبار، أو بناء، أو عرض، أو رفض.

من دون تسليم يخترع كل مراجع لنفسه إطار مراجعة: قد يبحث المطوّر عن مخاطر التنفيذ، وقد يحكم المسوّق على الرسالة، وقد يسأل المؤسس هل هذا نهائي. لا أحد منهم مخطئ، لكن المراجعة يكثر فيها التشويش لأن العمل وصل بلا سياق.

تخيّل فريقًا يشارك تصورًا لصفحة تسعير في Artifact حي. يعلّق أحدهم على التسلسل البصري، ويناقش آخر منطق التسعير، ويفترض ثالث أنها جاهزة للبناء. والسبب أن أحدًا لم يُخبَر أيّ طبقة من العمل تحتاج إلى حكم.

قاعدة مسؤول التشغيل: شارك كل Artifact ومعه إطار القرار.

سير عمل تسليم Artifact الحي

استخدم سير العمل هذا بعد إنشاء Artifact لصفحة أو تعديله، وقبل نشره في قناة المطوّرين أو قناة المنتج أو قناة العميل أو نقاش مراجعة داخلي. وقد وُضع للفرق المختلطة: مطوّرون، ومؤسسون، ومسوّقون، ومالكو منتجات، ومسؤولو تشغيل، ومستشارون، وأشخاص لا يكتبون الكود يحتاجون إلى مراجعة العمل من دون قراءة جلسة البرمجة كلها.

لمن وُضع: لكل من يستخدم Artifacts في Claude Code على أنها مادة مراجعة مشتركة.

متى تستخدمه: حين يحتاج شخص آخر إلى مراجعة Artifact أو اعتماده أو تعديله أو البناء عليه أو عرضه.

المدخلات المطلوبة:

• Artifact الحي أو الصفحة التي أُنشئت خلال جلسة البرمجة.
• الهدف التجاري من الصفحة أو المكوّن.
• آخر تعليمات أو أمر أنتج النسخة الحالية.
• أهم التغييرات في هذه النسخة.
• الملاحظات المحددة المطلوبة من المراجعين.
• أي قيد يجب أن يعرفه المراجعون، سواء تعلّق بالعلامة التجارية أو البيانات أو التقنية أو القانون أو الأمن أو الامتثال.

1. أنشئ Artifact للصفحة. ضيّق النطاق، فمراجعة صفحة واحدة أو مكوّن واحد أو قرار واحد أسهل من مراجعة Artifact مختلط يحاول حل كل شيء دفعة واحدة.
2. أضف عنوانًا واضحًا ووسم نسخة. يجب أن يصف العنوان العمل، لا الأداة. استخدم وسمًا بسيطًا مثل v0.1 concept أو v0.2 content pass أو v1.0 build review، فالوسم يخبر المراجعين بمدى نضج العمل.
3. اكتب فقرة واحدة عمّا تغيّر ولماذا تغيّر. اشرح السبب التجاري ولا تكتفِ بالتغيير الظاهر. عبارة مثل «نقلنا الأدلة إلى ما قبل المزايا لأن على الصفحة أن تجيب عن اعتراضات الثقة قبل أن تطلب من المستخدمين مقارنة التفاصيل» مفيدة، وعبارة «حدّثنا التخطيط» غير مفيدة.
4. شارك Artifact الحي في قناة الفريق الصحيحة. أرفق به العنوان، ووسم النسخة، وملخص التغيير، وموضع تركيز المراجعين، وأي موعد نهائي. واجعله حيث يعمل الأشخاص المناسبون أصلًا.
5. اجعل نص Artifact المرجع المعتمد للأمر التالي. لا تعدّل اعتمادًا على الذاكرة أو على نقاش تعليقات فوضوي. ابدأ التعليمات التالية من Artifact الحالي ومعه الملاحظات المقبولة.

الناتج المتوقع: Artifact مشترك يستطيع من لا يكتب الكود أن يراجعه من دون أن يسأل: «ما الذي أنظر إليه؟»

اختبار الجودة: ينبغي أن يتمكن المراجع من الإجابة عن 4 أسئلة في أقل من دقيقة: ما هذا؟ ما الذي تغيّر؟ لماذا تغيّر؟ ما الملاحظات المطلوبة مني؟

خطأ شائع يجب تجنبه: لا تنشر رابطًا وتكتب معه «آراؤكم؟». بهذا تُلقي على الجميع عمل توضيح السياق.

كتلة تعليمات جاهزة للنسخ داخل Claude Code

استخدم كتلة التعليمات هذه حين تريد أن يكون Artifact جاهزًا لمراجعة فريق مختلط. وهي تُلزم العمل بأن يتضمن المعلومات التي يحتاج إليها المراجعون، ولا تغني عن حكم البشر.

You are preparing a Claude Code Artifact for team review.

Create or revise the page Artifact, then include a review handoff section in plain English.

The handoff must include:
1. Title: a clear name for the Artifact.
2. Version tag: use v0.1 concept, v0.2 revision, v1.0 review-ready, or another simple tag that fits.
3. What changed + why: one short paragraph explaining the main change and the business reason behind it.
4. Reviewer focus: list exactly what reviewers should comment on.
5. Not in scope: list what reviewers should ignore for this pass.
6. Risks or assumptions: list any assumptions, missing inputs, or technical risks.
7. Next prompt source: provide a concise source-of-truth summary that can be pasted into the next prompt.

Write for non-coders. Do not assume the reviewer read the coding session. Avoid vague phrases like improved, optimized, enhanced, or polished unless you explain what changed.

If information is missing, state the assumption clearly instead of pretending it is known.

الآلية هنا هي التقييد: كتلة التعليمات تُلزم النموذج بأن يجهّز العمل للمراجعة. الحصول على ناتج مبهر سهل، أما الناتج الموثوق فيحتاج إلى عمل.

مثلًا، إذا كان Artifact مسودة صفحة هبوط، فلا ينبغي أن يقول التسليم: «حدّثنا الصفحة». ينبغي أن يقول: «أعدنا العمل على القسم الافتتاحي وقسم الأدلة لتشرح الصفحة مشكلة المشتري قبل أن تعرض مزايا المنتج. راجعوا وضوح الرسالة وترتيب الأقسام فقط، ولا تراجعوا التنسيق في هذه الجولة». بذلك يصير أمام المسوّق والمؤسس والمطوّر هدف واحد.

وسوم النسخ تتحكم في جودة الملاحظات

وسم النسخة يخبر الناس كيف يراجعون، فالمراجعون يوجّهون انتباههم بحسب ما يبدو لهم من نضج العمل.

إذا شاركت تصورًا أوليًا بلا وسم فسينتقد أحدهم المسافات أو لون الزر أو الحالات الاستثنائية. وإذا حمل الوسم v0.1 concept فالأرجح أن يركز الفريق على البنية والعرض التجاري والتدفق.

استخدم وسومًا بسيطة:

• v0.1 concept: راجع الفكرة، والبنية، والاتجاه.
• v0.2 content pass: راجع النص، والرسالة، وترتيب الأقسام.
• v0.3 interaction pass: راجع الحالات، ومسارات الاستخدام، وأفعال المستخدم.
• v1.0 build review: راجع جاهزية التنفيذ أو التسليم.

قد يشارك فريق منتج Artifact للوحة تحكم يحمل الوسم v0.1 concept ومعه هذه الملاحظة: «راجعوا هل تطابق هذه العناصر القرارات اليومية للمدير. لا تراجعوا التنسيق الآن». هذه الجملة وحدها تمنع نقاشًا بصريًا قبل أن يُحسم منطق اللوحة.

ضع على العمل وسمًا يبيّن نضجه قبل أن تطلب الآراء.

قاعدة المرجع المعتمد للأمر التالي

أقوى ما في سير العمل هذا خطوته الخامسة: أن تجعل نص Artifact المرجع المعتمد للأمر التالي.

قد تنحرف جلسات البرمجة بالذكاء الاصطناعي حين تُبنى التعليمات التالية على نقاش طويل أو على الذاكرة أو على تلخيص مبهم. النسخة الحالية من العمل موجودة في Artifact، والاتجاه الموافَق عليه موجود في التعليقات المقبولة. وينبغي أن يجمع الأمر التالي هذين المدخلين ويتجاهل ما سواهما.

وهذا مثال على أمر تعديل نظيف:

Use the current Artifact below as the source of truth.

Accepted feedback:
- Keep the hero structure.
- Replace the generic feature section with three operator problems.
- Move the pricing comparison lower on the page.
- Do not change the visual direction in this pass.

Task:
Revise the Artifact only for messaging and section order. Preserve the existing component structure unless a change is necessary for the accepted feedback.

Current Artifact:
Paste the current Artifact text here.

تستطيع أن تعطي النموذج مادة أنظف يعمل عليها من دون أن تزيد ثقتك به. الذكاء الاصطناعي هو المحرّك، ومسؤول التشغيل هو المهندس المعماري.

المقابل: هذا يضيف احتكاكًا

الاعتراض وجيه: «هل نحتاج فعلًا إلى كل هذه الإجراءات من أجل Artifact سريع؟»

إذا كان العمل استكشافًا عابرًا فالجواب لا. وإذا كان شخص واحد يجرّب وحده فالتسليم الثقيل يبطئ العمل. لكن ما إن يُنتظر من شخص آخر أن يراجع الناتج أو يعتمده أو يبني عليه أو يبيعه أو يعرضه حتى تصير كلفة التسليم أقل من كلفة الارتباك.

كيّف سير العمل بحسب حجم المخاطرة:

• إذا لم يكن على أحد غيرك أن يتصرف بناءً عليه، فأبقِه خفيفًا.
• إذا احتاج شخص واحد إلى مراجعته، فأضف عنوانًا، ووسم نسخة، وملخصًا، وطلب ملاحظات.
• إذا احتاج أكثر من قسم إلى مراجعته، فاستخدم تسليم Artifact الحي كاملًا.
• إذا كان الناتج قد يصل إلى العملاء، فاشترط موافقة بشرية قبل التنفيذ.

الإجراءات هدر حين لا تحمي شيئًا، وتنفع حين تحمي القرارات.

البيانات والصلاحيات وحدود المراجعة

قد تتصل Artifacts بمواد حساسة من مواد العمل: مسارات العملاء، أو ملاحظات التحليلات، أو نصوص داخلية، أو منطق المنتج، أو بيانات مصدَّرة من CRM، أو موضوعات الدعم، أو اعتراضات المبيعات. تعامل مع هذه المواد بحذر.

استخدم أقل قدر من البيانات الحساسة يكفي لإنجاز المهمة. احذف أسماء العملاء، والمعرّفات الخاصة، وتفاصيل الصفقات السرية، ورموز الوصول، والروابط الخاصة، وبيانات الدخول الداخلية، إلا إذا وُجد سبب واضح وموافَق عليه لإدراجها. وأبقِ المخرجات العالية المخاطر تحت مراجعة بشرية، وخصوصًا ما يتصل بالتواصل مع العملاء، أو الادعاءات القانونية، أو الصياغات المالية، أو السلوك المتعلق بالأمن، أو المعلومات الطبية، أو القرارات الخاضعة للوائح تنظيمية.

التحكم في الوصول مهم أيضًا. لا تشارك Artifact حيًا على نطاق واسع لمجرد أن المشاركة سهلة، وشاركه مع من يحتاجون إلى مراجعته أو التصرف بناءً عليه. وإذا كان فيه استراتيجية داخلية أو مواد تتصل بالعملاء، فطبّق عليه التقدير نفسه الذي تطبّقه على أي مستند داخلي.

ينبغي أن يسهّل التسليم المراجعة من دون أن تنتشر المعلومات الحساسة أكثر مما يلزم.

كيف تعرف أن التسليم نجح؟

يكون نظام التسليم ناجحًا حين يقلّ معه طلب التوضيح، سواء بدا مرتبًا أم لا.

في المراجعات الثلاث القادمة التي تُجرى على Artifacts، ابحث عن هذه المؤشرات:

• يعلّق المراجعون على الطبقة المطلوبة من العمل.
• تقلّ في النقاش أسئلة مثل «ما هذا؟» و«ما الذي تغيّر؟».
• تصير كتابة الأمر التالي أسهل لأن الملاحظات المقبولة واضحة.
• يشارك من لا يكتبون الكود من دون حاجة إلى سجل جلسة البرمجة.
• يستطيع الفريق أن يميّز هل Artifact تصور أولي، أم نسخة معدَّلة، أم جاهز للبناء.

إذا غابت هذه المؤشرات فالسبب تسليم لم يُحدَّد بما يكفي، ولا يقع اللوم على Claude Code.

في Artifact القادم الذي يشاركه فريقك، أضف العنوان، ووسم النسخة، وملخص التغيير في فقرة واحدة، وموضع تركيز المراجعين، وكتلة المرجع المعتمد قبل أن يُطلب من أي شخص إبداء ملاحظاته.

أين يقف عملك فعليًا؟

قبل أن تضيف أداة جديدة، يستحق أن تعرف إن كان عملك يعتمد على نظام أم عليك أنت. أعددتُ تقييمًا مجانيًا من دقيقتين يمنحك قراءة واضحة لذلك، وأول خطوة يجب إصلاحها. ابدأ التقييم المجاني.