Tôi đã làm chủ quy trình làm việc với Claude Code

Bạn 🤝 Claude Code

Tuyên bố miễn trừ trách nhiệm: Bài viết này hoàn toàn do con người viết. Tác giả của nó, Ashley, đã viết với mục đích cung cấp kiến thức thực sự hữu ích và có mục tiêu rõ ràng. Nếu bạn đến đây để tìm những nội dung nhảm nhí do AI tạo ra, bạn sẽ không tìm thấy ở đây đâu.

Tóm tắt nhanh

Không bao giờ vượt quá 60% ngữ cảnh. Chia công việc thành 4 giai đoạn: Nghiên cứu → Lên kế hoạch → Triển khai → Xác thực. Xóa ngữ cảnh giữa mỗi giai đoạn. Lưu mọi thứ vào một thư mục thoughts/ được liên kết tượng trưng (sử dụng npx humanlayer thoughts init).

Một trong những điểm mạnh mẽ nhất mà tôi muốn nhấn mạnh là về thư mục ‘thoughts’ được liên kết tượng trưng ở đây. Điều quan trọng cần lưu ý là thư mục này có thể được chia sẻ toàn cục, trên các repo, để mọi người trong nhóm và tổ chức của bạn đều có quyền truy cập vào các tài liệu mà Claude đang chỉnh sửa và xây dựng từ đó. Điều này cực kỳ mạnh mẽ.

Tôi thực sự khuyên bạn nên tải xuống các tệp .claude/commands và .claude/agents của humanlayer và dành chút thời gian để chỉnh sửa chúng cho phù hợp với codebase của bạn. Tải chúng tại đây!

Giờ thì vào phần chính nào :)

Thiên đường ngữ cảnh

Sáu tháng trước, các cuộc trò chuyện của tôi với các trợ lý lập trình AI trông giống như thế này: Tôi bắt đầu làm việc trên một tính năng, tải lên một loạt tệp, đặt câu hỏi, nhận câu trả lời, thực hiện thay đổi, gặp lỗi, thêm nhiều tệp hơn để cung cấp ngữ cảnh, đặt thêm câu hỏi. Chẳng mấy chốc, tôi đã đạt đến 95% dung lượng ngữ cảnh với mã nguồn được triển khai một nửa và hàng tá tệp “final_implementation_final_feature.md” 💀

Việc chuyển trọng tâm sang kỹ thuật ngữ cảnh đã thay đổi điều đó. (xin gửi lời cảm ơn sâu sắc đến đội ngũ humanlayer, đặc biệt là Dex, người giải thích điều này cực kỳ tốt và là nguồn cảm hứng lớn cho tôi.) Giờ đây, tôi có thể tạo ra hàng nghìn dòng mã với sự tự tin hơn bằng cách sử dụng một quy trình làm việc có cấu trúc giúp giữ cho ngữ cảnh của tôi sạch sẽ, kế hoạch vững chắc và kết quả triển khai dễ đoán hơn rất nhiều.

Kỹ thuật ngữ cảnh là tất cả những gì bạn cần

Vấn đề thực sự không phải là có nhiều ngữ cảnh hơn, mà là có đúng ngữ cảnh vào đúng thời điểm.

Bạn càng phân bổ nhiều vào cửa sổ ngữ cảnh, kết quả càng tệ (cả về chất lượng và hành vi không mong muốn) và tôi thấy điều này đúng bất kể bạn đang sử dụng LLM nào.

Quy tắc cá nhân của tôi: không bao giờ để ngữ cảnh vượt quá 60%. Tôi luôn kiểm tra bằng lệnh /context trong các phiên làm việc của mình.

Để tham khảo, đây là ngữ cảnh của tôi khi bắt đầu một cuộc trò chuyện mới

Vậy là, khoảng ~32% khi bắt đầu bất kỳ cuộc trò chuyện nào.

Tôi thường chia quy trình làm việc của mình thành bốn giai đoạn cốt lõi, xóa ngữ cảnh giữa mỗi giai đoạn. Ví dụ, nó có thể trông như sau:

1. Nghiên cứu: Prompt Claude của tôi: “/research_codebase + tính năng tôi muốn triển khai tiếp theo hoặc nghiên cứu codebase chung” → /context và /clear context nếu nghiên cứu vượt quá 60%, điều này thường xảy ra, và cứ thế cho 3 giai đoạn còn lại.

2. Lên kế hoạch: Prompt Claude của tôi: “/create_plan + @thoughts/research/researched_feature.md” → /context → 70% → /clear

3. Triển khai: Prompt Claude của tôi: “/implement_plan + @thoughts/plans/research_and_planned_feature.md Chỉ Giai đoạn 1 của kế hoạch này” → /context → 67% → /clear

4. Xác thực: Prompt Claude của tôi: “/validate_plan + @thoughts/plans/research_and_planned_feature.md + Tôi đã triển khai giai đoạn 1 của tài liệu kế hoạch này, vui lòng xác thực nó” → /context → 42% → tiếp tục cuộc trò chuyện (tức là không xóa ngữ cảnh)

Mỗi giai đoạn có một công việc cụ thể. Mỗi giai đoạn tạo ra các sản phẩm mà giai đoạn tiếp theo sẽ sử dụng.

Vâng, nó... khá nhiều nên hãy để tôi phân tích chi tiết.

Quy trình làm việc với Claude Code của tôi

Giai đoạn 1: Nghiên cứu (@research_codebase.md)

Mục tiêu: Hiểu những gì đã có và những gì cần thay đổi. KHÔNG viết mã trong giai đoạn này.

Khi tôi bắt đầu một tính năng mới, tôi không bao giờ lao vào triển khai ngay. Tôi luôn nghiên cứu trước, bằng cách gọi lệnh Claude tùy chỉnh của mình (.claude/commands/research_codebase.md):

/research_codebase + {Điều tôi muốn nghiên cứu hoặc xây dựng hoặc tính năng tôi muốn triển khai}

Sau đó, sau lệnh của mình, tôi cung cấp câu hỏi nghiên cứu. Ví dụ, khi tôi cần hiểu về quản lý trang trình duyệt trong một framework tự động hóa web:

/research_codebase + Hệ thống quản lý trang trình duyệt hiện tại hoạt động như thế nào? hoặc

/research_codebase + Các trang được tạo, theo dõi và dọn dẹp ở đâu?

Lệnh nghiên cứu sẽ sinh ra các agent phụ song song để điều tra các khía cạnh khác nhau cùng một lúc:

• Một agent định vị codebase tìm tất cả các tệp liên quan
• Một agent phân tích codebase kiểm tra cách triển khai hiện tại hoạt động
• Một agent định vị thoughts tìm kiếm bất kỳ tài liệu hoặc nghiên cứu nào đã có
• Một agent phân tích thoughts trích xuất thông tin chi tiết từ các tài liệu liên quan

Các agent này hoạt động song song, trả về các đường dẫn tệp và số dòng cụ thể.

Giai đoạn nghiên cứu kết thúc bằng việc tạo ra một tài liệu nghiên cứu toàn diện trong thư mục thoughts/ của tôi:

*thoughts/shared/research/2025-10-09_browser-page-management.md*

Tài liệu này rất toàn diện và bao gồm:

• Tóm tắt các phát hiện
• Tham chiếu mã nguồn với số tệp:dòng rất quan trọng
• Thông tin chi tiết về kiến trúc
• Các câu hỏi mở cần được làm rõ

Bằng cách sinh ra các agent song song, tôi nhận được câu trả lời toàn diện một cách nhanh chóng mà không cần phải đọc hàng chục tệp theo cách thủ công. Và bởi vì mọi thứ đều được lưu vào thư mục thoughts/, bản thân tôi, nhóm của tôi và Claude có thể tham chiếu lại sau này mà không cần giữ nó trong ngữ cảnh.

Giai đoạn 2: Lên kế hoạch (@create_plan.md)

Mục tiêu: Tạo một kế hoạch triển khai chi tiết, lặp đi lặp lại.

Sau khi nghiên cứu, tôi xóa ngữ cảnh và bắt đầu lại từ đầu với việc lập kế hoạch:

@create_plan.md thoughts/shared/research/2025-10-09_browser-page-management.md

Lệnh này đọc tài liệu nghiên cứu của tôi và bắt đầu một phiên lập kế hoạch tương tác. Sau phản hồi ban đầu của Claude, tôi thường lặp lại kế hoạch khoảng 5 lần trước khi hoàn thiện nó bằng cách đọc kỹ tệp .md.

Tài liệu kế hoạch này là nguồn thông tin chính xác duy nhất của chúng tôi

Tại sao lại lặp lại nhiều như vậy? Bởi vì bản nháp đầu tiên không bao giờ hoàn chỉnh. Giai đoạn lập kế hoạch là tương tác:

1. Bản nháp đầu tiên: Claude đọc nghiên cứu, đặt câu hỏi làm rõ
2. Bản nháp thứ hai: Tôi cung cấp câu trả lời, Claude tinh chỉnh phương pháp tiếp cận
3. Bản nháp thứ ba: Chúng tôi thảo luận về các đánh đổi thiết kế, Claude cập nhật các giai đoạn
4. Bản nháp thứ tư: Chúng tôi xác định các trường hợp biên, Claude thêm tiêu chí thành công
5. Bản nháp thứ năm: Đánh giá cuối cùng, mọi thứ đều có thể thực hiện được

Mỗi lần lặp lại làm cho kế hoạch trở nên cụ thể hơn. Khi tôi hoàn thành, kế hoạch có:

• Các giai đoạn rõ ràng với những thay đổi cụ thể
• Đường dẫn tệp chính xác cần sửa đổi
• Các đoạn mã cho thấy những gì cần thêm/thay đổi
• Xác minh tự động (kiểm thử, linting, kiểm tra kiểu)
• Xác minh thủ công (những thứ con người cần kiểm tra)
• Tiêu chí thành công cho mỗi giai đoạn

Kế hoạch cuối cùng được lưu vào:

thoughts/shared/plans/2025-10-09-browser-page-management.md

Đây là một ví dụ về một giai đoạn trong kế hoạch của chúng tôi có thể trông như thế nào:

Giai đoạn 1: Thêm theo dõi trang vào BrowserContext

Tổng quan
Thêm một sổ đăng ký trang vào BrowserContext để theo dõi tất cả các trang đã tạo và trạng thái vòng đời của chúng.

Các thay đổi cần thiết:
1. Cập nhật lớp BrowserContext
   Tệp: src/browser/browser_context.py

class BrowserContext:
    def __init__(self, ...):
        self._pages: Dict[str, Page] = {}
        self._active_page: Optional[Page] = None

Tiêu chí thành công:
Xác minh tự động:
- [ ] Vượt qua unit test: uv run pytest src/browser/tests/
- [ ] Không có lỗi linting: make lint
- [ ] Kiểm tra kiểu sạch sẽ: make check

Xác minh thủ công:
- [ ] Có thể theo dõi nhiều trang cùng một lúc
- [ ] Dọn dẹp trang hoạt động ở chế độ trình duyệt có giao diện
- [ ] Không rò rỉ bộ nhớ khi tạo trang lặp đi lặp lại

Điểm mấu chốt ở đây là dành thời gian lặp lại kế hoạch sẽ tiết kiệm hàng giờ trong quá trình triển khai và tránh mã nguồn tồi. Một kế hoạch vững chắc có nghĩa là tôi hiếm khi bị mắc kẹt hoặc phải quay lại.

Lệnh nghiên cứu đã tìm thấy các dòng mã liên quan, vì vậy lệnh lập kế hoạch của chúng tôi đã tiết kiệm được rất nhiều ngữ cảnh mà giờ đây nó có thể sử dụng để triển khai kế hoạch hiệu quả hơn.

Giai đoạn 3: Triển khai (@implement_plan.md)

Mục tiêu: Thực hiện từng giai đoạn một với sự tự tin.

Sau khi lập kế hoạch, tôi lại xóa ngữ cảnh và bắt đầu triển khai:

@implement_plan.md thoughts/shared/plans/2025-10-09-browser-page-management.md

Quy tắc của tôi: triển khai từng giai đoạn một.

Lệnh triển khai:

1. Đọc hoàn toàn kế hoạch
2. Đọc tất cả các tệp được đề cập trong Giai đoạn 1
3. Thực hiện các thay đổi đã chỉ định
4. Chạy xác minh tự động
5. Tạm dừng để kiểm tra thủ công

Điểm cuối cùng đó rất quan trọng. Sau khi vượt qua tất cả các kiểm tra tự động, Claude báo cho tôi:

Giai đoạn 1 Hoàn thành - Sẵn sàng cho Xác minh Thủ công

Xác minh tự động đã vượt qua:
- ✓ Unit test đã vượt qua
- ✓ Không có lỗi linting
- ✓ Kiểm tra kiểu sạch sẽ

Vui lòng thực hiện xác minh thủ công:
- [ ] Có thể theo dõi nhiều trang cùng một lúc
- [ ] Dọn dẹp trang hoạt động ở chế độ trình duyệt có giao diện

Hãy cho tôi biết khi nào kiểm tra thủ công hoàn tất.

Sau đó, tôi kiểm tra tính năng theo cách thủ công. Nếu nó hoạt động, tôi bảo Claude tiếp tục Giai đoạn 2 (Nếu ngữ cảnh của tôi vẫn dưới 60%). Nếu không, tôi báo cáo những gì đã thất bại và chúng tôi sửa nó trước khi tiếp tục.

Cách tiếp cận này ngăn chặn một cái bẫy phổ biến: triển khai mọi thứ, sau đó phát hiện ra Giai đoạn 1 có một lỗi nghiêm trọng làm hỏng mọi thứ sau đó.

Điểm mấu chốt: Từng giai đoạn một = xác thực liên tục = ít bất ngờ hơn

Giai đoạn 4: Xác thực (@validate_plan.md)

Mục tiêu: Xác minh một cách có hệ thống toàn bộ việc triển khai.

Sau khi triển khai tất cả các giai đoạn (hoặc thậm chí chỉ một), tôi xóa ngữ cảnh một lần nữa và xác thực:

@validate_plan.md thoughts/shared/plans/2025-10-09-browser-page-management.md

Lệnh xác thực:

1. Đọc kế hoạch
2. Kiểm tra các git commit gần đây
3. Chạy tất cả các lệnh xác minh tự động
4. Xem xét các thay đổi mã nguồn so với các thông số kỹ thuật của kế hoạch
5. Tạo một báo cáo xác thực toàn diện

Báo cáo cho thấy:

• ✓ Những gì đã được triển khai chính xác
• ⚠️ Bất kỳ sai lệch nào so với kế hoạch
• ✗ Các vấn đề cần khắc phục
• Danh sách kiểm tra thủ công

Bước cuối cùng này phát hiện ra những thứ như:

• “Giai đoạn 2 đã thêm xác thực bổ sung (tốt!)”
• “Thiếu xử lý lỗi cho trường hợp biên X (cần sửa)”
• “Kiểm tra tự động vượt qua nhưng kiểm tra thủ công cho thấy vấn đề về UX”

Điểm mấu chốt: Xác thực là lưới an toàn của bạn. Nó đảm bảo bạn không bỏ sót bất cứ điều gì trước khi phát hành sản phẩm.

Vũ khí bí mật: Thư mục thoughts/

Trong suốt quy trình làm việc này, mọi thứ đều được lưu vào thư mục thoughts/ của tôi:

thoughts/
├── ashley/
│   ├── tickets/
│   │   └── eng_1478.md          # Ticket ban đầu từ Linear
│   └── notes/
│       └── notes.md              # Quan sát cá nhân và ghi chú nhanh
├── shared/
│   ├── research/
│   │   └── 2025-10-09_browser-page-management.md
│   ├── plans/
│   │   └── 2025-10-09-browser-page-management.md
│   └── prs/
│       └── pr_456_browser_pages.md
└── searchable/                    # Liên kết tượng trưng để tìm kiếm

Tại sao điều này lại mạnh mẽ?

1. Bộ nhớ bền vững: Nghiên cứu và kế hoạch tồn tại sau khi xóa ngữ cảnh
2. Kiến thức tái sử dụng: Các tính năng trong tương lai có thể tham khảo các quyết định trong quá khứ
3. Hợp tác nhóm: Nghiên cứu được chia sẻ giúp ích cho mọi người
4. Dấu vết kiểm toán: Tôi có thể xem tại sao các quyết định được đưa ra từ nhiều tháng trước

Thư mục searchable/ chứa các liên kết cứng đến tất cả các tài liệu, giúp các công cụ tìm kiếm của Claude dễ dàng tìm thấy ngữ cảnh liên quan khi cần.

Tại sao quy trình này hoạt động

Quy trình này hoạt động tốt vì nó phù hợp với cách làm việc tốt nhất của cả con người và AI:

Đối với AI (Claude):

• Mục tiêu rõ ràng: Mỗi giai đoạn có một công việc duy nhất
• Ngữ cảnh liên quan: Chỉ những gì cần thiết, không hơn
• Vòng lặp xác minh: Các kiểm tra tự động ngăn chặn sự lệch hướng
• Bộ nhớ trong tệp: Không cần phải “ghi nhớ” qua các phiên làm việc

Đối với con người (tôi và bạn):

• Tải nhận thức: Từng giai đoạn một là có thể quản lý được
• Sự tự tin: Kế hoạch vững chắc làm giảm sự không chắc chắn
• Chất lượng: Nhiều điểm xác thực giúp phát hiện sớm các vấn đề
• Tốc độ: Nghiên cứu song song và các giai đoạn rõ ràng = giao hàng nhanh hơn

Đối với codebase:

• Tài liệu: Mỗi tính năng đều có nghiên cứu + kế hoạch
• Tính nhất quán: Tuân theo các mẫu được phát hiện trong quá trình nghiên cứu
• Khả năng bảo trì: Các nhà phát triển trong tương lai hiểu được các quyết định
• Chất lượng: Xác thực có hệ thống = ít lỗi hơn

Mẹo

1. Đừng bỏ qua nghiên cứu

   Ngay cả khi bạn nghĩ rằng bạn biết codebase, hãy chạy nghiên cứu. Bạn sẽ khám phá ra các mẫu và trường hợp biên mà bạn đã quên.

2. Lặp lại kế hoạch nhiều hơn bạn nghĩ

   Các kế hoạch đầu tiên của tôi luôn quá nông cạn. Bây giờ tôi dành 30–45 phút để lập kế hoạch và lặp lại hơn 5 lần. Sự đầu tư thời gian này rất đáng giá.

3. Hãy khắt khe về ngữ cảnh

   Nếu ngữ cảnh đạt 60%, hãy dừng lại và tự hỏi: “Tôi có thể lưu gì vào một tệp và tham chiếu sau?” Thông thường, đó là các kết quả nghiên cứu hoặc chi tiết kế hoạch.

4. Kiểm tra thủ công rất quan trọng

   Các bài kiểm tra tự động phát hiện các vấn đề ở cấp độ mã nguồn. Kiểm tra thủ công phát hiện các vấn đề về UX, vấn đề hiệu suất và các trường hợp biên trong thế giới thực. Hãy làm cả hai.

5. Cập nhật kế hoạch trong quá trình triển khai

   Nếu bạn phát hiện ra điều gì đó mới trong Giai đoạn 2 ảnh hưởng đến Giai đoạn 3, hãy cập nhật tệp kế hoạch. Hãy giữ nó là nguồn thông tin chính xác duy nhất.

6. Sử dụng thư mục thoughts một cách nghiêm túc

   Mọi tài liệu nghiên cứu, kế hoạch và ghi chú đều được đưa vào thoughts/.

   Bạn của tương lai sẽ cảm ơn bạn của hiện tại :)

Muốn thử quy trình này? Đây là cách bắt đầu:

1. Thiết lập các tệp lệnh của bạn

Tạo thư mục .claude/commands/ (hoặc .cursor/commands/) với:

• research_codebase.md
• create_plan.md
• implement_plan.md
• validate_plan.md

Bạn có thể điều chỉnh các lệnh tôi đã chia sẻ hoặc tạo các biến thể của riêng mình.

2. Tạo thư mục thoughts được liên kết tượng trưng của bạn

mkdir -p thoughts/{personal,shared,searchable}
mkdir -p thoughts/shared/{research,plans,prs}
mkdir -p thoughts/personal/{tickets,notes}

3. Thử một tính năng với quy trình đầy đủ

Chọn một tính năng nhỏ. Đừng cố gắng học mọi thứ cùng một lúc:

1. Nghiên cứu → xóa ngữ cảnh
2. Lên kế hoạch (lặp lại!!!) → xóa ngữ cảnh
3. Triển khai (một giai đoạn) → xóa ngữ cảnh
4. Xác thực → xóa ngữ cảnh

Lặp lại~

4. Quan sát những gì hoạt động

Sau tính năng đầu tiên của bạn, hãy suy ngẫm:

• Bạn đã bị mắc kẹt ở đâu?
• Điều gì có thể rõ ràng hơn trong các lệnh của bạn?
• Bạn có duy trì ngữ cảnh <60% không?

Hãy lặp lại trên chính quy trình làm việc.

Kết luận, siêu kỹ năng: Kỹ thuật ngữ cảnh

Đây là những gì tôi thực sự đã học được: làm việc với AI không phải lúc nào cũng là đặt đúng câu hỏi, mà là thiết kế đúng ngữ cảnh.

Mỗi khi bạn gọi Claude, bạn đang tải một ngữ cảnh cụ thể vào bộ nhớ làm việc của nó. Giống như bạn sẽ không biên dịch toàn bộ codebase của mình để thay đổi một hàm, bạn không nên tải toàn bộ lịch sử dự án của mình để triển khai một tính năng.

Quy trình làm việc tôi đã chia sẻ là kỹ thuật ngữ cảnh trong thực tế:

• Nghiên cứu: Tải ngữ cảnh để hiểu
• Lên kế hoạch: Tải ngữ cảnh để thiết kế
• Triển khai: Tải ngữ cảnh để thực thi
• Xác thực: Tải ngữ cảnh để xác minh

Mỗi giai đoạn có một mục đích tập trung, tạo ra các sản phẩm và xóa đi để chuẩn bị cho giai đoạn tiếp theo.

Nếu bạn vẫn đang vật lộn với việc lập trình cùng AI và thất vọng vì đạt đến giới hạn ngữ cảnh, hãy thử quy trình này.

Bắt đầu nhỏ. Lặp lại. Biến nó thành của riêng bạn.

Cảm ơn bạn đã đọc,

— Ashley Brooke Ha

Có câu hỏi? Tôi rất muốn nghe từ bạn. Bạn có thể tìm thấy tôi tại [email protected].

Phụ lục: Tham khảo nhanh

Quy trình bốn giai đoạn

1. Nghiên cứu (@research_codebase.md)

   • Hiểu mã nguồn hiện có
   • Sinh ra các agent song song
   • Tạo tài liệu nghiên cứu
   • Xóa ngữ cảnh

2. Lên kế hoạch (@create_plan.md)

   • Tạo kế hoạch triển khai
   • Lặp lại hơn 5 lần
   • Xác định tiêu chí thành công
   • Xóa ngữ cảnh

3. Triển khai (@implement_plan.md)

   • Thực hiện từng giai đoạn một
   • Chạy xác minh tự động
   • Thực hiện kiểm tra thủ công
   • Xóa ngữ cảnh giữa các giai đoạn

4. Xác thực kế hoạch đã được triển khai (@validate_plan.md)

   • Xác minh có hệ thống
   • Tạo báo cáo xác thực
   • Đảm bảo không bỏ sót gì
   • Xóa ngữ cảnh

Quy tắc quản lý ngữ cảnh

• Không bao giờ vượt quá 60% dung lượng ngữ cảnh
• Xóa ngữ cảnh sau mỗi giai đoạn chính
• Lưu mọi thứ vào thư mục thoughts/ (npx humanlayer thoughts init)
• Tham chiếu tệp thay vì giữ trong bộ nhớ
• Sử dụng các agent song song để thu thập thông tin hiệu quả

Cấu trúc thư mục

thoughts/
├── [personal]/           # Ghi chú/ticket cá nhân của bạn
│   ├── tickets/
│   └── notes/
├── shared/               # Tài liệu chia sẻ trong nhóm
│   ├── research/
│   ├── plans/
│   └── prs/
└── searchable/          # Liên kết cứng để tìm kiếm

Tài liệu tham khảo & Ghi chú

Ghi chú

Tôi thực sự khuyên bạn nên xem các video và tài nguyên dưới đây vì Dex và nhóm tại humanlayer đã làm một công việc tuyệt vời trong việc tiên phong các lệnh và agent này. Vì vậy, một lần nữa XIN CẢM ƠN đội ngũ của họ❤

Video

• Advanced context engineering for coding agents
• 12-Factor Agents: Patterns of reliable LLM applications — Dex Horthy, HumanLayer
• Advanced Context Engineering for Agents

Bài blog & Bài viết

• The New Skill in AI is Not Prompting, It’s Context Engineering — Phil Schmid on Context Engineering
• Effective context engineering for AI agents — Anthropic on Context Engineering for AI Agents

Công cụ & Tài nguyên

• Humanlayer GitHub — Công cụ quản lý ngữ cảnh và thư mục thoughts