- 博客(35)
- 资源 (2)
- 收藏
- 关注
RSS订阅原创 Context Engineering 实战 04｜Memory 不是聊天记录：长期记忆系统的工程设计
Crashsight 的崩溃分析 Agent。用户在第 5 轮告诉它：“这个 crash 是从 v3.2.1 的热修复开始出现的。Agent 记住了。后续 20 轮分析都围绕这个线索展开——查 v3.2.1 的 changelog、对比 v3.2.0 的 stacktrace、分析热修复改了哪些模块。第 32 轮，Agent 突然问：“请问这个 crash 是从哪个版本开始出现的？你告诉它了。它忘了。第 40 轮更糟。它给出了一个修复建议——“建议重启相关服务并观察”。
2026-05-06 20:49:32
258
原创 Context Engineering 实战 03｜运行时该给模型看什么：动态上下文组装
AIReview 的 code review 系统有 200 条 review 规则，早期全量塞进 context。上线第一周就发现问题：模型给一个纯前端的 React 组件提了"SQL 查询应该加索引"的 review 意见。排查后发现不是个例。只有 12% 的规则被正确使用。更多的规则被忽略或乱用。改成动态选择后——按文件类型 + diff 内容选 10-15 条相关规则注入——遵循率从 45% 到 83%，误报（强行套用不相关规则）从 22% 降到 4%。
2026-05-06 20:49:00
229
原创 Context Engineering 实战 02｜System Prompt 是架构决策，不是写说明书
Config Risk Assessment 系统上线第一周，指令遵循率 67%。System prompt 4000 token，把风险评估的所有规则、所有场景定义、所有输出格式都写在一起——一份完整的"操作手册"。团队做的第一件事：排查模型具体在哪些指令上不遵循。中间 1500 token 的遵循率只有 48%——接近抛硬币。而这 1500 token 恰好放着最细致的评估规则：“数值类配置变化超过 50% 视为高风险”“开关类配置的核心功能关闭标记高风险”。
2026-04-28 16:28:32
608
原创 Context Engineering 实战 01｜Context Engineering ≠ Prompt Engineering 2.0：到底在“工程“什么
AIReview 有 8 个工具（search_code、read_file、run_test 等），每个工具的 description + parameter schema 大约 100-150 token。这 900 token 是隐性固定开销，每次请求都在，你的规则和 diff 要跟它们竞争注意力。
2026-04-28 16:27:58
653
原创 Harness Engineering 06｜从单个 Harness 到 Harness Platform
activity-dev-harness 最成熟，Crashsight 最薄弱。但即使是最成熟的项目，也没法把自己的 Harness 能力直接给别人用——因为。四个项目的 Eval 回归脚本写了四遍，Trace 记录方案设计了四遍，工具分级逻辑实现了四遍。
2026-04-27 19:48:47
195
原创 Harness Engineering 05｜Safety & HITL Harness：边界、接管与回滚
activity-dev-harness 早期有一次事故：Developer Agent 修复一个 UI 问题时，判断"根因在配置文件"，然后改了——这是构建产物目录，每次构建会被覆盖。修改被覆盖后 Agent 检测到"修复没生效"，于是再改一次，再被覆盖，再改……陷入死循环，3 轮全部浪费。问题不是 Agent"不够聪明"。它的修复思路合理，代码也写对了。一个写权限没有边界的 Agent，能力越强，做出越界修改的概率就越高。
2026-04-27 19:47:36
424
原创 Harness Engineering 04｜能力 Harness：工具和检索的可靠性工程
activity-dev-harness 最初给 Developer Agent 配了 12 个工具。逻辑很直觉：能力越多 → 覆盖越全 → 效果越好。同样的故事在 RAG 上也发生了：AIReview 接入规则知识库后，团队以为"有知识就更准"。实测发现某些场景下接入 RAG 反而导致准确率下降——检索噪声污染了原本正确的判断。
2026-04-26 20:40:29
282
原创 Harness Engineering 03｜Eval & Trace Harness：验证和追溯的工程组织
手记 03 已经覆盖了评测和可观测性的基础概念：AI 测试金字塔、非确定性回归、5 层可观测模型。这篇不重复那些内容。当你有一套 Agent 系统，Eval 和 Trace 应该怎么组织成闭环，才能真正防住质量退化？手记 03 的视角 本篇的视角什么是 Eval Eval 在 Harness 里怎么组织什么是可观测性 Trace 记什么、怎么用、服务谁评测集怎么分类 Eval + Trace 怎么串成闭环非确定性回归的原理 真实系统里的 Eval 流水线长什么样。
2026-04-26 20:39:58
621
原创 Harness Engineering 02｜Repo Harness：让仓库对 Agent 可读
activity-dev-harness 第一次接入真实仓库时，Developer Agent 的表现让人意外：在 playground 里能写出 90% 正确的 Lua 代码，但进入真实项目后，35 个 case 只通过了 12 个。
2026-04-25 21:14:51
408
原创 Harness Engineering 01｜从 Prompt Engineering 到 Harness Engineering
activity-dev-harness 项目的 Prompt 调优阶段，团队在 system prompt 上反复打磨了三周：角色定义、输出约束、few-shot 示例、CoT 引导。每改一版，跑几个 case 看起来都有进步。第三周末拉全量 35 个 case 回归，通过率 45%，波动范围 30%-65%。也就是说，同一份 Prompt，今天跑 65% 明天跑 30%。后来真正让通过率稳定到 78%（波动 72%-85%）的，不是某一版"更好的 Prompt"。
2026-04-25 21:14:21
572
原创 AI Agent 实战避坑 06｜给 AI 的工具越多越好？Tool Use 设计的减法哲学
一个 Developer Agent 初始配了 12 个工具：读文件、写文件、运行命令、搜索代码、查文档、跑测试、看 git log、看 diff、格式化代码、检查类型、检查 lint、查依赖。看起来很全面——Agent 应该什么都能干了。工具少了 58%，通过率反而提高了 16 个百分点。
2026-04-24 17:10:13
448
原创 AI Agent 实战避坑 05｜AI 版 TDD：Eval-Driven Development 完全指南
格式检查（硬门槛）try:except:return results # 格式都不对，后面不用看了# 内容检查。
2026-04-24 17:09:27
653
原创 AI Agent 实战避坑 04｜别让 AI 边想边做：Planning/Execution 分离实战
让 Agent 实现一个 694 行的模块——real_wiring.py，负责活动系统的真实布线逻辑。Agent 上来就开始写代码，前 50 行还不错，到第 100 行发现前面的数据结构选错了，但它没有回头改，而是在错误的基础上继续往下堆了 400 行补丁逻辑。最后交出来的代码"能跑"，但维护性为零。这不是 Agent “笨”。这是自回归生成的结构性问题——每个 token 都基于前面已生成的内容，一旦前面走错了方向，后面要"推翻重来"在概率上极其困难。
2026-04-23 18:37:58
478
原创 AI Agent 实战避坑 03｜AI 的“我修好了“不能信：置信度校准入门
让 Developer Agent 修 100 个 bug。直觉上你会觉得：第一档最靠谱，第三档最不靠谱。AI 的自信程度和它的正确率之间，几乎没有正相关关系。这不是个别模型的问题，而是当前 LLM 的结构性缺陷。
2026-04-23 18:37:24
849
原创 AI Agent 实战避坑 02｜为什么你的 Prompt 越写越长，效果却越来越差
上个月优化一个 Code Review Agent 的 system prompt。初版 800 token，效果还行，能抓住主要问题。团队陆续加了各种要求：代码规范要检查、安全漏洞要扫描、性能问题要提醒、文档一致性要校验……两周后 prompt 膨胀到 6200 token。跑了一轮 eval，通过率从 78% 跌到 52%。加了三倍的细节，效果反而砍了三分之一。这不是个例——几乎每个认真做 Agent 的团队都会走到这一步。
2026-04-22 20:29:18
480
原创 AI Agent 的 8 种“死法“：一份来自生产环境的失败模式手册
AI Agent 的失败不是随机的，它有可预测的模式——这意味着可预测 = 可防御。很多人抱怨"AI 不好用"，本质上是把 AI 当黑盒在用：输入 prompt，祈祷输出正确。理解模型的激励结构（Reward），承认它和你的目标（Target）之间有 gap，然后用分层防御去系统性地缩小这个 gap。不要问"AI 为什么这么笨"，要问"我的系统哪层防御没做到位"。
2026-04-22 20:28:47
1057
原创 AI 工程化手记 02｜推理服务：一条请求的生命与代价
activity-dev-harness 的一次验收循环里，Developer Agent 推理一次生成代码，Reviewer Agent 推理一次生成 findings，FAIL 了再来一轮。3 轮循环 = 至少 6 次推理调用，每次都带着越来越长的上下文。Demo 阶段跑得很顺。
2026-04-21 15:04:58
406
原创 AI 工程化手记 01｜AI 工程不是调模型
activity-dev-harness 第一版 Demo 两天跑通：Agent 读 case JSON，生成 Lua 代码，跑 smoke test，演示效果不错。团队觉得"核心能力有了"。
2026-04-21 15:04:26
368
原创 【Unity工程化】08_Profiler实战完整定位流程
案例1：战斗场景帧率暴跌玩家反馈（紧急）："打BOSS的时候卡到怀疑人生""技能释放的瞬间直接1帧""手机发烫到不敢碰"测试数据：- 正常场景：60 FPS- 进入战斗：45 FPS- BOSS战：15-20 FPS（严重）- 玩家流失：+35%案例2：UI界面莫名卡顿测试反馈："打开背包界面卡顿500ms""滑动列表不流畅"Profiler数据：- 背包UI：初始化耗时600ms- DrawCall：从5个→120个- SetPass Call：78个。
2025-10-22 16:09:06
1627
原创 【Unity工程化】07_Addressables_Catalog加载机制详解
Addressables Catalog 文件加载机制摘要 Catalog文件是Unity Addressables系统的核心组件，作为资源定位的"地址簿"，记录着所有资源的存储位置、依赖关系和版本信息。本文深入解析： 文件结构：Catalog采用JSON格式存储，包含资源路径、依赖关系、加载器类型等关键数据，通过Base64编码压缩优化存储空间 加载流程：包含初始化→加载本地Catalog→检查远程更新→下载合并→最终就绪六个步骤，确保版本一致性 查询机制：采用哈希桶加速定位，通过Ad
2025-10-21 10:26:07
1198
1
原创 【Unity工程化】06_ShaderVariant管理与爆炸问题全解析
场景1：首次进入游戏卡顿10秒玩家反馈："为什么第一次进游戏要等这么久？"加载界面卡住不动了""手机都要烫坏了"开发者排查：- 打开Profiler查看- 发现大量 "Shader.Parse" 和 "Shader.CreateGPUProgram"- 首帧CPU耗时：8-12秒- 原因：运行时编译了1500+个Shader变体场景2：包体莫名增大200MB项目初期：- APK大小：350MB- Shader占用：15MB半年后：- APK大小：550MB（增加了200MB！
2025-10-20 10:14:14
2138
原创 【Unity工程化】05_构建管线自动化实战指南
本文介绍了构建Unity企业级自动化构建管线（CI/CD）的方案，通过Jenkins、Git Hooks等技术实现高效的打包流程。文章首先分析了手动打包的痛点（耗时、易出错、难以追溯），对比了自动化构建的显著优势（节省时间、提升质量、规范化）。随后详细讲解了完整的构建流程，包括8个关键阶段：代码检查、环境验证、预构建检查、资源打包、APP构建、后处理、产物上传和通知机制。最后提供了Jenkins环境搭建的具体步骤（Docker安装、Unity配置、插件管理）和完整的Jenkinsfile示例，展示了如何通过
2025-10-20 10:13:20
1076
原创 【Unity工程化】04_热更新框架设计原理对比分析
Unity热更新框架深度解析：XLua、HybridCLR与ILRuntime对比 核心摘要 本文深入剖析了三种主流Unity热更新方案（XLua、HybridCLR、ILRuntime）的技术原理与实现机制： XLua架构：基于Lua虚拟机，通过C#/Lua桥接层实现热更新，适合逻辑热更但性能开销较大 HybridCLR：扩展IL2CPP运行时实现完整C#热更新，性能接近原生但学习曲线陡峭 ILRuntime：基于C#轻量级运行时，平衡性能与易用性，适合中小项目 技术决策关键点： iOS平台限制决定了热更
2025-10-18 15:02:28
1221
原创 【Unity工程化】03_AssetBundle依赖冗余与优化思路
AssetBundle依赖冗余问题分析与优化 摘要 AssetBundle依赖冗余是Unity项目常见的性能问题，表现为包体异常膨胀（如资源增加100MB但包体增长430MB）。主要根因包括： 未标记共享资源：公共资源未单独打包，导致多Bundle重复包含 隐式依赖链：FBX模型等资源的材质、Shader等未显式标记 打包策略不当：缺乏合理的分包规划 优化方案： 自动化检测：开发工具扫描隐式依赖和重复资源 共享资源管理：将公共资源单独打包（如图集、Shader） 工程化实践：建立CI检测流程和团队规范 效果
2025-10-18 15:01:29
1357
原创 【Unity工程化】02_GC优化与内存池设计实战
本文深入探讨了Unity游戏开发中的GC（垃圾回收）优化与内存池设计实战。文章首先通过两个真实案例（战斗系统卡顿和UI内存风暴）展示了GC问题的严重性，量化分析了GC对性能、体验和电量的影响。随后解析了Unity三层GC架构和Boehm GC的工作流程，重点介绍了增量GC的原理及其配置方法。文章详细列举了四大GC分配来源：装箱操作、字符串拼接、闭包捕获和LINQ使用，并分别提供了优化方案。通过对象池设计、内存预分配等实战技巧，帮助开发者有效降低GC频率，消除游戏卡顿，提升用户体验。
2025-10-17 14:20:25
1126
原创 【Unity工程化】01_资源加载与缓存策略最佳实践
本文探讨了Unity资源加载与缓存策略的最佳实践，从常见问题场景出发，分析底层机制并提出优化方案。文章首先列举了同步加载卡顿、内存泄漏和GC抖动三类典型问题，指出资源加载对性能、内存和稳定性的关键影响。随后深入解析Unity资源加载的五层架构，对比Resources、AssetBundle等不同加载方式的底层实现差异，重点剖析异步加载中的GC陷阱（状态机、闭包、装箱等）。最后提出三种缓存模型（无限缓存、引用计数、LRU）及其适用场景，为开发者提供从基础到高级的性能优化路径，帮助实现流畅、稳定的游戏体验。
2025-10-17 14:18:52
1377
原创 【Unity 底层与原理向】08_配套课后作业：通过实践深化理解掌握 Unity 底层机制
目标：理解 Unity 的更新流程要求使用文章中的打印完整的 PlayerLoop 结构Awake在哪个阶段？Update在哪个阶段？在哪个阶段？LateUpdate在哪个阶段？Frame N:ms] Update目标：掌握 PlayerLoop 注入的基本方法要求在UpdateTimeframeCount创建一个 MonoBehaviour，在 Update 中打印日志观察自定义系统是否在 Update 之后执行预期输出。
2025-10-17 13:52:33
1181
原创 【Unity 底层与原理向】07_Script_Execution_Order机制与坑点
Unity脚本执行顺序解析 核心问题 脚本初始化顺序不确定导致依赖问题 常见陷阱：Awake中访问未初始化组件、OnEnable多次触发、场景加载顺序不一致 关键解决方案 使用Start替代Awake：确保所有Awake已完成 设置Script Execution Order：明确指定关键脚本的执行优先级 延迟初始化：通过协程等待一帧完成初始化 避免OnEnable中的重复注册：使用标志位防止多次订阅事件 最佳实践 关键系统(如GameManager)设置为负值优先执行 复杂初始化逻辑放在Start中 对于
2025-10-17 13:46:18
794
原创 【Unity 底层与原理向】06_PlayerLoop与自定义更新机制
Unity PlayerLoop 系统深度解析 本文深入探讨了 Unity 的 PlayerLoop 更新机制，对比了传统 MonoBehaviour.Update 与自定义 PlayerLoop 系统的优劣。主要内容包括： 通过工厂流水线类比，解释 PlayerLoop 的分阶段执行原理 详细拆解 Unity 帧循环的完整架构，展示 Initialization、EarlyUpdate、FixedUpdate 等核心阶段 揭示 MonoBehaviour.Update 的底层实现原理及其性能瓶颈 提出自定
2025-10-17 13:44:59
1290
原创 【Unity 底层与原理向】05_Unity内存模型Managed与Native详解
Unity 内存管理：GC卡顿与优化策略 核心问题 Unity采用双层内存架构，托管内存（C#堆）由GC自动管理，原生内存（引擎资源）需手动释放。GC卡顿主要由于Boehm GC的Stop-The-World机制，尤其在关键帧触发时影响更大。 关键发现 内存架构：C#对象与引擎资源分属不同内存空间，存在跨层引用关系 GC机制：传统GC导致卡顿，增量GC可分散回收压力 优化方向：减少托管堆分配、控制GC触发时机、正确处理跨层引用 实用建议 使用对象池减少分配 配置增量GC时间片 避免在Update中频繁分配内
2025-10-16 21:39:27
1365
原创 【Unity 底层与原理向】04_Unity序列化机制的黑盒解析
Unity序列化机制解析：常见字段丢失问题与解决方案 摘要 Unity序列化机制特殊且复杂，开发者常遇到字段丢失问题。本文揭示其核心规则：1)支持基本类型、UnityObject引用、标记为Serializable的自定义类、数组和List；2)不支持Dictionary、多维数组、复杂泛型等；3)public字段自动序列化，private字段需[SerializeField]标记；4)存在7-10层的嵌套深度限制。通过理解Unity的三层序列化架构和底层C++扫描逻辑，开发者可避免常见陷阱，如静态字段、常
2025-10-16 21:38:38
505
原创 【Unity 底层与原理向】03_Unity资源依赖关系与打包陷阱
Unity资源依赖与打包优化指南 核心问题：Unity包体无故增大常由资源依赖关系管理不当导致，表现为重复打包、冗余依赖和隐式引用问题。 关键发现： Unity资源引用分三层：文件GUID→对象FileID→隐式依赖 打包时递归收集所有依赖，未显式管理的共享资源(如Shader/图集)会被重复打包 常见陷阱包括：Shader冗余、图集复制、长依赖链导致资源雪崩 解决方案： 使用Unity内置工具或AssetBundle Analyzer分析依赖树 显式分配共享资源到独立Bundle 通过依赖分析脚本定位问题
2025-10-16 21:37:51
728
原创 【Unity 底层与原理向】02_Addressables与AssetBundle设计哲学
Unity 的 Addressables 和 AssetBundle 是两套资源加载系统，设计哲学迥异。AssetBundle 提供底层 API，需要开发者手动管理依赖、引用计数和卸载逻辑，灵活但繁琐；而 Addressables 在其基础上构建了高级框架，自动处理依赖关系、实现引用计数和智能卸载，简化开发但增加系统开销。核心区别在于：AssetBundle 强调控制力，Addressables 侧重易用性。Addressables 并非替代 AssetBundle，而是通过中间层封装复杂逻辑，为开发者提供
2025-10-16 21:36:36
807
原创 【Unity 底层与原理向】01_ScriptableObject底层存储与序列化机制
ScriptableObject 是 Unity 中能持久化数据的特殊对象，其本质是继承自 UnityEngine.Object 的资源型对象。与 MonoBehaviour 不同，SO 独立于 GameObject 存在，以.asset 文件形式存储，通过 Unity 序列化系统转换为 YAML 格式保存。SO 适合用于配置数据、全局事件系统和运行时共享数据，其特性包括：字段标记序列化、独立生命周期、跨场景引用和内存共享。关键区别在于 Mo
2025-10-16 21:33:49
995
原创 为什么 `.lua` 文件默认不支持打包进 AssetBundle
Unity的AssetBundle系统仅支持打包Unity可识别的资源类型（如Texture、Audio等），而.lua文件因无对应Importer无法被打包。虽然.lua会生成.meta文件用于GUID管理，但不会被导入为可序列化资源。解决方案包括：1）修改后缀为.bytes/.txt使用TextImporter；2）编写自定义LuaImporter；3）通过外部路径独立加载（适合热更）。官方不内置支持是因Lua属于第三方脚本语言。推荐热更项目采用外部加载，静态脚本使用.bytes后缀方案，并建议封装统一
2025-10-10 15:26:41
810
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人