事情是这样的。
最近我手上有个微服务项目，二十几个服务，一堆 Spring Boot，一堆 Go，一堆 Python 脚本，依赖关系画出来像一张心电图。我每次想做个改动，都要先花半小时翻代码，理清楚「我改这一行会不会把 Payment 弄崩」。
那天晚上我就在想，能不能让 AI 像架构师一样，把整个项目读一遍，然后告诉我哪里有坑。
不是让它写代码，是让它读。然后告诉我哪里有雷。
后来我就真的搭了一个出来。
我为什么要折腾这玩意儿
坦率的讲，这事本来不在我的待办里。我本来只是想搞清楚 Order Service 和 Payment Service 之间到底是怎么同步调用的。
但是翻代码翻到第三个小时我就崩溃了。
二十几个服务，每个都有自己的 controller、service、repository，配置文件分散在各个 application.yml 里，依赖关系藏在 import 语句和 @Autowired 里。你想理清楚「删掉某个接口谁会炸」，基本只能人肉 grep。
那我就想，让 AI 来干这事不行吗。
让 AI 读整个代码库，然后产出一份「架构体检报告」，评分多少、服务依赖图长什么样、哪里有 Critical 风险、应该先修哪个。
听起来很 fancy。但其实没那么玄，说到底就是「项目分析 + 大模型问答」这两件事拼起来。
不过这事的乐趣在于，我可以把它做出来，然后让任何人都能用。三分钟，导入一个项目，点一下按钮，AI 给你一份体检报告。
这东西到底长啥样
我做的东西不复杂，就三块。
第一块是项目导入。你可以把一个真实的微服务项目打成 ZIP 上传过来，系统会真的去解压、扫描、抽源码。嫌麻烦的话直接点 "Try Demo"，内置一个样例工程，二十几个服务，几千个文件，几十万行代码那种。
第二块是 AI 架构分析。这一步分两段，先用一个启发式扫描器把项目结构抠出来，多少个服务、多少个 API、多少个数据库、谁依赖谁。然后把这些素材喂给大模型，让它扮演一个资深微服务架构师，从八个维度做审查。
第三块是可视化。评分环、四张 Bento 指标卡、风险列表按严重度着色、React Flow 架构图、右下角还能直接跟 AI 对话问问题。
就这三块。没了。
技术栈我也没用什么花哨的。前端 Next.js 14 加 React Flow 加 Monaco，后端 FastAPI 加 SQLite，AI 调用走 OpenAI 兼容协议，主题是暗色 Bento，黑白银蓝绿，全程没有紫色。
这里有一个我觉得挺关键的设计，单独说一下。
Demo 模式 vs Real 模式。
默认进来你没配任何模型，系统自动进 Demo 模式。这套 Demo 模式下，所有的数字都是写死的，但都是自洽的，286,431 行代码、24 个服务、68 个依赖、评分 78、3 个 Critical 风险。每个按钮背后都是真实逻辑，只是结果来自预设剧本。
你填了自己模型的 Base URL 和 API Key 之后，进 Real 模式，这时候右上角的徽标会从「Demo Mode」变成你配的模型名，真的去调那个模型，所有结果都是 AI 现场跑出来的。
这套设计最关键的是那条红线。默认 Demo 结果必须通用合法，不能把 A 厂商模型的结果冠到 B 厂商头上。只有你自己填了 Key 配了模型，才如实署名「这是你配的模型跑出来的」。
为什么要这么做。因为这是我对「演示品」的理解。它可以不接真模型，但它不能骗人。每个按钮背后都要有真实逻辑，没有死链。
真实页面长这样
下面这八张图都是真实跑起来的页面截图，不是我拿设计稿渲染的。
1. 仪表盘
进来第一眼，深色 Bento 网格，中间一个醒目的「Import Project」入口，下方是近期项目表。右上角是模型徽标，配置后会变成已配置模型的样子。
2. 导入面板
点「Import Project」弹出这个面板。左边上传 ZIP（真实解压扫描），右边「Try Demo」一键带出内置样例工程。
3. 分析扫描页
导入完跳到分析页。先展示扫描统计，8,421 文件、286,431 行、24 服务、186 API、7 数据库。下面是 Monaco 渲染的源码，让你能看到 AI 正在读哪段代码。右下角「Start AI Audit」是真正的入口。
4. 审查结果
点完 Start AI Audit，评分环给你一个 78/100。下方四张 Bento 卡，Services 24、Dependencies 68、Risks 17、Critical 3。这四个数字就是前面那张扫描页喂给 AI 的素材。
5. 风险列表
风险列表按严重度着色，Critical 红、High 橙、Medium 黄。点任意一条右侧展开完整详情，标题、严重度、描述、证据代码、整改建议都有。
6. 架构图
架构图用 React Flow 画，节点按类型着色，服务蓝、数据库绿、Redis 橙、MQ 黄。点任意一个节点，右侧会显示这个节点的依赖列表和它涉及的风险。
7. AI 对话
右下角的 AI 对话是上下文感知的。它知道你这次分析的是哪个项目、有什么风险。所以你可以直接问「Payment 挂了会怎样」，它会基于真实风险清单给你答案，不是泛泛而谈。
8. 模型配置页
模型配置页长得最朴素，就是一个表单。但这是接下来重点要讲的。
怎么把它接上你自己的模型（蓝耘 Kimi K3 实操）
这块很多人卡住过，搞不清楚到底要填什么、模型怎么连。所以我专门讲一下，如果你用的是蓝耘的 maas 平台，跑一个 Kimi K3 模型，配置就是这么几步。
打开 Model 配置页（左侧导航第二项），你会看到一个表单，四个字段加一个测试按钮。
Base URL
填蓝耘 maas 的端点
https://maas-api.lanyun.net/v1注意末尾的 /v1 要带上，这是 OpenAI 兼容协议的标准路径。
API Key
去蓝耘控制台创建一把 API Key，复制过来粘进去。粘进去之后前端只会显示前几位加省略号，不会完整保存到任何云端，只存在你本地浏览器能访问到的存储里。
Model Name
这个名字是你自己起的，随便填，主要是为了右上角徽标显示和对话里识别。蓝耘 Kimi K3 你就填
Kimi K3或者填你喜欢的名字也行，比如「蓝耘-Kimi」、「我的架构师」。这个字段不影响模型调用，只影响展示。
Model ID
这个才是真正传给模型服务的标识符。在蓝耘 maas 后台你能看到当前可用的模型 ID，Kimi K3 对应的是
kimi-k3
把上面这四项填完，点「Test Connection」，系统会用你填的 Key 真实去连蓝耘那侧，连通了会回显，连不通会报错。
连通之后，刷新页面，右上角徽标就会从「Demo Mode」变成你起的那个名字，比如「Kimi K3」。这时候你点 Start AI Audit，调的就是蓝耘那侧的 Kimi K3，结果会基于真实模型产出，不再是固定剧本。
这里有个小坑我想提醒一下。
有些人会把 Base URL 写成 https://maas.lanyun.net 不带 /v1。这种会 404，因为 OpenAI 兼容协议要求 /v1/chat/completions 这个路径，Base URL 必须指向 /v1 这一层。
还有些人会把 Model ID 写成「Kimi K3」带空格。这种也会报错，因为大多数 OpenAI 兼容后端要求的 model 参数是 kimi-k3 这种连字符小写形式，不是显示名。
沉淀成 Skill 划算吗
做完了 Demo 我停下来想了一下，这事是一次性的还是可复用的。
结论是后者。
为什么。
第一个原因，高频。用户让我「做个 AI 工具 / Demo / 原型」的请求非常常见，每次都从零踩同样的坑不划算。
第二个原因，可参数化。输入是「一个产品 spec」，输出是「一套可运行的前后端加验证脚本」。骨架稳定，只有剧本和扫描规则随项目变。
第三个原因，有踩坑复利。Windows venv 布局、包启动、npm 镜像、404 语义这些坑，踩一次固化一次，下次直接跳过。
那什么不进 Skill 呢。
微服务审查的具体风险清单、固定数字，进 Skill 没用，那是这个项目特有的。某个 API 的实现细节也不进。
判断标准很简单，凡是「换一个 AI 加 web 的 Demo 还能用上的」，就值得进 Skill。凡是「只属于这一个项目」的，不进。
不过 Skill 也有边界。它解决的是 Demo 级的需求，不自动扩展成企业级平台。如果你要的是真实多轮对话、长任务队列、鉴权体系，Skill 只管前 80%，剩下要人工补。
我真的做了，而且测了
我把这件事落地成了一个标准 Skill，叫 ai-web-app-builder，放在当前工作目录 F:\lanyun\ai-web-app-builder，同时开源到了 GitHub：https://github.com/Leterhong/ai-web-app-builder
它不是一个空架子。它包含一整套方法论，触发条件怎么判断、标准目录结构长什么样、后端要遵守哪些规范、前端要做哪些事、容易踩哪些坑、交付前要跑哪些验收。
这里我特别想提它的验证清单。
Skill 第五节带了一份 36 项的「交付前必跑」清单，不是装饰品，是实打实的 HTTP 断言。我直接拿它对运行中的 Demo 实跑了一遍。
TOTAL 36 | PASS 36 | FAIL 0
ALL CHECKS PASSED关键的几条
[POST] /api/import/demo -- HTTP 200 pid=15
[POST] /api/ai/audit auto->demo -- mode=demo score=78
[bento] dependencies == 68 -- {'services':24,'dependencies':68,'risks':17,'critical':3}
[POST] /api/import/zip -- HTTP 200 pid=16
[POST] /api/ai/test (fake key) -- HTTP 200 ok=False err=HTTP 401 # 不崩
[analyze] invalid project_id -> error -- HTTP 404
[chat] invalid audit_id -> error -- HTTP 404这意味着，Skill 里写的每一条验收标准，都能在真实项目上被验证通过。Skill 不是空中楼阁，它和参考实现严丝合缝。
下次再接到「做个 AI 代码审查器」、「做个 AI SQL 优化器」、「做个 AI 文档分析台」这类需求，直接调用这个 Skill，它会给出标准目录、双模式开关模板、启发式扫描骨架、暗色 Bento 前端组件清单，以及那份 36 项验证清单。开发者只需要改 demo_data.py 的剧本和 analyzer 的扫描规则，就能在同样的结构上长出另一个 Demo。
而不必再从 venv 布局、包启动、npm 镜像这些坑里重新爬一遍。
收尾
从一个具体的好奇心，到一份能跑的 Demo，到一份能跑通的 Skill。这条路径本身就是这篇东西想说的事，把一次性的交付，变成可复用的能力。
上面每一张图都是运行中的真实页面截图，不是渲染占位。每一个数字都来自真实接口返回，不是手填。蓝耘那侧的 Base URL、Model ID 也是我刚刚从后端真读出来的，不是凭空编的。
你也可以照着上面那个 Model 配置页的填法，把你手上的蓝耘 Key 配进去，自己跑一遍。