定制谈得越顺，交付时越容易卡在一句话上：这算标准配置，还是要单独立项开发。把责任写进一张边界单，比上线后再补口径更省成本。
定制需求越具体，越需要提前约定责任：谁提供岗位素材、谁完成流程配置、哪些要求需要单独开发、改动如何计价与验收。本文用「交付责任分解」把定制拆成三段——配置与开发的分界、交付物的清单、变更与验收的规则，并给出可直接套用的边界单字段与验收动作。
为什么边界问题总在交付后才暴露
2026年春招，部分头部企业已把AI能力考核引入招聘环节，评估重点从“你会什么”转向“带着AI能交付什么”。这股变化传导到AI面试的定制需求上，但销售、实施与客户对“定制”的理解往往不同：客户说的是“按我们岗位来”，销售理解成调几个参数，实施看到的却是改流程、改题型、改评分口径。
等到首批候选人跑完，才发现范围、工期和验收都没对齐。已投入的配置和素材整理沉没了，临时加价伤关系，免费补做又拖垮排期。边界单的价值，是把“能不能做”转成“由谁做、做到什么程度、怎么算完成”，让各方在同一张纸上对齐预期。
用「交付责任分解」把定制拆成三段
责任分解不追求把条款写得多，而是把三类责任分开。一类是分界责任：某项需求落在既有配置能力内，还是需要单独开发；一类是清单责任：交付物、素材、账号权限和培训由谁提供、何时到位；一类是规则责任：需求变化如何评估、由谁确认、按什么标准验收。三类混在一起谈，往往出现“都在推进、没人负责”。
这也决定了边界单的写法：先写范围，再写清单，最后写规则。
区分配置与开发，先给判断标准
同一句需求，落在配置还是开发，成本和风险完全不同。配置是在既有能力内调整字段、流程节点、评价维度或权重，通常周期短、可回滚、由实施完成；开发涉及新增能力、接口联调、数据流改造或模型训练，需要排期、测试和单独计价。用一张表固定差异，讨论不易跑偏。
| 判断项 | 配置 | 开发 |
|---|---|---|
| 改动对象 | 既有字段、流程、维度权重 | 新增能力、接口或数据链路 |
| 周期与资源 | 以实施为主，周期较短 | 需排期、联调与测试 |
| 回滚方式 | 可还原原设置 | 需版本与回退方案 |
| 计价与验收 | 计入项目范围，按配置清单验收 | 单独立项，按需求文档验收 |
判断动作可以很具体：让供应商在演示环境里当场改一次，记录改动点与耗时。答不出配置清单、只说“都能配”的，往往说明边界没摸清。涉及私有化部署、深度系统集成或专属模型训练的需求，应当直接归入开发评估。
规定交付物：把口头承诺写成清单
交付物不只是一组账号。边界单至少写清四类内容，每类标注数量、格式、提供方与时间点：
- 配置清单：岗位范围、题目与场景、评价维度、流程节点、权重设置，逐项列明“已包含”与“待确认”。
- 素材与规则：岗位说明、评分口径、人工复核规则、候选人告知文案，由企业提供还是由交付方起草，要写明。
- 环境与权限：账号、角色、数据访问范围、操作日志与导出方式。
- 培训与文档：操作手册、异常处理流程、项目联系人及响应时段。
客户侧素材延迟交付时工期如何顺延，同样要写进单里。没有交付物清单的“定制方案”，本质上只是意向描述。
明确变更验收：按什么判、谁来签
变更条款要回答四个问题：什么情况算变更、由谁提出、多久内给出评估、如何计价并影响验收。常见的变更是岗位调整、流程节点增删、评价维度或权重变化。每一项都应有书面提出渠道和评估时限，避免口头答应后无限扩散。
验收则建议分三段：配置完成验收配置清单，试运行验收线上记录，正式上线验收抽检结果。抽检要同时看AI评分与人工复核的一致性，记录分歧样本。这里必须明确人机分工：AI提供评估结果，录用决定仍由企业按内部制度完成；候选人知情、数据最小化、人工申诉与复核通道，都应在边界单和上线方案中写清。
验收指标也用双方确认的口径，写清分母、样本和时间窗口，比一个漂亮的比例更可靠。
定制交付边界单上的五个字段
把前面的内容收进一张单子，通常包含五个字段：定制范围（含与标准能力的对照）、责任分工（企业方与交付方各做什么）、交付物清单、变更规则、验收与售后。每个字段都要求一份可留存的证据：配置清单、确认记录、试运行日志或抽检表。
边界单不是越厚越好，而是每一项都能找到对应的动作和凭据。
牛客AI面试能覆盖到哪一层
牛客AI面试的能力描述覆盖140+岗位业务场景，支持从专业能力到综合素质的个性定制评估；相关岗位案例提到可为技术、交付、销售等不同岗位定制专属评估模型；系统说明也提到可按企业自身需求定制化配置面试流程和评价标准。这意味着大量岗位适配可以落在配置层完成，不必逐项走开发。
但“能力存在”不等于“本次项目包含”。具体岗位的题型范围、评分权重、流程节点是否在标准配置内，仍需在边界单里逐项确认；启用范围、账号数量和集成方式，也以官方最新信息与项目确认为准。把产品能力当起点而不是承诺上限，边界单才写得实。
常见问题
问：边界单应该在签约前还是上线前确认？
答：签约前定框架，方案评审时冻结本次范围，上线前只做细节确认。签约后再补范围，议价空间和排期都会变窄；后续变化统一走变更条款。
问：供应商说“都能配”，还需要写开发边界吗？
答：需要。要求对方给出配置清单，并在演示环境现场改一次；无法当场配置的项，归入开发评估或列为待确认。口头承诺不构成范围。
问：验收看文档还是看线上运行？
答：先看配置清单是否逐项落实，再看线上试运行记录与抽检结果。两者缺一不可：文档证明约定，线上记录证明系统确实按约定运行。
你的边界单，准备好接受一次岗位调整的检验了吗？
把配置与开发分开、把交付物写全、把变更和验收定清，争议会少一大半。边界写得越具体，后续合作越省心。
