作为一名在代码堆里摸爬滚打了十年的程序员，我发现自己越来越不愿意在那些重复性、机械性的琐事上浪费宝贵的脑力。尤其是每周一早上的那个固定仪式——打开Git仓库，像考古一样翻阅过去七天的提交记录，试图从那些碎片化的 commit message 里拼凑出一份kan起来像样的周报发给领导。这事儿本身不难，但那种枯燥感简直Neng把人逼疯。

于是我Zuo了一个决定：既然我是写代码的，为什么不写一个“数字分身”来替我干这活儿？这就有了我人生中第一个真正落地的 AI Agent 工作流。今天我把整个思考过程、代码实现以及踩过的坑dou毫无保留地开源出来。Ru果你也想用 AI 技术把自个儿从繁琐的日常事务中解放出来这篇文章或许Neng给你提供一份Ke以直接“照抄”的作业。

一、 架构设计：不仅仅是脚本，而是一个智Neng体

在动手敲键盘之前，我先在脑子里画了一张蓝图。这不仅仅是一个简单的脚本，它应该具备感知、思考和行动的Neng力。我们需要构建一个完整的流水线，让数据像水流一样顺畅地穿过各个环节。

整个系统的逻辑闭环非常清晰，主要包含三个核心步骤：

┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│  数据源     │ ──→  │  AI 大脑    │ ──→  │  通知终端   │
│    │      │   │      │    │
│ 采集提交记录 │      │ 智Neng清洗生成 │      │ 自动推送消息 │
└─────────────┘      └─────────────┘      └─────────────┘

这种设计模式体现了 AI 代理工作流在提高任务处理效率方面的巨大潜力。它不再是简单的 API 调用，而是通过任务拆解，将数据采集、逻辑处理和结果反馈有机地串联起来形成了一个Neng够独立完成复杂任务的自动化系统。

技术选型的务实考量

说实话，这个项目用 Python 写肯定geng快，用 Node.js 也没问题。但我Zui终选择了 Go 语言，理由非常务实：

零依赖部署我只需要编译出一个二进制文件，扔到服务器上就Neng跑，不用折腾 Python 的虚拟环境或者 Node.js 的 node_modules。

性Neng强悍虽然这个任务量级hen小，但 Go 的并发模型和执行效率让我心里geng踏实。

标准库够用HTTP 请求、JSON 处理、时间管理，Go 的标准库全包了除了定时任务用了一个第三方库 robfig/cron，其他全是原生实现。

至于 AI 模型，我毫不犹豫地选择了 DeepSeek。原因hen简单：便宜。同样的任务，DeepSeek 的价格大概是 GPT-4 的几十分之一。对于这种每天或者每周跑一次的批处理任务，成本几乎Ke以忽略不计。我这边实测的数据显示，生成一份高质量周报的成本不到一分钱。

二、 核心实现：从数据采集到智Neng生成

让我们深入到代码层面kankan这个 Agent 是如何一步步工作的。

1. 配置管理：灵活的环境变量

为了保持灵活性，所有的敏感信息和配置项我dou扔到了环境变量里。程序启动时会读取 .env 文件，其配置结构大概是这样子的：

# DeepSeek API
DEEPSEEK_API_KEY=sk-xxxxx
DEEPSEEK_MODEL=deepseek-chat
# CNB Token
CNB_TOKEN=your-token-here
# 要监控的仓库列表
CNB_REPOS=org/repo1,org/repo2
# 企业微信机器人 Webhook 地址
WECHATWORK_WEBHOOK=https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx
# 定时任务：每周一早上 9:00 执行
CRON_SPEC=0 9 * * 1

在 Go 代码中，我定义了一个结构体来承载这些配置，并编写了一个简单的加载函数：

type Config struct {
    DeepSeekAPIKey    string
    DeepSeekModel     string
    CNBToken          string
    CNBRepos          string
    WeChatWorkWebhook string
    CronSpec          string
}
func loadConfig *Config {
    return &Config{
        DeepSeekAPIKey:    getEnv,
        DeepSeekModel:     getEnv,
        CNBToken:          getEnv,
        CNBRepos:          strings.Split, ","),
        WeChatWorkWebhook: getEnv,
        CronSpec:          getEnv,
    }
}

2. 数据采集：调用 CNB 获取提交记录

这是 Agent 的“眼睛”。核心逻辑非常直接：遍历配置文件里的每一个仓库，根据日期范围逐天去调用 CNB 的 API 拉取 PushEvent。

这里有个细节需要注意，CNB 返回的数据格式是 JSONL，也就是每行一个独立的 JSON 对象。我们需要用流式的方式去读取和解析，而不是一次性把整个文件加载到内存里。

func fetchEventsFromCNB  {
    url := fmt.Sprintf
    req, _ := http.NewRequest
    req.Header.Set
    resp, err := http.DefaultClient.Do
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close
    scanner := bufio.NewScanner
    var commits Commit
    for scanner.Scan {
        var evt CNBEvent
        json.Unmarshal), &evt)
        // 我们只关心 PushEvent，因为这里面才有代码提交信息
        if evt.Type != "PushEvent" {
            continue
        }
        for _, c := range evt.Payload.Commits {
            commits = append(commits, Commit{
                SHA:     c.SHA,
                Author:  c.Author.Name,
                Message: c.Message,
            })
        }
    }
    return commits, nil
}

3. 智Neng处理：Prompt 工程的艺术

这是整个 Agent 的“大脑”。原始的 commit 数据往往非常杂乱，充满了 "fix"、"update"、"wip" 这种毫无意义的单词。Ru果直接把这些丢给领导，那绝对是灾难。

所以我们需要 AI Zuo几件事：去噪、归纳、合并同类项，并且Zui重要的是——绝对不Neng编造。

我设计的 System Prompt 如下这算是我的一点小心得：

systemPrompt := `你是一个专业的周报整理助手。请根据提供的原始代码提交记录，整理成一份简洁、专业的工作周报。
1. 忠于事实：只基于原始数据进行归纳，绝对不Neng编造、推测或猜测任何未提及的功Neng。
2. 合并同类项：Ru果是同一功Neng的多轮调试提交，请合并为一条工作项。
3. 智Neng去噪：忽略 "fix"、"update"、"wip"、"init" 等无意义的提交信息。
4. 屏蔽干扰：删掉所有 Merge Request 相关的机械性信息。
📊 周报
### 姓名
**项目名**
- 工作项 1
- 工作项 2
💡 建议
- `

在调用 DeepSeek API 时我们将清洗后的数据拼接到 Prompt 里：

func generateReport  {
    reqBody := ChatRequest{
        Model: cfg.DeepSeekModel,
        Messages: ChatMessage{
            {Role: "system", Content: systemPrompt},
            {Role: "user", Content: "

4. 结果推送：企业微信集成

Zui后一步是“嘴巴”。企业微信的群机器人支持 Webhook 方式推送消息，这简直是为我们这种自动化场景量身定Zuo的。只需要一个 HTTP POST 请求，消息就Neng出现在群里。

当然Ru果你用的是飞书或者钉钉，逻辑也是完全通用的，只需要换一下 URL 和消息体格式即可。

三、 调试实录：那些我踩过的坑

虽然代码量不大，但在实际跑通的过程中，我还是遇到了几个让人抓狂的问题。分享出来希望Neng帮你省点调试时间。

坑一：周一的日期计算逻辑

这绝对是个经典坑。在 Go 语言里time.Weekday 的返回值逻辑是：周日=0，周一=1，……周六=6。

但是我们的业务逻辑里一周通常是从周一开始算的。Ru果直接用这个返回值Zuo减法，hen容易算错日期范围。我不得不写了一段转换逻辑，把周日当成 7 来处理，这样才Neng正确回溯到“上周一”。

now := time.Now
weekday := int)
if weekday == 0 { weekday = 7 } // Go 里周日是0，我们要转成7
thisMonday := now.AddDate).Truncate
lastMonday := thisMonday.AddDate
lastSunday := thisMonday.AddDate

这个坑我调试了两次才对，记下来免得你踩。

坑二：AI 的“幻觉”问题

第一次跑的时候，AI 居然给我“编”了一个我根本没Zuo的功Neng进去，还写得头头是道。这要是直接发出去，我就得卷铺盖走人了。

后来我在 Prompt 的开头加了“铁律”：**「绝对不Neng编造、推测、猜测」**，并明确要求它只基于传入的原始数据。之后这个问题就再也没出现过。这也说明了 Prompt Engineering 中约束条件的重要性。

坑三：空数据的异常处理

某天没有提交记录时CNB 返回的是 HTTP 404，而不是一个空数组。一开始我把它当成错误处理了导致日志里堆满了 WARN 级别的报错信息，kan着hen心慌。

后来意识到这是正常行为——没数据就是没数据，不是出错了。于是我把逻辑改成了静默跳过世界瞬间清静了。

四、 部署上线：让它自己跑起来

代码写完了总不Neng每次手动运行吧？我们需要把它变成一个系统服务，根据你的服务器环境，Ke以选择不同的部署方式。

方式一：Systemd 服务

创建一个服务文件 /etc/systemd/system/daily-report-agent.service

Description=Daily Report Agent
After=network.target
Type=simple
WorkingDirectory=/opt/daily-report-agent
ExecStart=/opt/daily-report-agent/daily-report-agent
Restart=on-failure
RestartSec=5s
WantedBy=multi-user.target

然后执行以下命令启动并设置开机自启：

sudo systemctl daemon-reload
sudo systemctl enable daily-report-agent
sudo systemctl start daily-report-agent
# 查kan运行状态
sudo systemctl status daily-report-agent
# 实时查kan日志
sudo journalctl -u daily-report-agent -f

方式二：Docker 部署

Ru果你不想折腾系统环境，Docker 是Zui好的选择。这是我的 Dockerfile

FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o daily-report-agent .
FROM alpine:latest
WORKDIR /app
COPY --from=builder /app/daily-report-agent .
COPY .env .
CMD 

构建并运行：

docker build -t daily-report-agent .
docker run -d --name report-agent --restart=always daily-report-agent

方式三：Windows 计划任务

Ru果你是在 Windows 电脑上跑，Ke以用 NSSM 把它注册为系统服务，或者直接用系统自带的“计划任务”：

schtasks /create /tn "DailyReportAgent" /tr "C:\path\to\daily-report-agent.exe now" /sc weekly /d FRI /st 16:00

这个项目从想法到Zui终跑通，大概花了我一个周末的时间。代码量不大，不到 500 行，但它是我副业产线上的第一个“产品”。

它的意义不在于周报本身，而在于验证了一个流程：数据采集 → AI 处理 → 自动推送。这个流程是Ke以复用到无数场景中的，比如监控告警、日报汇总、竞品追踪等等。周报，只是我拿它练手的第一个靶子。

目前，整个流程跑下来大概只需要 5 秒钟。比我自己手写快了 20 倍，而且绝对不会漏掉任何一个 commit。每个周一早上，当我还在挤地铁的时候，我的 AI Agent Yi经把周报整整齐齐地发到了群里。

Ru果你也想尝试，我Yi经把代码开源到了 GitHub。欢迎 Star、提 Issue、Fork 改造。Ru果你基于这个项目Zuo了什么有趣的改造，欢迎 PR 或者给我发邮件交流。

Zui后我想说这不是一篇“教你赚大钱”的文章，这只是一个普通程序员从 0 到 1 的实践记录。我们每个人douKe以成为自己工作的架构师，把那些重复的劳动交给 Agent，把创造力留给自己。

我是龙虾，一个正在用 AI Agent 搭建副业产线的程序员。Ru果你觉得有用，点个「在kan」就是Zui大的支持。

---