手机上写代码、做PPT、分析Excel？我用 Blazor 搞了个“AI 全能工作台“，踩坑无数终于跑通了

躺在沙发上刷手机的时候突然想改个 bug，结果发现电脑在书房懒得动……周末突然想起老板周一要的 PPT 还没做……相信每个打工人都有过这种时刻。这篇文章聊聊我是怎么折腾出一个能在手机上远程驱动 AI 干活的项目的——从写代码、做设计到处理 Excel，一个浏览器全搞定。以及这一路踩过的那些让人头疼的坑。

起因：一个"懒人需求"引发的血案

事情要从半年前说起。

那天晚上我躺在床上刷技术群，看到有人分享了一段代码，我脑子里突然闪过一个想法：这段逻辑好像我项目里也有类似的 bug？

然后我就犯了程序员的通病——想立刻验证。

但问题是，我的电脑在书房，我在卧室。走过去开机、等待启动、打开 IDE……这一套流程想想就累。于是我就在想：能不能用手机直接远程"指挥"一个 AI 来帮我改代码呢？

说干就干。

结果这一折腾，就是大半年。

我要解决的核心问题是什么？

先说清楚我想要什么。市面上有 Claude Code CLI、Codex CLI 这些强大的 AI 编程工具，但它们都有一个共同的问题：必须在本地命令行运行。

这意味着：

你得有一台开着的电脑
你得能 SSH 进去或者坐在电脑前
手机上？别想了

我最初的想法是：

在任何设备的浏览器里，远程驱动服务器上的 AI CLI 工具，实时看到 AI 的"思考过程"和代码输出，并且能直接预览生成的网页效果。

听起来不复杂对吧？天真的我也是这么想的。

但后来我发现，Claude Code 不只是能写代码。它有一套 Skills 技能系统，集成了处理 Excel、做 PPT、设计 UI、生成艺术作品等等各种专业能力。既然都能远程驱动了，为什么不把这些能力也用起来呢？

于是这个项目的定位就从"云端编程助手"升级成了"AI 全能工作台"。

技术选型：为什么是 Blazor？

有人可能会问：为什么不用 React/Vue + Node.js 这种更主流的组合？

说实话，我是.NET 老兵，写 C# 最顺手。但更重要的原因是：

Blazor Server 天生就是为这种实时交互场景设计的。

想想看，我需要：

实时流式输出 CLI 的执行结果（打字机效果）
服务端进程管理（启动、监控、杀死 CLI 进程）
会话状态管理（多个用户、多个会话、多个工作区）

用 Blazor Server，这些需求都变得异常自然：

SignalR 连接天然支持双向实时通信
服务端渲染意味着可以直接调用System.Diagnostics.Process
依赖注入让服务管理变得优雅

当然，Blazor 也有它的坑，后面会详细说。

架构设计：适配器模式拯救了我

项目做到一半的时候，我遇到了第一个大麻烦：不同的 AI CLI 工具，输出格式完全不一样。

Claude Code CLI 输出的是 stream-json 格式：

{"type": "assistant", "message": {"role": "assistant", "content": [{"type": "text", "text": "让我来看看这个问题..."}]}}

而 Codex CLI 输出的是 JSONL 格式：

{"type": "thread.started", "thread_id": "abc123"} {"type": "item.updated", "item": {"type": "agent_message", "text": "正在分析代码..."}}

结构完全不同，事件类型也对不上号。

一开始我傻乎乎地写了一堆 if-else：

if (toolId == "claude-code") { // 一堆 Claude 专属解析逻辑 } else if (toolId == "codex") { // 一堆 Codex 专属解析逻辑 }

写到第三个工具的时候我就崩溃了——这代码根本没法维护啊！

然后我想起了适配器模式。

核心思路是这样的：定义一个统一的ICliToolAdapter接口，每个 CLI 工具实现自己的适配器，负责把各种奇葩格式转换成统一的CliOutputEvent。

public interface ICliToolAdapter { string[] SupportedToolIds { get; } bool SupportsStreamParsing { get; } string BuildArguments(CliToolConfig tool, string prompt, CliSessionContext context); CliOutputEvent? ParseOutputLine(string line); string? ExtractSessionId(CliOutputEvent outputEvent); string? ExtractAssistantMessage(CliOutputEvent outputEvent); }

这个接口设计有几个关键点：

1.BuildArguments统一构建命令行参数

不同工具的参数格式天差地别。Claude Code 需要--output-format=stream-json --dangerously-skip-permissions，Codex 需要--skip-git-repo-check --dangerously-bypass-approvals-and-sandbox --json。

把这些差异封装在适配器里，上层调用方完全不需要关心。

2.ParseOutputLine处理流式输出解析

这是最复杂的部分。每个 CLI 的输出格式、事件类型、嵌套结构都不同。适配器负责把这些都转换成统一的CliOutputEvent对象。

3. 支持会话恢复

Claude Code 和 Codex 都支持会话恢复功能（通过 session_id 或 thread_id）。适配器负责从输出中提取这些 ID，并在后续请求中正确使用。

来看看 Claude Code 适配器的核心实现：

public class ClaudeCodeAdapter : ICliToolAdapter { public string BuildArguments(CliToolConfig tool, string prompt, CliSessionContext context) { var escapedPrompt = EscapeShellArgument(prompt); var argsBuilder = new StringBuilder(); // 基础参数 argsBuilder.Append("-p "); argsBuilder.Append("--verbose "); argsBuilder.Append("--output-format=stream-json "); argsBuilder.Append("--dangerously-skip-permissions "); // 会话恢复 if (context.IsResume && !string.IsNullOrEmpty(context.CliThreadId)) { argsBuilder.Append($"--resume {context.CliThreadId} "); } argsBuilder.Append($"\"{escapedPrompt}\""); return argsBuilder.ToString(); } public CliOutputEvent? ParseOutputLine(string line) { // 非 JSON 行直接返回原始内容 if (!trimmed.StartsWith("{") && !trimmed.StartsWith("[")) { return new CliOutputEvent { EventType = "raw", Content = trimmed }; } // 解析 JSON 并根据 type 字段分发处理 using var document = JsonDocument.Parse(trimmed); var eventType = GetStringProperty(root, "type") ?? "unknown"; switch (eventType) { case "assistant": ParseAssistantOrUserEvent(root, outputEvent, isAssistant: true); break; case "tool_use": ParseToolUseEvent(root, outputEvent); break; // ... 其他事件类型 } return outputEvent; } }

有了这套架构，新增一个 CLI 工具的支持变得非常简单——只需要实现一个新的适配器类，其他代码一行都不用改。

这就是适配器模式的魅力：开闭原则在实践中的完美体现。

进程管理：你以为很简单，其实到处是坑

接下来说说进程管理。这块看起来简单——不就是启动一个进程、读取输出嘛——但实际做起来，我掉进了无数坑。

坑1：Windows 和 Linux 的命令行差异

在 Windows 上，npm 安装的 CLI 工具实际上是.cmd文件。直接调用claude会报找不到命令，必须调用claude.cmd。

private string ResolveCommandPath(string command) { if (Path.IsPathRooted(command)) return command; if (!string.IsNullOrWhiteSpace(_options.NpmGlobalPath) && OperatingSystem.IsWindows()) { var cmdFileName = command.EndsWith(".cmd") ? command : command + ".cmd"; var fullPath = Path.Combine(_options.NpmGlobalPath, cmdFileName); if (File.Exists(fullPath)) return fullPath; } return command; }

坑2：输出编码问题

有些 CLI 工具在 Windows 上会输出乱码。特别是包含中文或特殊字符的时候。

解决方案是显式设置编码相关的环境变量：

if (OperatingSystem.IsWindows()) { startInfo.EnvironmentVariables["PYTHONIOENCODING"] = "utf-8"; startInfo.EnvironmentVariables["PYTHONLEGACYWINDOWSSTDIO"] = "utf-8"; } startInfo.StandardOutputEncoding = Encoding.UTF8; startInfo.StandardErrorEncoding = Encoding.UTF8;

坑3：stderr 不等于错误

这个坑让我 debug 了整整一天。

很多 CLI 工具（包括 Codex）会把正常输出也写到 stderr！这在 Unix 世界挺常见的，但我一开始傻傻地把 stderr 的内容都标记为"错误"，结果用户看到的全是"错误"信息。

var errorTask = ReadStreamAsync(process.StandardError, false, linkedCts.Token); // 注意这里是 false，不标记为错误

坑4：进程退出时机的判断

持久化进程模式下，进程不会退出，那怎么判断"这一轮交互结束了"？

我采用的是超时检测：如果连续 2 秒没有新输出，就认为这一轮结束了。

var noOutputTimeout = TimeSpan.FromSeconds(2); while (!cancellationToken.IsCancellationRequested) { bool hasNewOutput = false; if (outputReader.Peek() >= 0) { // 读取输出... lastOutputTime = DateTime.UtcNow; hasNewOutput = true; } if (!hasNewOutput && (DateTime.UtcNow - lastOutputTime) > noOutputTimeout) { break; // 认为结束 } await Task.Delay(50, cancellationToken); }

这个方案不完美，但在实践中效果还不错。

会话管理：IndexedDB 比你想象的坑多

用户的聊天记录需要持久化存储。在 Web 应用里，最自然的选择是 IndexedDB。

但 Blazor Server 有个问题：所有"前端"代码实际上都在服务器执行，你没法直接调用浏览器 API。

解决方案是通过 JS Interop：

public async Task<List<SessionHistory>> LoadSessionsAsync() { var sessions = await _jsRuntime.InvokeAsync<List<SessionHistory>>( "webCliIndexedDB.loadSessions"); return sessions ?? new List<SessionHistory>(); }

然后在前端写对应的 JavaScript：

window.webCliIndexedDB = { loadSessions: async function() { const db = await openDB('WebCliDB', 1); return await db.getAll('sessions'); }, saveSession: async function(session) { const db = await openDB('WebCliDB', 1); await db.put('sessions', session); return true; } };

这套方案运行良好，但有几个坑需要注意：

1. 存储配额限制

IndexedDB 有存储上限，而且这个上限在不同浏览器、不同设备上差异巨大。我专门处理了 QuotaExceededError：

catch (JSException ex) when (ex.Message.Contains("QuotaExceededError")) { throw new QuotaExceededException("存储空间不足，请删除一些旧会话以释放空间", ex); }

2. 保存频率控制

用户每发一条消息、每收一个字符都触发保存的话，浏览器扛不住。我用了防抖策略：

public Task SaveSessionAsync(SessionHistory session) { lock (_saveLock) { _hasPendingSave = true; _pendingSession = session; _saveTimer?.Dispose(); _saveTimer = new Timer(async _ => { await ExecuteSaveAsync(); }, null, SaveDebounceMs, Timeout.Infinite); } return Task.CompletedTask; }

3. 缓存策略

每次读取都访问 IndexedDB 太慢了。我在内存中维护了一份缓存，并设置了 10 秒的过期时间：

if (_allSessionsCache != null && DateTime.Now - _cacheTimestamp < _cacheExpiration) { return _allSessionsCache; }

上下文管理：Token 不够用怎么办？

AI 对话有个痛点：上下文窗口有限。对话多了，早期的内容就被"遗忘"了。

我实现了一套上下文管理系统，核心功能包括：

1. 自动提取代码片段

从对话中自动识别并提取代码块，单独管理：

if (config.AutoExtractCodeSnippets) { var snippets = CodeSnippetExtractor.ExtractCodeSnippets(message.Content); foreach (var snippet in snippets) { var snippetItem = new ContextItem { Type = ContextItemType.CodeSnippet, Content = snippet.Code, Language = snippet.Language, Priority = 6 }; contextItems.Add(snippetItem); } }

2. 多种压缩策略

当 Token 快用完时，支持多种压缩方式：

public enum CompressionStrategy { KeepRecent, // 只保留最近的消息 KeepHighPriority, // 保留高优先级内容 SmartSummary, // 智能摘要（代码压缩为描述） RemoveDuplicates // 移除重复的代码片段 }

其中 SmartSummary 最有意思——它会把大段代码压缩成一句话描述：

private string GenerateCodeSnippetSummary(string code, string language) { var lines = code.Split('\n'); var firstLine = lines.FirstOrDefault(l => !string.IsNullOrWhiteSpace(l))?.Trim() ?? ""; if (firstLine.Length > 60) firstLine = firstLine.Substring(0, 57) + "..."; return $"[{language}] {firstLine} ({lines.Length} 行)"; }

3. Token 估算

我写了一个简单的 Token 估算器。不完美，但足够用了：

public static int EstimateTokens(string text) { if (string.IsNullOrEmpty(text)) return 0; // 粗略估算：英文约4字符/token，中文约2字符/token var charCount = text.Length; var chineseCount = text.Count(c => c >= 0x4e00 && c <= 0x9fff); return (charCount - chineseCount) / 4 + chineseCount / 2; }

前端预览：把开发服务器也搬上去

做编程助手，只能看代码不能预览效果怎么行？

我实现了一个 DevServerManager，可以自动检测前端项目类型，并启动对应的开发服务器：

public async Task<DevServerInfo> StartDevServerAsync(string sessionId, FrontendProjectInfo projectInfo) { // 检查是否需要安装依赖 if (projectInfo.NeedsDependencyInstall) { await InstallDependenciesAsync(serverInfo); } // 分配端口 var port = await AllocatePortAsync(); // 启动开发服务器 await StartProcessAsync(serverInfo, projectInfo.DevCommand); // 等待服务器就绪 await WaitForServerReadyAsync(serverInfo); }

支持的项目类型包括：

Vite (Vue/React)
Next.js
Nuxt.js
普通的静态 HTML

端口分配采用动态分配策略，从 40000-50000 范围内找可用端口：

public async Task<int> AllocatePortAsync() { await _portAllocationLock.WaitAsync(); try { for (int port = _portRangeStart; port <= _portRangeEnd; port++) { if (_servers.Values.Any(s => s.Port == port)) continue; if (await IsPortAvailableAsync(port)) return port; } throw new InvalidOperationException($"无可用端口"); } finally { _portAllocationLock.Release(); } }

然后通过反向代理把请求转发到对应的开发服务器，用户就能直接在浏览器里看到效果了。

移动端适配：44px 触摸区域的学问

既然目标是"手机上写代码"，移动端适配就必须认真对待。

这块的核心原则就一个：触摸目标至少 44px。

苹果的 Human Interface Guidelines 明确说过，44pt 是手指能准确点击的最小尺寸。小于这个尺寸，用户会经常点错。

.touch-target { min-height: 44px; min-width: 44px; padding: 12px; }

另外还有几个移动端适配的坑：

1. iOS Safari 的 100vh 问题

iOS Safari 的 100vh 包含了地址栏的高度，导致页面底部被遮挡。解决方案：

.mobile-full-height { height: 100vh; height: -webkit-fill-available; height: 100dvh; /* 新标准 */ }

2. 虚拟键盘弹出时的布局问题

输入框在底部时，虚拟键盘会把它顶到看不见的地方。我用 Resize Observer 监听视口变化，动态调整布局：

window.visualViewport.addEventListener('resize', () => { const viewportHeight = window.visualViewport.height; document.documentElement.style.setProperty('--viewport-height', `${viewportHeight}px`); });

3. 横竖屏切换

这个相对简单，用 CSS Media Query 处理：

@media (orientation: landscape) and (max-height: 500px) { .preview-panel { position: fixed; right: 0; width: 50%; } }

一些有意思的小细节

做这个项目的过程中，还遇到了一些有意思的小问题：

Markdown 缓存

渲染 Markdown 是 CPU 密集型操作。如果每次渲染都重新计算，在消息多的时候会明显卡顿。

解决方案是加缓存：

private readonly Dictionary<string, MarkupString> _markdownCache = new(); private MarkupString RenderMarkdown(string? markdown) { if (_markdownCache.TryGetValue(markdown, out var cached)) return cached; var html = Markdown.ToHtml(markdown, _outputMarkdownPipeline); var result = new MarkupString(html); if (_markdownCache.Count > 100) _markdownCache.Clear(); _markdownCache[markdown] = result; return result; }

懒加载事件列表

一次 AI 交互可能产生几百条事件（思考、工具调用、代码生成……）。全部渲染的话，DOM 会非常重。

我采用了懒加载策略，初始只显示最新的 20 条：

private const int InitialDisplayCount = 20; private const int LoadMoreCount = 10; private int _displayedEventCount = InitialDisplayCount; private bool _hasMoreEvents => _jsonlEvents.Count > _displayedEventCount;

用户滚动到顶部时再加载更多。

工作区自动清理

每个会话都有独立的工作区目录，时间长了会占用大量磁盘空间。

我写了一个后台服务，定时清理过期的工作区：

public void CleanupExpiredWorkspaces() { var expirationTime = DateTime.UtcNow.AddHours(-_options.WorkspaceExpirationHours); var directories = Directory.GetDirectories(_options.TempWorkspaceRoot); foreach (var dir in directories) { var markerFile = Path.Combine(dir, ".workspace_info"); var lastAccessTime = File.Exists(markerFile) ? File.GetLastWriteTimeUtc(markerFile) : Directory.GetLastWriteTimeUtc(dir); if (lastAccessTime < expirationTime) { Directory.Delete(dir, recursive: true); } } }

不只是写代码：16 个官方 Skills 让它变成"全能工作台"

做到这里，我突然意识到一个问题：既然已经能远程驱动 Claude Code CLI 了，为什么只局限于写代码呢？

Claude Code 官方提供了一套 Skills 技能系统，每个 Skill 就像一个"专业插件"，赋予 AI 特定领域的专业能力。我把这套系统也集成进来了，效果出乎意料地好。

这些 Skills 能干嘛？

说几个我最常用的：

📊 Excel/表格分析（xlsx）

以前分析销售数据，我得打开 Excel，写公式，做透视表，折腾半天。现在直接把文件扔给 AI：

"帮我分析这份销售报表，找出销量下降最明显的三个区域，做个对比图"

AI 会自动读取 Excel 文件、分析数据、生成带公式的新表格、甚至输出可视化图表。整个过程不到 30 秒。

这个 Skill 支持：

创建带公式和格式的新电子表格
读取和分析现有数据
修改现有文件同时保留公式
数据可视化和图表生成
公式重新计算

📑 PPT 制作（pptx）

周五下午 5 点，老板突然说周一要汇报。以前这种时候只能加班熬夜做 PPT。

现在？直接跟 AI 说：

"帮我做一份关于 Q3 业绩的汇报 PPT，10 页左右，要突出增长亮点，风格简洁专业"

AI 会自动创建演示文稿、设计布局、填充内容、甚至加上过渡动画。我只需要最后过一遍，调整几个细节就行。

🎨 前端设计优化（frontend-design）

这个 Skill 太香了。

写后端的程序员最头疼的就是 UI——功能是好的，但就是不好看。以前只能硬着头皮抄 Bootstrap 模板。

现在可以直接说：

"帮我优化这个管理后台的设计，要现代感强一点，交互体验好一点"

AI 会给出完整的设计方案：配色、字体、间距、交互细节……而且不是那种千篇一律的"AI 味"设计，是真的有设计感。

这个 Skill 的核心理念是：避免通用的 AI 美学，强调大胆的美学方向、独特的字体选择、创意的颜色主题和意想不到的布局。

🖼️ 算法艺术 & 视觉设计（algorithmic-art / canvas-design）

这两个 Skill 我用来做一些创意类的工作：

给公众号文章配图
做活动海报
生成动态背景

algorithmic-art用 p5.js 生成算法艺术，可以创建流场动画、粒子系统这类炫酷的效果。

canvas-design则专注于静态视觉设计，输出博物馆或杂志级别的设计作品（是的，我没夸张）。

📄 文档处理全家桶（docx / pdf）

日常工作中文档处理占了大头时间：

合同要改几个字（docx）
PDF 要提取表格数据（pdf）
多个文档要合并（pdf）
需要给文档加水印（pdf）

这些繁琐的操作，现在一句话就能搞定。

特别是 PDF 这个 Skill，功能很全：

文本和表格提取
创建/合并/拆分 PDF
旋转页面、添加水印
密码保护
填写 PDF 表单（这个超实用！）

🧪 Web 应用测试（webapp-testing）

前端开发的同学都知道，测试是个体力活。

这个 Skill 基于 Playwright，可以自动化地：

验证前端功能
调试 UI 行为
捕获浏览器截图
查看浏览器日志

我用它来做回归测试，省了不少时间。

完整的 Skills 清单

目前集成的 16 个官方 Skills：

技能	一句话说明
algorithmic-art	用代码生成艺术作品（流场、粒子系统）
brand-guidelines	应用 Anthropic 官方品牌风格
canvas-design	创建博物馆级静态视觉设计
doc-coauthoring	结构化文档协作工作流
docx	Word 文档全功能处理
frontend-design	生产级前端界面设计
internal-comms	内部沟通文档模板（报告、FAQ等）
mcp-builder	构建 MCP 服务器
pdf	PDF 全功能处理（提取、合并、表单）
pptx	PowerPoint 演示文稿处理
skill-creator	创建新的自定义 Skill
slack-gif-creator	创建 Slack 优化的 GIF 动画
theme-factory	10 套预设主题一键应用
web-artifacts-builder	构建 Web 组件和工件
webapp-testing	Playwright 自动化测试
xlsx	Excel 电子表格全功能处理

这意味着什么？

WebCodeCli 不再只是一个"编程助手"，而是一个真正的"AI 工作台"。

以前我需要：

VSCode 写代码
Excel 分析数据
PowerPoint 做汇报
Figma 做设计
Photoshop 修图
……

现在，手机上打开一个网页，所有这些事情都能做。

当然，专业工具在专业场景下依然不可替代。但对于 80% 的日常需求，AI + Skills 的组合已经足够好用了。

最关键的是：随时随地，想用就用。

地铁上突然想起老板要的 PPT 还没改？掏出手机就能搞定。

这才是我理想中的工作方式。

回顾：架构思想总结

做完这个项目，回过头来看，有几个架构思想我觉得特别有价值：

1. 适配器模式处理多态性

不同 CLI 工具的输出格式差异巨大，适配器模式让这些差异被完美封装。上层业务代码完全不需要关心底层是 Claude 还是 Codex。

核心收益：新增工具支持只需要添加一个适配器类，符合开闭原则。

2. 服务层的职责划分

CliExecutorService：进程生命周期管理
ChatSessionService：消息和会话管理
ContextManagerService：上下文和 Token 管理
DevServerManager：开发服务器管理
SessionHistoryManager：持久化存储管理

每个服务有明确的职责边界，互不干扰。

3. 防御性编程

处理外部进程输出时，各种异常情况都可能发生。我在关键位置都加了防御性代码：

try { using var document = JsonDocument.Parse(trimmed); // ... } catch (JsonException) { // 解析失败时降级为原始文本 return new CliOutputEvent { EventType = "raw", Content = trimmed }; }