登峰造极者，殊途亦同归。

前言 以此文章来记录ProjectS从企划到开发到宣发到上线的全过程，其中涉及玩法构思，资源制作，技术思考，市场分析，上架操作等，几乎包含了从零开始制作独立游戏的全部知识和经验，希望对大家能有所启发，本系列文章将会持续更新 玩法设计 代号ProjectS企划案 技术方案 GamePlay框架 ET7+FariyGUI+huatuo+luban+yooasset接入教程 基于行为树的MOBA技能系统：总目录 ProjectS中的AI转向系统（Context Steering） ProjectS中的体素碰撞和寻路 CI/DI方案 从零开始基于TeamCity搭建项目的CI工作流 剧情架构 PCG框架 ProjectS中的地形系统-Procedural Content Generation（PCG） 渲染框架 ProjectS中的纹素密度规划 ProjectS中的GPU Driven ProjectS中的全局光照系统-Voxel-based Global Illumination（VXGI） ProjectS中的地形系统-Terrian Rendering Proje...

最近把几个平台的投资记录放在一起翻了一遍，感觉还是得写篇东西记一下。 先来个太长不看省流版： 我大概从 2022 年开始主动折腾投资理财，更早那点零星的账户收益谈不上什么投资意识，所以这篇就从自己真正动手选产品、做决定说起。也没什么成功经验好分享，毕竟钱还没赚回来，纯粹把这几年怎么踩坑、怎么改主意的过程记下来。 flowchart TD A["约 2022 年：胡乱选基金定投<br/>不懂，也不太想懂"] --> B["认亏止损<br/>转投货基、债基和国债"] B --> C["“摆烂”阶段<br/>现金管理与稳健理财，慢慢回血"] C --> D["追求更高收益<br/>买股票、主动基金和高端理财"] D --> E["大额亏损吞掉前期积累<br/>整体仍未回本"] E --> F["现在：转向高股息与指数<br/>留足现金...

前言 先给结论：本文拆解的《消逝的光芒 2》肢体切断路径，采用“预先设计断点与伤口资产，运行时选择并执行”的方案。它不属于刀刃划到任意位置，就沿着刀刃轨迹实时切开三角形、生成任意新断面的自由切割。 以前臂为例，制作阶段就已经定义好“左手切断”“左前臂切断”“左上臂切断”等配方。每种配方指定隐藏身体的哪一片区域、伤口放在哪里、用哪块模型封住断口，以及碎块使用什么物理配置。战斗发生时，程序根据命中和伤害条件选中其中一种配方，再把它应用到正在运动的角色上。 问题 提前制作或配置 运行时计算 哪些部位能断？ 可用断点、对应骨骼与身体关系 本次命中选中哪个候选，是否满足切断条件 断掉后露出什么？ 隐藏体积、定位辅助元素、两端补片及体型变体 更新隐藏参数，将补片装到当前姿态下的对应位置 掉下来的肢体是什么姿势？ 模型、蒙皮、骨架与碰撞代理 继承切断瞬间的姿态，计算后续运动、碰撞与落地 这里的“预制”指提前准备断点方案与伤口资产，不意味着提前录好每次掉落动画，也不要求把完整角色预先拆成一堆互不相连的模型。外表仍可以是连续的蒙皮网格；切断时隐藏其中一部分，再用预制补片...

当视频进入登录背景、角色展示、动态 UI 与透明特效后，播放器的职责不再是从头播到尾的线性流媒体。它需要随界面频繁启闭，随剧情演出时间轴精确跳转，与实时 3D 场景混合渲染，并在切后台时释放大块显存、回前台时无缝恢复进度。 CRIWARE、AVPro Video 等成熟中间件提供了可靠的跨平台解码接入，却未能消除生命周期管理的内在复杂性。Unity 组件、原生会话、系统解码器与 GPU 显存往往各行其道，上层业务仍需修补繁琐的状态流转与释放时序。 以 CRIWARE 的 CriMana 为例，Stop() 仅发送异步停止请求，底层实例销毁必须显式调用 Dispose()；应用切后台若涉及渲染挂起，还需使用 PauseOnApplicationPause()，底层 Player 甚至需自行注册 Unity 生命周期回调。普通暂停、后台暂停、停止与销毁的语义各自分散，接入方必须自行维护大量胶水代码以处理预热撤销、对象池复用与快速切歌。CRIWARE Player 官方文档。 AVPro Video 也有据可查：其 3.3.4 版本曾修复 Android ExoPlayer 在尚未执...

前言 在 AGI 浪潮席卷内容生产管线的当下，游戏特效的生成边界正被广泛讨论。然而，目前生成式 AI 在游戏资产与特效领域的探索，绝大多数仍局限于 2D 图像与预渲染序列帧；即使前沿模型具备了直接调度 Blender 等 DCC 工具进行自动化建模与节点搭建的能力，面对高要求的 3D 实时动态交互特效，在微调控制精度、空间物理一致性以及瞬态响应上依然显得捉襟见肘。 当画面从离线生成走向 60 帧的实时交互场景——无论是随角色骨骼动作撕扯翻卷的烈焰，还是在涉水踏步时层层推开的湍流与涟漪——真正决定画面可信度与控制上限的，依然深植于程序化图形学与物理模拟的根基之中。计算流体力学凭借不可压缩连续流场、涡旋拓扑以及对外界扰动的自然耦合，天然赋予了特效极其高级的动态质感与视觉张力。在生成式模型尚难跨越实时动态交互鸿沟的当下，程序化流体模拟依然是一条极具壁垒与深耕价值的硬核路径。 FluidNinja LIVE 2 彻底重构了 1.x 时代的蓝图与纯材质解算链，将整套 2D 纳维-斯托克斯（Navier-Stokes）流体求解管线完整搬进了 Unreal Engine 的 Niagara G...

让所有客户端在同一帧施放同一技能：《混沌与秩序之英雄战歌》战斗系统技术设计 下文把《混沌与秩序之英雄战歌》简称为 HOC1。一场移动 MOBA 战斗看起来很直观：我们拖动摇杆、点下技能，角色移动，目标掉血，屏幕上出现动画和特效。 引擎真正要处理的事情多得多。同一条输入需要在多台设备上落到相同的模拟时刻；技能要经历目标选择、施法校验、前摇、事件触发、伤害、Buff 和表现；渲染帧率与网络抖动还要被隔离在战斗结果之外。 这篇文章把视角锁定在战斗运行时，重点回答三个问题： HOC1 怎样用帧同步把多名玩家的输入组织成一条统一时间线？ 一条施法输入进入这条时间线后，技能系统怎样把它变成完整的战斗结算？ Buff、攻击、阵容部署以及表现层怎样接在同一套 Core 框架上？ 我们会沿一条战斗命令，依次讲清帧同步、技能、Buff、攻击、阵容部署和表现层怎样协作。有普通游戏逻辑经验的朋友，可以顺着这条数据流理解整套设计。 先看全景：四个阶段，一条战斗真值链 整套战斗可以先压缩成四个阶段：输入、同步、模拟、表现。 flowchart LR I[输入阶段<br/>触摸 技能提...

最近在用 AI 做反编译和网络安全相关的学习，陆陆续续踩了一些坑，遂有此文。 我把这个过程叫作“破甲”。这个词听起来多少有点江湖气，不过我的用法很克制，只在自己拥有或者明确获得授权的程序、靶场、协议和测试环境里研究。我的实际需求也很朴素：让模型别看到“反编译”“漏洞”“抓包”几个词就直接结束对话，能够继续参与后面的分析。 目前实践下来，体验好坏主要看前面的上下文有没有搭好。一句神奇提示词撑不起长任务，目标、授权范围、环境和交付物都说不清楚，模型只能把任务往最危险的方向猜。猜完以后拒绝，其实也很正常。 第一步：先把研究模式开对 刚开始时，我会先把研究背景讲清楚，相当于开启一次受约束的安全研究模式。 这里至少要说明几件事： 分析对象是什么，所有权或者授权从哪里来 研究目的是什么，是学习、兼容性分析、漏洞复现，还是恶意代码检测 工作在哪个环境里进行，比如本地副本、CTF、虚拟机或者隔离靶场 哪些动作允许做，哪些动作禁止做 最终需要什么结果，是函数说明、协议文档、风险报告，还是修复建议 这一步看起来有点啰嗦，实际非常省时间。模型知道我们在分析自己的二进制文件，和它以为我们要入侵线上服...

对普通 C# 项目来说，切到新版本通常就是改个 SDK、重新编译一下。LeanCLR 这种自研 runtime 会更底层一些：它要看懂我们写的业务代码，也要看懂 .NET 10 基础类库到底在向 runtime 要什么。 LeanCLR 现在已经有自己的 metadata loader、类型系统、对象模型、解释器、GC、异常、委托、泛型、基础反射和 AOT 生成框架。接入 .NET 10 的重点，是做一层清晰的 BCL / runtime contract 适配：让 LeanCLR 能在明确边界内跑 net10.0 纯逻辑程序集；暂时跑不了的 BCL 能力，也给出清楚的诊断，问题能早一点暴露出来。 为什么专门适配 .NET 10 如果只是想“跑一点 C# 逻辑”，LeanCLR 兼容旧版 corlib，或者自己做一套很小的基础库，也能用。目标一旦变成商业项目、跨引擎迁移、长期维护，.NET 10 就成了新的基线。后面的工具、库、语言特性和项目习惯，都会慢慢围着它走。 第一，.NET 10 是 LTS。按照 Microsoft 的 .NET 10 发布说明 和 .NET 8 / ....

AI 模型对比 最核心的 AI 模型自然是我们对比的首选。尽管各大编程 IDE 都涵括了几乎所有主流 AI 模型，但每家 AI 模型官方调教出的工具肯定是最合适和好用的。 截至 2026.7.1，主流 AI 模型对比如下： Claude Opus 4.8：目前综合能力最强的代码生成模型，在长上下文推理、复杂重构、跨文件理解上仍然是断档水平。特别是对于 Unity、C++、Shader 这类工程链路复杂的场景，Opus 4.8 的规划能力和自查能力肉眼可见地领先，配合 1M 上下文窗口，几乎可以一次吃下一个中小型项目 GPT-5.5：OpenAI 在 2026 年上半年拿出的答卷，主打的是稳。它没有 Opus 那种一冲一个准的爆发力，但是对于经典算法、数学证明、系统设计这类需要长链推理的任务，GPT-5.5 有着极强的准确性，很多 Claude 反复犯错的地方它能一遍过，非常适合做 Code Review 和架构设计 Codex Codex 是 OpenAI 在 2026 年的翻身之作，绑定 GPT-5.5，主打两点：审慎和深度推理。 它和 Claude Code 的差别很像 ...

我之所以翻译这篇文章，是因为看下来有挺多触动点，无论是技术层面还是非技术层面都是如此。 因为我最近也在开发 AI Agent。作者在末尾提到，认为未来的 Harness 想要让循环带来的变更在长期内保持可读，就需要找到一个更好的方法来组合这些越来越复杂的系统。 其实我觉得，我之前做的 NKG AI Flow 就是我自己给出的答案。在不断开发 Agent 的过程中，我不断总结、汇总并理解这些短板和缺点，最终给出了自己的答案，我觉得其实还挺适合的。 所以，我把这篇文章翻译出来给大家看一看，希望也能对大家有所启发。 原文地址：The Coming Loop，原文作者：Armin Ronacher，许可协议：CC BY-NC 4.0。 即将到来的循环 我不再亲自提示 Claude 了。我有一些循环在提示 Claude，并判断下一步该做什么。我的工作是写这些循环。 – Boris Cherny 过去几个月，我看到越来越多人在编程 Agent 上面再搭一层东西。那种感觉，已经不是“用一个编程 Agent”这么简单了。有些发生在 Pi 上，这当然很酷；但模式到处都差不多：把工作扔进某个队列...