ที่ปรึกษาตรวจลดค่าใช้จ่ายคลาวด์

หาจุดลดค่าคลาวด์ที่ได้ผลจริง เรียงตามความคุ้ม และตัดข้อเสนอที่แลกความเสถียรกับเงินเล็กน้อยทิ้ง

ยังไม่มีรีวิว อัปเดตเมื่อ 2026-08-03

ดาวน์โหลดไฟล์คัดลอกปลดล็อกด้วย Premiumนำไปใช้งานได้ทันที

อัปเกรดเป็น Premium เพื่อคัดลอกหรือดาวน์โหลดคำสั่งนี้ — รายละเอียดทั้งหมดด้านบนยังอ่านได้ตามปกติ

Prompt/Skill.md นี้มีเฉพาะฉบับภาษาอังกฤษ

ทั้งโค้ด ชื่อ API และแฟล็ก CLI จะเพี้ยนเมื่อแปล และภาษาอังกฤษยังใช้ Token น้อยกว่ามาก

การตรวจค่าใช้จ่ายมักไล่ตามรายการที่เห็นง่าย ไม่ใช่รายการที่แพงจริง Prompt นี้เริ่มจากสัดส่วนค่าใช้จ่ายจริงในบิล แยกของที่เสียเปล่าออกจากกำลังสำรองที่ตั้งใจกันไว้ คำนวณความคุ้มเทียบกับเวลาวิศวกรที่ต้องใช้ และทำเครื่องหมายข้อที่ลดความทนทานของระบบ

ภาพรวม

ชุดคำสั่งในหมวด โครงสร้างระบบและ DevOps · กลุ่มเทคโนโลยีและนักพัฒนา

ปัญหาที่คำสั่งนี้เข้าไปแก้

ตรวจบิลคลาวด์ที่เพิ่มขึ้นทุกเดือน
จัดลำดับการลดค่าใช้จ่ายตามแรงที่ลงและผลที่ได้
เลี่ยงการตัดที่ทำให้ระบบเสี่ยงล่ม

ข้างในไฟล์มีอะไรบ้าง

8 ส่วน · 5 ขั้นตอน · 26 ข้อกำหนด เรียงมาให้ AI คิดครบก่อนตอบ

Step 0 — Attribution before optimisation
Intake — ระบุข้อมูลที่คุณต้องป้อนเอง เพราะ AI ไม่มีทางรู้แทนคุณได้
Step 1 — Follow the distribution
Step 2 — Classify each cost
Step 3 — Quantify each action

รูปแบบไฟล์และเงื่อนไขการเข้าถึง

ไฟล์ Markdown ไฟล์เดียวจบ ใช้ได้กับ ChatGPT, Claude, Gemini
ดาวน์โหลดและคัดลอกเฉพาะบัญชี Premium
มีเฉพาะฉบับภาษาอังกฤษ — งานเทคนิคที่แปลแล้วความหมายเพี้ยน

เหมาะกับใคร

เขียนสำหรับ System Admin, DevOps โดยให้ AI ทำหน้าที่เป็น DevOps Engineer / System Architect

กลุ่มที่ได้ประโยชน์มากที่สุด

System Admin, DevOps
คนที่ทำงานด้านโครงสร้างระบบและ DevOps เป็นครั้งคราว ไม่อยากเริ่มจากศูนย์ทุกครั้ง
คนที่ใช้ AI อยู่แล้วแต่ผลยังไม่นิ่ง ได้บ้างไม่ได้บ้าง

สถานการณ์ที่หยิบไปใช้ได้ทันที

เหมาะกับงานเหล่านี้: ออกแบบ System Architecture เขียน Dockerfile และวางระบบ CI/CD

สิ่งที่ควรรู้ก่อนเริ่ม

เป็นคำสั่งระดับ Premium การดาวน์โหลดและคัดลอกต้องใช้บัญชี Premium แต่เนื้อหาอธิบายทั้งหมดในหน้านี้เปิดให้อ่านฟรี
ไฟล์เป็นภาษาอังกฤษอย่างเดียว — เนื้อหาเทคนิคที่แปลแล้วความหมายเพี้ยน แต่คุยกับ AI เป็นไทยได้ตามปกติ
ยังต้องตรวจเอง จุดที่ควรตรวจก่อนเสมอคือตัวเลข ชื่อบุคคล ชื่อองค์กร และลิงก์อ้างอิง

เมื่อไหร่ที่ควรใช้คำสั่งอื่นแทน

ถ้าโจทย์ไม่ใช่งานด้านโครงสร้างระบบและ DevOps คำสั่งนี้จะวางกรอบผิดตั้งแต่บรรทัดแรก เลือกจากหมวดที่ตรงกว่า

รีวิว

ยังไม่มีรีวิว มาเป็นคนแรกเลย!

เขียนรีวิว

เทคนิคการปรับแต่ง

ใช้ได้ทันทีโดยไม่ต้องกรอกตัวแปร แต่ยังมีจุดปรับได้ เรียงจากจุดที่ให้ผลมากไปน้อย

ปรับความเข้มของข้อกำหนด

ข้อกำหนดคือคันบังคับถัดไป แก้ครั้งละจุดแล้วเทียบผล

ระบุกลุ่มผู้อ่านให้แคบลง เช่น จาก “ลูกค้าทั่วไป” เป็น “เจ้าของร้านอายุ 30–45 ปีที่ไม่ถนัดศัพท์เทคนิค”
คำสั่งนี้ยังไม่ได้กำหนดโทนไว้ ถ้าอยากได้เสียงที่คงที่ทุกครั้ง ให้เพิ่มหนึ่งบรรทัดระบุโทนที่ต้องการลงไปเอง

ใช้ได้ทันที และต่อยอดได้

คำสั่งนี้ใช้งานได้ทันทีโดยไม่ต้องแก้ ถ้าจะปรับ แนะนำให้เก็บต้นฉบับไว้เวอร์ชันหนึ่งเสมอ แล้วแก้บนสำเนา เพราะเมื่อปรับไปหลายรอบจนผลลัพธ์เพี้ยน คุณจะยังมีจุดตั้งต้นให้กลับไปเทียบได้

ต่อเป็น Workflow หลายขั้น

เอาผลจากคำสั่งนี้ไปเป็นข้อมูลตั้งต้นของคำสั่งถัดไปในหมวดโครงสร้างระบบและ DevOps ร่างก่อนแล้วค่อยส่งต่อให้ตรวจ ได้ผลดีกว่าสั่งทุกอย่างรอบเดียว

ผลลัพธ์ที่จะได้รับ

ได้อะไรกลับมา และอะไรที่คำสั่งนี้ไม่ทำให้

หน้าตาของคำตอบ

หัวข้อ “Output contract” ล็อกรูปแบบไว้ 8 องค์ประกอบ ผลจึงมีโครงเดิมทุกครั้ง

จัดลำดับการแก้ตามเงินที่ประหยัดต่อเดือนเทียบกับวันทำงานวิศวกร ให้เริ่มที่การติด Tag ก่อนเพราะเป็นเงื่อนไขจำเป็น และเตือนว่ามีข้อเสนอหนึ่งที่จะทำให้ระบบไม่มีตัวสำรอง

สิ่งที่คำสั่งนี้จะไม่ทำ

ข้อจำกัดเหล่านี้ตั้งใจใส่ไว้ — คำตอบที่ยอมบอกว่าไม่รู้ มีประโยชน์กว่าคำตอบที่มั่นใจแต่ผิด

“Constraints” ระบุสิ่งที่ห้ามทำไว้ชัดเจน 4 ข้อ คำตอบที่ข้ามข้อห้ามเหล่านี้ถือว่าไม่ผ่าน

วิธีดูว่ารอบนี้ได้ผลดีหรือยัง

สัญญาณของรอบที่ดี คือคำตอบอ้างอิงข้อมูลที่คุณให้จริง ไม่ใช่ตัวอย่างสมมติ ถ้า AI ถามกลับ แปลว่าคำสั่งทำงานถูกต้อง คำตอบที่กว้างจนใช้กับใครก็ได้ มักเกิดจากวงเล็บที่ยังไม่ได้แทนค่า