在一开始就定义好交接
交接应让客户或下一个开发团队能够理解、部署和维护所约定的版本。仅有代码库可能无法说明所需的账户、环境变量、后台任务或某个重要权衡取舍的原因。在实现仍易于解释时，就将这些交付物纳入范围。
对于代理机构，还要确定由谁与最终客户沟通、预览和文档中呈现哪个品牌，以及哪些信息可以共享。白标交付需要明确的沟通和保密协议；它不应依赖于对关系归属的假设。
商定一个可管理的首次合作
一个小型的付费试点可以是一个已定义的功能或集成，并带有明确的验收检查。提供设计、素材、响应式行为、内容以及一位决策者。在实现之前识别缺失的设计状态，如空白屏幕、加载、错误和权限。对照约定范围审查可运行的预览，然后根据结果决定是否继续合作。
试点的费用、周期和可用性需要达成一致。示例时间表是一种规划辅助工具，而非通用的交付承诺。
让 SaaS 的首个版本保持具体
例如，一个预订产品的首个版本可以涵盖一种组织类型、员工和客户账户、一个预订流程、一个运营仪表盘，以及一个付款集成（如果收费是必需的）。定义每个角色能够查看和更改的内容。除非需要用来测试核心服务，否则将市场平台、高级报表和额外的订阅层级推迟处理。为版本的每个部分商定可观察的验收检查和一个审查里程碑。
纳入运营知识
- 源代码与权利： 代码库访问权限、依赖项许可证，以及关于归属和第三方义务的清晰记录。
- 安装： 一条可重现的启动命令，以及一个列出变量名称和用途、但不含机密值的环境模板。
- 发布： 托管和 DNS 归属、部署步骤、迁移、备份和回滚说明。
- 验证： 验收结果、重要的自动化检查、已知限制和未解决的决策。
- 集成： 账户所有者、webhook 配置、计划任务、数据映射和故障恢复。
- 支持： 一个约定的渠道、所涵盖的工作以及升级处理职责。响应时间和持续费用应写入协议中。
对于一个 GitHub Actions 项目， GitHub 的部署环境参考文档 描述了分支限制、审批规则和环境机密。确认代码库套餐和已配置的保护措施；部署指南应说明实际存在的控制机制。
测试是否有其他人能够运行它
一个有用的验收练习是：由原实现者以外的一位获授权人员，在一个干净的环境中按照安装指南操作并执行一次预览发布。记录指南不完整之处。对于一个已有的由 AI 构建的应用，这可能会在任何人承诺剩余开发范围之前揭示缺失的配置。
将开发工具的选择与交付的产品分开。私有 AI 开发环境并不自动意味着该应用包含 AI 功能；使用云端编码工具也不决定产品必须托管在何处。将约定的代码和数据处理安排与账户归属一并记录。
在选择私有或云端 AI 开发工具之前，列出这些工具可以访问哪些代码库、文档和测试数据；处理和日志可能在何处发生；谁可以授权访问；以及合作结束后如何终止访问。将这些需求与拟定的方案、提供商条款和运营工作进行比较。自托管方案仍需要访问控制、补丁修复和监控，而云端方案则需要约定的账户和数据策略。单凭任一标签都不能保证机密性或特定水平的模型性能。
参见 代理机构开发合作, SaaS 与 MVP 开发 以及 AI 交付选项。一次有价值的初步沟通会明确要交付的版本、各方职责，以及交接后客户必须能够自行运行的内容。
