เวิร์กโฟลว์ Greenfield ของ Claude Code: จากรีโปเปล่าสู่สไลซ์แรก

สิ่งที่คุณพยายามหลีกเลี่ยงเมื่อเริ่มแบบ Greenfield

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

มีความล้มเหลวบางอย่างที่เกิดซ้ำ ๆ:

• โค้ดที่ “ทำงานบนเครื่องของฉัน” เพราะการตั้งค่าอยู่ในความทรงจำของใครบางคน ไม่ได้อยู่ในสคริปต์
• ต้นไม้โฟลเดอร์ที่สะท้อนลำดับการสร้าง ไม่ใช่วิธีที่แอปควรเติบโต
• วงจรที่แต่ละพรอมต์ใหม่เขียนทับการตัดสินใจก่อนหน้า ทำให้ไม่มีอะไรคงที่

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

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

“สไลซ์แนวตั้ง” คือฟีเจอร์จิ๋วแบบ end-to-end ที่พิสูจน์ว่าแอปของคุณมีอยู่จริง ไม่ใช่เพียงม็อก UI หรือแค่ตารางฐานข้อมูล มันคือเส้นบาง ๆ ข้ามทั้งระบบ เช่น หน้าเพจที่มีฟอร์ม, จุดเชื่อมต่อ API หนึ่งรายการที่บันทึกข้อมูล, การเขียนอ่านฐานข้อมูลหนึ่งครั้ง และผลลัพธ์ที่เห็นได้กลับมาบนหน้า

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

ตัดสินใจก่อนสร้างอะไรเลย: สไลซ์แรก

สไลซ์แรกที่ชัดเจนจะทำให้รีโปอยู่ในระเบียบและพรอมต์มีโฟกัส นี่คือเวลาที่ต้องตัดสินใจว่าสิ่งที่จะสาธิตแบบ end-to-end คืออะไร ไม่ใช่สิ่งที่คุณหวังให้เป็นผลิตภัณฑ์เต็มรูปแบบ

เลือกเรื่องราวผู้ใช้ที่เล็กที่สุดซึ่งพิสูจน์ว่าแอปทำงานทั้งเส้นทาง สไลซ์ที่ดีแตะทั้ง UI ข้อมูล และการกระทำจริงหนึ่งอย่าง ตัวอย่าง: “ในฐานะผู้ใช้ ฉันสามารถเพิ่มงานและเห็นมันปรากฏในรายการหลังรีเฟรช” มันเล็ก แต่บังคับให้มี routing, การตรวจสอบความถูกต้อง, การเก็บข้อมูล และหน้าจอพื้นฐาน

เลือกแพลตฟอร์มเป้าหมายหนึ่งเดียวสำหรับสัปดาห์ที่ 1 และยึดติดกับมัน ถ้าคุณเริ่มเว็บ ให้ทำเฉพาะเว็บ อย่าเพิ่มหน้าจอมือถือ “เผื่อไว้” ถึงแม้คุณจะวางแผนใช้แพลตฟอร์มอย่าง Koder.ai ต่อไป ผลลัพธ์จะดีกว่าถ้าสไลซ์แรกอยู่ในเลนเดียว (React เว็บ หรือ Go API หรือ Flutter)

กำหนดความหมายของ “เสร็จสำหรับสัปดาห์ที่ 1” เป็นข้อ ๆ ง่าย ๆ:

• รันในเครื่องจากการโคลนใหม่ด้วยคำสั่งเดียว
• ฟีเจอร์ทำงานหนึ่งอย่างที่คลิกผ่านได้แบบ end-to-end
• ข้อผิดพลาดแสดงข้อความที่คนอ่านเข้าใจได้ (ไม่ใช่ stack trace)
• ข้อมูลถูกเก็บไว้ที่ไหนสักแห่งที่เรียบง่าย (แม้เป็นฐานข้อมูลท้องถิ่น)

แล้วเขียนสามข้อที่ไม่ใช่เป้าหมายเพื่อปกป้องขอบเขต เช่น: ไม่มี auth, ไม่มีระบบธีม, ไม่มี background jobs

เมื่อการตัดสินใจเหล่านั้นถูกเขียนลงแล้ว พรอมต์สำหรับการสร้างจะสามารถเข้มงวดได้: สร้างเฉพาะสิ่งที่สนับสนุนสไลซ์ และปล่อยสิ่งอื่น ๆ ไว้เป็น TODO

การตัดสินใจเบื้องต้นที่จะประหยัดงานแก้ซ้ำ

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

ก่อนอื่น ตัดสินรูปร่างของแอป ถ้าคุณจริงจังว่าจะต้องมี UI บราวเซอร์และแบ็กเอนด์ ให้เริ่มด้วยสองส่วนที่ชัดเจน (frontend + API) และที่เก็บสัญญาร่วมกัน (API types หรือสคีมาง่าย ๆ) ถ้าแอปสามารถเป็นเว็บที่เรนเดอร์ฝั่งเซิร์ฟเวอร์เดี่ยว ให้เก็บเป็นโค้ดเบสเดียวเพื่อให้การพัฒนาในเครื่องง่าย

ต่อมา ตกลงกฎการคอนฟิก ใช้ไฟล์ env ท้องถิ่น อย่าเก็บใน git และคอมมิตเทมเพลตแทน (เช่น .env.example) พร้อมค่าตัวอย่างปลอดภัยและคอมเมนต์สั้น ๆ วิธีนี้ช่วยให้การ onboard ง่ายและลดการรั่วไหลของความลับ

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

ชุดการตัดสินใจเริ่มต้นง่าย ๆ:

• รูปร่างแอป: แอปเดียวหรือ frontend + API
• คอนฟิก: .env ท้องถิ่น, คอมมิต .env.example
• พอร์ต: หนึ่งสำหรับเว็บ หนึ่งสำหรับ API หนึ่งสำหรับ DB (ถ้าจำเป็น)
• ชื่อ: ใช้สไตล์การตั้งชื่อเดียวสำหรับโฟลเดอร์และบริการ
• ความลับ: อย่าเก็บในรีโป ให้หมุนเมื่อรั่วไหล

ตัวอย่าง: คุณเลือก web บนพอร์ต 3000 และ api บนพอร์ต 8080 เทมเพลต env ของคุณรวม API_URL=http://localhost:8080 และ DATABASE_URL=... เมื่อ Claude สร้างสคริปต์และเอกสารต่อไป ทุกอย่างจะเข้าที่แทนที่จะลอยไป

วิธีพรอมต์ให้ Claude Code คงโครงสร้าง

เริ่มด้วยการขอสแกฟโฟลด์ที่รันได้ แทนที่จะขอ “ทั้งแอป” วิธีที่เร็วที่สุดสู่ผลลัพธ์ยุ่งเหยิงคือขอฟีเจอร์ก่อนที่คุณมีที่วางมัน

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

วิธีง่าย ๆ ที่ช่วยรักษาระเบียบคือตั้งกฎในพรอมต์:

• สร้างโครงกระดูกที่รันได้เล็กที่สุดก่อน (หน้า hello, health endpoint, หรือหน้าจอหนึ่งหน้า)
• เสนอโครงสร้างโฟลเดอร์และอธิบายแต่ละโฟลเดอร์ใน 1 ประโยค
• เพิ่มสคริปต์ที่ทำงานบนเครื่องใหม่ (install, dev, test, build) และระบุ prerequisites
• เก็บการเปลี่ยนแปลงเป็นชิ้นขนาด PR เดียว และระบุไฟล์ที่จะถูกสร้างหรือแก้ไขอย่างชัดเจน
• หยุดหลังการสแกฟโฟลด์และบอกวิธีรันมัน

นี่คือพรอมต์ที่คุณสามารถนำกลับมาใช้และปรับแต่งได้:

You are working in an empty repo. Create a minimal runnable skeleton.

Constraints:
- Keep it small: no real features yet.
- Propose a clear folder structure and add brief comments in each folder’s README.
- Add scripts for: setup, dev, test, build. They must work on a fresh machine.
- Tell me exactly how to run it, and what output I should see.
- After generating, stop and wait for my “ran it” confirmation.

Output:
1) File tree
2) Key files (only)
3) Run instructions

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

ขั้นตอนทีละขั้น: จากรีโปเปล่าสู่โครงกระดูกที่รันได้

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

สร้างรีโปและเขียน README เล็ก ๆ ในขณะที่ทุกอย่างยังใหม่ เก็บให้เป็นประโยชน์: prerequisites, คำสั่ง dev เดียว, และวิธีรันเทสต์ (แม้เทสต์จะว่างในตอนนี้)

ต่อมาเลือกเลเอาต์ระดับบนที่ตรงกับรูปร่างแอปที่คุณเลือก

ถ้าคุณกำลังสร้างชิ้นส่วนที่ต้อง deploy หลายชิ้น (เช่น frontend + API) โครงสร้างแบบ workspace อาจช่วยได้:

/
  apps/
  packages/
  scripts/
  docs/
  README.md

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

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

ทำให้ประสบการณ์นักพัฒนาทำนายได้ด้วยคำสั่งเดียวที่ทำงานได้จากโฟลเดอร์รูทของรีโป นี่คือลักษณะง่าย ๆ:

{
  "scripts": {
    "dev": "echo \"start dev server here\"",
    "build": "echo \"build here\"",
    "test": "echo \"tests here\"",
    "lint": "echo \"lint here\""
  }
}

ก่อนจะให้ AI สร้างอะไรเพิ่มเติม ให้รันคำสั่ง dev นั้น ยืนยันว่ามันออกอย่างสะอาด (หรือบูตเซิร์ฟเวอร์ตัวอย่างได้) แล้วคอมมิตครั้งแรกด้วยเฉพาะสแกฟโฟลด์ ถ้าทีมของคุณ (หรือคุณในอนาคต) สามารถทำซ้ำการตั้งค่าจากศูนย์ได้ คุณก็พร้อมที่จะสร้างสไลซ์แรก

โครงสร้างโฟลเดอร์ที่คุณสามารถรักษาไว้ขณะที่แอปเติบโต

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

ถ้าคุณทำงานภายในแอปเดี่ยว (หรือภายในโฟลเดอร์ apps/<name>/) เลเอาต์ภายในง่าย ๆ มักจะรับมือได้ดี:

• src/ โค้ดแอป (ฟีเจอร์ ส่วนที่ใช้ร่วมกัน จุดเข้า)
• config/ คอนฟิกที่ไม่เป็นความลับ
• tests/ เทสต์ระดับสูงที่อ่านเหมือนพฤติกรรมผู้ใช้
• scripts/ สคริปต์ช่วยเหลือ (ตั้งค่า dev, รีเซ็ต db, งานปล่อย)
• docs/ โน้ตและเช็คลิสต์สั้น ๆ ที่คุณจะดูแลจริง

ภายใน src/ แยกโค้ดฟีเจอร์ออกจากโค้ดแชร์ตามรูปแบบการเปลี่ยนแปลง โค้ดฟีเจอร์เปลี่ยนบ่อยและควรอยู่ใกล้กัน ส่วนที่แชร์ควรเป็นเบสิกและนำกลับมาใช้ใหม่ได้

กฎปฏิบัติ: ใส่หน้าจอ UI, handler, และโลจิกเฉพาะฟีเจอร์ไว้ใต้ src/features/<featureName>/... ใส่สิ่งอย่าง logging, API clients, คอมโพเนนต์ดีไซน์ซิสเต็ม, และยูทิลิตี้ทั่วไปไว้ใต้ src/shared/... ถ้าฟังก์ชันช่วยเหลือมีความหมายเฉพาะฟีเจอร์เดียว ให้เก็บไว้ในฟีเจอร์นั้น ถึงแม้ดูเหมือนนำกลับมาใช้ได้ ให้ย้ายเมื่อคุณมีการใช้อีกครั้งจริง ๆ

ชื่อโฟลเดอร์ควรบอกหน้าที่ ไม่ใช่เทคโนโลยี “features” และ “shared” ยังคงมีความหมายเมื่อสแตกของคุณเปลี่ยน หลีกเลี่ยงชื่ออย่าง “misc” หรือ “new”

เก็บ docs/ ให้เล็ก ตัวเริ่มต้นที่ดีคือ docs/checklists.md มีไม่กี่บรรทัด: วิธีรัน วิธีทดสอบ วิธีเพิ่มโฟลเดอร์ฟีเจอร์ใหม่ และความหมายของ “เสร็จ”

สคริปต์บิลด์ที่ทำให้โปรเจกต์คาดเดาได้

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

เริ่มด้วยชุดคำสั่งเล็ก ๆ และรักษาไว้ให้ธรรมดา ถ้ามีคนใหม่เข้าร่วม (หรือคุณกลับมาหลังสองสัปดาห์) เขาไม่ควรต้องใช้แฟลกพิเศษหรือขั้นตอนลับ

นี่คือพื้นฐานง่าย ๆ ที่ปรับใช้ได้กับสแตกใด ๆ:

{
  "scripts": {
    "dev": "node ./scripts/dev.js",
    "build": "node ./scripts/build.js",
    "test": "node ./scripts/test.js",
    "test:quick": "node ./scripts/test.js --quick",
    "test:full": "node ./scripts/test.js --full",
    "format": "node ./scripts/format.js",
    "lint": "node ./scripts/lint.js",
    "smoke": "node ./scripts/smoke.js"
  }
}

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

สคริปต์ build ควรสร้างไดเรกทอรีเอาต์พุตที่สะอาดเสมอ ลบผลลัพธ์เก่าก่อนแล้วสร้าง artifacts ใหม่ นั่นหลีกเลี่ยงบั๊กแปลก ๆ ที่เกิดจากไฟล์เมื่อวาน

สำหรับเทสต์ แยกการเช็กเร็วจากการเช็กช้า การเทสต์เร็วรันทุกการเปลี่ยน (unit tests, type checks) เทสต์เต็มรวม integration และรันก่อน merge

รักษาสไตล์ให้สอดคล้องด้วยคำสั่งเดียว กฎง่าย ๆ: format แก้ให้ถูก ส่วน lint เตือนข้อบกพร่อง

สุดท้าย เพิ่ม smoke check เล็ก ๆ ที่ตรวจสอบพื้นฐานก่อนเสียเวลาดีบัก:

• env vars ที่ต้องมีถูกตั้งค่า (และไม่ว่าง)
• พอร์ตที่เลือกว่าง
• แอปสามารถเริ่มและตอบคำขออย่างง่ายได้
• การเชื่อมต่อฐานข้อมูลทำงาน (ถ้าใช้)
• ผลลัพธ์ของ build มีอยู่หลัง build

สร้างฟีเจอร์สไลซ์แนวตั้งแรก

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

เลือกสิ่งที่น่าเบื่อแต่มีประโยชน์ เช่น “เพิ่มโน้ต” หรือ “สร้างงาน” เก็บให้เล็กพอที่จะเสร็จในช่วงเวลาสั้น ๆ แต่สมบูรณ์พอที่คุณจะคลิกและเห็นสถานะเปลี่ยน

สไลซ์ที่ดีประกอบด้วยสี่ส่วน: เส้นทางหรือหน้าจอหนึ่งหน้า, ฟอร์มหนึ่งอัน, การกระทำบันทึกหนึ่งอย่าง, และการแสดงผลหนึ่งอย่าง ตัวอย่าง: หน้า “New Task” มีช่องใส่ชื่อ ปุ่ม Save เรียกฟังก์ชันเดียว และรายการที่แสดงงานที่บันทึก

เริ่มด้วยสโตร์สำรองเพื่อให้คุณเคลื่อนไหวเร็ว อาเรย์ในหน่วยความจำ ไฟล์ JSON ท้องถิ่น หรืออินเทอร์เฟซสตับง่าย ๆ ก็พอ ข้อสำคัญคือสร้างขอบเขตที่คุณจะเปลี่ยนได้ภายหลัง ถ้าวันหนึ่งโค้ดเรียก taskRepository.save(task) การสลับไปยังฐานข้อมูลจริงจะเป็นการเปลี่ยนเล็ก ๆ ไม่ใช่การเขียนใหม่

เก็บ UI ให้เรียบ งดการถกเถียงระบบดีไซน์ สถานะว่าง และแอนิเมชัน

การตรวจยอมรับที่ทำได้ในสองนาที:

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

ทำให้เสถียรพอที่จะวนซ้ำ

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

ตั้งบาร์เล็ก ๆ ของความเสถียรให้บรรลุทุกครั้งที่เพิ่มสไลซ์:

• smoke test หนึ่งรายการพิสูจน์ว่าแอปบูตและหน้า/เส้นทางหลักเรนเดอร์
• smoke test หนึ่งรายการที่ทดสอบสไลซ์แบบ end-to-end (แม้จะใช้ฐานข้อมูลทดสอบ)
• ข้อความแสดงความผิดพลาดชัดเจนที่ผู้ใช้ทั่วไปทำอะไรได้ (ไม่ใช่ stack trace)
• ล็อก dev ที่อธิบายว่าเกิดอะไรขึ้นโดยไม่พิมพ์ความลับ
• พึ่งพาน้อยที่สุด ระบุเวอร์ชันและอัปเกรดอย่างมีจุดประสงค์

ตัวอย่างคอนกรีต: สไลซ์แรกของคุณให้ผู้ใช้สร้าง “Project” และเห็นในรายการ เพิ่มเทสต์ที่เริ่มเซิร์ฟเวอร์ เรียก endpoint สร้าง แล้วดึงรายการเพื่อตรวจว่าไอเท็มใหม่ปรากฏ ถ้ามันล้ม ควรล้มดัง ๆ พร้อมข้อความช่วยเหลือ เช่น “Create Project endpoint returned 500” ไม่ใช่เอาต์พุตยาว

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

ล็อกมีประโยชน์เมื่อตอบคำถาม: คำขอไหน ใคร (หรือ anonymous) อะไรล้ม และที่ไหน ใน dev ให้ใส่ request id และเวลา แต่หลีกเลี่ยงการพิมพ์โทเค็น รหัสผ่าน คีย์ API หรือ payload เต็มโดยปริยาย

เพิ่ม health check เล็ก ๆ บนเว็บอาจเป็น endpoint /health ที่คืนค่า ok บนมือถืออาจเป็นสถานะ “Connected” ที่เปลี่ยนเป็น “Offline” เมื่อแอปติดต่อแบ็กเอนด์ไม่ได้ มันเป็นสัญญาณเร็วก่อนที่คุณจะดีบักผิดจุด

กับดักทั่วไปเมื่อใช้ AI สำหรับโปรเจกต์ Greenfield

วิธีที่เร็วที่สุดจะเสียการเริ่มต้น Greenfield คือขอโมเดลให้สร้างทั้งแอป แล้วรันทีหลัง การสร้างขนาดใหญ่ซ่อนความผิดเล็กน้อย: dependency ขาด พาธ import ผิด สคริปต์สมมติว่ามีเครื่องมือที่คุณไม่มี ปฏิบัติต่อทุกผลลัพธ์เหมือนสิ่งที่คุณควรจะรันได้ภายในไม่กี่นาที

กับดักอีกอย่างคือออกแบบสถาปัตยกรรมสมบูรณ์แบบก่อนมีฟีเจอร์ การถกเถียงชื่อโฟลเดอร์รู้สึกเหมือนมีประสิทธิผล แต่ถ้าไม่มีสไลซ์จริง คุณจะไม่รู้ว่าอะไรอึดอัด โครงสร้างง่ายที่สนับสนุนเส้นทางทำงานหนึ่งเส้นดีกว่าโครงสร้างเจ๋งที่คุณยังไม่ได้ทดสอบ

การไหลของคำสั่ง (command drift) ก็พบบ่อย AI เพิ่มวิธีใหม่ในการเริ่มเซิร์ฟเวอร์ คุณเพิ่มอีกคำสำหรับเทสต์ และในไม่ช้าก็ไม่มีใครรู้ว่า “คำสั่ง” ไหนคือคำสั่งจริง ถ้าเพื่อนร่วมทีมโคลนรีโปและถาม “จะรันยังไง?” คุณเริ่มจ่ายดอกเบี้ยแล้ว

ความผิดพลาดที่ทำให้ต้องแก้ซ้ำมากที่สุด:

• สร้างบริการ หน้าจอ และคอนฟิกหลายอย่างในครั้งเดียว แทนที่จะสร้างเส้นทางที่รันได้ก่อน
• ดึง auth, payments, สไตลิงซับซ้อน, และโมเดลข้อมูลเต็มรูปแบบ ก่อนที่ฟีเจอร์แรกจะทำงาน end-to-end
• ปล่อยให้คำแนะนำการตั้งค่าอยู่ในแชตแทนที่จะเป็นสคริปต์ (หรือ README เดียว)
• ลืมเทมเพลต env ที่สะอาด ทำให้เครื่องถัดไปเริ่มไม่ได้โดยไม่เดา

ตัวอย่างง่าย ๆ: คุณสร้างแอป “สมบูรณ์” ที่มี login, theming, billing แต่การรันครั้งแรกล้มเพราะคีย์ลับหายและไม่มี .env.example คุณเลยเสียเวลาหนึ่งชั่วโมงแก้การตั้งค่าแทนเรียนรู้ว่าฟีเจอร์ใช้ได้จริงหรือไม่

รักษาความจริงใจ: คำสั่งที่รันได้หนึ่งคำสั่ง ฟีเจอร์เล็ก ๆ หนึ่งชิ้น เทมเพลต env หนึ่งอัน แล้วค่อยขยาย

เช็คลิสต์ด่วนก่อนเริ่มวนซ้ำ

ก่อนเพิ่ม “อีกหนึ่งฟีเจอร์” ให้แน่ใจว่าโปรเจกต์หยิบขึ้นมาได้ง่ายพรุ่งนี้ (หรือคนอื่นจะทำ) ความเร็วไม่ใช่เป้าหมายเดียว ความคาดเดาได้ต่างหาก

• รันด้วยคำสั่งเดียว: ผู้พัฒนาใหม่สามารถคัดลอกเทมเพลต env ตั้งค่าค่าจำเป็นไม่กี่ค่า และสตาร์ทแอปด้วยคำสั่งเดียว ถ้าต้องมีขั้นตอนเพิ่ม (DB setup, migrations, seed data) ให้จับรวมในสคริปต์
• สคริปต์ครอบคลุมพื้นฐาน: คำสั่งชัดเจนสำหรับ dev, test, build, และ smoke check ที่เร็ว
• โครงสร้างชัดเจน: เลเอาต์บอกเรื่องราวได้ (โค้ดแอป, คอนฟิก, สคริปต์, เทสต์) โดยไม่ต้องอ่านทั้งโค้ดเบส
• เส้นทางสาธิตสไลซ์: คุณอธิบายเดโมได้ในประโยคเดียว เช่น “สร้างไอเท็ม, เห็นในรายการ, รีเฟรช, ยังอยู่”
• จุดย้อนกลับ: ก่อนการเปลี่ยนใหญ่ มีจุดปลอดภัยให้กลับไป (คอมมิตสะอาด, แท็ก, หรือ snapshot/rollback)

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

ขั้นตอนถัดไป: เปลี่ยนเวิร์กโฟลว์เป็นนิสัยที่ทำซ้ำได้

การเริ่ม Greenfield ให้ผลตอบแทนต่อเมื่อคุณทำมันซ้ำได้ หลังจากสไลซ์แรกของคุณรัน end-to-end ให้แช่แข็งส่วนที่ดีเป็นเทมเพลตเล็ก ๆ: รูปแบบโฟลเดอร์เดียวกัน ชื่อสคริปต์เดิม ๆ และวิธีการต่อ UI, API, และข้อมูลเข้าด้วยกัน

ปฏิบัติต่อสไลซ์แรกเป็นตัวอย่างอ้างอิง เมื่อเริ่มสไลซ์ที่ 2 ให้คัดลอกรูปร่าง ไม่ใช่โค้ด ถ้าสไลซ์ที่ 1 มี route, handler, data access layer, และเทสต์พื้นฐาน สไลซ์ที่ 2 ควรตามเส้นทางเดียวกัน

เก็บการวางแผนให้เบา หน้าหนึ่งพอสำหรับสไลซ์ต่อไป 2–3 ชิ้น: เป้าหมายและการกระทำผู้ใช้สำหรับแต่ละสไลซ์ (หนึ่งประโยค), ข้อมูลที่ต้องการ, การตรวจสอบว่า “เสร็จ”, และความเสี่ยงที่ควรทดสอบเร็ว

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

ถ้าคุณชอบลูปการสร้างแบบแชตเป็นหลัก Koder.ai (koder.ai) เป็นอีกตัวเลือกหนึ่งที่รองรับโหมดวางแผน บันทึกสแนปชอตและการย้อนกลับ และสามารถส่งออกรหัสต้นฉบับเมื่อคุณต้องการย้ายโปรเจกต์ไปที่อื่น

เป้าหมายคือเวิร์กโฟลว์ที่คุณทำได้โดยไม่ต้องคิด: วางแผน 2–3 สไลซ์ สร้างหนึ่งสไลซ์ ทำให้เสถียร แล้วทำซ้ำ