เวิร์กโฟลว์
คู่มือนี้ครอบคลุมรูปแบบเวิร์กโฟลว์ทั่วไปสำหรับ OpenSpec และเมื่อควรใช้แต่ละรูปแบบ สำหรับการตั้งค่าเบื้องต้น ดูที่ เริ่มต้นใช้งาน สำหรับคำอ้างอิงคำสั่ง ดูที่ คำสั่ง
ปรัชญา: การกระทำ ไม่ใช่ขั้นตอน
เวิร์กโฟลว์แบบดั้งเดิมบังคับให้คุณผ่านขั้นตอน: การวางแผน จากนั้นการนำไปใช้งาน แล้วจึงเสร็จสิ้น แต่การทำงานจริงไม่ได้เข้ากับกรอบเหล่านั้นได้อย่างพอดี
OPSX ใช้แนวทางที่แตกต่าง:
text
Traditional (phase-locked):
PLANNING ────────► IMPLEMENTING ────────► DONE
│ │
│ "Can't go back" │
└────────────────────┘
OPSX (fluid actions):
proposal ──► specs ──► design ──► tasks ──► implementหลักการสำคัญ:
- การกระทำ ไม่ใช่ขั้นตอน - คำสั่งคือสิ่งที่คุณสามารถทำได้ ไม่ใช่ขั้นตอนที่คุณติดอยู่
- การพึ่งพาอาศัยเป็นตัวอำนวยความสะดวก - มันแสดงสิ่งที่เป็นไปได้ ไม่ใช่สิ่งที่จำเป็นต้องทำต่อไป
การปรับแต่ง: เวิร์กโฟลว์ของ OPSX ขับเคลื่อนโดยสคีมาที่กำหนดลำดับของผลลัพธ์ ดูที่ การปรับแต่ง สำหรับรายละเอียดเกี่ยวกับการสร้างสคีมาแบบกำหนดเอง
สองโหมด
เส้นทางด่วนเริ่มต้น (โปรไฟล์ core)
การติดตั้งใหม่จะใช้ core เป็นค่าเริ่มต้น ซึ่งจะมีคำสั่งดังนี้:
/opsx:propose/opsx:explore/opsx:apply/opsx:archive
ขั้นตอนทั่วไป:
text
/opsx:propose ──► /opsx:apply ──► /opsx:archiveขั้นตอนงานแบบขยาย/เต็มรูปแบบ (เลือกกำหนดเอง)
หากคุณต้องการคำสั่งสำหรับสร้างโครงสร้างและสร้างโค้ดอย่างชัดเจน (/opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:sync, /opsx:bulk-archive, /opsx:onboard) ให้เปิดใช้งานด้วยคำสั่ง:
bash
openspec config profile
openspec updateรูปแบบขั้นตอนงาน (โหมดขยาย)
ฟีเจอร์ด่วน
เมื่อคุณรู้แล้วว่าต้องการสร้างอะไรและแค่ต้องดำเนินการ:
text
/opsx:new ──► /opsx:ff ──► /opsx:apply ──► /opsx:verify ──► /opsx:archiveตัวอย่างบทสนทนา:
text
You: /opsx:new add-logout-button
AI: สร้าง openspec/changes/add-logout-button/
พร้อมสร้าง: proposal
You: /opsx:ff
AI: กำลังสร้างเอกสารประกอบขั้นตอนทั้งหมด...
✓ proposal.md
✓ specs/
✓ design.md
✓ tasks.md
พร้อมสำหรับการใช้งาน!
You: /opsx:apply
AI: กำลังดำเนินงานตามรายการ...
✓ เพิ่มปุ่มออกจากระบบในส่วนหัว
✓ ใช้งานการล้างข้อมูลเซสชัน
✓ เพิ่มกล่องยืนยัน
งานทั้งหมดเสร็จสมบูรณ์!
You: /opsx:archive
AI: ✓ ผสานข้อมูลสเปกแล้ว
✓ เก็บรักษาการเปลี่ยนแปลงแล้วเหมาะสำหรับ: ฟีเจอร์ขนาดเล็กถึงขนาดกลาง การแก้ไขบั๊ก การเปลี่ยนแปลงที่ตรงไปตรงมา
แบบสำรวจ
เมื่อข้อกำหนดไม่ชัดเจนหรือคุณต้องตรวจสอบก่อน:
text
/opsx:explore ──► /opsx:new ──► /opsx:continue ──► ... ──► /opsx:applyตัวอย่างบทสนทนา:
text
You: /opsx:explore
AI: คุณต้องการสำรวจอะไร?
You: ฉันต้องการปรับปรุงประสิทธิภาพการโหลดหน้า แต่ไม่แน่ใจ
ว่าจุดติดขัดอยู่ที่ไหน
AI: ให้ฉันช่วยตรวจสอบ...
[วิเคราะห์ขนาดบันเดิล ระบุคำขอที่ช้า ตรวจสอบ
รูปแบบการเรนเดอร์ของคอมโพเนนต์]
ฉันพบจุดติดขัดหลักสามประการ:
1. รูปภาพขนาดใหญ่ที่ไม่ได้เพิ่มประสิทธิภาพ
2. การดึงข้อมูลแบบซิงโครนัสใน ProductList
3. การเรนเดอร์ซ้ำจากการเปลี่ยนแปลงของ context
คุณต้องการแก้ไขส่วนไหนก่อน?
You: มาแก้ปัญหาการดึงข้อมูลกัน
You: /opsx:new optimize-product-list-fetching
AI: สร้างการเปลี่ยนแปลงแล้ว พร้อมสร้าง: proposal
You: /opsx:continue
AI: กำลังสร้าง proposal จากผลการสำรวจของเรา...
[เขียน proposal โดยรวมข้อมูลเชิงลึกจากการตรวจสอบ]
พร้อมสร้าง: specs, design
คุณต้องการขั้นตอนไหนต่อ?
You: /opsx:continue
AI: กำลังสร้าง specs...เหมาะสำหรับ: การเพิ่มประสิทธิภาพ การแก้ไขข้อผิดพลาด การตัดสินใจเชิงสถาปัตยกรรม ข้อกำหนดที่ไม่ชัดเจน
การเปลี่ยนแปลงแบบคู่ขนาน
ทำงานบนการเปลี่ยนแปลงหลายรายการพร้อมกัน:
text
Change A: /opsx:new ──► /opsx:ff ──► /opsx:apply (กำลังดำเนินการ)
│
สลับบริบท
│
Change B: /opsx:new ──► /opsx:ff ──────► /opsx:applyตัวอย่างบทสนทนา:
text
You: ฉันกำลังทำ add-dark-mode แต่ถูกเรียกไปแก้บั๊ก
You: /opsx:new fix-login-redirect
AI: สร้าง openspec/changes/fix-login-redirect/
You: /opsx:ff
AI: ✓ สร้างเอกสารประกอบขั้นตอนแล้ว
You: /opsx:apply
AI: กำลังทำงานบน fix-login-redirect...
[ใช้งานการแก้ไข]
งานทั้งหมดเสร็จสมบูรณ์!
You: /opsx:archive
AI: ✓ เก็บรักษา fix-login-redirect แล้ว
You: กลับมาทำ dark mode กันเถอะ
You: /opsx:apply add-dark-mode
AI: กำลังดำเนินการต่อ add-dark-mode...
ดำเนินการต่อที่งาน 2.3: อัปเดต Header...เหมาะสำหรับ: กระแสงานแบบคู่ขนาน การหยุดชะงักเร่งด่วน การทำงานร่วมกันในทีม
เมื่อคุณมีการเปลี่ยนแปลงที่เสร็จสมบูรณ์หลายรายการ ให้ใช้ /opsx:bulk-archive:
text
You: /opsx:bulk-archive
AI: พบการเปลี่ยนแปลงที่เสร็จสมบูรณ์ 3 รายการ:
- add-dark-mode (งานทั้งหมดเสร็จ)
- fix-login-redirect (งานทั้งหมดเสร็จ)
- update-footer (งานทั้งหมดเสร็จ)
กำลังตรวจสอบความขัดแย้งของสเปก...
⚠ add-dark-mode และ update-footer ทั้งคู่แตะ specs/ui/
กำลังตรวจสอบโค้ดเพื่อแก้ไข...
การเปลี่ยนแปลงทั้งสองถูกใช้งานแล้ว จะนำไปใช้ตามลำดับเวลา
เก็บรักษาการเปลี่ยนแปลงทั้ง 3 รายการ?
You: ใช่
AI: ✓ เก็บรักษา add-dark-mode แล้ว
✓ เก็บรักษา fix-login-redirect แล้ว
✓ เก็บรักษา update-footer แล้ว
ผสานสเปกตามลำดับ: add-dark-mode → update-footerการเก็บรักษาแบบจำนวนมากจะตรวจจับเมื่อการเปลี่ยนแปลงหลายรายการแตะสเปกเดียวกัน และแก้ไขความขัดแย้งโดยการตรวจสอบว่ามีการใช้งานจริงอย่างไร
การทำให้การเปลี่ยนแปลงสมบูรณ์
ขั้นตอนการทำให้สมบูรณ์ที่แนะนำ:
text
/opsx:apply ──► /opsx:verify ──► /opsx:archive
│ │
ตรวจสอบความถูกต้อง แจ้งเตือนเพื่อซิงค์
ของการใช้งาน หากจำเป็นVerify: ตรวจสอบงานของคุณ
/opsx:verify ตรวจสอบความถูกต้องของการใช้งานเทียบกับเอกสารประกอบของคุณในสามมิติ:
text
You: /opsx:verify
AI: กำลังตรวจสอบ add-auth...
ความสมบูรณ์
✓ งานทั้ง 12 รายการใน tasks.md ถูกตรวจสอบแล้ว
✓ ข้อกำหนดทั้งหมดใน specs มีโค้ดที่สอดคล้องกัน
⚠ สถานการณ์ "หมดเวลาเซสชันหลังไม่มีกิจกรรม" ยังไม่ได้ทดสอบ
ความถูกต้อง
✓ การใช้งานตรงกับเจตนาของสเปก
✓ กรณีขอบเขตจากสถานการณ์ได้รับการจัดการแล้ว
✓ สถานะข้อผิดพลาดตรงกับคำจำกัดความในสเปก
ความสอดคล้อง
✓ การตัดสินใจเชิงการออกแบบสะท้อนอยู่ในโครงสร้างโค้ด
✓ อนุสัญญาการตั้งชื่อสอดคล้องกับ design.md
⚠ การออกแบบกล่าวถึง "event-driven" แต่การใช้งานใช้ polling
สรุป
─────────────────────────────
ปัญหาวิกฤต: 0
คำเตือน: 2
พร้อมเก็บรักษา: ใช่ (มีคำเตือน)
คำแนะนำ:
1. เพิ่มการทดสอบสำหรับสถานการณ์หมดเวลาเซสชัน
2. พิจารณาปรับโครงสร้างเป็น event-driven ตามที่ออกแบบไว้ หรืออัปเดต design.mdสิ่งที่ verify ตรวจสอบ:
| มิติ | สิ่งที่ตรวจสอบ |
|---|---|
| ความสมบูรณ์ | งานทั้งหมดเสร็จ ข้อกำหนดทั้งหมดถูกใช้งาน สถานการณ์ทั้งหมดได้รับการพิจารณา |
| ความถูกต้อง | การใช้งานตรงกับเจตนาของสเปก กรณีขอบเขตได้รับการจัดการ |
| ความสอดคล้อง | การตัดสินใจเชิงการออกแบบสะท้อนอยู่ในโค้ด รูปแบบสอดคล้องกัน |
Verify จะไม่บล็อกการเก็บรักษา แต่จะแสดงปัญหาที่คุณอาจต้องการแก้ไขก่อน
Archive: ทำให้การเปลี่ยนแปลงสมบูรณ์
/opsx:archive เสร็จสิ้นการเปลี่ยนแปลงและย้ายไปยังที่เก็บถาวร:
text
You: /opsx:archive
AI: กำลังเก็บรักษา add-auth...
สถานะเอกสารประกอบ:
✓ proposal.md มีอยู่
✓ specs/ มีอยู่
✓ design.md มีอยู่
✓ tasks.md มีอยู่ (งาน 12/12 เสร็จสมบูรณ์)
สเปกแบบ Delta: ยังไม่ได้ซิงค์กับ main
→ คุณต้องการซิงค์ตอนนี้หรือไม่?
You: ใช่
AI: ✓ ซิงค์สเปกไปยัง openspec/specs/auth/spec.md แล้ว
✓ ย้ายไปยัง openspec/changes/archive/2025-01-24-add-auth/
เก็บรักษาการเปลี่ยนแปลงสำเร็จArchive จะแจ้งเตือนหากสเปกยังไม่ได้ซิงค์ จะไม่บล็อกงานที่ยังไม่เสร็จสมบูรณ์ แต่จะเตือนคุณ
เมื่อใดควรใช้สิ่งใด
/opsx:ff เทียบกับ /opsx:continue
| สถานการณ์ | ใช้ |
|---|---|
| ข้อกำหนดชัดเจน พร้อมสร้าง | /opsx:ff |
| กำลังสำรวจ ต้องการตรวจสอบทุกขั้นตอน | /opsx:continue |
| ต้องการปรับ proposal ก่อนทำ specs | /opsx:continue |
| แรงกดดันด้านเวลา ต้องการความรวดเร็ว | /opsx:ff |
| การเปลี่ยนแปลงที่ซับซ้อน ต้องการการควบคุม | /opsx:continue |
กฎง่ายๆ: หากคุณสามารถอธิบายขอบเขตทั้งหมดได้ล่วงหน้า ให้ใช้ /opsx:ff หากคุณกำลังค้นหาไปเรื่อยๆ ให้ใช้ /opsx:continue
เมื่อใดควรอัปเดตเทียบกับเริ่มใหม่
คำถามที่พบบ่อย: เมื่อใดที่การอัปเดตการเปลี่ยนแปลงที่มีอยู่เป็นสิ่งที่ยอมรับได้ และเมื่อใดควรเริ่มใหม่?
อัปเดตการเปลี่ยนแปลงที่มีอยู่เมื่อ:
- เจตนาเดียวกัน การดำเนินการที่ปรับปรุงแล้ว
- ขอบเขตแคบลง (MVP ก่อน ส่วนที่เหลือทีหลัง)
- การแก้ไขที่ขับเคลื่อนด้วยการเรียนรู้ (โค้ดเบสไม่เป็นอย่างที่คาดไว้)
- การปรับแต่งการออกแบบจากการค้นพบในการใช้งาน
เริ่มการเปลี่ยนแปลงใหม่เมื่อ:
- เจตนาเปลี่ยนแปลงอย่างมีนัยสำคัญ
- ขอบเขตขยายไปยังงานที่แตกต่างกันโดยสิ้นเชิง
- การเปลี่ยนแปลงเดิมสามารถทำเครื่องหมาย "เสร็จสิ้น" ได้โดยอิสระ
- การแก้ไขจะทำให้สับสนมากกว่าชี้แจง
text
┌─────────────────────────────────────┐
│ นี่คืองานเดียวกันหรือไม่? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
เจตนาเดียวกัน? ทับซ้อน >50%? ต้นฉบับสามารถ
ปัญหาเดียวกัน? ขอบเขตเดียวกัน? "เสร็จสิ้น" โดยไม่มี
│ │ การเปลี่ยนแปลงเหล่านี้?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
ใช่ ไม่ ใช่ ไม่ ไม่ ใช่
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
อัปเดต ใหม่ อัปเดต ใหม่ อัปเดต ใหม่ตัวอย่าง: "เพิ่มโหมดมืด"
- "ต้องรองรับธีมที่กำหนดเองด้วย" → การเปลี่ยนแปลงใหม่ (ขอบเขตขยาย)
- "การตรวจจับค่าที่ตั้งไว้ในระบบยากกว่าที่คิด" → อัปเดต (เจตนาเดียวกัน)
- "มาเปิดตัวสวิตช์ก่อน เพิ่มการตั้งค่าทีหลัง" → อัปเดตแล้วเก็บรักษา แล้วเริ่มการเปลี่ยนแปลงใหม่
แนวปฏิบัติที่ดี
รักษาการเปลี่ยนแปลงให้มุ่งเน้น
หนึ่งหน่วยงานเชิงตรรกะต่อการเปลี่ยนแปลงหนึ่งรายการ หากคุณกำลังทำ "เพิ่มฟีเจอร์ X และปรับโครงสร้าง Y ด้วย" ให้พิจารณาการเปลี่ยนแปลงสองรายการแยกกัน
ทำไมจึงสำคัญ:
- ตรวจสอบและเข้าใจได้ง่ายกว่า
- ประวัติการเก็บรักษาที่สะอาดกว่า
- สามารถเปิดตัวได้โดยอิสระ
- การย้อนกลับง่ายกว่าหากจำเป็น
ใช้ /opsx:explore สำหรับข้อกำหนดที่ไม่ชัดเจน
ก่อนที่จะมุ่งมั่นกับการเปลี่ยนแปลง ให้สำรวจพื้นที่ปัญหา:
text
You: /opsx:explore
AI: คุณต้องการสำรวจอะไร?
You: เราควรจัดการกับ rate limiting สำหรับ API ของเราอย่างไร?
AI: ให้ฉันตรวจสอบการตั้งค่าปัจจุบันและตัวเลือกของคุณ...
[วิจัยโค้ดเบส พิจารณารูปแบบ]
ฉันเห็นว่ามีสามวิธีที่เราสามารถทำได้:
1. แบบมิดเดิลแวร์ (ง่าย ต่อ endpoint)
2. แบบ Redis (ปรับขนาดได้ สถานะร่วม)
3. แบบ token bucket ต่อผู้ใช้ (ยุติธรรม ซับซ้อน)
สแต็กปัจจุบันของคุณแนะนำวิธีที่ 1 หรือ 2 ขนาดงานของคุณเป็นอย่างไร?การสำรวจช่วยชี้แจงความคิดก่อนที่คุณจะสร้างเอกสารประกอบ
ตรวจสอบก่อนเก็บรักษา
ใช้ /opsx:verify เพื่อตรวจสอบว่าการใช้งานตรงกับเอกสารประกอบ:
text
You: /opsx:verify
AI: กำลังตรวจสอบ add-dark-mode...
✓ งานทั้งหมดใน tasks.md ถูกตรวจสอบแล้ว
✓ ข้อกำหนดใน specs มีโค้ดที่สอดคล้องกัน
✓ การตัดสินใจเชิงการออกแบบสะท้อนอยู่ในการใช้งาน
พร้อมเก็บรักษา!ตรวจจับความไม่ตรงกันก่อนที่คุณจะปิดการเปลี่ยนแปลง
ตั้งชื่อการเปลี่ยนแปลงอย่างชัดเจน
ชื่อที่ดีทำให้ openspec list มีประโยชน์:
```text` ดี: หลีกเลี่ยง: add-dark-mode feature-1 fix-login-redirect update optimize-product-query changes implement-2fa wip
## สรุปคำสั่งอย่างรวดเร็ว
สำหรับรายละเอียดและตัวเลือกของคำสั่งทั้งหมด โปรดดูที่ [คำสั่ง](commands.md)
| คำสั่ง | วัตถุประสงค์ | เมื่อใดควรใช้ |
|---------|---------|-------------|
| `/opsx:propose` | สร้างการเปลี่ยนแปลง + เอกสารประกอบการวางแผน | เส้นทางเริ่มต้นที่รวดเร็ว (โปรไฟล์ `core`) |
| `/opsx:explore` | คิดทบทวนแนวคิด | ข้อกำหนดไม่ชัดเจน, การตรวจสอบ |
| `/opsx:new` | เริ่มต้นโครงร่างการเปลี่ยนแปลง | โหมดขยาย, การควบคุมเอกสารประกอบอย่างชัดเจน |
| `/opsx:continue` | สร้างเอกสารประกอบถัดไป | โหมดขยาย, การสร้างเอกสารประกอบทีละขั้นตอน |
| `/opsx:ff` | สร้างเอกสารประกอบการวางแผนทั้งหมด | โหมดขยาย, ขอบเขตที่ชัดเจน |
| `/opsx:apply` | ดำเนินการตามงาน | พร้อมที่จะเขียนโค้ด |
| `/opsx:verify` | ตรวจสอบการดำเนินการ | โหมดขยาย, ก่อนการจัดเก็บ |
| `/opsx:sync` | ผสานข้อกำหนดแบบ delta | โหมดขยาย, ทางเลือก |
| `/opsx:archive` | เสร็จสิ้นการเปลี่ยนแปลง | งานทั้งหมดเสร็จสมบูรณ์ |
| `/opsx:bulk-archive` | จัดเก็บการเปลี่ยนแปลงหลายรายการ | โหมดขยาย, งานแบบคู่ขนาน |
## ขั้นตอนถัดไป
- [คำสั่ง](commands.md) - คู่มือคำสั่งฉบับเต็มพร้อมตัวเลือก
- [แนวคิด](concepts.md) - เจาะลึกเกี่ยวกับข้อกำหนด เอกสารประกอบ และสคีมา
- [การปรับแต่ง](customization.md) - สร้างเวิร์กโฟลว์แบบกำหนดเอง