项目沟通里最常出现的一句话是能不能按我们这样改一下。这句话背后可能是很小的配置调整，也可能是一整套定制开发，代价差着几个数量级。能力边界规则里写得很明确：任何跨系统对接的可行性，都要确认接口、字段、权限和联调窗口之后才能表达。而技术侧的判断框架把涉及二次开发和定制开发的需求直接列为高风险场景，理由也很实在，这类需求最容易在信息不全时被口头答应，最后变成没人愿意接的烂摊子。
先把需求分成三类
听到改动需求，先别谈能不能做，先分是哪一类。第一类是配置能解决的：策略怎么组合、页面怎么改、用户组和套餐怎么设、推送怎么分人群，这类需求在系统里基本都有对应能力，改的是参数不是代码。第二类是对接能解决的：和客户已有的系统接上，靠接口交换数据，前提是对方接口开放、字段可映射。第三类才是真正的定制开发：系统里没有对应能力，也不存在现成接口，需要改代码来实现。三类混着谈，报价和排期一定失真。
配置层其实能走很远
很多被当成需要开发的需求，最后在配置层就解决了。不同人群走不同的认证方式、不同时间段推不同的页面、不同区域给不同的带宽、账号到期自动停用、访客自助申请后需要审核，这些看起来像定制，实际是策略和参数组合出来的。前提是实施的人真的把系统能力吃透，而不是按自己熟悉的那几个功能去套。所以第一步应该是让熟悉系统的人对照需求过一遍，把能配置解决的部分先划出来。
接口对接要问清四件事
涉及和客户现有系统对接的，有四件事必须问清楚再答复。接口是不是真的开放，很多系统有接口但不对外开放，或者只对特定合作方开放。字段能不能映射，对方的用户状态和本系统的账号状态语义是否对得上。权限给到什么程度，能不能读、能不能写、有没有配额限制。联调窗口有没有，对方什么时候能配合，有没有测试环境。四件事里任何一件没答案，都不应该给出可以直接落地的结论。
真正需要动代码的通常是哪几类
实际项目里必须定制开发的通常是这几类：认证流程和客户内部审批流程深度绑定，比如要等两级审批通过才放行；计费口径和客户的财务规则强耦合，标准套餐模型表达不了；需要和一套很老的内部系统交换数据，而那套系统只有私有协议。它们的共同特点是业务逻辑长在客户那一侧，通用产品无法预先覆盖。识别出这几类之后，剩下的工作才是评估代价。
代价不只在开发那一次
定制开发的账要往后算。系统升级时定制部分要不要跟着改，改一次多少钱；原来写这段的人离职之后，别人接手要多久能看懂；出现问题时是产品的问题还是定制部分的问题，责任怎么界定。这些后续成本在项目初期往往没人提，等第一次升级或者第一次故障就全冒出来了。所以在评估阶段就应该问清楚：这部分定制由谁长期维护，后期升级怎么处理，有没有文档。
为什么不能口头说可以做
判断框架里有条硬规则：不能把存在一个高成本补救方案直接表述成可以做。技术上几乎总有办法实现，问题是要付出什么代价。如果补救成本明显超出客户当初的预算和选型逻辑，正确做法是把代价讲清楚让客户自己决定，而不是先答应下来再说。口头答应可以做，最后交付不出来或者代价远超预期，损失的是整个项目的信任，比一开始就说清楚要严重得多。
需求描述里的高风险信号
有几类表述听到就该谨慎。对方要求先做个演示看看效果，但说不清验收标准；要求和现有系统的操作习惯一模一样，却拿不出那套系统的接口文档；在不提供任何拓扑、型号、数据规模的情况下要求直接报价；强调不能改现有流程，同时又要求新的管理能力。这些表述的共同点是信息不完整或者约束互相冲突。遇到这种情况，正确的回应是先列出需要确认的清单，确认完再下判断，而不是给一个含糊的肯定。
定制范围要写进合同
如果确实要做定制，合同里要写清四件事：范围边界，做到哪一步算完成，哪些明确不含；验收方式，用什么数据、什么场景、什么标准来验；后续责任，系统升级时定制部分怎么处理的费用由谁承担；交付物，源码、文档、部署说明归谁，客户能不能自己维护。这些条款看着繁琐，但它们是后期不扯皮的唯一依据。只写一句满足甲方需求，等于什么都没写。
折中的做法往往更划算
多数情况下有个更划算的中间路线：用配置和接口先把八成需求实现，剩下那一成用流程补。比如审批流不一定非要写进认证流程里，可以让审批在客户现有系统里完成，审批通过后由管理员或者接口触发开通；特殊的计费口径不一定非要改计费模型，可以用套餐组合加对账脚本来实现。这样做的好处是系统保持标准形态，后续升级不受影响，代价是人工介入多一步。这笔账在多数项目里是划算的。
什么时候应该说做不了
最后要承认，有些需求确实不适合接。改造代价远超客户预算、把标准产品改得面目全非导致无法升级、或者客户真正需要的其实是一套业务系统而不是认证系统，这几种情况下硬接下来对双方都没好处。判断依据是商业合理性那一层：这个方案是不是违背了客户当初的选型逻辑，投入产出是不是明显失衡。把话说清楚，同时给出替代方案，比硬着头皮接下再反复延期要体面得多，也更专业。