التطوير القائم على المواصفات: اضبط السلوك قبل كتابة الكود

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

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

ما التطوير القائم على المواصفات؟

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

قبل الذكاء الاصطناعي، كانت ممارسات قريبة من هذا النهج تستخدم المواصفات بوصفها اختبارات قابلة للتنفيذ، كما في التطوير الموجّه بالسلوك. ينسجم هذا التقليد مع سير العمل هنا، لكن وثيقة مواصفات بصيغة Markdown ليست بحد ذاتها اختبارًا قابلًا للتنفيذ. توثيق Cucumber للتطوير الموجّه بالسلوك.

الجديد عمليًا أن وكلاء البرمجة يستطيعون الرجوع إلى هذه الوثائق طوال التنفيذ. توفر GitHub Spec Kit، وهي أدوات مفتوحة المصدر لتنظيم عمل الوكيل، العملية التي يعمل ضمنها وكيلك. أما Kiro، بيئة البرمجة من AWS، فتدمج سير عمل قائمًا على المواصفات داخل المنتج. ولا يعفيك أي منهما من تحديد التجربة التي ينبغي أن يحصل عليها العميل.

جرى التحقق من التوثيق في 13 أكتوبر 2026: أسماء الأوامر ومسارات الملفات والإمكانات الواردة أدناه مستمدة من التوثيق الحالي لدى GitHub وKiro وAnthropic وOpenAI. أما المثال التطبيقي فهو للتوضيح، ولا يمثل ادعاءً بنشر الميزة في بيئة إنتاج أو تجربة قاست مكاسب الإنتاجية.

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

خطوات تطبيق التطوير القائم على المواصفات

افصل الوثائق بعضها عن بعض، لأن كلًا منها يجيب عن سؤال مختلف. فلا يمكن لمخطط معماري أن يحسم قاعدة ناقصة في سلوك المنتج، ولا لقائمة مهام أن تثبت أن الميزة تعمل.

المؤسس أو مالك المنتج هو صاحب القرار بشأن السلوك. والقائد الهندسي مسؤول عن ملاءمة التصميم للنظام. يستطيع الوكيل صياغة مسودة لكليهما، لكن سلاسة الكتابة ليست دليلًا على صحة أي من القرارين.

أدوات التطوير القائم على المواصفات: ما مقدار التنظيم الذي تحتاجه؟

اختر الأدوات بحسب موضع تعثر التنسيق. تلائم GitHub Spec Kit المستودعات التي تحتاج إلى عملية قابلة للتكرار حول وكيل موجود بالفعل. وتلائم Kiro المطورين الذين يريدون المتطلبات والتصميم وتنفيذ المهام داخل بيئة البرمجة. أما الملفات العادية فتكفي لميزة أولى أو لفريق لديه ممارسة راسخة وموثوقة للمراجعة.

GitHub Spec Kit: الأوامر والملفات التي ستستخدمها

توفر GitHub Spec Kit تعليمات وقوالب وسكربتات مساعدة قابلة لإعادة الاستخدام، بينما يتولى وكيل البرمجة الذي تختاره تنفيذ العمل. يوضح ملف README الحالي التسلسل الأساسي: إرساء مبادئ المشروع، ثم تحديد مواصفات الميزة، ثم التخطيط لها، ثم إنشاء المهام وتنفيذها، وأخيرًا التحقق من الفجوات المتبقية.

يشترط ملف README الحالي استخدام Python 3.11 أو أحدث، وuv، وهو أداة لتثبيت حزم Python، ووكيل مدعوم. يستخدم مثال الإعداد GitHub Copilot، مساعد البرمجة من GitHub. شغّل الأوامر التالية في الطرفية:

uv tool install specify-cli
specify init my-project --integration copilot
cd my-project

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

الاختلاف في صياغة الأسماء مهم. يستخدم README صيغة المهارات الافتراضية لدى Copilot، وهي /speckit-specify. ويستخدم مرجع الأوامر التفصيلي الصيغة ذات النقطة، وهي /speckit.specify. أما تكامل المهارات في Codex فيستخدم $speckit-specify. التزم بالصيغة الخاصة بالتكامل الذي ثبّتّه؛ فلا يمكن استبدال علامات الترقيم بعضها ببعض. مرجع التكاملات.

تتبع هذه الأسماء والأدوار مرجع Agentic SDD لدى GitHub. تمثل أوامر clarify وchecklist وanalyze نقاط تحقق إضافية للجودة. أما وثيقة المبادئ فتحدد قواعد المشروع الدائمة؛ فلا تُعِد كتابتها لكل ميزة صغيرة.

في مثال التصدير، ينبغي أن تصف تعليمة specify من يحق له التصدير، وأي السجلات يشملها، ومحتويات الملف، والسلوك عند الفشل. قدم التقنيات الحالية وقيود المستودع في خطوة التخطيط. واطلب اختبارات القبول صراحةً: يوثق أمر tasks إنشاء الاختبارات عند طلبها، لذا فإن توليد قائمة مهام لا يثبت أنها تضمنت اختبارات مناسبة.

الملفات التي ينبغي مراجعتها هي:

• .specify/memory/constitution.md: مبادئ المشروع. قالب وثيقة المبادئ.
• specs/<feature-directory>/spec.md: سلوك الميزة. توجد مجلدات الميزات عادةً تحت specs/، ويُنشأ اسم المجلد تلقائيًا أو يُضبط في الإعدادات. قالب المواصفات.
• plan.md وtasks.md داخل مجلد الميزة: تصميم التنفيذ وتقسيم العمل. تنتج مرحلة التخطيط أيضًا research.md وdata-model.md وquickstart.md، إلى جانب contracts/ للواجهات الخارجية حين ينطبق ذلك. قالب الخطة، مرجع المهام.

بعد التنفيذ، يقارن converge قاعدة الكود بالمواصفات والخطة والمهام. وإذا وجد فجوات، يضيف عملًا إلى tasks.md؛ ولا يصلح الكود بنفسه. نفّذ العمل المضاف ثم أعد التحقق. نتيجة «Converged» مفيدة للمراجعة، لكنها لا تحل محل اختباراتك أو موافقتك.

للتطبيقات القائمة، يبدأ دليل اعتماد الأدوات من GitHub بالحفاظ على الحالة الأصلية مرجعًا، ثم إجراء التهيئة داخل المشروع نفسه. الأمر الوارد فيه هو specify init --here --force --integration <key>، مع استبدال <key> بمفتاح التكامل الموثق، مثل claude أو codex. ينبه الدليل إلى أن --force قد يستبدل الملفات التي تديرها الأداة إذا تعارضت مع الملفات الموجودة. راجع الفروق الناتجة. ولا تحتاج إلى إعادة بناء مواصفات التطبيق كاملًا قبل تحديد مواصفات التغيير التالي فيه.

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

التطوير القائم على المواصفات في Kiro: المواصفات والتوجيه والخطافات

تفصل Kiro بين غرض الميزة، والإرشادات الدائمة للمشروع، والإجراءات التلقائية. استخدم specs لمواصفات الميزة الحالية، وsteering للأعراف المتبعة على مستوى المستودع، وhooks للفحوص المتكررة.

في بيئة التطوير المتكاملة، أي محرر الكود في Kiro، انقر + ضمن Specs، أو اختر Spec من المحادثة. اختر Feature ثم Requirements-First. راجع المتطلبات قبل قبول التصميم التقني وتقسيم المهام. يحتوي مجلد الميزة الناتج على .kiro/specs/<feature-name>/requirements.md وdesign.md وtasks.md. شغّل المهام من واجهتها بعد مراجعتها. توثيق المواصفات في Kiro.

تستخدم Kiro صيغة EARS، اختصارًا لعبارة Easy Approach to Requirements Syntax، للتعبير عن شرط والسلوك المتوقع من النظام عند تحققه. وفي هذا المثال: «عندما يطلب عضو تصدير البيانات، يجب على النظام رفض الطلب وعدم إرجاع أي ملف تصدير». هذه صياغة محددة بما يكفي لتحويلها إلى اختبار. مواصفات الميزات.

توفر Kiro أيضًا Design-First وQuick Spec. يبدأ Design-First بالتصميم التقني، بينما ينشئ Quick Spec الوثائق دون نقاط الموافقة الوسيطة. إذا كنت مؤسسًا يكرر وكيلك سوء فهم ما تقصده، فاختر Requirements-First واستفد من المراجعات التي يتيحها. فإزالة نقاط المراجعة تعني إزالة الجزء الذي يعالج المشكلة في هذه العملية.

يوفر Steering سياقًا دائمًا بصيغة Markdown داخل .kiro/steering/. والملفات الأساسية هي product.md وtech.md وstructure.md، وتغطي المنتج والتقنيات وتنظيم المستودع. ينشئ خيار Generate Steering Docs داخل بيئة التطوير هذا السياق الأولي. راجعه في ضوء المستودع. ضع هنا توجيهًا مثل «أعد استخدام سياسة الصلاحيات الحالية للعضوية» عندما ينطبق على مختلف الميزات، وضع «التصدير متاح للمالكين فقط» في مواصفات التصدير. توثيق Steering.

تشغّل Hooks أوامر الصدفة أو تعليمات للوكيل عند وقوع حدث. توجد ملفات خطافات المشروع حاليًا في .kiro/hooks/<id>.json، وPostFileSave من الأحداث الموثقة التي تطلقها. يمكن لخطاف محدد المهمة أن يشغّل اختبارات التصدير الحالية عند تغيير الكود ذي الصلة. احتفظ بالفحوص نفسها في التكامل المستمر، أي الفحوص الآلية للتغييرات المقترحة على الكود، حتى لا يكون الخطاف المحلي المكان الوحيد لتشغيلها. وفق جدول الإمكانات الحالي في Kiro، تتوفر الخطافات في بيئة التطوير وواجهة سطر الأوامر، ولا تتوفر في الويب أو الجوال. توثيق Hooks.

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

تطبيق التطوير القائم على المواصفات باستخدام Claude Code

يمكن لـClaude Code، وكيل البرمجة من Anthropic، اتباع هذه العملية بالاعتماد على مواصفات للميزة ووضع التخطيط Plan Mode. ولا تحتاج إلى تثبيت إطار عمل للمواصفات لتجربة الأسلوب.

أنشئ specs/workspace-export/spec.md بنفسك، أو راجع مسودة يعدها الوكيل. ثم ابدأ جلسة الطرفية في وضع التخطيط:

claude --permission-mode plan

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

صُمم Plan Mode للاستكشاف واقتراح نهج للعمل. وتوثق Anthropic استثناءً في جلسات الطرفية التفاعلية التي تتاح فيها صلاحيات التجاوز: لا تُفرض فيها قيود منع التعديل الخاصة بوضع التخطيط. ابدأ دون تفعيل التجاوز إذا أردت الالتزام بحدود الموافقة. توثيق أوضاع الصلاحيات.

بعد مراجعة المقترح، احفظ النهج المقبول في specs/workspace-export/plan.md وقائمة التحقق الخاصة به في tasks.md، ثم أذن بالتنفيذ. هذه المسارات اصطلاح يقترحه المقال، وليست ملفات يَعِد Plan Mode بإنشائها تلقائيًا. يشرح دليل Plan Mode في Claude Code أدوات التحكم والانتقال من التخطيط إلى الموافقة على التنفيذ.

احتفظ بتعليمات المستودع الدائمة في CLAUDE.md، مستعينًا بـدليل ذاكرة الفريق، وبالسلوك الخاص بالميزة في مواصفاتها. وإلا فقد يتحول متطلب مؤقت للتصدير إلى تعليمة دائمة تؤثر في أعمال لا علاقة لها به.

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

Codex: استخدام Plan Mode مع ملف المواصفات نفسه

يدعم Codex، وكيل البرمجة من OpenAI، الأسلوب البسيط نفسه لنقل العمل بين المراحل. في محادثة عبر واجهة سطر الأوامر لا تنفذ عملًا حاليًا، يبدأ /plan التخطيط، ويمكن إرفاق الطلب به مباشرةً. التوثيق الرسمي للأوامر.

من الطلبات المفيدة: «اقرأ specs/workspace-export/spec.md. افحص سياسة العضوية الحالية واستعلام المهام والاختبارات. اقترح أصغر خطة تنفيذ تحقق جميع المتطلبات. وحدد القرارات الناقصة قبل التنفيذ».

راجع الخطة، واحفظ الملفات المتفق عليها، ثم اطلب من Codex تنفيذ المهام وتقديم تقرير إنجاز يربط كل متطلب باختباره. استخدم AGENTS.md لتعليمات المستودع الدائمة؛ ويمكن لـ/init إنشاء هيكله الأولي. يشرح دليل إعداد Codex CLI تهيئة بيئة البداية.

توثق OpenAI أيضًا الاحتفاظ بالمواصفات والخطط وتقدم العمل في ملفات Markdown للمهام الأطول. والفائدة أن الجلسة اللاحقة تستطيع إعادة فتح الاتفاق. حدود الأسلوب: لا يُبقي Plan Mode ملف مواصفات مستقلًا للميزة محدثًا من تلقاء نفسه. اجعل تحديثه جزءًا من مراجعة التغيير. سير العمل الموثق لدى OpenAI.

مثال عملي: تصدير مهام مساحة العمل بصيغة CSV

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

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

المواصفات في صفحة واحدة

احفظ ما يلي في ملف spec.md الخاص بالميزة، أو ضع المحتوى السلوكي نفسه في ملف requirements.md لدى Kiro:

لاحظ القرار الكامن في R2: «جميع النتائج المطابقة» تختلف عن «الصفحة الظاهرة». حسم ذلك قبل التنفيذ يغير الاستعلام وخطة الاختبار فورًا. أما حسمه بعد العرض التجريبي فقد يفرض العودة إلى كليهما.

يسمي R4 عمدًا قرارًا يحتاج إلى أمثلة ملموسة. قبل الموافقة على المواصفات، احسم كيفية التعامل مع المدخلات التي قد تُفسر كصيغ في جداول البيانات، وسجّل تلك الأمثلة. فعبارة مثل «اجعل التصدير آمنًا» تترك للوكيل اختيار السياسة نيابةً عنك.

الخطة: دمج الميزة في التطبيق القائم

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

اختر أداة تحويل البيانات إلى CSV المعتمدة في المستودع إن وجدت. حدد ترويسات المحتوى والتنزيل، وسياسة تأمين الحقول، والسلوك عند الخطأ، والاختبارات. وأضف الزر مستخدمًا حالات التحميل والخطأ الحالية في التطبيق.

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

المهام: اجعل كل تغيير قابلًا للتحقق

حوّل الخطة إلى أعمال يستطيع المراجع تمييزها:

1. ثبّت السلوك الحالي لقائمة المهام وقواعد الترشيح المشتركة في فحوص عدم التراجع.
2. أضف اختبارات لصلاحيات الطلب تشمل المالك والعضو والمالك الذي أُزيلت ملكيته ومساحة عمل أخرى.
3. نفّذ الاستعلام المقيّد بالنطاق واستجابة CSV وفق سياسة الحقول المتفق عليها.
4. أضف عنصر التحكم في التصدير وحالة التحميل وطريقة عرض الفشل.
5. أكمل فحوص القبول، وافحص الفروق بحثًا عن تغييرات تتجاوز نطاق الميزة.

هذا تقسيم المهام في المثال الحالي. قد تولّد الأدوات قائمة مختلفة؛ والمعيار هو مدى تغطيتها لما اتُّفق عليه.

في تطبيق TypeScript، قد يشمل تغيير الكود المعروض للمراجعة server/exports/tasks.ts للصلاحيات والترشيح والاستجابة، وui/tasks/ExportButton.tsx للتفاعل، وtests/task-export.test.ts لحالات القبول. هذه مسارات توضيحية، وليست أعرافًا يفرضها إطار عمل. أما إضافة عامل جديد لطابور المهام أو ترحيل لقاعدة البيانات فتشير إلى تغيير في النطاق يجب حسمه قبل الدمج.

من معايير القبول إلى قرار الدمج

اطلب دليلًا على السلوك، لا مجرد قائمة بالملفات التي عدّلها الوكيل. ينبغي أن يربط وصف طلب السحب المتطلبات بفحوص مثل الآتية:

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

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

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

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

ما كلفة هذا الأسلوب، ومتى يستحقها؟

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

تتضمن قائمة الأسعار التجارية القياسية لدى Kiro خطة Free بسعر $0 شهريًا مع 50 وحدة رصيد، وخطة Pro بسعر $20 لكل مستخدم شهريًا مع 1,000 وحدة رصيد، قبل الضرائب المطبقة. لذلك تبلغ كلفة أربعة اشتراكات Pro 4 × $20 = $80 شهريًا، قبل الأرصدة الإضافية والضريبة. هذا حساب كلفة الاشتراكات، وليس توقعًا لعدد الميزات التي يمكنك إنجازها. صفحة الأسعار لدى Kiro.

تبلغ كلفة الأرصدة الإضافية المدفوعة $0.04 لكل وحدة رصيد. وتوضح Kiro أن تنقيح المواصفات وتنفيذ المهام وتشغيل خطافات الوكيل تستهلك أرصدة، وأن مهمة معقدة ضمن المواصفات قد تستهلك أكثر من وحدة رصيد. ولا يمكن وضع تحويل موثوق من «أرصدة» إلى «ميزات مكتملة» دون ملاحظة عبء العمل الفعلي. تعريف الأرصدة في Kiro.

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

أين تبدأ المبالغة، ومتى تصبح المواصفات عبئًا زائدًا؟

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

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

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

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

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

أبقِ الإصلاحات الصغيرة بسيطة حين يكون التغيير المطلوب واضحًا ومحدود الموضع: خطأ مطبعي، أو تعديل يتبع النمط المعتمد، أو خلل ضيق النطاق له اختبار واضح يمنع عودته. حدد السلوك المقصود وتحقق منه. قد تستهلك دورة كاملة من المبادئ والخطة والمهام انتباهًا أكثر مما يحتاجه التغيير.

معيار القرار ليس عدد أسطر الكود، بل عدد الافتراضات المؤثرة التي سيضطر الوكيل إلى اتخاذها من تلقاء نفسه.

أسبوعك الأول مع التطوير القائم على المواصفات

اختر ميزة صغيرة موجودة بالفعل في قائمة العمل. اطلب من مالكها اعتماد مواصفات للسلوك في صفحة واحدة، تتضمن ما يخرج عن النطاق وحالات الفشل. استخدم وكيلك الحالي في وضع التخطيط، أو المسار المقابل في Spec Kit أو Kiro، لاقتراح خطة تستند إلى المستودع الفعلي.

راجع الأسئلة قبل التنفيذ. واطلب قائمة مهام مرتبطة بالمتطلبات. عند مراجعة طلب السحب، قارن الأدلة بالاتفاق نفسه وسجّل القرارات التي تغيرت. واجعل حجم العملية متناسبًا مع مقدار الغموض الذي تعالجه.

اشترك في النشرة البريدية للاطلاع على طرق عملية للبناء والتشغيل باستخدام الذكاء الاصطناعي.