线上演示：nebulog.imady.co.nz（选择 "Continue as demo visitor"，免注册即可进入）。演示说明见我们的在线演示页面。
一、背景与由来
我觉得软件开发者并非像大多数人想象那样理性、高效，而是经常会跳出一些原始朴素、不切实际的想法：程序运行时，希望实时看到App正在做什么、发生的轨迹、能够帮助debug的有用日志信息，但是又不愿意用现成、哪怕是免费的工具，而是喜欢自己折腾造轮子。
我对这个问题的第一次尝试是在2014年，为南昌天睿的“大众经纪人”地产代理项目开发应用时，由于服务器硬盘容量小、日志无处存放，又不便于实施监控应用状态，于是就写了一个小工具 TRLogger，能够把服务器上的日志直接传回本地查看。
到了2018年，受到一篇关于SignalR的博客启发，我开始写一个能把应用日志实时推送到浏览器的工具，起初名为 MYLogger（MY为苏州美娱的缩写），第一版大约花了2周时间，采用Asp.Net MVC做前端。2019年我把项目更名为NebuLog（即Nebula Logger，星云日志，牛轰轰的名字），并陆续增加了WPF、Blazor、甚至Unity引擎的实现 -- 可以在三维场景中实时显示日志。2020年，Nebulog被收入GitHub的北极代码库（Arctic Code Vault）。旧版NebuLog的介绍可以参考我的知乎博客。
NebuLog从来不是一个商业项目，它出于对技术的兴趣而存在。在当年写的知乎博客中我是这样写道：“NebuLog并不是一个完善规划、有清晰产品思路的项目，而是一个出于技术探索的蜻蜓点水式的即兴项目，旨在通过在微软各种技术中实现NebuLog的过程来学习相关技术的结构、运行流程。”。不过有一个令人会心一笑的巧合：NebuLog起步几年后，微软在.NET 8中推出了Aspire Dashboard，同样为开发者提供实时查看日志的能力。这说明"开发时实时观察程序"是一个真实而普遍的需求。
本次改造使用了Claude Desktop App，其快速阅读遗留文档、理解项目需求的能力令我印象深刻。（顺便一说，我并不认同vibe coding这种说法，至少在严谨的软件开发项目中是不能以氛围感来替代工程纪律的。）
二、NebuLog v1 的不足
我们现在把Nebulog在2026年以前的实现称为v1，目前看来它的方向是有一定需求场景的，但如果要作为一个成熟产品，它并不完整：
- 只有日志列表，没有全局视图。 仪表板上的统计面板从未真正完成，使用者看得到一条条日志，却看不到"整体情况如何"。
- 数据量一大就变慢。 日志超过一万条后，页面明显卡顿。虽然当年就想到在前端可以采用环形缓冲池的方式来提升表现，却一种没有时间去实现。
- 没有遵循行业标准。 v1使用了自己定义的数据格式，源于Asp.Net Core中划分的日志等级,但只能与NebuLog自己的组件配合，很难接入外界通用的观测体系。
- 难以接入和上手。 公开访问的演示示例程序已经过时，新用户克隆后在本地难以运行，无法在几分钟内看明白它能做什么。
- 缺少多用户与权限。 这个当时就没做。任何NebuLog客户端都能无差别看到全部内容，不适合在团队或公开环境中使用。
- 技术底座老化。 v1最初基于.Net Core 2.0开发，最晚更新到2022年的.NET 6，而前端组件更存在过时的安全隐患，后续维护成本越来越高。
三、v2 的目标
终于在2026年我重新想到对NebuLogv1进行升级和改造。v2不追求做大，而是以v1的功能与定位为锚点，把它做成一个轻量、可靠、面向开发者的小工具，并保持与.Net成熟版本的兼容。具体目标有三项：
- 功能延续。 保留v1的核心价值：日志实时推送到浏览器、可嵌入任何 .NET 应用、开发者与程序之间可以双向通信。
- 技术现代化。 全面升级到当前的.NET 10与React 19，并以生产级标准完成认证、权限、自动化测试、持续集成与容器化部署。
- 标准兼容。 完全遵循OpenTelemetry这一业界通用的可观测性标准。这意味着任何遵循该标准的应用，不论用何种语言编写，都可以直接接入NebuLog，也可以同时接入微软 Aspire 等其他工具。
同样重要的是明确不做什么：不做数据库存储、不做大规模集群、不追求覆盖所有信号类型。作为一个学习和演示性质的项目，范围清楚，交付才能可靠。
四、实施过程：以 BRIPA 模型为引导，以多代理协作与互相检验为方法
方法框架：BRIPA
我在软件工程硕士的毕业课题中提出过一个名为 BRIPA 的实施模型，包含五个环节：基线（Baseline）、参照（Referencing）、交互（Interact）、原型（Prototyping）、推进（Advancement）。它的核心主张是：当需求难以事先说清时，与其写一份冗长的需求文档，不如尽早做出一个可运行的版本，以"软件本身"作为下一轮需求的依据。结合当前AI编程技术的飞速发展，这种模式的效率与可靠性在本项目也得到了有力支持。
NebuLog 的重建，正是按BRIPA模型的五个环节进行的。
1. 基线：从已有的软件出发。 v1 就是一个现成的、运行过的基线。它让需求在第一天就完整而具体：哪些功能要保留，哪些不足要弥补，都可以直接从 v1 中读出。v1 记录的每一个日志字段，都在 v2 中找到了对应位置，没有需求遗漏。更重要的是，有了基线，"做得更好"可以被量化。
2. 参照：对齐行业标准。 以 OpenTelemetry 国际标准与微软官方组件为参照，确定了"应用端完全遵循标准，NebuLog 只在标准预留的扩展位置实现自己的功能"这一方案。这既保证了兼容性，也保留了产品自身的独特之处。
3. 交互：在关键处做出人的判断。 项目定位经历了三次修正，每一次都来自人的判断：AI 最初建议收窄范围以避免与微软产品重叠，我明确它不以竞争为目的；AI 随后规划了过多的技术组件，我按市场实际与预算加以收敛；在标准兼容方式上，我指出"只用官方组件会削弱展示价值"，由此确定了最终方案。
4. 原型：上线即原型。 v2.0 发布后，我发现线上演示的信息量远不如 v1 的旧截图丰富。这个发现直接催生了 v2.1：一个公开落地页、八个引导式演示场景，以及一个由两个服务组成的"演示商店"。访客点击一次"结账"，就能在控制台中看到这一请求如何穿过两个服务。新的需求，正是在使用已有软件的过程中被发现的。
5. 推进：持续迭代。 下一版本已规划接收更多类型的运行数据，例如可以强化实时日志脱敏能力（已经确定NebuRedaction项目）、或者重新实现v1的多种示例、重新支持Unity引擎等。
执行方式：人类+多个AI代理协作模式的AI Software Engineering
具体的开发工作由三个AI代理与我共同完成，每个角色职责明确：
| 角色 | 承担者 | 职责 |
|---|---|---|
| 决策者 | 我 | 产品定位、关键取舍、发布批准 |
| 规划与验收 | AI 代理一 | 分析、制定任务单、独立验收线上成果 |
| 开发与部署 | AI 代理二 | 编码、测试、部署，并对照任务单回报完成情况 |
| 基础设施 | AI 代理三 | 统一分配服务器、域名与网络资源 |
所有协作都以书面文档为契约。每项任务都有一份任务单，写明背景、范围，以及验收标准，这是"完成"的唯一定义。执行方完成后，必须逐条对照验收标准回报结果，并如实记录偏差与原因。
互相检验：可靠交付的关键
这种方式真正的价值不在于速度，而在于每一方的工作都由另一方检验：
- 规划方检验执行方。 独立验收线上系统时，规划方发现了几处测试与代码审查都没有发现的问题，例如说明文字与实际实现不一致。由此确立的原则是：写代码的一方，不验收自己的工作。
- 执行方检验规划方。 当任务单中的设想与实际技术环境不符时，执行方有权修正，并写回原因。全程约二十处此类修正，全部属于实现细节，没有一处涉及需求范围。这正是一个好基线带来的稳定性。
- 基础设施方与规划方互相检验。 双方在部署方案上互相指出了对方的疏漏，在上线之前就消除了隐患。
- 检查本身也要被检验。 项目中最有价值的一条经验是：一个检查报告"通过"，不代表它真的在检查。因此我们约定，任何自动检查在投入使用前，都要先用一个"故意的错误"验证它确实能发现问题。
- 以真实环境验收。 自动化测试之外，我们把"上线后像访客一样走一遍"写成了脚本，在真实的线上环境中完整模拟访客路径。它第一次运行，就发现了测试环境中无法暴露的问题。
AI 的错误往往出现在"看起来正确"的地方。对此，更仔细的思考并不够，需要的是可执行、可复核的验证机制。这正是这套流程被设计出来的原因。
五、交付结果
v2.0于2026年10月5日发布，距开始分析仅两天；v2.1于10月7日发布，新增落地页、多个引导演示与模拟商店示例。
| 指标 | v1 | v2 |
|---|---|---|
| 技术平台 | .NET 6（2022） | .NET 10（当前版本） |
| 自动化测试 | 无 | 324 项 |
| 大数据量表现 | 一万条以上明显卡顿 | 十万条日志流畅滚动 |
| 实时性 | 未测量 | 从产生到显示约 0.1 秒 |
| 处理能力 | 未测量 | 每秒持续处理一万余条日志 |
| 用户与权限 | 无 | 四种角色 |
| 行业标准兼容 | 不兼容 | 完全遵循 OpenTelemetry |
| 公开演示 | 无 | 线上可访问，免注册试用 |
演示中有一个直观的例子：同一个网页请求，用.NET的两种不同开发方式实现，一种产生15条框架日志，另一种产生55条。访客可以在两个窗口中并排看到这一差异，这正是开发工具应当提供的洞察。
六、这个项目说明了什么
对imady的客户而言，NebuLog本身并不重要，重要的是它展示的工作方式：
- 技术独立。 从 2014 年的最初构想，到 2018 年的第一版，再到 2026 年的重建，NebuLog 由一个人独立构思与实现，全部源码公开可查。
- 技术深度。 v2覆盖了现代.NET技术栈的主要模块，并在国际标准的框架内实现了自己的扩展，而不是简单调用现成组件。
- 方法创新。 以研究中提出的BRIPA模型为引导，以多个AI代理分工协作、交叉检验作为软件工程方法，在保证质量的前提下显著缩短了交付周期。
- 交付可靠。 每一项任务都有明确的验收标准，每一项成果都由另一方独立检验，每一个数字都可以在公开的代码仓库中复核。
同样的方法，可以用于升级您已有的软件系统：以现有系统为基线，明确保留什么、改进什么，再以可验证的方式逐步交付。