各位大佬好，想结合公司现状请教一个问题。
一、公司现状
目前在我们团队：
- 前端研发完成的依据主要是 UI 设计图 + 基本功能可用
- 达到 “能用” 后即认为研发完成，直接提测
- 测试承担查漏补缺角色 这种模式已经形成惯例，且管理层认为没有明显问题。
从现实角度看，我能理解：
- 开发时间紧、任务重
- 先 0-1 完成，保证基本可运行
但在实际执行过程中，出现了一些持续性问题：
- 大量低级问题需要多轮修改
- UI 实现未严格对照产品定义
- 非功能性问题（边界、异常、细节一致性）长期被忽视
- 部分功能未完全按产品定义实现
- 版本在测试阶段反复返工 测试阶段经常在 “补实现”，而不是单纯验证风险。
二、我在思考的改进方向
我在考虑是否可以推动一个轻量级机制：
区分两个概念
- Dev Done（功能能用）
- Ready For Test（达到提测标准） Dev Done ≠ Ready For Test
建立轻量化提测标准（不增加重流程）
例如：
- 实现与产品定义逐条对照，无明显功能缺失
- 主流程与关键异常流程已自测
- 无明显逻辑冲突
- UI 实现与产品定义一致 通过一个简化 checklist 进行自检确认后再提测。
目的不是增加流程负担，而是：
- 减少低质量提测导致的多轮返工
- 降低低级问题比例
- 优化整体交付节奏
- 明确责任边界
责任边界重塑
我理解的理想分工是：
- 产品：对定义完整性负责
- 研发：对实现质量负责
- 测试：对风险验证负责 而不是由测试承担实现质量的补完职责。
三、我目前的困惑
1、在时间紧、任务重的背景下，推行轻量化提测标准是否现实？
2、是否会被认为 “测试在增加门槛”？
3、如何在不激化矛盾的前提下逐步建立这种机制？
4、是否有成熟团队已经实践过类似做法？
四、核心问题
如果持续采用 “能用即提测” 的模式：
- 质量是否会越来越依赖测试发现？
- 研发质量意识是否会被弱化？
- 是否会形成长期隐性成本？ 想听听各位在类似环境下的实践经验