ตัวอย่าง MCP แบบครบขั้นตอน
ตัวอย่างเหล่านี้แสดงวิธีที่ผู้ช่วยควรเปลี่ยนคำถามธุรกิจเป็นการวิเคราะห์ DataGlass ที่ตรงประเด็น แต่ละเรื่องเริ่มจากคำถามของผู้ใช้ กำหนดขอบเขตที่ต้องใช้ เรียกเฉพาะเครื่องมือที่จำเป็นต่อหลักฐาน และจบด้วยคำตอบที่ช่วยให้ตัดสินใจได้
วิธีอ่านแต่ละตัวอย่าง
แต่ละตัวอย่างมี 5 ส่วน:
- ใช้เมื่อใด อธิบายการตัดสินใจและ baseline ที่ควรเปรียบเทียบ
- Prompt พร้อมคัดลอกและปรับใช้
- ลำดับเครื่องมือ แสดงขั้นตอนที่เล็กที่สุดแต่เพียงพอ พร้อมเหตุผลของแต่ละ call
- คำตอบตัวอย่าง สาธิตลำดับเนื้อหา caveat และขั้นตอนต่อไป
- รายการตรวจคุณภาพ ช่วยประเมินว่าผู้ช่วยตอบอย่างน่าเชื่อถือหรือไม่
เครื่องมือจะส่ง exact input schema ให้ผู้ช่วยที่เชื่อมต่อ ณ runtime ตารางด้านล่างจึงเน้นเจตนาทางธุรกิจ รหัสร้านและ region ต้องมาจากผล discovery เสมอ ห้ามคัดลอกจากตัวอย่าง
1. ตรวจสุขภาพร้าน 30 วัน
ใช้เมื่อใด
ใช้ตอนเริ่ม weekly review หรือเมื่อต้องการรู้ว่าร้านมีเรื่องเร่งด่วนหรือไม่ก่อนเลือกวิเคราะห์ต่อ เปรียบเทียบ 30 วันที่เลือกกับ 30 วันก่อนหน้าทันทีเพื่อให้ช่วงมีระยะเท่ากันและเห็นบริบทตามเวลา
Prompt
ตรวจสุขภาพร้าน Bangkok Home Studio บน Shopee สำหรับ 30 วันที่ผ่านมา เทียบกับ
30 วันก่อนหน้าทันที เริ่มด้วยข้อสรุปหนึ่งประโยค แล้วแสดงกำไรที่เกิดขึ้นจริง
GMV, margin, COGS coverage และสินค้าที่ขาดทุน จัดอันดับความเสี่ยงสำคัญไม่เกิน
3 รายการ ระบุวันที่จริงและสกุลเงิน THB พร้อมติดป้ายผลที่ใช้ COGS ที่อนุมาน
ลำดับเครื่องมือ
| ขั้น | เครื่องมือ | เหตุผลที่เรียก | หยุดหรือทำต่อ |
|---|---|---|---|
| 1 | list_shopee_shops | ค้นหา shopId, region, ชื่อร้าน และ timezone ที่บัญชีมีสิทธิ์ | หากไม่พบร้าน ให้หยุดและอธิบายอย่างชัดเจน |
| 2 | diagnose_shop | อ่าน headline, KPI delta, COGS coverage, loss-makers และ signal สำหรับช่วง 30 วัน | ปกติเพียงพอสำหรับคำตอบแรก |
| 3 | suggestedTool ของ signal | ยืนยัน warning สำคัญหนึ่งเรื่อง เช่น สินค้าหรือโฆษณา | เรียกเมื่อหลักฐานมีผลต่อข้อสรุปหรือผู้ใช้ขอรายละเอียด |
ผู้ช่วยไม่ควรเรียก endpoint การเงินและสินค้าทุกตัวหลัง diagnose_shop คำถามสุขภาพร้านแบบย่อถือว่าสมบูรณ์เมื่อ headline และความเสี่ยงหลักมีหลักฐานรองรับ
คำตอบตัวอย่าง
Bangkok Home Studio ต้องได้รับการตรวจสอบ: กำไรที่เกิดขึ้นจริงลดลง 8.4% เหลือ ฿136,420 ระหว่าง 17 มิถุนายน–16 กรกฎาคม ขณะที่ GMV แทบไม่เปลี่ยนที่ ฿928,600 (+0.7%)
- Margin ลดลง — warning Weighted margin ลดจาก 16.8% เป็น 14.7% (−2.1 percentage points) สินค้า margin ต่ำ 2 รายการอธิบายการลดลงของกำไร 71%
- สินค้าขาดทุน — warning สินค้า 6 รายการขาดทุนรวม ฿9,840 โดยรายการที่แย่ที่สุดขาดทุน ฿5,120
- ความมั่นใจของ COGS — ควรตรวจ Explicit COGS ครอบคลุม 82% ของ GMV อีก 18% ใช้ต้นทุนที่อนุมาน กำไรระดับสินค้าในส่วนนั้นจึงเป็นค่าประมาณ
จำนวนออเดอร์คงที่ สาเหตุหลักในตอนนี้จึงเป็น product mix มากกว่า demand ควรตรวจสินค้า 2 รายการที่กระทบกำไรติดลบก่อน ไม่มีข้อมูลร้านใดถูกเปลี่ยน
รายการตรวจคุณภาพ
- ข้อสรุปอยู่ก่อนรายละเอียดและใช้กำไรที่เกิดขึ้นจริง ไม่ใช่ payout
- ช่วงปัจจุบันและช่วงเปรียบเทียบมีระยะเท่ากันและระบุชัดเจน
- แสดงทั้งทิศทางและขนาดการเปลี่ยนแปลง โดยการเปลี่ยน margin ใช้ percentage points
- ติดป้าย COGS ที่อนุมานแทนการนำเสนอเป็นค่าที่แม่นยำ
- ตามเฉพาะ signal สำคัญที่จำเป็นต่อคำตอบ
2. อธิบายว่าทำไมกำไรลดลง
ใช้เมื่อใด
ใช้เมื่อกำไร ยอดขาย หรือ margin เปลี่ยนโดยไม่คาดคิด และต้องการสาเหตุที่จัดอันดับแล้วแทนภาพรวม dashboard อีกชุด ตัวอย่างนี้ใช้ Lazada เพื่อแสดงว่า unified diagnosis สามารถต่อไปยังหลักฐานการเงินและสินค้าของแต่ละแพลตฟอร์มได้
Prompt
ทำไมกำไรที่เกิดขึ้นจริงของ Northstar Living บน Lazada จึงลดลงในเดือนนี้
จนถึงปัจจุบัน เทียบกับช่วงก่อนหน้าที่มีจำนวนวันเท่ากัน จัดอันดับสาเหตุตาม
ผลกระทบต่อกำไร แยก product mix, ค่าธรรมเนียม, โฆษณา, COGS ที่หาย และ
ออเดอร์ที่ยังไม่ settle แสดงเฉพาะสินค้าเท่าที่จำเป็นต่อข้อสรุป
ลำดับเครื่องมือ
| ขั้น | เครื่องมือ | หลักฐานที่ได้ |
|---|---|---|
| 1 | list_lazada_shops | sellerId และ region ของ Northstar Living ที่มีสิทธิ์เข้าถึง |
| 2 | diagnose_shop | ทิศทางกำไร GMV, margin, ออเดอร์ COGS coverage และ signal ที่จัดอันดับแล้ว |
| 3 | get_lazada_financial_overview | P&L รวม การเปลี่ยนแปลงต้นทุน loss-makers และช่วงเปรียบเทียบ |
| 4 | rank_lazada_products_by_profit | สินค้าที่มีผลบวกและลบต่อกำไรรวมมากที่สุด |
| 5 | get_lazada_product_breakdowns | รายละเอียดเฉพาะสินค้าที่เป็นสาเหตุลบหลัก |
หาก diagnose_shop แสดงว่า unit economics คงที่แต่มี warning เรื่อง settlement timing ผู้ช่วยสามารถหยุดก่อนดึงข้อมูลสินค้า และอธิบายว่าเหตุใดช่วงล่าสุดยังไม่สมบูรณ์
คำตอบตัวอย่าง
กำไรที่เกิดขึ้นจริงลดลง ฿24,140 (−13.6%) ในเดือนนี้จนถึงปัจจุบัน การลดลงเป็นเรื่องจริง แม้อาจมีอีกประมาณ ฿1,600 จากออเดอร์ล่าสุดที่ยังไม่ settle
อันดับ สาเหตุ ผลกระทบต่อกำไรโดยประมาณ หลักฐาน 1 สัดส่วนเปลี่ยนไปยังสินค้า margin ต่ำ −฿12,480 สินค้าโปรโมต 2 รายการเพิ่มเป็น 29% ของ GMV แต่มี margin เพียง 7–9% 2 ค่าโฆษณาสูงขึ้น −฿7,120 Spend เพิ่ม 18% แต่กำไรที่เกิดขึ้นจริงจากโฆษณาไม่โต 3 คอมมิชชั่นและ service fee −฿2,940 สัดส่วนค่าธรรมเนียมจริงเพิ่ม 0.6 percentage points 4 การเปลี่ยนแปลงสินค้าอื่น −฿1,600 สินค้าที่เหลือมีการเปลี่ยนแปลงเล็กน้อยทั้งบวกและลบ COGS coverage คงที่ที่ 94% ต้นทุนที่หายจึงไม่ใช่สาเหตุหลัก ควรเริ่มจากสินค้าโปรโมต 2 รายการ เพราะอธิบายการลดลงได้มากกว่าค่าธรรมเนียมที่เพิ่มขึ้น
รายการตรวจคุณภาพ
- สาเหตุรวมกันได้ใกล้เคียงการเปลี่ยนแปลงทั้งหมดและเรียงตามผลกระทบ
- แยกหลักฐานที่ settle แล้วออกจากกิจกรรมล่าสุดที่ยังไม่สมบูรณ์
- ตรวจ COGS ก่อนสรุปว่ากำไรลดจริง
- แสดงเฉพาะสินค้าแกนนำ ไม่ dump catalog ทั้งหมด
- ไม่ตีความว่า GMV คงที่หมายถึงกำไรคงที่
3. หาโฆษณาที่ดูดีแต่ขาดทุน
ใช้เมื่อใด
ใช้เมื่อ ROAS ที่ Marketplace แสดงดูสูงแต่กำไรอ่อน หรือก่อนจัดสรรงบใหม่ Shopee และ TikTok Shop มีเครื่องมือโฆษณาใน curated MCP ส่วน Lazada campaign analysis ยังไม่อยู่ใน surface ที่คัดสรร
Prompt
ตรวจโฆษณา Shopee ของ Bangkok Home Studio ใน 30 วันที่ผ่านมา เรียงแคมเปญ
active จาก True ROAS ที่อ่อนที่สุด เปรียบเทียบ True ROAS กับ ROAS ที่
Marketplace แสดงและ profit-aware floor แล้วจัดแคมเปญสำคัญเป็น ลดงบ คงงบ
หรือพิจารณาเพิ่ม พร้อมอธิบายหลักฐานและห้ามนำการเปลี่ยนแปลงไปใช้
ลำดับเครื่องมือ
| ขั้น | เครื่องมือ | หลักฐานที่ได้ |
|---|---|---|
| 1 | list_shopee_shops | ร้านและ region ที่มีสิทธิ์ |
| 2 | get_shopee_ads_performance | แคมเปญ active, spend, attributed GMV, ออเดอร์ และ headline ROAS |
| 3 | get_shopee_corrected_roas | ผลที่ปรับการยกเลิกและคืนสินค้าสำหรับแคมเปญต้องสงสัย |
| 4 | get_shopee_campaign_profit_adjusted_roas | Profit-aware ROAS floor ที่บันทึกไว้สำหรับประเมินจุดคุ้มทุน |
| 5 | get_shopee_target_roas_recommendations | Target ที่เสนอสำหรับแคมเปญที่เกี่ยวข้องเมื่อมีข้อมูล |
สำหรับ TikTok Shop ให้ใช้ get_tiktok_gmv_max_campaigns เจาะ get_tiktok_gmv_max_sessions เฉพาะเมื่อต้องการระดับสินค้า ยืนยันด้วย get_tiktok_campaign_roas แล้วอ่านคำแนะนำงบหรือ target ROAS
คำตอบตัวอย่าง
หนึ่งในสี่แคมเปญสำคัญต่ำกว่า profit-aware floor แต่ Marketplace ROAS ทำให้ดูเหมือนมีประสิทธิภาพ
แคมเปญ Marketplace ROAS True ROAS Profit-aware floor การตัดสินใจ Storage Set Auto 5.2× 2.1× 2.8× ลด / ตรวจสอบ Linen Search 4.1× 3.4× 2.9× คง Kitchen Bundle 3.8× 3.6× 2.7× พิจารณาเพิ่มอย่างระมัดระวัง Brand Terms 6.4× 5.9× 3.1× คง แต่ volume จำกัด Storage Set Auto มีประสิทธิภาพลดลงหลังรวมการยกเลิก คืนสินค้า ค่าธรรมเนียม และ COGS DataGlass เสนอ target ROAS 3.0× ตอนนี้ยังไม่มีอะไรเปลี่ยน ถ้าต้องการ ผมนำไปใช้ด้วย
apply_shopee_target_roasได้ ซึ่งจะยกระดับเกณฑ์ของค่าโฆษณาจริงทันที และย้อนได้ด้วยrevert_shopee_target_roasหรือจะตรวจใน DataGlass ก่อนก็ได้
รายการตรวจคุณภาพ
- ใช้ True ROAS หรือ profit-adjusted ROAS ตัดสินใจ ไม่ใช่ headline ROAS เพียงอย่างเดียว
- ระบุช่วงวันที่และตัวกรองแคมเปญ active ชัดเจน
- พิจารณา spend volume ก่อนเพิ่มงบแคมเปญ ROAS สูง
- อธิบาย recommendation ว่าเป็นข้อเสนอ จนกว่าเครื่องมือเขียนข้อมูลจะทำงานจริง
- การเสนอให้นำไปใช้ต้องระบุชื่อเครื่องมือ ผลที่เกิดกับข้อมูลจริง และวิธีย้อนกลับ แล้วรอให้ผู้ใช้ยืนยัน
- แยก “ลด”, “คง” และ “พิจารณาเพิ่ม” พร้อมเหตุผล
4. แก้สินค้า margin ต่ำด้วยการจำลอง
ใช้เมื่อใด
ใช้เมื่อสินค้าขายได้แต่สร้างกำไรน้อยเกินไป หรือเมื่อต้องการเปรียบเทียบราคา ส่วนลด หรือ COGS ก่อนตัดสินใจ ตัวอย่างนี้ใช้ TikTok Shop และเก็บ product, SKU, campaign, advertiser และ shop ID ที่คืนมาเป็น string ทุกครั้ง
Prompt
หาสินค้า margin ต่ำที่มีผลกระทบมากที่สุดใน Good Day Official บน TikTok Shop
สำหรับ 30 วันที่ผ่านมา ตรวจว่า COGS เป็นค่าที่กรอก อนุมาน หรือหายไป จากนั้น
จำลองขึ้นราคา 5% โดยคงส่วนลด ค่าธรรมเนียม COGS และจำนวนขายเท่าเดิม
เปรียบเทียบกำไรต่อหน่วยและ margin ระหว่างปัจจุบันกับผลจำลอง ระบุสมมติฐาน
และห้ามเปลี่ยน listing
ลำดับเครื่องมือ
| ขั้น | เครื่องมือ | หลักฐานที่ได้ |
|---|---|---|
| 1 | list_tiktok_shops | shopId แบบ string และ region ที่ถูกต้อง |
| 2 | get_tiktok_financial_overview | Margin ร้าน loss-makers และ COGS coverage |
| 3 | get_tiktok_product_breakdowns | Margin ระดับสินค้าและผลกระทบต่อกำไรรวม |
| 4 | search แล้ว fetch | Canonical product และ TikTok product/SKU binding เมื่อต้องค้น identity |
| 5 | get_product_costs | ต้นทุนที่กรอก อนุมาน หรือหายไป |
| 6 | get_tiktok_product_profit | Forward unit economics ปัจจุบัน |
| 7 | simulate_tiktok_profit | สถานการณ์ read-only หนึ่งรายการที่ override ราคา 5% |
หนึ่ง simulation ควรแทนหนึ่งสถานการณ์ หากผู้ใช้ต้องการเปรียบเทียบราคา ส่วนลด และ COGS ให้รัน simulation แยก 3 รายการพร้อมชื่อกำกับ แทนการรวม override ที่ไม่เกี่ยวข้องไว้ในกรณีเดียว
คำตอบตัวอย่าง
สินค้า: Stackable Pantry Box, SKU
PBX-CLEAR-Mเหตุผลที่เลือก: ขาย 1,284 หน่วย แต่มี margin เพียง 6.8% ยอดขายสูงจึงทำให้เป็นความเสี่ยงสินค้า margin ต่ำที่ใหญ่ที่สุด COGS เป็นค่า กรอกจริง อัปเดตล่าสุด 2 กรกฎาคม
Metric ปัจจุบัน จำลองขึ้นราคา 5% เปลี่ยนแปลง ราคาขาย ฿429.00 ฿450.45 +฿21.45 กำไรต่อหน่วย ฿29.17 ฿48.02 +฿18.85 Margin 6.8% 10.7% +3.9 pp สมมติฐาน: อัตราส่วนลด ค่าธรรมเนียม Marketplace, COGS, การจัดสรร affiliate/ads และจำนวนขายคงเดิม นี่คือ unit-economics what-if ไม่ใช่ demand forecast และไม่มีการเปลี่ยน listing บน TikTok Shop
รายการตรวจคุณภาพ
- เลือกสินค้าจากผลกระทบรวม ไม่ใช่ percentage margin ต่ำที่สุดเพียงอย่างเดียว
- ระบุแหล่งและความใหม่ของ COGS ก่อนให้คำแนะนำ
- แสดงค่าปัจจุบันและค่าจำลองเทียบกัน
- เปิดเผยสมมติฐานคงที่ และไม่สื่อว่า volume จริงจะคงเดิม
- เก็บรหัส Marketplace เป็น string ภายใน แต่แสดงชื่อสินค้าที่เข้าใจง่ายก่อน
5. สร้างแผนเติมสต็อกโดยไม่สั่งซ้ำ
ใช้เมื่อใด
ใช้ใน replenishment review เพื่อตัดสินใจว่า SKU ใดต้องเติม ควรซื้อเท่าใด และ open purchase order ครอบคลุมความต้องการแล้วหรือไม่ เครื่องมือ inventory จำกัด scope ตาม inventory ของผู้ใช้ที่ยืนยันตัวตน ไม่ได้ route ด้วย shop ID ของ Marketplace
Prompt
สร้างแผนเติมสต็อกเร่งด่วน เริ่มจาก inventory alert ที่เปิดอยู่ ใช้จำนวน
reorder แบบ (s,S) และ forecast รายสัปดาห์ แล้วหักจำนวนจาก purchase order
ที่เปิดหรือกำลังเข้า จัดอันดับ SKU ตามความเสี่ยงขาดสต็อก แสดงสต็อกปัจจุบัน
จำนวนกำลังเข้า จำนวนใหม่ที่แนะนำ และหลักฐาน ห้ามสร้าง purchase order
ลำดับเครื่องมือ
| ขั้น | เครื่องมือ | หลักฐานที่ได้ |
|---|---|---|
| 1 | get_inventory_alerts | Open reorder-point alerts โดยแยกประวัติ resolved |
| 2 | get_reorder_plan | Reorder threshold และ target quantity ที่คำนวณตาม canonical variant |
| 3 | get_inventory_forecast | Demand รายสัปดาห์หรือรายเดือนที่คาดใน planning horizon |
| 4 | get_demand_chart | รูปแบบในอดีตและบริบท forecast เมื่อคำแนะนำผิดปกติ |
| 5 | get_open_purchase_orders | จำนวน open และ inbound ที่ต้องหักเพื่อไม่สั่งซ้ำ |
คำตอบตัวอย่าง
มี 3 SKU ที่ต้องดำเนินการตอนนี้ อีกหนึ่ง alert มีสต็อกเข้าครอบคลุมแล้ว จึงไม่ควรสร้างออเดอร์ใหม่
ลำดับ SKU มีอยู่ กำลังเข้า สั่งเพิ่ม หลักฐาน 1 ORG-WHT-L 42 0 180 Cover 2.1 สัปดาห์; supplier lead time 5 สัปดาห์; demand โต 12% 2 LIN-BGE-Q 18 25 75 ต่ำกว่า reorder point หลัง demand ที่คาด 3 สัปดาห์ 3 PBX-CLR-M 61 120 40 Plan แนะนำ 160 แล้วลดด้วยสต็อกเข้า 120 หน่วยที่ยืนยันแล้ว — RACK-BLK 35 200 0 Inbound order ครอบคลุมจำนวนที่ขาดทั้งหมด ให้ติดตามเท่านั้น ควรยืนยัน supplier lead time ของ ORG-WHT-L ก่อน ตัวเชื่อมต่อนี้ไม่ได้สร้างหรือแก้ purchase order
รายการตรวจคุณภาพ
- แยก open alert ออกจากประวัติ acknowledged, dismissed หรือ resolved
- ไม่คัดลอกจำนวนจาก reorder plan โดยไม่คิด แต่รวม inbound units แล้ว
- ใช้ forecast และ lead time อธิบายความเร่งด่วน
- แสดงการตัดสินใจสั่งศูนย์เมื่อสต็อกเข้าพอ
- ระบุว่าการซื้อยังเป็นการดำเนินการของผู้ใช้นอก MCP
6. กระทบยอด payout ของ Marketplace
ใช้เมื่อใด
ใช้เมื่อยอดฝากเงินจริงหรือยอดใน settlement report ต่างจากที่คาด Payout เป็นคำถามเรื่อง cash settlement ไม่ใช่ profitability ต้องใช้วันที่ payout หรือ settlement และเครื่องมือ payout ของแพลตฟอร์มเสมอ
Prompt
กระทบยอด Shopee payout ของ Bangkok Home Studio ระหว่าง 1–15 กรกฎาคม แสดง
payout ที่คาด ยอดที่ Shopee รายงาน ผลต่างที่แน่นอน และยอด paid เทียบ pending
ระบุออเดอร์หรือ adjustment line ที่อธิบาย mismatch ใช้วันที่ payout แสดง THB
และห้ามใช้กำไรที่เกิดขึ้นจริงแทน
ลำดับเครื่องมือ
| ขั้น | เครื่องมือ | หลักฐานที่ได้ |
|---|---|---|
| 1 | list_shopee_shops | Shop ID, region และ timezone ที่มีสิทธิ์ |
| 2 | get_shopee_payout | Expected escrow, ยอดที่ Marketplace รายงาน reconciliation delta, status และ order line สำหรับ inclusive payout dates |
| 3 | get_order | รายละเอียด normalized order เสริมสำหรับรายการสำคัญหนึ่งรายการจากผล payout |
สำหรับ TikTok Shop, get_tiktok_payout เปรียบเทียบ expected กับ bank-settlement statement ส่วน get_lazada_payout คืน net finance-statement settlement แยก paid/pending และไม่มีโครงสร้าง expected-versus-reported แบบเดียวกับ Shopee และ TikTok
คำตอบตัวอย่าง
สำหรับ payout dates 1–15 กรกฎาคม payout ที่คาดคือ ฿84,620.00 และ Shopee รายงาน ฿83,336.00 มีผลต่าง −฿1,284.00
- Paid: ฿80,910.00
- Pending: ฿2,426.00
- รายการปรับปรุงที่อธิบายผลต่าง: return fee −฿720, shipping adjustment −฿404, commission correction −฿160
- ส่วนที่ยังอธิบายไม่ได้: ฿0.00
รายการปรับปรุง 3 รายการอธิบายผลต่างได้ทั้งหมด จึงไม่มี reconciliation balance ที่ค้างอยู่ ไม่ควรเปรียบเทียบ payout นี้กับกำไรที่เกิดขึ้นจริงในวันเดียวกันโดยตรง เพราะ settlement timing และนิยาม metric ต่างกัน
รายการตรวจคุณภาพ
- ระบุชัดว่าใช้วันที่ payout หรือ settlement ไม่ใช่ order date
- ไม่ปน expected, reported, paid, pending และ delta เข้าด้วยกัน
- Adjustment line รวมกันตรงกับ delta โดยศูนย์หมายถึงตรงกันพอดี
- ใช้สกุลเงินท้องถิ่นและทศนิยมเมื่อการกระทบยอดต้องการความแม่นยำ
- ไม่ใช้เครื่องมือกำไรแทนหลักฐาน settlement
ปรับตัวอย่างไปใช้กับคำถามของคุณ
แทนชื่อร้าน Marketplace สินค้า และช่วงตัวอย่างด้วยการตัดสินใจของคุณ แต่ควรเก็บคำสั่งเชิงโครงสร้างที่ช่วยเพิ่มคุณภาพคำตอบ:
- กำหนด comparison baseline;
- ขอให้จัดอันดับสาเหตุหรือการตัดสินใจแทน raw export;
- บังคับให้ระบุวันที่ สกุลเงิน และความมั่นใจของ COGS;
- ให้ผู้ช่วยหยุดเมื่อหลักฐานรองรับข้อสรุปแล้ว;
- อธิบาย recommendation และ simulation ว่าเป็นข้อเสนอจนกว่าเครื่องมือเขียนข้อมูลจะทำงานจริง และกำหนดให้ผู้ช่วยระบุชื่อเครื่องมือ ผลที่เกิดกับข้อมูลจริง และวิธีย้อนกลับ ก่อนเสนอให้ลงมือ
ดูคำถามเริ่มต้นเพิ่มเติมใน คลัง prompt และดู input กับข้อจำกัดการ route ที่ รายการเครื่องมือ MCP