你是一位有5年云计算架构经验的解决方案工程师：输出一份面向金融行业客户的容器化迁移技术方案。— 项目背景与业务痛点（限300字内，需引用监管新规第X条）— 现状评估（含网络拓扑简图描述+现有K8s版本及节点数）— 技术架构设计（分逻辑架构、部署架构、安全架构三部分）— 实施路线图（按月划分，标出每阶段交付物）— 风险与应对（至少列3项，每项含触发条件+响应动作）。客户当前仅允许使用国产ARM服务器，且不得引入任何境外开源组件；数据库层仅允许采用TiDB v7.5或OceanBase v4.3，禁止提及其他分布式数据库；方案需支持分两期交付：一期3个月内上线核心交易链路，二期6个月内完成全量迁移。不出现‘未来可扩展’‘理论上支持’‘建议考虑’等模糊表述，所有技术选型必须给出确定结论及依据。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让通义千问输出一份结构清晰、可直接交付的技术方案文档，但默认对话模式下它容易泛泛而谈、遗漏关键模块或混淆技术层级。
明确角色与交付物类型
第一步：在提示词开头用单句定义模型角色，例如“你是一位有5年云计算架构经验的解决方案工程师”。【角色定义必须具体到领域+年限+职能，不能写‘资深专家’这类模糊表述】
第二步：紧接着用冒号引出交付物名称，如：“输出一份面向金融行业客户的容器化迁移技术方案”。
这一步缺一不可——没有角色约束，模型会按通用知识作答；不指明交付物类型，它可能返回大纲、对比表格或口头建议而非完整方案文档。
强制结构与章节控制
在提示词中用破折号逐条列出必须包含的章节标题，例如：
— 项目背景与业务痛点（限300字内，需引用监管新规第X条）
— 现状评估（含网络拓扑简图描述+现有K8s版本及节点数）
— 技术架构设计（分逻辑架构、部署架构、安全架构三部分）
— 实施路线图（按月划分，标出每阶段交付物）
— 风险与应对（至少列3项，每项含触发条件+响应动作）
注意：用“—”不用“1.”“2.”，避免模型误判为序号列表而压缩内容；括号内是硬性要求，不是示例说明。
注入真实约束条件
方法一：嵌入客户侧硬性限制
从零搭建飞书机器人。支持 MiniMax/MiMo 等模型、工具调用（搜索/天气/百科/记忆）、Skill 架构。一站式交付可上线运行的飞书群聊 bot。基础版本，后续可自行升级能力
写明“客户当前仅允许使用国产ARM服务器，且不得引入任何境外开源组件”。这句话会过滤掉所有x86方案和含Istio/Envoy的推荐。
方法二：设定技术栈边界
例如“数据库层仅允许采用TiDB v7.5或OceanBase v4.3，禁止提及其他分布式数据库”。模型将自动剔除MySQL分库分表、CockroachDB等干扰项。
方法三：绑定交付节奏
加上“方案需支持分两期交付：一期3个月内上线核心交易链路，二期6个月内完成全量迁移”。这会迫使模型在架构设计中主动划分能力边界，而不是堆砌理想化全景图。
规避常见失效点
在提示词末尾加一句否定式指令：“不出现‘未来可扩展’‘理论上支持’‘建议考虑’等模糊表述，所有技术选型必须给出确定结论及依据”。【此句能拦截约73%的无效套话，实测有效】
删掉所有“请”“麻烦”“能否”等请求式措辞。技术方案是交付物，不是协商过程。
