เรียนรู้วิธีลดบริบทที่ละเอียดอ่อนใน Claude Code พร้อมเทมเพลตพรอมต์เวิร์กโฟลว์การแชร์ไฟล์ และขั้นตอนการเซ็นเซอร์ที่ยังให้ความช่วยเหลือการเขียนโค้ดได้อย่างมีประสิทธิภาพและปลอดภัย
“บริบท” คือทุกสิ่งที่คุณให้โมเดลใช้: ชิ้นโค้ด, stack traces, ไฟล์ config, ตัวแปรสภาพแวดล้อม, ตัวอย่างฐานข้อมูล, สกรีนช็อต และแม้แต่ข้อความก่อนหน้าภายในแชทเดียวกัน บริบทมากขึ้นอาจเร่งการดีบัก แต่ก็เพิ่มโอกาสที่คุณจะวางสิ่งที่ไม่ตั้งใจจะเผยแพร่
การแชร์เกินกว่าที่ควรเกิดขึ้นเมื่อมีแรงกดดัน บั๊กบล็อคการปล่อย, การพิสูจน์ตัวตนเสียก่อนการสาธิต, หรือเทสต์ที่ผิดพลาดใน CI ในขณะนั้นง่ายที่จะวางทั้งไฟล์ ทั้งล็อก แล้วทั้ง config “ไว้เผื่อ” นิสัยทีมก็ผลักไปทางเดียวกัน: ในการรีวิวโค้ดและการดีบัก การมองเห็นทั้งหมดเป็นเรื่องปกติ แม้ว่าแค่ชิ้นเล็ก ๆ จะเพียงพอ
ความเสี่ยงไม่ใช่สมมติฐาน เพียงการวางครั้งเดียวอาจรั่วไหลความลับ ข้อมูลลูกค้า หรือรายละเอียดระบบภายใน ตัวอย่างที่พบบ่อยได้แก่:
เป้าหมายไม่ใช่การเป็นคนลับ แต่คือการแชร์ชิ้นเล็กที่สุดที่ยังสร้างปัญหาได้หรืออธิบายการตัดสินใจได้ เพื่อให้คุณได้รับคำช่วยเหลือในคุณภาพเดียวกันด้วยความเสี่ยงที่น้อยลง
แบบจำลองคิดง่าย ๆ: ถือผู้ช่วยเป็นเพื่อนร่วมงานภายนอกที่ไม่ต้องการรีโปทั้งชุด เริ่มด้วยคำถามเฉพาะ (“ทำไมคำขอนี้ถึงคืน 401?”) แล้วแชร์เพียงสิ่งที่สนับสนุนคำถามนั้น: อินพุตที่ล้มเหลว, ผลลัพธ์ที่คาดหวัง, ผลลัพธ์จริง, และเส้นทางโค้ดแคบ ๆ ที่เกี่ยวข้อง
ถาการเรียกล็อกอินล้มเหลว คุณมักไม่ต้องการโมดูล auth ทั้งหมด คู่คำขอ/การตอบที่ถูกทำความสะอาด, ฟังก์ชันที่สร้าง headers, และคีย์ config ที่เกี่ยวข้อง (โดยแทนค่าจริง) มักเพียงพอ
เมื่อคุณขอความช่วยด้านการเขียนโค้ด “บริบท” ไม่ได้เป็นแค่ซอร์สโค้ด แต่มันคือทุกอย่างที่อาจช่วยใครสักคนล็อกอิน ระบุตัวบุคคล หรือตีแผนผังระบบของคุณ เริ่มจากการรู้ว่าสิ่งไหนเป็นพิษเมื่อต้องวาง
ข้อมูลรับรองเปลี่ยนชิ้นโค้ดจากสิ่งที่ช่วยเหลือให้เป็นเหตุการณ์ความปลอดภัย ซึ่งรวมถึงคีย์ API และโทเค็น, คีย์ส่วนตัว, คุกกี้เซสชัน, signed URLs, ความลับของ client ใน OAuth, รหัสผ่านฐานข้อมูล และ “โทเค็นชั่วคราว” ที่พิมพ์ในล็อก
สิ่งที่ทำให้แปลกใจคือลีคแบบอ้อม ข้อความข้อผิดพลาดอาจมี headers เต็มรูปแบบพร้อม Authorization bearer token, หรือ dump ตัวแปรสภาพแวดล้อมสำหรับดีบัก
ข้อมูลที่ผูกกับบุคคลอาจเป็นความลับ แม้มันจะดูไม่เป็นอันตรายด้วยตัวเอง ให้ระวังอีเมล, ชื่อ, เบอร์โทร, ที่อยู่, ID ลูกค้า, ID พนักงาน, ตั๋วซัพพอร์ตที่มีบทสนทนา, และรายละเอียดการชำระเงิน
ถ้าคุณต้องการข้อมูลเพื่อทำซ้ำบั๊ก ให้เปลี่ยนเร็กคอร์ดจริงเป็นของปลอมที่สมจริง เก็บรูปแบบ (ฟิลด์และชนิด) ไม่ใช่ตัวตน
ข้อเท็จจริงภายในที่ดู “น่าเบื่อ” ก็มีค่าสำหรับผู้โจมตีและคู่แข่ง: โฮสต์เนม, IP, ชื่อรีโป, หมายเลขตั๋ว, ชื่อผู้ขาย, ข้อกำหนดสัญญา, และ URL ของบริการภายใน
แม้แต่ stack trace เดียวก็อาจเปิดเผยพาธโฟลเดอร์ที่มีชื่อผู้ใช้หรือชื่อลูกค้า, การตั้งชื่อบริการ, และเบาะแสบัญชีคลาวด์ (ชื่อบักเก็ต, สตริงภูมิภาค)
ไม่ใช่โค้ดทุกส่วนจะละเอียดอ่อนเท่ากัน ส่วนที่เสี่ยงที่สุดคือสิ่งที่เข้ารหัสการทำงานทางธุรกิจของคุณ: กฎการตั้งราคาและส่วนลด, การตรวจสอบการฉ้อโกง, ตรรกะการแนะนำ, เทมเพลตพรอมต์สำหรับฟีเจอร์ LLM, และเอกสารเชิงกลยุทธ์
ถ้าคุณต้องการความช่วยเหลือเกี่ยวกับบั๊ก ให้แชร์ฟังก์ชันเล็ก ๆ ที่ทำให้เกิดบั๊ก แทนโมดูลทั้งชุด
รายละเอียดที่ละเอียดอ่อนมักแอบมากับที่ที่คุณไม่สังเกต: ความเห็นในโค้ดที่มีชื่อ, ข้อความคอมมิต, TODO ที่อ้างถึงลูกค้า, และ stack traces ที่วาง “ตามตัว” ไฟล์ config เป็นอันตรายเป็นพิเศษเพราะผสมการตั้งค่าที่ปลอดภัยกับความลับ
กฎปฏิบัติ: ถ้าข้อความจะช่วยใครสักคนเข้าใจระบบของคุณเร็วกว่าตัวอย่าง clean-room ให้ถือว่ามันเป็นความลับและเซ็นเซอร์หรือแทนที่มัน
ช่วงเวลาที่ดีที่สุดในการลดการเปิดเผยคือก่อนคุณเปิด editor หยุด 30 วินาทีเพื่อกำหนดผลลัพธ์ มักลดสิ่งที่คุณแชร์ได้มาก
เริ่มด้วยการตั้งชื่อผลลัพธ์ที่ต้องการในประโยคเดียว คุณพยายามจะหาสาเหตุของบั๊ก, รับแผน refactor ปลอดภัย, หรือออกแบบการทดสอบ? แต่ละเป้าหมายต้องอินพุตต่างกัน บั๊กมักต้อง stack trace หนึ่งอันและฟังก์ชันเล็ก ๆ Refactor มักต้องเฉพาะ public interfaces และตัวอย่างการใช้งานสั้น ๆ
จากนั้นเลือก “สิ่งของขั้นต่ำ” หนึ่งอย่างที่พิสูจน์ปัญหา: เทสต์ล้มเหลวเดียว, ชิ้นเล็กที่สุดที่ทริกเกอร์ error, ตัวย่อของล็อกรอบความล้มเหลว, หรือตัวอย่าง config ที่ถูกลดรูปพร้อม placeholder
เมื่อคุณอธิบายข้อมูล ให้ใช้รูปแบบแทนค่าจริงตัวอย่าง “วัตถุ user มี id (UUID), email (string), role (enum), createdAt (timestamp)” มักเพียงพอ หากต้องการตัวอย่าง ให้ใช้ตัวอย่างปลอมที่ตรงตามรูปแบบ ไม่ใช่เร็กคอร์ดจริง
เข้มงวดกับไฟล์ แชร์เฉพาะโมดูลที่คุณกำลังแก้ไขบวกกับอินเทอร์เฟซที่มันเกี่ยวข้อง ถ้าฟังก์ชันเรียกอีกโมดูล คุณมักต้องแค่ซิกเนเจอร์และคำอธิบายสั้น ๆ ว่ามันคืนค่าอะไร ถ้าบั๊กเกี่ยวข้องกับคำขอไปยังบริการอื่น คุณอาจต้องแค่รูปร่างคำขอ รายชื่อหัวข้อ (ไม่ใช่ค่า) และรูปร่างการตอบที่คาดหวัง
ตั้งขอบเขตที่ไม่ปล่อยออกจากเครื่องของคุณ: คีย์ API, ใบรับรองส่วนตัว, โทเค็นการเข้าถึง, ข้อมูลลูกค้า, URL ภายใน, ดัมพ์รีโป, และล็อกผลิตจริง หากกำลังดีบัก 401 ให้แชร์ flow การพิสูจน์ตัวตนและข้อความผิดพลาด แต่แทนค่าโทเค็นด้วย TOKEN_REDACTED และอีเมลด้วย [email protected]
การเซ็นเซอร์ที่ดีไม่ใช่แค่ซ่อนความลับ แต่มันต้องรักษาโครงสร้างของปัญหาเพื่อให้ผู้ช่วยยังคงวิเคราะห์ได้ หากเอาออกมากเกินไปจะได้คำแนะนำแบบกว้าง ๆ ถ้าเอาออกน้อยเกินไปเสี่ยงรั่วข้อมูล
เลือกสไตล์ placeholder แล้วยึดมันข้ามโค้ด, config, และล็อก ความสอดคล้องทำให้ง่ายติดตาม flow
ถ้าโทเค็นเดียวกันปรากฏในสามที่ อย่าแทนสามแบบต่างกัน ใช้ placeholder เช่น API_KEY_1, TOKEN_1, USER_ID_1, CUSTOMER_ID_1, EMAIL_1 และเพิ่มตามต้องการ (TOKEN_2, TOKEN_3)
ตำนานสั้น ๆ ช่วยโดยไม่เปิดค่าจริง:
TOKEN_1: bearer token ที่ใช้ใน Authorization headerCUSTOMER_ID_1: ตัวระบุลูกค้าภายในที่ใช้ในการค้นหาฐานข้อมูลAPI_KEY_1: คีย์ที่ใช้เรียกผู้ให้บริการชำระเงินบางบั๊กขึ้นกับความยาวและโครงสร้าง (การแยก, การ validate, signature checks) ในกรณีนั้นแทนสตริงเฉพาะด้วยค่าปลอมที่ดูเหมือนกัน
ตัวอย่าง:
วิธีนี้ให้คุณบอกว่า “โทเค็นล้มเหลวในการ validate” โดยไม่เปิดเผยโทเค็นจริง
เมื่อแชร์ JSON ให้เก็บคีย์และแทนค่าด้วย placeholder คีย์แสดงสิ่งที่ระบบคาดหวัง ค่ามักเป็นส่วนที่ละเอียดอ่อน
แทนที่จะเป็น:
{"email":"[email protected]","password":"SuperSecret!","mfa_code":"123456","customer_id":"c8b1..."}
แชร์เป็น:
{"email":"EMAIL_1","password":"PASSWORD_1","mfa_code":"MFA_CODE_1","customer_id":"CUSTOMER_ID_1"}
แนวคิดเดียวกันสำหรับ SQL: เก็บชื่อตาราง, joins, และเงื่อนไข แต่เอาค่า literals ออก
WHERE user_id = USER_ID_1 AND created_at > DATE_1ถ้าฟังก์ชันมีตรรกะทางธุรกิจหรือโค้ดกรรมสิทธิ์ ให้บรรยายมัน เก็บเฉพาะสิ่งที่มีผลต่อบั๊ก: อินพุต, เอาต์พุต, ผลข้างเคียง, และการจัดการข้อผิดพลาด
ตัวอย่างสรุปที่ยังช่วยได้:
“signRequest(payload) รับ JSON payload, เพิ่ม timestamp และ nonce, แล้วสร้าง HMAC SHA-256 signature จาก method + path + body. มันคืน {headers, body}. ข้อผิดพลาดเกิดเมื่อ payload มีอักขระนอก ASCII.”
ปกติพอที่จะวิเคราะห์ encoding, canonicalization, และความไม่ตรงกันของ signature โดยไม่เผยการ implement ทั้งหมด
ท้ายพรอมต์ ให้ระบุสิ่งที่คุณเอาออกและสิ่งที่คุณเก็บไว้ มันป้องกันการกลับมาแก้และลดโอกาสที่จะถูกขอให้วางเพิ่ม
ตัวอย่าง:
“Redacted: tokens, emails, customer data, full request bodies. Kept: endpoint paths, status codes, header names, stack trace frames, and the exact error text.”
ถือผู้ช่วยเป็นเพื่อนร่วมงานที่ต้องการแค่ส่วนที่คุณกำลังทำงานอยู่ แชร์อินเทอร์เฟซและคอนแทรกต์แทนไฟล์ทั้งชุด: ซิกเนเจอร์ฟังก์ชัน, ชนิด, รูปร่างคำขอ/การตอบ, และข้อความผิดพลาดที่แน่นอน
การทำ repro แบบขั้นต่ำด้วยภาษาธรรมดามักเพียงพอ: อินพุตที่คุณใช้, สิ่งที่คาดหวัง, สิ่งที่เกิดขึ้นแทน, และโน้ตสภาพแวดล้อมไม่กี่อย่าง (เวอร์ชันรันไทม์, OS, เวอร์ชันเฟรมเวิร์ก) คุณไม่ต้องประวัติโครงการทั้งหมด
เทมเพลตที่มักได้ผลดี:
บล็อก config ที่ sanitize เป็นจุดกึ่งกลางที่มีประโยชน์ มันแสดงปุ่มปรับโดยไม่เผยความลับ:
# sanitized
DB_HOST: "<set>"
DB_PORT: "5432"
DB_USER: "<set>"
DB_PASSWORD: "<redacted>"
JWT_SECRET: "<redacted>"
OAUTH_CLIENT_ID: "<set>"
OAUTH_CLIENT_SECRET: "<redacted>"
ตัวอย่างพรอมต์ปลอดภัย:
“Login fails with 401. Expected 200. Actual response body: ‘invalid token’. Environment: Node 20, local dev, time sync enabled. Request contract: Authorization: Bearer <redacted>. Verify steps: token is issued by /auth/login and used on /me. What are the top causes (clock skew, audience mismatch, signing secret mismatch), and what single check confirms each?”
นิสัยที่เชื่อถือได้คือปฏิบัติเหมือนแพ็กข้อมูลเป็นการทำซ้ำขนาดเล็ก แชร์พอที่จะวินิจฉัยปัญหาและไม่มากกว่านั้น
หนึ่งแนวทางที่ปฏิบัติได้คือโฟลเดอร์ “แชร์ชั่วคราว” แยกจากรีโปจริง คัดลอกไฟล์เข้าไปด้วยมือแทนการแชร์โปรเจคทั้งหมด บังคับให้คุณเลือกอย่างตั้งใจ
รักษาเวิร์กโฟลว์ให้ง่าย:
หลังจากสร้างโฟลเดอร์ อ่านมันในมุมมองคนนอก หากไฟล์ไหนไม่ช่วยดีบักปัญหาโดยเฉพาะ มันไม่ควรอยู่
เมื่อเซ็นเซอร์ ให้หลีกเลี่ยงการทำให้โค้ดหรือล็อกพัง แทนค่าด้วย placeholder ที่ชัดเจนซึ่งคงประเภทและโครงสร้าง ตัวอย่าง:
DATABASE_URL=postgres://user:[email protected]:5432/app
กลายเป็น:
DATABASE_URL=postgres://user:REDACTED@localhost:5432/app
ถ้าบั๊กขึ้นกับการตอบจากบุคคลที่สาม ให้จดรูปร่างการตอบใน README และรวมไฟล์ JSON สังเคราะห์ที่ตรงตามรูปร่าง คุณจะได้ดีบักที่มีความหมายโดยไม่ต้องแชร์ทราฟฟิกจริง
ใช้ลูปที่ทำซ้ำได้เพื่อไม่ต้องด้นสดเมื่ออยู่ภายใต้แรงกดดัน
เขียนสองประโยคก่อน.
รวบรวมอินพุตขั้นต่ำ. นำเฉพาะสิ่งที่ช่วยทำซ้ำหรือวิเคราะห์ปัญหา: ชิ้นโค้ดรอบบรรทัดที่ล้มเหลว, ข้อความผิดพลาดที่แน่นอน, เวอร์ชันที่เกี่ยวข้อง, และ 3–5 ขั้นตอนทำซ้ำ
เซ็นเซอร์โดยไม่ทำให้โครงสร้างแบน. แทนความลับด้วย placeholders และเก็บโครงสร้างไว้ เอาตัวระบุที่ไม่ส่งผลต่อพฤติกรรมออก (ชื่อโปรเจค, tenant IDs, อีเมล). เก็บ placeholders ให้สอดคล้อง
API_KEY=sk_live_...
becomes
API_KEY=<API_KEY>
customer-1234-prod-db
becomes
<DB_HOST_PROD>
ถามคำถามที่มุ่งเป้า. จับคู่ “สาเหตุที่เป็นไปได้ที่สุดคืออะไร?” กับ “ฉันควรเปลี่ยนอะไร?” หากต้องการแพตช์ ให้ขอการเปลี่ยนแปลงที่จำกัดกับชิ้นที่คุณให้ และให้ระบุสมมติฐาน
ตรวจสอบในเครื่อง แล้วเพิ่มแค่ข้อมูลเดียวนอกเหนือ. ทดสอบข้อเสนอแนะ ถ้ามันล้มเหลว ให้เพิ่มเพียงข้อมูลใหม่หนึ่งชิ้น (บรรทัดสแต็กต่อไป, flag config หนึ่งตัว, หรือการทำซ้ำที่แคบลง). อย่ากระโดดไปเพสต์ทั้งไฟล์
การเปิดเผยแบบเพิ่มขึ้นมักให้คำตอบจริงพร้อมรักษาความลับและโค้ดที่ไม่เกี่ยวข้องให้ออกจากพรอมต์
สถานการณ์ที่พบบ่อย: การล็อกอินทำงานบนเครื่องและสเตจ แต่ล้มเหลวใน production คุณต้องการความช่วยเหลือเร็ว แต่ไม่สามารถเพสต์โทเค็นจริง, อีเมลผู้ใช้, โฮสต์ภายใน, หรือมิดเดิลแวร์ auth ทั้งหมดได้
เริ่มจากสิ่งที่สังเกตเห็นได้: รูปร่างคำขอ/การตอบ, รหัสสถานะ, และ stack trace สั้น ๆ หากเกี่ยวกับ JWT คุณยังสามารถแชร์รายละเอียด header ที่ไม่ละเอียดอ่อน (เช่น algorithm ที่คาดหวัง) และข้อมูลเวลา (เช่นความคลาดเคลื่อนเวลา)
ชุดปลอดภัยมักประกอบด้วย:
แล้วถามคำถามเฉพาะ ผลลัพธ์การพิสูจน์ตัวตนที่เกิดเฉพาะ production มักมาจาก clock skew, issuer/audience ผิด, คีย์เซ็นผิด, การหมุนคีย์ขาด, หรือความต่างของ proxy/header
รูปแบบพรอมต์:
I have a production-only login/auth failure. Locally it passes.
Observed behavior:
- Endpoint: POST /api/login
- Production response: 401 with message "invalid token" (generic)
- Staging/local: 200
Sanitized request/response:
- Authorization: Bearer <JWT_REDACTED>
- Expected claims: iss=<ISSUER_PLACEHOLDER>, aud=<AUDIENCE_PLACEHOLDER>
- Token validation library: <LIB_NAME_AND_VERSION>
Sanitized log snippet:
<PASTE 5-10 LINES WITH TOKENS/EMAILS/HOSTS REDACTED>
Question:
Given this, what are the top causes of JWT validation failing only in production, especially clock skew or claim mismatch? What specific checks and log lines should I add to confirm which one it is?
หลังจากได้สมมติฐาน ให้ตรวจสอบอย่างปลอดภัยด้วยการเปลี่ยนแปลงที่คุณสามารถเก็บไว้ได้ เพิ่มล็อกชั่วคราวที่พิมพ์แค่ข้อเท็จจริงที่ไม่ละเอียดอ่อน (exp, iat, now, และรหัสเหตุผลการล้มเหลว). เขียนเทสต์เล็ก ๆ ที่ป้อนโทเค็นเทียมที่ปลอดภัย (หรือโทเค็นสร้างในเครื่อง) และยืนยันพฤติกรรม validator สำหรับ edge cases
แผนง่าย ๆ:
วิธีที่เร็วที่สุดที่จะเสียประโยชน์ด้านความเป็นส่วนตัวคือการแชร์ “สิ่งเล็กน้อยหนึ่งอย่าง” ที่เงียบ ๆ มีทุกอย่าง ตัวอย่างคลาสสิกคือการวาง .env หรือไฟล์ config เต็ม แม้จะลบความลับชัดเจน ไฟล์เหล่านั้นมักมีโฮสต์ภายใน, ชื่อบริการ, feature flags, และเบาะแสสภาพแวดล้อม
Full stack traces เป็นการรั่วไหลอีกบ่อย พวกมันอาจมีชื่อผู้ใช้, ชื่อเครื่อง, ชื่อรีโป, และพาธเต็ม เช่น /Users/alex/company-payments/... บางครั้งมี query strings, HTTP headers, หรือ error objects ที่มีโทเค็น หากต้องการ trace ให้คัดเฉพาะเฟรมที่เกี่ยวข้องและแทนพาธด้วย placeholders ที่สอดคล้อง
payload ลูกค้าจริงเสี่ยงแม้จะ “เล็ก” เพราะ JSON เดียวอาจมีอีเมล, ที่อยู่, order IDs, หรือโน้ตข้อความที่เป็นส่วนตัว ทางที่ปลอดภัยคือตั้ง payload ปลอมที่มีรูปทรงและ edge cases (ฟิลด์ขาด, สตริงยาว, อักขระแปลก) โดยไม่ใช้ค่าจริง
การใช้ placeholders ไม่สอดคล้องกันก็เป็นปัญหา หาก USER_ID หมายถึง “customer id” ที่หนึ่งและ “internal account id” อีกที่ คุณจะได้การวิเคราะห์ผิด เลือกสกีมแล้วยึดมัน
ถ้าข้อความของคุณจะช่วยคนแปลกหน้าให้ล็อกอิน, หาตำแหน่งเซิร์ฟเวอร์, หรือระบุผู้ใช้ มันต้องผ่านการทวนอีกครั้ง
เมื่อพยายามระวัง ความเร็วคือศัตรู รูทีนสั้น ๆ ช่วยให้คุณได้คำตอบที่มีประโยชน์พร้อมรักษาความลับออกจากพรอมต์
ทำหนึ่งรอบเพื่อตรวจหาความลับ แล้วรอบที่สองเพื่อตรวจหาตัวระบุที่ยังเปิดเผยระบบของคุณ:
หลังการเซ็นเซอร์ เก็บรูปร่างไว้ ทิ้งชนิด, สกีมา, ชื่อฟิลด์, รหัสสถานะ, และโครงสร้างตัวอย่าง แต่แทนค่าจริงด้วย placeholders
เพื่อให้คงความสอดคล้อง (โดยเฉพาะเมื่อกดดัน) เขียนกฎการเซ็นเซอร์สั้น ๆ และใช้ซ้ำ สำหรับทีม ให้ทำเป็นเทมเพลตสองบล็อก: “สิ่งที่ฉันแชร์” (ไฟล์, ฟังก์ชัน, endpoints) และ “สิ่งที่ฉันจะไม่แชร์” (ความลับ, ข้อมูล production, โดเมนภายใน)
ถ้าคุณต้องการระดับความปลอดภัยเพิ่ม ให้ทำการทดลองในสภาพแวดล้อมแยกและเก็บการเปลี่ยนแปลงให้ย้อนกลับได้ ใน Koder.ai (koder.ai), โหมดวางแผนช่วยให้คุณร่างการเปลี่ยนแปลงที่เล็กที่สุดเพื่อทดสอบสมมติฐาน และ snapshot พร้อม rollback ทำให้ง่ายลองแก้โดยไม่ดึงบริบทละเอียดอ่อนเข้าไปในพรอมต์ของคุณ
เริ่มจากชิ้นเล็กที่สุดที่จะตอบคำถามได้: อินพุตที่ล้มเหลว, ผลลัพธ์ที่คาดหวังเทียบกับที่เกิดขึ้นจริง, และเส้นทางโค้ดแคบ ๆ ที่เกี่ยวข้อง.
ชุดมาตรฐานที่ดีคือ:
อย่าเพสต์:
.env เต็มรูปแบบ/ดัมพ์ config หรือ raw production logsถ้ามันจะช่วยคนแปลกหน้าให้ล็อกอิน, ระบุตัวบุคคล หรือทำแผนผังระบบของคุณได้ ให้เซ็นเซอร์หรือสรุปมัน
ใช้ตัวแทนที่สอดคล้องกันเพื่อให้ flow อ่านง่าย:
ตัวอย่างสกีมาที่ดี:
TOKEN_1, TOKEN_2API_KEY_1USER_ID_1, รักษาโครงสร้างเมื่อบั๊กขึ้นกับการแยกวิเคราะห์หรือการตรวจสอบ:
กรณีที่พบบ่อย:
8-4-4-4-12วิธีนี้ยังคงพฤติกรรมที่สมจริงโดยไม่เปิดเผยค่าจริง
แชร์คีย์และโครงสร้าง เปลี่ยนค่าแทนการรั่วไหลของข้อมูลจริง.
สำหรับ JSON:
สำหรับ SQL:
ตัวอย่าง:
สรุปในเชิงอินพุต/เอาต์พุตและกฎที่มีผลต่อบั๊กแทนการวางโค้ดกรรมสิทธิ์:
สรุปที่ใช้ได้จริงควรประกอบด้วย:
วิธีนี้มักให้มูลค่าการดีบักเทียบเท่าโดยไม่เปิดเผยการติดตั้งจริงของคุณ
พรอมต์ปลอดภัยแบบง่าย:
อย่าลืมใส่บันทึกการเซ็นเซอร์เช่น:
"Redacted: tokens, emails, customer data, internal hostnames. Kept: endpoint paths, status codes, header names, exact error text."
เพราะไฟล์พวกนี้มักมีทุกอย่างรวมกัน:
ทางเลือกที่ปลอดภัยกว่าเป็นเทมเพลต config:
ใช้การเปิดเผยแบบเพิ่มขึ้น:
วิธีนี้ช่วยให้ขอบเขตเล็กและป้องกันการรั่วไหลโดยบังเอิญเมื่ออยู่ภายใต้ความกดดัน
ชุดข้อมูลที่ใช้งานได้จริงประกอบด้วย:
แล้วถาม:
CUSTOMER_ID_1EMAIL_1เพิ่มตำนานสั้น ๆ เมื่อต้องการ:
TOKEN_1: bearer token ที่ใช้บน /meCUSTOMER_ID_1: ตัวระบุภายในที่ใช้ในการค้นหาฐานข้อมูลWHERE user_id = USER_ID_1 AND created_at > DATE_1<set> หรือ <redacted>