Cách sử dụng AI hiệu quả trong công việc -

Tôi sắp cung cấp cho bạn một danh sách nhiều task cần xử lý trong cùng một session.

Tôi sắp cung cấp nhiều task cần xử lý trong cùng một session.

MỤC TIÊU:
Tiếp nhận toàn bộ task trước, sau đó mới điều tra source code, phân tích tổng thể và tạo plan riêng cho từng task.

==================================================
GIAI ĐOẠN 1 - TIẾP NHẬN TASK
==================================================

Tôi sẽ gửi từng task trong các message riêng biệt.

Trong giai đoạn này:
- Chỉ tiếp nhận và ghi nhớ thông tin.
- KHÔNG phân tích.
- KHÔNG điều tra source code.
- KHÔNG viết hoặc sửa code.
- KHÔNG tạo plan.
- KHÔNG tự bắt đầu thực hiện.

Sau mỗi task chỉ trả lời:

"Đã tiếp nhận Task N: <mô tả ngắn>"

Sau đó chờ task tiếp theo.

Thông tin tôi gửi có thể bao gồm:
- Requirement
- SRS
- Screenshot
- API
- Database/Table
- Business Rule
- Source path
- Jira/Task description
- Ghi chú
- Constraint

Hãy coi tất cả là context của task tương ứng.

==================================================
GIAI ĐOẠN 2 - BẮT ĐẦU PHÂN TÍCH
==================================================

CHỈ khi tôi nói:

"HẾT TASK - BẮT ĐẦU PHÂN TÍCH"

thì mới bắt đầu làm việc.

Trước tiên:

1. Tổng hợp toàn bộ task đã nhận.
2. Tự xác định module/domain nghiệp vụ chung của nhóm task.
3. Điều tra source code thực tế.
4. Xác định dependency giữa các task.
5. Tìm implementation/business logic hiện tại có thể reuse.
6. Xác định ảnh hưởng BE / FE / DB.
7. Phát hiện phần logic dùng chung.
8. Đề xuất thứ tự implementation hợp lý.

YÊU CẦU:

- Investigation first, design second.
- Ưu tiên reuse implementation hiện tại.
- Không duplicate business logic.
- Tuân thủ architecture và coding convention hiện tại.
- Chú trọng SOLID.
- Chú trọng transaction/concurrency/performance khi cần.
- Không over-engineering.
- Không suy đoán API/Class/Table nếu có thể kiểm tra trong source.
- Nếu không xác định được thì ghi rõ NEED CONFIRM.

==================================================
GIAI ĐOẠN 3 - XÁC ĐỊNH THƯ MỤC PLAN
==================================================

Root directory:

C:\PROJECT\Docs\Plan

TỰ xác định tên module/domain từ nội dung các task.

Ví dụ:

Task thuộc Hình sự
→ C:\PROJECT\Docs\Plan\HinhSu

Task thuộc Dân sự
→ C:\PROJECT\Docs\Plan\DanSu

Task thuộc Thi hành án
→ C:\PROJECT\Docs\Plan\ThiHanhAn

Task thuộc Quản trị
→ C:\PROJECT\Docs\Plan\QuanTri

Đây chỉ là ví dụ, KHÔNG phải danh sách cố định.

Quy tắc đặt tên folder:
- PascalCase.
- Không dấu.
- Ngắn gọn.
- Phản ánh đúng module/domain nghiệp vụ.

Nếu không thể xác định chắc chắn module/domain:
- KHÔNG tự đoán.
- Hỏi tôi confirm tên folder trước khi tạo plan.

==================================================
GIAI ĐOẠN 4 - TẠO PLAN
==================================================

Trong folder module/domain đã xác định, tạo:

00_MASTER_PLAN.md

và một file riêng cho MỖI task:

TASK_01_<short-name>.md
TASK_02_<short-name>.md
TASK_03_<short-name>.md
...

Tên <short-name>:
- Không dấu.
- Ngắn gọn.
- Mô tả đúng chức năng.
- Không phụ thuộc vào thứ tự message ngoài Task N.

--------------------------------------------------
MASTER PLAN
--------------------------------------------------

00_MASTER_PLAN.md phải chứa:

1. Scope tổng thể
2. Danh sách task
3. Phân loại BE / FE / DB nếu có
4. Dependency giữa các task
5. Shared components / shared business logic
6. Existing implementation có thể reuse
7. Thứ tự implementation đề xuất
8. Risk chung
9. Các vấn đề cần confirm
10. Trạng thái từng task

--------------------------------------------------
TASK PLAN
--------------------------------------------------

Mỗi TASK file phải có:

# TASK N - <Tên task>

## 1. Requirement
## 2. Current Implementation
## 3. Business Flow
## 4. Source Code Investigation
## 5. Existing Code Can Reuse
## 6. API Impact
## 7. Database Impact
## 8. Backend Impact
## 9. Frontend Impact
## 10. Files / Classes Expected To Change
## 11. Implementation Plan
## 12. Validation / Business Rules
## 13. Transaction / Concurrency / Performance
## 14. Test Cases
## 15. Dependencies With Other Tasks
## 16. Risks
## 17. Need Confirm

Nếu section nào không áp dụng:
- Ghi "N/A".
- Không cố tạo nội dung giả.

==================================================
QUY TẮC QUAN TRỌNG
==================================================

Trong quá trình này:

- CHỈ điều tra và tạo tài liệu plan.
- KHÔNG implement.
- KHÔNG sửa source code.
- KHÔNG refactor source code.
- KHÔNG tự fix issue phát hiện được.
- KHÔNG thay đổi DB/Liquibase.
- KHÔNG tự ý mở rộng scope.

Chỉ được tạo/cập nhật tài liệu bên trong:

C:\PROJECT\Docs\Plan\<Module>

Nếu phát hiện vấn đề ngoài scope:
→ Ghi vào Risks / Need Confirm.
→ Không tự xử lý.

Plan phải dựa trên SOURCE CODE THỰC TẾ đã điều tra, không chỉ dựa vào mô tả task.

==================================================
KẾT THÚC
==================================================

Sau khi tạo xong:

1. Báo module/domain đã xác định.
2. Báo đường dẫn folder plan.
3. Liệt kê các file đã tạo.
4. Tóm tắt dependency giữa các task.
5. Liệt kê các vấn đề cần tôi confirm.
6. DỪNG LẠI.

TUYỆT ĐỐI KHÔNG IMPLEMENT cho đến khi tôi confirm.

Nếu hiểu quy trình, chỉ trả lời:

"Sẵn sàng nhận Task 1."

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

Tôi sắp cung cấp nhiều task cần xử lý trong cùng một session.

MỤC TIÊU:

Tiếp nhận toàn bộ task trước, sau đó mới điều tra source code, phân tích tổng thể và tạo plan riêng cho từng task.

==================================================

GIAI ĐOẠN 1 - TIẾP NHẬN TASK

==================================================

Tôi sẽ gửi từng task trong các message riêng biệt.

Trong giai đoạn này:

- Chỉ tiếp nhận và ghi nhớ thông tin.

- KHÔNG phân tích.

- KHÔNG điều tra source code.

- KHÔNG viết hoặc sửa code.

- KHÔNG tạo plan.

- KHÔNG tự bắt đầu thực hiện.

Sau mỗi task chỉ trả lời:

"Đã tiếp nhận Task N: <mô tả ngắn>"

Sau đó chờ task tiếp theo.

Thông tin tôi gửi có thể bao gồm:

- Requirement

- SRS

- Screenshot

- API

- Database/Table

- Business Rule

- Source path

- Jira/Task description

- Ghi chú

- Constraint

Hãy coi tất cả là context của task tương ứng.

==================================================

GIAI ĐOẠN 2 - BẮT ĐẦU PHÂN TÍCH

==================================================

CHỈ khi tôi nói:

"HẾT TASK - BẮT ĐẦU PHÂN TÍCH"

thì mới bắt đầu làm việc.

Trước tiên:

1. Tổng hợp toàn bộ task đã nhận.

2. Tự xác định module/domain nghiệp vụ chung của nhóm task.

3. Điều tra source code thực tế.

4. Xác định dependency giữa các task.

5. Tìm implementation/business logic hiện tại có thể reuse.

6. Xác định ảnh hưởng BE / FE / DB.

7. Phát hiện phần logic dùng chung.

8. Đề xuất thứ tự implementation hợp lý.

YÊU CẦU:

- Investigation first, design second.

- Ưu tiên reuse implementation hiện tại.

- Không duplicate business logic.

- Tuân thủ architecture và coding convention hiện tại.

- Chú trọng SOLID.

- Chú trọng transaction/concurrency/performance khi cần.

- Không over-engineering.

- Không suy đoán API/Class/Table nếu có thể kiểm tra trong source.

- Nếu không xác định được thì ghi rõ NEED CONFIRM.

==================================================

GIAI ĐOẠN 3 - XÁC ĐỊNH THƯ MỤC PLAN

==================================================

Root directory:

C:\PROJECT\Docs\Plan

TỰ xác định tên module/domain từ nội dung các task.

Ví dụ:

Task thuộc Hình sự

→ C:\PROJECT\Docs\Plan\HinhSu

Task thuộc Dân sự

→ C:\PROJECT\Docs\Plan\DanSu

Task thuộc Thi hành án

→ C:\PROJECT\Docs\Plan\ThiHanhAn

Task thuộc Quản trị

→ C:\PROJECT\Docs\Plan\QuanTri

Đây chỉ là ví dụ, KHÔNG phải danh sách cố định.

Quy tắc đặt tên folder:

- PascalCase.

- Không dấu.

- Ngắn gọn.

- Phản ánh đúng module/domain nghiệp vụ.

Nếu không thể xác định chắc chắn module/domain:

- KHÔNG tự đoán.

- Hỏi tôi confirm tên folder trước khi tạo plan.

==================================================

GIAI ĐOẠN 4 - TẠO PLAN

==================================================

Trong folder module/domain đã xác định, tạo:

00_MASTER_PLAN.md

và một file riêng cho MỖI task:

TASK_01_<short-name>.md

TASK_02_<short-name>.md

TASK_03_<short-name>.md

...

Tên <short-name>:

- Không dấu.

- Ngắn gọn.

- Mô tả đúng chức năng.

- Không phụ thuộc vào thứ tự message ngoài Task N.

--------------------------------------------------

MASTER PLAN

--------------------------------------------------

00_MASTER_PLAN.md phải chứa:

1. Scope tổng thể

2. Danh sách task

3. Phân loại BE / FE / DB nếu có

4. Dependency giữa các task

5. Shared components / shared business logic

6. Existing implementation có thể reuse

7. Thứ tự implementation đề xuất

8. Risk chung

9. Các vấn đề cần confirm

10. Trạng thái từng task

--------------------------------------------------

TASK PLAN

--------------------------------------------------

Mỗi TASK file phải có:

# TASK N - <Tên task>

## 1. Requirement

## 2. Current Implementation

## 3. Business Flow

## 4. Source Code Investigation

## 5. Existing Code Can Reuse

## 6. API Impact

## 7. Database Impact

## 8. Backend Impact

## 9. Frontend Impact

## 10. Files / Classes Expected To Change

## 11. Implementation Plan

## 12. Validation / Business Rules

## 13. Transaction / Concurrency / Performance

## 14. Test Cases

## 15. Dependencies With Other Tasks

## 16. Risks

## 17. Need Confirm

Nếu section nào không áp dụng:

- Ghi "N/A".

- Không cố tạo nội dung giả.

==================================================

QUY TẮC QUAN TRỌNG

==================================================

Trong quá trình này:

- CHỈ điều tra và tạo tài liệu plan.

- KHÔNG implement.

- KHÔNG sửa source code.

- KHÔNG refactor source code.

- KHÔNG tự fix issue phát hiện được.

- KHÔNG thay đổi DB/Liquibase.

- KHÔNG tự ý mở rộng scope.

Chỉ được tạo/cập nhật tài liệu bên trong:

C:\PROJECT\Docs\Plan\<Module>

Nếu phát hiện vấn đề ngoài scope:

→ Ghi vào Risks / Need Confirm.

→ Không tự xử lý.

Plan phải dựa trên SOURCE CODE THỰC TẾ đã điều tra, không chỉ dựa vào mô tả task.

==================================================

KẾT THÚC

==================================================

Sau khi tạo xong:

1. Báo module/domain đã xác định.

2. Báo đường dẫn folder plan.

3. Liệt kê các file đã tạo.

4. Tóm tắt dependency giữa các task.

5. Liệt kê các vấn đề cần tôi confirm.

6. DỪNG LẠI.

TUYỆT ĐỐI KHÔNG IMPLEMENT cho đến khi tôi confirm.

Nếu hiểu quy trình, chỉ trả lời:

"Sẵn sàng nhận Task 1."

Sau đó bạn cứ gửi tự nhiên:

Task 1:
[BE] API danh sách ...

Requirement:
...

Các file/module liên quan nếu biết:
...

Task 1:

[BE] API danh sách ...

Requirement:

...

Các file/module liên quan nếu biết:

...

Cứ thế cho đến khi hết. Điểm quan trọng là đừng bảo Claude “phân tích task này” ở từng message, vì như vậy nó sẽ tốn context/token vào việc điều tra từng task ngay lúc nhận.

HẾT TASK.

BẮT ĐẦU PHÂN TÍCH.

Hãy xem toàn bộ các task như một scope công việc thống nhất, không phân tích chúng như các yêu cầu hoàn toàn độc lập.

Ưu tiên:
- Điều tra implementation hiện tại trước khi đề xuất code mới.
- Tận dụng code/business logic/API/entity/repository/service có sẵn.
- Xác định dependency giữa các task.
- Tránh duplicate logic.
- Đánh giá performance nếu có xử lý dữ liệu lớn.
- Tuân thủ SOLID và convention hiện tại của project.
- Không over-engineering.

Output cho tôi:
1. Tổng hợp scope
2. Phân tích từng task
3. Dependency giữa các task
4. Code hiện tại có thể reuse
5. File/class dự kiến cần sửa
6. DB/API ảnh hưởng
7. Thứ tự implementation đề xuất
8. Risk / vấn đề chưa rõ
9. Những điểm cần tôi CONFIRM

CHƯA ĐƯỢC SỬA CODE.
Chờ tôi confirm kế hoạch trước.

HẾT TASK.

BẮT ĐẦU PHÂN TÍCH.

Hãy xem toàn bộ các task như một scope công việc thống nhất, không phân tích chúng như các yêu cầu hoàn toàn độc lập.

Ưu tiên:

- Điều tra implementation hiện tại trước khi đề xuất code mới.

- Tận dụng code/business logic/API/entity/repository/service có sẵn.

- Xác định dependency giữa các task.

- Tránh duplicate logic.

- Đánh giá performance nếu có xử lý dữ liệu lớn.

- Tuân thủ SOLID và convention hiện tại của project.

- Không over-engineering.

Output cho tôi:

1. Tổng hợp scope

2. Phân tích từng task

3. Dependency giữa các task

4. Code hiện tại có thể reuse

5. File/class dự kiến cần sửa

6. DB/API ảnh hưởng

7. Thứ tự implementation đề xuất

8. Risk / vấn đề chưa rõ

9. Những điểm cần tôi CONFIRM

CHƯA ĐƯỢC SỬA CODE.

Chờ tôi confirm kế hoạch trước.

NearTechSoft – Thiết kế website giá rẻ

Cách sử dụng AI hiệu quả trong công việc

Liên hệ

Thiết kế website

Trợ giúp