พรอมต์ไกด์สไตล์ Claude Code เพื่อการรีวิวโค้ดที่สม่ำเสมอ

ทำไมการละเมิดไกด์สไตล์แพร่กระจายได้เร็ว

การละเมิดไกด์สไตล์แทบจะไม่เกิดขึ้นเป็นความผิดพลาดครั้งใหญ่ครั้งเดียว แต่มันเริ่มจากการเลือกเล็ก ๆ ที่ดูว่า "พอใช้ได้" ใน pull request แล้วสะสมจนโค้ดเบสดูไม่สม่ำเสมอและยากต่อการอ่าน

การเบี่ยงเบนสไตล์มักจะเป็นแบบนี้: ไฟล์หนึ่งใช้ userID ไฟล์ถัดมาระบุ userId และอีกไฟล์ใช้ uid ตัวจัดการหนึ่งคืนค่า { error: "..." } อีกตัวโยนข้อผิดพลาด อีกตัวล็อกแล้วคืน null การเปลี่ยนแต่ละครั้งเล็ก ๆ แต่รวมกันแล้วทำให้รูปแบบในรีโปไม่คาดเดาได้

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

นั่นคือเหตุผลที่เป้าหมายควรเป็นการมีคอนเวนชันที่สม่ำเสมอ ไม่ใช่รสนิยมส่วนบุคคล คำถามไม่ใช่ "ฉันชอบชื่อนี้ไหม?" แต่เป็น "นี่ตรงตามกฎที่ตกลงกันไว้หรือไม่ เพื่อให้คนถัดไปทำตามได้โดยไม่ต้องคิดมาก"

การจับการละเมิดตั้งแต่เนิ่น ๆ คือการหยุดรูปแบบไม่ดีไว้ก่อนที่จะกลายเป็นเชื้อคัดลอก ให้โฟกัสที่โค้ดใหม่และที่แก้ไข แก้จุดแรกที่มีความไม่สอดคล้องใหม่ และบล็อกการรวมโค้ดที่นำมาซึ่งการเบี่ยงเบนใหม่ เมื่อรายงานปัญหา ให้เพิ่มตัวอย่างสั้น ๆ ที่แนะนำเพื่อให้คนอื่นทำตามครั้งหน้าได้ง่าย

ตัวอย่างสมจริง: นักพัฒนาคนหนึ่งเพิ่ม endpoint ใหม่ของ API แล้วล็อก request body ตรง ๆ "แค่เพื่อดีบัก" ถ้าสิ่งนั้นเข้ามา endpoint ถัด ๆ ไปก็จะคัดลอก และในไม่ช้าข้อมูลที่ละเอียดอ่อนก็จะไปปรากฏในล็อก การจับมันใน PR แรกถูกและง่าย การแก้หลังจากมันแพร่กระจายแล้วทั้งเจ็บปวดและมีความเสี่ยง

เปลี่ยนไกด์สไตล์ให้เป็นกฎที่ชัดเจนและทดสอบได้

ไกด์สไตล์จะใช้ได้ในการรีวิวก็ต่อเมื่อมันอ่านเหมือนเช็คลิสต์ ไม่ใช่ชุดความชอบ ปรับแต่ละคำแนะนำให้เป็นกฎที่ตรวจสอบได้บน diff

จัดระเบียบกฎเป็นสี่หมวดให้ชัดเจน: การตั้งชื่อ (naming), เลเยอร์ (layering), การจัดการข้อผิดพลาด (error handling), และการล็อก (logging) สำหรับแต่ละหมวด เขียนสองสิ่ง: สิ่งที่ต้องเป็นจริง และสิ่งที่ห้ามทำ

กำหนดความเข้มของแต่ละกฎล่วงหน้า:

• บังคับ: หากไม่ผ่านจะบล็อกการเปลี่ยนแปลง
• แนะนำ: ควรแก้ถ้าไม่มีเหตุผลชัดเจนที่จะไม่แก้
• เป็นทางเลือก: ดีแต่ไม่บล็อก

ตั้งขอบเขตเพื่อให้การรีวิวไม่กลายเป็นการรีแฟกเตอร์ไม่รู้จบ กฎง่าย ๆ ที่ใช้ได้ดีคือ: "โค้ดใหม่และที่แก้ไขต้องสอดคล้อง; โค้ดเก่าที่ไม่ได้แตะไม่ต้องถูกเขียนใหม่ เว้นแต่จะขัดขวางการแก้" ถ้าต้องการทำความสะอาด ให้ตั้งเวลาเป็นงานแยก

นอกจากนี้ให้กำหนดผลลัพธ์ที่ต้องการจากการรีวิวเพื่อให้ทำตามได้ง่าย: ผลผ่าน/ล้ม, รายการการละเมิดพร้อมไฟล์และบรรทัดอ้างอิง, การแก้แนะนำในรูปแบบแก้ไขที่เป็นรูปธรรม, และบันทึกความเสี่ยงสั้น ๆ เมื่อบางอย่างอาจก่อให้เกิดบั๊กหรือการรั่วไหล

ตัวอย่าง: ถ้า PR ล็อก token ผู้ใช้ดิบ การรีวิวควรล้มภายใต้ "logging: never log secrets" และแนะนำให้ล็อกเฉพาะ request ID แทน

โครงสร้างพรอมต์ที่บังคับใช้กฎมากกว่ารสนิยม

พรอมต์ไกด์สไตล์มักล้มเหลวเมื่อมันฟังดูเป็นความชอบส่วนตัว พรอมต์รีวิวที่ดีต้องอ่านเหมือนสัญญา: ข้อห้ามที่ชัดเจน ข้อยกเว้นที่ตั้งชื่อชัด และผลลัพธ์ที่คาดเดาได้

เริ่มด้วยสองบล็อกสั้น ๆ: สิ่งที่ต้องเป็นจริง และสิ่งที่สามารถยืดหยุ่นได้ จากนั้นเพิ่มกฎการตัดสิน: "ถ้าไม่ชัด ให้ระบุ Needs Clarification อย่าสันนิษฐาน"

บังคับให้มีหลักฐาน เมื่อเครื่องมือตรวจพบการละเมิด ให้บังคับให้มันอ้างข้อความ identifier และตำแหน่งไฟล์เป๊ะ ๆ แทนคำบรรยายคลุมเครือ ข้อจำกัดเดียวนั้นช่วยลดการโต้ตอบซ้ำ ๆ ได้มาก

เก็บขอบเขตให้แคบ: แสดงความคิดเห็นเฉพาะบรรทัดที่เปลี่ยนและเส้นทางโค้ดที่ได้รับผลกระทบโดยตรงเท่านั้น หากอนุญาตให้รีแฟกเตอร์ที่ไม่เกี่ยวข้อง การบังคับใช้สไตล์จะกลายเป็นการ "เขียนไฟล์ใหม่" และผู้คนจะหยุดเชื่อถือคำติชม

นี่คือโครงสร้างที่ใช้ซ้ำได้:

Role: strict style guide reviewer.
Input: diff (or files changed) + style guide rules.
Non-negotiables: [list].
Allowed exceptions: [list].
Scope: ONLY comment on changed lines and directly impacted code paths. No unrelated refactors.
Evidence: Every finding MUST include (a) file path, (b) exact identifier(s), (c) short quote.
Output: structured compliance report with pass/fail per category + minimal fixes.

บังคับให้รายงานมีส่วนเดิมทุกครั้ง แม้บางส่วนจะขึ้นว่า "ไม่พบปัญหา": Naming, Layering, Error handling, Logging

ถ้ารายงานระบุว่า "service layer leaking DB details" มันต้องอ้างอิงบางอย่างเช่น internal/orders/service/order_service.go และการเรียกที่ชี้ชัด (ตัวอย่าง db.QueryContext) เพื่อให้คุณแก้ปัญหาโดยไม่ต้องถกเถียงกันว่ามันหมายถึงอะไร

ขั้นตอนทีละขั้น: สร้างเวิร์กโฟลว์พรอมต์เช็กสไตล์

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

ใช้เวิร์กโฟลว์สองพาสเรียบง่าย:

1. วางมาตรฐานของคุณเป็นรายการกฎแบบตัวเลขสั้น ๆ (10-25 บรรทัด) ให้แต่ละกฎตรวจสอบได้
2. เพิ่มบริบทสำหรับการเปลี่ยนแปลง: diff, ไฟล์ที่แตะ และประโยคสั้น ๆ เกี่ยวกับเจตนา
3. ขอรายงานการละเมิดก่อน ให้มีไฟล์และบรรทัด สาเหตุสั้น ๆ และหมายเลขกฎที่ตรงกัน
4. เฉพาะหลังรายงานแล้ว ให้ขอแพตช์ที่เล็กที่สุดเพื่อให้เป็นไปตามกฎ
5. รันพรอมต์เดิมอีกครั้งบนโค้ดที่อัปเดตเพื่อยืนยันว่าไม่มีเหลือ

ตัวอย่าง: PR เพิ่ม endpoint ใหม่ Pass 1 จะชี้ว่า handler พูดคุยกับ PostgreSQL โดยตรง (layering), ใช้การตั้งชื่อผสมใน struct ของ request (naming), และล็อกอีเมลเต็มรูปแบบ (logging). Pass 2 แก้ไขเล็กน้อย: ย้ายการเรียก DB ไปยัง service หรือ repository, เปลี่ยนชื่อ struct, และปกปิดอีเมลในล็อก โดยไม่เปลี่ยนอย่างอื่น

การตั้งชื่อ: พรอมต์ที่จับสิ่งเล็ก ๆ

ปัญหาการตั้งชื่อดูเหมือนเล็ก แต่สร้างต้นทุนจริง: คนอ่านความหมายผิด การค้นหาซับซ้อน และชื่อคล้ายกันจำนวนมากเพิ่มขึ้น

ระบุให้ชัดเจนกฎการตั้งชื่อที่รีวิวเวอร์ต้องบังคับใช้ทั่วทั้งการเปลี่ยน: ชื่อไฟล์, types ที่ export, ฟังก์ชัน, ตัวแปร, คอนสแตนต์, และเทสต์ ระบุชัดเรื่องการใช้เคส (camelCase, PascalCase, snake_case) และเลือกกฎคำย่อหนึ่งแบบ (เช่น APIClient vs ApiClient) แล้วบังคับใช้ทุกที่

มาตรฐานคำศัพท์ร่วมกันก็สำคัญ: ประเภทข้อผิดพลาด, ฟิลด์ล็อก, และคีย์คอนฟิก ถ้าล็อกใช้ request_id ไม่ควรยอม reqId ในไฟล์หนึ่งและ requestId ในอีกไฟล์

คำสั่งสำหรับรีวิวที่ใช้งานได้จริง:

Check every new or renamed identifier. Enforce casing + acronym rules.
Flag vague names (data, info, handler), near-duplicates (userId vs userID), and names that contradict behavior.
Prefer domain language: business terms over generic tech words.

ขอรายงานสั้น ๆ: สามชื่ิอที่ทำให้สับสนที่สุด, รายชื่อ near-duplicates และตัวที่ควรเก็บไว้, รวมถึงชื่อฟิลด์ล็อก/คอนฟิก/ข้อผิดพลาดที่ไม่ตรงกับมาตรฐาน

กฎเลเยอร์: แยกความรับผิดชอบไม่ให้ปะปน

กฎเลเยอร์ทำงานได้ดีที่สุดเมื่ออธิบายเป็นภาษาธรรมดา: handler ดูแล HTTP, service ถือ business rules, repository ติดต่อฐานข้อมูล

ล็อกทิศทางการพึ่งพา Handler สามารถเรียก service ได้ Service สามารถเรียก repository ได้ Repository ไม่ควรเรียก service หรือ handler Handler ไม่ควร import โค้ดฐานข้อมูล helpers SQL หรือโมเดล ORM ถ้าใช้แพ็กเกจร่วม (config, time, IDs) ให้แน่ใจว่าไม่มีโลจิกของแอปอยู่ในนั้น

กำหนดที่อยู่ของงานข้ามเลเยอร์ การ validate มักอยู่ที่ boundary สำหรับรูปร่าง request และใน service สำหรับกฎธุรกิจ การอนุญาตมักเริ่มใน handler (identity, scopes) แต่ service ควรบังคับการตัดสินขั้นสุดท้าย การ mapping อยู่ที่ขอบของเลเยอร์: handler แปลง HTTP เป็น domain input, repository แปลง DB rows เป็น domain types

ใส่บล็อกนี้ในพรอมต์เพื่อให้รีวิวเป็นรูปธรรม:

Check layering: handler -\u003e service -\u003e repository only.
Report any leaks:
- DB types/queries in handlers or services
- HTTP request/response types inside services or repositories
- repository returning DB models instead of domain objects
- auth/validation mixed into repository
For each leak, propose the smallest fix: move function, add interface, or rename package.

ทำให้รายงานชัดเจน: ระบุไฟล์ เลเยอร์ที่ควรอยู่ การ import หรือการเรียกที่ละเมิดกฎ และการเปลี่ยนแปลงเล็กที่สุดที่ป้องกันไม่ให้รูปแบบนั้นแพร่กระจาย

ข้อตกลงการจัดการข้อผิดพลาด: สม่ำเสมอเมื่อเกิดความกดดัน

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

เขียนปรัชญาและบังคับใช้ ตัวอย่าง: "wrap errors เพื่อเพิ่มบริบท; สร้าง error ใหม่เมื่อเปลี่ยนความหมายหรือแปลเป็นข้อความผู้ใช้; คืน raw error เฉพาะที่ขอบระบบ" ประโยคเดียวจะป้องกันรูปแบบสุ่ม ๆ จากการแพร่

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

ในการรีวิว ให้เช็กความล้มเหลวที่พบบ่อย: ข้อผิดพลาดถูกละเลย (ล็อกแต่ไม่คืนค่า), คืนค่ากำกวม (ค่ากลับเป็น nil พร้อม error เป็น nil หลังจากล้มเหลว), และข้อความผู้ใช้ที่รั่วข้อมูลเช่น stack trace, คำสั่ง query, token หรือ PII ถ้ารองรับการ retry หรือ timeout ให้บังคับให้ระบุไว้ชัดเจน

ตัวอย่าง: การเรียก checkout เวลา timeout ผู้ใช้เห็น "Payment service is taking too long." ภายในให้ wrap timeout และใส่ op=checkout.charge และ order ID เพื่อให้ค้นหาได้และแก้ไขได้

ข้อตกลงการล็อก: อ่านได้ ค้นหาได้ และปลอดภัย

ล็อกช่วยได้เมื่อทุกคนเขียนแบบเดียวกัน ถ้าผู้พัฒนาแต่ละคนเลือกคำพูด ระดับ และฟิลด์เอง การค้นหาจะกลายเป็นการคาดเดา

ทำให้ระดับล็อกเป็นสิ่งที่ไม่ต่อรองได้: debug สำหรับรายละเอียดการพัฒนา, info สำหรับเหตุการณ์ปกติ, warn สำหรับสถานการณ์ที่คาดไม่ถึงแต่จัดการได้, และ error เมื่อการกระทำต่อผู้ใช้ล้มเหลวหรือจำเป็นต้องให้ความสนใจ ระวังการใช้ fatal หรือ panic ให้ชัดเจนตามนโยบายการล่ม

ล็อกแบบมีโครงสร้างสำคัญกว่าประโยคที่สมบูรณ์แบบ กำหนดชื่อคีย์ที่คงที่เพื่อไม่ให้แดชบอร์ดและ alerts พัง เลือกชุดคีย์แกนเล็ก ๆ (เช่น event, component, action, status, duration_ms) และรักษาให้สม่ำเสมอ

จัดการข้อมูลละเอียดอ่อนเป็นข้อห้ามชัดเจน ระบุชัดเจนสิ่งที่ห้ามล็อกเด็ดขาด: รหัสผ่าน, auth tokens, หมายเลขบัตรเครดิตเต็ม, ความลับ, และข้อมูลส่วนบุคคลดิบ เรียกสิ่งที่ดูไม่อันตรายแต่จริง ๆ แล้วอันตราย เช่น ลิงก์รีเซ็ตรหัสผ่าน, session IDs, และ request bodies เต็ม ๆ ว่าเป็นความเสี่ยง

Correlation IDs ทำให้การดีบักข้ามเลเยอร์เป็นไปได้ บังคับให้มี request_id ในทุกบรรทัดล็อกที่อยู่ภายในการร้องขอ ถ้าล็อก user_id ให้กำหนดว่าเมื่อใดอนุญาตและจะแสดงผู้ใช้ที่ไม่ได้ระบุอย่างไร

บล็อกพรอมต์ที่ใช้ซ้ำได้:

Review the changes for logging conventions:
- Check level usage (debug/info/warn/error). Flag any level that does not match impact.
- Verify structured fields: require stable keys and avoid free-form context in the message.
- Confirm correlation identifiers: request_id on all request-bound logs; user_id only when allowed.
- Flag any sensitive data risk (tokens, secrets, personal data, request/response bodies).
- Identify noisy logs (in loops, per-item logs, repeated success messages) and missing context.
Return: (1) violations with file/line, (2) suggested rewrite examples, (3) what to add or remove.

ก่อนจะ merge ให้ทำ "safety pass" อย่างรวดเร็ว: ล็อกใหม่ที่ขาด request_id สำหรับงานที่ผูกกับ request, คีย์ใหม่ที่เปลี่ยนชื่อเดิม (userId vs user_id), error logs ที่ขาดข้อมูลว่าล้มที่ไหน (operation, resource, status), ล็อกความถี่สูงที่จะเกิดทุก request, และความเป็นไปได้ที่จะมีความลับหรือข้อมูลส่วนบุคคลปรากฏในฟิลด์หรือข้อความ

วิธีจับการละเมิดก่อนที่มันจะแพร่

มองการเบี่ยงเบนสไตล์เหมือนการแตกของ build ไม่ใช่คำแนะนำ เพิ่มเกทที่เข้มงวดก่อน merge และให้ผลผ่านหรือไม่ผ่านชัดเจน หากกฎบังคับถูกละเมิด (การตั้งชื่อ, ขอบเขตเลเยอร์, ความปลอดภัยล็อก, การจัดการข้อผิดพลาด) ให้ล้มและชี้ไฟล์บรรทัดที่แน่นอน

รักษาเกทให้สั้น เทคนิคปฏิบัติได้คือให้มีเช็คลิสต์ YES/NO ต่อตัว และปฏิเสธการอนุมัติถ้ารายการใดเป็น NO

เช็คลิสต์ขนาด PR ที่จับปัญหาส่วนใหญ่:

• Naming: ตรงตามรูปแบบที่อนุมัติสำหรับไฟล์ types และฟังก์ชัน
• Layering: ไม่มีการเรียกข้ามเลเยอร์โดยตรง (เช่น handler เรียก DB)
• Errors: คืนค่าอย่างสม่ำเสมอพร้อมบริบท ไม่มีการละเลยเงียบ ๆ
• Logging: ฟิลด์สม่ำเสมอ ไม่มีความลับ และระดับตรงกับผลกระทบ
• Tests/docs: อัปเดตเมื่อพฤติกรรมหรือ API สาธารณะเปลี่ยน

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

กับดักทั่วไปเมื่อใช้พรอมต์ในการบังคับสไตล์

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

การตั้งชื่อเป็นตัวอย่างทั่วไป "ใช้ชื่อที่ชัดเจน" ตรวจสอบไม่ได้ ทำให้มันเข้มงวดเป็นสิ่งที่ตรวจสอบได้: "ฟังก์ชันเป็นกริยา (เช่น createInvoice), boolean เริ่มด้วย is/has/can, types ที่ export เป็น PascalCase"

กับดักอีกอย่างคือขอทุกอย่างพร้อมกัน เมื่อพรอมต์พยายามครอบคลุม naming, layering, errors, logging, tests และ performance ในครั้งเดียว คำติชมจะตื้น แยกรีวิวเป็นพาสที่โฟกัสเมื่ออยากได้ความลึก หรือลดเกทให้เหลือกฎบังคับเท่านั้น

ปัญหาที่ทำให้การบังคับใช้แตกหักบ่อยที่สุด:

• กฎคลุมเครือ: แทนที่จะใช้คำว่า "สะอาด" และ "สม่ำเสมอ" ให้ใช้ภาษาที่วัดได้
• ผสมการแก้ไขสไตล์กับการออกแบบใหม่: อย่าให้พรอมต์สไตล์เสนอสถาปัตยกรรมใหม่
• ไม่มีหลักฐานอ้างอิง: บังคับให้ทุกความคิดเห็นต้องอ้าง identifier หรือ snippet เป๊ะ ๆ
• ข้อยกเว้นที่เงียบ: ถ้าอนุญาตข้อยกเว้น ให้บันทึกสั้น ๆ ว่าทำไม และเมื่อไหร่ควรถอนออก

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

เช็คลิสต์ด่วนที่คุณรันกับทุกการเปลี่ยนแปลง

รันพาสด่วนบน diff (ไม่ใช่ทั้งรีโป) และยืนยัน:

• Naming: ตัวระบุใหม่ตามแพทเทิร์นของคุณ (เคส, prefixes, suffixes) แนวคิดเดียวต้องมีชื่อเดียวข้ามไฟล์
• Layering: การพึ่งพาไปในทิศทางที่อนุญาตเท่านั้น เลเยอร์ล่างไม่ import เลเยอร์บน
• Errors: คืนค่าความล้มเหลวพร้อมบริบท ไม่มีการละเลยเงียบ
• Logging: ระดับถูกต้อง ฟิลด์คงที่ และไม่มีความลับหรือข้อมูลส่วนบุคคล
• Final pass: ผู้ตรวจระบุชัด: “no mandatory violations found” หรือระบุการละเมิดที่ต้องแก้ก่อน merge

เก็บพรอมต์เทมเพลตสั้น ๆ และวางมันกับแต่ละการเปลี่ยนแปลง:

Review ONLY the changed code against our rules for naming, layering, errors, and logging.
List mandatory violations first (with file + line if available). Then list optional suggestions.
End with either: “no mandatory violations found” or “mandatory violations found”.

ตัวอย่าง: ฟังก์ชันใหม่ procUsr() ใน handler ที่เขียนไปยัง PostgreSQL โดยตรง ควรล้มทั้ง naming และ layering แม้ว่าฟีเจอร์จะทำงานได้ การจับมันตั้งแต่ตรงนี้จะป้องกันการคัดลอก-วางแพร่ปัญหา

ตัวอย่าง: รีวิวสมจริงที่แก้ปัญหาได้ตั้งแต่ต้น

เพื่อนร่วมทีมเพิ่ม endpoint ใหม่: POST /v1/invoices/{id}/send มันแตะ handler, service, และ storage

ในพาสแรก คุณต้องการรายงาน ไม่ใช่การเขียนใหม่:

Pass 1 (report only)
You are a strict style checker. Read the patch.
Rules: naming must match our guide, handlers call services only, services call storage only, no SQL in handlers,
errors must be wrapped with context, logs must be structured and not leak PII.
Output: a numbered list of violations with file:line, rule name, and one-sentence impact. Do not propose fixes.
If a rule might be intentionally broken, ask one clarification question.

ผลลัพธ์ทั่วไป: SendInvoiceNow() vs SendInvoice การตั้งชื่อไม่ตรงกัน, handler เรียก db.QueryRow โดยตรง, คืนค่า raw err โดยไม่มีบริบท, และล็อกที่ดังเกินไปเช่น log.Printf("sending invoice %v", invoice) ที่ dump วัตถุเต็ม

พาสที่สองขอการแก้ไขที่เล็กและปลอดภัย:

Pass 2 (minimal fix suggestions)
Using the violations list, propose the smallest code edits to comply.
Constraints: keep behavior the same, no refactors beyond what is needed, show suggested function names and where code should move.
For each fix, include 1-2 lines of example code.

ถ้าการละเมิดกฎได้รับอนุญาต ให้บอกตั้งแต่ต้น: "Exceptions are permitted only if you add a short comment explaining why, and you add a follow-up task to remove the exception."

หลังการแก้ handler จะกลายเป็น adapter บาง ๆ, service ดูแล workflow, storage ดูแล query, ข้อผิดพลาดกลายเป็น fmt.Errorf("send invoice: %w", err) และล็อกเป็นบรรทัดเดียวสะอาดพร้อมฟิลด์ที่ปลอดภัย (invoice ID ไม่ใช่ invoice ทั้งหมด)

ขั้นตอนถัดไป: ทำให้เป็นกิจวัตรโดยไม่ทำให้ช้าลง

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

เก็บบล็อกกฎขนาดเล็กไว้บนสุดของพรอมต์และวางมันในทุกรีวิวโดยไม่เปลี่ยน ถ้าทุกคนแก้กฎทุกครั้ง คุณจะไม่มีมาตรฐาน แต่อยู่ในเวทีถกเถียง

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

ถ้าคุณทำงานใน flow การสร้างด้วยแชทอย่าง Koder.ai (koder.ai) ควรรันการเช็กเกทเดียวกันระหว่างการเปลี่ยน ไม่ใช่แค่ตอนท้าย ฟีเจอร์อย่างการวางแผน snapshots และ rollback ช่วยให้การแก้สไตล์เล็ก ๆ และย้อนกลับได้ก่อนคุณส่งซอร์สโค้ดออกไป