二开预算怎么估：SOW 与变更单

为什么按页面数估二开预算容易失真？

一张页面可能只是展示已有数据，也可能需要新的权限、报价、审批、状态推进和外部协作。两者的工程工作不同。预算应先描述业务结果，再分解实现和验证范围，不能把“一个客户价页面”当作只增加输入框和保存按钮。若行为没有说清，报价的确定性只是表面确定。

把业务目标写成角色、条件、动作和可核对结果。例如哪些客户适用哪种价格，配置何时生效，成交后怎样冻结，取消与售后如何处理。企业客户价与审批流程基于源码定制（¥900 / 人天），需求确认后给固定总价。先核对源码可复用的部分，再明确新增规则与验收。

一份SOW应包含哪些内容？

SOW是工作范围说明，用于让双方对目标、交付、前提和验收形成相同理解。它应有明确版本，引用讨论依据，并列出未包含项目。流程图、接口表和页面说明可以作为附件，但不应以附件数量代替业务规则。存在冲突时写清优先依据与需要确认的问题，避免实施团队自行猜测。

范围项目	要写明的内容	可用的确认资料
业务目标	谁遇到什么问题，期望哪种结果	场景、现状与业务负责人
包含工作	配置、接口、页面、数据与验证	逐项工作清单和改动边界
排除工作	外部系统改造、历史修复和额外平台	明确排除及后续触发条件
前置输入	授权资料、契约、样本和环境	资料负责人与交付状态
验收方法	正常、拒绝、异常和历史兼容	用例、期望结果与证据形式
运行交接	发布、回退、权限和维护资料	岗位与操作说明
未知风险	资料缺失、规则未定与外部依赖	假设、调查步骤和复评条件

每项验收都应能指回范围内容。若范围只描述正常提交，而验收临时要求所有历史状态兼容，就产生了没有被估计的工作；反过来，已写入范围的拒绝和异常场景，也不能因为页面能够提交就省略。

怎样拆出不直接显示在页面上的工作？

沿业务链从输入到最终结果拆解。确认身份和对象范围，读取所需资料，计算规则，写入状态，调用外部系统，再处理查询、重试和售后。每段识别已有能力、需要调整和需要新建的内容，附固定版本证据。未知部分先调查或试验，不把全部风险塞到一个笼统的“后端开发”项目里。

单体版仓库保留 OpenAPI 契约，管理端和 PC 端提供依据该契约生成接口类型的命令。 已有契约和类型生成能够帮助核对接口边界，但不说明企业全部规则已经实现。新增接口还要处理权限、错误、并发修订和外部映射；如果多个端要同时变化，应分别列出实际路径和验证资料。源码事实与估算假设分开保留，便于需求发生变化时重新判断。

外部资料怎样影响估算？

ERP、WMS或渠道接口没有确定版本时，字段、身份与错误行为都可能继续变化。客户应提供授权资料、真实契约、脱敏样本和测试入口，实施方说明缺失会阻塞哪些工作。不能因为客户端愿意配合，就假定外部供应商可以在任意时间完成改造或开放生产账号。

对依赖建立清单，注明负责方、当前状态和取得条件。资料齐全后复核估算，发现规则变化则走范围调整。若只需先验证可行性，可安排边界有限的试验，明确它不包含正式交付与渠道验收，避免试验结果被误当作全部项目已经完成。

测试和历史兼容为什么要独立列项？

新功能经常影响旧订单、旧权限或已有接口调用方。验证要说明测试数据从哪里来，覆盖哪些状态，结果怎样核对。历史资料不能未经授权复制到开发环境；脱敏与合成样本的整理也需要实际工作。构建通过只证明产物能够生成，不证明业务变化满足需求。

金额与售后的现有约束为：金额以元为单位、使用精确十进制和接口字符串；积分、会员折扣与数量退款各有计算器，退款从冻结成交金额按累计数量差额分配。 如果定制影响报价、成交或退款，就需要检查冻结资料及旧记录的解释能力，而不只是新页面显示正确。数据结构变化还要核对迁移角色与历史保全，参照数据库迁移文档形成具体检查项。

未知项应该怎么写进预算？

区分已了解的工作和仍需调查的风险。对风险写触发条件、调查方式、影响范围和决定岗位；获得证据后更新估算版本。不能用任意百分比或虚构工时包装未知，也不能承诺资料尚未提供时已经锁定完整周期。需求确认后给固定总价，详见定制开发服务。

先完成最影响方案的验证，能减少后续反复。例如确认外部接口是否支持按业务编号查结果，或确认某段旧代码能否重建。这些试验要有停止条件和结果记录；试验失败时回到方案比较，不继续堆叠临时绕过让项目表面推进。

什么变化需要一张变更单？

新增角色、业务状态、外部对象、终端或历史范围，都可能改变原工作量。即使页面没有增加，规则和验收也可能发生变化。变更单应引用原SOW版本，说明新增或取消的内容、原因、受影响交付及验收，确认费用与安排如何调整。

变更确认之前先处理不依赖它的工作，但不把未确认规则悄悄写进正式发布。实现中发现缺陷与客户新增需求也要区分：原范围承诺的行为没有实现，不能一概当作收费新增项目。依据记录和验收资料判断责任，使范围管理同时保护双方的合理预期。

客户已有开发或使用AI工具时怎么分工？

内部团队可以继续掌握企业规则和数据，商城实施侧提供底座约束与改造协作。把接口、测试和运行交接的交叉点写清，比比较谁写代码更快更有用。AI可以帮助整理代码和候选实现，但业务规则、秘密资料、真实渠道及结果核对仍需人负责。

分工后仍由明确岗位决定验收和上线。不要让内部开发、外部实施和运营各自维护一份不同的范围说明，也不要将工具生成的代码量作为完成依据。交付记录应描述结果、证据和限制，让接班人员能够继续维护，而不是只有原实施者了解全部隐含条件。

怎样把估算讨论变成可评审材料？

提交范围版本、拆分清单、依赖、假设、验收和未决问题，要求业务与技术分别核对。费用和周期按实际工作沟通，支持期和升级范围在合同中确认。使用选型沟通模板整理当前条件，结合定制开发服务讨论实施责任。

回到二次开发专题核对改动位置与升级影响，再阅读扩展开发说明。预算的作用是让工作和责任有依据，并不保证所有需求都能无成本吸收，也不构成固定单价、工期或永久升级承诺。