配置大模型，这里用的是国内兼容OpenAI接口的API

在三线小城当技术Leader的AI编程探索实录

坐标某三线城市，目前在这家规模不大的互联网公司做技术负责人。熟悉我的朋友都知道，我是个坚定的Mac党，平时在家远程办公，手里这台M2 Max的MacBook Pro就是我的生产力主力。不过做咱们这行的，总有些历史包袱，所以旁边还常年开着个Windows虚拟机，专门用来测一些奇葩的兼容性问题，或者跑跑只有Windows环境才有的老旧内部工具。

最近这大半年，大模型火得一塌糊涂。我们老板虽然身在三线城市，但心在硅谷，天天在群里发各种“AI赋能”、“降本增效”的文章，话里话外就一个意思：技术部能不能用AI把研发成本砍一半？说实话，刚听到这要求时，我差点把手里的冰美式泼屏幕上。咱们团队统共就十来号人，平时连个像样的下午茶都没有，还砍一半？但吐槽归吐槽，活还得干。为了保住大家的饭碗，也为了让自己能多点时间研究我喜欢的云原生和K8s，我决定硬着头皮搞一波技术探索，把AI真正落地到咱们的研发流程里。

其实也不用老板逼，我自己早就受够了现在的研发效率。上个月我们接了个内部老系统重构的活儿，外加两条新业务线的CRUD。产品那边天天催进度，那个姓王的产品经理最爱说的一句话就是“这个需求很简单，怎么要做一周”。我真是想顺着网线过去把他的机械键盘塞他嘴里。

开发资源捉襟见肘，几个后端兄弟天天加班到晚上十点，写出来的代码可想而知。测试那边的李妹子更是怨声载道，上周五晚上快下班时，她直接在群里开喷：“这提测质量也太差了吧！空指针异常都能带到测试环境，你们写代码不用脑子的吗？”当时看着群里的消息，我真是头大如斗，当时真的想砸电脑。

痛定思痛，我意识到靠堆人力和加班已经解决不了问题了。既然打不过，就加入。我决定引入AI辅助工具，先从个人开发提效，再到团队流程改造，一步步来。

要提升个人编码效率，代码补全和生成工具是首选。之前团队里有人用过GitHub Copilot，但咱们这网络环境大家都懂，加上有时候它对国内一些特定的业务语境理解不到位，经常生成一些牛头不对马嘴的代码。后来我深度试用了腾讯云的 CodeBuddy，发现这玩意儿在IDE里的集成体验相当丝滑，而且对中文语境和国内常用技术栈的理解明显更接地气。

拿我最熟悉的K8s来说吧。以前写个Deployment和Service的yaml，虽然闭着眼睛都能敲出来，但遇到一些复杂的探针配置、资源限制或者亲和性调度，总得去翻文档或者找以前的模板抄。现在有了 CodeBuddy，体验完全不一样了。

比如上周我要给一个核心微服务配置K8s的HPA（水平自动伸缩），我直接在IDE里用自然语言描述：“帮我写一个K8s HPA的yaml，针对名为order-service的Deployment，CPU目标使用率70%，最小副本数2，最大副本数10，并且加上自定义指标基于QPS的伸缩。”

CodeBuddy 瞬间就给我生成了一段非常规范的yaml：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  # 注意：自定义指标需要集群安装了Prometheus Adapter
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "1000"

它不仅把基础的CPU指标写对了，还非常贴心地加上了基于QPS的自定义指标配置，甚至连注释都帮我写好了，提醒我需要安装Prometheus Adapter。这种懂行的AI，用起来就是顺手。现在团队里写CRUD、写单测、甚至写正则表达式，大家都习惯先让 CodeBuddy 跑个初稿，自己再微调，效率肉眼可见地提升了。

但光靠代码补全和单点生成，还不足以解决我们“提测质量差”和“需求理解不到位”的系统性问题。为了解决这些痛点，我把目光投向了多智能体（Multi-Agent）框架，最终选了微软的 AutoGen。

为什么选 AutoGen？因为我们的研发流程不仅仅是“写代码”这一个动作，它包含了需求分析、架构设计、编码、Code Review、测试用例生成等多个环节。AutoGen 的核心魅力在于它能让多个大模型扮演不同的角色，通过对话和协作来完成复杂任务。

我当时的设想是：搞一个“产品经理Agent”来细化需求，一个“架构师Agent”来设计接口，一个“Coder Agent”来写代码，最后再来一个“QA Agent”来生成测试用例并审查代码。听起来很美好，但实操起来简直是踩坑大全。

刚开始配置 AutoGen 的时候，我差点被气死。我让“产品经理Agent”和“架构师Agent”讨论一个订单退款的需求。结果这俩货不知道怎么回事，陷入了死循环。“产品经理”一直强调“用户体验要好，退款要秒到账”，“架构师”则死磕“分布式事务一致性，必须用TCC”。俩人在那里疯狂对话，Token狂烧，最后直接触发了API的Rate Limit。当时看着控制台疯狂滚动的报错日志，我真是哭笑不得。

后来我仔细研究了 AutoGen 的文档，发现关键在于 Prompt 的设计以及对话终止条件（termination）的控制。你不能让Agent无限制地聊下去，必须给它们设定明确的边界和输出格式。

我重新调整了策略，把 AutoGen 的应用场景聚焦在“代码审查与单测生成”上。我配置了两个Agent：一个是 ReviewAgent，专门负责挑刺；另一个是 CoderAgent，负责根据Review意见修改代码并生成单测。

下面是我简化后的 AutoGen 核心配置代码，大家可以参考一下：

import autogen

config_list = [
    {
        "model": "gpt-4-1106-preview", # 或者用其他兼容模型
        "api_key": "sk-xxxxxxxx",
        "base_url": "https://api.your-proxy.com/v1"
    }
]

llm_config = {"config_list": config_list, "temperature": 0.2}

# 1. 定义代码审查Agent (ReviewAgent)
reviewer = autogen.AssistantAgent(
    name="Code_Reviewer",
    system_message="""你是一个严苛的高级Java代码审查专家。
    你的任务是审查代码，指出潜在的Bug、性能问题、不符合规范的地方。
    特别关注空指针异常、并发安全和SQL注入。
    如果代码没问题，请回复"APPROVED"。如果有问题，请给出具体的修改建议。""",
    llm_config=llm_config,
)

# 2. 定义编码Agent (CoderAgent)
coder = autogen.AssistantAgent(
    name="Coder",
    system_message="""你是一个资深的Java开发工程师。
    你需要根据Code_Reviewer的反馈修改代码，并为修改后的核心逻辑编写JUnit 5单元测试。
    代码必须包含详细的注释。当Reviewer回复"APPROVED"时，输出最终的完整代码。""",
    llm_config=llm_config,
)

# 3. 定义用户代理（模拟人类介入）
user_proxy = autogen.UserProxyAgent(
    name="Human",
    human_input_mode="NEVER",
    max_consecutive_auto_reply=3, # 限制最大自动回复次数，防止死循环
    code_execution_config={"work_dir": "coding_output", "use_docker": False},
)

# 4. 发起群聊
groupchat = autogen.GroupChat(
    agents=[user_proxy, reviewer, coder], 
    messages=[], 
    max_round=6 # 限制最大对话轮数
)
manager = autogen.GroupChatManager(groupchat=groupchat, llm_config=llm_config)

# 初始任务输入
initial_task = """
请审查以下订单退款服务的代码，并生成单测：
public void refundOrder(String orderId) {
    Order order = orderMapper.selectById(orderId);
    if (order.getStatus() == 1) {
        order.setStatus(3);
        orderMapper.updateById(order);
        // 调用支付接口退款
        payService.refund(order.getPayNo(), order.getAmount());
    }
}
"""

user_proxy.initiate_chat(manager, message=initial_task)

这段代码跑通的那一刻，看着控制台里 Code_Reviewer 准确指出了 order 可能为 null 导致的空指针风险，以及没有加分布式锁导致的并发退款问题，然后 Coder 乖乖地加上了 Optional 判空和 Redis 分布式锁，还顺手补全了单测。那一刻，我终于长舒了一口气，终于搞定了，开心！

经过大半个月的折腾，这套基于 CodeBuddy 和 AutoGen 的AI辅助研发体系总算是在团队里跑通了。为了让大家直观感受到效果，我拉了一下上个月和这个月的研发数据做了个对比：

指标	引入AI前 (上月)	引入AI后 (本月)	变化幅度
人均日代码提交行数	320 行	485 行	+51.5%
提测打回率	35%	12%	-65.7%
单元测试覆盖率	22%	68%	+209%
单个CRUD接口平均耗时	4.5 小时	2.0 小时	-55.5%

数据不会骗人。虽然这其中有大家被老板“降本增效”鞭策的因素，但AI工具确实实打实地帮我们减少了很多无意义的搬砖时间。现在李妹子在群里吐槽的次数少了，王产品经理催进度的时候我也能更硬气地怼回去了。

回顾这段时间的技术探索，我最大的心得体会是：AI 绝对不是银弹，它不能替代程序员的思考，更不能指望它直接帮你搞定复杂的业务架构。在三线城市做技术，我们缺乏大厂那种完善的基础设施和充沛的人力资源，AI 对我们来说更像是一个“效能放大器”。

用 CodeBuddy 解决单点编码的效率问题，用 AutoGen 解决流程中的协同和质量把控问题，这才是适合我们这种小团队的落地姿势。不要盲目追求大而全的AI中台，从最痛的点切入，小步快跑，快速迭代，才是技术探索的正确打开方式。

好了，不说了，老板又在群里@我，问AI能不能帮他自动生成周报了。我得去研究一下怎么用 AutoGen 给他搞个“马屁精Agent”了。大家如果在AI辅助编程方面有什么踩坑经验或者好用的Prompt，欢迎在评论区交流，我先去撸代码了！