Claude viết mã luôn mắc lỗi? 12 quy tắc này đã giảm tỷ lệ sai sót xuống 3%

marsbitXuất bản vào 2026-05-14Cập nhật gần nhất vào 2026-05-14

Tóm tắt

**Tóm tắt: 12 Quy tắc trong CLAUDE.md Giảm Tỷ lệ Lỗi Code của Claude Xuống 3%** Bài viết mở rộng bộ quy tắc CLAUDE.md nổi tiếng của Andrej Karpathy và Forrest Chang, vốn có 4 quy tắc nhằm giảm lỗi phổ biến khi Claude viết code (như đưa ra giả định thầm lặng, kỹ sư quá mức). Sau 6 tuần thử nghiệm trên 30 kho code, tác giả nhận thấy 4 quy tắc gốc vẫn hiệu quả nhưng chưa đủ cho các tác vụ AI phức tạp hơn xuất hiện từ đầu năm 2026, như Agent đa bước, hook chain hay cộng tác đa kho code. Do đó, tác giả đề xuất thêm 8 quy tắc mới, nâng tổng số lên 12, để giải quyết các lỗi kiểu mới: 5. **Không để model làm công việc phi ngôn ngữ:** (VD: quyết định logic retry API). 6. **Đặt ngân sách token cứng:** Ngăn các vòng lặp debug tốn kém kéo dài vô hạn. 7. **Phơi bày xung đột, không dung hòa trung bình:** Tránh việc Claude trộn lẫn các phong cách/pattern mâu thuẫn trong code. 8. **Đọc trước, viết sau:** Hiểu code hiện có trước khi sửa/viết mới để tránh trùng lặp hoặc phá vỡ logic. 9. **Kiểm thử không phải tùy chọn, nhưng bản thân việc kiểm thử không phải mục tiêu:** Đảm bảo test xác thực logic thực sự, không chỉ đơn giản pass. 10. **Các thao tác chạy dài cần điểm kiểm tra (checkpoint):** Bảo vệ tiến trình trong các tác vụ đa bước, tránh mất toàn bộ nếu một bước lỗi. 11. **Quy ước có trước, sự mới mẻ có sau:** Tuân theo pattern hiện có của codebase thay vì giới thiệu quy ước mới gây rối. 12. **Thất bại phải rõ ràng, không thất bại thầm lặng:** Ưu tiên báo lỗi rõ ràng thay vì để code chạy "...

Lời biên tập: Vào tháng 1 năm 2026, lời phàn nàn của Andrej Karpathy về việc Claude viết mã đã chỉ ra một tệp có vẻ nhỏ nhưng cực kỳ quan trọng trong quy trình lập trình AI: CLAUDE.md. Forrest Chang sau đó đã tổng hợp những vấn đề này thành 4 quy tắc ứng xử, nhằm ràng buộc các lỗi phổ biến của Claude khi viết mã: giả định ngầm định, kỹ thuật hóa quá mức, làm hỏng mã không liên quan và thiếu tiêu chuẩn thành công rõ ràng.

Nhưng vài tháng sau, phạm vi sử dụng Claude Code đã không chỉ còn là "để mô hình viết một đoạn mã". Khi Agent đa bước, kích hoạt chuỗi hook, tải xung đột kỹ năng và cộng tác đa kho mã trở thành tiêu chuẩn, các kiểu thất bại mới cũng bắt đầu xuất hiện: mô hình mất kiểm soát trong nhiệm vụ dài, kiểm tra thông qua nhưng không xác minh logic thực sự, di chuyển hoàn thành nhưng bỏ qua lỗi một cách âm thầm, các phong cách mã khác nhau bị trộn lẫn sai lầm.

Tác giả bài viết này đã thử nghiệm 30 kho mã trong 6 tuần và thêm 8 quy tắc mới dựa trên 4 quy tắc gốc của Karpathy, nhằm bao quát các vấn đề mới khi lập trình AI chuyển từ việc bổ sung đơn lẻ sang hợp tác hóa Agent.

Dưới đây là bài viết gốc:

Cuối tháng 1 năm 2026, Andrej Karpathy đã đăng một chuỗi tweet, phàn nàn về cách Claude viết mã. Ông chỉ ra ba vấn đề điển hình: đưa ra giả định sai lầm mà không có giải thích, phức tạp hóa quá mức, và gây ra sự phá hủy không liên quan đối với mã lẽ ra không nên sửa đổi.

Forrest Chang thấy chuỗi tweet này, đã tổng hợp những lời phàn nàn thành 4 quy tắc ứng xử, viết vào một tệp CLAUDE.md riêng biệt và đăng lên GitHub. Dự án này đạt được 5.828 Star ngay trong ngày đầu tiên, được 60.000 lần lưu trong hai tuần, và hiện nay đã có 120.000 Star, trở thành kho mã đơn tệp phát triển nhanh nhất năm 2026.

Sau đó, tôi đã dùng 30 kho mã để kiểm tra nó trong 6 tuần.

4 quy tắc này thực sự hiệu quả. Xác suất xuất hiện lỗi trước đây khoảng 40%, trong các nhiệm vụ mà các quy tắc này phát huy tác dụng, đã giảm xuống dưới 3%. Nhưng vấn đề là, mẫu ban đầu này được tạo ra để giải quyết các lỗi xuất hiện khi Claude viết mã vào tháng 1.

Đến tháng 5 năm 2026, các vấn đề mà hệ sinh thái Claude Code phải đối mặt đã khác: các Agent xung đột lẫn nhau, kích hoạt chuỗi hook, xung đột tải kỹ năng, và gián đoạn quy trình công việc đa bước xuyên phiên.

Vì vậy, tôi đã thêm 8 quy tắc nữa. Dưới đây là bản CLAUDE.md đầy đủ với 12 quy tắc: lý do tại sao mỗi quy tắc đáng để thêm vào, và bản mẫu gốc của Karpathy sẽ thất bại thầm lặng ở 4 điểm nào.

Nếu bạn muốn bỏ qua giải thích và sao chép sử dụng ngay, tệp đầy đủ được đặt ở cuối bài.

Tại sao điều này quan trọng

CLAUDE.md của Claude Code là tệp bị đánh giá thấp nhất trong toàn bộ ngăn xếp công nghệ lập trình AI. Hầu hết các nhà phát triển thường mắc ba loại sai lầm:

Thứ nhất, coi nó như thùng rác sở thích, nhồi nhét tất cả thói quen của mình vào, cuối cùng phình to đến hơn 4000 token, tỷ lệ tuân thủ quy tắc giảm xuống 30%.

Thứ hai, hoàn toàn không sử dụng, mỗi lần đều nhắc lại. Điều này gây lãng phí token gấp 5 lần, và thiếu tính nhất quán giữa các phiên khác nhau.

Thứ ba, sao chép một mẫu rồi không bao giờ động đến nữa. Nó có thể hiệu quả trong hai tuần, nhưng khi kho mã thay đổi, nó sẽ thất bại mà bạn không hề hay biết.

Tài liệu chính thức của Anthropic nói rất rõ: về bản chất, CLAUDE.md chỉ mang tính khuyến nghị. Claude sẽ tuân theo nó khoảng 80% thời gian. Một khi vượt quá 200 dòng, tỷ lệ tuân thủ sẽ giảm rõ rệt vì các quy tắc quan trọng bị chìm trong tiếng ồn.

Mẫu của Karpathy đã giải quyết vấn đề này: một tệp, 65 dòng, 4 quy tắc. Đây là mức chuẩn tối thiểu.

Nhưng mức trần có thể cao hơn. Sau khi thêm 8 quy tắc dưới đây, nó không chỉ bao quát các vấn đề viết mã mà Karpathy phàn nàn vào tháng 1 năm 2026, mà còn cả các vấn đề điều phối Agent xuất hiện vào tháng 5 năm 2026 - những vấn đề chưa tồn tại khi mẫu gốc được viết.

4 quy tắc gốc

Nếu bạn chưa xem kho của Forrest Chang, hãy xem phiên bản cơ bản này trước:

Quy tắc 1: Suy nghĩ trước khi viết mã.

Không ngầm định giả định. Hãy nêu rõ giả định của bạn, phơi bày các điểm đánh đổi. Hỏi trước khi đoán. Khi có giải pháp đơn giản hơn, hãy chủ động đưa ra ý kiến phản đối.

Quy tắc 2: Ưu tiên đơn giản.
Sử dụng mã ít nhất có thể giải quyết vấn đề. Không thêm các tính năng tưởng tượng. Không thiết kế lớp trừu tượng cho mã một lần. Nếu một kỹ sư kỳ cựu cho rằng nó quá phức tạp, thì nên được đơn giản hóa.

Quy tắc 3: Sửa đổi như phẫu thuật.
Chỉ sửa phần phải sửa. Đừng tùy tiện "tối ưu hóa" mã, chú thích hoặc định dạng liền kề. Đừng tái cấu trúc thứ chưa hỏng. Giữ phong cách nhất quán với hiện có.

Quy tắc 4: Thực thi hướng mục tiêu.
Trước tiên định nghĩa tiêu chuẩn thành công, sau đó lặp đi lặp lại cho đến khi hoàn thành xác minh. Đừng bảo Claude phải làm từng bước như thế nào, mà hãy bảo nó kết quả thành công nên trông ra sao, để nó tự lặp.

4 quy tắc này có thể giải quyết khoảng 40% kiểu thất bại mà tôi thấy trong các phiên Claude Code không có giám sát. Khoảng 60% vấn đề còn lại ẩn trong các khoảng trống dưới đây.

8 quy tắc tôi đã thêm, và lý do

Mỗi quy tắc đều đến từ một khoảnh khắc thực tế: 4 quy tắc gốc của Karpathy đã không đủ dùng. Dưới đây tôi sẽ nói về bối cảnh đó trước, sau đó đưa ra quy tắc tương ứng.

Quy tắc 5: Đừng để mô hình làm công việc phi ngôn ngữ

Quy tắc của Karpathy không bao quát điểm này. Do đó, mô hình bắt đầu quyết định những vấn đề lẽ ra nên do mã xác định xử lý: có nên thử lại một lần gọi API không, làm thế nào để định tuyến một tin nhắn, khi nào nên nâng cấp xử lý. Kết quả là, mỗi tuần phán đoán đều khác nhau. Bạn nhận được một câu lệnh if-else không ổn định, tính phí theo mỗi token 0,003 đô la.

Khoảnh khắc đó là như thế này: có một đoạn mã gọi Claude để "phán đoán khi gặp lỗi 503 có nên thử lại không". Ban đầu nó chạy rất tốt, kéo dài hai tuần, sau đó đột nhiên trở nên không ổn định, vì mô hình bắt đầu coi thân yêu cầu như ngữ cảnh phán đoán. Chiến lược thử lại trở nên ngẫu nhiên, vì bản thân prompt đã ngẫu nhiên.

Quy tắc 6: Đặt ngân sách token cứng, không có ngoại lệ

CLAUDE.md không có ràng buộc ngân sách, tương đương với một tấm séc trắng. Mỗi vòng lặp đều có thể mất kiểm soát, biến thành một đợt đổ ngữ cảnh 50.000 token. Mô hình sẽ không tự dừng lại.

Khoảnh khắc đó là như thế này: một phiên gỡ lỗi kéo dài 90 phút. Mô hình cứ lặp đi lặp lại xung quanh cùng một thông báo lỗi 8KB, và dần quên mất mình đã thử các phương án sửa chữa nào. Cuối cùng, nó bắt đầu đề xuất các phương án mà tôi đã bác bỏ từ 40 tin nhắn trước. Nếu có ngân sách token, quá trình này đã nên bị chấm dứt ở phút thứ 12.

Quy tắc 7: Phơi bày xung đột, đừng dung hòa trung bình

Khi hai phần trong kho mã mâu thuẫn với nhau, Claude sẽ cố gắng làm hài lòng cả hai bên, kết quả viết ra một mớ mã không mạch lạc.

Khoảnh khắc đó là như thế này: một kho mã tồn tại hai mẫu xử lý lỗi, một mẫu là async/await kèm try/catch rõ ràng, mẫu kia là ranh giới lỗi toàn cục. Mã mới Claude viết ra sử dụng cả hai mẫu. Kết quả là xử lý lỗi bị làm hai lần. Tôi mất 30 phút mới hiểu tại sao lỗi bị nuốt hai lần.

Quy tắc 8: Đọc trước, viết sau

Quy tắc "Sửa đổi như phẫu thuật" của Karpathy bảo Claude đừng sửa mã liền kề. Nhưng nó không bảo Claude: trước tiên hãy hiểu mã liền kề. Không có điều này, Claude sẽ viết ra mã mới xung đột với mã hiện có cách đó 30 dòng.

Khoảnh khắc đó là như thế này: Claude thêm một hàm mới có chức năng hoàn toàn giống bên cạnh một hàm đã có, vì nó không đọc hàm cũ trước. Hai hàm làm cùng một việc. Nhưng do thứ tự import, hàm mới ghi đè hàm cũ, mà hàm cũ đã tồn tại như tiêu chuẩn duy nhất trên thực tế trong 6 tháng.

Quy tắc 9: Kiểm tra không phải tùy chọn, nhưng bản thân kiểm tra không phải mục tiêu

Quy tắc "Thực thi hướng mục tiêu" của Karpathy ngụ ý kiểm tra có thể là tiêu chuẩn thành công. Nhưng trong thực tế, Claude sẽ coi "kiểm tra thông qua" là mục tiêu duy nhất, từ đó viết ra một số mã có thể thông qua kiểm tra nông cạn, nhưng lại phá hỏng thứ khác.

Khoảnh khắc đó là như thế này: Claude viết 12 bài kiểm tra cho một hàm xác thực, tất cả đều thông qua. Nhưng logic xác thực trong môi trường sản xuất hỏng. Những bài kiểm tra đó chỉ xác minh hàm "trả về cái gì đó", chứ không xác minh nó có trả về đúng thứ không. Hàm có thể thông qua kiểm tra vì nó trả về một hằng số.

Quy tắc 10: Thao tác chạy lâu cần điểm kiểm tra

Mẫu của Karpathy mặc định tương tác là một lần. Nhưng công việc Claude Code thực tế thường là đa bước: tái cấu trúc xuyên 20 tệp, xây dựng tính năng trong một phiên, gỡ lỗi xuyên nhiều commit. Nếu không có điểm kiểm tra, một bước sai, toàn bộ tiến độ trước đó đều có thể mất.

Khoảnh khắc đó là như thế này: một nhiệm vụ tái cấu trúc 6 bước sai ở bước thứ 4. Khi tôi phát hiện, Claude đã tiếp tục hoàn thành bước 5 và 6 trên trạng thái sai. Thời gian tháo gỡ sửa chữa còn dài hơn thời gian làm lại toàn bộ nhiệm vụ. Nếu có điểm kiểm tra, bước 4 đã có thể phát hiện vấn đề.

Quy tắc 11: Quy ước ưu tiên hơn sáng tạo mới

Trong một kho mã đã có mẫu trưởng thành, Claude thích giới thiệu cách viết của riêng nó. Dù cách viết của nó "tốt hơn", nhưng việc giới thiệu mẫu thứ hai, bản thân nó đã tệ hơn bất kỳ mẫu đơn lẻ nào.

Khoảnh khắc đó là như thế này: Claude giới thiệu hooks vào một kho mã React dựa trên class component. Nó thực sự chạy được. Nhưng đồng thời nó phá hỏng mẫu kiểm tra vốn có của kho mã, vì những bài kiểm tra đó phụ thuộc vào componentDidMount. Cuối cùng mất nửa ngày mới xóa và viết lại nó.

Quy tắc 12: Thất bại rõ ràng, đừng thất bại thầm lặng

Thất bại đắt giá nhất của Claude, thường là những thất bại trông giống như thành công. Một hàm "chạy được", nhưng trả về dữ liệu sai; một lần migration "hoàn thành", nhưng bỏ qua 30 bản ghi; một bài kiểm tra "thông qua", nhưng chỉ vì bản thân khẳng định là sai.

Khoảnh khắc đó là như thế này: Claude nói một lần di chuyển cơ sở dữ liệu "hoàn thành thành công". Nhưng thực tế, nó đã thầm lặng bỏ qua 14% bản ghi kích hoạt xung đột ràng buộc. Hành vi bỏ qua được ghi vào nhật ký, nhưng không được phơi bày rõ ràng. 11 ngày sau, khi dữ liệu báo cáo bắt đầu bất thường, chúng tôi mới phát hiện vấn đề.

Kết quả dữ liệu

Tôi đã theo dõi cùng một nhóm 50 nhiệm vụ đại diện trong 6 tuần, bao phủ 30 kho mã, kiểm tra ba cấu hình.

Tỷ lệ lỗi đề cập đến: nhiệm vụ cần được sửa chữa hoặc viết lại, để khớp với ý định ban đầu. Các lỗi tính bao gồm: giả định sai lầm thầm lặng, kỹ thuật hóa quá mức, phá hủy không liên quan, thất bại thầm lặng, vi phạm quy ước, dung hòa xung đột, bỏ lỡ điểm kiểm tra.

Tỷ lệ tuân thủ đề cập đến: khi một quy tắc nào đó áp dụng, xác suất Claude sẽ áp dụng rõ ràng quy tắc đó là bao nhiêu.

Kết quả thực sự thú vị, không chỉ là tỷ lệ lỗi giảm từ 41% xuống 3%. Quan trọng hơn, từ 4 quy tắc mở rộng thành 12 quy tắc, hầu như không tăng gánh nặng tuân thủ, tỷ lệ tuân thủ chỉ từ 78% giảm xuống 76%, nhưng tỷ lệ lỗi lại giảm thêm 8 điểm phần trăm. Các quy tắc mới bổ sung bao phủ các kiểu thất bại mà 4 quy tắc cũ chưa xử lý, chúng không tranh giành cùng một ngân sách chú ý.

Mẫu của Karpathy sẽ thất bại thầm lặng ở những đâu

Ngay cả không thêm quy tắc mới, mẫu 4 quy tắc gốc cũng ít nhất không đủ dùng ở 4 điểm.

Thứ nhất, nhiệm vụ Agent chạy lâu.
Quy tắc của Karpathy chủ yếu nhắm vào thời điểm Claude đang viết mã. Nhưng khi Claude đang chạy một pipeline đa bước, điều gì sẽ xảy ra? Mẫu gốc không có quy tắc ngân sách, không có quy tắc điểm kiểm tra, cũng không có quy tắc "thất bại lớn tiếng". Do đó pipeline sẽ dần trôi dạt.

Thứ hai, tính nhất quán đa kho mã.
"Khớp phong cách hiện có" mặc định chỉ có một phong cách. Nhưng trong một monorepo có 12 dịch vụ, Claude phải chọn khớp phong cách nào. Quy tắc gốc không bảo nó cách chọn. Do đó nó hoặc chọn ngẫu nhiên, hoặc trộn lẫn trung bình một vài phong cách.

Thứ ba, chất lượng kiểm tra.
"Thực thi hướng mục tiêu" sẽ coi "kiểm tra thông qua" là thành công, nhưng không nói rõ bản thân kiểm tra phải có ý nghĩa. Kết quả là, Claude viết ra một số bài kiểm tra hầu như không xác minh gì, nhưng những bài kiểm tra này khiến nó lầm tưởng mình rất tự tin.

Thứ tư, sự khác biệt giữa môi trường sản xuất và giai đoạn nguyên mẫu.
Cùng 4 quy tắc, có thể ngăn mã sản xuất bị kỹ thuật hóa quá mức, nhưng cũng có thể làm chậm phát triển nguyên mẫu. Vì đôi khi giai đoạn nguyên mẫu thực sự cần 100 dòng giàn giáo thăm dò, trước tiên tìm ra hướng đi. Quy tắc "Ưu tiên đơn giản" của Karpathy dễ kích hoạt quá mức trong mã giai đoạn đầu.

8 quy tắc mới bổ sung này không nhằm thay thế 4 quy tắc gốc của Karpathy, mà là sửa chữa các khoảng trống của chúng: mẫu gốc tương ứng với bối cảnh viết mã kiểu tự động bổ sung vào tháng 1 năm 2026; còn đến tháng 5 năm 2026, Claude Code đã bước vào môi trường cộng tác đa bước, đa kho mã do Agent điều khiển, vấn đề mà hai bên đối mặt không giống nhau.

Những phương pháp nào không hiệu quả

Trước khi quyết định cuối cùng 12 quy tắc này, tôi cũng đã thử một số phương án khác.

Thêm các quy tắc tôi thấy trên Reddit / X.
Trong số đó, hầu hết hoặc chỉ lặp lại 4 quy tắc gốc của Karpathy bằng cách diễn đạt khác, hoặc là các quy tắc đặc thù miền không thể khái quát hóa, như "luôn sử dụng class Tailwind". Cuối cùng đều xóa.

Vượt quá 12 quy tắc.
Tôi kiểm tra tối đa đến 18 quy tắc. Sau khi vượt quá 14 quy tắc, tỷ lệ tuân thủ từ 76% giảm xuống 52%. Giới hạn 200 dòng là có thật. Sau khi vượt quá độ dài này, Claude sẽ bắt đầu khớp mẫu thành "ở đây có quy tắc", thay vì thực sự đọc từng quy tắc.

Quy tắc phụ thuộc vào sự tồn tại của một số công cụ.
Ví dụ: "luôn sử dụng eslint", một khi dự án không cài đặt eslint, quy tắc này sẽ thất bại, và là thất bại thầm lặng. Sau đó tôi đổi nó thành cách diễn đạt không phụ thuộc công cụ cụ thể, ví dụ đổi "sử dụng eslint" thành "tuân theo phong cách đã được thực thi trong kho mã".

Đặt ví dụ trong CLAUDE.md, thay vì quy tắc.
Ví dụ chiếm nhiều ngữ cảnh hơn quy tắc. Ba ví dụ tiêu thụ ngữ cảnh, tương đương với khoảng 10 quy tắc, và Claude dễ quá khớp với ví dụ. Quy tắc là trừu tượng, ví dụ là cụ thể. Vì vậy, nên sử dụng quy tắc.

"Cẩn thận một chút" "suy nghĩ nghiêm túc" "tập trung một chút".
Đây đều là tiếng ồn. Tỷ lệ tuân thủ loại chỉ dẫn này giảm xuống khoảng 30%, vì chúng không thể kiểm tra được. Sau đó tôi thay thế chúng bằng các quy tắc mệnh lệnh cụ thể hơn, như "nêu rõ giả định".

Bảo Claude hãy giống như "kỹ sư kỳ cựu".
Điều này không hiệu quả. Claude vốn đã nghĩ mình giống kỹ sư kỳ cựu. Vấn đề thực sự không nằm ở chỗ nó có nghĩ như vậy không, mà ở chỗ nó có thực thi như vậy không. Quy tắc mệnh lệnh có thể thu hẹp khoảng cách này, từ ngữ nhắc danh tính không thể.

Bản CLAUDE.md đầy đủ 12 quy tắc

Dưới đây là phiên bản đầy đủ có thể sao chép dán sử dụng ngay.

Tạm thời không thể hiển thị nội dung này bên ngoài tài liệu Feishu

Lưu nó thành CLAUDE.md trong thư mục gốc kho mã. Dưới 12 quy tắc này, thêm các quy tắc chuyên biệt dự án, như ngăn xếp kỹ thuật, lệnh kiểm tra, mẫu lỗi, v.v. Tổng thể không vượt quá 200 dòng, sau khi vượt quá, tỷ lệ tuân thủ quy tắc sẽ giảm rõ rệt.

Cách cài đặt

Chỉ hai bước:

1. Nối 4 quy tắc cơ bản của Karpathy vào CLAUDE.md của bạn
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md


2. Dán các quy tắc 5–12 trong bài viết này vào bên dưới

Lưu tệp trong thư mục gốc kho mã. Ký hiệu >> ở đây rất quan trọng, tác dụng của nó là nối thêm vào CLAUDE.md đã có, thay vì ghi đè các quy tắc chuyên biệt dự án bạn đã viết.

Mô hình tâm trí

CLAUDE.md không phải danh sách mong muốn, mà là một hợp đồng hành vi, dùng để bịt các kiểu thất bại cụ thể bạn đã quan sát thấy.

Mỗi quy tắc nên trả lời một câu hỏi: Nó ngăn chặn lỗi gì?

4 quy tắc của Karpathy, ngăn các kiểu thất bại ông thấy vào tháng 1 năm 2026: giả định thầm lặng, kỹ thuật hóa quá mức, phá hủy không liên quan, tiêu chuẩn thành công yếu. Chúng là cơ sở, đừng bỏ qua.

8 quy tắc tôi thêm, ngăn các kiểu thất bại mới xuất hiện sau tháng 5 năm 2026: vòng lặp Agent không ràng buộc ngân sách, nhiệm vụ đa bước không điểm kiểm tra, kiểm tra trông có vẻ kiểm tra nhưng thực ra không kiểm tra logic then chốt, và vấn đề đóng gói thất bại thầm lặng thành thành công thầm lặng. Chúng là bản vá tăng cường.

Tất nhiên, hiệu quả cụ thể khác nhau tùy người. Nếu bạn không chạy pipeline đa bước, quy tắc 10 không quá quan trọng với bạn. Nếu kho mã của bạn chỉ có một phong cách thống nhất, và đã được lint thực thi, quy tắc 11 là thừa. Sau khi đọc 12 quy tắc này, giữ lại các quy tắc thực sự tương ứng với lỗi bạn thực tế mắc phải, xóa phần còn lại.

Một bản CLAUDE.md 6 quy tắc được tùy chỉnh cho kiểu thất bại thực tế, tốt hơn một bản có 12 quy tắc, trong đó 6 quy tắc bạn không bao giờ dùng đến.

Kết luận

Tweet của Karpathy vào tháng 1 năm 2026, về bản chất là một lời phàn nàn. Forrest Chang biến nó thành 4 quy tắc. Cuối cùng, 12 vạn nhà phát triển đã Star kết quả này. Và trong số đó, hầu hết mọi người, ngày nay vẫn chỉ sử dụng 4 quy tắc đó.

Mô hình đã tiến bộ, hệ sinh thái cũng đã thay đổi. Agent đa bước, kích hoạt chuỗi hook, tải kỹ năng, cộng tác đa kho mã - những thứ này đều không tồn tại khi Karpathy viết tweet đó. 4 quy tắc cũ không giải quyết những vấn đề này. Chúng không sai, mà là không đầy đủ.

Thêm 8 quy tắc. 6 tuần thời gian, kiểm tra bao phủ 30 kho mã. Tỷ lệ lỗi từ 41% giảm xuống 3%.

Tối nay hãy lưu bài viết này, dán 12 quy tắc này vào CLAUDE.md của bạn. Nếu nó giúp bạn tránh được một tuần vòng vo với Claude, hãy chia sẻ.

Tiền kỹ thuật số thịnh hành

ctr
CitreaCTR
wstusdt
wrapped stUSDTWSTUSDT
apr
aPrioriAPR
ctx
Cryptex FinanceCTX
audio
AudiusAUDIO
comp
CompoundCOMP
mantra
MantraMANTRA
waxl
AxelarWAXL
bill
Billions NetworkBILL
pyth
PYTH (Pyth)PYTH
rune
THORChainRUNE
velodrome
Velodrome FinanceVELODROME
brev
BrevisBREV
cake
PancakeSwapCAKE
jst
JUSTJST

Câu hỏi Liên quan

QAndrej Karpathy đã phàn nàn về những vấn đề cụ thể nào khi Claude viết code vào tháng 1 năm 2026?

AAndrej Karpathy đã phàn nàn về ba loại vấn đề chính: Claude đưa ra giả định sai mà không giải thích, làm phức tạp hóa vấn đề một cách không cần thiết, và gây ra những thay đổi phá vỡ không liên quan đến các phần code không nên bị chạm tới.

Q4 quy tắc gốc trong mẫu CLAUDE.md của Karpathy (do Forrest Chang tổng hợp) là gì và chúng nhắm giải quyết vấn đề gì?

A4 quy tắc gốc là: 1. Suy nghĩ trước khi code (tránh giả định thầm lặng). 2. Ưu tiên sự đơn giản (dùng ít code nhất có thể). 3. Sửa đổi có chọn lọc như phẫu thuật (chỉ sửa phần cần thiết). 4. Thực thi hướng mục tiêu (xác định tiêu chí thành công rõ ràng). Chúng nhằm giải quyết các lỗi phổ biến như giả định sai, kỹ thuật quá mức, phá vỡ code không liên quan và thiếu tiêu chuẩn thành công rõ ràng.

QTác giả bài viết đã thêm 8 quy tắc mới dựa trên những thất bại nào mà mẫu cũ không bao phủ?

A8 quy tắc mới giải quyết các thất bại mới nảy sinh trong môi trường lập trình AI hiện đại, như: Mô hình đưa ra quyết định phi ngôn ngữ (Rule 5), vòng lặp Agent không có ngân sách token (Rule 6), dung hòa mâu thuẫn thay vì làm rõ (Rule 7), không đọc code hiện có trước khi viết (Rule 8), viết test vô nghĩa chỉ để đạt mục tiêu (Rule 9), tác vụ dài hạn thiếu điểm kiểm tra (Rule 10), phá vỡ quy ước codebase (Rule 11), và thất bại trong im lặng (Rule 12).

QKết quả thử nghiệm 6 tuần với 12 quy tắc cho thấy điều gì về tỷ lệ tuân thủ và tỷ lệ lỗi?

ASau 6 tuần thử nghiệm trên 30 codebase, việc áp dụng 12 quy tắc đã giảm tỷ lệ lỗi từ 41% xuống còn 3%. Đáng chú ý, tỷ lệ tuân thủ (khi quy tắc áp dụng) chỉ giảm nhẹ từ 78% (với 4 quy tắc) xuống 76% (với 12 quy tắc), cho thấy các quy tắc mới bổ sung phạm vi lỗi mới mà không làm quá tải sự chú ý của mô hình.

QTheo bài viết, có những phương pháp nào đã được thử nghiệm nhưng không hiệu quả khi xây dựng CLAUDE.md?

AMột số phương pháp không hiệu quả bao gồm: Thêm quá nhiều quy tắc (trên 14 quy tắc làm giảm tỷ lệ tuân thủ), đưa ra các quy tắc phụ thuộc vào công cụ cụ thể (như 'luôn dùng eslint'), sử dụng nhiều ví dụ thay vì quy tắc trừu tượng, dùng chỉ dẫn chung chung như 'cẩn thận một chút', và bảo Claude 'hãy như một kỹ sư kỳ cựu' thay vì đưa ra các quy tắc hành động cụ thể.

Nội dung Liên quan

Michael Saylor: 'Chúng tôi chưa bao giờ nói rằng sẽ không bao giờ bán Bitcoin'

Chủ tịch MicroStrategy, Michael Saylor, đã làm rõ rằng công ty chưa từng cam kết sẽ không bao giờ bán Bitcoin (BTC) của mình, mặc dù kỳ vọng vẫn sẽ là nhà mua ròng BTC trong dài hạn. Tuyên bố được đưa ra sau các báo cáo về việc MicroStrategy nhận được một sự cho phép mới để bán BTC trị giá tới 5 tỷ USD. Saylor phủ nhận thông tin này, nói rằng sự cho phép không phải là mới và đã được công bố từ ngày 29/6 như một phần trong hệ thống quản lý vốn của công ty. Ông nhấn mạnh rằng thỏa thuận này cho phép việc bán BTC vì các mục đích cụ thể nhưng không bắt buộc công ty phải bán. MicroStrategy không công bố bất kỳ sự cho phép mới nào và vẫn dự kiến tiếp tục là bên mua ròng Bitcoin. Saylor cũng nói thêm rằng chương trình kiếm tiền từ Bitcoin của MicroStrategy không yêu cầu bán tài sản BTC và công ty chưa từng chính thức thông qua chính sách "sẽ không bao giờ bán BTC".

cryptonews.ru26 phút trước

Michael Saylor: 'Chúng tôi chưa bao giờ nói rằng sẽ không bao giờ bán Bitcoin'

cryptonews.ru26 phút trước

«Cưa mùa hè» tiếp tục: Phá vỡ $67,000 sẽ là khởi đầu cho đà tăng của Bitcoin

Giá Bitcoin giảm xuống 62.217 USD vào ngày 1/8, tiếp tục giai đoạn củng cố trong phạm vi 58.000 - 67.000 USD kể từ đầu tháng 6. Thị trường đang chia rẽ về hướng đi tiếp theo. Các nhà phân tích kỹ thuật chỉ ra hai kịch bản chính. Một số, như Crypto Candy và Jelle, dự báo khả năng giảm về vùng 60.000 USD nếu giá không vượt lên trên 66.000 USD, đồng thời mô tả thị trường đang trong giai đoạn "củng cát mùa hè" kéo dài. Ngược lại, những người khác như Daan Crypto Trades và Roman nhấn mạnh rằng việc phá vỡ mốc 67.000 USD với khối lượng giao dịch đủ mạnh có thể mở đường cho đợt tăng mạnh lên vùng 70.000 - 80.000 USD. Về góc nhìn dài hạn, nhà phân tích Gert van Lagen xem đây là giai đoạn tích lũy, với Bitcoin đang thử nghiệm đường viền cổ của mô hình "cốc và tay cầm" hình thành suốt 7 năm. Ông cũng lưu ý rằng các nhà đầu tư nắm giữ dài hạn vẫn kiên định, không chịu bán tháo. Tóm lại, thị trường Bitcoin đang trong thời kỳ tích lũy quan trọng, với hai mức giá then chốt là 60.000 USD và 67.000 USD. Việc phá vỡ một trong hai mức này sẽ định hình xu hướng chính tiếp theo.

cryptonews.ru40 phút trước

«Cưa mùa hè» tiếp tục: Phá vỡ $67,000 sẽ là khởi đầu cho đà tăng của Bitcoin

cryptonews.ru40 phút trước

Tuần tới cần chú ý｜Đạo luật CLARITY dự kiến được biểu quyết tại Thượng viện; SpaceX, Circle công bố báo cáo tài chính (3.8-9.8)

**Tóm tắt các sự kiện quan trọng từ ngày 3 đến 9 tháng 8:** **Tuần tới sẽ có nhiều sự kiện đáng chú ý trong lĩnh vực tiền điện tử và công nghệ:** * **Pháp luật & Quy định:** Dự luật CLARITY Act, nhằm thiết lập khung quy định liên bang cho tiền điện tử, có khả năng được đưa ra biểu quyết toàn thể tại Thượng viện Mỹ vào tuần tới. Các nhà đàm phán cần đạt được 60 phiếu ủng hộ trước ngày 7/8. * **Báo cáo tài chính:** Nhiều công ty lớn sẽ công bố báo cáo tài chính quý II/2026, bao gồm **SpaceX (ngày 4/8)**, công ty khai thác Bitcoin **Hut 8 (ngày 4/8)**, **Circle (ngày 5/8)** và công ty khai thác liên quan đến gia đình Trump là **American Bitcoin (ngày 3/8)**. * **Sự kiện SpaceX:** Bên cạnh báo cáo tài chính, cổ phiếu của SpaceX sẽ bắt đầu được mở khóa từ ngày 6/8, với đợt đầu tiên có thể lên tới 12% tổng số cổ phiếu. * **Dữ liệu kinh tế:** Báo cáo việc làm phi nông nghiệp (Non-Farm) quan trọng của Mỹ cho tháng 7 sẽ được công bố vào ngày 7/8. * **Cập nhật công nghệ:** * **XRP Ledger:** Phiên bản mới xrpld 3.3.0 với 5 tính năng mới dự kiến phát hành vào tuần tới. * **Grok:** Elon Musk thông báo Grok 4.6 dự kiến ra mắt vào khoảng ngày 7/8. * **Bitcoin:** Việc gửi tín hiệu bắt buộc cho BIP-110 sẽ bắt đầu vào khoảng ngày 8/8. * **Ngừng hoạt động:** Một số dịch vụ tiền điện tử sẽ ngừng hoạt động vào ngày 3/8, bao gồm công cụ theo dõi danh mục DeFi **Zapper** và ví **Ctrl Wallet**. * **Niêm yết & Hủy niêm yết:** Sàn Upbit Hàn Quốc sẽ hủy niêm yết token AQT và AERGO từ ngày 3/8. Trong khi đó, công ty robot **宇树科技 (Unitree Robotics)** sẽ tiến hành thăm dò giá ban đầu cho đợt IPO trên STAR Market vào ngày 5/8.

marsbit1 giờ trước

Tuần tới cần chú ý｜Đạo luật CLARITY dự kiến được biểu quyết tại Thượng viện; SpaceX, Circle công bố báo cáo tài chính (3.8-9.8)

marsbit1 giờ trước

Cổ phiếu giảm mạnh hơn cả tiền điện tử, tiền đã đi đâu?

Tác giả: Cathy, Baihua Blockchain Vào ngày 28 và 29 tháng 7, chỉ số Kospi của Hàn Quốc hai ngày liên tiếp kích hoạt cơ chế ngắt mạch (circuit breaker), một sự kiện chưa từng có trong lịch sử. Cổ phiếu bán dẫn toàn cầu lao dốc, đặc biệt là SK Hynix – cổ phiếu trọng số lớn nhất, giảm khoảng 23% sau hai ngày. Điều trớ trêu là, trong khi thị trường chứng khoán biến động dữ dội như tiền mã hóa, Bitcoin lại thể hiện sự ổn định tương đối, phục hồi gần 15% từ mức thấp tháng 7. Bài viết phân tích rằng đợt sụt giảm này không phải là sự hoảng loạn toàn thị trường, mà là một cuộc "giải tỏa đòn bẩy cưỡng chế" nhắm vào các giao dịch đầu cơ tập trung nhất, như lĩnh vực bán dẫn và AI. Các yếu tố thúc đẩy bao gồm báo cáo lợi nhuận không đạt kỳ vọng của SK Hynix, sự cạnh tranh tiềm tàng từ Trung Quốc, và việc Ngân hàng Nhật Bản tăng lãi suất khiến các khoản đầu tư mang theo (carry trade) bằng Yên phải thoái vốn. Vậy tiền từ thị trường chứng khoán có chảy vào Bitcoin không? Câu trả lời là không. Bitcoin "kháng sụt giảm" vì nó đã trải qua đợt bán tháo lớn vào tháng 5 và tháng 6, với dòng tiền ròng rút kỷ lục khỏi các ETF Bitcoin Mỹ. Tiền thực sự đã chảy vào tài sản an toàn truyền thống như vàng, với hệ số tương quan giữa Bitcoin và vàng giảm xuống mức rất thấp. Điều này cho thấy Bitcoin hiện được coi là tài sản mạo hiểm để tìm kiếm lợi nhuận, chứ không phải nơi trú ẩn an toàn. Bài viết kết luận rằng để dòng tiền thực sự quay trở lại với Bitcoin, cần ba điều kiện: áp lực thanh khoản toàn cầu giảm bớt, Fed cắt giảm lãi suất mà không gây ra suy thoái, và Đạo luật CLARITY được thông qua để giải tỏa lo ngại về quy định. Mặc dù tiền chưa chảy vào, Bitcoin đã tự định vị mình như một tài sản có tương quan thấp với Nasdaq, một đặc điểm mà các tổ chức có thể tìm kiếm để đa dạng hóa danh mục đầu tư sau cú sốc AI.

marsbit1 giờ trước

Cổ phiếu giảm mạnh hơn cả tiền điện tử, tiền đã đi đâu?

marsbit1 giờ trước

Đối thoại với Ray Dalio: Chúng ta đang ở trong bong bóng AI, 1% danh mục đầu tư của tôi là Bitcoin

Ray Dalio, người sáng lập Bridgewater Associates, trong một cuộc phỏng vấn đã chỉ ra rằng thế giới hiện tại đang trong một "AI bubble" (bong bóng AI) cổ điển, với giá tài sản tăng vọt và đầu cơ quá mức. Ông cảnh báo bong bóng có thể vỡ do lãi suất tăng, nguồn cung cổ phiếu dư thừa hoặc khi nhà đầu tư cần tiền mặt trả nợ, dẫn đến suy thoái kinh tế. Đồng thời, Dalio mô tả một "chu kỳ lớn" kéo dài khoảng 80 năm, bao gồm ba động lực chồng chéo: khoảng cách giàu nghèo và xung đột nội bộ, thâm hụt ngân sách chính phủ khổng lồ và thay đổi địa chính trị. Ông nhấn mạnh rằng Mỹ và Anh đang đối mặt với những thách thức trong giai đoạn suy yếu này. Để bảo vệ của cải, Dalio khuyến nghị đa dạng hóa danh mục đầu tư với cổ phiếu, vàng, trái phiếu, bất động sản thay vì chỉ giữ tiền mặt. Ông tiết lộ khoảng 1% danh mục của mình là Bitcoin, nhưng vẫn ưa chuộng vàng vật chất hơn do tính ổn định và vai trò tiền tệ dự trữ. Về tác động của AI, Dalio cho rằng nó không chỉ thay thế lao động chân tay mà còn cả tư duy, làm trầm trọng thêm bất bình đẳng thu nhập. Con người cần phát huy trí tuệ cảm xúc và trực giác - những thứ AI chưa có - và học cách hợp tác với AI. Cuối cùng, ông phân tích những rủi ro của thuế tài sản và xu hướng thế giới có thể trở nên "khu vực hóa" hơn, với các khối như châu Mỹ và châu Á - Thái Bình Dương, trong bối cảnh sự thống trị toàn cầu của Mỹ đang suy yếu.

marsbit5 giờ trước

Đối thoại với Ray Dalio: Chúng ta đang ở trong bong bóng AI, 1% danh mục đầu tư của tôi là Bitcoin

marsbit5 giờ trước

Giao dịch

Giao ngay

Bài viết Nổi bật

AGENT S là gì

Agent S: Tương Lai của Tương Tác Tự Động trong Web3 Giới thiệu Trong bối cảnh không ngừng phát triển của Web3 và tiền điện tử, các đổi mới đang liên tục định nghĩa lại cách mà cá nhân tương tác với các nền tảng kỹ thuật số. Một dự án tiên phong như vậy, Agent S, hứa hẹn sẽ cách mạng hóa tương tác giữa con người và máy tính thông qua khung tác nhân mở của nó. Bằng cách mở đường cho các tương tác tự động, Agent S nhằm đơn giản hóa các nhiệm vụ phức tạp, cung cấp các ứng dụng chuyển đổi trong trí tuệ nhân tạo (AI). Cuộc khám phá chi tiết này sẽ đi sâu vào những phức tạp của dự án, các tính năng độc đáo của nó và những tác động đối với lĩnh vực tiền điện tử. Agent S là gì? Agent S đứng vững như một khung tác nhân mở đột phá, được thiết kế đặc biệt để giải quyết ba thách thức cơ bản trong việc tự động hóa các nhiệm vụ máy tính: Thu thập Kiến thức Cụ thể theo Miền: Khung này học một cách thông minh từ nhiều nguồn kiến thức bên ngoài và kinh nghiệm nội bộ. Cách tiếp cận kép này giúp nó xây dựng một kho lưu trữ phong phú về kiến thức cụ thể theo miền, nâng cao hiệu suất của nó trong việc thực hiện nhiệm vụ. Lập Kế Hoạch Qua Các Tầm Nhìn Nhiệm Vụ Dài Hạn: Agent S sử dụng lập kế hoạch phân cấp tăng cường kinh nghiệm, một cách tiếp cận chiến lược giúp phân chia và thực hiện các nhiệm vụ phức tạp một cách hiệu quả. Tính năng này nâng cao đáng kể khả năng quản lý nhiều nhiệm vụ con một cách hiệu quả và hiệu suất. Xử Lý Các Giao Diện Động, Không Đều: Dự án giới thiệu Giao Diện Tác Nhân-Máy Tính (ACI), một giải pháp đổi mới giúp nâng cao tương tác giữa các tác nhân và người dùng. Sử dụng các Mô Hình Ngôn Ngữ Lớn Đa Phương Thức (MLLMs), Agent S có thể điều hướng và thao tác các giao diện người dùng đồ họa đa dạng một cách liền mạch. Thông qua những tính năng tiên phong này, Agent S cung cấp một khung vững chắc giải quyết các phức tạp liên quan đến việc tự động hóa tương tác giữa con người với máy móc, mở ra nhiều ứng dụng trong AI và hơn thế nữa. Ai là Người Tạo ra Agent S? Mặc dù khái niệm về Agent S là hoàn toàn đổi mới, thông tin cụ thể về người sáng lập vẫn còn mơ hồ. Người sáng lập hiện vẫn chưa được biết đến, điều này làm nổi bật giai đoạn sơ khai của dự án hoặc sự lựa chọn chiến lược để giữ kín các thành viên sáng lập. Bất chấp sự ẩn danh, sự chú ý vẫn tập trung vào khả năng và tiềm năng của khung này. Ai là Các Nhà Đầu Tư của Agent S? Vì Agent S còn tương đối mới trong hệ sinh thái mã hóa, thông tin chi tiết về các nhà đầu tư và những người tài trợ tài chính của nó không được ghi chép rõ ràng. Sự thiếu vắng thông tin công khai về các nền tảng đầu tư hoặc tổ chức hỗ trợ dự án dấy lên câu hỏi về cấu trúc tài trợ và lộ trình phát triển của nó. Hiểu biết về sự hỗ trợ là rất quan trọng để đánh giá tính bền vững và tác động tiềm năng của dự án. Agent S Hoạt Động Như Thế Nào? Tại cốt lõi của Agent S là công nghệ tiên tiến cho phép nó hoạt động hiệu quả trong nhiều bối cảnh khác nhau. Mô hình hoạt động của nó được xây dựng xung quanh một số tính năng chính: Tương Tác Giống Như Con Người: Khung này cung cấp lập kế hoạch AI tiên tiến, cố gắng làm cho các tương tác với máy tính trở nên trực quan hơn. Bằng cách bắt chước hành vi của con người trong việc thực hiện nhiệm vụ, nó hứa hẹn nâng cao trải nghiệm người dùng. Ký Ức Tường Thuật: Được sử dụng để tận dụng các trải nghiệm cấp cao, Agent S sử dụng ký ức tường thuật để theo dõi lịch sử nhiệm vụ, từ đó nâng cao quy trình ra quyết định của nó. Ký Ức Tình Huống: Tính năng này cung cấp cho người dùng hướng dẫn từng bước, cho phép khung này cung cấp hỗ trợ theo ngữ cảnh khi các nhiệm vụ diễn ra. Hỗ Trợ OpenACI: Với khả năng chạy cục bộ, Agent S cho phép người dùng duy trì quyền kiểm soát đối với các tương tác và quy trình làm việc của họ, phù hợp với tinh thần phi tập trung của Web3. Tích Hợp Dễ Dàng với Các API Bên Ngoài: Tính linh hoạt và khả năng tương thích với nhiều nền tảng AI khác nhau đảm bảo rằng Agent S có thể hòa nhập liền mạch vào các hệ sinh thái công nghệ hiện có, làm cho nó trở thành lựa chọn hấp dẫn cho các nhà phát triển và tổ chức. Những chức năng này cùng nhau góp phần vào vị trí độc đáo của Agent S trong không gian tiền điện tử, khi nó tự động hóa các nhiệm vụ phức tạp, nhiều bước với sự can thiệp tối thiểu của con người. Khi dự án phát triển, các ứng dụng tiềm năng của nó trong Web3 có thể định nghĩa lại cách mà các tương tác kỹ thuật số diễn ra. Thời Gian Phát Triển của Agent S Sự phát triển và các cột mốc của Agent S có thể được tóm tắt trong một dòng thời gian nêu bật các sự kiện quan trọng của nó: 27 tháng 9, 2024: Khái niệm về Agent S được ra mắt trong một bài nghiên cứu toàn diện mang tên “Một Khung Tác Nhân Mở Sử Dụng Máy Tính Như Một Con Người,” trình bày nền tảng cho dự án. 10 tháng 10, 2024: Bài nghiên cứu được công bố công khai trên arXiv, cung cấp một cái nhìn sâu sắc về khung và đánh giá hiệu suất của nó dựa trên tiêu chuẩn OSWorld. 12 tháng 10, 2024: Một video trình bày được phát hành, cung cấp cái nhìn trực quan về khả năng và tính năng của Agent S, thu hút thêm sự quan tâm từ người dùng và nhà đầu tư tiềm năng. Những dấu mốc trong dòng thời gian không chỉ minh họa sự tiến bộ của Agent S mà còn chỉ ra cam kết của nó đối với sự minh bạch và sự tham gia của cộng đồng. Những Điểm Chính Về Agent S Khi khung Agent S tiếp tục phát triển, một số thuộc tính chính nổi bật, nhấn mạnh tính đổi mới và tiềm năng của nó: Khung Đổi Mới: Được thiết kế để cung cấp cách sử dụng máy tính trực quan giống như tương tác của con người, Agent S mang đến một cách tiếp cận mới cho việc tự động hóa nhiệm vụ. Tương Tác Tự Động: Khả năng tương tác tự động với máy tính thông qua GUI đánh dấu một bước tiến tới các giải pháp tính toán thông minh và hiệu quả hơn. Tự Động Hóa Nhiệm Vụ Phức Tạp: Với phương pháp mạnh mẽ của nó, nó có thể tự động hóa các nhiệm vụ phức tạp, nhiều bước, làm cho các quy trình nhanh hơn và ít sai sót hơn. Cải Tiến Liên Tục: Các cơ chế học tập cho phép Agent S cải thiện từ các trải nghiệm trước đó, liên tục nâng cao hiệu suất và hiệu quả của nó. Tính Linh Hoạt: Khả năng thích ứng của nó trên các môi trường hoạt động khác nhau như OSWorld và WindowsAgentArena đảm bảo rằng nó có thể phục vụ một loạt các ứng dụng rộng rãi. Khi Agent S định vị mình trong bối cảnh Web3 và tiền điện tử, tiềm năng của nó để nâng cao khả năng tương tác và tự động hóa quy trình đánh dấu một bước tiến quan trọng trong công nghệ AI. Thông qua khung đổi mới của mình, Agent S minh họa cho tương lai của các tương tác kỹ thuật số, hứa hẹn một trải nghiệm liền mạch và hiệu quả hơn cho người dùng trên nhiều ngành công nghiệp khác nhau. Kết luận Agent S đại diện cho một bước nhảy vọt táo bạo trong sự kết hợp giữa AI và Web3, với khả năng định nghĩa lại cách chúng ta tương tác với công nghệ. Mặc dù vẫn còn ở giai đoạn đầu, những khả năng cho ứng dụng của nó là rộng lớn và hấp dẫn. Thông qua khung toàn diện của mình giải quyết các thách thức quan trọng, Agent S nhằm đưa các tương tác tự động lên hàng đầu trong trải nghiệm kỹ thuật số. Khi chúng ta tiến sâu hơn vào các lĩnh vực tiền điện tử và phi tập trung, các dự án như Agent S chắc chắn sẽ đóng một vai trò quan trọng trong việc định hình tương lai của công nghệ và sự hợp tác giữa con người với máy tính.

Tổng lượt xem 1.1kXuất bản vào 2025.01.14Cập nhật vào 2025.01.14

AGENT S là gì

Làm thế nào để Mua S

Chào mừng bạn đến với HTX.com! Chúng tôi đã làm cho mua Sonic (S) trở nên đơn giản và thuận tiện. Làm theo hướng dẫn từng bước của chúng tôi để bắt đầu hành trình tiền kỹ thuật số của bạn.Bước 1: Tạo Tài khoản HTX của BạnSử dụng email hoặc số điện thoại của bạn để đăng ký tài khoản miễn phí trên HTX. Trải nghiệm hành trình đăng ký không rắc rối và mở khóa tất cả tính năng. Nhận Tài khoản của tôiBước 2: Truy cập Mua Crypto và Chọn Phương thức Thanh toán của BạnThẻ Tín dụng/Ghi nợ: Sử dụng Visa hoặc Mastercard của bạn để mua Sonic (S) ngay lập tức.Số dư: Sử dụng tiền từ số dư tài khoản HTX của bạn để giao dịch liền mạch.Bên thứ ba: Chúng tôi đã thêm những phương thức thanh toán phổ biến như Google Pay và Apple Pay để nâng cao sự tiện lợi.P2P: Giao dịch trực tiếp với người dùng khác trên HTX.Thị trường mua bán phi tập trung (OTC): Chúng tôi cung cấp những dịch vụ được thiết kế riêng và tỷ giá hối đoái cạnh tranh cho nhà giao dịch.Bước 3: Lưu trữ Sonic (S) của BạnSau khi mua Sonic (S), lưu trữ trong tài khoản HTX của bạn. Ngoài ra, bạn có thể gửi đi nơi khác qua chuyển khoản blockchain hoặc sử dụng để giao dịch những tiền kỹ thuật số khác.Bước 4: Giao dịch Sonic (S)Giao dịch Sonic (S) dễ dàng trên thị trường giao ngay của HTX. Chỉ cần truy cập vào tài khoản của bạn, chọn cặp giao dịch, thực hiện giao dịch và theo dõi trong thời gian thực. Chúng tôi cung cấp trải nghiệm thân thiện với người dùng cho cả người mới bắt đầu và người giao dịch dày dạn kinh nghiệm.

Tổng lượt xem 2.1kXuất bản vào 2025.01.15Cập nhật vào 2026.06.02

Làm thế nào để Mua S

Thảo luận

Chào mừng đến với Cộng đồng HTX. Tại đây, bạn có thể được thông báo về những phát triển nền tảng mới nhất và có quyền truy cập vào thông tin chuyên sâu về thị trường. Ý kiến ​​của người dùng về giá của S (S) được trình bày dưới đây.

活动图片

Danh mục Phổ biếnright-arrow

Thẻ Nổi bậtright-arrow