بازاندیشی در تقسیم هزینه ها: رویکردی مبتنی بر نمودار با یکپارچه سازی LLM

خلاصه پیادهسازی تفکیک هزینه با گراف و هوش مصنوعی (200 کلمه)
پیادهسازیهای سنتی تفکیک هزینه، کاربران را با درهمریختگی جداول زمانی و دشواری مرور رویدادهای خاص رها میکنند. راهحل پیشنهادی مبتنی بر مدل گراف است: گرهها نماد افراد، لبههای جهتدار بیانگر بدهی (مثلاً A → B یعنی «A به B بدهکار است»)، و وزنهها معادل مبلغ هستند. اضافه کردن هر هزینه (مانند ناهار ۱۲۰ دلاری آلیس با تقسیم مساوی)، ایجاد لبههای جدیدی مانند باب → آلیس ۴۰ دلار و چارلی → آلیس ۴۰ دلار را به دنبال دارد.
این سیستم با معماری MCP (پروتکل بافت مدل) و استفاده از ADK گووالگوی گو، رابط مکالمه طبیعی ایجاد میکند. کاربران بدون نیاز به فرمها یا منوها، هزینهها را به سادگی ثبت میکنند:
- افزودن هزینه با وزن نامساوی (مثل بلیت تئاتر ۱۰۰ دلاری باب با وزنهای
آلیس:۱، باب:۲، چارلی:۱). - دریافت تسویه شفاف (مثلاً «باب باید ۱۵ دلار به آلیس بپردازد»).
نقطه برجسته قابلیت نمایش بصری گراف خروجی DOT است که با Graphviz قابل تجسم است. این روندی برای ردیابی دقیق بدهیها و تایید منطق تسویه فراهم میکند، برخلاف ابزارهای کورکورانه. ترکیب مدلسازی گراف با رابط گفتاری، همترازی شناختی طبیعی، عیبیابی آسان و انعطافپذیری در تقسیم هزینه (مساوی/وزنی/درصدی) را ممکن میسازد. معماری مبتنی بر MCP همچنین ادغام با پلتفرمهای متنوع (например Claude Code عاملهای سفارشی) را تسهیل میکند.
مشکل با انشعابات هزینه های سنتی
اگر تا به حال از ابزارهای تقسیم هزینه های گروهی استفاده کرده اید، این تمرین را می دانید: مفهوم عالی، اما بسیاری از پیاده سازی ها چیزی را به دلخواه می گذارند. یک نقطه درد رایج زمانی است که جدولهای زمانی هزینههای گروههای مختلف را ترکیب میکنند و تمرکز بر یک سفر یا رویداد خاص را دشوار میکند. آیا می خواهید فقط هزینه های تعطیلات آخر هفته خود را به سرعت مرور کنید؟ ممکن است متوجه شوید که در حال پیمایش صورتحسابهای نامرتبط و انشعابات شام از گروههای دیگر هستید.
این الگوی طراحی غیر شهودی مرا به این فکر انداخت: باید راه بهتری وجود داشته باشد.
مدل ذهنی مبتنی بر نمودار
پیشرفت زمانی حاصل شد که متوجه شدم تقسیم هزینه اساساً یک مشکل است مشکل نمودار. در اینجا سادگی ظریف است:
- گره ها نماینده افراد گروه شما
- لبه های جهت دار نشان دهنده پول بدهکار است (A → B یعنی A به B بدهکار است)
- وزنه های لبه مقادیر هستند
وقتی هزینه ای را اضافه می کنید، اساساً لبه هایی را در این نمودار ایجاد می کنید. اگر آلیس برای ناهاری که به طور مساوی بین سه نفر تقسیم می شود 120 دلار بپردازد، باب 40 دلار و چارلی 40 دلار بدهکار است. این دو لبه است: باب → آلیس (40 دلار) و چارلی → آلیس (40 دلار).
این مدل ذهنی شهودی است زیرا منعکس کننده طرز تفکر طبیعی ما در مورد بدهی ها است: «من ۴۰ دلار به آلیس بدهکارم» یک رابطه هدایت شده با ارزش است.
تقسیم کننده هزینه های ساختمان
مسلح به این بینش، من تقسیم هزینه را به عنوان یک ابزار مبتنی بر نمودار ساختم. تصمیمات کلیدی طراحی:
- جداسازی گروه: هر گروه گراف جداگانه خود را دارد. هزینه های سفر ناپا شما هرگز با خدمات آب و برق آپارتمان شما ترکیب نمی شود.
- تقسیم انعطافپذیر: پشتیبانی از تقسیمهای مساوی، تقسیمهای وزنی، و تقسیمهای مبتنی بر درصد – همه بهطور تمیز به محاسبات لبه ترجمه میشوند.
- تسویه حساب های پاک: نمودار محاسبه اینکه چه کسی به چه کسی بدهکار است را بی اهمیت می کند. دیگر خبری از زنجیره های گیج کننده «آلیس به باب می پردازد که به چارلی می پردازد» وجود ندارد – فقط تسویه حساب های مستقیم.
ادغام MCP: جایی که جالب می شود
اینجاست که ابزار مدرن هوش مصنوعی تجربه را تغییر می دهد. من تقسیمکننده هزینه را بهعنوان یک ابزار MCP (پروتکل بافت مدل) بستهبندی کردم و با استفاده از کیت توسعه نماینده Google (ADK) در Go، یک نماینده ساختم.
نتیجه؟ یک رابط مکالمه که در واقع بصری است:
User: let's do expense splitting
Agent: I can help with that! First, let's create a group.
What would you like to name it?
User: create a group called napa-trip
Agent: Great! I've created a group called 'napa-trip'.
Now, who are the members of this group?
User: add alice, bob, charlie to the group
Agent: I've added Alice, Bob, and Charlie to the napa-trip group.
Now, let's add some expenses...
بدون کلیک روی فرم ها بدون منوهای کشویی فقط مکالمه طبیعی
اضافه کردن هزینه ها به طور طبیعی
جادوی واقعی هنگام اضافه کردن هزینه ها نشان می دهد:
User: add an expense by alice for lunch. 120$
Agent: I've added a $120 expense for lunch, paid by Alice.
What's the next expense?
User: it's for snacks and drinks by charlie. 60$
Agent: Got it. $60 for snacks and drinks, paid by Charlie, has been added.
حتی شکاف های پیچیده نیز طبیعی هستند:
User: add an expense by bob for show tickets with unequal weights
Agent: Okay, Bob paid for show tickets with unequal weights.
What was the total amount? And how would you like to split
the weights among Alice, Bob, and Charlie?
User: 100
Agent: And what are the unequal weights for Alice, Bob, and Charlie?
User: alice: 1, bob:2, charlie:1
Agent: I've added the $100 expense for show tickets, paid by Bob,
with the following weights: Alice 1, Bob 2, Charlie 1.
باب 100 دلار پرداخت کرد اما سهم او (وزن 2 از 4 کل) 50 دلار بود، بنابراین او در واقع فقط 50 دلار بدهکار است.
سود: تسویه حساب های روشن
هنگامی که آماده استقرار هستید:
User: get group details now
Agent: Here are the details for the 'napa-trip' group:
**Members:** Alice, Bob, Charlie
**Settlement Details:**
- Bob needs to pay Alice $15
- Charlie needs to pay Alice $20
- Charlie needs to pay Bob $5
تجسم نمودار: علامت گذاری نقطه
یکی از مزایای مدل سازی هزینه ها به عنوان یک نمودار این است که شما می توانید ساختار را در واقع مشاهده کنید. این ابزار نمودار را در نماد DOT صادر می کند، که می تواند با استفاده از Graphviz تجسم شود:
digraph "napa-trip" {
"alice" [label="alice"];
"bob" [label="bob"];
"charlie" [label="charlie"];
"alice" -> "bob" [label="$25.00"];
"alice" -> "charlie" [label="$20.00"];
"bob" -> "alice" [label="$40.00"];
"bob" -> "charlie" [label="$20.00"];
"charlie" -> "alice" [label="$40.00"];
"charlie" -> "bob" [label="$25.00"];
}

این نمودار کامل بدهی را نشان می دهد که هر تعهد فردی را نشان می دهد. توجه داشته باشید که این نمودار خامی است که تمام بدهی های زوجی از هر هزینه را نشان می دهد. سپس الگوریتم تسویه این را ساده می کند:
- آلیس 25 دلار به باب بدهکار است اما باب به آلیس 40 دلار بدهکار است → خالص: باب به آلیس 15 دلار بدهکار است
- چارلی به آلیس 40 دلار بدهکار است اما آلیس به چارلی 20 دلار بدهکار است → خالص: چارلی به آلیس 20 دلار بدهکار است
- چارلی 25 دلار به باب بدهکار است اما باب 20 دلار به چارلی بدهکار است → خالص: چارلی به باب 5 دلار بدهکار است
زیبایی نمایش گراف در شفافیت آن است. شما می توانید:
- آن را تجسم کنید: برای مشاهده شبکه تعهدات، در هر ابزار Graphviz قرار دهید
- اشکال زدایی کنید: دقیقاً ببینید که هر هزینه چگونه در تسویه حساب نهایی نقش داشته است
- آن را ممیزی کنید: ریاضیات را با ردیابی از طریق لبه ها تأیید کنید
- آن را درک کنید: نمایش بصری منطق حل و فصل را آشکار می کند
این سطح از شفافیت در ابزارهای تقسیم هزینه نادر است. اکثر آنها جعبه های سیاهی هستند که در آن هزینه ها را وارد می کنید و بدون اینکه منطق اساسی را ببینید، تسویه حساب می کنید. با افشای نمودار، کاربرانی که میخواهند بفهمند چرا مبلغ مشخصی بدهکار هستند، میتوانند آن را از طریق ساختار ردیابی کنند. تمیز، حداقل، و به طور مستقیم از ساختار نمودار مشتق شده است. بدون انتقال میانی، بدون سردرگمی.
چرا این مهم است
ترکیبی از یک مدل داده های صوتی (نمودارها) و یک رابط بصری (هوش مصنوعی مکالمه) چیزی واقعاً بهتر از راه حل های موجود ایجاد می کند:
- هم ترازی شناختی: مدل نمودار با طرز فکر ما در مورد بدهی ها مطابقت دارد
- حفظ زمینه: گروهها از هم جدا میمانند و مرور رویدادهای خاص را آسان میکنند
- سهولت مکالمه: بدون رابط کاربری برای یادگیری، فقط آنچه را که می خواهید توصیف کنید
- توسعه پذیری: ابزارهای MCP را می توان با پلتفرم های مختلف هوش مصنوعی (Claude Code، عوامل سفارشی و غیره) ادغام کرد.
معماری فنی
برای علاقه مندان، پشته این است:
منطق اصلی: محاسبه تسویه مبتنی بر نمودار پیاده سازی شده در برو
لایه MCP: در معرض به عنوان ابزار پروتکل بافت مدل پیاده سازی شده در برو
عامل: ساخته شده با کیت توسعه نماینده Google – ADK in Go
رابط: زبان طبیعی از طریق LLM
انتزاع MCP به این معنی است که همان ابزار را می توان از ابزارهای CLI مانند Claude Code، رابط های وب یا عوامل سفارشی استفاده کرد – هر کجا که بتوانید یک LLM را متصل کنید.
نتیجه گیری
گاهی اوقات بهترین راه حل ها از عقب رفتن و پرسیدن: “ساختار اساسی این مشکل چیست؟” برای تقسیم هزینه، شناخت ماهیت نمودار بدهی ها و تعهدات بود.
در ترکیب با ابزار مدرن هوش مصنوعی، ما در نهایت میتوانیم رابطهایی بسازیم که به همان اندازه طبیعی باشد که از یک دوست بپرسیم: “هی، من به شما چه چیزی مدیونم؟”
این کد گواهی بر این است که چگونه انتزاعات خوب – هم در مدل سازی داده ها و هم در رابط های ابزار – می توانند تجربه کاربر را از خسته کننده به لذت بخش تبدیل کنند.
آیا ناامیدی مشابهی را با ابزارهای موجود تجربه کرده اید؟ من دوست دارم در مورد مشکلاتی که با بازنگری در مدل داده های بنیادی حل کرده اید بشنوم.



