
อธิบาย Legacy Code ให้ทีมใหม่เข้าใจเร็ว พร้อม Flag จุดเสี่ยงและ Tech Debt
ให้ AI วิเคราะห์โค้ดเก่าที่ซับซ้อน สรุปการทำงาน ชี้จุดเสี่ยง และจัดทำ tech debt log พร้อม effort estimate เพื่อให้ทีมใหม่เริ่มต้นได้อย่างปลอดภัยและมีทิศทางชัดเจน
เริ่มต้นที่นี่
ตัวอย่างผลลัพธ์ที่จะได้
ก่อนเริ่มลงมือปรับพรอมต์ ดูตัวอย่างผลลัพธ์ที่คุณจะได้จริงเพื่อให้แน่ใจว่าพรอมต์นี้ตรงกับงานที่ต้องการ
1. Overview
โมดูลนี้จัดการการดึงข้อมูลผู้ใช้และประมวลผล order สำหรับระบบที่น่าจะเป็น e-commerce โดยเชื่อมต่อฐานข้อมูล MySQL โดยตรง ดีซีเรียไลซ์ payload ของ order และคำนวณส่วนลดตามหมวดหมู่สินค้า โดยรวมแล้วเป็น utility script ยุคแรกที่ยังไม่ถูก refactor ให้เป็น service layer ที่ถูกต้อง
2. Key Components
get_user_data(user_id)— ดึงข้อมูลทุก column ของผู้ใช้จาก tableusersด้วย user ID ที่รับมาprocess_orders(orders)— วนลูปรายการ order และดีซีเรียไลซ์payloadแต่ละรายการด้วยpicklecalculate_discount(items)— คำนวณส่วนลดรวมโดยเปรียบเทียบทุก item กับทุก item อื่นในรายการ
3. Data Flow
- Caller ส่ง
user_id(integer) เข้าget_user_data - ฟังก์ชันเปิด DB connection ใหม่ทุกครั้งที่ถูกเรียก แล้วสร้าง SQL string โดยต่อ string ตรงๆ
- ผลลัพธ์ถูก return เป็น tuple of tuples โดยไม่มี ORM หรือ DTO
process_ordersรับ list of dicts โดยแต่ละpayloadเป็น binary blob ที่ผ่าน pickle- Object ที่ดีซีเรียไลซ์แล้วถูก append เข้า
resultsหากเกิด error ทุกชนิดจะถูกละเว้นเงียบๆ calculate_discountรับ list of item dicts ที่มี keycategoryและpriceแล้ว return float
4. Risk Flags
- SQL Injection (Critical) —
get_user_dataบรรทัด 11:"SELECT * FROM users WHERE id = " + str(user_id)ต่อ input ตรงเข้า query โดยไม่ผ่าน parameterised query ผู้โจมตีสามารถส่ง1 OR 1=1เพื่อดึงข้อมูลผู้ใช้ทั้งหมดได้ - Hard-coded Credentials (Critical) — บรรทัด 4–6:
DB_HOST,DB_USER,DB_PASSเป็น plain-text ใน source code หากถูก commit เข้า repository ข้อมูลนี้จะรั่วไหลสู่ทุกคนที่เข้าถึง git history ได้ - Arbitrary Code Execution via pickle (Critical) —
process_ordersบรรทัด 20:pickle.loads()บน payload ที่ไม่ได้รับการตรวจสอบ หาก payload ถูกควบคุมโดยผู้โจมตีจะทำให้เกิด Remote Code Execution ได้ - Silent Failure / Bare
except(High) — บรรทัด 21:except: passกลืน exception ทุกชนิดรวมถึงKeyboardInterruptและSystemExitทำให้ order ที่ fail หายไปโดยไม่มี log ใดๆ - O(n²) Complexity (Medium) —
calculate_discountบรรทัด 27–30: nested loop ขนาด n×n สำหรับ 10,000 items จะเกิด 100 ล้าน iteration และ block thread หลักได้ - Resource Leak (Medium) —
get_user_dataเปิด connection ใหม่ทุก call และdb.close()จะถูกข้ามไปหากเกิด exception ก่อนถึงบรรทัดนั้น ทำให้ connection รั่วสะสมเมื่อ traffic สูง
5. Tech Debt Log
| # | Location | Issue | Suggested Fix | Effort |
|---|---|---|---|---|
| 1 | บรรทัด 4–6 | Hard-coded DB credentials | ย้ายไปใช้ environment variable หรือ secret manager | Low |
| 2 | บรรทัด 11 | SQL injection via string concat | ใช้ parameterised query: cursor.execute("… WHERE id = %s", (user_id,)) | Low |
| 3 | บรรทัด 20 | pickle.loads บน untrusted data | เปลี่ยนเป็น json.loads หรือ validated schema (Pydantic) | Medium |
| 4 | บรรทัด 21 | Bare except: pass | Catch specific exceptions และ log ด้วย logger.exception(...) | Low |
| 5 | บรรทัด 9–14 | เปิด connection ใหม่ทุก call | ใช้ connection pool ผ่าน SQLAlchemy หรือ mysql-connector-python | Medium |
| 6 | บรรทัด 27–30 | O(n²) discount loop | Refactor ด้วย collections.Counter keyed by category | Low |
| 7 | ทั้งไฟล์ | ไม่มี unit test | เพิ่ม pytest tests พร้อม mocked DB เริ่มจาก get_user_data | High |
6. Onboarding Tips
- อย่า expose
get_user_dataสู่ user-facing endpoint จนกว่าจะแก้ SQL injection เพราะฟังก์ชันนี้ไม่ปลอดภัยสำหรับ input ที่ไม่ได้ validate มาก่อน - field
payloadใน order เป็น pickle blob ห้ามเพิ่ม order source ใหม่ที่เขียนลง field นี้โดยไม่ตกลงกับทีมเรื่อง migration ไปใช้ JSON ก่อน calculate_discountจะ timeout บน dataset ขนาดใหญ่ หากต้องการรันกับ item มากกว่า 500 รายการให้ประสานงานกับทีมก่อนนำไปใช้ใน synchronous request path
ขั้นตอนที่ 1
ปรับให้เข้ากับงานของคุณ
แก้ค่าตัวแปรด้านล่าง พรอมต์ฉบับสมบูรณ์จะอัพเดทอัตโนมัติพร้อมก๊อปไปวางใน Claude หรือ ChatGPT ได้ทันที
You are a senior software engineer conducting a legacy code onboarding review. Your audience is a new team member who is familiar with Python but has never seen this codebase before.
Analyse the code below and produce a structured report with the following sections:
## 1. Overview (2–4 sentences)
Summarise what this code does and its role in the system.
## 2. Key Components
List the main functions, classes, or modules. For each, write one sentence explaining its responsibility.
## 3. Data Flow
Describe how data enters, transforms, and exits this code. Use a numbered step list.
## 4. Risk Flags
Identify any of the following and explain the specific risk for each:
- Silent failures / bare except / swallowed errors
- Race conditions or concurrency issues
- Hard-coded credentials, secrets, or environment-specific values
- Unbounded loops or O(n²)+ complexity hotspots
- Direct database calls in business logic (no abstraction layer)
- Missing null/boundary checks
## 5. Tech Debt Log
For each debt item, provide:
| # | Location | Issue | Suggested Fix | Effort |
|---|----------|-------|---------------|--------|
(Effort: Low / Medium / High)
## 6. Onboarding Tips
Three bullet points a new developer must know before touching this code.
Constraints:
- Be specific: reference line numbers or function names whenever possible.
- Do not rewrite the code. Explain and flag only.
- If something is ambiguous or requires runtime context to judge safely, say so explicitly rather than guessing.
```CODE TO REVIEW```
import MySQLdb
import pickle
DB_HOST = "192.168.1.100"
DB_USER = "root"
DB_PASS = "P@ssw0rd123"
def get_user_data(user_id):
db = MySQLdb.connect(DB_HOST, DB_USER, DB_PASS, "users_db")
cursor = db.cursor()
cursor.execute("SELECT * FROM users WHERE id = " + str(user_id))
rows = cursor.fetchall()
db.close()
return rows
def process_orders(orders):
results = []
for order in orders:
try:
data = pickle.loads(order['payload'])
results.append(data)
except:
pass
return results
def calculate_discount(items):
total = 0
for i in range(len(items)):
for j in range(len(items)):
if items[i]['category'] == items[j]['category']:
total += items[i]['price'] * 0.1
return total
```ขั้นตอนที่ 2
เข้าใจเทคนิคที่ซ่อนอยู่
คลิกที่ส่วนไฮไลต์ในพรอมต์เพื่อกระโดดไปดูคำอธิบายเทคนิคแต่ละจุด ใช้ความเข้าใจนี้เพื่อปรับพรอมต์อื่นของคุณเองในภายหลัง
Analyse the code below and produce a structured report with the following sections: ## 1. Overview (2–4 sentences) Summarise what this code does and its role in the system. ## 2. Key Components List the main functions, classes, or modules. For each, write one sentence explaining its responsibility. ## 3. Data Flow Describe how data enters, transforms, and exits this code. Use a numbered step list. ## 4. Risk Flags Identify any of the following and explain the specific risk for each: - Silent failures / bare except / swallowed errors - Race conditions or concurrency issues - Hard-coded credentials, secrets, or environment-specific values - Unbounded loops or O(n²)+ complexity hotspots - Direct database calls in business logic (no abstraction layer) - Missing null/boundary checks ## 5. Tech Debt Log For each debt item, provide: (Effort: Low / Medium / High) ## 6. Onboarding Tips Three bullet points a new developer must know before touching this code. Constraints: - Be specific: reference line numbers or function names whenever possible. - - ```CODE TO REVIEW``` {{code}} ```
- 1Role assignment
“You are a senior software engineer conducting a legacy code onboarding review.”
การกำหนด role ที่ชัดเจนทำให้ AI เลือกมุมมองและน้ำเสียงที่เหมาะสม แทนที่จะตอบแบบกว้างๆ AI จะวิเคราะห์ในฐานะวิศวกรผู้มีประสบการณ์ที่เข้าใจความเสี่ยงในโค้ดจริง
- 2Context grounding
“Your audience is a new team member who is familiar with {{programming_language}} but has never seen this codebase before.”
การบอก audience ให้ AI ทราบช่วยปรับระดับของคำอธิบายให้พอดี ไม่ต้องอธิบาย syntax พื้นฐาน แต่ต้องอธิบาย business logic และ convention เฉพาะของ codebase นี้
- 3Output format constraint
“## 1. Overview (2–4 sentences) ## 2. Key Components ## 3. Data Flow ## 4. Risk Flags ## 5. Tech Debt Log ## 6. Onboarding Tips”
การกำหนด section ทั้ง 6 ล่วงหน้าบังคับให้ AI ครอบคลุมทุกมิติที่จำเป็นสำหรับ onboarding และทำให้ output สามารถนำไปใส่ใน wiki หรือ PR description ได้ทันทีโดยไม่ต้องแก้ไขโครงสร้าง
- 4Structured output template
“| # | Location | Issue | Suggested Fix | Effort | |---|----------|-------|---------------|--------|”
การให้ table template พร้อม column headers บังคับให้ AI สรุป tech debt ในรูปแบบที่ประเมินงานได้จริง แทนที่จะเขียนเป็น paragraph ยาวที่ยากต่อการ prioritise
- 5Negative constraint
“Do not rewrite the code. Explain and flag only.”
การห้ามชัดเจนป้องกัน AI จากการ hallucinate โดยการเขียน refactored version ที่อาจมี bug ใหม่หรือเปลี่ยน behavior โดยไม่ตั้งใจ ทำให้ผลลัพธ์ใช้เป็น review document ได้อย่างปลอดภัย
- 6Uncertainty calibration
“If something is ambiguous or requires runtime context to judge safely, say so explicitly rather than guessing.”
คำสั่งนี้ลด hallucination โดยตรง เพราะ AI มักมีแนวโน้มตอบให้ครบแม้ไม่มีข้อมูลเพียงพอ การบอกให้ยอมรับความไม่แน่ใจทำให้ผลลัพธ์น่าเชื่อถือกว่าสำหรับการตัดสินใจด้านวิศวกรรม
ขั้นตอนที่ 3
เห็นความต่าง พรอมต์ทั่วไป vs พรอมต์ที่ใช้เทคนิค
คนส่วนใหญ่เริ่มต้นด้วยคำสั่งสั้นๆ แบบฝั่งซ้าย แต่ผลลัพธ์มักไม่ตรงใจและต้องถามซ้ำหลายรอบ พรอมต์แบบฝั่งขวาแก้ปัญหานี้ด้วยเทคนิคที่อธิบายข้างต้น
พรอมต์แบบที่ใช้กันทั่วไป
อธิบาย code นี้ให้หน่อย
พรอมต์แบบที่ใช้เทคนิคข้างบน
กำหนด role เป็น senior engineer, ระบุ audience และ language ที่รู้จัก, บังคับ output เป็น 6 sections พร้อม risk flags และ tech debt table ที่มี effort estimate, ห้าม rewrite code และสั่งให้ยอมรับความไม่แน่ใจอย่างชัดเจน
ทำไมแบบที่ใช้เทคนิคถึงดีกว่า
คำถามสั้นๆ ไม่บอก AI ว่า audience คือใคร ระดับความรู้อยู่ที่ไหน หรือต้องการข้อมูลส่วนใดเป็นพิเศษ AI จะตอบแบบกว้างๆ อาจอธิบาย syntax ที่รู้อยู่แล้ว หรือพลาดจุดเสี่ยงด้านความปลอดภัย prompt ที่ดีกำหนดโครงสร้าง output ไว้ล่วงหน้าครบทุกมิติ ทำให้ผลลัพธ์นำไปใช้ได้ทันทีโดยไม่ต้องถามซ้ำ และ constraint ด้าน negative กับ uncertainty ช่วยให้ output น่าเชื่อถือพอที่จะใช้ตัดสินใจด้านวิศวกรรมได้จริง
พรอมต์ที่เกี่ยวข้อง
ลองพรอมต์อื่นในแนวเดียวกัน

งานโค้ด
สร้าง 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 ที่ยอมรับ ช่วยให้ทีมปัจจุบันและนักพัฒนารุ่นต่อไปเข้าใจว่าทำไมจึงตัดสินใจเช่นนั้น

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