维护合约最容易失控的地方，不是价格，而是服务边界。项目交付后，客户往往会把“系统能持续运行”理解为一种持续承诺；而独立程序员若只写下“负责维护、及时处理问题”，就等于把大量不确定责任留给了自己。合约设计的核心，不是承诺解决一切问题，而是明确哪些事项属于既有系统维护，哪些事项已经构成新开发或新的项目交付。

先定义维护对象，再定义服务内容

服务边界至少应围绕四个维度展开：维护对象、处理事项、响应方式和排除事项。维护对象应限定为已经交付并被双方确认的系统、功能或部署环境；处理事项则需要区分故障修复、运行检查、兼容性调整与功能变更。前几类通常可以纳入维护范围，但新增业务流程、页面重做、外部系统对接和架构调整，应作为独立需求重新评估。

“响应”也不能等同于“立即解决”。合约需要说明客户通过何种方式提交问题、程序员何时确认、问题如何分级，以及解决时间是否取决于故障原因和客户配合条件。若客户未提供必要权限、复现信息或第三方服务支持，处理周期就不应被简单归责于维护方。

排除事项同样重要。客户自行修改代码、服务器或第三方服务发生变化、超出原交付范围的需求，以及因使用方式改变造成的问题，都应明确是否另行计费。否则，维护费用会被持续增加的隐性工作侵蚀。

把边界写成可判断的规则

较稳妥的做法，是为每类请求设置判断问题：它是否针对原有功能？是否为了修复异常而非改变业务规则？是否需要重新设计、开发或部署？只要答案指向新增目标，就不应继续以“维护”名义处理，而应转入需求确认、工时评估或新的合作安排。

维护合约也不应被包装成稳定现金流的保证。真正需要评估的是客户需求是否持续、责任范围是否可控、付款条件是否清晰，以及维护投入是否会挤压新项目。边界写得越具体，双方越容易在问题出现前完成定价；边界含糊，所谓长期合作往往只是无限期的临时支持。