0

دانلود کتاب مهندسی نرم‌افزار بومی هوش مصنوعی – ساخت با عوامل هوش مصنوعی و توسعه مبتنی بر مشخصات

بازدید 115
  • عنوان کتاب: AI-Native Software Engineering
  • نویسنده: Alfonso Graziano
  • حوزه: مهندسی نرم‌افزار
  • سال انتشار: 2026
  • تعداد صفحه: 73
  • زبان اصلی: انگلیسی
  • نوع فایل: pdf
  • حجم فایل: 2.85 مگابایت

وقتی با یک عامل کدنویسی هوش مصنوعی تعامل می‌کنید، هر آنچه مدل در مورد وظیفه شما، کدبیس شما، استانداردهای کدنویسی شما و اهداف شما می‌داند، باید در یک مکان واحد قرار گیرد: پنجره زمینه. مدل نمی‌تواند فایل‌های شما را به ابتکار خود مرور کند، آنچه را که سه‌شنبه گذشته توافق کرده‌اید به خاطر بسپارد، یا کتابخانه تست ترجیحی تیم شما را جستجو کند، مگر اینکه چیزی در محیط آن آن اطلاعات را ارائه دهد. مدل فقط می‌تواند با آنچه دریافت می‌کند کار کند. و آنچه دریافت می‌کند، شما کنترل می‌کنید. این بینش پشت مهندسی زمینه است: آنچه بیشترین اهمیت را دارد این نیست که دستور شما چقدر هوشمندانه است. مهم این است که آیا مدل اطلاعات صحیح را برای استدلال خوب دریافت می‌کند یا خیر. دستور سیستم شما، فایل‌های قوانین شما، قطعه کدهایی که به آنها ارجاع می‌دهید، تعاریف ابزاری که زمان اجرا تزریق می‌کند، تاریخچه مکالمه‌ای که در طول جلسه جمع می‌شود: همه اینها در پنجره زمینه قرار می‌گیرند و آنچه را که عامل در مرحله بعد انجام می‌دهد، شکل می‌دهند. مهندسی زمینه، نظم و انضباطی است که باعث می‌شود آن زمینه به خوبی کار کند. این به معنای تصمیم‌گیری در مورد اینکه چه چیزی را شامل شود و چه چیزی را حذف کند، ساختاردهی اطلاعات به گونه‌ای است که توجه مدل به جایی که مهم است معطوف شود، و حفظ دقیق زمینه با تکامل جلسات و تغییر کدبیس‌ها است. یک سناریوی ساده را در نظر بگیرید: از عامل کدنویسی خود می‌خواهید که یک نقطه پایانی API جدید به یک سرویس Node.js اضافه کند. عامل چیزی می‌نویسد که منطقی به نظر می‌رسد. سپس فایل را باز می‌کنید و متوجه می‌شوید که از Moment.js استفاده می‌کند، که تیم شما دو سال پیش به دلیل اندازه بسته آن را منسوخ کرد. اعتبارسنجی Zod که معماری شما برای همه ورودی‌ها نیاز دارد را نادیده گرفته است. آزمایشی که نوشته یک تست واحد است، اما خط لوله CI شما روی پوشش تست ادغام دروازه می‌زند. هیچ چیز تولید شده توسط عامل در خلاصه اشتباه نبود – فقط برای سیستم شما اشتباه بود. وسوسه این است که دفعه بعد با نوشتن یک دستور دقیق‌تر پاسخ دهید. اما مسئله واقعی نحوه بیان درخواست شما نیست. مسئله این است که عامل هیچ زمینه‌ای در مورد ممنوعیت Moment.js، مورد نیاز بودن Zod یا در مورد قراردادهای تست شما نداشته است. اگر اطلاعات مربوطه قبل از شروع استدلال عامل، به طور قابل اعتمادی در متن وجود داشته باشد، هر سه مشکل از بین می‌روند. این مهندسی متن است. مهندسی متن با انتخاب ابزار و ساخت دستور متفاوت است، اگرچه همپوشانی دارند. انتخاب اینکه از Cursor یا Copilot استفاده شود، یا اینکه از Claude یا GPT-x به عنوان مدل زیربنایی استفاده شود، تصمیمات انتخاب ابزار هستند. فهمیدن اینکه چگونه یک درخواست را به طور واضح و دقیق بیان کنیم، همان ساخت سریع است. مهندسی زمینه لایه زیرین هر دو است: این مربوط به کلیت آنچه مدل هنگام شروع استدلال می‌بیند، صرف نظر از اینکه از کدام ابزار یا مدل استفاده می‌کنید، است.

When you interact with an AI coding agent, everything the model knows about your task, your codebase, your coding standards, and your intentions must arrive in a single place: the context window. The model can’t browse your files on its own initiative, remember what you agreed on last Tuesday, or look up your team’s preferred testing library unless something in its environment delivers that information. It can only work with what it receives. And what it receives, you control. That’s the insight behind context engineering: what matters most isn’t how clever your prompt is. It’s whether the model receives the right information to reason well. Your system prompt, your rules files, the code snippets you reference, the tool definitions the runtime injects, the conversation history that accumulates over the session: all of it lands in the context window and shapes what the agent does next. Context engineering is the discipline of making that context work well. It means deciding what to include and what to leave out, structuring information so the model’s attention lands where it matters, and keeping the context accurate as sessions evolve and codebases change. Consider a straightforward scenario: You ask your coding agent to add a new API endpoint to a Node.js service. The agent writes something that looks reasonable. Then you open the file and notice it uses Moment.js, which your team deprecated two years ago because of bundle size. It skipped the Zod validation your architecture requires for all inputs. The test it wrote is a unit test, but your CI pipeline gates on integration test coverage. Nothing the agent produced was wrong in the abstract–it was just wrong for your system. The temptation is to respond by writing a more detailed prompt next time. But the real issue isn’t how you phrased the request. It’s that the agent had no context about Moment.js being banned, about Zod being required, or about your testing conventions. All three problems would disappear if the relevant information were reliably already in the context before the agent started reasoning. That’s context engineering. Context engineering is different from tool selection and prompt crafting, though they overlap. Choosing whether to use Cursor or Copilot, or deciding whether to use Claude or GPT-x as the underlying model, are tool selection decisions. Figuring out how to phrase a request clearly and precisely is prompt crafting. Context engineering is the layer beneath both: it concerns the totality of what the model sees when it begins reasoning, regardless of which tool or model you’re using.

این کتاب را میتوانید از لینک زیر بصورت رایگان دانلود کنید:

Download: AI-Native Software Engineering

نظرات کاربران

  •  چنانچه دیدگاه شما توهین آمیز باشد تایید نخواهد شد.
  •  چنانچه دیدگاه شما جنبه تبلیغاتی داشته باشد تایید نخواهد شد.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

X