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

前言 以此文章来记录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...

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

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

让所有客户端在同一帧施放同一技能：《混沌与秩序之英雄战歌》战斗系统技术设计 下文把《混沌与秩序之英雄战歌》简称为 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 上，这当然很酷；但模式到处都差不多：把工作扔进某个队列...

前言 最近这段时间一直在做 AI Agent，越做越觉得这事和最开始想的还真不太一样。 一开始大家很容易把注意力放在 Prompt 上，觉得只要规则写得足够细，模型够聪明，事情就能办成。讲道理，这个阶段当然是有用的，尤其是单次任务里，Prompt 写好一点，结果立竿见影。 但真把 Agent 放进一个持续运行的业务流里，问题就完全不是这么简单了。 它不是问一次答一次，而是要拿数据、调工具、过规则、看日志、做验证，失败了还得知道从哪里重新来。这个时候你就会发现，大模型本身只是其中一环，真正决定 Agent 能不能稳定跑起来的，反而是那些看起来很无聊的工程细节。 所以这篇文章就先记一下我目前开发 AI Agent 的一些体感。后面想法肯定还会变，但至少现在看，这几个点已经不是锦上添花了，而是地基。 Harness AI 最应该放在第一个讲的，我觉得还是最近提到比较多的 Harness AI。 如果说大模型提供的是推理能力，那 Harness AI 更像是把推理能力接进真实业务流程里的那套线束。它关心的不是模型某一次回答漂不漂亮，而是输入从哪里来，数据怎么过节点，什么时候调用工具，调用...

开源地址： https://github.com/wqaetly/nkg-ai-flow 前言 最近 Agent、Workflow、Harness、AI Native 这些词越来越热，我自己实践下来最大的感受是：LLM 固然很强，但不够稳定。 它很像一个极其聪明的推理核心。给它清楚的上下文，它能总结、规划、写代码、调用工具；边界没说清楚，它也能非常自信地把车开沟里。问题不是模型笨，而是我们不能把工程系统的稳定性押在模型每一次临场发挥上。 最开始做 Agent，写 Skill 是最快的。把步骤、约束、工具说明、验收标准写进文档里，让 LLM 照着干，验证一个想法非常舒服。 但 Skill 本质上还是指令，不是执行计划。流程短的时候还好，一旦步骤多起来，模型就可能漏掉关键动作，或者把“必须执行”理解成“可以参考”。比如该先检查文件状态再修改，它可能直接开改；该跑验证再总结，它可能写一句“验证通过”就收工。 这事不一定每次翻车，但只要关键步骤存在偶尔被略过的可能，工程链路就很难放心交给它。 所以我开始重新思考 Agent Harness。一个真正好用的 Agent 系统，不能只会“接模...