最近，我跟团队落地了一个基于 Python 的 AI Web 应用项目，终于让我体会到，大模型与实际业务融合远比简单调用 API 更复杂，也更值得深究。
很多人觉得“大模型接入业务”不就是简单调用接口、传输数据、接收结果吗？
可当我们实际做了才发现，这种看似顺滑的流程，其实非常脆弱。一旦业务稍微复杂，光靠模型 API 堆功能，马上暴露各种问题：上下文丢失、逻辑割裂、输出格式随意。这就像买了一辆超级跑车，却只在狭窄的车库里来回倒腾，根本发挥不了它的真实价值。
我们要的是，让模型真正融入流程。
我们的 Python AI 应用主要实现了四个功能：文档校对、文档生成、智能邮件，以及未来的系统对接展望。
文档校对
第一大功能是文档校对。很多平台已经支持文件上传，但只是粗放地处理。我们设计了专用的 Python 解析脚本，先自动识别文档结构（比如代码的规范格式、财务报表特定指标等），然后结合明确的业务规则调用大模型。这种细致的前置处理，大大提高了模型的输出质量，降低了人工后续的干预。
功能展示：
代码示例：
// 开始核对按钮点击事件
document.getElementById('startCheck').addEventListener('click', async function() {
console.log('开始核对按钮被点击');
const preCheckFile = document.getElementById('preCheckFile').files[0];
const billingFiles = document.getElementById('billingReportFiles').files;
const steps = document.querySelectorAll('.step');
// 步骤1：解析预核对表
startStep(steps[0], '正在解析预核对表...');
updateProgressBar(1);
const preCheckFormData = new FormData();
preCheckFormData.append('file', preCheckFile);
try {
console.log('开始发送预核对表解析请求');
const preCheckResponse = await fetch('/parse_excel', {
method: 'POST',
body: preCheckFormData
});
console.log('预核对表解析请求响应状态:', preCheckResponse.status);
if (!preCheckResponse.ok) throw new Error('预核对表解析失败');
const preCheckResult = await preCheckResponse.json();
parseResults.preCheckData = preCheckResult.data;
completeStep(steps[0], `预核对表解析完成，共 ${preCheckResult.data.length} 条记录`);
// 修改调用方式，直接传入数据
showPartialData([preCheckResult.data]);
} catch (error) {
console.error('预核对表解析出错:', error);
failStep(steps[0], error.message);
return;
}
// 步骤2：解析计费报表
startStep(steps[1], '正在解析计费报表...');
updateProgressBar(2);
try {
console.log('开始发送计费报表解析请求');
for (let i = 0; i < billingFiles.length; i++) {
const billingFormData = new FormData();
billingFormData.append('file', billingFiles[i]);
const billingResponse = await fetch('/parse_excel', {
method: 'POST',
body: billingFormData
});
console.log(`第 ${i + 1} 个计费报表解析请求响应状态:`, billingResponse.status);
if (!billingResponse.ok) throw new Error('计费报表解析失败');
const billingResult = await billingResponse.json();
parseResults.billingData.push(billingResult.data);
}
completeStep(steps[1], `计费报表解析完成，共 ${billingFiles.length} 个文件`);
// 修改显示部分解析数据的调用，传入合并后的数据
showPartialData([parseResults.preCheckData, ...parseResults.billingData]);
} catch (error) {
console.error('计费报表解析出错:', error);
failStep(steps[1], error.message);
return;
}
// 步骤3：AI 分析差异
startStep(steps[2], 'AI正在分析差异...');
updateProgressBar(3);
// 先检查是否已经存在加载元素，避免重复创建
let loadingElement = document.getElementById('aiLoading');
if (!loadingElement) {
loadingElement = document.createElement('div');
loadingElement.id = 'aiLoading';
// 创建加载圈元素
const spinner = document.createElement('div');
spinner.className = 'loading-spinner';
// 创建提示文本元素
const text = document.createElement('span');
text.textContent = 'AI 分析中，请稍候...';
// 将加载圈和提示文本添加到加载提示元素中
loadingElement.appendChild(spinner);
loadingElement.appendChild(text);
document.body.appendChild(loadingElement);
}
try {
console.log('开始发送 AI 分析差异请求');
const compareResp = await fetch('/compare_and_ask', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
pre_check: parseResults.preCheckData,
billing: parseResults.billingData
})
});
console.log('AI 分析差异请求响应状态:', compareResp.status);
if (!compareResp.ok) throw new Error('AI分析差异失败');
const compareResult = await compareResp.json();
parseResults.differences = compareResult.data;
// 显示 AI 分析结果
const parsedResultsElement = document.getElementById('parsedResults');
let resultContent = '';
if (compareResult.data) {
if (typeof compareResult.data === 'string') {
resultContent = compareResult.data;
console.log("resultContent", resultContent);
} else if (Array.isArray(compareResult.data) || typeof compareResult.data === 'object') {
resultContent = `<pre style="white-space: pre-wrap; word-wrap: break-word;">${JSON.stringify(compareResult.data, null, 2)}</pre>`;
}
} else {
resultContent = '未获取到有效的 AI 分析结果';
}
if (parsedResultsElement) {
parsedResultsElement.innerHTML = resultContent;
} else {
console.error('未找到 parsedResults 元素');
}
completeStep(steps[2], 'AI分析差异完成');
// 移除加载提示
if (loadingElement) {
document.body.removeChild(loadingElement);
}
// 步骤4：生成核对报告
startStep(steps[3], '正在生成核对报告...');
updateProgressBar(4);
setTimeout(() => {
completeStep(steps[3], '核对报告生成完成');
// 移除切换到核对结果 tab 的逻辑
}, 1000);
} catch (error) {
console.error('AI 分析差异出错:', error);
failStep(steps[2], error.message);
// 移除加载提示
if (loadingElement) {
document.body.removeChild(loadingElement);
}
}
});
文档生成
第二大功能是文档生成。听起来简单，就是数据填报到报表中，但我们测试发现，GPT 之类的大模型并不擅长处理高度结构化和规则复杂的数据填充。这一步只能依靠 Python 原生脚本实现。我们使用 pandas 等工具，将处理好的结构化数据自动填入模板，实现批量文档输出。
可以实现：一键打印全部，包含8个合同、7个表单样式、97页文档，每月至少节省2人/天工作量。
自动邮件
第三大功能是智能邮件生成和发送。看似简单的邮件自动化，如果仅依靠模型生成内容，常常会缺乏具体业务语境。我们选择了一个巧妙的融合方式：通过前面生成的精准报表结果，让大模型编写出语义清晰且业务贴切的邮件内容，再通过 Python 自动发送邮件，实现无感式的业务流程闭环。
prompt 示例：
你是会议纪要生成专家，请根据如下规则，为每个月不同厂商生成标准格式的项目考核纪要。
【目录结构】
- 每个目录如 `json/3e9f7a`、`json/2a4b6c` 表示不同月份（如 3e9f7a 表示特定年月）；
- 每个目录中包含：
- `a1b2c3.json`：包含厂商 A、厂商 B、厂商 C 各厂商的解析服务数据、评分、金额等结算信息；
- `d4e5f6.json`：包含当月各厂商的考核扣分项目和扣分事由；
- `7g8h9i/`：输出纪要存放路径，其中需生成：
- `x1.json` → 厂商A 纪要
- `y2.json` → 厂商B 纪要
- `z3.json` → 厂商C 纪要
【任务目标】
- 根据 `a1b2c3.json` 与 `d4e5f6.json` 两个文件，为每个厂商生成一个标准会议纪要（JSON格式）；
- 每份纪要内容包括：会议信息、合同名称、考核评分、扣分详情、整改措施、结算信息；
- 请按以下映射关系提取数据生成：
- `"厂商A"` 对应 `x1.json`
- `"厂商B"` 对应 `y2.json`
- `"厂商C"` 对应 `z3.json`
【输出格式】
每个厂商输出一个 JSON 对象，结构统一如下：
{
"title": "...",
"meeting": {
"name": "特定年月考核评审会议纪要",
"date": "下一月份",
"participants": {
"公司X": ["人员A", "人员B", "人员C", "人员D", "人员E", "人员F", "人员G"],
"<厂商全称>": ["参会人列表"]
}
},
"contract": {
"name": "...",
"contract_number": "如有则填写，否则省略"
},
"assessment": {
"period": "特定年月",
"score_criteria": {
"指标1": 40,
"指标2": 20,
"指标3": 30,
"指标4": 10
},
"result": {
"评分": "...",
"扣分情况": "...",
"说明": "..."
},
"整改措施": { ...如有扣分则列出... }
},
"settlement": {
...每个模块的数据...
},
"note": "特此纪要"
}
【细节要求】
- 若某厂商无扣分，写明“扣分情况：无”，说明中突出“支撑稳定、无客户投诉”；
- 若有扣分，需写明模块、扣分原因、影响评分、整改方案；
- 所有金额含税，税率默认 6%，如有单价不同请按预处理文件给出；
- 会议名称与日期需自动根据目录名生成；
- 输出格式为 JSON，不能包含其他文字或注释；
请依次生成每个厂商的纪要，输出为 `7g8h9i/x1.json`、`y2.json`、`z3.json` 文件内容。
外部对接
第四个功能目前还在规划阶段：接入外部系统。我们希望未来实现系统与系统、模型与模型之间的直接交互。
小结
然而，实现前三个功能的过程中，我们也遇到了不少挑战。
1、首先是环境兼容性问题，比如内外网隔离导致的库依赖冲突。为了避免踩坑，我们严格控制依赖版本，争取做到一次构建，到处稳定运行。
2、其次是架构上的博弈。一开始我们希望打造一个通用的文档解析器，但实际运行后发现，业务场景差异巨大，通用型并不能真正适配所有情况。最终我们转向了“通用解析器 + 定制化脚本”的组合模式，既保持了通用性的框架，又能灵活响应不同业务的特殊需求。
3、最棘手的难点在于，大模型本质上并不会真正“思考”。它擅长的是即时响应，却无法贯穿历史上下文，缺乏整体一致性和逻辑重构的能力。为了解决这个问题，我们采用了代码规则前置、输出后验证、必要时人工闭环的三步组合策略，确保模型输出始终稳定可靠。
经过这一系列尝试，我想分享一个关键洞察：真正落地的大模型应用，不能只靠模型 API 堆叠功能，必须依托脚本能力、系统集成能力，以及业务场景的精准判断。
