高校科研平台交付给我的训练，不只是写 Java 接口，而是在客户需求、既有系统、数据质量、权限边界和上线节奏之间做工程取舍。公开复盘这段经历时，我会保留技术方法和交付经验，但不写入具体客户名称、具体高校名称、内部业务细节、真实数据或合同信息。
定制化交付的第一步是把需求变成边界
科研管理平台覆盖的角色和流程很多，需求往往不是一句“加个功能”就能实现。实施人员、业务老师、技术团队和已有系统之间，需要先对流程、字段、权限、报表口径和上线影响达成一致。
我在这类项目里的重点工作，是把客户表达转换成可实现的模块边界：哪些属于标准流程扩展，哪些需要新表和新接口，哪些只是配置项，哪些会影响历史数据和已有统计口径。
- • 先确认业务流程和角色权限，再进入接口和表结构设计。
- • 对报表和打印类需求，提前确认字段来源、统计口径和导出格式。
- • 对历史数据有影响的需求，必须同步考虑迁移、回滚和验收方式。
定制化模块要贴近业务，也要守住系统结构
成果转化、绩效发放、科研业务表打印、科研考核统计等模块，都有明显的业务差异。它们需要贴合客户流程，但不能为了单个场景把系统结构改得难以维护。
我的做法是尽量把变化收在业务 service、配置、模板和查询条件里，保持 controller、权限、数据访问和公共组件的稳定。这样后续遇到类似客户时，可以复用思路，而不是每次重新写一套不可维护的逻辑。
- • 流程差异优先通过状态、配置和模板表达。
- • 公共能力沉淀为可复用方法，避免散落在页面或接口里。
- • 客户特殊规则需要写清楚触发条件和不适用范围。
系统对接考验的是可靠性和协作
统一认证、人事系统、财务系统和消息待办平台对接，表面上是接口开发，实际更考验边界沟通。双方字段定义、调用时机、异常返回、重试策略、权限映射和联调环境，都可能影响上线结果。
对接类任务我会先整理契约和数据流，再实现适配层。适配层负责把外部系统的不稳定性隔离起来，例如字段缺失、状态码差异、超时、重复推送和历史数据不一致，避免这些问题直接污染核心业务流程。
- • 统一认证重点关注身份映射、会话状态和失败提示。
- • 人事与财务对接重点关注字段口径、同步时机和异常补偿。
- • 消息待办重点关注幂等、重复推送和撤回或状态变更。
数据清洗和迁移不能只靠脚本跑完
科研数据经常来自历史系统、人工维护表格或多来源汇总，可能存在重复人员、字段缺失、名称不一致、旧编码和口径变化。清洗工作如果只追求一次性跑通，很容易在上线后暴露问题。
我更关注可核对的处理过程：清洗规则要能解释，异常数据要能导出确认，迁移前后要有数量和关键字段校验，必要时保留回滚方案。这样实施、业务和开发能围绕同一份结果讨论，而不是只看脚本是否执行成功。
- • 重复数据合并需要明确主记录和字段优先级。
- • 数据库升级迁移需要保留校验 SQL、执行顺序和异常记录。
- • 评审或统计数据提取要确认筛选条件，避免口径误差。
交付经验如何迁移到 AI 应用
这段 Java 全栈交付经验对 AI 应用开发很有帮助。AI 项目同样需要需求边界、数据治理、权限控制、异常降级和可验收结果。模型调用只是其中一个组件，真正决定项目能否落地的是系统是否可维护、可解释、可交付。
例如 RAG 知识库也会遇到类似问题：哪些资料可以进入索引，哪些内容需要脱敏，检索失败怎么提示，来源引用如何校验，外部 Provider 不可用时如何降级。这些并不是纯模型问题，而是工程交付问题。
公开边界
这篇文章只保留通用工程经验，不公开具体客户、具体高校、内部流程细节、真实业务数据、合同信息、账号、接口地址或生产配置。
如果后续需要把这段经历放入简历下载或 AI 问答知识库，也应继续使用脱敏后的职责、技术栈和通用交付方法，避免把客户项目细节变成公开素材。