可以连接什么
第一层尽量不使用专业术语。下面列出可以直接交给我们的具体任务类型。
API 与服务
REST、webhook、队列、实时通道以及第三方平台。
数据库与数据流
同步、迁移、格式转换以及数据一致性规则。
Legacy 系统
当旧系统不能或不值得重写时，在其外部建立适配器和新的集成层。
设备
通过受控接口把物理设备连接到后端、移动端、桌面端和 Web。
你描述问题，我们把它转化为技术方案。
无需提前选择框架、协议或架构模式。先确认实际目标、现有限制以及不能破坏的部分。
谁在使用、现有系统是什么、需要得到什么结果。
第一阶段包含什么，需要与哪些系统集成。
分析后给出工期和工作量，而不是按“页面数量”给出虚假价格。
架构与运行细节
如果你只关心最终结果，可以跳过本节；如果你负责技术部分，这里展示我们如何处理系统内部的复杂性。
01可靠交换比“正常路径”更重要
幂等
重复请求不能意外创建第二次支付、订单或设备命令。
超时与部分失败
当某个参与方不可用或操作只完成一部分时，系统有明确行为。
可观察性
日志和关联 ID 能指出交换在哪个环节中断。
安全
认证、授权以及系统之间的最小必要访问。
02避免集成产生新的技术债
契约
数据格式和错误显式定义，而不是依赖系统之间的隐藏假设。
适配器
外部 API 和 legacy 的特殊行为停留在系统边界。
版本控制
一个系统升级时不必让所有其他组件紧急同步更新。
失败场景
重试、延迟、重复和依赖不可用都作为正式测试场景。
清晰阶段，可验证结果
大型软件项目不应该连续几个月像一个无法观察的黑盒。
- 01
需求分析
任务、用户、限制以及现有系统。
- 02
系统边界
组件、数据、集成关系和关键风险。
- 03
实现
分阶段交付中间结果，并验证关键场景。
- 04
发布
上线、诊断、更新以及后续迭代。
系统集成成本取决于什么
复杂度取决于外部 API 质量、系统数量、数据一致性要求，以及当前系统是否已经具备足够诊断能力。
对非标准软件而言，在需求不清楚时给出精确价格，通常意味着预留很大的风险空间，或者后续不断追加费用。我们先明确系统和风险，再评估真正需要完成的工作。
常见实际问题
不做营销式承诺，只说明在项目开始前能够确定的内容。
没有现代 API 的系统也能集成吗？+
很多情况下可以。可能使用数据库、文件、SDK、webhook、网络协议或专用适配器。首先要找到最安全的集成点。
重试时如何避免重复数据？+
在接口契约层定义操作标识和幂等规则，而不是假设网络永远不会重复请求。
可以把设备接入现有后端吗？+
可以，只要存在可用的技术接口。通常先用独立服务或适配器隔离设备，再让后端面向规范化契约。
当项目跨越多种技术
通过相关页面可以直接进入你真正关心的系统部分。
从一段描述开始就够了。
说明什么需要正常工作、目前已有些什么，以及你希望得到什么结果。
Email ↗