2026 年 6 月 17 日，一套 AI 视频工作流以 28,800 元完成独占授权与源码交付。

这是我第一次走完“开发、报价、成交、交付、收款”的完整商业闭环。它不是我一个人的单打独斗：合作伙伴持续负责需求方的商务沟通与成交推进，我负责技术侧的系统梳理、源码处理、交付文档和本地运行验证。最终结果来自两个人不同职责的协作。

这里复盘的是潜在客户真正关心的问题：一套原团队能运行的工作流，怎样变成另一组人可以接手的交付物。

客户购买的不是一个页面

这套系统用于组织 AI 视频生产流程。它不是单体脚本，而是由多项服务共同组成：

用户端工作流界面
  -> FastAPI 后端
     -> PostgreSQL
     -> Redis
     -> FFmpeg
     -> 第三方生成 API
     -> 对象存储
  -> 实时任务状态

管理后台
  -> 同一后端与数据库

用户端负责素材上传、任务编排与结果查看；后端处理业务数据、异步任务、第三方生成能力和文件链路；管理后台负责用户、任务与运营数据。

成交的核心不是“把几个 AI 接口接起来”，而是将已有业务流程整理为一套可以被使用、部署和继续维护的软件系统。独占授权与源码交付进一步提高了要求：接收方拿到的不能只是压缩后的工程目录，还必须知道依赖是什么、配置在哪里、服务如何启动，以及哪些外部资源需要自行准备。

40 天里，商务和技术是两条线

从首次释放购买意向到最终成交，前后经历了约 40 天。期间出现过重复展示、价格调整和其他方案竞争等变化。

这段过程让我更清楚地看到两类职责的差异：

  • 合作伙伴负责持续衔接需求方，反馈采购意向与商务变化；
  • 我维护可交付的技术资产，澄清源码、授权和部署的边界；
  • 双方在成交前确认价格和分工，避免把商务承诺直接变成没有范围的开发任务。

原报价在成交前经过调整，最终以 28,800 元确认。这个数字能够证明一次真实交易，但不能单独证明产品的市场估值，更不代表所有类似系统都应使用同一报价。价格成立的前提，是当时的功能范围、已有实现、授权方式与交付责任组合在一起。

我负责的技术交付

功能可以运行，只是交付的起点。技术侧真正花时间的是减少系统对原开发环境和个人经验的依赖。

1. 先画清运行边界

我先按真实运行关系梳理前端、后端、管理后台、数据库、缓存、音视频工具、对象存储和第三方 API。

这一步不是为了画一张漂亮架构图，而是回答具体问题：

  • 哪些模块随源码交付；
  • 哪些能力依赖接收方自己的第三方账号；
  • 哪些数据属于原环境，不能进入交付包；
  • 哪些配置必须替换后，系统才能在新环境运行；
  • 本地验证与生产部署分别需要什么。

只有所有权和依赖关系清楚以后，源码清理才有边界。

2. 对源码和配置做脱敏

交付版本不能继续连接原团队的数据库、对象存储或第三方账号。我把运行配置收拢为环境变量，并提供只包含字段说明和安全示例的配置模板。

检查范围也不只包括 password 或 api_key。身份与资产线索还可能藏在：

  • 默认连接字符串和备用配置；
  • 启动、迁移与临时调试脚本；
  • 前端构建变量；
  • 示例请求、日志与异常堆栈；
  • 数据库导出、截图和云资源标识。

文章里不会给出私有字段、真实路由或可复用的业务实现。对客户来说，重要的是知道这项检查被纳入交付流程，而不是看到敏感细节。

3. 将原环境约定改成可说明的配置

系统在长期开发中形成过一些隐式约定，例如用数据库命名或特定视图判断环境。在原团队内部，这些规则依靠成员记忆也能工作；换到一套新的本地数据库后，它们可能让界面状态与真实数据来源不一致。

这次交付没有借机重写整套架构。目标是提供隔离且可运行的版本，因此处理原则是：

  1. 让数据访问落到接收方自己的环境；
  2. 移除原生产资源的连接可能；
  3. 将仍然存在的历史兼容逻辑写进交付说明；
  4. 把非必要重构与本次必须完成的交付拆开。

这是一种范围控制。交付项目最容易失控的地方，就是把“接手需要解决的问题”和“未来可以优化的问题”混在同一张清单里。

4. 把启动经验写成交付文档

内部开发时，启动顺序常常散落在终端历史和个人记忆中。交付文档需要让另一位开发者按依赖顺序完成准备：

  1. 安装 Python、Node.js、PostgreSQL、Redis 和 FFmpeg；
  2. 创建本地数据库并填写环境变量；
  3. 安装并启动 FastAPI 后端；
  4. 分别启动用户端和管理后台；
  5. 检查 API、任务状态、文件处理与前端访问；
  6. 识别生产部署时需要替换的域名、进程和外部资源。

每一段说明都尽量回答四个问题：在哪个目录运行、执行什么、成功时看到什么、失败时先检查什么。

5. 用接手者视角定义验收

“首页能打开”不能代表多服务系统完成交付。我的验收清单关注的是：

  • 空白数据库能否完成初始化；
  • 后端是否连接本地 PostgreSQL 与 Redis；
  • 用户端能否调用 API 并获得任务状态；
  • 管理后台能否读取本地数据；
  • FFmpeg 和文件处理依赖是否可用；
  • 未配置第三方能力时，错误是否清楚；
  • 源码、日志和构建产物中是否仍有原环境信息；
  • 尚未验证的外部能力是否被明确列出。

测试环境能够验证的是本地部署和主要链路，不应被描述为对所有生产环境的保证。把未验证项写出来，也是交付质量的一部分。

最终交付了什么

在不公开私有实现的前提下，这次交付可以概括为：

  • AI 视频工作流相关源码；
  • 用户端、后端和管理后台的运行说明；
  • 数据库、缓存、FFmpeg 与第三方服务的依赖说明；
  • 脱敏后的环境变量模板；
  • 本地环境适配与启动步骤；
  • 已验证范围、外部前置条件和后续维护边界；
  • 对约定范围内系统的独占授权。

最终结果不是“把源码发给客户”这一个动作，而是完成了一次有金额、有授权方式、有分工、有交付物的交易。合作伙伴的商务推进让需求从意向走到成交；技术侧的整理则让成交对象不只是一个只能在原机器运行的项目。

这次交易留下的三个判断

交付能力和开发能力不是一回事

开发能力回答“能不能做出来”；交付能力回答“离开作者以后能不能理解、运行和维护”。后者依赖配置、文档、数据边界、错误路径和验收，而不只是代码量。

报价必须绑定范围

28,800 元不是一个可以复制到所有 AI 项目的价格模板。报价应绑定功能现状、授权范围、源码是否交付、部署责任、第三方费用、维护周期和验收标准。范围没有确定时，先报一个“完整平台总价”往往只是把未知风险留到开发阶段。

商务协作需要写清贡献

这次交易不是我个人独立完成。技术资产、商务触达、持续跟进和成交确认缺一不可。公开案例中如实写清分工，比把协作成果全部包装成个人能力更可信，也便于未来项目在一开始就确定责任人。

我现在可以提供的相关服务

基于这次实践，我更适合承接边界明确的 AI 应用和现有系统改造，例如：

  • Python / FastAPI 后端与 React 前端开发；
  • AI 或第三方 API 接入；
  • 异步任务、状态流转与文件处理链路；
  • 已有工作流的本地化、部署和源码交接；
  • 配置脱敏、运行文档与验收清单整理；
  • 现有系统的问题定位与分阶段改造。

如果需求还很模糊，我倾向于先做一次付费诊断：梳理现有流程、系统依赖、第一阶段范围和验收方式，再决定是否进入开发。这样客户知道第一笔钱买到了什么，开发者也不需要在一个没有边界的承诺里不断加功能。

联系方式和其他公开项目可以在关于页面找到。