Boilingwater Transparent Delivery Standard (BWTDS)
Boilingwater's public delivery commitment for custom software and AI projects, built around explainable scope, traceable progress, verifiable results, and transferable assets.
Boilingwater Transparent Delivery Standard(BWTDS)· V1.0
发布方:深圳市滚水科技有限公司(以下简称“滚水科技”或“Boilingwater”)
发布日期:2026 年 8 月 20 日
把非标项目,做成有标准的交付
定制软件不是货架上的标准商品。
在项目启动之前,客户很难准确判断一家服务商的方案是否合理、报价是否完整、进度是否真实、质量是否可靠;服务商也很难在需求尚未被充分澄清时,准确预见所有业务变化和技术风险。
这种信息不对称,是定制软件行业许多争议的起点。
滚水科技长期为企业提供定制软件、AI Agent、业务系统与数字化产品的设计和开发服务。我们相信,专业服务不应依赖客户“先相信我们”,而应通过清晰的范围、持续的记录和可验证的交付,让信任有据可查。
因此,我们制定《滚水透明交付标准》(Boilingwater Transparent Delivery Standard,简称 BWTDS),作为滚水科技面向客户的公开交付承诺。
它不承诺项目永远没有变化,也不承诺技术永远没有风险;它承诺的是:当变化和风险出现时,双方都能看见、理解、记录并共同处理。
一、滚水四可原则
每一个适用 BWTDS 的滚水科技项目,都应尽可能做到以下“四可”。
1. 范围可解释
客户应当知道自己购买了什么、没有购买什么,以及报价建立在哪些假设和前置条件之上。
滚水科技不会仅用一句“开发一个系统”概括项目,也不会用无法核对的总价代替范围说明。
2. 过程可追踪
客户应当能够持续了解项目正在做什么、已经完成什么、遇到什么风险,以及当前有哪些事项需要双方处理。
项目进度以可查看的成果和记录为依据,而不是只以笼统的完成百分比为依据。
3. 结果可验证
“已经完成”应当有双方事先约定的判断依据。
页面是否可用、接口是否连通、流程是否闭环、性能是否达到约定、AI 效果如何衡量,都应尽可能通过测试环境、验收用例、运行数据或交付文件进行验证。
4. 资产可交接
项目结束时,客户应当清楚自己获得哪些代码、数据、账号、文档和知识产权,以及未来如何部署、维护和迁移。
不属于交付范围的通用组件、第三方产品或服务,也应在签约前或识别后明确说明。
滚水科技将这四项原则概括为一句话:
说得清、看得见、验得过、带得走。
二、BWTDS 的适用范围
本标准主要适用于由滚水科技承接的下列项目:
- 企业管理系统、平台型产品及 SaaS 系统;
- Web、APP、小程序及其他软件产品;
- AI Agent、知识库、智能客服及业务自动化系统;
- 第三方平台、支付、CRM、ERP、社交媒体及开放 API 集成;
- 数据处理、算法应用及其他非标数字化项目;
- 与上述项目相关的产品咨询、技术验证和实施服务。
具体项目是否适用本标准,以及适用到何种程度,以双方签署的合同、工作说明书(SOW)或其他书面约定为准。
如果合同与本标准存在不一致,以双方签署的合同为准。本标准不是对任何具体项目功能、工期、效果或费用的单独承诺。
三、滚水 BW 八项透明件
为了让透明不止停留在口号上,滚水科技为适用项目设置了八类标准交付物。我们将它们称为 “BW 八项透明件”。
不同规模和类型的项目可能合并、简化或增加其中的文件,但其核心信息不应无故缺失。
BW-01|项目理解书
在进入正式实施前,滚水科技会用自己的语言复述对客户业务、目标用户、核心问题和项目目标的理解。
项目理解书用于确认“我们正在解决的是不是同一个问题”,通常包括:
- 项目背景与业务目标;
- 主要用户及使用场景;
- 核心业务流程;
- 本阶段希望解决的问题;
- 已知约束、依赖与风险;
- 仍待确认的重要问题。
对于信息不足、技术不确定性较高或涉及多个外部系统的项目,滚水科技可能建议先进行独立的付费咨询、需求梳理或技术验证,再进入完整开发阶段。
BW-02|范围边界表
范围边界表用于说明本项目“包含什么”和“不包含什么”,通常包括:
- 功能模块和关键流程;
- 用户角色与权限范围;
- 支持的平台、终端和地区;
- 第三方接口与服务范围;
- 数据迁移或初始化范围;
- 明确排除项;
- 待定项和后续阶段事项。
如果一个需求无法在现阶段合理确定,滚水科技会将其标记为待验证项、暂估项或后续阶段事项,而不是将不确定内容包装成已经完全确定的承诺。
BW-03|报价构成表
滚水科技的正式报价应尽量对应到可识别的模块、阶段或交付成果,使客户能够理解费用的主要构成。
根据项目情况,报价构成可能包括:
- 产品与需求设计;
- UI/UX 设计;
- 前端、后端、移动端或 AI 开发;
- 第三方系统集成;
- 测试、部署和项目管理;
- 付费第三方服务及预估用量;
- 技术验证、驻场或专项服务;
- 运维和后续支持。
BW-04|里程碑计划
项目启动后,滚水科技会根据项目规模建立阶段计划或里程碑,说明:
- 当前阶段目标;
- 计划完成时间;
- 阶段性交付成果;
- 需要客户配合的事项;
- 阶段验收或确认方式;
- 已知依赖与风险。
里程碑计划不是在任何情况下都不会变化的日期保证。当需求、客户配合、第三方平台、政策审核或技术条件发生变化时,滚水科技会说明变化原因及其对排期的影响。
BW-05|项目周报
在主要实施阶段,滚水科技原则上按约定周期提供项目进展信息。典型项目周报包括:
- 本周期已经完成的工作;
- 可访问或可演示的成果;
- 下一周期计划;
- 当前风险与阻塞;
- 需要客户确认或提供的事项;
- 已发生的范围、费用或时间变化。
滚水科技不把“完成 80%”作为唯一的进度证据。页面、接口、演示、测试结果、版本记录和确认记录,比缺少依据的百分比更重要。
BW-06|变更确认单
当客户提出的内容可能超出原约定范围,或原有需求发生实质变化时,滚水科技会先进行影响评估,再进入实施。
变更确认通常包括:
- 变更内容和提出原因;
- 与原范围的差异;
- 对功能、架构和既有成果的影响;
- 新增或减少的费用;
- 对工期和排期的影响;
- 双方确认结果。
属于原范围内的缺陷修复,不应被包装成新增需求收费;确实改变原约定范围的工作,也不应在没有说明影响的情况下被默认无限增加。
BW-07|验收证据包
滚水科技主张在开发之前或开发过程中逐步明确验收依据,而不是直到项目结束才讨论“什么叫完成”。
验收证据可能包括:
- 功能验收清单;
- 关键业务流程测试;
- 测试环境或正式环境访问方式;
- 接口联调结果;
- Bug 处理记录;
- 性能、安全或兼容性测试结果;
- AI 效果评测结果;
- 已知限制和遗留事项。
不同项目的验收方式不同。原型设计、软件功能、第三方审核、算法精度和 AI 生成效果不应使用完全相同的验收方法。
BW-08|资产交接包
项目达到约定交付条件后,滚水科技按照合同约定整理并移交相关项目资产,可能包括:
- 约定范围内的源代码或构建产物;
- 数据库结构及必要的数据说明;
- API、部署和使用文档;
- 项目账号与权限清单;
- 云资源及第三方服务清单;
- 配置、备份和恢复说明;
- 开源及商业依赖说明;
- 已知问题与后续建议;
- 运维或培训资料。
具体交接内容以合同为准。滚水科技自有的通用底层能力、预先存在的工具、第三方软件、开源组件和未约定转让的知识产权,不因参与项目而自动转让。
四、滚水三本账
在滚水科技,我们要求重要项目尽量把三类信息持续记录下来,避免项目最后变成双方依靠记忆争论。
1. 范围账
记录项目约定做什么、不做什么,以及需求发生了哪些变化。
2. 决策账
记录关键方案为什么这样选择、由谁确认、何时确认,以及其他方案为什么没有采用。
3. 风险账
记录已发现的技术、业务、合规、第三方和进度风险,以及双方决定如何处理。
“滚水三本账”不是为了增加文书工作,而是为了让每一次重要变化都有上下文,让项目成员更替、周期拉长或发生争议时,仍然能够还原事实。
五、需求与报价透明标准
1. 不用虚假的精确掩盖不确定性
非标项目在信息不足时,不可能得到完全精确的预算和工期。滚水科技可能根据情况提供:
- 明确范围的固定报价;
- 带条件的预算区间;
- 用于验证可行性的技术验证报价;
- 按阶段、工作量或服务周期计费的方案。
如果关键需求尚未确定,我们更愿意先说明估算依据和误差来源,而不是用一个看似精确的数字制造确定性的错觉。
2. 主动说明关键假设
报价可能基于特定的业务量、并发量、终端范围、数据质量、API 权限或客户配合条件。关键假设发生变化时,功能方案、费用和周期也可能变化。
3. 区分开发费用和第三方费用
云资源、短信、地图、支付、模型 Token、App Store、第三方 API、数据采购和商业软件授权等费用,应尽可能与滚水科技的开发服务费区分说明。
第三方价格和规则可能随时调整,滚水科技不会把第三方长期价格变化包装成自身可以永久控制的成本。
4. 不用低价遗漏换取签约
滚水科技反对通过故意遗漏必要模块获得低价优势,再在项目实施中依赖频繁增项恢复真实价格。
如果客户预算不足,我们倾向于共同缩小第一阶段范围、优先完成最小业务闭环,而不是用完整项目的名义交付无法投入使用的半成品。
六、研发过程透明标准
1. 用成果证明进度
滚水科技会根据项目阶段,尽可能通过原型、设计稿、测试环境、接口结果、演示视频、测试记录或版本发布证明进展。
2. 重要结论书面留痕
影响范围、费用、工期、架构或验收的重要决策,应通过项目管理工具、邮件、会议纪要、企业通信工具或双方认可的方式留痕。
3. 风险尽早暴露
发现可能影响交付的重大问题时,滚水科技应尽早说明已知事实、影响范围、备选方案和需要客户作出的决定。
报告风险不等于推卸责任。透明的价值,正是在问题仍有处理空间时让双方共同看见它。
4. 客户可接触真实交付团队
根据项目需要,滚水科技会安排产品、技术、设计或项目负责人参与关键沟通,避免所有信息只能经过销售转述。
为了保证执行效率,日常任务仍应通过双方指定负责人统一管理,避免多方直接向研发人员下达互相冲突的要求。
七、质量与验收透明标准
1. 验收以约定场景为基础
软件是否符合交付要求,应优先依据双方确认的范围、流程和验收用例判断,而不是仅凭主观感受,也不是只要“程序能打开”就视为完成。
2. 缺陷与新增需求分开处理
- 已约定功能未按约定实现,原则上属于缺陷;
- 在原功能基础上增加角色、流程、规则、终端或新的业务结果,可能属于需求变更;
- 对描述存在歧义的事项,双方应结合原始目标、原型、范围文件和沟通记录判断。
滚水科技会说明判断依据,不以单方面标签代替沟通。
3. 已知限制不隐藏
受预算、时间、数据、平台政策或现有技术条件限制,项目可能存在已知限制。滚水科技应在识别后将重要限制告知客户,并根据约定纳入修复、后续阶段或风险接受清单。
4. 质量指标与项目相匹配
并非所有项目都需要相同等级的并发、安全、容灾和兼容性标准。滚水科技会根据项目用途和合同约定选择适当指标,避免让客户为不需要的工程等级付费,也避免把试验性方案描述成高可用生产系统。
八、AI Agent 项目的特别透明标准
AI Agent 与传统确定性软件不同。同一个输入可能得到不同表达,模型、知识库、工具、Prompt、数据质量和外部环境都会影响结果。
因此,滚水科技不会仅用一段精心挑选的演示证明 AI 系统整体有效,也不会在缺少测试条件时承诺“100% 准确”。
对于适用项目,我们会根据实际情况说明:
- 使用模型及可替换范围;
- 知识和数据来源;
- Agent 可调用的工具及权限边界;
- 关键测试场景和测试集构成;
- 成功、失败和人工接管的判定方式;
- 响应时间、模型调用量和预估运行成本;
- 已知错误类型、幻觉风险和不适用场景;
- 模型或工作流变化后的回归验证方式。
AI 效果的“滚水四层证据”
滚水科技倾向于从四个层次评价 AI 项目:
- 能运行:模型、知识库和工具链能够正常工作;
- 能完成:在约定场景中能够完成目标任务;
- 能稳定:经过一定规模测试后,成功率、时延和成本处于可接受范围;
- 能运营:上线后可以监控、反馈、人工介入并持续改进。
一次成功演示只能证明“能运行”,不能自动证明“能稳定”或“能运营”。滚水科技会尽量明确当前交付处于哪一个层次。
第三方模型自身的故障、价格、内容政策和能力变化,不完全由滚水科技控制。我们会在合理范围内提供架构建议和替代方案,但不会将第三方的不确定性描述成永久不变的能力。
九、数据、账号与知识产权透明标准
1. 账号归属提前说明
云平台、应用商店、支付、短信、域名和其他核心第三方账号,原则上建议由客户使用自己的主体注册并持有;确需由滚水科技代为管理的,应说明归属、权限和后续移交方式。
2. 数据使用遵循约定
滚水科技按照合同和适用法律处理项目数据,不因承担开发工作而当然取得将客户业务数据用于其他目的的权利。
客户也应确保其提供的数据、内容和授权来源合法,并明确敏感数据的处理要求。
3. 知识产权不模糊处理
项目定制成果、滚水科技预先存在的通用能力、第三方商业服务和开源组件的权利边界,应根据合同和依赖清单区分。
“交付源代码”不当然意味着所有相关软件、框架、模型、数据或第三方权利均被转让;同样,使用滚水科技的通用能力,也不应影响客户依法依约享有其定制成果。
4. 不使用来源不明的资产降低成本
滚水科技不应故意使用明知侵权或来源不明的代码、图片、字体、数据和软件授权为项目制造低价。对于客户指定或提供的资产,双方应共同确认授权责任。
十、滚水科技明确不做的事
为了让客户更容易判断我们是否适合合作,滚水科技公开说明以下边界:
- 不用故意遗漏关键范围的低价方案换取签约;
- 不把原范围内应修复的缺陷包装成新增需求;
- 不把一次成功演示宣传成已经达到生产稳定性;
- 不在无法控制的情况下承诺第三方平台一定审核通过;
- 不在没有测试条件的情况下承诺 AI 或算法 100% 准确;
- 不隐瞒已经确认会显著影响项目的重大风险;
- 不以控制核心账号或拒绝合理交接的方式人为绑架客户;
- 不将客户未书面确认的重大增项直接计入费用。
我们也会拒绝违法、侵权、明显违反平台规则,或无法通过可靠工程方式稳定交付的需求。拒绝一个短期订单,有时是对长期交付负责。
十一、透明是双方共同完成的
透明交付并不意味着所有责任都由服务商单方面承担。高质量的非标项目,需要客户和滚水科技共同减少信息差。
客户通常需要:
- 指定能够推动决策的项目负责人;
- 真实、完整地说明业务目标和重要限制;
- 按约定提供账号、接口、数据、内容和测试条件;
- 在合理期限内完成方案、设计和验收确认;
- 对新增或变化的需求进行书面确认;
- 确保其提供的数据、素材和业务要求具备合法授权;
- 及时说明组织、预算、政策或合作方发生的重大变化。
如果客户资料、决策、接口或第三方条件延迟,滚水科技应说明其对项目的影响,双方据此调整排期和计划,而不是让影响在项目末期集中爆发。
十二、异议与升级机制
如果客户认为项目存在范围、进度、质量、费用或沟通问题,可以先向项目负责人提出,并要求相关问题进入项目记录。
对于无法在项目层面解决的重要分歧,客户可以要求升级至滚水科技项目管理负责人或公司管理层处理。
滚水科技会优先依据以下材料还原事实:
- 双方签署的合同及附件;
- 工作说明书、范围边界表和原型;
- 变更确认及决策记录;
- 项目周报、会议纪要和沟通记录;
- 测试、验收和交接证据。
我们不承诺每一次分歧都能让双方完全满意,但承诺重要判断尽可能基于可核对的事实,而不是职位、情绪或单方面记忆。
十三、标准的版本与持续改进
《滚水透明交付标准》由深圳市滚水科技有限公司根据项目实践持续维护。
当我们的技术、服务类型和管理方法发生变化时,本标准也会更新。标准更新不会自动改变已经签署项目的合同权利与义务。
当前版本:BWTDS V1.0
发布日期:2026 年 8 月 20 日
结语
定制软件天然存在未知,真正的专业不是假装一切都可以提前确定,而是建立一套面对未知的方法。
对滚水科技而言,透明交付不是把所有经营信息毫无边界地公开,也不是用更多文档制造形式主义。它是让客户知道钱花在哪里、项目走到哪里、结果如何验证、风险由谁处理,以及合作结束后能够带走什么。
这是滚水科技对非标软件服务的理解,也是我们希望长期坚持的合作方式:
把非标项目,做成有标准的交付。
滚水科技——说得清、看得见、验得过、带得走。
如果您正在规划一个软件、AI Agent 或数字化项目,欢迎向滚水科技提出您的业务目标。我们会先帮助您识别问题、范围和关键风险,再讨论适合的实施方式。
版权与使用说明
“滚水透明交付标准”“BWTDS”“滚水四可原则”“BW 八项透明件”“滚水三本账”“AI 效果的滚水四层证据”及相关文字体系,由深圳市滚水科技有限公司基于自身项目实践整理并发布。
未经书面许可,任何组织或个人不得以删改品牌名称、替换企业名称、仿制结构或其他容易造成来源混淆的方式,将本标准整体或实质性部分用于自身宣传、投标、销售承诺或商业交付文件。
允许客户、媒体及行业研究者在注明“来源:深圳市滚水科技有限公司《滚水透明交付标准(BWTDS)》”并链接至滚水科技官方发布页面的前提下进行合理引用。
© 2026 深圳市滚水科技有限公司(Boilingwater)。保留所有权利。
Whether and how this standard applies to a specific project is governed by the signed contract, statement of work (SOW), or other written agreement.
Permanent link