一开始用 Copilot 时，Markdown 就是默认格式。后来 Agent 也一直往 Markdown 文件里写东西给我看——方案、分析、摘要，全是 Markdown。我也没多想，开发者标配嘛，轻量通用。

直到每次 Design Review 看架构方案，问题开始冒出来了。

Markdown 读架构方案，太累了

Agent 写方案越来越快，一个方案几千字，模块职责、调用关系、数据流、边界、风险全堆在 Markdown 里。每一项单独看都不复杂，合起来就很累。

架构设计本来就不适合全靠文字描述。A 模块调 B 模块、数据从 C 流到 D、部署拓扑长什么样——用文字写出来，读的人要在脑子里重新拼一遍。读 Markdown 时经常读到第三遍才拼出系统长什么样。

问题不是 Markdown 不好。文字写逻辑、写清单、写步骤，Markdown 很舒服。但一张系统架构图需要的空间关系和数据流向，文字描述效率太低了。

所以我换了个方式：让 AI 直接出网页版的 Design Doc。

打开网页，先看结构

改成 HTML 页面后，最明显的变化是阅读顺序变了。

左侧是导航，页面里直接放架构图。打开先看整体——动了哪些模块、数据往哪流。再看风险点和实现细节。

以前读 Markdown，经常读到第三遍才搞清楚系统长什么样。网页化以后，第一遍就能建立整体印象。

核心变化不是"从文档变成网页"，而是从"先读完全文再判断"变成了"先看结构再看细节再判断"。

做成 Skill 固化下来

用了几次之后，我发现这可以固化下来。

Design Review 的输入很稳定：设计方案或代码改动。 输出也很稳定：网页化 Design Doc。 我关心的评审点也差不多：模块边界、数据流、文件改动、风险点。

所以做了个 Skill。固化的东西分两类：阅读结构（左侧导航、按模块-数据流-风险排序）和评审标准（方案对比、边界是否清晰、有无设计过度）。

不需要升级成完整 Agent。把输入输出定义清楚，把呈现方式调舒服，把 review 标准写进去——做到这一步就够用了。

这个思路推到了其他场景

Design Review 之后，我把这个思路试到了其他地方。

PPT：不太会排版，让 AI 输出 HTML 再转 PPT，排版灵活多了。配合字幕还能拼成视频，一份内容两个产出。

读论文：让 AI 生成 HTML 页面，启动本地服务器，扔一个 IP 端口。数据和图表配着结论，扫一眼就够了。

审稿：以前 AI 写一段 Markdown 我肉眼扫。现在让 Agent 按固定格式输出，写个脚本检查字段——不对就退回。

现在让 AI 做事，我第一反应不是"让它输出什么格式"，而是"最终给谁看"。