腾讯混元发布 Hy4 preview：770B 总参数、49B 激活、1M 上下文

@@@space height = 16 @@@

@@@buttonGroupCard

[[buttons]] text = "GitHub" icon = "GitHub" url = "https://github.com/Tencent-Hunyuan/Hy4-preview"

[[buttons]] text = "HuggingFace" icon = "huggingface" url = "https://huggingface.co/tencent/Hy4-preview"

[[buttons]] text = "ModelScope" icon = "modelscope" url = " https://modelscope.cn/models/Tencent-Hunyuan/Hy4-preview"

@@@space height =32 @@@ 今天，我们发布 Hy4 preview，总参数 770B，激活参数 49B，上下文长度 1M，在代码、办公、科学等真实生产力任务上展现出卓越能力。

# 新一代旗舰模型 Hy4 preview 在模型尺寸、上下文长度、数据规模上都进行了显著的扩展，预训练和后训练的共同进步带来了智能水平的又一次巨大提升，稳居开源模型第一梯队。

@@@space height = 16 @@@

# 为生产力而生 通过与腾讯内部软工、游戏、金融、安全等领域顶尖专家的高质量数据共建，Hy4 preview 在各类真实生产力任务上取得显著进步： ## 软件工程 增强长程开发任务的理解、规划、调试与验证能力，进一步提升前端开发的视觉审美和交互质量；

@@@mediaGallerySwiper [[items]] title="《国家古建筑3D》- 古建筑数字孪生网站" type = "video" media_src = "https://hy-model-ap-prod-1258344703.cos.ap-guangzhou.myqcloud.com/llm-blog/default/a951c950/2026082809243397_4ed20a20575db183c706008f94266b28.mp4?q-sign-algorithm=sha1&q-ak=AKIDRl074nOsGdJ9zjMsCRWP3ShmgS3VtX4S&q-sign-time=1787880277;2103240277&q-key-time=1787880277;2103240277&q-header-list=&q-url-param-list=&q-signature=ce1a9352a835dd538539a22a09bb7652a505e821" description="Prompt: 请生成一个名为「国家古建筑3D / National Ancient Architecture 3D」的桌面优先、全视口、可交互古建筑数字卷宗。使用随附的七个 GLB，不得用占位几何体、卡片封面或网络图片替代建筑主体。\n一、成功标准与实现优先级\n最终页面第一眼必须像一份可操作的中国古建筑研究卷宗，而不是 SaaS、商品页或普通纵向落地页。实现时按以下顺序保证质量：\n七个 GLB 全部可加载、切换、拖拽旋转和滚轮缩放。\n固定三栏卷宗布局、宣纸色、宋体、靛蓝标记和细线框准确。\n左侧卷目、中央舞台、右侧资料随当前建筑同步更新。\n自动旋转、演示、复位、截图、全屏和中英文切换可用。\n最后再补充微动效和移动端抽屉，不得牺牲桌面主画面。\n二、素材包契约：只使用这些文件\n将精简素材包原样放入项目的 public 目录或保持等价的公开路径。七个模型共享同一套 Draco 解码器；纹理已嵌入 GLB，不需要额外贴图。\nmodels/gugong.glb 故宫 / Forbidden City\nmodels/potala.glb 布达拉宫 / Potala Palace\nmodels/huanghelou.glb 黄鹤楼 / Yellow Crane Tower\nmodels/tiantan.glb 天坛 / Temple of Heaven\nmodels/changcheng.glb 长城 / Great Wall\nmodels/tulou.glb 福建土楼 / Fujian Tulou\nmodels/mogao.glb 莫高窟 / Mogao Caves\n\ndraco/draco_wasm_wrapper.js\ndraco/draco_decoder.wasm\n\t禁止再次联网搜索、生成或替换建筑模型。\n\t左侧缩略图由对应 GLB 的离屏渲染生成，可缓存为 canvas/data URL。\n\t右侧正面、背面、左侧、右侧视图由同一 GLB 在 0°、180°、−90°、90° 相机角度渲染，不额外依赖图片。\n\t模型加载失败时显示小型靛蓝色重试提示，不允许静默换成占位图。\n三、页面骨架与尺寸\n.app {\n position: fixed;\n inset: 20px;\n display: grid;\n grid-template-rows: 60px minmax(0, 1fr);\n overflow: hidden;\n}\n.main {\n display: grid;\n grid-template-columns: 296px minmax(0, 1fr) 336px;\n min-height: 0;\n}\n\t页面不产生普通纵向滚动；只有左侧列表和右侧详情可独立滚动。\n\t中央舞台占视觉面积 55–65%，模型占舞台高度约 58–76%。\n\t顶部从左到右：菜单、品牌、分类、弹性留白、年代、自转、演示、语言。\n\t三栏和顶部之间只用 1px 细线分隔；转角可有短 L 形制图定位线。\n四、视觉系统\n:root {\n --paper: #F7F2E5;\n --paper-deep: #EFE7D3;\n --paper-active: #F2EAD8;\n --ink: #2A241A;\n --ink-soft: #4A4336;\n --muted: #8A8172;\n --indigo: #22406A; /* RGB 34,64,106 · CMYK 68,40,0,58 */\n --line: rgba(42,36,26,.12);\n --line-strong: rgba(42,36,26,.22);\n}\n\t所有强调元素统一使用靛蓝 #22406A；RGB (34, 64, 106)；CMYK (68, 40, 0, 58)。\n\t背景使用从 #F7F2E5 到 #EFE7D3 的极柔和径向渐变，并叠加 0.025–0.05 的均匀纸张噪点。\n\t中文标题和正文使用 Songti SC / STSong / Noto Serif CJK SC；小型 UI、数字和英文说明使用 PingFang SC / Noto Sans CJK SC。\n\t品牌约 15px、字距 5.4px；正文 12–14px；建筑标题 34–40px。\n\t所有线框纤细、精确、低对比；几乎不使用圆角，禁止厚重阴影。\n五、中央 Three.js 舞台：必须按源参数实现\n使用 Three.js r184、GLTFLoader、DRACOLoader 和 OrbitControls。画布透明，页面纸色从 DOM 背景透出。\nrenderer: antialias=true, alpha=true, pixelRatio=min(DPR, 2), outputColorSpace=sRGB\ncamera: PerspectiveCamera(38, aspect, 0.01, 100)\nambient: #fff4e0, intensity 1.1\nkey: #ffffff, intensity 2.2, position [3, 5, 4]\nfill: #dfe8ff, intensity 0.7, position [-4, 2, -3]\ncontrols: dampingFactor 0.08, zoomSpeed 0.8, autoRotateSpeed 0.9\ninitial camera: theta 0, phi 1.44, radius 5.4, target [0, 0.58, 0]\nnormalization: 模型最大尺寸统一缩放为 2.2，包围盒居中并贴齐地面\n\t建筑下方只添加非常轻的径向接触阴影，不制作明显地板、镜面或环境展台。\n\t拖拽时 cursor 为 grab/grabbing；水平旋转为主，纵向倾斜限制在轻微范围。\n\t用户拖拽、缩放或手动选择建筑时暂停自动演示；自动旋转可独立开关。\n\t组件卸载或切换时释放旧模型 geometry、material、texture 和 Draco/renderer 资源，避免 GPU 内存累积。\n六、七卷数据与联动\nconst buildings = [\n { id:'gugong', nameZh:'故宫', nameEn:'Forbidden City', place:'北京', era:'明清', category:'宫殿' },\n { id:'potala', nameZh:'布达拉宫', nameEn:'Potala Palace', place:'拉萨', era:'唐', category:'宫殿' },\n { id:'huanghelou', nameZh:'黄鹤楼', nameEn:'Yellow Crane Tower', place:'武汉', era:'三国吴', category:'楼阁' },\n { id:'tiantan', nameZh:'天坛', nameEn:'Temple of Heaven', place:'北京', era:'明', category:'坛庙' },\n { id:'changcheng', nameZh:'长城', nameEn:'Great Wall', place:'北疆', era:'秦—明', category:'关隘' },\n { id:'tulou', nameZh:'福建土楼', nameEn:'Fujian Tulou', place:'闽西南', era:'宋元以降', category:'民居' },\n { id:'mogao', nameZh:'莫高窟', nameEn:'Mogao Caves', place:'敦煌', era:'前秦', category:'石窟' }\n].map(x => ({ ...x, model: `/models/${x.id}.glb` }));\n\t左栏标题为『卷目　共 7 卷』；每项显示序号、动态缩略图、名称、地点年代和靛蓝类别标签。\n\t选中项使用 #F2EAD8 背景和左侧 2px 靛蓝线，不放大、不加投影。\n\t顶部分类包括全部、宫殿、楼阁、坛庙、关隘、民居、石窟，只筛选左侧卷目。\n\t舞台页码显示『01 / 07　● ○ ○ ○ ○ ○ ○』并与模型同步。\n\t右侧依次显示多视图、基本信息、70–130 字营造述略和深褐色细边标签。\n七、核心交互与切换\n\t拖拽旋转、滚轮缩放、惯性阻尼必须真实作用于 3D 模型；滚轮进入舞台时不滚动页面。\n\t点击四视图时，将主相机平滑转到对应角度，不打开图片弹窗。\n\t建筑切换总时长 750–1000ms：旧模型 opacity 1→0、scale 1→1.06；新模型 opacity 0→1、scale 0.90→1，并带 4°–8° 的克制旋转交接。\n\t详情和底部标题先淡出，再在新模型可见后分组显现；不得瞬间替换。\n\t自动演示每 3.2–4.5 秒切换下一卷；复位动画 600–800ms；普通 Hover 180–250ms。\n八、工具与状态\n\t顶部：○ 自转、□ 演示、EN/中；状态激活后指示符变靛蓝色。\n\t舞台右侧：↺ 复位、▣ 截图、⤢ 全屏，34px 圆形细边按钮纵向排列。\n\t模型加载时仅在舞台底部显示 2px 靛蓝进度线，完成后 300ms 淡出。\n\t截图只导出中央舞台；全屏针对整个卷宗应用；Tooltip 必须随语言切换。\n九、中英文与响应式\n\t中英文切换覆盖品牌、分类、卷目、建筑名、年代地点、操作提示、详情标题、基本信息、述略、标签和工具提示。\n\t≥1200px 保持 296 / 自适应 / 336px 三栏；900–1199px 缩为约 250 / 自适应 / 300px。\n\t **改变一个现实世界变量，看影响如何沿产业链传播，并最终汇聚到不同公司的经营结果与估值变化。**\n\n建议选择一个结构复杂、上下游关系清晰、市场关注度高的真实行业作为案例，例如 AI 基础设施、半导体、新能源汽车等。具体行业、公司、变量和分析框架可自行选择，以最终展示效果和金融逻辑完整性为优先。\n\n### 核心框架\n\n构建一张可交互的多层金融因果网络，至少覆盖：\n\n**宏观 / 外部环境**\n→ **行业需求与供给**\n→ **产业链环节**\n→ **关键公司**\n→ **核心经营指标**\n→ **利润与现金流**\n→ **公司估值 / 行业价值**\n\n网络应体现真实的上下游关系、竞争关系、供需约束、价格传导以及必要的二阶效应和反馈回路，而不是简单的线性流程图。\n\n### 核心交互\n\n用户应能够：\n\n* 点击任意关键节点并修改其数值；\n* 或输入一个自然语言情景，例如：\n\n * “如果 AI 资本开支下降 30%”\n * “如果 HBM 供给增加 50%”\n * “如果推理成本下降 70%”\n\n模型自动将该变化映射为结构化冲击，并动态展示：\n\n**变量变化**\n→ **影响路径传播**\n→ **上下游公司受影响**\n→ **收入 / 利润 / FCF 等变化**\n→ **估值重新计算**\n\n整个传播过程应有明显的动态视觉反馈，使用户能够直观看到“一个变化如何穿过整个金融系统”。\n\n### 展示重点\n\n不要把产品做成传统研报或普通 Dashboard。\n\n希望第一眼看到的是一张**复杂、精密、可玩的金融系统网络**。\n\n可以大胆设计：\n\n* 多层级节点\n* 产业链 Zoom in / Zoom out\n* 动态冲击波\n* 正负影响路径\n* 节点大小、颜色、连线粗细表达不同金融含义\n* 公司估值实时变化\n* 行业赢家 / 输家重新排序\n* 关键二阶影响\n* 反直觉结果\n* AI 自动生成的一句核心 insight\n\n例如最终能够出现类似：\n\n> “这一冲击最大的受益者并不是 GPU 厂商，而是 HBM；云厂商虽然收入受益，但更高资本开支压低了短期自由现金流。”\n\n### 设计原则\n\n**底层模型可以非常复杂，但用户交互必须非常简单。**\n\n理想体验是：\n\n> **点一个节点 → 改一个数字 → 整个产业重新流动 → 所有影响最终汇聚到估值。**\n\n页面应专业、现代、高级，并具有足够的视觉密度和动态效果，让普通投资者第一眼觉得震撼，同时让金融专业人士能够看出背后的产业逻辑、财务传导和估值推演是严肃的。\n\n具体页面结构、行业选择、节点数量、模型形式、动画方式和视觉语言请自行发挥，以最终呈现一个令人印象深刻的金融能力展示 Demo 为目标。\n\n所有真实世界数据应基于公开信息，事实、市场预期与模型推断需要明确区分。" poster="https://hy-model-ap-prod-1258344703.cos.ap-guangzhou.myqcloud.com/llm-blog/default/9a5ea02f/2026082802363385_1a8f685c15feef92820538fea13ff231.png?q-sign-algorithm=sha1&q-ak=AKIDRl074nOsGdJ9zjMsCRWP3ShmgS3VtX4S&q-sign-time=1787855798;2103215798&q-key-time=1787855798;2103215798&q-header-list=&q-url-param-list=&q-signature=7cc832b662f9d7662092b2b4e4f0771d6cc3def7"

@@@

@@@space height = 56 @@@

## 游戏开发 增强一句需求直接生成可玩原型能力，并能熟练使用游戏引擎，开发者可以通过多轮交互持续完善复杂游戏项目；

[[items]] type = "video" media_src = "https://hy-model-ap-prod-1258344703.cos.ap-guangzhou.myqcloud.com/llm-blog/default/a951c950/2026082809334733_169fbc25818e8d9c6f83eb8b075e9786.mp4?q-sign-algorithm=sha1&q-ak=AKIDRl074nOsGdJ9zjMsCRWP3ShmgS3VtX4S&q-sign-time=1787880833;2103240833&q-key-time=1787880833;2103240833&q-header-list=&q-url-param-list=&q-signature=054eb7652e282635b875e24f8f3b109a8eaa1bdf" poster="https://hy-model-ap-prod-1258344703.cos.ap-guangzhou.myqcloud.com/llm-blog/default/c9e0c958/2026082802142653_0c5b94d0ac87004e9528449501241146.png?q-sign-algorithm=sha1&q-ak=AKIDRl074nOsGdJ9zjMsCRWP3ShmgS3VtX4S&q-sign-time=1787854470;2103214470&q-key-time=1787854470;2103214470&q-header-list=&q-url-param-list=&q-signature=da913f3e6c4dc69e2360595000983c5f1a0dd2d4" title="多轮--肉鸽游戏" description="Prompt：任务：做一个可双击打开、离线运行的单文件 HTML 游戏 demo\n风格：手绘绘本 / 田园自然主义（明亮户外，Ghibli 式）\n类型：俯视角自动攻击生存肉鸽（Vampire Survivors 类，但美术反着做）\n技术：原生 three.js r160，vendor 目录本地引入，无 npm / 无打包器\n\n【第一原则：明亮画面 + 色相分离，不是暗色 + 发光】\n同类产品在 300 敌人同屏时都会变「脏、暗、糊」，唯一出路是堆 bloom。\n本作反过来做：底色是饱和的草绿与暖米色，信息层级靠\n「色相分离 + 描边粗细」建立，不靠明暗对比，不靠发光。\n基调是「森林在生病，不是森林死了」——禁止末世、血腥、机械恐怖。\n\n────────────────────────────────\n一、渲染管线（硬约束，任何一条违反就重做）\n────────────────────────────────\n\n1. 禁止清单（明确不要）：\n - 禁止 MeshStandardMaterial / MeshPhysicalMaterial / PBR / envMap / IBL\n - 禁止任何后处理（无 bloom、无 SSAO、无 DOF、无 outline pass）\n - 禁止外部纹理文件、模型文件、字体文件（一切运行时生成）\n - 禁止震屏（camera shake）与顿帧（hitstop / 压慢 timeScale）\n - toneMapping = NoToneMapping，outputColorSpace = SRGBColorSpace\n\n2. Ramp 图集（整套画风的地基）：\n 在 256x256 canvas 上逐行绘制色阶：图集高 100 行（rowH = 256/100），\n 每行是一条水平线性渐变「暗色 -> 亮色」，跃变点默认 0.30，\n 跃变处留 3px 软过渡（soft = 3/256）避免锯齿。未登记的行留纯黑。\n 一个物件类型占一行，用行号索引，例：\n 0 深色远景树冠 / 2 中景树冠 / 9 树干 / 23,24 岩石 /\n 26,27 枯草 / 48,49 地面草地 / 50 小径 / 56 沙 /\n 58,59 草叶 / 73 墙 / 93 屋顶\n 材质 fragment：\n rampX = fit(dot(N, uSunDir), -1, 1, 0, 1) * shadow\n col = texture2D(tRamp, vec2(rampX, rowV)).rgb\n 即：明暗只有两档色块，硬边分界。这是绘本色块的本质，不要磨平。\n\n3. 草地专用规则（最容易做错的一处）：\n 草不能用 dot(N,L) 查 ramp —— 实例化草叶法线杂乱，会发暗发噪。\n 草改用 shadow 值直接查 ramp。\n 另外用 step(0.8, hash) 让 20% 的草采「基行 +1」那条 ramp，\n 靠两行色差造出叶片明暗差异，而不是靠堆面数。\n\n4. 雾在 HSV 空间做，不在 RGB：\n 把颜色转 HSV，按深度把 V 拉向 uFogVal、把 S 拉向 uFogSat，再转回 RGB。\n RGB 线性混白会让远景发灰发脏，HSV 做法会让远景「变淡但仍然是绿的」。\n\n5. 阴影：\n PCFSoftShadowMap，一盏 DirectionalLight（强度 1.0）。\n shadow 值过一遍 smoothstep(uShadowSoftA, uShadowSoftB, shadow) 再用。\n 阴影「染色」而非压黑：以 (1 - shadow) 为权重把阴影区往冷色偏，\n 全亮处完全不受影响。\n 正射阴影相机覆盖 ±95 米，near 1 / far 320。\n\n6. 云影：一张噪声纹理按世界 XZ 采样投在地面上，慢速平移，\n 与 uCloudDepth 相乘。这是让静态画面「活着」的最便宜手段。\n\n────────────────────────────────\n二、程序化世界（全部运行时生成，零外部资源）\n────────────────────────────────\n\n1. 确定性随机：实现 mulberry32，所有散布走种子随机。\n 同一个种子必须生成逐像素相同的场景。\n 不同物种用各自独立的随机流（各带自己的 seed），不要共用一条流 ——\n 否则调整任一物种的数量会让其它所有物种的位置全部漂移。\n\n2. 噪声纹理：一张 canvas 纹理，4 个八度（网格 4/8/16/32，振幅衰减 0.55），\n RGBA 四个通道各存一路不同偏移的噪声，一张图当四张用。\n\n3. 地形：280x280 平面，200x200 段。高度场用三层正弦叠加 +\n 一条单调下降的幂函数（造出「地势往海那边塌下去」）：\n h = 3.2\n + sin(x*0.035)*cos(z*0.030)*3.0\n + sin(x*0.011+1.7)*cos(z*0.014-0.6)*6.5\n + sin(x*0.075+3.1)*cos(z*0.068+2.2)*0.8\n - pow(max(0,(x-34)/58), 1.7) * 22.0\n CPU 与 GPU 必须共用同一个高度函数（散布物件要贴地）。\n\n4. 小径：把噪声纹理阈值化成一张 256x256 遮罩，flipY=false，\n CPU 侧也保留一份像素数据做双线性采样，保证\n 「着色器画成路的地方」和「散布逻辑认为是路的地方」是同一块地。\n 两边不一致会看到树长在路中间。\n\n5. 植被程序化建模（不是 billboard，是真几何）：\n - 树干与枝：沿折线生成锥形管（taperedTube）。\n V 坐标用累积弧长而非 i/(n-1)，U 用实际周长，\n 参考向量用平行传输推进（不要用 Frenet 框架 —— 切线接近 up 时会翻转，UV 会扭）。\n - 每个顶点写一个自定义属性 colorInfo = vec2(rampRow, shakeWeight)，\n 于是整棵树只要一个材质、一个 drawcall；风场强度按顶点权重给，\n 树梢摆得多、树根不动。\n - 目标面数量级：树 ~1150 tris / 灌木 ~570 / 棕榈 ~1000。\n 超了写一个 decimate 简化掉，不要放任面数膨胀。\n\n6. 散布数量（照抄这一组，是平衡过密度与帧率的）：\n 树 108（半径 12-110m，缩放 0.82-1.54）\n 灌木 104（10-110m，0.90-1.90）\n 棕榈 18（贴海岸线一条带）\n 小岩 130（0.85-2.40） 大石 9（3.20-5.60）\n 蘑菇 88（缩放 0.80-0.85，区间刻意很窄）\n 草 30000 路面枯草 32500\n 散布用 tries = count x 14 次拒绝采样，带一个 clumping 参数做成丛，\n 不要均匀撒 —— 均匀撒出来是「草坪」，成丛才是「林地」。\n 合计约 30,000+ 实例 / 约 228,000 三角面 / 目标 60fps。\n\n7. 草的实例化：一个双面 quad + 8 个 patch 的草叶图集\n （canvas 上用二次贝塞尔画 6-10 根白色叶片，当 alpha 用）。\n 每个实例给 4 个随机数（相位/高度/色行/朝向）。\n 量感来自贴图和数量，不来自几何复杂度。\n\n8. 踩草：玩家附近半径内的草顶点朝远离玩家的方向弯折\n （uCharPos / uCharDir / uTrampleR / uTrampleAmp）。\n 顶点位移必须 > 3px 屏幕距离才看得见，否则等于没做。\n\n────────────────────────────────\n三、可读性判据（先标定，再做任何视觉改动）\n────────────────────────────────\n\n相机 PerspectiveCamera(fov 42, near 0.5, far 900)。\n玩法机位用固定偏移向量 camOff = (0, 27.7, 21.45)，俯角约 52 度。\n720p 下：相机距 35.0m，纵向视野 39m -> 1 米约等于 18.46 px。\n横竖同一比例（方形像素）；只有「世界水平长度 -> 屏幕纵向」才乘 sin(52) = 0.79。\n\n铁律：任何小于 3px 的位移或变化都判定为看不见，不要做。\n先写一个测量脚本把这个换算量出来，再动手调数值。别靠肉眼。\n\n滚轮缩放：只改相机沿 camOff 方向的距离倍率，范围 0.55x-1.5x，\n14 档，指数步进，缓动跟随（lerp 系数 dt*9）。\n不要改 fov —— 改 fov 会让透视畸变，玩家会觉得画面在呼吸。\n 0.55x -> 相机 19m，视野 22m（看角色细节）\n 1.00x -> 相机 35m，视野 39m（默认）\n 1.50x -> 相机 53m，视野 60m（看战场全貌）\n\n────────────────────────────────\n四、角色与敌人造型\n────────────────────────────────\n\n1. 材质：玩法层不新建 uniform，直接共享场景那一批引用\n （tRamp / uSunDir / 雾参数 / time）。这样面板改了光照或雾，\n 角色跟着变，不会出现「背景一套、角色一套」。\n\n2. 描边：反向外扩壳（inverted hull），单独一个 side=BackSide 的\n 壳网格沿法线外推。关键细节：\n - 外推方向不能用原始法线，要先按位置焊接顶点求平滑法线，\n 再乘一个斜接补偿倍数（存成 aOutN = vec4(dir, miterScale)）。\n 不做这一步，尖角处描边会裂开。\n - 方向要过实例矩阵，倍数必须原样保留（实例缩放不该改描边宽度）。\n - 主体着色不用这个平滑法线 —— 硬边明暗是绘本色块的基础。\n\n3. 敌人剪影必须正交，三个阵营从轮廓就能分开：\n 木偶阵营 —— 方正硬直（暖木褐 + 靛蓝布）\n 菌丛阵营 —— 圆胖伞状（紫红 + 苔绿）\n 雾灵阵营 —— 半透无定形（青白），唯一一处时间驱动的悬停动画\n 精英词条只用色偏表示（六条词条各一个色相），不要改造型。\n 写一个「剪影差异」测试：把两个敌人渲成纯黑剪影做像素 diff，\n 差异率低于阈值就说明造型撞了，必须改。\n\n4. 步态：不要用时间驱动，用位移驱动 ——\n 给每个单位一个「走多少米算一步」的 len 参数，\n 相位 = 累计位移 / len。这样快走快摆、停下就停，\n 不会出现「站着原地踏步」。\n\n────────────────────────────────\n五、打击感（全部在世界层，镜头一像素不许动）\n────────────────────────────────\n\n明确禁止：震屏、顿帧、径向模糊、色差。\n打击感靠一批 InstancedMesh 特效层承担，每层是一种形状 + 一行 ramp：\n\n 斩击主笔触（弧片，金色，不是绿色 —— 绿刀光铺在草地上等于隐形）\n 斩击笔锋（更窄更亮的一片，晚 0.02s 收，做出「笔迹中间那一道亮」）\n 命中星芒（金）/ 暴击星芒（橙红，换色相而非只放大）\n 命中冲击环（贴地扩散，给落点）\n 受击环 + 定向碎屑（朱红，这个色相全场只有道具在用，不会混）\n 火星扩散 / 冰碎碎片 / 萤光跳动 / 霜环 / 危险预警圈 / 碎叶\n\n实现要点：\n- 每层容量按「同屏最多多少个」给，池化复用，超了静默丢弃，不要崩。\n- 淡出走逐实例不透明度属性 aFade，不要靠缩到 0 退场 ——\n 缩到 0 那几帧它还在画面上缩成一个点，读起来是「被吸回去」而不是「散掉」。\n- 单层平面片（弧片、星芒）所在的层必须 side=DoubleSide，\n 否则背对相机那一帧整片消失。\n\n────────────────────────────────\n六、玩法系统（数值可照抄）\n────────────────────────────────\n\n单局 12 分钟。时间轴：\n 0:00 开局（只有最弱杂兵）\n 3:00 第一座「露心井」—— 可主动拧开提升难度换收益（风险自选）\n 6:00 中期 boss（两阶段，掉进化宝箱）\n 7:00 第二座露心井\n 11:00 终局 boss（三阶段）\n 12:00 超时判失败\n\n玩家基础：hp 120 / armor 2 / moveSpeed 7.2 / crit 0.05 / critDmg 1.5 / pickup 3.2\n属性上限（必须有上限，否则后期数值崩）：\n 局内 hp 成长 进化（藤镰->回旋叶刃，萤针->雷萤针）。\n升级三选一，带刷新 3 / 封印 2 / 放弃换资源 1；\n前 5 级至少出现 2 次新武器；连续 4 次没出进化配套则第 5 次保底。\n\n敌人 5 种：杂兵 / 冲锋者（0.8s 前摇 + 13m/s 冲锋 + 0.9s 硬直）/\n投射者（保持 12m 距离）/ 分裂体（死亡分裂 2 个小型）/ 小型体。\n精英词条 6 条，同一精英最多 2 条，且必须禁掉\n「迅捷 + 无前摇高伤」这类会变成不可读秒杀的组合。\n\n场景碰撞规则（这一组区分很重要）：\n - 树、大石、村舍都是实心的，撞上不停死，沿边缘滑行。\n - 树挡人不挡箭（树冠离地几米，箭从底下过），村舍挡箭。\n 场上一百多棵树，连树一起挡弹的话远程武器整条废掉。\n - 冲锋敌人撞树提前刹住并进硬直 -> 站树后可以骗掉冲锋，\n 树林因此有战术价值，不只是障碍物。\n - 敌人绕障方向按编号定死，不要每帧随机 —— 否则会在障碍前左右横跳。\n\n场上道具「吸铁石」：每 20s 掷骰 45% 命中，落在玩家 9-17m 处，\n24s 未捡自动消失。吃到后 6 秒内全场光尘飞向玩家。\n - 吸附速度不设固定值，按「剩余到手时间」反算，让所有球同时到手\n —— 固定速度会让最远那颗永远差最后一截。\n - 拾取判据用「本帧是否跨过了玩家」，不用「距离小于半径」\n —— 高速下每帧走 3m 以上，按距离判会来回横跳。\n────────────────────────────────\n七、UI 与调参面板\n────────────────────────────────\n\n1. HUD 用 DOM 叠在 canvas 上（不要画在 canvas 里）：\n 左上生命与技能冷却、顶部中央倒计时与下一节点、底部光尘与当前构筑、\n boss 出现时屏幕正上方一条血条并在条上画出阶段刻度。\n 阶段刻度必须来自真实的阶段阈值常量（别两处各写一份）——\n 假刻度比没有刻度更糟：没刻度只是信息少，假刻度是骗人。\n 伤害飘字做世界坐标 -> 屏幕坐标投影。\n\n2. 右侧实时调参面板（H 键开关）：约 45 个滑杆 + 38 个取色器，\n 分组折叠，覆盖：色板每一行的暗色/亮色/跃变点、光照方向、\n 雾的远近与饱和度明度、阴影强度与软硬、云影深度、饱和度提升、\n 风场、每个物种的数量与缩放区间与分布半径、种子输入框、\n 「重新随机」与「恢复默认」按钮。\n 默认值快照必须深拷贝，否则会和活动配置共用引用被一起改掉。\n 改颜色后热重建 ramp 图集，不重启页面。\n\n3. 双模式：默认「观察模式」（OrbitControls 自由看风景、调参、截图），\n Enter 进玩法，Esc 回观察且玩法层完整卸载、场景恢复纯净。\n 观察模式快捷键：O 叠加层 / P 冻结动画 / R 重随机 / H 面板。\n\n────────────────────────────────\n八、交付与自检\n────────────────────────────────\n\n1. 源码分模块（core 渲染核心 / palettes 色板 / geometry 建模 /\n world 世界搭建 / panel 面板 / game 下的 sim·view·hud·config 分离）。\n config 只放数据不放逻辑。\n2. 最后写一个打包脚本，把所有 ES module 转成 IIFE 顺序内联，\n 连同 three.js 一起塞进一个 HTML 文件，双击 file:// 能直接跑。\n3. 每个「拍出来的数」旁边写一条注释，说明上界和下界分别是什么夹出来的。\n 例：冲刺 0.26s —— 短于 0.18s 姿态只展开一半读成瞬移，\n 长于 0.35s 玩家会拿它赶路而不是救命。\n 写不出上下界的数，说明这个数还没想清楚。\n4. 写自动化验收脚本（puppeteer 无头截图 + 断言），至少覆盖：\n 实例数/三角面对账、草与配色、面板控件计数、描边外壳闭合性、\n 角色步态、特效可见度、镜头位移上限（单步 来完成这个游戏\n# Agent 任务提示词：卡牌构筑肉鸽游戏（类杀戮尖塔）从 0 到可发行\n\n## 一、角色与总目标\n\n你是一名独立游戏全栈开发 Agent，需要独立完成一款 **卡牌构筑 Roguelike（Deckbuilding Roguelike）** 游戏的设计、开发、美术、测试与打包。参考标杆是《杀戮尖塔》（Slay the Spire），但玩法数值和内容必须原创，不得抄袭原作的卡牌名称、角色形象与美术资产。\n\n**最终交付物：一个可以双击运行、无需安装 Godot 或任何运行时的 Windows 桌面版游戏（.exe），内容量达到\"完整单章体验\"，且已通过自动化测试验证可玩性与平衡性。**\n\n你必须自主推进到底，不要在中途反复询问细节。遇到需要抉择的地方，选择最稳妥的方案、在进度报告中说明假设，然后继续执行。只有在出现无法自行绕过的阻塞（工具不可用、权限缺失、平台限制）时才停下来向我说明。\n\n---\n\n## 二、可用工具与使用规范\n\n### 1. `dcc-mcp-godot` —— 引擎与工程操作（主力工具）\n- 所有 Godot 工程的创建、场景搭建、节点操作、脚本挂载、资源导入、运行调试、导出打包，一律通过 `dcc-mcp-godot` 完成。\n- **开工第一步**：列出 `dcc-mcp-godot` 实际提供的全部工具及其参数，确认 Godot 版本（优先 Godot 4.x / GDScript），把可用能力清单写进 `docs/TOOLING.md`。后续所有计划必须建立在这份真实能力清单之上，**不要假设某个工具存在**。\n- 如果某项操作 MCP 未直接提供（例如批量写脚本文件），改用文件写入 + Godot 项目重新导入的方式，并在文档中记录这一绕行方案。\n\n### 2. `imageGen` —— 全部美术素材生成\n- 卡牌插画、敌人立绘、遗物图标、UI 框体、背景、地图节点图标等所有视觉资产，全部用 `imageGen` 生成，不得使用来源不明的网络图片。\n- **必须先锁定统一美术风格**：在生成任何正式资产前，先做一轮\"风格试片\"（3 套候选风格各出 3 张图），选定其一，把该风格的**固定提示词后缀**写入 `docs/ART_BIBLE.md`，之后每一张图都必须附加这个后缀，以保证全局风格统一。\n- 建议风格方向（可自行判断后选定）：手绘水墨暗黑幻想 / 厚涂油画哥特 / 扁平化几何符号风。其中扁平符号风在批量一致性上最稳妥。\n- 生成后需要做后处理：统一裁切尺寸、必要时去背景、转 PNG、按命名规范落盘到 `assets/` 对应子目录。\n\n### 3. `dcc-cua` —— 自动化游戏测试\n- 用于驱动真实运行中的游戏窗口，模拟玩家点击、拖拽卡牌、选择路线、结算战斗，进行端到端可玩性验证。\n- 详细测试要求见\"第六节：测试体系\"。\n\n### 4. 其他\n- 版本管理：全程使用 git，每个阶段完成后提交，commit message 说明该阶段产出。\n- 文档：所有设计决策落到 `docs/` 目录下的 Markdown 文件，保持随代码更新。\n\n---\n\n## 三、游戏内容规格（\"完整单章体验\"）\n\n这是**验收下限**，不是上限。数量不达标即视为阶段未完成。\n\n### 核心战斗系统\n- 回合制、单人对多敌；玩家每回合初始能量 **3 点**，抽 **5 张**牌。\n- 三区管理：抽牌堆 / 弃牌堆 / 消耗堆（Exhaust）。抽牌堆空则洗回弃牌堆。\n- **格挡（Block）** 在玩家回合开始时清零（除非有特定遗物/卡牌保留）。\n- 敌人有**意图显示**（攻击数值、防御、buff、debuff、特殊），玩家可据此决策——这是本类型的灵魂，必须实现准确。\n- 状态效果至少包含：力量、敏捷、易伤、虚弱、脆弱、中毒、灼烧、荆棘、缴械、artifact（抵消一次 debuff）。状态的结算顺序必须有明确规则并写入文档。\n\n### 内容数量\n| 类别 | 数量要求 | 说明 |\n|---|---|---|\n| 可玩职业 | **2 个** | 例：重装战士（格挡/力量流）、秘术织梦者（法术连锁/牌序操控）。两者机制必须有本质差异，不能只是数值换皮 |\n| 卡牌 | **80+ 张** | 每职业 ≥35 张专属 + ≥10 张中立卡；含攻击/技能/能力三类；稀有度分普通/罕见/稀有；每张卡有升级形态（共 160+ 形态） |\n| 敌人 | **30+ 个** | ≥20 普通怪 + ≥7 精英 + ≥3 Boss，每个敌人有独立 AI 意图模式，不得复用同一套行为脚本 |\n| 遗物 | **40+ 件** | 覆盖开局遗物、Boss 遗物、商店遗物、事件遗物，效果类型要多样（触发式、被动、代价型） |\n| 药水 | **15+ 种** | 即时消耗品，战斗内外可用 |\n| 地图节点 | 单章 **15 层** | 节点类型：普通战斗、精英战斗、随机事件、商店、篝火（休息/升级）、宝箱、Boss。分支路径生成算法需保证每条路径体验均衡 |\n| 随机事件 | **20+ 个** | 每个事件 2-3 个选项，有正/负/风险型结果 |\n\n### 元系统\n- 卡牌奖励三选一（可跳过）、卡牌移除（商店/篝火）、金币经济、爬塔进度存档（中途退出可续玩）。\n- 局内存档 + 结算统计页（本局伤害、回合数、最终卡组、死亡原因）。\n- 主菜单、职业选择、设置（音量、分辨率、全屏）、退出。\n\n---\n\n## 四、技术架构要求（这一节决定项目能否被自动化测试，请严格执行）\n\n1. **逻辑与表现彻底分离**。战斗规则、卡牌结算、敌人 AI、地图生成必须写成纯 GDScript 数据层模块，**不依赖任何 Node2D/UI 节点即可运行**。UI 层只订阅逻辑层发出的信号并做展示。\n - 判定标准：能用 `godot --headless --script` 跑完一整局战斗并输出结果日志。这是后续平衡性测试的前提，做不到就必须重构。\n2. **内容数据驱动**。所有卡牌、敌人、遗物、事件定义放在 `data/*.json`（或 Godot `Resource` 文件）中，代码只负责解释执行。新增一张卡不应该需要改动战斗引擎代码。\n3. **确定性随机**。所有随机使用带种子的 RNG，且不同用途（地图、卡牌奖励、战斗、事件）用**独立的 RNG 流**。任何一局都能用种子完整复现——这是 bug 复现和自动化测试的生命线。\n4. **建议目录结构**：\n ```\n res://\n ├─ core/ # 纯逻辑：battle_engine, card_resolver, enemy_ai, map_gen, rng\n ├─ data/ # cards.json, enemies.json, relics.json, events.json, potions.json\n ├─ ui/ # 场景与控件\n ├─ assets/ # art/cards, art/enemies, art/relics, art/ui, art/bg, audio/\n ├─ tests/ # 单元测试 + headless 模拟器\n ├─ tools/ # 生成脚本、资产处理脚本、平衡性分析脚本\n └─ docs/ # 设计文档、工具清单、美术规范、测试报告\n ```\n5. **性能红线**：战斗场景稳定 60 FPS，场景切换 35% | 该层存在难度尖峰，需重做该层敌人配置 |\n| 单局平均时长（回合数换算） | 25 – 45 分钟 | 过长则加快节奏，过短则加内容深度 |\n| 单卡使用率 | 无卡片使用率 25% | 该卡过强，需削弱 |\n| 遗物拾取后胜率变化 | 每件遗物均有正向但 < 20% 的提升 | 识别过强/无用遗物并调整 |\n| 崩溃 / 死循环 / 卡死回合 | **0 次** | 任何一次都是阻塞级 bug，必须修复后重跑 |\n\n- **调优要迭代**：跑数据 → 改数值 → 重跑，至少完成 3 轮，直到全部指标进入目标区间。每轮改动记入报告。\n\n### 第 3 层：`dcc-cua` 端到端真机测试\n- 运行打包后的真实游戏窗口，用 `dcc-cua` 模拟真人操作，完成以下测试用例：\n 1. **完整通关流程**：主菜单 → 选职业 → 爬完 15 层 → 击败 Boss → 结算 → 回主菜单。两个职业各跑一遍。\n 2. **交互健壮性**：拖拽卡牌到无效目标、能量不足时出牌、连续快速点击、战斗中反复开关设置面板、结算时点击各处——不得崩溃或进入非法状态。\n 3. **存档续玩**：爬到第 8 层强制关闭进程，重开游戏验证进度正确恢复。\n 4. **UI 可读性检查**：在关键节点（战斗中、商店、事件、结算）截图，检查是否有文字溢出、图层遮挡、按钮被裁切、分辨率适配问题。\n 5. **分辨率适配**：至少测试 1920×1080、1600×900、2560×1440 与窗口化模式。\n- 产出 `docs/E2E_REPORT.md`：用例列表、通过/失败、失败截图、修复记录。**所有用例必须最终全绿。**\n\n### 可玩性主观检查清单（自查并在报告中逐条回答）\n- 新玩家不看说明书，能否在 3 场战斗内理解核心规则？\n- 是否存在\"必胜套路\"让每局决策变得无意义？\n- 是否存在开局就注定失败的运气局？\n- 卡组构筑是否真的能玩出至少 4 种差异明显的流派（每职业 ≥2 种）？\n- 死亡时玩家会觉得\"是我的决策失误\"还是\"这游戏不讲道理\"？\n\n---\n\n## 七、质量红线（违反即视为交付失败）\n\n1. ❌ 不得交付带占位图、Lorem ipsum 文本、TODO 注释残留的版本。\n2. ❌ 不得为了让测试通过而弱化测试标准，或跳过失败用例。\n3. ❌ 不得抄袭《杀戮尖塔》的卡名、角色设计、UI 布局像素级复刻或美术资产。机制可以借鉴（这是类型公约），表达必须原创。\n4. ❌ 不得把战斗逻辑写进 UI 脚本里——这会让 headless 测试无法进行。\n5. ❌ 不得在没有实际运行验证的情况下声称某功能\"已完成\"。每一句\"完成\"都必须有对应的运行结果、测试输出或截图支撑。\n6. ❌ 最终 exe 未在干净目录冒烟测试通过，不得宣布交付。\n\n---\n\n## 八、汇报格式\n\n每个阶段结束时，用这个格式简短汇报（不要长篇大论）：\n\n```\n【阶段 Px 完成】\n产出：（3-5 条）\n验收：（对照该阶段验收标准逐条给结论，附关键数据/截图）\n假设与决策：（你自行拍板的地方）\n问题：（阻塞项，或\"无\"）\n下一步：（一句话）\n```\n\n---\n\n## 九、现在开始\n\n从 **P0** 开始执行：先勘察三个工具的真实能力，建好工程骨架，跑通\"空场景 → Windows .exe → 双击运行\"的最小闭环，然后向我汇报。确认导出链路可用后，不要停顿，直接推进 P1。\n" poster="https://hy-model-ap-prod-1258344703.cos.ap-guangzhou.myqcloud.com/llm-blog/default/c9e0c958/2026082801540528_f14b4781120825a7e35317daeefabf64.png?q-sign-algorithm=sha1&q-ak=AKIDRl074nOsGdJ9zjMsCRWP3ShmgS3VtX4S&q-sign-time=1787853246;2103213246&q-key-time=1787853246;2103213246&q-header-list=&q-url-param-list=&q-signature=54c90f166ce1f4ce2051939a854f542362d322e8"

同时，Hy4 preview 持续与 CodeBuddy / WorkBuddy 等产品深度协同，优化生产力场景的真实用户体验。我们组织了163 名内部专家进行了 203 个工程任务的盲测，结果显示 Hy4 preview（均分2.99/4) 略优于 GLM 5.3（均分2.92/4.00；胜46.8%/平12.8%/负40.4%) 和 Kimi K3（均分2.94/4.00；胜51.2%/平7.9%/负40.9%)。

@@@space height = 32 @@@

::: center Hy4 preview API价格（每百万Tokens） ::: ::: center |输入（命中缓存） | 输入 | 输出 | | ------ | ------ | ------ | | 0.3元 | 6元| 18元 | :::

@@@space height = 32 @@@

Hy4 preview 是 Hy4 迭代的一个早期版本，预训练和后训练均仍有较大的提升空间，也有一些已知问题，如复杂任务的长思考和过度自我验证倾向，我们将持续敏捷迭代。如同 Hy3 preview，我们希望通过 Hy4 preview 的尽快发布获得广泛的真实反馈，从而显著提升 Hy4 正式版。同时，我们将坚持发挥与腾讯产品和专家深度合作的独特优势，持续提升生产力的普惠性和上限。