vibecodingthailand

งานโค้ดนักพัฒนา

อธิบาย Error Message ให้เข้าใจง่ายพร้อมแก้ทีละขั้นและป้องกันซ้ำ

พรอมต์สำหรับนักพัฒนาที่ต้องการอ่าน error message ที่ซับซ้อนให้เข้าใจง่าย รับคำแนะนำแก้ไขทีละขั้นตอน และเรียนรู้วิธีป้องกันไม่ให้ปัญหาเดิมเกิดซ้ำในอนาคต

6เทคนิค prompt engineering

3ตัวแปรปรับแต่งได้

ข้อความผลลัพธ์ตัวอย่าง

debuggingerror-messagecode-reviewtroubleshootingstep-by-step

ปรับและคัดลอกพรอมต์

เริ่มต้นที่นี่

ตัวอย่างผลลัพธ์ที่จะได้

ก่อนเริ่มลงมือปรับพรอมต์ ดูตัวอย่างผลลัพธ์ที่คุณจะได้จริงเพื่อให้แน่ใจว่าพรอมต์นี้ตรงกับงานที่ต้องการ

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

Live preview

สรุปปัญหา (What Went Wrong)

Error TypeError: Cannot read properties of undefined (reading 'map') เกิดขึ้นเมื่อ React พยายาม render component ProductList แต่ตัวแปรที่ควรเป็น array กลับมีค่าเป็น undefined ในขณะนั้น สาเหตุหลักคือข้อมูลจาก API ยังโหลดไม่เสร็จในรอบ render แรก ทำให้ .map() ไม่สามารถทำงานบน undefined ได้ ปัญหานี้อยู่ที่บรรทัดที่ 12 ของไฟล์ ProductList.jsx

สาเหตุที่เป็นไปได้ (Root Causes)

State ไม่มี default value (พบบ่อยที่สุด): useState() โดยไม่ใส่ค่าเริ่มต้นจะได้ undefined แทน [] ทำให้ render ครั้งแรกพัง
API response structure ไม่ตรงกับที่คาด: ใช้ data.products แต่ API ส่งกลับเป็น data.items หรือ data.data ทำให้ได้ undefined
Props ขาด default value: Parent component ส่ง prop มาช้ากว่า child render ครั้งแรก โดยไม่มีการกำหนดค่าเริ่มต้นไว้

วิธีแก้ทีละขั้นตอน (Step-by-Step Fix)

ขั้นตอนที่ 1: กำหนด default value ให้ state

// ❌ ไม่ดี — render แรกได้ undefined
const [products, setProducts] = useState();

// ✅ ดี — เริ่มต้นเป็น array เปล่าก่อนข้อมูลจาก API มาถึง
const [products, setProducts] = useState([]);

ขั้นตอนที่ 2: เพิ่ม guard clause ก่อนเรียก .map()

// ✅ ป้องกัน crash ถ้า products ยังเป็น undefined หรือ null
{Array.isArray(products) && products.map(product => (
  <div key={product.id}>{product.name}</div>
))}

ขั้นตอนที่ 3: จัดการ loading state เพื่อ UX ที่ดีขึ้น

const [products, setProducts] = useState([]);
const [loading, setLoading] = useState(true);

if (loading) return <p>กำลังโหลดสินค้า...</p>; // แสดง loading ระหว่างรอ API
return products.map(product => (
  <div key={product.id}>{product.name}</div>
));

วิธีป้องกันไม่ให้เกิดซ้ำ (Prevention)

ใช้ TypeScript: กำหนด type products: Product[] เพื่อให้ compiler แจ้งเตือนก่อน runtime ถ้า type ไม่ตรง
ใช้ Array.isArray() แทน optional chaining เสมอ: items?.map(...) ยังพังได้ถ้าค่าเป็น null แต่ Array.isArray(items) && items.map(...) ปลอดภัยกว่า
ติดตั้ง ESLint plugin eslint-plugin-react: rule react/require-default-props จะเตือนทันทีที่ props ไม่มี default value

สิ่งที่ต้องทำก่อนเลย (Quick Win)

เปลี่ยน useState() เป็น useState([]) แล้วลอง run ใหม่ทันที กรณีส่วนใหญ่จะหาย error ได้เลยโดยไม่ต้องแก้ code ส่วนอื่น

ขั้นตอนที่ 1

ปรับให้เข้ากับงานของคุณ

แก้ค่าตัวแปรด้านล่าง พรอมต์ฉบับสมบูรณ์จะอัพเดทอัตโนมัติพร้อมก๊อปไปวางใน Claude หรือ ChatGPT ได้ทันที

ตัวแปรปรับแต่งได้3 ค่า

{{error_message}}วาง error message ทั้งหมดที่ได้รับจาก console หรือ terminal รวมถึง stack trace ถ้ามี

{{language_or_framework}}ระบุภาษาและ framework ที่ใช้ เช่น Python/Django, TypeScript/Next.js, PHP/Laravel

{{context}}อธิบายสั้นๆ ว่ากำลังทำอะไรอยู่เมื่อ error เกิดขึ้น หรือพิมพ์ 'ไม่มีข้อมูลเพิ่มเติม' ถ้าไม่ทราบ

พรอมต์ที่ปรับแล้ว พร้อมก๊อปไปวาง

You are a senior software engineer and debugging specialist with deep expertise in JavaScript / React.

A developer has encountered the following error:

```
TypeError: Cannot read properties of undefined (reading 'map')
    at ProductList (ProductList.jsx:12:18)
    at renderWithHooks (react-dom.development.js:14985:18)
```

Additional context: เกิดตอน render component ที่รับ data จาก API call แบบ async แล้วแสดงรายการสินค้า

---

Analyze this error and respond using the structured format below. Write all technical terms, code, and error names in English. Write all explanations and descriptions in Thai.

## สรุปปัญหา (What Went Wrong)
อธิบายว่า error นี้คืออะไรในภาษาที่เข้าใจง่าย ไม่เกิน 3-4 ประโยค บอกให้ชัดว่าส่วนไหนของระบบที่ล้มเหลวและเพราะอะไร

## สาเหตุที่เป็นไปได้ (Root Causes)
แสดงเป็น bullet list เรียงจากสาเหตุที่พบบ่อยที่สุดไปน้อยที่สุด อธิบายแต่ละสาเหตุ 1-2 ประโยค

## วิธีแก้ทีละขั้นตอน (Step-by-Step Fix)
ระบุเป็นขั้นตอนที่มีหมายเลข แต่ละขั้นตอนต้องมีคำอธิบายภาษาไทยและ code snippet (ถ้าเกี่ยวข้อง) พร้อม comment ภาษาไทยกำกับ

## วิธีป้องกันไม่ให้เกิดซ้ำ (Prevention)
แนะนำ best practice, defensive coding pattern หรือ tooling ที่ช่วยป้องกัน error ประเภทนี้ในอนาคต อย่างน้อย 3 ข้อ

## สิ่งที่ต้องทำก่อนเลย (Quick Win)
สรุปใน 1-2 ประโยคว่าควรลองทำอะไรก่อนเป็นอันดับแรกเพื่อแก้ปัญหาได้เร็วที่สุด

หมายเหตุ: หาก error message ที่ให้มาไม่มีข้อมูลเพียงพอ ให้ระบุว่าต้องการข้อมูลเพิ่มเติมอะไรก่อนที่จะสรุปสาเหตุที่แน่ชัด

ขั้นตอนที่ 2

เข้าใจเทคนิคที่ซ่อนอยู่

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

prompt



A developer has encountered the following error:

```
{{error_message}}
```

Additional context: {{context}}

---

Analyze this error and respond using the structured format below. 

## สรุปปัญหา (What Went Wrong)
อธิบายว่า error นี้คืออะไรในภาษาที่เข้าใจง่าย ไม่เกิน 3-4 ประโยค บอกให้ชัดว่าส่วนไหนของระบบที่ล้มเหลวและเพราะอะไร

## สาเหตุที่เป็นไปได้ (Root Causes)
แสดงเป็น bullet list  อธิบายแต่ละสาเหตุ 1-2 ประโยค

## วิธีแก้ทีละขั้นตอน (Step-by-Step Fix)
ระบุเป็นขั้นตอนที่มีหมายเลข แต่ละขั้นตอนต้องมีคำอธิบายภาษาไทยและ 

## วิธีป้องกันไม่ให้เกิดซ้ำ (Prevention)
แนะนำ best practice, defensive coding pattern หรือ tooling ที่ช่วยป้องกัน error ประเภทนี้ในอนาคต 

## สิ่งที่ต้องทำก่อนเลย (Quick Win)
สรุปใน 1-2 ประโยคว่าควรลองทำอะไรก่อนเป็นอันดับแรกเพื่อแก้ปัญหาได้เร็วที่สุด

หมายเหตุ:

เทคนิค prompt engineeringตัวแปรที่ปรับได้

1
Role assignment
“You are a senior software engineer and debugging specialist with deep expertise in {{language_or_framework}}.”
การระบุ role ที่ชัดเจนพร้อม domain expertise ช่วยให้โมเดลปรับโทนและความลึกของคำตอบให้ตรงกับ framework ที่ developer ใช้จริง แทนที่จะตอบแบบ generic
2
Language mixing instruction
“Write all technical terms, code, and error names in English. Write all explanations and descriptions in Thai.”
การแยกภาษาออกจากกันอย่างชัดเจนรักษาความแม่นยำของ technical term ไว้ในขณะที่คำอธิบายยังอ่านเข้าใจง่ายสำหรับ developer ที่ใช้ภาษาไทย
3
Prioritization instruction
“เรียงจากสาเหตุที่พบบ่อยที่สุดไปน้อยที่สุด”
การบังคับให้เรียงลำดับตามความน่าจะเป็นช่วยให้ developer ลองแก้สาเหตุที่เป็นไปได้มากที่สุดก่อน ประหยัดเวลาในการ debug อย่างมีนัยสำคัญ
4
Output format constraint
“code snippet (ถ้าเกี่ยวข้อง) พร้อม comment ภาษาไทยกำกับ”
การกำหนดให้มี code snippet พร้อม comment ภาษาไทยทำให้ผลลัพธ์ copy-paste ได้ทันทีโดยไม่ต้องตีความเพิ่มเติม ลด cognitive load ของผู้ใช้
5
Minimum count constraint
“อย่างน้อย 3 ข้อ”
การกำหนดจำนวนขั้นต่ำบังคับให้โมเดลคิดอย่างครอบคลุมแทนที่จะตอบแบบผิวเผินด้วยข้อเดียว ทำให้คำแนะนำป้องกันมีคุณค่าจริง
6
Negative constraint
“หาก error message ที่ให้มาไม่มีข้อมูลเพียงพอ ให้ระบุว่าต้องการข้อมูลเพิ่มเติมอะไรก่อนที่จะสรุปสาเหตุที่แน่ชัด”
การกำหนด fallback behavior ป้องกันไม่ให้โมเดลเดาสาเหตุโดยไม่มีข้อมูลพอ ซึ่งอาจนำ developer ไปแก้ปัญหาผิดจุดและเสียเวลาเปล่า

ขั้นตอนที่ 3

เห็นความต่าง พรอมต์ทั่วไป vs พรอมต์ที่ใช้เทคนิค

คนส่วนใหญ่เริ่มต้นด้วยคำสั่งสั้นๆ แบบฝั่งซ้าย แต่ผลลัพธ์มักไม่ตรงใจและต้องถามซ้ำหลายรอบ พรอมต์แบบฝั่งขวาแก้ปัญหานี้ด้วยเทคนิคที่อธิบายข้างต้น

พรอมต์แบบที่ใช้กันทั่วไป

อธิบาย error นี้ให้หน่อย: TypeError: Cannot read properties of undefined (reading 'map')

พรอมต์แบบที่ใช้เทคนิคข้างบน

ระบุ role: senior debugging specialist พร้อมกำหนด framework จาก variable
แยก error message และ context เป็น variable ที่ชัดเจน
บังคับ output 5 sections ได้แก่ สรุปปัญหา / สาเหตุ (เรียงลำดับความน่าจะเป็น) / แก้ทีละขั้น (มี code snippet + comment ไทย) / ป้องกัน (อย่างน้อย 3 ข้อ) / quick win
กำหนดภาษา: technical term ใช้อังกฤษ คำอธิบายใช้ไทย
มี fallback เมื่อ error message ไม่มีข้อมูลเพียงพอ

ทำไมแบบที่ใช้เทคนิคถึงดีกว่า

การถามแบบสั้นๆ ทำให้โมเดลไม่ทราบว่าใช้ React, Vue หรือ vanilla JS จึงตอบได้แค่คำอธิบาย generic โดยไม่มีวิธีแก้ที่ใช้งานได้จริง การกำหนด output format ที่ชัดเจนบังคับให้โมเดลครอบคลุมทั้งการวินิจฉัย การแก้ไข และการป้องกัน ช่วยประหยัดเวลาในการ follow-up ถามซ้ำหลายรอบ นอกจากนี้การระบุ fallback behavior ยังป้องกันไม่ให้โมเดลเดาสาเหตุโดยไม่มีข้อมูลพอ ซึ่งเป็นปัญหาที่พบบ่อยในการ debug ผ่าน AI

พรอมต์ที่เกี่ยวข้อง

ลองพรอมต์อื่นในแนวเดียวกัน

งานโค้ด

อธิบาย Legacy Code ให้ทีมใหม่เข้าใจเร็ว พร้อม Flag จุดเสี่ยงและ Tech Debt

ให้ AI วิเคราะห์โค้ดเก่าที่ซับซ้อน สรุปการทำงาน ชี้จุดเสี่ยง และจัดทำ tech debt log พร้อม effort estimate เพื่อให้ทีมใหม่เริ่มต้นได้อย่างปลอดภัยและมีทิศทางชัดเจน

นักพัฒนาดูพรอมต์

งานโค้ด

สร้าง Test Cases ครอบคลุมจาก Function Spec

สร้าง test suite จาก function specification ที่ครอบคลุมทั้ง happy path, edge cases และ adversarial inputs พร้อม rationale ของแต่ละ test และ runnable code ในภาษาและ framework ที่เลือก ช่วย developer เขียน test อย่างเป็นระบบและตรวจจับ bug ที่ซ่อนอยู่ได้อย่างมีประสิทธิภาพ

นักพัฒนาดูพรอมต์

งานโค้ด

Code Review Checklist 5 มิติ: Correctness, Security, Performance, Style, Test Coverage

พรอมต์สำหรับ developer ที่ต้องการ code review เชิงลึก ครอบคลุม 5 มิติหลัก พร้อมระบบ status icon และ verdict สรุป ช่วยให้ review ได้ครบถ้วนและสม่ำเสมอทุกครั้ง

นักพัฒนาดูพรอมต์

งานโค้ด

เขียน Architecture Decision Record (ADR) สำหรับการตัดสินใจทางเทคนิค

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

นักพัฒนาดูพรอมต์

ดูพรอมต์ทั้งหมดในคลัง

Prompt Library

อธิบาย Error Message ให้เข้าใจง่ายพร้อมแก้ทีละขั้นและป้องกันซ้ำ

ปรับและคัดลอก

งานโค้ดนักพัฒนา

อธิบาย Error Message ให้เข้าใจง่ายพร้อมแก้ทีละขั้นและป้องกันซ้ำ

6เทคนิค prompt engineering

3ตัวแปรปรับแต่งได้

ข้อความผลลัพธ์ตัวอย่าง

debuggingerror-messagecode-reviewtroubleshootingstep-by-step

ปรับและคัดลอกพรอมต์

เริ่มต้นที่นี่

ตัวอย่างผลลัพธ์ที่จะได้

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

Live preview

สรุปปัญหา (What Went Wrong)

สาเหตุที่เป็นไปได้ (Root Causes)

State ไม่มี default value (พบบ่อยที่สุด): useState() โดยไม่ใส่ค่าเริ่มต้นจะได้ undefined แทน [] ทำให้ render ครั้งแรกพัง
API response structure ไม่ตรงกับที่คาด: ใช้ data.products แต่ API ส่งกลับเป็น data.items หรือ data.data ทำให้ได้ undefined
Props ขาด default value: Parent component ส่ง prop มาช้ากว่า child render ครั้งแรก โดยไม่มีการกำหนดค่าเริ่มต้นไว้

วิธีแก้ทีละขั้นตอน (Step-by-Step Fix)

ขั้นตอนที่ 1: กำหนด default value ให้ state

// ❌ ไม่ดี — render แรกได้ undefined
const [products, setProducts] = useState();

// ✅ ดี — เริ่มต้นเป็น array เปล่าก่อนข้อมูลจาก API มาถึง
const [products, setProducts] = useState([]);

ขั้นตอนที่ 2: เพิ่ม guard clause ก่อนเรียก .map()

// ✅ ป้องกัน crash ถ้า products ยังเป็น undefined หรือ null
{Array.isArray(products) && products.map(product => (
  <div key={product.id}>{product.name}</div>
))}

ขั้นตอนที่ 3: จัดการ loading state เพื่อ UX ที่ดีขึ้น

const [products, setProducts] = useState([]);
const [loading, setLoading] = useState(true);

if (loading) return <p>กำลังโหลดสินค้า...</p>; // แสดง loading ระหว่างรอ API
return products.map(product => (
  <div key={product.id}>{product.name}</div>
));

วิธีป้องกันไม่ให้เกิดซ้ำ (Prevention)

ใช้ TypeScript: กำหนด type products: Product[] เพื่อให้ compiler แจ้งเตือนก่อน runtime ถ้า type ไม่ตรง
ใช้ Array.isArray() แทน optional chaining เสมอ: items?.map(...) ยังพังได้ถ้าค่าเป็น null แต่ Array.isArray(items) && items.map(...) ปลอดภัยกว่า
ติดตั้ง ESLint plugin eslint-plugin-react: rule react/require-default-props จะเตือนทันทีที่ props ไม่มี default value

สิ่งที่ต้องทำก่อนเลย (Quick Win)

ขั้นตอนที่ 1

ปรับให้เข้ากับงานของคุณ

ตัวแปรปรับแต่งได้3 ค่า

{{error_message}}วาง error message ทั้งหมดที่ได้รับจาก console หรือ terminal รวมถึง stack trace ถ้ามี

{{language_or_framework}}ระบุภาษาและ framework ที่ใช้ เช่น Python/Django, TypeScript/Next.js, PHP/Laravel

พรอมต์ที่ปรับแล้ว พร้อมก๊อปไปวาง

You are a senior software engineer and debugging specialist with deep expertise in JavaScript / React.

A developer has encountered the following error:

```
TypeError: Cannot read properties of undefined (reading 'map')
    at ProductList (ProductList.jsx:12:18)
    at renderWithHooks (react-dom.development.js:14985:18)
```

Additional context: เกิดตอน render component ที่รับ data จาก API call แบบ async แล้วแสดงรายการสินค้า

---

Analyze this error and respond using the structured format below. Write all technical terms, code, and error names in English. Write all explanations and descriptions in Thai.

## สรุปปัญหา (What Went Wrong)
อธิบายว่า error นี้คืออะไรในภาษาที่เข้าใจง่าย ไม่เกิน 3-4 ประโยค บอกให้ชัดว่าส่วนไหนของระบบที่ล้มเหลวและเพราะอะไร

## สาเหตุที่เป็นไปได้ (Root Causes)
แสดงเป็น bullet list เรียงจากสาเหตุที่พบบ่อยที่สุดไปน้อยที่สุด อธิบายแต่ละสาเหตุ 1-2 ประโยค

## วิธีแก้ทีละขั้นตอน (Step-by-Step Fix)
ระบุเป็นขั้นตอนที่มีหมายเลข แต่ละขั้นตอนต้องมีคำอธิบายภาษาไทยและ code snippet (ถ้าเกี่ยวข้อง) พร้อม comment ภาษาไทยกำกับ

## วิธีป้องกันไม่ให้เกิดซ้ำ (Prevention)
แนะนำ best practice, defensive coding pattern หรือ tooling ที่ช่วยป้องกัน error ประเภทนี้ในอนาคต อย่างน้อย 3 ข้อ

## สิ่งที่ต้องทำก่อนเลย (Quick Win)
สรุปใน 1-2 ประโยคว่าควรลองทำอะไรก่อนเป็นอันดับแรกเพื่อแก้ปัญหาได้เร็วที่สุด

หมายเหตุ: หาก error message ที่ให้มาไม่มีข้อมูลเพียงพอ ให้ระบุว่าต้องการข้อมูลเพิ่มเติมอะไรก่อนที่จะสรุปสาเหตุที่แน่ชัด

ขั้นตอนที่ 2

เข้าใจเทคนิคที่ซ่อนอยู่

prompt



A developer has encountered the following error:

```
{{error_message}}
```

Additional context: {{context}}

---

Analyze this error and respond using the structured format below. 

## สรุปปัญหา (What Went Wrong)
อธิบายว่า error นี้คืออะไรในภาษาที่เข้าใจง่าย ไม่เกิน 3-4 ประโยค บอกให้ชัดว่าส่วนไหนของระบบที่ล้มเหลวและเพราะอะไร

## สาเหตุที่เป็นไปได้ (Root Causes)
แสดงเป็น bullet list  อธิบายแต่ละสาเหตุ 1-2 ประโยค

## วิธีแก้ทีละขั้นตอน (Step-by-Step Fix)
ระบุเป็นขั้นตอนที่มีหมายเลข แต่ละขั้นตอนต้องมีคำอธิบายภาษาไทยและ 

## วิธีป้องกันไม่ให้เกิดซ้ำ (Prevention)
แนะนำ best practice, defensive coding pattern หรือ tooling ที่ช่วยป้องกัน error ประเภทนี้ในอนาคต 

## สิ่งที่ต้องทำก่อนเลย (Quick Win)
สรุปใน 1-2 ประโยคว่าควรลองทำอะไรก่อนเป็นอันดับแรกเพื่อแก้ปัญหาได้เร็วที่สุด

หมายเหตุ:

เทคนิค prompt engineeringตัวแปรที่ปรับได้

1
Role assignment
“You are a senior software engineer and debugging specialist with deep expertise in {{language_or_framework}}.”
การระบุ role ที่ชัดเจนพร้อม domain expertise ช่วยให้โมเดลปรับโทนและความลึกของคำตอบให้ตรงกับ framework ที่ developer ใช้จริง แทนที่จะตอบแบบ generic
2
Language mixing instruction
“Write all technical terms, code, and error names in English. Write all explanations and descriptions in Thai.”
การแยกภาษาออกจากกันอย่างชัดเจนรักษาความแม่นยำของ technical term ไว้ในขณะที่คำอธิบายยังอ่านเข้าใจง่ายสำหรับ developer ที่ใช้ภาษาไทย
3
Prioritization instruction
“เรียงจากสาเหตุที่พบบ่อยที่สุดไปน้อยที่สุด”
การบังคับให้เรียงลำดับตามความน่าจะเป็นช่วยให้ developer ลองแก้สาเหตุที่เป็นไปได้มากที่สุดก่อน ประหยัดเวลาในการ debug อย่างมีนัยสำคัญ
4
Output format constraint
“code snippet (ถ้าเกี่ยวข้อง) พร้อม comment ภาษาไทยกำกับ”
การกำหนดให้มี code snippet พร้อม comment ภาษาไทยทำให้ผลลัพธ์ copy-paste ได้ทันทีโดยไม่ต้องตีความเพิ่มเติม ลด cognitive load ของผู้ใช้
5
Minimum count constraint
“อย่างน้อย 3 ข้อ”
การกำหนดจำนวนขั้นต่ำบังคับให้โมเดลคิดอย่างครอบคลุมแทนที่จะตอบแบบผิวเผินด้วยข้อเดียว ทำให้คำแนะนำป้องกันมีคุณค่าจริง
6
Negative constraint
“หาก error message ที่ให้มาไม่มีข้อมูลเพียงพอ ให้ระบุว่าต้องการข้อมูลเพิ่มเติมอะไรก่อนที่จะสรุปสาเหตุที่แน่ชัด”
การกำหนด fallback behavior ป้องกันไม่ให้โมเดลเดาสาเหตุโดยไม่มีข้อมูลพอ ซึ่งอาจนำ developer ไปแก้ปัญหาผิดจุดและเสียเวลาเปล่า

ขั้นตอนที่ 3

เห็นความต่าง พรอมต์ทั่วไป vs พรอมต์ที่ใช้เทคนิค

พรอมต์แบบที่ใช้กันทั่วไป

อธิบาย error นี้ให้หน่อย: TypeError: Cannot read properties of undefined (reading 'map')

พรอมต์แบบที่ใช้เทคนิคข้างบน

ระบุ role: senior debugging specialist พร้อมกำหนด framework จาก variable
แยก error message และ context เป็น variable ที่ชัดเจน
บังคับ output 5 sections ได้แก่ สรุปปัญหา / สาเหตุ (เรียงลำดับความน่าจะเป็น) / แก้ทีละขั้น (มี code snippet + comment ไทย) / ป้องกัน (อย่างน้อย 3 ข้อ) / quick win
กำหนดภาษา: technical term ใช้อังกฤษ คำอธิบายใช้ไทย
มี fallback เมื่อ error message ไม่มีข้อมูลเพียงพอ

ทำไมแบบที่ใช้เทคนิคถึงดีกว่า

พรอมต์ที่เกี่ยวข้อง

ลองพรอมต์อื่นในแนวเดียวกัน

งานโค้ด

อธิบาย Legacy Code ให้ทีมใหม่เข้าใจเร็ว พร้อม Flag จุดเสี่ยงและ Tech Debt

นักพัฒนาดูพรอมต์

งานโค้ด

สร้าง Test Cases ครอบคลุมจาก Function Spec

นักพัฒนาดูพรอมต์

งานโค้ด

Code Review Checklist 5 มิติ: Correctness, Security, Performance, Style, Test Coverage

นักพัฒนาดูพรอมต์

งานโค้ด

เขียน Architecture Decision Record (ADR) สำหรับการตัดสินใจทางเทคนิค

นักพัฒนาดูพรอมต์

ดูพรอมต์ทั้งหมดในคลัง

Prompt Library

อธิบาย Error Message ให้เข้าใจง่ายพร้อมแก้ทีละขั้นและป้องกันซ้ำ

ปรับและคัดลอก