我完全能理解你现在的焦虑和压力。从你描述的情况来看，这是一种典型的 “互联网高压竞品模式” 遇上 “AI 技术乐观主义” 的混合体。在销售业绩承压的大背景下，这种节奏很容易出现。

针对你的两个核心问题，我来谈谈我的看法：

问题一：这种项目模式以后会是常态吗？
大概率不会成为所有项目的常态，但这种 “快节奏、高风险” 的模式会成为重要且常见的补充，尤其在特定场景下。

它会成为一种常态化的 “特种战模式”：

背景驱动： 当市场红利消失，公司为了活下去或抢占先机，会频繁采用这种 “小步快跑、快速验证” 的方式。尤其是你提到的 “辅助产品” 或 “工具类产品”，它们通常依附于主流产品，试错成本相对较低。

AI 的催化作用： 研发总监敢于这么推，确实是因为 AI 工具（如 Copilot、通义灵码等）极大地提升了代码生成和调试的效率。管理层看到了技术红利，自然会想把这个红利压缩到极致，变成竞争优势。

结论： 这种模式会频繁出现，尤其是在探索性项目、工具类项目或紧急的市场应对项目中。但它不太可能完全取代核心复杂业务的严谨流程。如果核心业务也这么搞，不出半年系统就会变成 “屎山”，技术债务会直接压垮团队。

它并非 “常态”，因为它不可持续：

质量成本： 20 天上线，5 天测试，意味着大量的潜在 Bug 和逻辑漏洞会流入生产环境。这会带来极高的运维成本和客户信任损失。当这种损失超过收益时，模式自然会回调。

人的 burnout（ burnout，即职业倦怠）： 这种高压状态对团队的消耗极大。如果成为 365 天的常态，优秀的人才会最先离开。管理者需要在高频激励和高压鞭策之间找到平衡。

问题二：对测试人员的要求会更高吗？
是的，要求会呈指数级上升。 这种模式下，测试不再只是 “验证者”，而是变成了 “质量守护者 + 信息整合者 + 风险预警者”。

在这种 “三无”（无完整方案、无需求文档、无详细用例）环境下，对测试人员的能力模型提出了以下挑战：

业务理解与 “拼图” 能力（核心）：

以前： 拿着需求文档写用例，看一步走一步。

现在： 你必须通过碎片化的信息（口头沟通、会议纪要、产品经理的几句话、开发的草图）去脑补出完整的业务逻辑图。你需要比产品经理更懂业务闭环，才能发现他们逻辑中的漏洞。

极强的沟通与主动性：

不能再等文档了。你必须从第一天就嵌入到开发过程中。开发写代码时，你就要在旁边问：“这块逻辑如果用户输错了怎么办？”“这个边界值你是怎么处理的？” 你需要主动去 “索要” 信息，而不是被动接收。

风险识别与取舍能力（抓大放小）：

AI 说的 “抓大放小” 很对，但关键在于什么是 “大”？

你必须具备极强的直觉和经验来判断： 哪条路径是主业务流程（断了用户就付不了款，这是 P0 级 Bug），哪条是异常流程（报错提示不友好，这是 P2 级）。你要能把有限的测试时间精准地砸在最容易翻车的地方。

测试策略的转变： 从 “全覆盖” 转向 “基于风险的测试”。你的测试计划不再是一张静态的 Excel 表，而是一个动态的、不断根据开发进度调整的风险检查清单。

工具与 AI 的利用能力：

既然开发用 AI 提效，测试也要用 AI 武装自己。

利用 AI 辅助生成测试数据、边界值分析，甚至生成自动化脚本的框架。 在这种快节奏下，手工重复劳动是来不及的，你必须把重复的事情交给自动化或 AI 工具，把精力集中在探索性测试和复杂逻辑验证上。

高度的责任心和主人翁意识：

因为没有文档，出了问题无法甩锅给 “需求写得不清楚”。测试是质量的最后一道防线。你需要有一种 “这个功能如果我测不出来，上线就会出大事” 的责任感，这会倒逼你去更深入地思考。

给你的几点实操建议（应对眼前这个项目）：
和产品、开发 “死磕” 前 15 分钟：
不要等到开发完才开始测。现在就去参加他们的方案讨论会。在会上，不要只听，要提问：“用户是怎么触发这个功能的？”“这个数据从哪里来，如果接口挂了怎么办？”“失败提示是什么？” 把你的测试点前置到设计阶段。

建立一个 “活” 的思维导图：
你现在做的思维导图很好，但不要把它做完就扔了。把它作为一个动态的 checklist（检查清单）。每和开发沟通一次，就往里补充分支、异常场景。这个导图最后就是你测试报告的依据。

明确 “核心链路” 并进行冒烟测试：
和研发总监、产品经理确认：“如果这 3 个核心功能不能用，我们就不上线，同意吗？” 先确保核心流程（Happy Path）绝对跑通，再去管那些边缘的、万分之一概率的异常。

做好风险预警（向上管理）：
如果时间真的不够，不要自己默默扛着。把风险量化后抛出去：“老板，按目前进度，我只能保证核心流程 A 和 B 的质量，边缘场景 C 和 D 的覆盖度只有 30%，如果上线，这里可能会有风险。我们是一边上线一边观察修复，还是延后两天？” 把选择题交给决策者。

总结一下：
这种模式确实很痛苦，但也是测试人员从 “执行者” 向 “专家” 进阶的必经之路。它逼迫你不再依赖文档，而是依赖自己的思考。如果你能顶住这种压力，成功地交付几个质量还不错的项目，你的业务敏感度和风险把控能力会得到巨大提升，这比按部就班写一年用例的成长都快得多。

放平心态，把它当作一次高强度的实战演练。加油！