在AI工具普及的今天，C#程序员的工作方式正在发生巨变——过去需要手动敲200行的DTO映射代码，现在Copilot能一键生成；调试了两小时的NullReferenceException，ChatGPT一句话就能点出问题；甚至复杂的LINQ查询优化，AI也能给出可直接运行的方案。但现实是，很多开发者用AI反而更累：生成的代码看似正确却藏着隐蔽bug，风格和项目规范冲突，甚至被AI带偏方向导致返工。

作为每天用Copilot+ChatGPT开发C#项目的开发者，我总结出一套“高效且不翻车”的方法论：每天少写200行代码的核心不是“让AI写得多”，而是“让AI写得对”。本文从“AI最擅长的3类C#场景”入手，解剖“被AI带偏的3个典型陷阱”，最后提炼出经实战验证的“3个防偏技巧”，每个技巧都附具体提示词模板和代码案例，帮你真正让AI成为“提效助手”而非“埋坑队友”。

文章目录

一、先明确：AI最擅长替C#程序员干这3类活

不是所有代码都适合让AI写。根据我3个月的使用数据（每天记录AI生成代码量），Copilot+ChatGPT在以下3类场景效率最高，能覆盖日常开发60%的代码量，且出错率低于5%。

1. 重复性“体力活”代码：一键生成，减少机械劳动

C#开发中大量存在“格式固定、逻辑简单但必须写”的代码，比如DTO与实体的映射、构造函数、接口实现模板等。这些代码AI生成准确率接近100%，完全没必要手动写。

案例：用Copilot生成DTO与实体的映射代码

需求：有一个User实体类和UserDto，需要生成User转UserDto的ToDto()方法和反向的ToEntity()方法，包含10个属性（ID、Name、Age、Email等）。

手动写需要：逐个属性赋值，约20行代码，耗时3分钟，容易漏写属性。

Copilot生成：在代码中输入注释，Copilot自动补全：

// 实体类
public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
    public string Email { get; set; }
    public DateTime CreateTime { get; set; }
    // 其他6个属性...
}

// DTO类
public class UserDto
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
    public string Email { get; set; }
    public string CreateTimeStr { get; set; } // 实体中是DateTime，DTO中是格式化字符串
    // 其他6个属性...
}

// 输入以下注释，Copilot自动生成转换方法
public static class UserConverter
{
    // 将User转换为UserDto，CreateTime格式化为"yyyy-MM-dd HH:mm:ss"
    public static UserDto ToDto(this User user)
    {
        if (user == null)
            return null;
            
        return new UserDto
        {
            Id = user.Id,
            Name = user.Name,
            Age = user.Age,
            Email = user.Email,
            CreateTimeStr = user.CreateTime.ToString("yyyy-MM-dd HH:mm:ss"),
            // 自动补全其他6个属性的映射...
        };
    }
    
    // 将UserDto转换为User，CreateTimeStr解析为DateTime
    public static User ToEntity(this UserDto dto)
    {
        if (dto == null)
            return null;
            
        return new User
        {
            Id = dto.Id,
            Name = dto.Name,
            Age = dto.Age,
            Email = dto.Email,
            CreateTime = DateTime.ParseExact(dto.CreateTimeStr, "yyyy-MM-dd HH:mm:ss", null),
            // 自动补全其他6个属性的映射...
        };
    }
}

效率提升：3分钟的活→10秒，且Copilot会自动处理null判断和类型转换（如DateTime与字符串互转），比手动写更严谨。

2. 框架类“模板化”代码：按规范生成，避免记忆细节

C#开发依赖大量框架（ASP.NET Core、EF Core、AutoMapper等），这些框架的配置代码（如中间件注册、DbContext配置）有固定模板，但细节繁琐（比如EF Core的Fluent API写法）。AI对框架语法的记忆远胜人类，能生成符合最佳实践的代码。

案例：用ChatGPT生成EF Core的DbContext配置

需求：为User、Order、Product三个实体配置DbContext，包含表名映射、外键关系（1个User对应多个Order，1个Order包含多个Product）、索引（为User的Email建唯一索引，Order的CreateTime建普通索引）。

手动写需要：回忆Fluent API的语法（HasOne、WithMany、HasIndex等），处理外键命名规范，约40行代码，耗时10分钟，容易写错关系映射。

ChatGPT生成：用提示词“用EF Core 7的Fluent API配置DbContext，包含User、Order、Product三个实体，要求：1. User表名映射为T_Users，Order为T_Orders，Product为T_Products；2. User与Order是一对多（一个User有多个Order），Order与Product是多对多；3. 为User.Email建唯一索引，Order.CreateTime建普通索引；4. 包含注释说明每个配置的作用”，得到代码：

using Microsoft.EntityFrameworkCore;
using YourNamespace.Entities;

public class AppDbContext : DbContext
{
    public DbSet<User> Users { get; set; }
    public DbSet<Order> Orders { get; set; }
    public DbSet<Product> Products { get; set; }

    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options)
    {
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // 1. 表名映射
        modelBuilder.Entity<User>().ToTable("T_Users");
        modelBuilder.Entity<Order>().ToTable("T_Orders");
        modelBuilder.Entity<Product>().ToTable("T_Products");

        // 2. User与Order的一对多关系
        modelBuilder.Entity<Order>()
            .HasOne(o => o.User) // Order关联到User
            .WithMany(u => u.Orders) // User包含多个Order
            .HasForeignKey(o => o.UserId) // 外键为Order.UserId
            .OnDelete(DeleteBehavior.Cascade); // 级联删除：删除User时删除其所有Order

        // 3. Order与Product的多对多关系（通过中间表T_OrderProducts）
        modelBuilder.Entity<Order>()
            .HasMany(o => o.Products)
            .WithMany(p => p.Orders)
            .UsingEntity<Dictionary<string, object>>(
                "T_OrderProducts", // 中间表名
                j => j.HasOne<Product>().WithMany().HasForeignKey("ProductId"),
                j => j.HasOne<Order>().WithMany().HasForeignKey("OrderId")
            );

        // 4. 索引配置
        modelBuilder.Entity<User>()
            .HasIndex(u => u.Email)
            .IsUnique() // 唯一索引：确保Email不重复
            .HasDatabaseName("IX_Users_Email");

        modelBuilder.Entity<Order>()
            .HasIndex(o => o.CreateTime)
            .HasDatabaseName("IX_Orders_CreateTime"); // 普通索引：优化按时间查询
    }
}

效率提升：10分钟的活→1分钟，且代码包含表名规范、外键删除行为、索引命名等细节，符合EF Core最佳实践，比新手手动写更专业。

3. 调试类“问题定位”代码：快速定位bug，减少排查时间

C#开发中，NullReferenceException、InvalidCastException等错误调试耗时，尤其是复杂业务逻辑中的隐藏bug。AI能通过错误信息和代码片段快速定位问题，甚至生成修复方案。

案例：用ChatGPT调试“循环中修改集合导致的异常”

问题：运行以下代码时抛出“Collection was modified; enumeration operation may not execute”异常，但找不到原因：

public void UpdateOrders(List<Order> orders)
{
    foreach (var order in orders)
    {
        if (order.Status == OrderStatus.Canceled)
        {
            orders.Remove(order); // 移除已取消的订单
        }
    }
}

手动调试需要：回忆foreach循环的特性（枚举时不能修改集合），尝试改用for循环，耗时5分钟。

ChatGPT定位：将代码和异常信息发给ChatGPT，立即得到原因和修复方案：

// 异常原因：foreach循环使用的枚举器不允许在迭代时修改集合（添加/删除元素）
// 修复方案1：使用for循环从后往前遍历（避免索引偏移）
public void UpdateOrders(List<Order> orders)
{
    for (int i = orders.Count - 1; i >= 0; i--)
    {
        if (orders[i].Status == OrderStatus.Canceled)
        {
            orders.RemoveAt(i); // 按索引移除，无异常
        }
    }
}

// 修复方案2：遍历集合的副本（原集合可修改）
public void UpdateOrders(List<Order> orders)
{
    foreach (var order in orders.ToList()) // ToList()创建副本
    {
        if (order.Status == OrderStatus.Canceled)
        {
            orders.Remove(order); 
        }
    }
}

效率提升：5分钟的调试→30秒，且AI提供两种方案并解释适用场景（方案1适合大数据量，方案2代码简洁）。

二、警惕：被AI带偏的3个典型陷阱（附避坑示例）

AI生成的代码“看起来对”和“实际能用”是两回事。我统计过团队使用AI的错误案例，以下3类陷阱占比80%，每个陷阱都有明确的“识别方法”和“避坑要点”。

1. 陷阱1：代码“语法正确但逻辑错误”，隐藏业务bug

AI擅长模仿代码格式，但对复杂业务逻辑的理解经常出错——比如生成的权限校验代码漏了某个角色，计算金额时少算了折扣，这些问题编译能通过，但运行时会出业务故障。

案例：权限校验代码漏判管理员角色

需求：生成一个CheckPermission方法，要求“管理员（Admin）和超级管理员（SuperAdmin）可以访问，普通用户（User）拒绝访问”。

AI生成的问题代码：

// AI生成的代码（有逻辑漏洞）
public bool CheckPermission(string role)
{
    // 漏了Admin角色的判断
    return role == "SuperAdmin"; 
}

问题分析：AI只处理了“超级管理员”，漏了“管理员”，语法正确但不符合业务需求，上线后会导致管理员无法访问，属于严重bug。

识别方法：对涉及业务规则（权限、金额、状态流转）的AI代码，用“反向测试法”验证——输入边界值（如案例中的Admin角色），看是否符合预期。

避坑要点：在提示词中明确“业务规则”，并要求AI“列出所有判断条件”。例如：

生成CheckPermission方法，要求：
1. 输入参数为角色字符串（可能值："User"、"Admin"、"SuperAdmin"）；
2. 仅Admin和SuperAdmin返回true，User返回false；
3. 代码中必须显式列出所有角色的判断条件（不要用else省略）。

正确代码（按改进提示词生成）：

public bool CheckPermission(string role)
{
    // 显式列出所有角色的判断，无遗漏
    if (role == "Admin")
        return true;
    if (role == "SuperAdmin")
        return true;
    if (role == "User")
        return false;
    // 处理未定义的角色（额外的鲁棒性考虑）
    return false;
}

2. 陷阱2：代码“符合通用规范但不符合项目规范”，导致风格混乱

每个团队/项目都有自己的代码规范（如命名风格、异常处理方式、日志格式），AI默认生成的是“通用规范”，直接使用会导致项目代码风格混乱，增加维护成本。

案例：命名风格与项目规范冲突

项目规范：方法名必须用“动词+名词”形式（如GetUserById），参数名必须小写开头（如userId），但AI生成的代码用了其他风格：

AI生成的问题代码：

// 项目规范：方法名"动词+名词"，参数名小写开头
// AI生成：方法名名词+动词，参数名大写开头
public User UserGet(int UserId) 
{
    return _dbContext.Users.Find(UserId);
}

问题分析：AI生成的UserGet（名词+动词）和UserId（大写开头）不符合项目规范，若直接提交，会被代码审查打回返工。

识别方法：建立“项目规范清单”（命名、异常、日志等），用清单逐条检查AI生成的代码。

避坑要点：在提示词中“注入项目规范”，例如：

生成根据ID查询用户的方法，遵循以下项目规范：
1. 方法名格式：动词+名词（如GetUserById）；
2. 参数名：小写字母开头（如userId）；
3. 异常处理：若查询结果为null，抛出ArgumentNullException，消息包含"用户不存在"；
4. 必须包含XML注释。

正确代码（按规范提示词生成）：

/// <summary>
/// 根据用户ID查询用户信息
/// </summary>
/// <param name="userId">用户ID</param>
/// <returns>用户实体</returns>
/// <exception cref="ArgumentNullException">用户不存在时抛出</exception>
public User GetUserById(int userId)
{
    var user = _dbContext.Users.Find(userId);
    if (user == null)
    {
        throw new ArgumentNullException($"用户不存在，userId: {userId}");
    }
    return user;
}

3. 陷阱3：过度依赖AI导致“能力退化”，复杂逻辑写不出

长期依赖AI生成代码，会导致开发者对基础语法（如LINQ复杂查询、异步编程）的熟练度下降，遇到AI生成不了的复杂逻辑（如自定义分布式锁、并发控制）就束手无策。

案例：不会手写复杂LINQ查询

需求：从Order列表中查询“2023年下单、金额大于1000、用户等级为VIP，且至少包含3个商品”的订单，并按金额降序排列。

依赖AI的后果：开发者直接让AI生成，但AI生成的代码可能有性能问题（如多次遍历集合），而开发者因长期不手写LINQ，无法识别问题。

AI生成的低效代码：

// AI生成：多次遍历集合，性能差
var result = orders
    .Where(o => o.CreateTime.Year == 2023)
    .Where(o => o.Amount > 1000)
    .Where(o => o.User.Level == "VIP")
    .Where(o => o.Products.Count >= 3)
    .OrderByDescending(o => o.Amount)
    .ToList();

问题分析：虽然结果正确，但多个Where会导致多次遍历集合，大数据量下性能差（应合并为一个Where），而依赖AI的开发者无法优化。

避坑要点：“AI生成+手动优化”结合，对复杂逻辑先尝试手写核心部分，再用AI辅助完善。例如先手写合并条件的LINQ，再让AI补充注释和异常处理：

优化后的代码：

// 手动合并条件，单次遍历，性能更优
var vipHighValueOrders = orders
    .Where(o => 
        o.CreateTime.Year == 2023 && 
        o.Amount > 1000 && 
        o.User.Level == "VIP" && 
        o.Products.Count >= 3
    )
    .OrderByDescending(o => o.Amount)
    .ToList();

三、核心技巧：「不被AI带偏」的3个实战方法（附提示词模板）

经过3个月的迭代，我总结出一套“提效且安全”的AI使用方法论，核心是“人类主导，AI辅助”——用明确的规则约束AI，用验证机制过滤错误，确保AI始终服务于你的开发目标。

技巧1：先“拆解需求”再喂给AI，避免AI生成“大而全的垃圾”

AI对“模糊需求”的处理往往是“堆砌代码”，看似功能齐全却充满冗余。正确的做法是将需求拆解为“最小可执行单元”，逐个让AI生成，再手动拼接。

原理

复杂需求（如“开发一个用户管理模块”）包含多个子任务（实体定义、仓储接口、服务实现、API控制器），AI一次性生成会导致：

  • 代码冗余（包含不需要的功能）；
  • 逻辑混乱（子任务间依赖错误）；
  • 难以排查问题（出错后不知道哪部分有问题）。
实战案例：开发用户登录接口（拆解法）

需求：开发一个ASP.NET Core的用户登录接口，包含“参数验证→查询用户→密码校验→生成Token→返回结果”流程。

错误做法：直接让AI“生成用户登录接口”，得到一个包含所有逻辑的大方法，难以维护。

正确做法：拆解为5个子任务，逐个生成：

  1. 子任务1：定义登录请求参数类（LoginRequest）
    提示词：“定义ASP.NET Core的LoginRequest类，包含Username（必填，最大长度50）和Password（必填，最小长度6），用DataAnnotations做验证，包含XML注释。”
    AI生成：

    /// <summary>
/// 用户登录请求参数
/// </summary>
public class LoginRequest
{
    /// <summary>
    /// 用户名
    /// </summary>
    [Required(ErrorMessage = "用户名不能为空")]
    [MaxLength(50, ErrorMessage = "用户名最长50个字符")]
    public string Username { get; set; }

    /// <summary>
    /// 密码
    /// </summary>
    [Required(ErrorMessage = "密码不能为空")]
    [MinLength(6, ErrorMessage = "密码最短6个字符")]
    public string Password { get; set; }
}

  2. 子任务2：生成密码校验方法（VerifyPassword）
    提示词：“生成VerifyPassword方法，参数为明文密码和数据库存储的加密密码（SHA256加盐），返回bool表示是否匹配，包含盐值提取逻辑（加密密码格式：盐值+“:”+哈希值）。”
    AI生成：

    /// <summary>
/// 验证密码是否匹配（SHA256加盐加密）
/// </summary>
/// <param name="plainPassword">明文密码</param>
/// <param name="encryptedPassword">加密密码（格式：盐值:哈希值）</param>
/// <returns>是否匹配</returns>
public bool VerifyPassword(string plainPassword, string encryptedPassword)
{
    var parts = encryptedPassword.Split(':');
    if (parts.Length != 2)
        return false;

    string salt = parts[0];
    string storedHash = parts[1];
    string inputHash = ComputeSha256Hash(plainPassword + salt);

    return inputHash == storedHash;
}

// SHA256哈希计算（辅助方法）
private string ComputeSha256Hash(string rawData)
{
    using (SHA256 sha256Hash = SHA256.Create())
    {
        byte[] bytes = sha256Hash.ComputeHash(Encoding.UTF8.GetBytes(rawData));
        StringBuilder builder = new StringBuilder();
        foreach (byte b in bytes)
            builder.Append(b.ToString("x2"));
        return builder.ToString();
    }
}

  3. 按此方法生成剩余3个子任务（查询用户、生成Token、组装控制器），最后手动拼接为完整接口，逻辑清晰且易维护。

提示词模板（拆解法通用）
完成子任务：[具体子任务描述]
约束条件：
1. 仅实现当前子任务，不包含其他功能；
2. 代码必须可编译，包含必要的命名空间；
3. 处理边界情况（如null值、参数错误）。

技巧2：用“约束性提示词”框定范围，让AI生成“刚好需要的代码”

AI的“废话率”与提示词的“模糊度”成正比。通过“约束条件”（如技术栈版本、代码风格、性能要求）限制AI的输出范围，能大幅提升代码可用性。

原理

默认提示词（如“生成一个分页查询方法”）缺少关键约束，AI可能生成：

  • 不符合项目技术栈的代码（如用EF6而非EF Core）；
  • 包含过时API的代码（如用HttpClient而不用IHttpClientFactory）；
  • 忽略性能要求的代码（如全表查询而非分页）。
实战案例：生成EF Core分页查询（带约束）

需求：生成一个分页查询用户的方法，用EF Core 7，返回包含总条数和当前页数据的PagedResult，支持按Name排序，避免全表查询。

模糊提示词（效果差）：“生成用户分页查询方法”
AI可能生成无排序、无总条数的代码，甚至用Skip().Take()但忘记加OrderBy（EF Core中会报错）。

约束性提示词（效果好）：

生成用户分页查询方法，满足：
1. 技术栈：EF Core 7，异步方法（返回Task）；
2. 输入参数：pageIndex（从1开始）、pageSize、sortByAsc（是否升序）；
3. 返回类型：自定义PagedResult<User>，包含TotalCount（总条数）和Items（当前页数据）；
4. 性能要求：必须先排序（按Name）再分页，避免全表加载到内存；
5. 异常处理：捕获DbException并包装为自定义的DataAccessException。

AI生成的高质量代码：

/// <summary>
/// 分页查询用户（EF Core 7异步实现）
/// </summary>
/// <param name="pageIndex">页码（从1开始）</param>
/// <param name="pageSize">每页条数</param>
/// <param name="sortByAsc">是否按Name升序</param>
/// <returns>分页结果</returns>
public async Task<PagedResult<User>> GetUsersPagedAsync(int pageIndex, int pageSize, bool sortByAsc)
{
    try
    {
        // 计算跳过的条数（pageIndex从1开始）
        int skip = (pageIndex - 1) * pageSize;

        // 先查询总条数（避免全表加载）
        int totalCount = await _dbContext.Users.CountAsync();

        // 排序后分页（EF Core要求分页前必须排序）
        IQueryable<User> query = _dbContext.Users;
        query = sortByAsc 
            ? query.OrderBy(u => u.Name) 
            : query.OrderByDescending(u => u.Name);

        // 分页查询当前页数据
        var items = await query.Skip(skip).Take(pageSize).ToListAsync();

        return new PagedResult<User>
        {
            TotalCount = totalCount,
            Items = items
        };
    }
    catch (DbException ex)
    {
        // 包装为自定义异常
        throw new DataAccessException("查询用户分页失败", ex);
    }
}

// 分页结果类（AI自动生成）
public class PagedResult<T>
{
    public int TotalCount { get; set; }
    public List<T> Items { get; set; } = new List<T>();
}
提示词模板（约束性通用）
生成[功能描述]的代码，满足：
1. 技术栈：[具体版本，如ASP.NET Core 6、EF Core 7]；
2. 输入输出：[参数类型和返回值，如输入int userId，返回Task<User>]；
3. 关键要求：[性能、安全性、风格等，如“必须使用async/await”“避免SELECT *”]；
4. 异常处理：[具体异常类型和处理方式，如“捕获ArgumentNullException并抛出自定义异常”]。

技巧3：建立“三重验证机制”，过滤AI代码中的隐藏错误

即使是约束性提示词生成的代码，也必须经过验证才能提交。我总结的“三重验证”能覆盖99%的AI代码错误，确保上线安全。

验证流程（按优先级排序）
  1. 编译验证：用IDE编译代码，检查语法错误、命名空间缺失、类型不匹配等基础问题；
  2. 逻辑验证：写单元测试覆盖边界情况（如null输入、极限值、异常场景）；
  3. 规范验证：对照项目规范清单（命名、注释、架构）检查风格一致性。
实战案例：验证AI生成的“批量更新用户状态”方法

AI生成的代码如下，需通过三重验证：

// AI生成：批量更新用户状态
public void UpdateUserStatuses(List<int> userIds, UserStatus newStatus)
{
    var users = _dbContext.Users.Where(u => userIds.Contains(u.Id)).ToList();
    foreach (var user in users)
    {
        user.Status = newStatus;
    }
    _dbContext.SaveChanges();
}

  1. 编译验证：通过（无语法错误）；

  2. 逻辑验证：

    • 单元测试1：userIds为null→预期：抛出ArgumentNullException（实际：AI代码未处理，会抛出NullReferenceException，需修复）；
    • 单元测试2：userIds包含不存在的ID→预期：不影响其他用户（实际：正确，AI代码只更新存在的用户）；
    • 单元测试3：并发更新→预期：无死锁（实际：AI用了ToList()加载到内存，可能有并发问题，需改为Where().ToListAsync()并加锁）。

  3. 规范验证：

    • 项目要求“所有数据库操作必须异步”→AI用了同步的SaveChanges()，需改为SaveChangesAsync()；
    • 项目要求“方法必须包含XML注释”→AI未生成，需补充。

修复后的代码：

/// <summary>
/// 批量更新用户状态
/// </summary>
/// <param name="userIds">用户ID列表（不能为null）</param>
/// <param name="newStatus">新状态</param>
/// <returns>更新的用户数量</returns>
/// <exception cref="ArgumentNullException">userIds为null时抛出</exception>
public async Task<int> UpdateUserStatusesAsync(List<int> userIds, UserStatus newStatus)
{
    if (userIds == null)
        throw new ArgumentNullException(nameof(userIds), "用户ID列表不能为null");

    // 并发控制：使用悲观锁（根据项目并发策略调整）
    using (var transaction = await _dbContext.Database.BeginTransactionAsync())
    {
        var users = await _dbContext.Users
            .Where(u => userIds.Contains(u.Id))
            .ForUpdate() // 加锁防止并发更新
            .ToListAsync();

        foreach (var user in users)
        {
            user.Status = newStatus;
        }

        int updatedCount = await _dbContext.SaveChangesAsync();
        await transaction.CommitAsync();
        return updatedCount;
    }
}

四、总结：AI提效的本质是“人类专注于决策，AI专注于执行”

3个月的实践证明，C#程序员用AI每天少写200行代码完全可行，但前提是：你必须比AI更清楚“需要什么”和“如何验证”。

  • 对重复性代码（DTO映射、配置模板），让AI全权处理，节省机械劳动；
  • 对框架类代码（EF Core、ASP.NET Core），用约束性提示词引导AI生成符合规范的代码，再手动调整细节；
  • 对业务逻辑代码，先拆解需求，让AI生成局部实现，再通过三重验证确保逻辑正确；
  • 永远记住：AI是“执行工具”而非“决策者”，复杂场景的架构设计、性能优化、业务规则，最终仍需人类主导。

按这套方法，我的团队将AI融入C#开发流程后，平均开发效率提升40%，代码审查通过率从65%提升到92%，真正实现了“用AI提效而不被AI带偏”。现在，你可以从明天的DTO映射代码开始尝试——这是最简单的起点，也是感受AI提效的第一步。

------------伴代码深耕技术、连万物探索物联，我聚焦计算机、物联网与上位机领域，盼同频的你关注，一起交流成长～

# 人工智能 # c# # copilot
Logo
智能体开发者社区

中国智能体开发者社区，聚焦智能体与大模型开发，提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动，促进经验交流与协作，助力开发者快速构建创新智能应用。

更多推荐

cover

AI Agent 多角色协作总是重复问需求？用单一事实源串起文档、代码和测试

avatar 智能体开发者社区

零成本在终端里搭建 AI 编程智能体（Open Interpreter + 智谱免费模型）

作为嵌入式开发者，我一直在寻找一种能的 AI 工具。Claude Code 虽然强大，但需要付费 API 且国内网络不稳定；GitHub Copilot 依赖 IDE，不够灵活。后来我发现了——一个开源的终端 AI Agent，支持多种大模型后端。配合智谱 AI 的免费模型，我实现了，能读写文件、执行 Shell 命令、管理 QEMU 虚拟机，极大提升了内核和驱动学习效率。这篇文章记录完整的搭建过

avatar 智能体开发者社区

AIOps 项目做了一个 SRE 实验排障 AI Agent

of=/dev/sdX、iptables -F、nft flush ruleset、systemctl stop sshd|network|firewalld、chmod -R 777 /、chown -R、curl …| sh、wget …| bash、kill -9 1、shutdown、reboot、setenforce 0 等。项目代号 SRE Lab Doctor，仓库 andersth

avatar 智能体开发者社区