ไดอะแกรมที่แมปกับโค้ด
Eraser และ Whimsical สร้างกล่องสวย ๆ ได้ แต่สุดท้ายวิศวกรของคุณก็ยังสร้างอะไรก็ตามที่ทันเดดไลน์ ไดอะแกรมของ Bob กลายเป็นโครงสร้างไฟล์และขอบเขตของโมดูลที่ Alex ใช้จริงใน codebase
Bob·Architectเอเจนต์สถาปนิก AI ที่ออกแบบระบบให้ทีมของคุณสร้าง
Bob วาดระบบ เลือกสแตก และส่งมอบโครงสร้างให้ Alex เพื่อให้สถาปัตยกรรมของคุณกลายเป็นโค้ดเบส ไม่ใช่เอกสารที่ถูกลืม
แผนภาพที่สอดคล้องกับโค้ด ไม่ใช่แค่ภาพสวยๆ
เหตุใดเอกสารสถาปัตยกรรมจึงล้าสมัยตั้งแต่วันที่เขียน
ไดอะแกรมสวยแต่ไม่มีใครนำไปใช้จริง
Eraser และ Whimsical สร้างกล่องและลูกศรที่สวยงาม แต่วิศวกรของคุณก็ยังสร้างอะไรก็ตามที่พอจะทันเดดไลน์อยู่ดี ไดอะแกรมของ Bob กลายเป็นโครงสร้างไฟล์และขอบเขตของโมดูลที่ Alex ใช้งานจริง
เลือกสแตกตามกระแส
"เราเลือก Mongo เพราะมันกำลังนิยม" Bob อธิบายว่าทำไมถึงเลือก Postgres แทน Mongo ทำไมถึงใช้ queue แทน direct calls และทำไม Redis vs Memcached เหตุผลทั้งหมดถูกเขียนไว้เป็นลายลักษณ์อักษร เพื่อให้คุณสามารถตั้งคำถามกับมันได้
สถาปัตยกรรมกับโค้ดค่อยๆ แยกจากกัน
ไดอะแกรมในวิกิเป็นของ sprint 1 แต่โค้ดเป็นของ sprint 14 ไม่มีใครอัปเดตอย่างใดอย่างหนึ่งให้ตรงกัน Bob ตรวจทานระบบปัจจุบันและอัปเดตเอกสารสถาปัตยกรรมให้สะท้อนสิ่งที่ถูกส่งมอบจริง
ความต้องการที่ไม่ใช่เชิงฟังก์ชันถูกพบหลังเปิดใช้งาน
Performance, security และ observability ถูกนำมาเสริมทีหลังหลังจาก outage แรก Bob วางแผนสิ่งเหล่านี้ตั้งแต่ขั้นออกแบบ โดยอิงตามข้อกำหนดด้านการขยายระบบของ Emma และรูปแบบการเข้าถึงที่ data model ของคุณต้องรองรับ
หนึ่งวันกับ Bob
ตั้งแต่พรอมป์แรกของคุณไปจนถึงผลลัพธ์ที่พร้อมใช้งาน นี่คือวิธีที่ Bob ทำงานจริง
- 01
อ่าน PRD ของ Emma
Bob เริ่มจากขอบเขตที่จำกัด เพื่อให้สถาปัตยกรรมสอดคล้องกับผลิตภัณฑ์ ไม่ใช่กลับกัน
ส่งต่อให้ Emma - 02
เลือกสแตกพร้อมเหตุผลประกอบ
ฐานข้อมูล เฟรมเวิร์ก คิว แคช ทุกตัวเลือกมาพร้อมคำอธิบายเชิงเปรียบเทียบข้อดีข้อเสียเป็นลายลักษณ์อักษรที่คุณสามารถโต้แย้งได้
- 03
แมปโมเดลข้อมูลและขอบเขตของโมดูล
เอนทิตี ความสัมพันธ์ ความเป็นเจ้าของ เส้นทางการเขียนข้อมูล สิ่งที่เจ็บปวดเมื่อต้องมารีแฟกเตอร์ทีหลัง
- 04
วาดไดอะแกรมระบบที่แมปไปยังโค้ด
กล่องและลูกศรสะท้อนโมดูลและการพึ่งพาจริง แผนภาพจึงยังคงซิงก์กับโค้ดเมื่อมีการพัฒนาเพิ่ม
- 05
ส่งโครงสร้างให้ Alex
Alex พัฒนาภายในขอบเขตที่ Bob วางไว้ โดยไม่ฝังหนี้เทคนิคแบบ "อีกสามเดือนค่อยรีแฟกเตอร์" ไว้ตั้งแต่ต้น
ส่งต่อให้ Alex
ทุกสิ่งที่ Bob ต้องการเพื่อออกแบบระบบที่มั่นคง
แผนภาพสถาปัตยกรรม
แผนภาพบริการ การไหลของข้อมูล และการผสานรวมที่สร้างใน Editor ไม่ใช่ในเครื่องมือแยกต่างหาก
คำแนะนำด้านเทคโนโลยีสแตก
ตัวเลือกสแตกที่มีเหตุผลรองรับตามข้อจำกัดของคุณ ไม่ได้เลือกตามกระแสหรือความคุ้นเคย
การออกแบบโมเดลข้อมูล
สคีมาและความสัมพันธ์ที่ออกแบบตามรูปแบบการเข้าถึงจริงของผลิตภัณฑ์ของคุณ
การวางแผนด้านที่ไม่ใช่ฟังก์ชัน
ประสิทธิภาพ ความปลอดภัย และการสังเกตการณ์ถูกนำมาพิจารณาตั้งแต่ขั้นตอนการออกแบบ ไม่ใช่หลังเปิดใช้งาน
บันทึกการตัดสินใจ
การตัดสินใจด้านสถาปัตยกรรมถูกบันทึกเป็นลายลักษณ์อักษรพร้อมเหตุผล เพื่อให้ตัวคุณในอนาคตสามารถย้อนกลับมาทบทวนได้
การแมประหว่างโครงสร้างกับโค้ด
แผนภาพเชื่อมโยงกับโครงสร้างไฟล์และขอบเขตของโมดูลที่ Alex ใช้สร้าง
การทบทวนสถาปัตยกรรม
Bob สามารถทบทวนระบบที่มีอยู่และแนะนำการเปลี่ยนแปลงพร้อมเหตุผลที่ชัดเจน
อะไรจะเปลี่ยนไปเมื่อ Bob อยู่ในทีมของคุณ
เวิร์กโฟลว์ที่ทำขึ้นเองแบบแมนนวลนั้นช้า ต้องทำด้วยมือ และพึ่งพาเครื่องมือจำนวนมาก วางเมาส์เหนือการ์ดใดก็ได้ เพื่อดูว่าทำไมแต่ละประโยชน์ถึงสำคัญ
ทำไมผู้สร้างถึงเลือก Bob แทนตัวเลือกอื่น?
เปรียบเทียบกับ
ย้ายมาจาก Eraser AI ใช่ไหม? นี่คือจุดที่ Bob เหนือกว่า
เลือกสแตกด้วยเหตุผล ไม่ใช่กระแส
ChatGPT มักแนะนำเฟรมเวิร์กที่พบเห็นบ่อยที่สุดในข้อมูลฝึกสอน แต่ Bob จะอธิบายว่าทำไมจึงเลือก Postgres แทน Mongo ทำไมถึงใช้ queue แทน direct calls ทำไมจึงเลือก Redis แทน Memcached พร้อมเหตุผลที่คุณโต้แย้งได้ และการตัดสินใจที่คุณนำกลับมาทบทวนได้
สถาปัตยกรรมที่คงความทันสมัยอยู่เสมอ
ไดอะแกรมในวิกิจะล้าสมัยภายในสปรินต์ที่ 3 Bob ตรวจสอบโค้ดจริงและอัปเดตสถาปัตยกรรมให้ตรงกับสิ่งที่ส่งมอบไปแล้ว ดังนั้นเอกสารจึงไม่เคยเป็นเรื่องแต่ง และการเริ่มงานของวิศวกรใหม่ใช้เวลาเพียงวันเดียว ไม่ใช่หนึ่งเดือน
Atoms เทียบกับ Eraser AI: เปรียบเทียบฟีเจอร์ ราคา และความสามารถ
| ฟีเจอร์ | Atoms แนะนำ | Eraser AI |
|---|---|---|
| ผลลัพธ์ | สถาปัตยกรรมที่เชื่อมโยงไปสู่โค้ดได้ | ไดอะแกรมในวิกิ |
| การเลือกสแตกอย่างมีเหตุผล | ข้อแลกเปลี่ยนที่เขียนไว้ชัดเจน | คำแนะนำทั่วไป |
| ยังคงซิงค์กันเมื่อโค้ดถูกส่งมอบ | รีเฟรชตามโค้ดเบสแล้ว | ล้าสมัยภายในสปรินต์ที่ 3 |
| เชื่อมต่อกับทีมวิศวกรรม | ส่งต่อให้ Alex | ส่งต่อผ่านการส่งออก |
| การสร้างไดอะแกรม | สร้างอัตโนมัติ | สร้างอัตโนมัติ |
Bob ทำงานร่วมกับทีม AI ที่เหลือของคุณอย่างไร?
Bob ไม่ได้ทำงานเพียงลำพัง นี่คือวิธีที่การส่งต่องานเกิดขึ้น เมื่อคุณสร้างร่วมกับทีมเต็มรูปแบบ
BobAlex
Bob ออกแบบระบบ ส่วน Alex ลงมือสร้าง โดยไม่ฝังหนี้เทคนิคแบบ "ค่อยรีแฟกเตอร์อีก 6 เดือน เมื่อระบบเริ่มสเกล" ไว้ตั้งแต่ต้น
ดูว่าเป็นอย่างไร? Alex ใช้งานได้BobEmma
Bob ปรับสถาปัตยกรรมให้สอดคล้องกับขอบเขตผลิตภัณฑ์ของ Emma ไม่มีระบบที่ออกแบบเกินความจำเป็นสำหรับฟีเจอร์ง่าย ๆ
ดูว่าเป็นอย่างไร? Emma ใช้งานได้BobDavid
Bob ออกแบบโมเดลข้อมูล เพื่อให้ David สืบค้นได้อย่างเป็นระเบียบ Analytics เป็นองค์ประกอบหลัก ไม่ใช่สิ่งที่มาเสริมทีหลัง
ดูว่าเป็นอย่างไร? David ใช้งานได้สิ่งที่ Bob ออกแบบสำหรับผู้สร้าง
งานสถาปัตยกรรมคอนกรีตที่ Bob สร้างขึ้นซึ่งเชื่อมโยงกับโค้ดจริง
- ออกแบบระบบ
การออกแบบระบบ Greenfield
ออกแบบระบบตั้งแต่เริ่มต้นพร้อมให้เหตุผลในการเลือกสแต็กตามข้อจำกัดของคุณ
- เลือกสแต็ก
การเลือกสแต็ก
เปรียบเทียบตัวเลือกสแต็กสำหรับโปรเจกต์ของคุณและเลือกสิ่งที่เหมาะกับทีมและขนาดการใช้งานของคุณ
- ออกแบบสคีมา
การออกแบบโมเดลข้อมูล
ออกแบบสคีมา ความสัมพันธ์ และดัชนีให้เหมาะกับคิวรีที่ผลิตภัณฑ์ของคุณจะใช้งานจริง
- แมปการผสานรวม
การแมปการผสานรวม
วางแผนบริการจากภายนอก เว็บฮุก และการไหลของข้อมูลก่อนเริ่มงานผสานรวม
- วางแผนรองรับการขยาย
แผนประสิทธิภาพและการขยายระบบ
ระบุคอขวดและวางแผนสำหรับการเติบโตในระดับถัดไปก่อนที่จะกระทบกับระบบ production
- ทบทวนความปลอดภัย
การทบทวนด้านความปลอดภัยและการปฏิบัติตามข้อกำหนด
ระบุประเด็นด้านการยืนยันตัวตน ข้อมูล และความเป็นส่วนตัว และจัดการตั้งแต่ขั้นออกแบบแทนที่จะรอหลังเปิดใช้งาน
ลองใช้พรอมต์เหล่านี้กับ Bob
ออกแบบระบบตั้งแต่ต้น
@Bob ออกแบบสถาปัตยกรรมสำหรับ SaaS แบบหลายผู้เช่าที่มีการคิดค่าบริการตามการใช้งาน รองรับผู้เช่าที่คาดไว้ 10k ราย และการจ่ายเงินผ่าน Stripe Connect เลือกสแตก วาดไดอะแกรมบริการ และส่งมอบโครงสร้างไฟล์ให้ Alex
เลือกสแตกพร้อมเหตุผลประกอบ
@Bob เรากำลังเลือกระหว่าง Postgres + Prisma และ PlanetScale + Drizzle สำหรับผลิตภัณฑ์ใหม่ เปรียบเทียบทั้งสองตัวตามข้อจำกัดของเรา (การอ่านหลายภูมิภาค, วิศวกรคนเดียว, 100ms p95) และแนะนำหนึ่งตัวพร้อมระบุข้อแลกเปลี่ยนอย่างชัดเจน
ทบทวนสถาปัตยกรรมที่มีอยู่
@Bob ตรวจสอบเลเยอร์ API ปัจจุบันของเรา ขณะนี้เราเห็นค่า p95 ที่ 800ms บน dashboard endpoint และต้องการขยายให้รองรับทราฟฟิกเพิ่มขึ้น 10 เท่า ระบุคอขวด เสนอการเปลี่ยนแปลง และเขียนแผนการย้ายระบบให้ Alex
ออกแบบโมเดลข้อมูลสำหรับฟีเจอร์
@Bob ออกแบบสคีมาสำหรับโปรแกรมแนะนำต่อใน PRD ของ Emma จัดทำแมปเอนทิตี ความสัมพันธ์ และดัชนีสำหรับคิวรีที่เราจะใช้งานจริง ส่งมอบสคีมาและแผน migration ให้ Alex
พบกับทีม AI ที่เหลือของ Bob
ไม่มีเอเจนต์คนใดทำงานลำพัง แตะเพื่อนร่วมทีมคนใดก็ได้เพื่อดูว่าพวกเขาจัดการส่วนของผลิตภัณฑ์คุณอย่างไร
ได้รับความไว้วางใจจากลูกค้าจาก
คำถามที่พบบ่อย
ให้บ๊อบลงมือทำงาน
เลิกวาดไดอะแกรมที่ไม่มีใครนำไปใช้จริง ให้ Bob ออกแบบระบบที่ทีม AI ของคุณสามารถสร้างและซิงก์ให้ตรงกันภายใน Atoms ได้
