Năm Ứng Dụng AI Chỉ Biết "Có", Bỏ Qua Rủi Ro? Nhật Ký Hành Trình Phát Triển Phần Mềm Hoàn Toàn Mã Nguồn Mở

marsbit发布于2026-06-16更新于2026-06-16

文章摘要

Năm 2026, mã nguồn được tạo ra ngày càng nhanh nhưng lại được triển khai với ít sự kiểm tra hơn. Các rủi ro từ AI tạo code thường ẩn trong những đoạn mã trông có vẻ chính xác, có thể dẫn đến rò rỉ dữi liệu hoặc tổn thất tài sản. Sự cố cấu hình oracle cbETH của Moonwell là một ví dụ điển hình, khi một lỗi ngữ nghĩa giá trị vượt qua tất cả các bước kiểm tra và gây thiệt hại 1.78 triệu USD. Dự án mã nguồn mở **Narwhal AI Code Risks** từ Phòng thí nghiệm Narwhal, Đại học Bắc Kinh, tập hợp các rủi ro thành một "nhật ký hành trình" công khai, giúp nhà phát triển nhận diện sớm nguy cơ. Dự án phân loại thông tin thành ba lớp: `cases/` (sự kiện thực tế), `inferred/` (tín hiệu cảnh báo sớm) và `scenarios/` (kịch bản rủi ro điển hình), đồng thời chia rủi ro thành 7 loại chính: chuỗi cung ứng, lỗ hổng cấp mã, cấu hình đám mây & hạ tầng, rủi ro Agent, rủi ro lĩnh vực chuyên sâu, rủi ro sở hữu trí tuệ & tuân thủ, và yếu tố con người. Mục đích của dự án là biến các bài học từ sự cố thành tri thức có thể tái sử dụng, giúp cộng đồng tránh lặp lại sai lầm tương tự trong kỷ nguyên ứng dụng AI.

Rủi ro khi AI viết mã ẩn chứa trong những dòng code trông có vẻ đúng, có thể dẫn đến rò rỉ dữ liệu hoặc tổn thất tài sản. Dự án mã nguồn mở Narwhal AI Code Risks đã tổng hợp các trường hợp thực tế, tín hiệu cảnh báo sớm và các con đường rủi ro điển hình, giúp nhà phát triển nhận diện nguy cơ từ sớm, tránh lặp lại sai lầm.

Năm 2026, mã nguồn đang được tạo ra ngày càng nhanh, nhưng lại được triển khai với sự kiểm tra ngày càng ít.

Ngày càng nhiều khi nhu cầu của người dùng được đưa vào hộp thoại, AI đọc xong ngữ cảnh, bổ sung hàm, kéo các dependency, sửa cấu hình, rồi tiện tay tạo ra cả bài kiểm thử.

Khi kịp nhận ra, một đoạn mã đã nằm trong kho lưu trữ, chờ được hợp nhất.

Người dùng thậm chí đã hình thành thói quen mới: cứ để AI viết ra và chạy trước đã, có vấn đề thì xem lại chỗ nào cần sửa.

Nhưng trong thế giới phần mềm, thứ nguy hiểm nhất thường là những dòng mã trông có vẻ bình thường: cú pháp đúng, giao diện hợp lệ, kiểm thử vượt qua, chú thích hoàn hảo.

Thế nhưng nó vẫn có thể kéo về những gói thư viện không tồn tại, mở ra các quyền quá rộng, phơi bày cơ sở dữ liệu... thậm chí để một Agent có khả năng gọi trực tiếp các công cụ hệ thống, dưới tác động của prompt injection, mang dữ liệu nhạy cảm ra khỏi hệ thống nội bộ.

Thực sự nguy hiểm, không phải là khi đèn báo lỗi sáng đỏ. Mà là khi tất cả các đồng hồ đo rủi ro đều hiển thị bình thường.

Rủi ro từ việc AI viết mã, trước đây nằm rải rác khắp nơi: một bài blog bảo mật ẩn chứa một trường hợp, một Issue ghi lại một manh mối. Đến khi đội ngũ tiếp theo gặp phải vấn đề tương tự, họ lại phải bắt đầu lắp ghép nguồn gốc rủi ro từ đầu, lại tốn thêm thời gian và công sức để thực hiện các phép đo quy mô lớn trên mã nguồn.

Trong khi đó, Narwhal AI Code Risks vừa được Narwhal-Lab của Đại học Bắc Kinh công bố mã nguồn mở đã sắp xếp các mảnh thông tin này, phân loại theo ba kiểu: sự kiện thực tế, tín hiệu cảnh báo sớm và các con đường rủi ro điển hình, để các nhà nghiên cứu tham khảo.

Liên kết bài báo: https://github.com/Narwhal-Lab/Narwhal-aicode-risks

Khi 28 kiểm tra đều vượt qua, hệ thống vẫn chệch hướng

Manh mối đầu tiên là một Pull Request đã được hợp nhất, trong phần ký tên PR ghi rõ Claude Opus 4.6 và Copilot, cùng bốn nhà phát triển con người. 28 kiểm tra đều vượt qua: Không ai phát hiện ra vấn đề.

Sau đó, robot thanh lý chỉ mất vài phút để lấy đi tài sản thế chấp trị giá 1.778.044,83 USD.

Trong tệp cấu hình, giá của cbETH được đặt thành tỷ lệ quy đổi với ETH, khoảng 1,12 USD, thay vì giá thực tế gần 2.200 USD.

Một lỗi ngữ nghĩa giá trị đã vượt qua toàn bộ quy trình phát triển, kiểm tra và hợp nhất, cuối cùng biến thành tổn thất thực tế trong hệ thống tài chính. Đó chính là điểm gây chú ý nhất trong sự cố cấu hình oracle cbETH của Moonwell.

Vấn đề nằm ở chỗ trong mã nguồn không có lỗi cú pháp, và nhà phát triển con người cũng không ngay lập tức ngăn chặn quy trình bất thường. Ngược lại, nó trông rất hoàn chỉnh, rất suôn sẻ, đó chỉ là một lần giao hàng kỹ thuật bình thường.

Nhưng chính cái vẻ "bình thường" ngầm chảy này mới khiến nó trở thành ví dụ điển hình cho sự cố an ninh.

Rủi ro của AI Coding nằm ở chỗ nó không phải lúc nào cũng xuất hiện dưới dạng báo lỗi.

Nhiều khi, nó khoác lên mình vẻ ngoài của câu trả lời đúng, lặng lẽ đi vào quy trình kỹ thuật. Mã chạy được, kiểm tra vượt qua, PR có thể hợp nhất, nhưng ngữ nghĩa nghiệp vụ đã lệch khỏi thế giới thực.

Trong các dự án rủi ro thấp, sự lệch ngữ nghĩa này có thể chỉ là một lần làm lại công việc; nhưng trong các kịch bản nhạy cảm như tài chính, hệ thống dữ liệu doanh nghiệp, nó sẽ trực tiếp dẫn đến rò rỉ dữ liệu, phơi bày quyền hạn và tổn thất tài sản.

Khi AI tham gia viết mã, sửa cấu hình, làm review, thậm chí cùng ký tên vào PR, liệu chúng ta có đủ tự tin để biết mỗi lần chệch hướng xảy ra như thế nào không?

Tín hiệu xanh thông hành, không chiếu sáng mọi ngóc ngách

Giai đoạn đầu, AI giúp bạn viết mã chủ yếu dừng lại ở việc bổ sung cục bộ. Nếu viết sai cú pháp, trình biên dịch sẽ báo lỗi, unit test sẽ thất bại, quy trình CI sẽ chặn nó lại.

Ngày nay, AI Coding đã đi xa hơn trong khi sự giám sát lại chậm chạp chưa theo kịp.

Nó có thể đọc tệp, sửa cấu hình, cài đặt dependency, tạo script hạ tầng, cũng có thể thông qua Agent tự lập kế hoạch giữa nhiều nhiệm vụ.

AI không còn chỉ ngồi bên cạnh và đưa công cụ, nó bắt đầu bước vào chuỗi dài hơn của quy trình kỹ thuật phần mềm.

Ranh giới vốn rõ ràng trong kỹ thuật phần mềm, giờ bị AI Agent kết nối lại thành một con đường dài hơn, khó truy nguồn hơn.

Bản ghi rải rác, cần một nhật ký hành trình công cộng

Sự cố an ninh hiếm khi có kết luận đầy đủ ngay từ đầu. Một số sự kiện có đầy đủ bằng chứng, có thể đưa vào danh mục làm trường hợp thực tế; một số vẫn chỉ dừng lại ở ảnh chụp cộng đồng, thảo luận của nhà nghiên cứu hoặc công bố sơ bộ, chỉ phù hợp để tiếp tục theo dõi; một số khác không gắn với một sự kiện thực tế duy nhất, nhưng đã hình thành mô hình rõ ràng, phù hợp để dùng làm diễn tập trước.

Narwhal AI Code Risks phân chia tài liệu thành ba lớp: `cases/`, `inferred/` và `scenarios/`.

cases/ ghi lại các sự kiện thực tế đã có nguồn công khai và chuỗi bằng chứng hỗ trợ; inferred/ lưu trữ các tín hiệu cảnh báo sớm chưa hoàn toàn được xác minh, nhưng đáng để theo dõi liên tục; scenarios/ tổng hợp các kịch bản điển hình rủi ro đủ rõ ràng, tạm thời chưa gắn với một sự kiện duy nhất.

Nếu không có bản ghi công cộng như vậy, rủi ro từ AI Coding rất dễ trở thành ký ức ngắn hạn trên internet.

Hôm nay mọi người nhớ một tên gói nào đó, ngày mai thảo luận về một lần phơi bày dữ liệu, vài tháng sau lại bị che lấp bởi làn sóng công cụ mới. Đến khi vấn đề tương tự xuất hiện trở lại, đội ngũ vẫn như ruồi không đầu đâm vào vùng hàng hải rủi ro chưa biết.

Điều Narwhal AI Code Risks đang làm, chính là cố định lại những mảnh rủi ro rời rạc này, để người đến sau có thể lật đến cùng một trang.

Theo bảy loại chỉ mục, nhìn thấy con đường rủi ro đã đi qua

Vấn đề do AI viết mã mang lại, không chỉ nằm trong mã nguồn. Nó nằm trong dependency, trong quyền hạn, trong việc gọi công cụ của Agent, và hơn hết là trong cách con người tin tưởng vào đầu ra của AI.

Hiện tại, Narwhal AI Code Risks phân loại rủi ro thành 7 loại: chuỗi cung ứng, lỗ hổng cấp mã, cấu hình đám mây và hạ tầng, rủi ro Agent, rủi ro lĩnh vực chuyên sâu, rủi ro sở hữu trí tuệ và tuân thủ, cùng các yếu tố con người.

Trong rủi ro chuỗi cung ứng, AI có thể đề xuất các dependency không tồn tại. Trong lỗ hổng cấp mã, AI có thể viết lại các vấn đề như duyệt đường dẫn, thiếu kiểm tra đầu vào, xác thực quyền vào mã nghiệp vụ. Trong cấu hình đám mây và hạ tầng, AI có thể để cho mã chạy được mà đưa ra các quyền quá rộng, thùng lưu trữ công khai hoặc cổng bị phơi bày. Rủi ro Agent thì phức tạp hơn, không chỉ tạo văn bản, mà còn bắt đầu thực hiện hành động. Vật phẩm do AI tạo ra đang chôn giấu mối nguy hiểm cho hệ thống thực.

Động cơ AI đang nổ máy, và nhật ký hành trình vừa mới mở ra

Khi AI từng bước bước vào thế giới thực, việc phòng ngừa rủi ro liên quan không nên chỉ dừng lại ở tổng kết sau sự cố hoặc thảo luận rời rạc.

Điều thực sự quan trọng của Narwhal AI Code Risks, là biến các trường hợp rủi ro thành tri thức có thể tái sử dụng.

Nhà phát triển có thể dùng nó để nhận diện vấn đề tương tự; nhà nghiên cứu an ninh có thể lấy nó làm thư viện mẫu; nhà sản xuất công cụ có thể trích xuất quy tắc phát hiện và tiêu chuẩn đánh giá từ đó; cộng đồng mã nguồn mở cũng có thể tiếp tục bổ sung các trường hợp mới, bằng chứng mới và loại rủi ro mới.

Động cơ của AI đang gầm rú, mỗi lần chệch hướng cũng nên để lại tọa độ. Rủi ro không bao giờ biến mất vì bị lờ đi, nhưng kinh nghiệm có thể được ghi lại và truyền đi. Giá trị thực sự không phải là phát hiện một lỗ hổng, mà là để người đến sau không phải bước vào cùng một cái bẫy nữa.

Điều Narwhal AI Code Risks đang làm, chính là để lại cho thế giới phần mềm của năm ứng dụng AI một nhật ký hành trình mã nguồn mở.

Tài liệu tham khảo:

https://github.com/Narwhal-Lab/Narwhal-aicode-risks

Bài viết từ tài khoản công chúng WeChat "New Zhi Yuan", tác giả: LRST

相关问答

QDự án Narwhal AI Code Risks là gì và mục tiêu chính của nó là gì?

ADự án Narwhal AI Code Risks là một dự án mã nguồn mở từ Narwhal-Lab thuộc Đại học Bắc Kinh. Mục tiêu chính của nó là thu thập, phân loại và chia sẻ các trường hợp nghiên cứu về rủi ro bảo mật tiềm ẩn trong quá trình AI tạo mã code. Dự án giúp các nhà phát triển nhận diện sớm các mối nguy, tránh lặp lại sai lầm, bằng cách cung cấp các sự kiện thực tế, tín hiệu cảnh báo sớm và các kịch bản rủi ro điển hình.

QVụ việc Moonwell cbETH được nêu trong bài viết minh họa cho loại rủi ro nào khi AI viết code?

AVụ việc Moonwell cbETH minh họa cho rủi ro về 'lệch lạc ngữ nghĩa' (semantic deviation) hoặc lỗi logic trong mã code do AI tạo ra. Trong sự cố này, AI đã đặt một tỷ lệ chuyển đổi giá sai cho tài sản crypto (cbETH) trong cấu hình, dẫn đến tổn thất tài chính lớn. Điều đáng chú ý là mã code này không có lỗi cú pháp, đã vượt qua tất cả 28 bước kiểm tra và được hợp nhất vào dự án, cho thấy rủi ro khó phát hiện khi AI tạo ra mã 'trông có vẻ đúng' nhưng lại sai về mặt nghiệp vụ.

QDự án Narwhal AI Code Risks phân loại tài liệu rủi ro thành những loại nào?

ADự án phân loại tài liệu rủi ro thành ba loại chính trong cấu trúc thư mục: 1. `cases/`: Ghi lại các sự kiện thực tế đã có nguồn công khai và chuỗi bằng chứng đầy đủ. 2. `inferred/`: Lưu trữ các tín hiệu cảnh báo sớm chưa được xác minh hoàn toàn nhưng đáng để theo dõi. 3. `scenarios/`: Tổng hợp các kịch bản điển hình có đường đi rủi ro rõ ràng, chưa gắn với một sự kiện duy nhất.

QBài viết liệt kê những danh mục rủi ro chính nào mà AI viết code có thể gây ra?

ABài viết liệt kê 7 danh mục rủi ro chính: 1. Rủi ro chuỗi cung ứng (Supply Chain): Ví dụ AI đề xuất các phụ thuộc không tồn tại. 2. Lỗ hổng cấp độ mã (Code-level Vulnerabilities). 3. Cấu hình đám mây và hạ tầng (Cloud & Infra Config). 4. Rủi ro từ Agent AI. 5. Rủi ro theo lĩnh vực chuyên sâu (Vertical Domain Risks). 6. Rủi ro sở hữu trí tuệ và tuân thủ (IP & Compliance). 7. Rủi ro từ yếu tố con người (Human Factors).

QTại sao việc có một 'nhật ký hành trình' công khai như Narwhal AI Code Risks lại quan trọng đối với cộng đồng phát triển phần mềm trong kỷ nguyên AI?

AMột 'nhật ký hành trình' công khai như Narwhal AI Code Risks rất quan trọng vì nó biến những bài học từ các sự cố rải rác thành tri thức có thể tái sử dụng và chia sẻ. Nó giúp ngăn chặn việc cộng đồng lãng quên các rủi ro cũ khi xuất hiện các công cụ mới, cho phép các nhà phát triển, nhà nghiên cứu bảo mật và nhà cung cấp công cụ học hỏi từ quá khứ, xây dựng các biện pháp phát hiện tốt hơn, và tránh lặp lại cùng một sai lầm. Điều này tạo ra một cơ sở kiến thức chung, giúp định hướng phát triển phần mềm an toàn hơn trong kỷ nguyên AI.

你可能也喜欢

XRP Ledger 发布 3.2.0 版本升级并启用 XRPLd 新品牌名

XRP Ledger发布了3.2.0版本,这是对其底层区块链基础设施的一次重要升级。本次更新的核心是将运行网络的软件名称从“rippled”更名为“xrpld”,以更好地反映整个项目生态。 与此前侧重于前端功能的版本不同,3.2.0版本优先进行了后端升级和效率提升,旨在增强网络性能并为未来的扩展做准备。关键改进包括内存优化措施,预计可节省高达40%的服务器内存使用。 此次升级引入了名为“fixCleanup3_2_0”的修改,为单资产金库、借贷协议、权限系统、去中心化交易所、多用途代币和权限域等多个模块带来了安全性增强。开发团队还新增了不变性检查,以确保已删除账户不会在账本上留下不一致的数据,从而加强整个网络的完整性和可靠性。 对于开发者而言,新版本增加了一项重要功能:应用程序无需连接服务器即可检索XRP Ledger协议和服务器定义信息,这将极大便利钱包、区块链浏览器和API等的开发工作。 在可扩展性和稳定性方面,更新包括可配置的区块大小、通过nuDB实现的高效数据库存储,以及将gRPC服务器的TLS/双向TLS支持改为可选,以提升企业用户的性能和连接性。此外,默认对等端口从51235更改为2459,并修复了涉及自动做市商、支付、代币托管、多用途代币、订单簿和RPC等多个方面的问题。出于性能考虑,3.2.0版本暂时禁用了交易不变性检查,但开发团队表示这不会构成安全威胁。

TheNewsCrypto16分钟前

XRP Ledger 发布 3.2.0 版本升级并启用 XRPLd 新品牌名

TheNewsCrypto16分钟前

交易

现货
合约

热门文章

如何购买S

欢迎来到HTX.com!我们已经让购买Sonic(S)变得简单而便捷。跟随我们的逐步指南,放心开始您的加密货币之旅。第一步:创建您的HTX账户使用您的电子邮件、手机号码注册一个免费账户在HTX上。体验无忧的注册过程并解锁所有平台功能。立即注册第二步:前往买币页面,选择您的支付方式信用卡/借记卡购买:使用您的Visa或Mastercard即时购买Sonic(S)。余额购买:使用您HTX账户余额中的资金进行无缝交易。第三方购买:探索诸如Google Pay或Apple Pay等流行支付方法以增加便利性。C2C购买:在HTX平台上直接与其他用户交易。HTX场外交易台(OTC)购买:为大量交易者提供个性化服务和竞争性汇率。第三步:存储您的Sonic(S)购买完您的Sonic(S)后,将其存储在您的HTX账户钱包中。您也可以通过区块链转账将其发送到其他地方或者用于交易其他加密货币。第四步:交易Sonic(S)在HTX的现货市场轻松交易Sonic(S)。访问您的账户,选择您的交易对,执行您的交易,并实时监控。HTX为初学者和经验丰富的交易者提供了友好的用户体验。

2.6k人学过发布于 2025.01.15更新于 2026.06.02

如何购买S

相关讨论

欢迎来到HTX社区。在这里,您可以了解最新的平台发展动态并获得专业的市场意见。以下是用户对S(S)币价的意见。

活动图片