什么情况适合联合共建
- 01
业务模型独特
现有系统解决不了你的核心流程，硬套会造成大量手工绕行
- 02
要沉淀自有资产
希望系统与数据长期属于自己，而不是每年续费的平台账号
- 03
有明确的业务流程
你清楚业务怎么跑，需要的是把它变成系统，而不是被教育怎么做业务
- 04
需要长期迭代
业务会持续变化，系统要能跟着改，不是一次性交付完就荒掉
先判断：选用现有系统，还是联合共建
对比项
选用现有成熟系统
联合共建全新平台
适合的场景
业务场景和现有系统基本吻合
现有系统满足不了核心流程
上线速度
部署配置通常数天内完成
按需求建模后的排期，分阶段推进
前期投入
较低，直接用现成能力
较高，换来确定性和专属能力
功能边界
以现有功能为主，差异处做适配
完全按你的业务模型来建
后续扩展
按需二次开发
源码在手，可持续迭代
从需求到上线，五个阶段
- 01
需求建模
通常 1–2 周禾君负责
- 和你的业务人员逐条过流程、角色与数据
- 把口头描述整理成可执行的系统模型与字段清单
需要你配合
- 确认交付边界与验收标准
- 指定一位业务对接人
- 02
原型设计
通常 1–2 周禾君负责
- 输出页面结构、操作路径与状态流转
- 标注关键交互与异常情况处理
需要你配合
- 确认原型后再进入开发，避免后期大改
- 03
系统开发
按模块分批禾君负责
- Nuxt 4 + Prisma + PostgreSQL 全栈实现
- 按模块交付可运行版本，随时可以看到进度
需要你配合
- 阶段性试用并反馈
- 准备业务测试数据
- 04
测试部署
通常 1–2 周禾君负责
- 测试环境验证、业务数据校验、流程演练
- Docker Compose 部署到你的服务器
需要你配合
- 安排业务人员参与验收
- 准备服务器或云主机
- 05
持续迭代
长期禾君负责
- 遵循语义化版本规范持续发版
- 按需扩展功能，不推倒重来
需要你配合
- 提出业务变化与新需求
补充说明
适用场景
业务模型独特，需要专属系统。
交付什么，怎么验收
标准交付物
部署上线时一并交付，含源码与全套文档。
- 完整系统源码
- Docker 部署脚本
- 运维手册
- 用户操作手册
- 接口文档
- 数据库业务字典
验收标准
每条都可以当面核对，达不到就继续改。
- 1可独立部署源码可编译、可部署运行，不依赖我们持续介入
- 2类型与测试通过全链路 TypeScript 类型检查与测试通过
- 3文档可交接文档齐全，你方团队可基于文档做二次开发
- 4上线有协助部署上线阶段我们协助完成，不是丢包走人
关于共建，你可能关心
外包通常按人天结算、交付即结束；共建是按阶段验收的系统交付，交付的是可长期迭代的产品化系统，配套完整文档与源码，后续升级不需要重新招标。