AI จะค่าเริ่มต้นไปที่ค่าเฉลี่ยทั่วไปของข้อมูลที่มันถูกเทรนมา ดังนั้นเพื่อให้ได้สไตล์ ของคุณ คุณต้อง แสดงและบังคับใช้ มัน ผ่านตัวอย่าง ไฟล์กฎที่ชัดเจน และ loop ของ linter ที่จับสิ่งที่หลุดรอดไป อย่าพึ่งให้มันเดามาตรฐานของคุณ (WordPress Coding Standards, PSR-12 ฯลฯ)
.eslintrc, phpcs.xml หรือ .editorconfig ของคุณ สิ่งเหล่านี้คือกฎในรูปแบบที่เครื่องตรวจสอบได้ และ AI สามารถอ่านมันได้CLAUDE.md หรือ system prompt ที่ระบุมาตรฐานอย่างชัดเจน "โปรเจกต์นี้ใช้ PSR-12 ใช้ indent 4 ช่อง วาง brace บนบรรทัดถัดไปสำหรับฟังก์ชัน ใช้ snake_case สำหรับ hooks" คำสั่งถาวรดีกว่าการพูดซ้ำทุก prompt# 1. AI generates the change, then you run the project linter on it:
phpcs --standard=phpcs.xml src/NewClass.php
# => src/NewClass.php 12 | ERROR | Expected 1 space after FUNCTION keyword; 0 found
# src/NewClass.php 14 | ERROR | Line indented incorrectly; expected 4 spaces, found 2
# 2. Paste those exact errors back to the AI: "Fix these phpcs errors."
# 3. Re-run until clean. The linter — not the AI's claim — is the source of truth.
Loop นี้ลู่เข้าได้เร็วเพราะ linter ให้ feedback ที่แม่นยำในระดับบรรทัดซึ่ง AI สามารถลงมือทำตามได้โดยตรง แทนที่คุณจะต้องอธิบายสไตล์เป็นร้อยแก้ว
โค้ดที่เพิกเฉยต่อ conventions ของโปรเจกต์สร้าง ความฝืดในการ review และความไม่สม่ำเสมอ แม้ว่ามันจะทำงานถูกต้องในเชิงฟังก์ชัน ผู้ review เสียเวลาไปกับการจัด format และ codebase ก็เคลื่อนออกจากแนวทาง AI ไม่มีการรับรู้ถึง house style ของคุณเว้นแต่คุณจะให้มัน ดังนั้นงานคือการทำให้กฎ ชัดเจนและตรวจสอบได้ ไฟล์กฎสำหรับเจตนา โค้ดที่เป็นตัวแทนสำหรับสำนวน และ linter เป็นผู้บังคับใช้ใน loop วินัยเดียวกันนี้ (config + ตัวอย่าง + การตรวจสอบอัตโนมัติ) ก็คือวิธีที่คุณ onboard เพื่อนร่วมทีมที่เป็นมนุษย์ให้เข้าใจ conventions ของคุณเช่นกัน