গাইড

AI app builder-এর জন্য prompt কীভাবে লিখবেন (আগে-পরের উদাহরণসহ)

AI app builder-এর জন্য একটি ভালো prompt কোডের নয়, product-এর বর্ণনা দেয়: কে এটি ব্যবহার করে, ধাপে ধাপে তারা কী করে, এটি কোন ডেটা রাখে, আর কে কী দেখতে পারে। প্রথম সংস্করণ তৈরি হওয়ার পর প্রতি বার্তায় একটি নির্দিষ্ট পরিবর্তন চান, বলুন কোনটি একই থাকতে হবে, আর সমস্যাগুলো "আমি X করলাম, Y আশা করেছিলাম, Z পেলাম" এই আকারে বর্ণনা করুন। এই তিনটি অভ্যাসই বেশিরভাগ হতাশাজনক ফলাফল ঠিক করে দেয়।

এই গাইডের বাকি অংশে প্রতিটি ধরন বিস্তারিতভাবে দেখানো হয়েছে, আগে-পরের উদাহরণসহ, যা আপনি নিজের মতো করে বদলে নিতে পারবেন।

app builder-কে prompt দেওয়া কেন একটি chat-এর সঙ্গে আলাদা

কোনো chat assistant-কে প্রশ্ন করলে অস্পষ্ট prompt-এ অস্পষ্ট উত্তর আসে, আর আপনি এগিয়ে যান। কিন্তু AI app builder-কে prompt দিলে উত্তর হয় একটি চলমান program। আপনার বর্ণনার প্রতিটি ফাঁক একটি অনুমান দিয়ে ভরে যায়, আর সেই অনুমানগুলো কোড, database table আর screen হয়ে যায়, যেগুলো নিয়ে আপনাকে বাঁচতে হয় বা উল্টে ফেলতে হয়।

তাই prompt-এর লক্ষ্য চালাক শোনানো নয়। লক্ষ্য হলো গুরুত্বপূর্ণ সিদ্ধান্তগুলোর কম অংশ ভাগ্যের ওপর ছেড়ে দেওয়া। এর জন্য প্রযুক্তিগত শব্দভাণ্ডারের দরকার নেই। দরকার শুধু সেই বিষয়গুলো নির্দিষ্ট করে বলা যা কেবল আপনি জানেন: আপনার ব্যবহারকারী, আপনার কাজের প্রবাহ আর আপনার নিয়মগুলো।

প্রথম prompt-এ কী যোগ করবেন

কিছু লেখার আগে এই প্রশ্নগুলোর উত্তর দিন। প্রতিটি এমন একটি ফাঁক বন্ধ করে যেখানে AI অন্যথায় অনুমান করত।

যা যোগ করবেনকেন গুরুত্বপূর্ণউদাহরণ
এক বাক্যে productপরের সব সিদ্ধান্তের কাঠামো ঠিক করে"দুটি চেয়ারের একটি নাপিতের দোকানের জন্য একটি booking সাইট"
কে ব্যবহার করেscreen ও ভাষার স্টাইল ঠিক করে"ফোনে আসা walk-in গ্রাহক, আর ল্যাপটপে মালিক"
মূল flow, ধাপে ধাপেপ্রথমে যা অবশ্যই কাজ করতে হবে"একটি সেবা বাছুন, একটি সময় বাছুন, নাম ও ফোন লিখুন, নিশ্চিতকরণ পান"
কোন ডেটা রাখেdatabase-এর নকশা হয়ে যায়"সেবা, booking, গ্রাহক"
কে কী দেখতে বা বদলাতে পারেlogin ও অনুমতি ঠিক করে"শুধু মালিক সব booking দেখতে পান"
চেহারা ও অনুভূতি, সংক্ষেপেসাধারণ ডিফল্ট স্টাইল এড়ায়"গাঢ়, সরল, বড় বোতাম"
এখনকার জন্য কী বাদপ্রথম সংস্করণকে ছোট রাখে"আপাতত কোনো payment বা review নেই"

শেষ সারিটিকে কম গুরুত্ব দেওয়া হয়। আপনি যা চান না তা বললে AI এমন blog, pricing পেজ আর newsletter signup যোগ করা থেকে বিরত থাকে, যা আপনি কখনও চাননি।

আগে-পরে: প্রথম prompt

আগে:

আমার জিমের জন্য একটি অ্যাপ বানিয়ে দাও।

Builder-কে সবকিছু অনুমান করতে হবে: সদস্য না কর্মী? ক্লাস না ব্যক্তিগত প্রশিক্ষণ? Payment? আপনি এমন কিছু পাবেন যা জিমের ওয়েবসাইটের মতো দেখায়, কিন্তু আপনার দরকারি কিছুই করে না।

পরে:

একটি ছোট যোগ ব্যায়াম স্টুডিওর জন্য একটি class booking অ্যাপ বানাও। সদস্যরা এই সপ্তাহের ক্লাস দেখবে (নাম, প্রশিক্ষক, সময়, কতটি আসন খালি আছে), একটি আসন বুক করবে, আর দুই ঘণ্টা আগে পর্যন্ত বাতিল করতে পারবে। সদস্যরা email ও password দিয়ে সাইন আপ করবে। স্টুডিওর মালিক লগইন করে ক্লাস যোগ করবেন, কে বুক করেছে দেখবেন, আর উপস্থিতি চিহ্নিত করবেন। ক্লাস, সদস্য ও booking একটি database-এ রাখো। শান্ত, হালকা design যা ফোনে ভালো দেখায়। আপাতত কোনো payment নেই।

দ্বিতীয়টিও এখনও সংক্ষিপ্ত। এটি কেবল উপরের table-এর প্রশ্নগুলোর উত্তর দেয়।

আচরণ বর্ণনা করুন, বাস্তবায়ন নয়

কীভাবে বানাতে হবে তা না বলে কী ঘটবে তা বর্ণনা করলে প্রায়ই ভালো ফল পাওয়া যায়।

আগে:

একটি useEffect যোগ করো যা booking আনে, আর সম্পাদনার জন্য একটি modal component।

পরে:

মালিক কোনো booking-এ ক্লিক করলে একটি প্যানেল খুলবে, যেখানে সময় বদলানো বা বাতিল করা যাবে। বদলগুলো তালিকায় সঙ্গে সঙ্গে দেখা উচিত।

প্রথম prompt AI-কে একটি নির্দিষ্ট কৌশলে আটকে দেয়, যা অ্যাপটি যেভাবে বানানো হয়েছে তার সঙ্গে মাপসই নাও হতে পারে। দ্বিতীয়টি তাকে ফলাফল জানায় এবং সে আগে যে কোড লিখেছে তার জন্য সঠিক পদ্ধতি বেছে নিতে দেয়। আপনি developer হলে এবং শক্ত পছন্দ থাকলে তা বলুন, কিন্তু সঙ্গে ফলাফলটিও বলুন।

নিয়মগুলো নির্দিষ্ট করুন

AI-নির্মিত অ্যাপে সবচেয়ে বেশি ভুল হয় ব্যবসায়িক নিয়মে, কারণ সেগুলো আপনার কাছে স্পষ্ট কিন্তু AI-র কাছে অদৃশ্য। এগুলো খুলে লিখুন।

  • সীমা: "একজন সদস্য সর্বোচ্চ তিনটি ভবিষ্যৎ booking রাখতে পারবে।"
  • সময়: "ক্লাস শুরুর দুই ঘণ্টা আগে বাতিলের সুযোগ শেষ হবে।"
  • Edge case: "ক্লাস ভর্তি হয়ে গেলে Book-এর বদলে একটি waitlist বোতাম দেখাও।"
  • অনুমতি: "প্রশিক্ষকরা নিজের ক্লাসের উপস্থিতি দেখতে পারবেন, অন্য প্রশিক্ষকদের নয়।"

এর প্রতিটি এক বাক্যের। এর কোনোটি বাদ গেলে অ্যাপটি হয় নিয়মটি মানবে না, নয়তো নিজের মতো একটি সংস্করণ বানিয়ে নেবে।

প্রথম সংস্করণের পর: প্রতি বার্তায় একটি পরিবর্তন

Preview-তে কিছু চালু হওয়ার পর পুরো product বর্ণনা করা থেকে সরে ছোট, যাচাইযোগ্য পরিবর্তন চাওয়ায় যান।

আগে:

design ঠিক হয়নি, booking ঠিকমতো কাজ করছে না, আর আমি একটি calendar view ও email চাই।

পরে (চারটি আলাদা বার্তায়):

১. কোনো ক্লাসের শেষ আসনটি বুক করলে ক্লাসে এখনও "১টি আসন খালি" দেখায়। এর বদলে "Full" দেখানো উচিত এবং Book বোতাম লুকানো উচিত। ২. Schedule পেজে একটি সপ্তাহের calendar view যোগ করো, প্রতিদিনের জন্য একটি কলাম। বর্তমান list view-টি একটি বিকল্প হিসেবে রাখো। ৩. ফোনে ক্লাস কার্ড আরও ছোট করো: কম padding, আর প্রশিক্ষকের নাম সময়ের একই লাইনে। ৪. কেউ বুক করলে তাকে একটি নিশ্চিতকরণ email পাঠাও।

এটি কেন কাজ করে:

  • প্রতিটি পরিবর্তন এত ছোট যে AI এক পাসেই ঠিকমতো করতে পারে।
  • পরের ধাপে যাওয়ার আগে প্রতিটি আপনি পরীক্ষা করতে পারেন।
  • একটি ভুল হলে শুধু সেই ধাপটি উল্টে ফেলা যায়, বাকিগুলো না হারিয়ে।

কী রাখতে হবে তা বলুন

যা আগে থেকেই কাজ করছে তা বদলাতে বললে বলুন কী বদলানো যাবে না। এটি regression (সম্পাদনার পর আগে কাজ করা জিনিস ভেঙে যাওয়া) থামানোর সবচেয়ে সহজ উপায়।

Home পেজের hero নতুন করে বানাও, বড় headline আর ডানে একটি ছবি সহ। Navigation, রং আর hero-র নিচের সবকিছু ঠিক যেমন আছে তেমনই রাখো।

ডেটার ক্ষেত্রেও একই: "সদস্যদের একটি phone number ক্ষেত্র যোগ করো। বিদ্যমান কোনো ক্ষেত্র মুছো বা নাম বদলাও না।"

Screenshot ও হুবহু লেখা ব্যবহার করুন

"উপরের দিকের সেই জিনিসটা"-র মতো শব্দ অস্পষ্ট। বেশিরভাগ AI app builder ছবি গ্রহণ করে, আর একটি ছোট নোটসহ screenshot এক অনুচ্ছেদ বর্ণনার চেয়ে দ্রুত।

  • একটি screenshot সংযুক্ত করুন এবং বলুন "লাল বৃত্ত দেওয়া বোতামটি ফোনে menu-র উপর এসে পড়ছে"।
  • কোনো error message-এর হুবহু লেখা পেস্ট করুন, সংক্ষেপ না করে।
  • স্ক্রিনের label হুবহু উদ্ধৃত করুন: "Settings পেজের Save changes বোতাম"।

Bug-এর জন্য এই আকার ব্যবহার করুন:

Bookings পেজে, আগামীকালের একটি booking-এ আমি Cancel-এ ক্লিক করলাম। আশা করেছিলাম সেটি আমার তালিকা থেকে সরে যাবে। কিন্তু কিছুই হলো না, refresh করার পরও booking-টি আছে। এটি ঠিক করো এবং যাচাই করো যে বাতিল করা কাজ করছে।

AI দিয়ে বানানো অ্যাপের bug কীভাবে খুঁজবেন তা নিয়ে আমাদের AI দিয়ে বানানো অ্যাপের debug কীভাবে করবেন গাইডে আরও গভীরে যাওয়া হয়েছে।

বড় পরিবর্তনের আগে পরিকল্পনা নিন

অ্যাপের অনেক অংশ ছোঁয় এমন কিছুর জন্য — যে অ্যাপে আগে কোনো user account ছিল না সেখানে account যোগ করা, payment যোগ করা, বা ডেটার গঠন বদলানো — কোনো কোড বদলানোর আগে একটি পরিকল্পনা চান।

কিছু বদলানোর আগে ব্যাখ্যা করো কীভাবে team account যোগ করবে: কোন নতুন table লাগবে, কোন পেজগুলো বদলাবে, আর বিদ্যমান ব্যবহারকারীদের কী হবে। এখনই কোড বদলিও না।

পরিকল্পনাটি পড়ুন। সে কিছু ভুল বুঝে থাকলে একটি অনুচ্ছেদ শুধরানো, তৈরি হয়ে যাওয়া একটি feature শুধরানোর চেয়ে অনেক সস্তা। অনেক builder-এর এর জন্য আলাদা মোড থাকে; Mythex-এ এটি Plan মোড, যা Build ও Ask-এর পাশে থাকে।

যা এড়িয়ে চলবেন

যা এড়াবেনকেনবদলে যা করবেন
"আরও ভালো করো" / "চোখে পড়ার মতো করো"কোনো লক্ষ্য নেই, তাই AI এলোমেলোভাবে বদলায়পরিবর্তনটির নাম বলুন: "অংশগুলোর মাঝে আরও ফাঁকা জায়গা, বড় শিরোনাম"
দশটি feature সহ একটিমাত্র বিশাল promptভুল জমে যায়; পরীক্ষা করা কঠিনপ্রতি বার্তায় একটি feature
Chat-এ API key পেস্ট করাkey chat ইতিহাসে থেকে যায়Builder-এর secrets বা environment সেটিং ব্যবহার করুন
ভাঙা ফলাফল নিয়ে তর্ক করাপ্রতিটি সমাধান bug-এর ওপর জমেউল্টে ফেলুন, তারপর নতুন করে বলুন
যে কোড আপনি বোঝেন না তা নির্দিষ্ট করাএকটি দুর্বল মানানসই পথে আটকে দেয়আপনার চাওয়া আচরণ বর্ণনা করুন
"enterprise-grade security" চাওয়াএর কোনো নির্দিষ্ট অর্থ নেইআসল নিয়মগুলো তালিকা করুন: কে কী দেখতে পারবে

API key নিয়ে: যদি কোনো payment বা email সেবা লাগে, তার key prompt-এ না রেখে project-এর secrets-এ রাখুন। যদি এটি নতুন হয় তবে environment variable ও secrets কী দেখুন।

পুনর্ব্যবহারযোগ্য prompt টেমপ্লেট

বন্ধনীর অংশগুলো বদলে এগুলো নিজের মতো করে নিন।

নতুন অ্যাপ:

[কী ধরনের অ্যাপ] [কার] জন্য বানাও। তারা [মূল flow, ধাপে ধাপে]। [দ্বিতীয় ধরনের ব্যবহারকারী] [কী করার জন্য] লগইন করে। [ডেটা] একটি database-এ রাখো। [চেহারা ও অনুভূতি]। [পরের জন্য যা বাদ] রাখো।

নতুন feature:

[পেজ]-এ [feature] যোগ করো। যখন [ব্যবহারকারী] [কাজ] করবে, তখন [কী ঘটবে]। শুধু [কে] [এটি করতে] পারবে। [বিদ্যমান জিনিস] ঠিক যেমন আছে তেমন রাখো।

Design পরিবর্তন:

[পেজ]-এ [নির্দিষ্ট উপাদান]-কে [নির্দিষ্ট পরিবর্তন] করো। [যা রাখতে হবে] রাখো। ফোনের প্রস্থে ঠিক দেখাচ্ছে কি না যাচাই করো।

Bug:

[পেজ]-এ আমি [ধাপসমূহ] করলাম। আশা করেছিলাম [প্রত্যাশা]। কিন্তু [আসল ফল, হুবহু error লেখাসহ]। এটি ঠিক করো এবং যাচাই করো যে flow কাজ করছে।

পরিবর্তন ছাড়া প্রশ্ন:

কোনো কোড বদলিও না। ব্যাখ্যা করো [অ্যাপের অংশ] কীভাবে কাজ করে এবং [ডেটা] কোথায় রাখা হয়।

বড় spec লেখা

বড় project-এর জন্য প্রথমে একপাতার একটি brief লিখে সেটিকে শুরুর prompt হিসেবে পেস্ট করা সাহায্য করতে পারে: ব্যবহারকারী, মূল flow, ডেটা, নিয়ম আর কী scope-এর বাইরে। এটি লিখতেও AI-র সাহায্য নিতে পারেন — AI দিয়ে product requirements doc লেখা-র গাইডে কীভাবে তা আছে। শুধু প্রথম বানানোর অনুরোধটি মূল flow-তে সীমাবদ্ধ রাখুন, আর বাকিটা ধাপে ধাপে যোগ করুন।

Mythex-এ prompt দেওয়া

উপরের সবকিছু Mythex-এ কাজ করে। কয়েকটি নির্দিষ্ট বিষয় যা সাহায্য করে:

  • Build, Plan ও Ask মোড। বড় বা ঝুঁকিপূর্ণ পরিবর্তনে Plan ব্যবহার করুন, আর সম্পাদনা ছাড়া ব্যাখ্যা চাইলে Ask।
  • Checkpoint। প্রতিটি সফল পরিবর্তনের পর Mythex একটি checkpoint সংরক্ষণ করে, আর কোনো reply-তে Revert to this point ক্লিক করলে project সেই অবস্থায় ফিরে যায়। আগের কোনো বার্তা সম্পাদনা করে নতুন করে পাঠিয়ে সেই জায়গা থেকে ভিন্ন prompt চেষ্টাও করতে পারেন।
  • Secrets card। Agent-এর যখন কোনো API key লাগে, সে chat-এর একটি card-এর মাধ্যমে জিজ্ঞেস করে, যাতে মানটি আপনার বার্তায় লেখা না হয়ে project secret হিসেবে সংরক্ষিত হয়।
  • ছবি। Screenshot বা mockup সংযুক্ত করুন, agent সেগুলো দেখবে।

Docs-এ কার্যকর prompt নিয়ে একটি ছোট পাতা আছে, আর পুনর্নির্মাণ ছাড়া উন্নত করা নিয়েও একটি আছে। একেবারে শূন্য থেকে শুরু করলে, AI দিয়ে অ্যাপ কীভাবে বানাবেন একটি পূর্ণ project ধরে এগোয়, আর AI দিয়ে সুন্দর দেখতে অ্যাপ কীভাবে ডিজাইন করবেন চেহারার মান উন্নত করার prompt নিয়ে আলোচনা করে।

প্রশ্নোত্তর

AI app builder-এর জন্য prompt কত বড় হওয়া উচিত?

প্রথম সংস্করণের জন্য চার থেকে আট বাক্যের একটি ছোট অনুচ্ছেদই সাধারণত যথেষ্ট: অ্যাপটি কে ব্যবহার করে, মূল flow কী, এটি কোন ডেটা রাখে আর কে কী দেখতে পারে। এরপর একবারে একটি পরিবর্তন চেয়ে ছোট prompt দিলে লম্বা prompt-এর চেয়ে ভালো ফল পাওয়া যায়।

AI-কে কোন framework বা language ব্যবহার করতে হবে তা বলা উচিত?

শুধু তখনই, যখন এর পেছনে কারণ থাকে, যেমন কোনো developer পরে কোডের দায়িত্ব নেবেন, বা কোনো সেবা শুধু একটি stack-এর সঙ্গে কাজ করে। অন্যথায় product বর্ণনা করুন এবং builder-কে যুক্তিসঙ্গত ডিফল্ট বেছে নিতে দিন।

AI কেন এমন জিনিস বদলে দেয় যা আমি বদলাতে বলিনি?

সাধারণত প্রম্পটটি অস্পষ্ট ছিল ("এটিকে আরও ভালো করো") অথবা কী রাখতে হবে তা বলা ছিল না। ঠিক কোন জিনিসটি বদলাতে হবে তা নাম ধরে বলুন, কোনটি একই থাকতে হবে তা বলুন, আর প্রতি বার্তায় একটি পরিবর্তন চান।

খারাপ ফলাফল ঠিক করতে আরও prompt দেওয়া ভালো, নাকি নতুন করে শুরু করা?

শেষ পরিবর্তনের পর জিনিস খারাপ হলে তার আগের সংস্করণে ফিরে গিয়ে নতুন করে বলুন, উপরে উপরে আরও সমাধান স্তূপ না করে। নতুন project শুরু করুন শুধু তখন, যখন ধারণাটিই বদলে গেছে।

Mythex · Pricing · AI দিয়ে যা খুশি বানান · ওয়েবসাইট ও অ্যাপের টেমপ্লেট · Mythex-এর তুলনা · AI অ্যাপ তৈরির শব্দকোষ · AI অ্যাপ তৈরির বিনামূল্যের টুল · English

English አማርኛ العربية Български Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)