如果想要满足 1、2 点的话，需要使用 agent 来取代目前单一的 LLM 方案，这个后续正在探索，有结果了再进行回复。

感谢你的问题，由于公司提供的模型为公有化模型，与之交互仅能采用 api 的方式进行，无法保留沟通的上下文信息 (即便提供模型回答的 request_id 依旧无法让模型恢复当时沟通的上下文信息)，每次的调用都是全新对话，效果上无法做到与日常使用时的页面对话的便捷程度。
基于这个前提来回答你的问题，1、2 都无法做到。3 的回答，结合我实际落地的情况来说，先整理一个版本，交付模型产出，不满意的点逐步调整，最终让模型基于我满意的输出结构重新整理 prompt。4 的问题中，原子结构指的是每条独立的测试用例？尚未理解，抱歉。

分片也可以，外部定义一个容器，然后分段把内容交付 ai 模型产出结果，然后打包进入外部容器内，我最开始使用 deepseek 的时候用的是这个方案，可行的

qwen3 max 可以支持大量文本，可以考虑切换一下模型

感谢认可

需要结合下一篇文章一起看，这个功能可以理解成一个编辑入口，下一篇文章中介绍了使用 AI 解析需求文档生成对应格式的测试场景，是这篇文章的前置动作。这样可以少了手动录入的环节

输出格式的话，每家公司的测试用例组织形式不同，方案思路是通用的。可以考虑抽离 prompt 作为配置项，支持多种输出格式。

因为录入的信息是综合编写天数：AI+ 人工=8 日，而 AI 的生成占比 0.3，实际是几乎不占用编写天数的，所以总天数 *0.7=综合编写天数 8 天，计算总天数 (纯人工方式，不依赖 AI) 的方式就是 8/0.7

欢迎大家讨论

这篇文章没有提要从零开发什么功能，用的是 elements 的上传组件，文章说的是如何在不具备 OSS、Nginx 的情况下使用 django 代理图片的过程，重点不在于上传这个功能。