Zengmx的个人空间

写在前面

最近刚刚提交了离职申请，即将告别这家陪伴我九年多的公司，心中充满感恩。接下来在入职下一份工作前，会有一段相对空闲的时间，预计会以较高的频率更新博客内容。

如今，HTTPS 已成为现代网站的标配。不支持 HTTPS 的站点不仅会被主流浏览器标记为“不安全”，还可能被直接阻止访问。因此，为网站启用 HTTPS 不仅是提升安全性的必要措施，也是增强用户信任的关键一步。

本文将手把手带你完成免费 HTTPS 证书的申请与部署全过程。一些基础概念我们放在文末的【附录】中，感兴趣的同学可以进一步了解。

环境说明

• 云服务器提供商：火山引擎
• 域名托管平台：阿里云
• 操作系统：CentOS Stream 8
• Web 服务器：nginx/1.14.1

步骤一：申请免费 SSL 证书

国内主流云服务商（如阿里云、腾讯云、火山引擎等）均提供免费的 SSL 证书服务。通常每人每年可申请 20 张证书，每张有效期为 3 个月，到期后可重新申请，完全满足个人或测试站点的需求。

本文以 火山引擎 为例，演示证书申请流程。

1. 进入证书申请页面

访问 火山引擎证书中心，点击“免费证书”进行申请。

写在前面：一眨眼，又快到月底了。立下的“每周写一篇技术博客”的 FLAG，果然还是很容易被现实狠狠打脸……
本文内容源自 2025 年 6 月在事业部内部的一次技术分享，主题是《AI Code Review 技术实践》。今天整理成文，既是复盘，也希望能给同样在探索 AI 辅助开发的朋友们一些参考。

一、为什么我们需要 AI 自动 Code Review？

随着团队规模快速扩张，我们逐渐面临几个棘手的问题：

1. 新人涌入，代码风格不一
   新成员技术背景各异，对团队规范的理解和执行参差不齐，导致代码一致性下降。
2. 低级错误频发
   诸如空指针、未处理异常、重复逻辑等“本不该犯”的错误越来越多，直接影响系统稳定性和用户体验。
3. 人工 Review 越来越吃力
   导师和项目经理的时间本就紧张，面对海量 PR（Pull Request），很难做到逐行细致审查，效率和覆盖率都难以保证。
4. 质量依赖“人治”
   虽然有代码规范和检查工具，但是否执行、执行多严格，往往取决于个人习惯——这显然不可持续。

于是，我们开始思考：能否借助大模型的能力，实现自动化的、智能的代码审查？

二、我们的核心需求

在调研和讨论后，我们明确了几个关键需求：

• ✅ 基于大模型自动审查：支持对多种语言的代码文件进行智能分析；
• ✅ 内网可部署：保障代码安全，不依赖外部 SaaS 服务；
• ✅ 深度集成 GitLab：公司使用 GitLab 管理代码，需支持 MR（Merge Request）和 Push 触发；
• ✅ 结果推送钉钉：通过企业钉钉机器人，将审查结果实时同步到项目群，确保问题不被遗漏。

三、选型：为什么是 AI-Codereview-Gitlab？

经过对比多个开源方案，我们最终选择了 AI-Codereview-Gitlab（ https://github.com/sunmh207/AI-Codereview-Gitlab）。它不仅满足上述需求，还有不少亮眼特性：

🌟 核心优势

• 自动触发，无需人工干预
  利用 GitLab Webhook，代码提交或 MR 创建时自动触发审查，响应迅速。
• 深度集成 GitLab API
  可灵活扩展，未来支持自定义规则、标签过滤等高级功能。
• 全自动覆盖多种提交场景
  无论是 push 还是 merge request，都能自动分析并评论到对应位置。
• 网络异常自动重试
  内置 retrying 机制，确保在内网环境不稳定时仍能可靠运行。

写在前面：本文源自2025年3月的一次公司内部分享。如果你也曾被“大模型无所不能”的宣传洗脑过，那今天咱们就一起拆穿它的“嘴强王者”本质，并亲手给它装上手脚——做一个真正能干活的AI Agent！

一、大模型这么强，为啥还要Agent？

你有没有试过对ChatGPT说：“帮我订张机票！”
它大概会温柔地回你一句：“亲，建议您打开携程哦～”

是不是瞬间感觉被敷衍了？
没错，这就是当前大语言模型（LLM）的三大“硬伤”：

• 知识滞后：它可能还在怀念2012年的世界末日，根本不知道昨天的油价涨了。
• 无法动手：它能教你追女神，但不会帮你发微信（毕竟它连手机都没有）。
• 缺乏主见：像极了开会时说“我都行”的同事，最后活全甩给你。

所以，光靠“嘴强”是不够的。我们需要一个能感知环境、自主决策、动手执行的智能体——这就是 AI Agent。

简单来说，Agent = LLM + 工具 + 编排逻辑。
你可以把它理解为：给大模型装上“手脚”（工具）和“小脑”（编排层），让它从“嘴强王者”变身“行动派打工人”！

二、Agent vs LLM：谁才是真·靠谱？

一句话总结：LLM 是顾问，Agent 是包工头。

三、手搓Agent的“三剑客”

一个完整的Agent通常由三个核心组件构成：

1. 大脑（LLM）：负责理解用户意图、推理任务、决定下一步干啥。比如判断你是要注册、查询，还是删号跑路。
2. 手脚（Tools）：让Agent能和外部世界互动，比如查数据库、发邮件、调API。没有工具，Agent就是个“思想家”。
3. 指挥中心（编排层）：协调大脑和手脚，管理对话状态，确保任务一步步推进，不跑偏。

整个流程大概是这样的：

用户输入 → LLM理解意图 → 规划行动 → 调用工具 → 获取结果 → 返回用户（或继续下一步）

四、开发前的“吃饭家伙”

别急着写代码，先备好装备：

• Python：AI界的“万能胶水”，库多、生态好、写起来爽。
• PyCharm 或 Jupyter Notebook：一个适合工程开发，一个适合快速验证想法。
• LLM选择：国内推荐通义千问（Qwen），免费额度够用（比如 qwen-max 送100万token），后面案例就用它。
• 基础知识：懂点机器学习原理、会处理数据、能写Python函数——不用多深，但得会“缝合”。

💡小贴士：本文坚持“手搓”原则——不用 Dify、Coze 这类平台，直接写代码！只为让你知其然，更知其所以然。

五、实战：从 Hello World 到油田问数

1. Hello World 级 Agent

最简单的Agent：你问它“你好”，它回你“你好呀！”。虽然没啥用，但仪式感不能少！

运行代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

import os
from dotenv import load_dotenv
from openai import OpenAI
# 加载环境变量
load_dotenv()
# 设置API密钥，从千问里面去获取
api_key = "sk-c1f…………"
# 基础配置
base_url = "https://dashscope.aliyuncs.com/compatible-mode/v1"
# 设置使用的基础模型，在阿里模型超市可以看到model名称
chat_model = "deepseek-v3"
# 创建客户端
client = OpenAI(
    api_key=api_key,
    base_url=base_url
)
def get_completion(prompt):
    response = client.chat.completions.create(
        model=chat_model,
        messages=[
            {"role": "user", "content": prompt},
        ],
        extra_body={"enable_thinking": False},
    )
    return response.choices[0].message.content
# 测试调用
response = get_completion("你好，南威软件！")
print(response)

运行结果

1
2
3
4
5
6
7
8
9
10

你好！看来你对 **南威软件** 感兴趣。南威软件（Nanwei Software）是中国一家专注于 **政务信息化、公共安全、智慧城市** 等领域的高新技术企业，提供软件开发、系统集成和解决方案服务。  

如果你有具体问题，比如：  
- 公司业务或产品  
- 股票/上市信息（上交所代码：603636）  
- 合作或招聘咨询  

可以直接告诉我，我会尽力帮你整理相关信息！ 😊  

（注：作为AI，我无法访问实时数据，但可以提供公开资料或分析建议。）

个人博客已然荒废多年。这些年，工作与生活交织奔忙，几乎占据了全部的时间与心力。技术在飞速迭代，而我却在项目交付与日常琐事中渐行渐远，不知不觉间，技术债务越积越多，曾经的热情也悄然蒙尘。

近来静心反思，深感记录与沉淀的重要性。代码会重构，项目会迭代，但唯有持续的思考与总结，才能真正沉淀为自己的能力。于是，决定重启这个尘封已久的博客，不再追求华丽的辞藻或高深的理论，只愿它成为一处安静的角落：

• 记录工作中遇到的技术难题与解决方案；
• 梳理学习过程中的知识脉络与心得体会；
• 反思项目实践中的得失与成长。

在此立下一个或许很容易被打脸的 flag：争取每月至少输出一篇文章。不为其他原因，只为提醒自己——别停下学习与思考的脚步。

路漫漫其修远兮，吾将上下而求索。这一次，希望走得更稳，更远。

PS：本次重新部署的一些参考材料

hexo官网：https://hexo.io/zh-cn/docs/

Hexo + NexT主题美化GitHub博客：https://www.cnblogs.com/qianxiaohan/p/19032755

使用 Hexo 搭建个人博客并部署到云服务器：https://www.cnblogs.com/cheyaoyao/p/17836522.html

笔者09年开始实习至今，分别经历了互联网产品→定制化项目→项目型产品三个阶段，在第一次转型时由于只是开发人员，对于转型的理解并没有那么深刻；在第二次转型时，由于已是负责人，需要站在更高的层面上思考以及转变，对于转型之痛深有感触，对于转型过程中所走的弯路也印象尤深，故以此文来记录自己的理解，叙述的内容带有工作领域的局限性，也希望与大家共同探讨。

前言：

在开始撰文之前，先以福特创始人Henry Ford的一句话（真实性存疑）作为开头，此句也成了我在产品设计时的座右铭，“If I had asked people what they wanted, they would have said faster horses.”。

短短一句话，其实已经道尽产品思维的特性，产品越深入，对其越是感同身受。接下来，笔者将从定义、思维方式、团队构成、需求来源、商业模式、版本分支、配套工具等方面分享笔者认知中产品与项目之间区别和联系。

01 定义

1. 项目是什么

有学习过PMP或者高项的人，应该对于项目的定义是再熟悉不过了——项目是为创造某种独特的产品或服务所做出的一次性的努力，其具备的几个特征： 目标性；独特性； 临时性；渐进明细。

落到我们实际的工作中，软件项目的本质就是为了实现合同约定的建设内容或用户方的需求，通过程序开发\部署的方式将其以软件的形式实现，并将其与交付物一并提交给用户。

2. 产品是什么

对于产品的定义，百科中给出一段相对绕口的描述——产品是指能够提供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。

如果用更加贴近于软件开发方式来描述的话，那么软件产品是面向解决业务场景需求，持续迭代，并可在多个项目中被复用的一类具有通用性的软件形态。

笔者所在的公司中，存在着两种不同形态的产品，一种为业务应用类产品，其专注于解决业务场景方面的需求，并可在多个项目中进行应用，如电子证照、政务服务办理等；另外一种为底层组件类产品，其业务属性较弱，对于通用属性进行高度提炼并对业务进行拆解，如用户中心、表单中心等。

举一种实际生活中的例子描述这两者的区别：项目就是一次性杯子，目的是为了解决单次喝水的需求，目标明确且一次性；而产品就是陶瓷杯或者水杯，面向的场景是解决多次喝水场景的需求，而且还会根据喝水、喝咖啡、喝酒等不同场景衍生出不同的子产品。