คุณคือวิศวกร [ภาษา/เฟรมเวิร์ก] อาวุโสที่กำลังรีวิวโค้ดสำหรับ [โครงการ/โดเมน]
เป้าหมาย: [แก้ไขข้อผิดพลาด | ประสิทธิภาพ | ความสามารถในการอ่าน | ความปลอดภัย | DX | ความสอดคล้องของ API]
ข้อจำกัด: [คู่มือสไตล์ เวอร์ชันที่รองรับ ขีดจำกัดหน่วยความจำ/เวลา ข้อจำกัดของไลบรารี]
บริบท:
- รันไทม์/Env: [Node 20, JVM 17, Python 3.11, iOS 17, ฯลฯ ]
- การพึ่งพาหลัก: [รายการ]
- สถาปัตยกรรม: [monolith, microservice, serverless, hexagonal, ฯลฯ ]
- อินเทอร์เฟซ/สัญญาที่เกี่ยวข้อง: [ลิงก์หรืออินไลน์]
งาน:
1) รีวิวโค้ดต่อไปนี้สำหรับ [เป้าหมาย]
2) ระบุปัญหาเฉพาะพร้อมหลักฐาน (การอ้างอิงบรรทัด การประมาณความซับซ้อน กรณีพิเศษ)
3) เสนอ diff ที่น้อยที่สุดและตรงเป้าหมาย
4) จัดทำเวอร์ชันที่ปรับปรุงใหม่ขั้นสุดท้าย
5) อธิบายข้อดีข้อเสียและความเสี่ยง
โค้ด:
```[ภาษา]
// วางโค้ดที่นี่

เป้าหมาย: ลดความซับซ้อนของเวลาและหน่วยความจำโดยไม่เปลี่ยนพฤติกรรมสาธารณะ
จัดหา: ความซับซ้อนปัจจุบัน ความซับซ้อนที่เสนอ การเพิ่มประสิทธิภาพขนาดเล็กกับการเปลี่ยนแปลงเชิงอัลกอริทึม และเกณฑ์มาตรฐานที่จะเรียกใช้

ปรับปรุงเพื่อความชัดเจน: การตั้งชื่อที่ดีขึ้น ฟังก์ชันที่เล็กลง ความรับผิดชอบเดียว
เพิ่ม docstrings/JSDoc ลดความซับซ้อนของการควบคุมการไหล ลบโค้ดที่ตายแล้ว รักษา API สาธารณะให้เสถียร

แบบจำลองภัยคุกคาม: อินพุตที่ไม่น่าเชื่อถือจาก [แหล่งที่มา]
ตรวจสอบ: injection, deserialization, SSRF, XSS, CSRF, authZ/authN, การจัดการความลับ
แนะนำ: ไลบรารีที่ปลอดภัย รูปแบบการตรวจสอบ และ diff ที่น้อยที่สุด

เรากำลังย้ายจาก [lib A] ไปยัง [lib B]
แสดงรายการการเปลี่ยนแปลงที่ทำให้เกิดปัญหา เสนอเลเยอร์อะแดปเตอร์ และจัดทำแผนการเปิดตัวที่เพิ่มขึ้นพร้อมการทดสอบ

Env: Python 3.11, FastAPI, Pydantic v2
สัญญา: endpoint ต้องส่งคืน 200 พร้อม { data, meta } แม้ว่าจะเกิดความล้มเหลวบางส่วน
ข้อจำกัด: ต้องยังคง async; ไม่สามารถเพิ่ม deps ที่หนักหน่วงใหม่ได้

1) วิจารณ์: แสดงรายการปัญหาที่เป็นรูปธรรมพร้อมหลักฐาน
2) Diff: การเปลี่ยนแปลงที่เล็กที่สุดในการแก้ไข
3) ปรับปรุง: โค้ดสุดท้ายที่สะอาดและสำนวน
4) การทดสอบ: การทดสอบหน่วยที่ครอบคลุม happy path + 3 กรณีพิเศษ

เสนอ 3 ตัวเลือกการปรับปรุง:
- ตัวเลือก A: การเปลี่ยนแปลงน้อยที่สุด
- ตัวเลือก B: การออกแบบใหม่ปานกลาง
- ตัวเลือก C: เขียนใหม่ทั้งหมด
สำหรับแต่ละ: ข้อดีข้อเสีย ความซับซ้อน ความเสี่ยง แผนการย้ายข้อมูล และเวลาที่จะเลือก

ข้อจำกัด: API สาธารณะเดียวกัน <50ms p95 <10MB หน่วยความจำเพิ่มเติม ไม่มีการพึ่งพารันไทม์ใหม่
แสดงว่าการปรับปรุงของคุณเป็นไปตามข้อจำกัดแต่ละข้ออย่างไรด้วยการวัดหรือการให้เหตุผล

คุณคือวิศวกร Python อาวุโส เป้าหมาย: ความถูกต้อง + ประสิทธิภาพ
Env: Python 3.11, FastAPI, httpx, Pydantic v2 สัญญา: ห้าม raise เมื่อเกิดความล้มเหลวบางส่วน
งาน: รีวิวและปรับปรุง จัดเตรียมวิจารณ์ → diff ที่น้อยที่สุด → ปรับปรุงขั้นสุดท้าย → การทดสอบ
โค้ด:
```python
จาก fastapi import APIRouter
import httpx
router = APIRouter
@router.get("/users/{user_id}")
async def get_user(user_id: str):
async with httpx.AsyncClient as client:
profile = await client.get(f")
posts = await client.get(f")
return {"data": {"profile": profile.json, "posts": posts.json}}

ใส่คำอธิบายประกอบแต่ละคำแนะนำด้วย: {severity, category, rationale} รวมส่วนย่อยก่อน/หลังและแผนการย้ายข้อมูลขั้นตอนเดียวหากพฤติกรรมอาจเปลี่ยนแปลง

ส่งคืนเอาต์พุตเป็น unified diff พร้อมเส้นทางไฟล์ที่ถูกต้องจาก repo root นี้ รวมเฉพาะ hunks ที่เปลี่ยนแปลง ไม่มีความคิดเห็นใน diff จากนั้นรวมส่วนแยกต่างหากสำหรับ notes

ตอบกลับด้วยสองบล็อกเท่านั้น:
1) ```diff
...การเปลี่ยนแปลง...

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

หากข้อกำหนดไม่ชัดเจน ให้ถามคำถามเพื่อความกระจ่างสูงสุด 3 ข้อก่อนดำเนินการต่อ

บทบาท: วิศวกร TypeScript อาวุโส
เป้าหมาย: ปรับปรุงความสามารถในการอ่านและความปลอดภัยของรันไทม์โดยไม่เปลี่ยน API สาธารณะ
Env: Node 20, TypeScript 5.4, Zod สำหรับการตรวจสอบ, ESLint Airbnb, strictNullChecks
ข้อจำกัด: ไม่มีการพึ่งพารันไทม์ใหม่นอกเหนือจาก Zod ไม่มีการเปลี่ยนแปลงที่ก่อให้เกิดปัญหา รักษาระดับความซับซ้อน O(n)
งาน:
- วิจารณ์ → Diff → ปรับปรุง → การทดสอบ → หมายเหตุ
- แท็กปัญหาด้วย {severity, category, rationale}
- รวมสคีมา Zod สำหรับการตรวจสอบอินพุตและการทดสอบหน่วย 4 รายการ
โค้ด:
```ts
ส่งออกฟังก์ชัน parseUser(raw: any) {
if (!raw) return null
return {
id: raw.id || '0',
name: raw.name || 'Unknown',
age: parseInt(raw.age),
}
}

เรียกใช้ mental ESLint pass และแสดงรายการการละเมิดที่คุณคาดหวัง จากนั้นแก้ไข

สำหรับการเปลี่ยนแปลงแต่ละครั้ง ให้ตั้งชื่อรูปแบบการปรับปรุง (เช่น Extract Function, Introduce Parameter Object) และอธิบายเวลาที่จะนำไปใช้ใน codebase นี้

ใช้เฉพาะบริบท repo รีวิวไฟล์ที่เปลี่ยนแปลงใน PR นี้สำหรับ [เป้าหมาย] ใส่คำอธิบายประกอบผลการค้นหาแบบอินไลน์ด้วยความรุนแรงและเหตุผล เสนอ diff ที่รักษา API สาธารณะและ NFRs รวมถึงการทดสอบที่สัมผัสเฉพาะเส้นทางที่เปลี่ยนแปลง