禅道二次开发与Dify工作流：从数据聚合到AI自动生成项目月报

1. 项目背景与整体思路

1.1 为什么选择禅道二次开发而不是换一套系统

上个月底，领导让我把整个研发团队的项目月报整理出来，我盯着禅道里那一百多条任务、几十个Bug，以及一堆没有填完的工时记录，头都是大的。这东西人工统计实在太反人类了。我们的流程是：任务在禅道里分派、Bug在禅道里跟踪、每天工时也关联到禅道任务上，数据其实都在那里，但没人愿意一条条去数。更麻烦的是，月报这种东西除了汇总数字，还得写出“这个月有没有延期风险”“哪些任务值得复盘”“下个月重点应该放哪”，这些判断性内容靠纯Excel透视表搞不出来。

所以我当时想到的方向不是把项目管理系统换掉，而是在现有禅道上做二次开发，把月报数据抽出来，再交给大模型去分析和总结。为什么选禅道二次开发？因为我们已经在禅道上跑了两年多的项目，几百个任务、上千条记录都沉淀在里面，迁移系统的成本远高于写一个对接脚本。禅道本身有比较开放的API，底层数据表也可以只读访问，这给了做自动化很大的空间。

当然，光有数据还不够，还要有能读懂这些数据的“分析大脑”。我选了Dify来做工作流编排，因为它可以快速把一个带提示词的AI分析流程发布成HTTP接口，团队内部其他系统也能复用，不用自己从头写大模型调用代码。整个方案做下来，核心就三件事：从禅道拿数据、把数据变成结构化输入、交给Dify工作流生成月报分析。这个思路适合那些已经在用禅道、希望用AI减轻管理报表负担的技术团队，也适合想了解怎么把项目管理系统和AI平台打通的朋友参考。

1.2 Dify工作流在这个场景里解决什么问题

最初我也犹豫过，为什么不直接写Python调用大模型API，非得再套一层Dify？我的实际体验是：直接调API虽然简单，但提示词、模型参数、输出格式全都散落在脚本里，换个模型或者想调整分析逻辑，就得改代码重新部署。而Dify工作流把“输入变量、LLM节点、输出变量”这些环节可视化地串起来，我可以把月报分析的需求固化成一个标准流程，非开发同事也能在界面上调整提示词，甚至把同一个工作流复用到其他项目上。

在这个月报场景里，Dify工作流承担的职责，是从我提供的结构化项目数据中提炼出三样东西：项目概况、风险预警、下月建议。它会根据任务完成率、Bug分布、严重程度、逾期情况等信息，生成一段可以直接贴到周报或月报里的文字。Dify还顺带帮我解决了输出格式问题，通过结束节点的变量定义，工作流可以返回固定的JSON结构，比如summary、risks、suggestions，这样后续自动生成文档时就不用再写一堆正则去解析AI回复。

在没有Dify之前，我也试过直接把数据塞给大模型，结果回复虽然像模像样，但有时会漏掉关键风险，有时输出格式千奇百怪。后来把提示词挪到Dify工作流里，加上数据预处理和输出约束，稳定性明显好很多。说白了，Dify在这里不是必需品，但它让整条链路更工程化、可维护，也让我后续写脚本的时候不用反复折腾prompt。

2. 技术选型：禅道二次开发的入口与Dify接入方式

2.1 禅道二次开发的四条路，我为什么选了API优先

禅道二次开发，常见的有四条入口：官方插件机制、数据库直连、API接口扩展、在源码基础上改PHP逻辑。我不建议一上来就改源码，因为禅道升级会把改动覆盖掉，而且万一改出问题，还得背锅。插件机制适合做一些表单扩展和按钮触发的事情，但对月报这种偏数据的场景并不顺手。所以我优先考虑了API和数据库两种方式，后面实际实现也是两条腿走路。

禅道从17版本开始提供了比较完整的开放API，走的是/api.php/v1/前缀，可以获取项目、任务、Bug、用户等资源。API的优势是安全，因为禅道会自己处理权限校验；缺点是不同版本之间接口路径有差异，分页参数和返回字段也偶尔会变，需要以自己实际部署的版本为准。我的做法是先写一个小的接口探针脚本，把项目列表、任务列表、Bug列表各拉一次，观察返回的JSON结构，再定抽取逻辑。

数据库直连是另一条很重要的路。禅道底层是MySQL，表名都是zt_开头，比如zt_task、zt_bug、zt_effort。只要账号有只读权限，就能用很灵活的SQL做聚合统计，比反复调API高效得多。不过这里要强调一个原则：二次开发尽量只读数据库，绝不直接改。否则很容易绕过禅道的缓存和权限逻辑，造成数据不一致。我自己遇到过同事用SQL把任务状态改坏了，后来禅道前端一直显示异常的情况，所以现在所有写操作都走官方API，只有统计数据才查库。

2.2 选择Dify工作流而不是直接调大模型API的原因

Dify是一个开源的大模型应用开发平台，支持知识库、Agent、工作流这些能力。我在这个项目里只用到了它的“工作流应用”类型，核心是三个节点：开始节点、LLM节点、结束节点。开始节点定义输入变量，比如project_data；LLM节点写提示词并调用模型；结束节点定义输出变量，把AI生成的分析结果返回给调用方。整个过程可以在Dify界面里拖拽完成，不需要写后端服务。

我选择Dify的另一个原因是它天然支持多模型切换。团队里不同的项目可能想用不同模型来平衡成本和效果，Dify可以配置多个模型供应商，工作流里切换模型只需要点一下，不用改脚本。如果业务部门觉得月报太啰嗦，他们自己可以在Dify界面里修改提示词，不用等研发排期。这种“让业务同学参与AI流程调整”的能力，是直接写代码调API给不了的。

当然，Dify也有学习成本，至少你得理解“输入变量绑定”“节点输出映射”“提示词变量引用”这几个概念。但比起从零实现一套Prompt管理平台，Dify的成本已经低到可以忽略。后面我会详细介绍工作流的搭建细节。

2.3 整体数据流设计

这条链路最终跑起来是这样的：定时脚本先通过禅道API和数据库只读查询，把指定项目、指定月份的任务、Bug、工时数据取出来，清洗成一份结构化的JSON；然后脚本带着这份JSON去请求Dify工作流的HTTP接口，Dify把它交给大模型生成分析结果；最后脚本把返回的摘要、风险点、建议内容写入月报草稿文件，或者回传给禅道的自定义字段，供管理者查阅。

整个数据流里，最关键的约束是“输入数据的质量”。AI分析这件事，很大程度上是“垃圾进，垃圾出”。如果给到Dify的数据本身缺失严重，比如工时大量为空、任务状态混乱，那再牛的提示词也救不回来。所以我在脚本里加了数据补全逻辑：没有填工时的任务按预估工时折算成参考消耗，状态非“已完成”的任务统一归入“进行中”或“未开始”的分类，这样AI拿到的是一份干净的数据。

我画不出什么华丽的架构图，但用文字描述就是：禅道数据源（API + MySQL只读）→ Python数据聚合脚本 → Dify工作流API → AI分析结果 → 月报输出。后面每一步怎么实现，都有对应的代码和配置，直接照着做就行。

3. 从禅道抽取月报数据：API与数据库两条路

3.1 打开禅道API并处理鉴权

禅道开源版的API默认不一定会开启，需要先到“后台→系统→API”里确认一下。以我的环境为例，部署版本是禅道17.6开源版，API地址是https://zentao.example.com/api.php/v1/。鉴权方式有两种：一种是通过账号密码换取token，一种是直接在后台创建一个永久令牌。考虑到脚本要跑定时任务，我选择了在后台创建API令牌的方式，好处是token不容易失效，也不用在脚本里存明文密码。

获取token后，所有请求都在HTTP头里带上Token: 你的令牌值。比如拉取项目详情：

import requests base_url = "https://zentao.example.com/api.php/v1" token = "your_api_token_here" headers = {"Token": token, "Content-Type": "application/json"} # 拉取项目列表 resp = requests.get(f"{base_url}/projects", headers=headers, timeout=10) resp.raise_for_status() projects = resp.json() print(projects)

需要注意几个问题：第一，不同禅道版本的API前缀可能不是api.php/v1，有的企业版是用api.php/v2，最好在本地试一下首页能否返回说明文档。第二，Token这个Header的名字是严格的，写成Authorization可能会返回401。第三，禅道接口有分页，一般通过limit和offset参数控制，默认只返回一页数据，拉全量时必须循环请求。

3.2 用Python脚本拉取任务、Bug和工时

拉取任务和Bug都走API，但接口字段很多，我只保留月报真正关心的。任务的字段大概包括：id、name、status、assignedTo、estimate（预计工时）、consumed（消耗工时）、left（剩余工时）、deadline、finishedDate等。Bug的字段包括：severity、status、resolution、openedDate、resolvedDate、title等。

下面是我实际用的简化版拉取脚本，只展示了任务部分：

def fetch_tasks_by_project(project_id): tasks = [] offset = 0 limit = 100 while True: url = f"{base_url}/projects/{project_id}/tasks" params = {"limit": limit, "offset": offset} resp = requests.get(url, headers=headers, params=params, timeout=15) resp.raise_for_status() data = resp.json() batch = data.get("tasks", []) tasks.extend(batch) if len(batch) < limit: break offset += limit return tasks

这里每次请求100条，通过判断返回条数是否小于limit来决定是否还有下一页。很多团队项目任务量在几百条级别，循环几次就能拉完。Bug的拉取方式和任务类似，只是接口路径变成了/projects/{project_id}/bugs。工时数据我则直接走数据库，因为单一任务的工时记录在API里没有聚合好的字段，用SQL求和更直接。

需要注意，API返回的JSON里字段名是小驼峰，而数据库字段名是下划线风格，编写脚本时别混了。比如API里的assignedTo对应数据库assignedTo，但有些版本APIid字段名是id，没踩坑之前我以为可以直接映射，结果打印出来一看少了好几个字段，最好每次先用json.dumps(..., ensure_ascii=False)打印一页原始数据再写字段映射。

3.3 只读MySQL兜底方案

为什么还要直连MySQL？因为API拿到的任务列表虽然包含基本状态，但要做“项目该月新增Bug数量”“任务关闭率”“按严重程度统计Bug分布”这类聚合，用SQL写起来远比在Python里循环统计方便。我叫了数据库只读账号，只授权SELECT，连接信息通过环境变量传入。

我实际用的几张核心表和作用如下：

聚合SQL示例：统计某项目某月份关闭Bug数量，并按严重程度分组。

SELECT severity, COUNT(*) AS bug_count FROM zt_bug WHERE project = 37 AND status = 'closed' AND resolvedDate BETWEEN '2025-11-01' AND '2025-11-30' GROUP BY severity;

这里有个小坑：禅道的resolvedDate格式是2025-11-20 10:30:00，直接和'2025-11-01'比较没问题，但如果用DATE_FORMAT转换，索引会失效。我建议直接写成resolvedDate >= '2025-11-01' AND resolvedDate < '2025-12-01'，既准确又高效。

另一个实用的小技巧是，如果只查当月数据，不要把所有历史任务都拉出来再在内存里筛。SQL里加上project和日期条件，数据量小很多，脚本跑起来也就几秒钟。

3.4 数据清洗与聚合处理

抽出来的原始数据不能直接塞给Dify。大模型适合读“结论性摘要”，不适合读几百行明细。我在脚本里做了两层聚合：第一层按状态统计任务数量，比如“已完成28个、进行中12个、未开始5个”；第二层按严重程度统计Bug分布，比如“致命1个、严重4个、一般8个、轻微3个”。同时对工时做汇总，得到“总预算工时、总消耗工时、月新增消耗工时”。

数据清洗时我遇到的常见问题有：任务没有指派人的情况，我统一归为“未指派”；任务没有截止日期的情况，我记为“未设置截止时间”；Bug没有严重级别的情况，我归为“一般”。这些异常值如果不处理，AI分析时很容易产生误判，比如把“未填截止时间”当成“任务无限延期”。

清洗完成后，我生成一个结构化的JSON，作为Dify工作流的输入。大致长这样：

{ "project_name": "客户服务中台", "month": "2025-11", "task_summary": { "total": 45, "completed": 28, "in_progress": 12, "pending": 5 }, "bug_summary": { "total_opened": 16, "total_closed": 11, "critical": 1, "major": 4, "minor": 11 }, "effort_hours": { "plan_estimate": 860, "consumed_month": 320, "consumed_total": 780, "remaining": 180 }, "milestones": [ {"name": "订单模块重构", "planned_date": "2025-11-15", "actual_date": "2025-11-20", "status": "delayed"} ] }

这一步是整个方案里最花时间的地方，数据只要干净一点，AI的输出质量立刻提升一截。

4. 在Dify中搭建月报分析工作流

4.1 创建工作流和输入输出变量

登录Dify控制台，创建一个“工作流”类型的应用，不要选“聊天助手”。进入工作流画布后，默认会有一个“开始”节点。我的做法是在开始节点里定义两个变量：一个是project_data，类型选JSON，用于接收上面清洗后的结构化数据；另一个是month，类型选字符串，用于告诉AI当前分析的是哪个月份。

定义输入变量时，要特别注意变量名和Python脚本里传的key完全一致，否则API调用会报“input key not found”。我刚开始把变量名命名为ProjectData，脚本里用project_data传，结果一直校验失败，改成完全一致后就好了。

接着添加一个LLM节点，输入引用方式选择“变量”，把project_data和month都拖进提示词上下文里。LLM节点的输出是文本，后续需要把它拆分到不同的输出字段。如果不想用复杂的代码节点，我建议直接在结束节点定义多个输出变量，然后在LLM节点里让模型标注“使用固定分隔符输出三块内容”，再用一个简单的Python节点去切分。不过更省事的做法是用Dify的“结构化提取”概念：在LLM提示词里约定输出JSON，然后结束节点直接引用sys.query拿原始内容，由脚本端解析。

经过几次折腾，我最终在结束节点里定义了四个输出变量：summary（整体概况）、risks（风险点）、suggestions（下月建议）、raw_output（原始返回内容），方便排查问题。

4.2 设计LLM节点与提示词

提示词是决定AI分析质量的关键。我写过好几版，从最初简单的“帮我总结月报”，到后来固定的“角色+任务+数据+输出格式”，效果差别非常大。这里分享一版我目前用得比较顺的提示词结构：

你是一位资深的项目管理分析师。请根据提供的项目任务数据和Bug数据，生成一份结构化的项目月报。 数据源： {project_data} 分析要求： 1. 先总结项目整体进展，包括任务完成情况、Bug处理情况、工时消耗情况。 2. 识别项目风险，包括任务逾期、严重Bug未关闭、剩余工时紧张等情况。 3. 给出下个月的工作建议，建议要具体可执行，不要泛泛而谈。 输出要求： 以JSON格式返回，包含三个字段：summary, risks, suggestions。 其中summary为字符串，risks为字符串数组，suggestions为字符串数组。

这里有个很重要的细节：{project_data}是Dify里引用输入变量的写法，前后的大括号不能少。你可以在LLM节点的“上下文”区域点击添加变量，Dify会自动生成这个占位符，手动打字容易出错。

模型参数我也做了调整，temperature设置为0.2，因为月报分析更偏向“确定的结论”而不是“创造性的发散”。max_tokens设置为2000左右，避免输出太长被截断。如果你用的是不同模型，可能需要根据模型上下文长度调整，但思路是一样的：分析类任务，温度低一些，输出结构越稳定。

4.3 发布并获取调用接口

工作流编辑完成后，点击“发布”按钮。发布成功之后，Dify会提供一个API访问地址，格式一般是/v1/workflows/run。我们需要在Dify应用里创建一个“API访问令牌”，这个令牌以app-开头，后续在HTTP请求的Authorization头里使用。

在Dify界面里，“访问API”页面会展示完整的调用示例，包括curl命令和参数说明。我当时最关心的就是response_mode参数，它有两个值：blocking和streaming。月报生成是离线脚本调用，所以我用blocking，就是一直等Dify跑完再返回完整结果。

调用参数大致是这样：

{ "inputs": { "project_data": {...}, "month": "2025-11" }, "response_mode": "blocking", "user": "monthly-report-bot" }

user字段可以随便填一个标识，Dify用它来做不同用户间的资源隔离。脚本里我固定成一个字符串就行。

拿到这个接口信息后，禅道和Dify之间的桥就算搭好了。后面要做的，就是把Python脚本、Dify接口、调度任务三者串起来。

5. 端到端串联：调度脚本与回写月报草稿

5.1 Python调用Dify工作流，传入结构化数据

数据聚合完成之后，下一步就是往Dify发请求。我封装了一个函数，接收清洗后的project_data和月份，返回Dify输出的分析结果。

def call_dify_workflow(project_data, month): api_key = "app-your-dify-api-key" url = "https://dify.example.com/v1/workflows/run" headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" } payload = { "inputs": { "project_data": project_data, "month": month }, "response_mode": "blocking", "user": "monthly-report-bot" } resp = requests.post(url, headers=headers, json=payload, timeout=120) resp.raise_for_status() result = resp.json() return result["data"]["outputs"]

这里有个超时问题值得注意。Dify工作流里如果调用的是大模型，生成时间通常要几十秒，HTTP请求的超时时间不能设得太短，否则脚本会报ReadTimeout。我一开始设了10秒，跑一次挂一次，后来改成120秒才稳定。

返回结果中，data.outputs是一个JSON对象，里面的字段就是我们在Dify结束节点里定义的变量。如果你在LLM节点里让模型返回JSON对象，但结束节点定义的是纯文本，那脚本拿到的可能是一串字符串，需要再用json.loads解析一次。为了避免这种麻烦，我建议在Dify结束节点里定义summary、risks、suggestions三个独立变量，分别映射LLM输出内容的不同部分。

5.2 解析输出并回写月报草稿

拿到Dify返回的outputs之后，我会把它整理成一份Markdown格式的月报草稿，保存到本地，同时可以写入禅道的自定义字段或者第三方Wiki。下面的代码把分析结果写成Markdown文件：

import json from datetime import datetime def generate_markdown_report(outputs, project_name, month): summary = outputs.get("summary", "") risks = outputs.get("risks", []) suggestions = outputs.get("suggestions", []) lines = [] lines.append(f"# {project_name} {month}月项目月报") lines.append("") lines.append("## 项目概况") lines.append(summary) lines.append("") lines.append("## 风险预警") for risk in risks: lines.append(f"- {risk}") lines.append("") lines.append("## 下月建议") for suggestion in suggestions: lines.append(f"- {suggestion}") report = "\n".join(lines) filename = f"{project_name}_{month}_月报草稿.md" with open(filename, "w", encoding="utf-8") as f: f.write(report) return filename

如果你希望在禅道里直接看到这份月报，一个比较稳妥的做法是在禅道里创建一个“文档”类型的对象，然后通过API上传Markdown内容。但禅道的文档API在开源版里能力有限，所以我目前的方案是先把草稿写到本地或代码仓库，再定期同步到文档平台。对领导来说，他拿到的是一份可以继续编辑的草稿，并不是最终僵硬的报告，反而更实用。

5.3 配置定时任务实现月底自动生成

月报一般是月底和月初交，所以我把脚本做成了“可传参”的命令行工具，接收--project-id和--month两个参数。这样既能手动补跑某个月的月报，也能用cron在每月1号自动生成上个月的月报。

假设脚本路径是/opt/zentao-monthly-report/main.py，逻辑是先算出上个月的月份，再拉数据、调Dify、存文件。cron配置如下：

0 9 1 * * cd /opt/zentao-monthly-report && /usr/bin/python3 main.py --project-id 37 --month last-month >> monthly.log 2>&1

这里--month last-month是我在脚本里做的小处理：传入last-month时自动用datetime计算上一个自然月。这样就不用每个月手动改cron参数了。

定时任务跑起来之后，还需要额外做日志和异常通知。我的做法是：脚本结束后把结果写入日志，如果Dify调用失败抛出异常，就通过企业微信机器人发送一条告警消息。因为脚本运行时间比较长，如果不监控，很容易出现月底发现月报没生成、数据全没拉下来的尴尬情况。

6. 踩坑记录与问题排查

6.1 Dify接口鉴权和请求格式

我遇到的第一个问题就是Dify请求返回401。排查了一圈发现，Dify工作流API的鉴权头是Authorization: Bearer app-xxxxx，注意Bearer后面有一个空格，而且密钥必须是app-开头，不能误用其他类型应用的密钥。还有一次是请求体里的inputs里的key和Dify开始节点定义的变量名不一致，返回400错误。这种问题最常见的原因就是变量名大小写或者下划线没对上，我的排查方式是在Dify界面的“编排”页面里点开开始节点，对照输入变量的名字逐个检查。

另外，response_mode如果写成streaming，Dify会返回一个流式的SSE响应，普通requests.post拿不到完整JSON，只能拿到data流块。如果不想处理流式，请务必用blocking。

6.2 禅道API分页和字段缺失

禅道API的分页默认是20条还是100条，不同版本不一样，我在脚本里显式指定了limit=100来减少请求次数。但有些旧版本并不支持limit参数，而是用page和perPage。如果发现拉到的数据一直只有一页，建议直接打印响应体，看看pager字段里总页数的计算方式。

字段缺失的问题更隐蔽。API返回的字段名可能在不同版本间有变化，比如新版本里任务状态的取值范围是doing、done、cancel，旧版本可能是wait、doing、done。我写脚本时没有硬编码状态，而是把原始值透传到聚合层，在AI提示词里告诉大模型“任务状态可能的取值有哪些”，让AI自己理解。这个方法很实用，减少了字段映射的维护成本。

6.3 AI输出不稳定与提示词调优

AI生成月报质量不稳定的原因通常有两点：一是输入数据里有空值或异常值，二是提示词没有约定清楚输出的边界。我试过让AI“自由发挥”，结果它经常把“未开始的5个任务”解读成“团队效率低下”，这种过度解读很误导人。

后来我在提示词里明确加上“只基于数据做事实性总结，不要臆测没有数据支撑的结论”。这个约束大大减少了AI的脑补。另外，如果发现同一次数据生成的结果相差很大，多半是temperature设太高了，降到0.2基本能稳定。还有一个很有效的技巧是：在输出要求里给一个简单模板，比如“本月完成X个任务，其中X个按期完成，主要风险是X”，这样AI会更按套路出牌。

6.4 数据幂等和增量提取

定时任务最怕重复生成。因为禅道任务和Bug状态会持续变化，如果月底跑了一次、月初又跑一次，可能数据略有不同。我的处理方式是在生成月报草稿时，先判断目标目录里是否已经存在同名文件；如果存在，就备份成带时间戳的历史版本，再写入新内容。这样每次生成都有历史记录，不会因为自动覆盖而丢了上一版。

增量提取方面，任务和Bug我都是按“月份”过滤，比如Bug用resolvedDate，任务用finishedDate，工时用date。这里要注意：一个Bug可能在这个月创建、下个月才解决，如果只按解决时间统计，会漏掉“当月新增”的口径。我建议在JSON里同时保留opened_month和resolved_month两个维度，让AI可以分别解读“新增趋势”和“解决效率”。这个细节看起来不起眼，但月报的价值就在这里。

7. 实际效果与扩展建议

7.1 上线后的效果评估

这套流程跑通之后，我最大的感受是：月报不再是“加班整理”而是“人工复核”。以前我需要花两三个小时从禅道导出、筛选、写分析，现在脚本5分钟内生成草稿，我再花20分钟校对补充，就能交出一份还不错的月报。领导也能更早看到数据，因为月初第一天早上就能收到生成的草稿文件。

效果评估不能光看省了多少时间，还要看分析质量。说实话，AI生成的“项目概况”部分已经可以用了，但“风险预警”和“下月建议”部分还需要人来把关，比如某位同学请了长假这种信息，数据里看不出来，AI也不会凭空知道。所以我的定位是：让AI承担数据整理和初稿生成，人负责做最终判断。这比完全相信AI生成结果或者完全人工写月报都靠谱。

7.2 后续还能做哪些扩展

目前这套方案只做了“月度报告”，但同样的思路可以扩展到每周一生成周报、每天生成项目健康度快照。只要把Dify的输入数据从“月维度聚合”改成“周维度”或“日维度”，脚本逻辑不需要大改。

另一个扩展方向是接入Dify的知识库，把历史项目复盘报告作为参考语料，让AI在生成新内容时能借鉴以前的表述风格。不过这会带来数据隐私和权限的问题，需要谨慎评估。更直接一点的做法是，把生成的月报草稿自动同步回禅道，作为项目附件或文档对象，减少人工上传的步骤。我自己还没完全做完这块，因为企业微信通知、Wiki同步等需求优先级更高，但核心方案已经验证可行。

最后分享一个小技巧：给AI的数据尽量给聚合后的JSON，而不是原始明细。大模型对结构化摘要的把握远好于处理几百条原始记录，而且token消耗也少得多。你花在数据清洗上的每一分钟，都会在AI输出质量上得到回报。