speccrew 0.7.44 → 0.7.46
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.speccrew/agents/speccrew-team-leader.md +6 -6
- package/README.ar.md +5 -17
- package/README.de.md +5 -17
- package/README.en.md +5 -17
- package/README.es.md +5 -17
- package/README.fr.md +5 -17
- package/README.hi.md +384 -0
- package/README.ja.md +5 -17
- package/README.md +5 -17
- package/README.pt-BR.md +5 -17
- package/README.ru.md +5 -17
- package/docs/GETTING-STARTED.ar.md +39 -40
- package/docs/GETTING-STARTED.de.md +39 -40
- package/docs/GETTING-STARTED.en.md +39 -40
- package/docs/GETTING-STARTED.es.md +39 -40
- package/docs/GETTING-STARTED.fr.md +39 -40
- package/docs/GETTING-STARTED.hi.md +636 -0
- package/docs/GETTING-STARTED.ja.md +39 -40
- package/docs/GETTING-STARTED.md +39 -40
- package/docs/GETTING-STARTED.pt-BR.md +25 -26
- package/docs/GETTING-STARTED.ru.md +37 -38
- package/lib/commands/init.js +3 -3
- package/package.json +1 -1
- package/workspace-template/scripts/update-progress.js +5 -1
- package/README.bn.md +0 -174
- package/README.bs.md +0 -394
- package/README.da.md +0 -394
- package/README.el.md +0 -174
- package/README.it.md +0 -394
- package/README.ko.md +0 -394
- package/README.no.md +0 -394
- package/README.pl.md +0 -394
- package/README.th.md +0 -311
- package/README.tr.md +0 -306
- package/README.uk.md +0 -306
- package/README.vi.md +0 -174
- package/README.zh-TW.md +0 -394
- package/docs/GETTING-STARTED.bn.md +0 -219
- package/docs/GETTING-STARTED.bs.md +0 -219
- package/docs/GETTING-STARTED.da.md +0 -637
- package/docs/GETTING-STARTED.el.md +0 -633
- package/docs/GETTING-STARTED.it.md +0 -639
- package/docs/GETTING-STARTED.ko.md +0 -639
- package/docs/GETTING-STARTED.no.md +0 -563
- package/docs/GETTING-STARTED.pl.md +0 -597
- package/docs/GETTING-STARTED.th.md +0 -219
- package/docs/GETTING-STARTED.tr.md +0 -597
- package/docs/GETTING-STARTED.uk.md +0 -597
- package/docs/GETTING-STARTED.vi.md +0 -217
- package/docs/GETTING-STARTED.zh-TW.md +0 -639
package/README.uk.md
DELETED
|
@@ -1,306 +0,0 @@
|
|
|
1
|
-
# SpecCrew - AI-орієнтований фреймворк програмної інженерії
|
|
2
|
-
|
|
3
|
-
<p align="center">
|
|
4
|
-
<a href="./README.md">简体中文</a> |
|
|
5
|
-
<a href="./README.zh-TW.md">繁體中文</a> |
|
|
6
|
-
<a href="./README.en.md">English</a> |
|
|
7
|
-
<a href="./README.ko.md">한국어</a> |
|
|
8
|
-
<a href="./README.de.md">Deutsch</a> |
|
|
9
|
-
<a href="./README.es.md">Español</a> |
|
|
10
|
-
<a href="./README.fr.md">Français</a> |
|
|
11
|
-
<a href="./README.it.md">Italiano</a> |
|
|
12
|
-
<a href="./README.da.md">Dansk</a> |
|
|
13
|
-
<a href="./README.ja.md">日本語</a> |
|
|
14
|
-
<a href="./README.pl.md">Polski</a> |
|
|
15
|
-
<a href="./README.ru.md">Русский</a> |
|
|
16
|
-
<a href="./README.bs.md">Bosanski</a> |
|
|
17
|
-
<a href="./README.ar.md">العربية</a> |
|
|
18
|
-
<a href="./README.no.md">Norsk</a> |
|
|
19
|
-
<a href="./README.pt-BR.md">Português (Brasil)</a> |
|
|
20
|
-
<a href="./README.th.md">ไทย</a> |
|
|
21
|
-
<a href="./README.tr.md">Türkçe</a> |
|
|
22
|
-
<a href="./README.uk.md">Українська</a> |
|
|
23
|
-
<a href="./README.bn.md">বাংলা</a> |
|
|
24
|
-
<a href="./README.el.md">Ελληνικά</a> |
|
|
25
|
-
<a href="./README.vi.md">Tiếng Việt</a>
|
|
26
|
-
</p>
|
|
27
|
-
|
|
28
|
-
<p align="center">
|
|
29
|
-
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/v/speccrew.svg" alt="npm version"></a>
|
|
30
|
-
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/dm/speccrew.svg" alt="npm downloads"></a>
|
|
31
|
-
<a href="https://github.com/charlesmu99/speccrew/blob/main/LICENSE"><img src="https://img.shields.io/npm/l/speccrew.svg" alt="license"></a>
|
|
32
|
-
</p>
|
|
33
|
-
|
|
34
|
-
> Віртуальна команда розробки на базі ШІ, що забезпечує швидку інженерну реалізацію для будь-якого програмного проекту
|
|
35
|
-
|
|
36
|
-
## Що таке SpecCrew?
|
|
37
|
-
|
|
38
|
-
SpecCrew — це вбудований фреймворк віртуальної команди розробки на базі ШІ. Він перетворює професійні робочі процеси програмної інженерії (PRD → Feature Design → System Design → Dev → Test) у багаторазові робочі процеси Агентів, допомагаючи командам розробників досягти Specification-Driven Development (SDD), особливо підходить для існуючих проектів.
|
|
39
|
-
|
|
40
|
-
Інтегруючи Агентів та Навички в існуючі проекти, команди можуть швидко ініціалізувати системи документації проекту та віртуальні програмні команди, реалізуючи нові функції та модифікації відповідно до стандартних інженерних робочих процесів.
|
|
41
|
-
|
|
42
|
-
---
|
|
43
|
-
|
|
44
|
-
## ✨ Ключові особливості
|
|
45
|
-
|
|
46
|
-
### 🏭 Віртуальна команда розробки
|
|
47
|
-
Генерація одним кліком **7 професійних ролей Агентів** + **30+ робочих процесів Навичок**, створення повної віртуальної команди розробки:
|
|
48
|
-
- **Team Leader** - Глобальне планування та управління ітераціями
|
|
49
|
-
- **Product Manager** - Аналіз вимог та генерація PRD
|
|
50
|
-
- **Feature Designer** - Проектування функцій + API-контракти
|
|
51
|
-
- **System Designer** - Проектування систем Frontend/Backend/Mobile/Desktop
|
|
52
|
-
- **System Developer** - Багатоплатформна паралельна розробка
|
|
53
|
-
- **Test Manager** - Координація тестування в три етапи
|
|
54
|
-
- **Task Worker** - Паралельне виконання підзадач
|
|
55
|
-
|
|
56
|
-
### 📐 Моделювання ISA-95 в шість етапів
|
|
57
|
-
Базовано на міжнародній методології моделювання **ISA-95**, стандартизація перетворення бізнес-вимог в програмні системи:
|
|
58
|
-
```
|
|
59
|
-
Domain Descriptions → Functions in Domains → Functions of Interest
|
|
60
|
-
↓ ↓ ↓
|
|
61
|
-
Information Flows → Categories of Information → Information Descriptions
|
|
62
|
-
```
|
|
63
|
-
- Кожен етап відповідає певним UML-діаграмам (use case, sequence, class diagrams)
|
|
64
|
-
- Бізнес-вимоги "уточнюються поетапно", без втрати інформації
|
|
65
|
-
- Результати безпосередньо придатні для розробки
|
|
66
|
-
|
|
67
|
-
### 📚 Система бази знань
|
|
68
|
-
Трирівнева архітектура бази знань, що гарантує, що ШІ завжди працює на основі "єдиного джерела істини":
|
|
69
|
-
|
|
70
|
-
| Рівень | Каталог | Вміст | Призначення |
|
|
71
|
-
|--------|---------|-------|-------------|
|
|
72
|
-
| L1 Системні знання | `knowledge/techs/` | Технологічний стек, архітектура, угоди | ШІ розуміє технічні межі проекту |
|
|
73
|
-
| L2 Бізнес-знання | `knowledge/bizs/` | Функції модулів, бізнес-процеси, сутності | ШІ розуміє бізнес-логіку |
|
|
74
|
-
| L3 Артефакти ітерацій | `iterations/iXXX/` | PRD, проектні документи, звіти про тестування | Повний ланцюжок відстеження для поточних вимог |
|
|
75
|
-
|
|
76
|
-
### 🔄 Чотириетапний конвеєр знань
|
|
77
|
-
**Автоматизована архітектура генерації знань**, автоматична генерація бізнес/технічної документації з вихідного коду:
|
|
78
|
-
```
|
|
79
|
-
Етап 1: Сканування вихідного коду → Генерація списку модулів
|
|
80
|
-
Етап 2: Паралельний аналіз → Вилучення функцій (багато Worker паралельно)
|
|
81
|
-
Етап 3: Паралельне узагальнення → Завершення оглядів модулів (багато Worker паралельно)
|
|
82
|
-
Етап 4: Системна агрегація → Генерація панорами системи
|
|
83
|
-
```
|
|
84
|
-
- Підтримує **повну синхронізацію** та **інкрементальну синхронізацію** (на основі Git diff)
|
|
85
|
-
- Один оптимізує, команда використовує
|
|
86
|
-
|
|
87
|
-
### 🔧 Harness Практична структура впровадження
|
|
88
|
-
**Стандартизована структура виконання**, що забезпечує точне перетворення проектних документів у виконувані інструкції з розробки:
|
|
89
|
-
- **Принцип операційного посібника**: Навичка — це SOP, кроки чіткі, послідовні та самодостатні
|
|
90
|
-
- **Контракт введення-виведення**: Чітке визначення інтерфейсів, суворе виконання як pseudocode
|
|
91
|
-
- **Архітектура прогресивного розкриття**: Шаруватезавантаження інформації, уникнення одноразового перевантаження контексту
|
|
92
|
-
- **Делегування суб-Агентів**: Автоматичний поділ складних завдань, паралельне виконання гарантує якість
|
|
93
|
-
|
|
94
|
-
---
|
|
95
|
-
|
|
96
|
-
## Вирішення 8 ключових проблем
|
|
97
|
-
|
|
98
|
-
### 1. ШІ ігнорує існуючу документацію проекту (розрив знань)
|
|
99
|
-
**Проблема**: Існуючі методи SDD або Vibe Coding покладаються на те, що ШІ резюмує проекти в реальному часі, легко пропускаючи критичний контекст і призводячи до результатів розробки, що відхиляються від очікувань.
|
|
100
|
-
|
|
101
|
-
**Рішення**: Репозиторій `knowledge/` служить "єдиним джерелом істини" проекту, накопичуючи архітектурний дизайн, функціональні модулі та бізнес-процеси, забезпечуючи відповідність вимог джерелу.
|
|
102
|
-
|
|
103
|
-
### 2. Пряма технічна документація з PRD (пропуск змісту)
|
|
104
|
-
**Проблема**: Прямий перехід від PRD до детального проектування легко пропускає деталі вимог, призводячи до того, що реалізовані функції відхиляються від вимог.
|
|
105
|
-
|
|
106
|
-
**Рішення**: Впровадження фази **Документа Feature Design**, що фокусується лише на скелеті вимог без технічних деталей:
|
|
107
|
-
- Які сторінки та компоненти включені?
|
|
108
|
-
- Потоки операцій сторінок
|
|
109
|
-
- Логіка обробки бекенду
|
|
110
|
-
- Структура зберігання даних
|
|
111
|
-
|
|
112
|
-
Розробка повинна лише "наростити м'ясо" на основі конкретного технічного стеку, забезпечуючи зростання функцій "близько до кісток (вимог)".
|
|
113
|
-
|
|
114
|
-
### 3. Невизначена область пошуку Агента (невизначеність)
|
|
115
|
-
**Проблема**: У складних проектах широкий пошук коду та документів ШІ дає невизначені результати, що ускладнює гарантування узгодженості.
|
|
116
|
-
|
|
117
|
-
**Рішення**: Чіткі структури каталогів документів та шаблони, розроблені на основі потреб кожного Агента, реалізують **прогресивне розкриття та завантаження за запитом** для забезпечення детермінізму.
|
|
118
|
-
|
|
119
|
-
### 4. Пропущені етапи та завдання (розрив процесу)
|
|
120
|
-
**Проблема**: Відсутність повного охоплення інженерного процесу легко пропускає критичні кроки, що ускладнює гарантування якості.
|
|
121
|
-
|
|
122
|
-
**Рішення**: Охоплення повного життєвого циклу програмної інженерії:
|
|
123
|
-
```
|
|
124
|
-
PRD (Вимоги) → Feature Design (Проектування функцій) → API Contract (Контракт)
|
|
125
|
-
→ System Design (Системне проектування) → Dev (Розробка) → Test (Тестування)
|
|
126
|
-
```
|
|
127
|
-
- Вихід кожної фази є входом наступної фази
|
|
128
|
-
- Кожен крок потребує людського підтвердження перед продовженням
|
|
129
|
-
- Всі виконання Агентів мають списки todo з самоперевіркою після завершення
|
|
130
|
-
|
|
131
|
-
### 5. Низька ефективність командної співпраці (інформаційні силоси)
|
|
132
|
-
**Проблема**: Досвід програмування з ШІ важко розділяти між командами, що призводить до повторних помилок.
|
|
133
|
-
|
|
134
|
-
**Рішення**: Всі Агенти, Навички та пов'язані документи версіонуються з вихідним кодом:
|
|
135
|
-
- Оптимізація однієї людини розділяється командою
|
|
136
|
-
- Знання накопичуються в кодовій базі
|
|
137
|
-
- Підвищується ефективність командної співпраці
|
|
138
|
-
|
|
139
|
-
### 7. Занадто довгий контекст одного Агента (вузьке місце продуктивності)
|
|
140
|
-
**Проблема**: Великі складні завдання перевищують контекстні вікна одного Агента, викликаючи відхилення в розумінні та зниження якості виходу.
|
|
141
|
-
|
|
142
|
-
**Рішення**: **Механізм автодиспетчеризації суб-Агентів**:
|
|
143
|
-
- Складні завдання автоматично ідентифікуються та розділяються на підзавдання
|
|
144
|
-
- Кожне підзавдання виконується незалежним суб-Агентом з ізольованим контекстом
|
|
145
|
-
- Батьківський Агент координує та агрегує для забезпечення загальної узгодженості
|
|
146
|
-
- Уникає розширення контексту одного Агента, забезпечуючи якість виходу
|
|
147
|
-
|
|
148
|
-
### 8. Хаос ітерації вимог (труднощі управління)
|
|
149
|
-
**Проблема**: Кілька вимог, змішаних в одній гілці, впливають одна на одну, що ускладнює відстеження та відкат.
|
|
150
|
-
|
|
151
|
-
**Рішення**: **Кожна вимога як незалежний проект**:
|
|
152
|
-
- Кожна вимога створює незалежний каталог ітерації `iterations/iXXX-[ім'я-вимоги]/`
|
|
153
|
-
- Повна ізоляція: документи, дизайн, код та тести керуються незалежно
|
|
154
|
-
- Швидка ітерація: доставка малої гранулярності, швидка верифікація, швидке розгортання
|
|
155
|
-
- Гнучке архівування: після завершення, архівування в `archive/` з чіткою історичною відстежуваністю
|
|
156
|
-
|
|
157
|
-
### 6. Затримка оновлення документів (старіння знань)
|
|
158
|
-
**Проблема**: Документи застарівають по мірі розвитку проектів, змушуючи ШІ працювати з невірною інформацією.
|
|
159
|
-
|
|
160
|
-
**Рішення**: Агенти мають можливості автоматичного оновлення документів, синхронізуючи зміни проекту в реальному часі для підтримки точності бази знань.
|
|
161
|
-
|
|
162
|
-
---
|
|
163
|
-
|
|
164
|
-
## Основний робочий процес
|
|
165
|
-
|
|
166
|
-
```mermaid
|
|
167
|
-
graph LR
|
|
168
|
-
A[PRD<br/>Документ вимог] --> B[Feature Design<br/>Проектування функцій]
|
|
169
|
-
B --> C[API Contract<br/>Контракт інтерфейсу]
|
|
170
|
-
C --> D[System Design<br/>Системне проектування]
|
|
171
|
-
D --> E[Dev<br/>Реалізація]
|
|
172
|
-
E --> F[System Test<br/>Тестування]
|
|
173
|
-
F --> G[Archive<br/>Архівування]
|
|
174
|
-
|
|
175
|
-
H[Knowledge<br/>Репозиторій] -.-> A
|
|
176
|
-
H -.-> B
|
|
177
|
-
H -.-> D
|
|
178
|
-
H -.-> E
|
|
179
|
-
|
|
180
|
-
E -.-> H
|
|
181
|
-
F -.-> H
|
|
182
|
-
```
|
|
183
|
-
|
|
184
|
-
### Опис фаз
|
|
185
|
-
|
|
186
|
-
| Фаза | Агент | Вхід | Вихід | Людське підтвердження |
|
|
187
|
-
|------|-------|------|-------|----------------------|
|
|
188
|
-
| PRD | PM | Користувацькі вимоги | Документ вимог продукту | ✅ Обов'язково |
|
|
189
|
-
| Feature Design | Feature Designer | PRD | Документ Feature Design + API контракт | ✅ Обов'язково |
|
|
190
|
-
| System Design | System Designer | Feature Spec | Документи проектування Frontend/Backend | ✅ Обов'язково |
|
|
191
|
-
| Dev | Dev | Design | Код + Записи завдань | ✅ Обов'язково |
|
|
192
|
-
| System Test | Test Manager | Вихід Dev + Feature Spec | Тест-кейси + Тестовий код + Тестовий звіт + Звіт багів | ✅ Обов'язково |
|
|
193
|
-
|
|
194
|
-
---
|
|
195
|
-
|
|
196
|
-
## Порівняння з існуючими рішеннями
|
|
197
|
-
|
|
198
|
-
| Вимір | Vibe Coding | Ralph Loop | **SpecCrew** |
|
|
199
|
-
|-------|-------------|------------|-------------|
|
|
200
|
-
| Залежність від документів | Ігнорує існуючі документи | Покладається на AGENTS.md | **Структурована база знань** |
|
|
201
|
-
| Передача вимог | Пряме кодування | PRD → Код | **PRD → Feature Design → System Design → Код** |
|
|
202
|
-
| Людська участь | Мінімальна | При запуску | **На кожній фазі** |
|
|
203
|
-
| Повнота процесу | Слабка | Середня | **Повний інженерний робочий процес** |
|
|
204
|
-
| Командна співпраця | Важко ділитися | Особиста ефективність | **Розділення знань команди** |
|
|
205
|
-
| Управління контекстом | Один екземпляр | Цикл одного екземпляра | **Автодиспетчеризація суб-Агентів** |
|
|
206
|
-
| Управління ітерацією | Змішане | Список завдань | **Вимога як проект, незалежна ітерація** |
|
|
207
|
-
| Детермінізм | Низький | Середній | **Високий (прогресивне розкриття)** |
|
|
208
|
-
|
|
209
|
-
---
|
|
210
|
-
|
|
211
|
-
## Швидкий старт
|
|
212
|
-
|
|
213
|
-
### Передумови
|
|
214
|
-
|
|
215
|
-
- Node.js >= 16.0.0
|
|
216
|
-
- Підтримувані IDE: Qoder (за замовчуванням), Cursor, Claude Code
|
|
217
|
-
|
|
218
|
-
> **Примітка**: Адаптери для Cursor та Claude Code не тестувалися в реальних середовищах IDE (реалізовані на рівні коду та верифіковані через E2E тести, але ще не протестовані в реальних Cursor/Claude Code).
|
|
219
|
-
|
|
220
|
-
### 1. Встановити SpecCrew
|
|
221
|
-
|
|
222
|
-
```bash
|
|
223
|
-
npm install -g speccrew
|
|
224
|
-
```
|
|
225
|
-
|
|
226
|
-
### 2. Ініціалізувати проект
|
|
227
|
-
|
|
228
|
-
Перейдіть до кореневого каталогу проекту та виконайте команду ініціалізації:
|
|
229
|
-
|
|
230
|
-
```bash
|
|
231
|
-
cd /path/to/your-project
|
|
232
|
-
|
|
233
|
-
# За замовчуванням використовує Qoder
|
|
234
|
-
speccrew init
|
|
235
|
-
|
|
236
|
-
# Або вкажіть IDE
|
|
237
|
-
speccrew init --ide qoder
|
|
238
|
-
speccrew init --ide cursor
|
|
239
|
-
speccrew init --ide claude
|
|
240
|
-
```
|
|
241
|
-
|
|
242
|
-
Після ініціалізації в проекті будуть створені:
|
|
243
|
-
- `.qoder/agents/` / `.cursor/agents/` / `.claude/agents/` — 7 визначень ролей Агентів
|
|
244
|
-
- `.qoder/skills/` / `.cursor/skills/` / `.claude/skills/` — 30+ робочих процесів Навичок
|
|
245
|
-
- `speccrew-workspace/` — Робочий простір (каталоги ітерацій, база знань, шаблони документів)
|
|
246
|
-
- `.speccrewrc` — Файл конфігурації SpecCrew
|
|
247
|
-
|
|
248
|
-
Щоб пізніше оновити Агентів та Навички для конкретного IDE:
|
|
249
|
-
|
|
250
|
-
```bash
|
|
251
|
-
speccrew update --ide cursor
|
|
252
|
-
speccrew update --ide claude
|
|
253
|
-
```
|
|
254
|
-
|
|
255
|
-
### 3. Почати робочий процес розробки
|
|
256
|
-
|
|
257
|
-
Дотримуйтесь стандартного інженерного робочого процесу крок за кроком:
|
|
258
|
-
|
|
259
|
-
1. **PRD**: Агент Product Manager аналізує вимоги та генерує документ вимог продукту
|
|
260
|
-
2. **Feature Design**: Агент Feature Designer генерує документ feature design + API контракт
|
|
261
|
-
3. **System Design**: Агент System Designer генерує документи system design за платформами (frontend/backend/mobile/desktop)
|
|
262
|
-
4. **Dev**: Агент System Developer реалізує розробку за платформами паралельно
|
|
263
|
-
5. **System Test**: Агент Test Manager координує трифазне тестування (дизайн кейсів → генерація коду → звіт виконання)
|
|
264
|
-
6. **Archive**: Архівувати ітерацію
|
|
265
|
-
|
|
266
|
-
> Результати кожної фази потребують людського підтвердження перед переходом до наступної фази.
|
|
267
|
-
|
|
268
|
-
### 4. Оновити SpecCrew
|
|
269
|
-
|
|
270
|
-
Коли виходить нова версія SpecCrew, виконайте оновлення у два кроки:
|
|
271
|
-
|
|
272
|
-
```bash
|
|
273
|
-
# Step 1: Update the global CLI tool to the latest version
|
|
274
|
-
npm install -g speccrew@latest
|
|
275
|
-
|
|
276
|
-
# Step 2: Sync Agents and Skills in your project to the latest version
|
|
277
|
-
cd /path/to/your-project
|
|
278
|
-
speccrew update
|
|
279
|
-
```
|
|
280
|
-
|
|
281
|
-
> **Примітка**: `npm install -g speccrew@latest` оновлює сам інструмент CLI, а `speccrew update` оновлює файли визначень Агентів та Навичок у вашому проекті. Для повного оновлення необхідні обидва кроки.
|
|
282
|
-
|
|
283
|
-
### 5. Інші CLI команди
|
|
284
|
-
|
|
285
|
-
```bash
|
|
286
|
-
speccrew list # Список встановлених агентів та навичок
|
|
287
|
-
speccrew doctor # Діагностика середовища та статусу встановлення
|
|
288
|
-
speccrew update # Оновлення агентів та навичок до останньої версії
|
|
289
|
-
speccrew uninstall # Видалити SpecCrew (--all також видаляє робочий простір)
|
|
290
|
-
```
|
|
291
|
-
|
|
292
|
-
📖 **Детальний посібник**: Після встановлення ознайомтесь з [Посібником початку роботи](docs/GETTING-STARTED.uk.md) для повного робочого процесу та посібника діалогів агентів.
|
|
293
|
-
|
|
294
|
-
---
|
|
295
|
-
|
|
296
|
-
## Більше інформації
|
|
297
|
-
|
|
298
|
-
- **Карта знань Агентів**: [speccrew-workspace/docs/agent-knowledge-map.md](./speccrew-workspace/docs/agent-knowledge-map.md)
|
|
299
|
-
- **npm**: https://www.npmjs.com/package/speccrew
|
|
300
|
-
- **GitHub**: https://github.com/charlesmu99/speccrew
|
|
301
|
-
- **Gitee**: https://gitee.com/amutek/speccrew
|
|
302
|
-
- **Qoder IDE**: https://qoder.com/
|
|
303
|
-
|
|
304
|
-
---
|
|
305
|
-
|
|
306
|
-
> **SpecCrew не має на меті замінити розробників, а автоматизувати нудні частини, щоб команди могли зосередитися на більш цінній роботі.**
|
package/README.vi.md
DELETED
|
@@ -1,174 +0,0 @@
|
|
|
1
|
-
# SpecCrew - Khung Kỹ thuật Phần mềm Điều khiển bởi AI
|
|
2
|
-
|
|
3
|
-
<p align="center">
|
|
4
|
-
<a href="./README.md">简体中文</a> |
|
|
5
|
-
<a href="./README.zh-TW.md">繁體中文</a> |
|
|
6
|
-
<a href="./README.en.md">English</a> |
|
|
7
|
-
<a href="./README.ko.md">한국어</a> |
|
|
8
|
-
<a href="./README.de.md">Deutsch</a> |
|
|
9
|
-
<a href="./README.es.md">Español</a> |
|
|
10
|
-
<a href="./README.fr.md">Français</a> |
|
|
11
|
-
<a href="./README.it.md">Italiano</a> |
|
|
12
|
-
<a href="./README.da.md">Dansk</a> |
|
|
13
|
-
<a href="./README.ja.md">日本語</a> |
|
|
14
|
-
<a href="./README.pl.md">Polski</a> |
|
|
15
|
-
<a href="./README.ru.md">Русский</a> |
|
|
16
|
-
<a href="./README.bs.md">Bosanski</a> |
|
|
17
|
-
<a href="./README.ar.md">العربية</a> |
|
|
18
|
-
<a href="./README.no.md">Norsk</a> |
|
|
19
|
-
<a href="./README.pt-BR.md">Português (Brasil)</a> |
|
|
20
|
-
<a href="./README.th.md">ไทย</a> |
|
|
21
|
-
<a href="./README.tr.md">Türkçe</a> |
|
|
22
|
-
<a href="./README.uk.md">Українська</a> |
|
|
23
|
-
<a href="./README.bn.md">বাংলা</a> |
|
|
24
|
-
<a href="./README.el.md">Ελληνικά</a> |
|
|
25
|
-
<a href="./README.vi.md">Tiếng Việt</a>
|
|
26
|
-
</p>
|
|
27
|
-
|
|
28
|
-
<p align="center">
|
|
29
|
-
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/v/speccrew.svg" alt="npm version"></a>
|
|
30
|
-
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/dm/speccrew.svg" alt="npm downloads"></a>
|
|
31
|
-
<a href="https://github.com/charlesmu99/speccrew/blob/main/LICENSE"><img src="https://img.shields.io/npm/l/speccrew.svg" alt="license"></a>
|
|
32
|
-
</p>
|
|
33
|
-
|
|
34
|
-
> Một đội phát triển AI ảo cho phép triển khai kỹ thuật nhanh chóng cho bất kỳ dự án phần mềm nào
|
|
35
|
-
|
|
36
|
-
## SpecCrew là gì?
|
|
37
|
-
|
|
38
|
-
SpecCrew là một khung đội phát triển AI ảo được nhúng. Nó chuyển đổi các quy trình kỹ thuật phần mềm chuyên nghiệp (PRD → Feature Design → System Design → Dev → Test) thành các quy trình Agent có thể tái sử dụng, giúp các đội phát triển đạt được Specification-Driven Development (SDD), đặc biệt phù hợp cho các dự án hiện có.
|
|
39
|
-
|
|
40
|
-
Bằng cách tích hợp các Agent và Skill vào các dự án hiện có, các đội có thể nhanh chóng khởi tạo hệ thống tài liệu dự án và đội phần mềm ảo, triển khai các tính năng mới và sửa đổi theo các quy trình kỹ thuật tiêu chuẩn từng bước.
|
|
41
|
-
|
|
42
|
-
---
|
|
43
|
-
|
|
44
|
-
## ✨ Điểm Nổi Bật Chính
|
|
45
|
-
|
|
46
|
-
### 🏭 Đội Phần Mềm Ảo
|
|
47
|
-
Tạo bằng một cú nhấp chuột **7 vai trò Agent chuyên nghiệp** + **30+ quy trình Skill**, xây dựng đội phần mềm ảo hoàn chỉnh:
|
|
48
|
-
- **Team Leader** - Lập kế hoạch toàn cầu và quản lý lặp lại
|
|
49
|
-
- **Product Manager** - Phân tích yêu cầu và xuất PRD
|
|
50
|
-
- **Feature Designer** - Thiết kế tính năng + hợp đồng API
|
|
51
|
-
- **System Designer** - Thiết kế hệ thống Frontend/Backend/Mobile/Desktop
|
|
52
|
-
- **System Developer** - Phát triển song song đa nền tảng
|
|
53
|
-
- **Test Manager** - Điều phối kiểm thử ba giai đoạn
|
|
54
|
-
- **Task Worker** - Thực thi tác vụ phụ song song
|
|
55
|
-
|
|
56
|
-
### 📐 Mô hình hóa ISA-95 Sáu Giai đoạn
|
|
57
|
-
Dựa trên phương pháp luận mô hình hóa quốc tế **ISA-95**, chuẩn hóa chuyển đổi yêu cầu nghiệp vụ thành hệ thống phần mềm:
|
|
58
|
-
```
|
|
59
|
-
Domain Descriptions → Functions in Domains → Functions of Interest
|
|
60
|
-
↓ ↓ ↓
|
|
61
|
-
Information Flows → Categories of Information → Information Descriptions
|
|
62
|
-
```
|
|
63
|
-
- Mỗi giai đoạn tương ứng với biểu đồ UML cụ thể (use case, sequence, class)
|
|
64
|
-
- Yêu cầu nghiệp vụ được "tinh chế từng bước", không mất thông tin
|
|
65
|
-
- Đầu ra có thể sử dụng trực tiếp cho phát triển
|
|
66
|
-
|
|
67
|
-
### 📚 Hệ thống Cơ sở Kiến thức
|
|
68
|
-
Kiến trúc cơ sở kiến thức ba tầng đảm bảo AI luôn làm việc dựa trên "nguồn sự thật duy nhất":
|
|
69
|
-
|
|
70
|
-
| Tầng | Thư mục | Nội dung | Mục đích |
|
|
71
|
-
|------|---------|----------|----------|
|
|
72
|
-
| L1 Kiến thức Hệ thống | `knowledge/techs/` | Stack công nghệ, kiến trúc, quy ước | AI hiểu ranh giới kỹ thuật của dự án |
|
|
73
|
-
| L2 Kiến thức Nghiệp vụ | `knowledge/bizs/` | Chức năng module, luồng nghiệp vụ, thực thể | AI hiểu logic nghiệp vụ |
|
|
74
|
-
| L3 Tạo phẩm Lặp | `iterations/iXXX/` | PRD, tài liệu thiết kế, báo cáo kiểm thử | Chuỗi truy xuất đầy đủ cho yêu cầu hiện tại |
|
|
75
|
-
|
|
76
|
-
### 🔄 Pipeline Kiến thức Bốn Giai đoạn
|
|
77
|
-
**Kiến trúc tạo kiến thức tự động**, tự động tạo tài liệu nghiệp vụ/kỹ thuật từ mã nguồn:
|
|
78
|
-
```
|
|
79
|
-
Giai đoạn 1: Quét mã nguồn → Tạo danh sách module
|
|
80
|
-
Giai đoạn 2: Phân tích song song → Trích xuất tính năng (nhiều Worker song song)
|
|
81
|
-
Giai đoạn 3: Tóm tắt song song → Hoàn thành tổng quan module (nhiều Worker song song)
|
|
82
|
-
Giai đoạn 4: Tổng hợp hệ thống → Tạo toàn cảnh hệ thống
|
|
83
|
-
```
|
|
84
|
-
- Hỗ trợ **đồng bộ hóa đầy đủ** và **đồng bộ hóa tăng dần** (dựa trên Git diff)
|
|
85
|
-
- Một người tối ưu hóa, cả đội chia sẻ
|
|
86
|
-
|
|
87
|
-
### 🔧 Harness Khung Thực chiến Triển khai
|
|
88
|
-
**Khung thực thi chuẩn hóa**, đảm bảo tài liệu thiết kế được chuyển đổi chính xác thành các chỉ lệnh phát triển có thể thực thi:
|
|
89
|
-
- **Nguyên tắc sổ tay vận hành**: Skill là SOP, các bước rõ ràng, liên tục và tự chứa
|
|
90
|
-
- **Hợp đồng đầu vào-đầu ra**: Định nghĩa rõ ràng các giao diện, thực thi nghiêm ngặt như pseudocode
|
|
91
|
-
- **Kiến trúc tiết lộ dần dần**: Tải thông tin theo lớp, tránh quá tải ngữ cảnh một lần
|
|
92
|
-
- **Ủy quyền Sub-Agent**: Tự động chia nhỏ tác vụ phức tạp, thực thi song song đảm bảo chất lượng
|
|
93
|
-
|
|
94
|
-
---
|
|
95
|
-
|
|
96
|
-
## Giải quyết 8 Vấn đề Cốt lõi
|
|
97
|
-
|
|
98
|
-
### 1. AI Bỏ qua Tài liệu Dự án Hiện có (Khoảng trống Kiến thức)
|
|
99
|
-
**Vấn đề**: Các phương pháp SDD hoặc Vibe Coding hiện có phụ thuộc vào AI tóm tắt các dự án theo thời gian thực, dễ dàng bỏ lỡ bối cảnh quan trọng và gây ra kết quả phát triển lệch khỏi kỳ vọng.
|
|
100
|
-
|
|
101
|
-
**Giải pháp**: Kho lưu trữ `knowledge/` đóng vai trò là "nguồn sự thật duy nhất" của dự án, tích lũy thiết kế kiến trúc, các mô-đun chức năng và quy trình kinh doanh để đảm bảo các yêu cầu vẫn đúng hướng từ nguồn.
|
|
102
|
-
|
|
103
|
-
### 2. Tài liệu Kỹ thuật Trực tiếp từ PRD (Bỏ sót Nội dung)
|
|
104
|
-
**Vấn đề**: Nhảy trực tiếp từ PRD đến thiết kế chi tiết dễ dàng bỏ sót các chi tiết yêu cầu, khiến các tính năng được triển khai lệch khỏi yêu cầu.
|
|
105
|
-
|
|
106
|
-
**Giải pháp**: Giới thiệu giai đoạn **Tài liệu Feature Design**, chỉ tập trung vào khung yêu cầu mà không có chi tiết kỹ thuật:
|
|
107
|
-
- Bao gồm những trang và thành phần nào?
|
|
108
|
-
- Các luồng thao tác trang
|
|
109
|
-
- Logic xử lý backend
|
|
110
|
-
- Cấu trúc lưu trữ dữ liệu
|
|
111
|
-
|
|
112
|
-
Phát triển chỉ cần "điền nội dung" dựa trên ngăn xếp công nghệ cụ thể, đảm bảo các tính năng phát triển "gần xương (yêu cầu)".
|
|
113
|
-
|
|
114
|
-
### 3. Phạm vi Tìm kiếm Agent Không chắc chắn (Sự không chắc chắn)
|
|
115
|
-
**Vấn đề**: Trong các dự án phức tạp, tìm kiếm rộng mã và tài liệu bởi AI mang lại kết quả không chắc chắn, làm cho tính nhất quán khó đảm bảo.
|
|
116
|
-
|
|
117
|
-
**Giải pháp**: Các cấu trúc thư mục tài liệu rõ ràng và các mẫu, được thiết kế dựa trên nhu cầu của từng Agent, triển khai **tiết lộ dần dần và tải theo yêu cầu** để đảm bảo sự tất định.
|
|
118
|
-
|
|
119
|
-
### 4. Thiếu Các Bước và Nhiệm vụ (Đứt gãy Quy trình)
|
|
120
|
-
**Vấn đề**: Thiếu bao phủ đầy đủ quy trình kỹ thuật dễ dàng bỏ sót các bước quan trọng, làm cho chất lượng khó đảm bảo.
|
|
121
|
-
|
|
122
|
-
**Giải pháp**: Bao phủ toàn bộ vòng đời kỹ thuật phần mềm:
|
|
123
|
-
```
|
|
124
|
-
PRD (Yêu cầu) → Feature Design (Thiết kế Tính năng) → API Contract (Hợp đồng)
|
|
125
|
-
→ System Design (Thiết kế Hệ thống) → Dev (Phát triển) → Test (Kiểm thử)
|
|
126
|
-
```
|
|
127
|
-
- Đầu ra của mỗi giai đoạn là đầu vào của giai đoạn tiếp theo
|
|
128
|
-
- Mỗi bước yêu cầu xác nhận của con người trước khi tiếp tục
|
|
129
|
-
- Tất cả các thực thi Agent có danh sách todo với tự kiểm tra sau khi hoàn thành
|
|
130
|
-
|
|
131
|
-
### 5. Hiệu quả Hợp tác Đội thấp (Các hầm chứa Kiến thức)
|
|
132
|
-
**Vấn đề**: Kinh nghiệm lập trình AI khó chia sẻ giữa các đội, dẫn đến các lỗi lặp lại.
|
|
133
|
-
|
|
134
|
-
**Giải pháp**: Tất cả các Agent, Skill và tài liệu liên quan được kiểm soát phiên bản với mã nguồn:
|
|
135
|
-
- Tối ưu hóa của một người được chia sẻ bởi đội
|
|
136
|
-
- Kiến thức được tích lũy trong cơ sở mã
|
|
137
|
-
- Cải thiện hiệu quả hợp tác đội
|
|
138
|
-
|
|
139
|
-
### 7. Ngữ cảnh Đơn Agent Quá dài (Điểm nghẽn Hiệu suất)
|
|
140
|
-
**Vấn đề**: Các nhiệm vụ phức tạp lớn vượt qua cửa sổ ngữ cảnh đơn Agent, gây ra sự lệch lạc trong hiểu biết và giảm chất lượng đầu ra.
|
|
141
|
-
|
|
142
|
-
**Giải pháp**: **Cơ chế Tự động Điều phối Sub-Agent**:
|
|
143
|
-
- Các nhiệm vụ phức tạp được tự động nhận diện và chia thành các nhiệm vụ con
|
|
144
|
-
- Mỗi nhiệm vụ con được thực thi bởi một Sub-Agent độc lập với ngữ cảnh được cô lập
|
|
145
|
-
- Agent cha điều phối và tổng hợp để đảm bảo tính nhất quán tổng thể
|
|
146
|
-
- Tránh mở rộng ngữ cảnh đơn Agent, đảm bảo chất lượng đầu ra
|
|
147
|
-
|
|
148
|
-
### 8. Sự hỗn loạn Lặp lại Yêu cầu (Khó khăn Quản lý)
|
|
149
|
-
**Vấn đề**: Nhiều yêu cầu trộn lẫn trong cùng một nhánh ảnh hưởng lẫn nhau, làm cho việc theo dõi và quay lại trở nên khó khăn.
|
|
150
|
-
|
|
151
|
-
**Giải pháp**: **Mỗi Yêu cầu như một Dự án Độc lập**:
|
|
152
|
-
- Mỗi yêu cầu tạo một thư mục lặp lại độc lập `iterations/iXXX-[tên-yêu-cầu]/`
|
|
153
|
-
- Cô lập hoàn toàn: tài liệu, thiết kế, mã và kiểm thử được quản lý độc lập
|
|
154
|
-
- Lặp lại nhanh chóng: giao hàng độ hạt nhỏ, xác minh nhanh, triển khai nhanh
|
|
155
|
-
- Lưu trữ linh hoạt: sau khi hoàn thành, lưu trữ trong `archive/` với khả năng truy xuất lịch sử rõ ràng
|
|
156
|
-
|
|
157
|
-
### 6. Trì hoãn Cập nhật Tài liệu (Sự xuống cấp Kiến thức)
|
|
158
|
-
**Vấn đề**: Tài liệu trở nên lỗi thời khi các dự án phát triển, khiến AI làm việc với thông tin sai.
|
|
159
|
-
|
|
160
|
-
**Giải pháp**: Các Agent có khả năng cập nhật tài liệu tự động, đồng bộ hóa các thay đổi dự án theo thời gian thực để giữ cho cơ sở kiến thức chính xác.
|
|
161
|
-
|
|
162
|
-
---
|
|
163
|
-
|
|
164
|
-
## Thông tin Bổ sung
|
|
165
|
-
|
|
166
|
-
- **Bản đồ Kiến thức Agent**: [speccrew-workspace/docs/agent-knowledge-map.md](./speccrew-workspace/docs/agent-knowledge-map.md)
|
|
167
|
-
- **npm**: https://www.npmjs.com/package/speccrew
|
|
168
|
-
- **GitHub**: https://github.com/charlesmu99/speccrew
|
|
169
|
-
- **Gitee**: https://gitee.com/amutek/speccrew
|
|
170
|
-
- **Qoder IDE**: https://qoder.com/
|
|
171
|
-
|
|
172
|
-
---
|
|
173
|
-
|
|
174
|
-
> **SpecCrew không nhằm mục đích thay thế các nhà phát triển, mà tự động hóa các phần nhàm chán để các đội có thể tập trung vào công việc có giá trị hơn.**
|