Package A
流程自动化启动包
面向报表汇总、数据清洗、文件处理、导入导出等高频重复流程，先把单点流程稳定跑通。
- 先按一个最痛流程收口
- 优先验证“能不能省时间”
- 适合试点项目和第一阶段验证
Cooperation
启动方式 / 标准服务包
Service EntryExecFabric 当前的启动方式围绕真实流程梳理、受控执行接入和小型正式交付三类项目展开，重点是把第一阶段做成可验证、可交付、可复用的闭环。
合作判断的重点不是功能名有多少，而是当前场景是否明确、边界是否清晰、第一阶段是否能形成稳定结果。
更常见的启动方式，是围绕 一个高频、重复、规则相对明确的流程 建立最小闭环。这样更容易验证投入产出，也更容易形成后续扩展的基础。
这页回答的是“什么时候该进入项目交付沟通”，不是“所有用户下一步都应该买什么”。 如果对方还处在免费体验、个人空间脚本位扩容或标准团队版月租 / 年租阶段，优先看会员与支付路径； 只有进入更强隔离、内网、本地桥接或正式项目边界时，才该切到这页。
当前更适合把公开体验、标准团队版、正式项目交付和私有化边界分开讲清楚， 让不同阶段的客户都能快速找到合适入口。
先做一个点先收口范围适合真实场景支持正式交付
EXECFABRIC // SERVICE PACKAGESMAT 04
entry: one painful flow firstmode: delivery / controlled executiongoal: delivery_value / repeatable_solution
DON'T START WITH A BIG EMPTY SYSTEM
Package B
脚本接入与治理包
面向已存在脚本或运维动作，但缺少统一入口、执行前确认、历史留痕和治理边界的场景。
- 脚本 / Skill 接入
- 执行前确认与风险分级
- 历史记录与失败原因可见
Package C
小型私有化交付包
面向已经超出标准团队版边界，需要更强隔离、本地数据或本地脚本接入、正式治理要求和企业 1.0 单租户交付的场景。
- 独立租户与权限边界
- 本地执行桥接与审计
- 支持正式项目交付
Entry Split
哪些场景先不要直接按项目交付谈
| 当前状态 | 更适合的路径 | 为什么 |
|---|---|---|
| 还在第一次体验平台 | 先走免费线 | 先确认这是不是值得继续了解的平台，不急着进入项目报价 |
| 只是个人继续接脚本 | 先走本地脚本位增购 | 这属于轻量扩容，不等于正式团队协作或企业交付 |
| 已经开始多人协作，但需求仍偏标准 | 先走团队版月租 / 年租正式租户入口 | 先用标准 SaaS 路径验证协作是否成立，再决定要不要进入更重交付 |
| 需要更强隔离、内网、本地执行桥接或正式项目验收 | 进入项目交付沟通 | 这时才真正需要谈部署、交付边界、里程碑和服务包 |
Good Fit
当前更适合优先沟通的几类项目
- 报表、文件、数据处理这类高频重复流程
- 已有 Python 脚本，需要接成统一入口的场景
- 本地环境、本地脚本或内网资源需要被受控调度的场景
- 标准团队版已经不够，需要更强隔离、定制页面或正式交付边界的场景
Not A Good Start
当前不建议直接启动的事项
- 范围过宽、没有明确第一阶段边界的定制需求
- 每个客户都要求深度定制，却没有复用空间和不包含项
- 默认整仓源码交付，但又希望平台后面还能持续复用和升级
- 只想做一个“AI 聊天壳”，没有真实执行场景
- 预算极低、但预期长期驻场式支持
- 没有脚本、没有流程、没有要解决的具体问题，却先想做大系统
How We Start
标准启动方式
| 步骤 | 要做什么 | 目的 |
|---|---|---|
| 01 | 先说清当前最痛的流程名称 | 避免一开始就把需求谈得过大、过空 |
| 02 | 说明当前输入、输出和执行频率 | 判断这个点值不值得先自动化 |
| 03 | 按一个点收口范围、周期和不包含项 | 快速给出正式方案和报价 |
| 04 | 先交付最小闭环，再决定第二阶段 | 降低决策难度，也更容易形成复用案例 |
Cooperation Ladder
当前五种合作方式怎么选
| 合作方式 | 适合谁 | 当前更适合解决什么 | 默认不等于什么 |
|---|---|---|---|
| 免费演示 | 第一次了解平台的人 | 先确认执行链路、产品定位和是否值得继续深入 | 不等于企业正式生产环境 |
| 付费咨询 / POC | 已有场景，但范围还没收口的团队 | 先把目标、范围、预算和实施顺序说清楚 | 不等于完整正式交付或无限轮需求沟通 |
| 团队版 SaaS | 标准能力、较轻协作、预算有限的团队 | 低门槛进入正式使用和标准团队协作 | 不等于独立私有化或深度定制项目 |
| 轻量私有化部署 | 想先落一个正式独立环境的小微团队 | 用较小范围先跑通一个正式闭环 | 不等于复杂定制开发或长期驻场 |
| 标准私有化部署 | 需要内网、合规、更强边界和正式验收的客户 | 承接独立部署、正式培训和长期基础支持 | 不等于默认包含全部新增功能和无限支持 |
Implementation
实施和培训当前怎么安排
- 先按范围确认、环境准备、能力接入、联调验收、培训上线这五步推进。
- 培训按角色讲，不把业务负责人、管理员、普通使用人和 IT 运维混成一套大课。
- 上线时不只交一个账号，还会同时交付使用说明、交付说明、热更新说明和结果入口说明。
Support Boundary
后续支持边界先讲清楚
- 已交付范围内问题排查、基础答疑和少量脚本更新通常属于标准支持。
- 新增功能、大范围页面改造、深度第三方集成和驻场陪跑应单独评估。
- 当前建议默认按工作日支持窗口理解，更高响应等级应单独约定。
Why This Structure
这种合作结构的直接价值
- 第一阶段边界更清晰，便于评估和验收
- 更容易在短周期内看到真实结果
- 能先验证流程价值，再决定是否进入第二阶段扩展
- 适合从标准团队版继续上探到企业版和私有化场景
Preparation
进入评估前建议准备
- 一个真实流程名称，以及当前最痛的环节
- 输入、输出、执行频率和当前处理方式
- 现有脚本、文件样例、接口说明或执行规则
- 第一阶段希望达成的结果和时间要求
Next Step
带一个真实流程进入评估，会更高效
进入具体沟通后，重点通常不是继续讨论抽象概念，而是尽快把流程范围、输入输出、周期和第一阶段目标对齐。