开发经验分享：项目复盘与经验提炼

在软件开发的世界里，完成一个项目交付上线，往往只是阶段性工作的结束。真正能让团队和个人实现跨越式成长的，是项目完成后的深度复盘与经验提炼。复盘不是简单的“庆功会”或“批斗会”，而是一次系统性的回顾、分析与学习，旨在将项目过程中的隐性知识显性化，将个人经验转化为团队资产。本文将结合一个近期完成的、涉及复杂数据处理与AI集成的Web平台项目，从AI技术趋势的把握、敏捷开发中的时间管理以及部署工具链的选择三个核心维度，分享我们的复盘心得与提炼出的实用方法论。

一、拥抱AI技术趋势：从概念验证到生产落地

在本次项目中，我们面临一个核心挑战：如何高效、准确地对用户上传的大量非结构化文本（如报告、邮件）进行智能分类和关键信息提取。最初，团队内部出现了分歧：是采用传统的基于规则和关键词的NLP方法，还是尝试引入预训练的AI大模型？

复盘发现：我们初期过于迷恋大模型的“炫技”能力，直接尝试调用GPT-3.5级别的API进行全量文本处理。这导致了几个问题：响应延迟高、成本不可控、对特定领域术语理解不佳。项目一度在POC（概念验证）阶段停滞。

经验提炼：我们总结出一套“分层AI应用”策略，将AI能力按需、分层地融入系统：

轻量级本地模型打头阵：对于分类任务，我们转而使用scikit-learn训练一个轻量的文本分类模型（如SVM或简单的神经网络），或使用sentence-transformers生成嵌入向量进行相似度匹配。这解决了90%的常规分类需求，速度快、成本为零。
大模型作为精调与兜底：对于本地模型置信度低的样本，以及复杂的信息抽取任务（如抽取特定格式的合同条款），我们再调用大模型API。同时，我们利用大模型生成合成数据，用于增强我们本地模型的训练集。
Prompt工程标准化：我们将对大模型的调用封装成服务，并建立了团队内部的Prompt模板库，确保每次调用的格式和指令清晰、一致，显著提升了输出结果的稳定性和可用性。

技术细节示例： 我们使用Hugging Face的Transformers库部署了一个轻量级模型服务。

# 示例：使用预训练模型进行文本分类（简化版）
from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch

# 加载本地微调好的模型
model_path = "./models/our_text_classifier"
tokenizer = AutoTokenizer.from_pretrained(model_path)
model = AutoModelForSequenceClassification.from_pretrained(model_path)

def classify_text(text):
    inputs = tokenizer(text, return_tensors="pt", truncation=True, padding=True, max_length=512)
    with torch.no_grad():
        outputs = model(**inputs)
    predictions = torch.nn.functional.softmax(outputs.logits, dim=-1)
    # 获取预测类别和置信度
    confidence, predicted_class = torch.max(predictions, dim=-1)
    return predicted_class.item(), confidence.item()

通过这种务实的分层策略，我们既享受了AI前沿技术的红利，又保证了系统的性能、成本可控和可靠性。

二、敏捷开发中的时间管理：从“救火”到“防火”

项目初期，我们严格遵循两周一个迭代的Scrum流程，但依然感到疲于奔命，每日站会变成了“问题汇报会”，而非“计划同步会”。开发周期后半段，为了赶进度，技术债堆积，代码质量下降。

复盘发现：时间管理的失效，根源在于任务拆解粒度不均、对“未知”工作量预估不足（尤其是涉及第三方AI API集成和数据处理的部分），以及并行任务间的依赖关系未被清晰定义。

经验提炼：我们改进了敏捷实践，引入了更精细化的时间管理技巧：

故事点与理想人天的结合：在估算时，不仅使用相对的故事点，对于核心、复杂的任务，强制要求拆解到不超过2个理想人天的粒度。如果无法拆解，则意味着需要先进行一次“探针任务”（Spike），专门用于调研和降低不确定性。
明确区分“开发”与“集成调试”时间：过去我们常把“调用API”估算为0.5天，但忽略了网络调试、错误处理、重试机制、日志记录等集成工作。现在，我们会为任何外部依赖（API、服务、数据库）单独估算集成调试时间，通常是开发时间的30%-50%。
可视化依赖与瓶颈：使用看板工具（如Jira或Trello）的泳道，不仅按“待办、进行中、完成”划分，还增加了“等待中”（如等待设计稿、等待第三方反馈）和“阻塞”（如环境问题、关键技术难题）状态。这使团队能一眼识别瓶颈，及时介入协调。
固定“技术债偿还”迭代：每完成三个功能迭代，安排一个“加固迭代”，不安排新功能，专门用于代码重构、性能优化、文档补充和自动化测试完善。这有效防止了债务的无限累积。

三、部署工具链的选择：自动化与可靠性的平衡

项目的部署目标是混合云环境：核心服务部署在私有Kubernetes集群，部分AI微服务和前端静态资源部署在公有云（如AWS或阿里云）。我们早期使用传统的Shell脚本配合Jenkins，随着服务增多，部署脚本变得冗长且脆弱。

复盘发现：手动干预多、环境差异导致“在我机器上是好的”问题频发、回滚流程缓慢且容易出错。

经验提炼：我们系统性地评估并构建了新的部署工具链，核心原则是一切皆代码，流程全自动化。

基础设施即代码（IaC）：使用Terraform定义所有云资源（VPC、ECS、RDS等），版本化管理，一键创建或销毁一致的环境（开发、测试、生产）。
容器化与编排标准化：所有应用必须提供Dockerfile。使用Helm作为Kubernetes的包管理工具，将应用配置、依赖服务（如Redis、MySQL）打包成Chart，实现一键部署。
CI/CD流水线升级：从Jenkins迁移到GitLab CI/CD（因其与代码仓库集成更紧密）。流水线清晰分为多阶段：

# .gitlab-ci.yml 核心阶段示例
stages:
  - build
  - test
  - scan
  - deploy-staging
  - deploy-production

build-job:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

test-job:
  stage: test
  script:
    - echo “Running unit tests and integration tests...”
    # 具体测试命令

security-scan:
  stage: scan
  script:
    - echo “Running Trivy image scan and SonarQube code analysis...”
    # 安全扫描命令，失败则阻断流水线

deploy-staging:
  stage: deploy-staging
  script:
    - echo “Deploying to staging cluster with Helm...”
    - helm upgrade --install my-app ./helm-chart --values ./values-staging.yaml
  only:
    - main

deploy-production:
  stage: deploy-production
  script:
    - echo “Deploying to production cluster...”
    - helm upgrade --install my-app ./helm-chart --values ./values-production.yaml
  when: manual # 生产部署需要手动触发
  only:
    - main