สรุปและแบบฝึกหัด
ประเด็นสำคัญ
- สเปกมาก่อนเสมอ และมันสั้น เป็นย่อหน้าเดียวที่ระบุข้อจำกัดที่สำคัญเอาไว้ รวมถึงข้อจำกัดด้านเวิร์กโฟลว์ที่ไม่เคยปรากฏในตัวแอปที่รันอยู่
- ความลับไม่เคยแตะต้อง repo เลย ทุกโปรเจกต์อ่านคีย์จากตัวแปรสภาพแวดล้อมหรือค่าคอนฟิกที่เข้ารหัสซึ่งตั้งค่าไว้ในแดชบอร์ด
- สแต็กถูกเลือกเพื่อให้มีสิ่งที่ทำพลาดได้น้อยลง ระบบล็อกอินแบบมีคนดูแล ฐานข้อมูลแบบมีคนดูแล การโฮสต์แบบสแตติก ฟังก์ชัน
- อุปสรรคถูกแก้ไขด้วยการป้อนหลักฐานที่แม่นยำให้ AI ทั้งข้อความ error ตัวจริง โค้ดจริง การตั้งค่าดีพลอย และการจำกัดขอบเขตการแก้ไขให้แคบ
- การเปิดตัวหมายถึงการทดสอบจริงกับความเป็นจริง ไม่ใช่แค่ "มันคอมไพล์ผ่าน" ไม่ว่าจะเป็นการซื้อจริง บัญชีที่สอง ลิงก์ลึกบนเว็บไซต์ที่ดีพลอยจริง
ลองทำดู
เลือกไอเดียของคุณเองสักหนึ่งอัน แล้วเขียนสเปกหนึ่งย่อหน้าแบบที่ทั้งสี่กรณีนี้ทำ ระบุการกระทำหลักของแอป ข้อมูลที่ผู้ใช้แต่ละคนมองเห็นได้ และข้อจำกัดด้านเวิร์กโฟลว์อย่างน้อยหนึ่งข้อ (เนื้อหาถูกเผยแพร่ได้อย่างไร ใครทำอะไรได้บ้าง) จากนั้นลิสต์บล็อกส่วนประกอบแบบมีคนดูแลที่คุณจะพึ่งพา เพื่อให้มีโค้ดที่เขียนเองน้อยลงที่อาจพัง จำกัดให้อยู่แค่หนึ่งย่อหน้าบวกกับลิสต์บุลเล็ตสั้น ๆ ถ้ามันยาวเกินกว่านั้น แปลว่าคุณกำลังระบุรายละเอียดมากเกินไป
พรอมต์ประจำบท
I want to build: [one-paragraph description of the app].
Before any code, help me tighten this into a buildable spec.
1. Restate the single core action a user performs.
2. List the data each user can see — and what they must NOT see.
3. Name the workflow constraints that won't show up in the UI
(e.g. "pushing a file should publish it", "only their own data").
4. Recommend a stack that MINIMIZES custom code: managed auth,
managed database, static or serverless hosting where possible.
5. Flag the one part most likely to go wrong, and how we'll test it
against reality (a real purchase, a second account, a deep link).
Keep the spec to a paragraph plus bullets. Push back if it's too big.