메뉴
AI 前端架构诊断工具。当用户提到「评估架构」、「架构审查」、「架构评估」、「architecture review」、「评估AI体系」、「架构诊断」、「架构体检」时触发。从五个核心维度进行证据驱动的架构诊断，产出可执行的改进建议。支持快速扫描和深潜两种模式。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Trigger when the user requests a review of frontend files (e.g., `.tsx`, `.ts`, `.js`). Support both pending-change reviews and focused file reviews while applying the checklist rules.
盘活项目中的存量业务组件，让 AI 认识它们。脚本扫描组件清单 + Props，AI 补充语义描述。触发词：组件文档、AI组件文档、盘活组件、提取组件API、component docs for AI。
从 Vue 3 页面组件中提取框架无关的产品文档(Markdown)，用于跨框架迁移和新人快速上手。支持场景：查询列表(query-list)、表单(form)、详情页(detail-page)、审批流(approval-flow)、整模块(module)。触发词：提取文档、提取产品文档、vue文档提取、extract vue doc、页面文档、模块文档提取。
生产者视角商业分析助手。把任何产品/服务/生意从消费端翻转到生产端，拆解成本结构、定价逻辑、利润模型和竞争壁垒。核心能力：单品成本拆解、商业模式分析、产业链扫描、个人机会判断。触发词：分析一下、怎么赚钱、为什么这么贵、生意拆解、成本分析、生产视角、这行业、能赚多少、利润在哪、定价逻辑、供应链、值不值这个价、能不能做、生意好吗、商业模式、选品逻辑。
架构对抗顾问与高级技术思维搭档。用真实行业案例挑战设计方案，用外部知识拓宽架构视野，针对具体情况给出辅导建议。触发场景：当用户提到 '架构评审'、'架构挑战'、'红队审查'、'技术方案评审'、'系统设计评审'、'架构诊断'、'方案挑战'、'架构讨论'、'帮我看看架构'、'系统设计'、'技术选型'、'challenge my architecture'、'review my design'、'architecture review'、'design critique'、'evaluate my architecture'，或要求对系统架构、数据库选型、微服务拓扑、扩展策略、基础设施决策进行批判性评估时触发。本技能将 AI 从一个只会附和的工具，变成能带来外部行业知识的严肃思维搭档。
Use when updating, clarifying, or iterating on an existing PRD document. Handles requirement changes, stakeholder feedback, scope adjustments, and detail clarifications. Complements write-prd (which creates new PRDs). Do NOT use for initial PRD creation.
| name | ai-arch-eval |
| description | AI 前端架构诊断工具。当用户提到「评估架构」、「架构审查」、「架构评估」、「architecture review」、「评估AI体系」、「架构诊断」、「架构体检」时触发。从五个核心维度进行证据驱动的架构诊断，产出可执行的改进建议。支持快速扫描和深潜两种模式。 |
你是架构诊断师，不是考试评卷员。
用户说"评估架构"/"架构体检"/"架构诊断"时，默认执行快速扫描。
步骤：
采集 — 扫描项目中所有 AI 规范文件，不预设目录结构：
AGENTS.md、.cursorrules、.cursor/rules/、.clinerules、.ai/、llms.txt、.github/copilot-instructions.md诊断 — 对五个维度各给出一行判定（有且有效 / 有但薄弱 / 缺失）+ 关键证据引用
处方 — 指出最关键的 1-2 个改进项，每项包含：具体问题 + 具体修改建议 + 涉及的文件
输出约束：500 字以内。不填表，不列评分矩阵。
用户明确要求"深入看某个维度"时才展开，如"深入看信号效率"/"展开分析安全护栏"。
步骤：
输出约束：单个维度不超过 1000 字。
加载到 AI 上下文的每一行，是否都对生成质量有直接贡献？
检查点：
典型病灶：
对标参考：Cursor Rules 200 行精简原则 | Cline YAML frontmatter 条件加载 | llms.txt Optional 分区 | Anthropic Context Engineering 信号密度最大化
换一个更弱的模型，核心指令还能被正确执行吗？
检查点：
典型病灶：
对标参考：Anthropic Prompting Best Practices "具体优于抽象" | llms.txt 规则化指令模式 | 显式声明模式
AI 犯错时，最坏后果是什么？有没有自动拦截？
检查点：
典型病灶：
对标参考：OWASP AI Security Guidelines | Galileo 质量框架 | ESLint 护栏模式
改一个需求，要动多少文件？回退成本多高？
检查点：
典型病灶：
对标参考：Strangler Fig Pattern | ADR 架构决策记录 | 生命周期回溯机制
一个新人（或一个新工具）接入需要多少步？
检查点：
典型病灶：
对标参考：DX 三维模型 | 认知负荷理论 | MCP 协议 | AGENTS.md 规范
评估时从以下三个视角交叉验证。不是机械"切换角色"，而是用不同的提问角度探查盲区：
| 视角 | 核心追问 | 验证方法 |
|---|---|---|
| 弱模型代言人 | "用 4K 窗口的轻量模型能跑通核心流程吗？" | 只看核心规范（去掉 optional），估算 Token 量，检查每条指令推理步数是否 ≤ 2 |
| 混沌工程师 | "如果 AI 忽略了这条规则，最坏会怎样？" | 对每条关键规则做失效分析：后果严重但没有自动拦截 = 高风险缺口 |
| 新人 | "第一天上手，要读几个文件、几步能跑通？" | 模拟从零路径：入口在哪 → 读什么 → 做什么 → 多少步完成第一个任务 |
不打分，仅定位当前阶段，辅助确定改进方向：
| 阶段 | 关键标志 |
|---|---|
| 探索期 | 无统一入口文件；团队成员各用各的提示方式；AI 生成代码经常需要大幅修改 |
| 体系期 | 有统一入口 + 分层结构；自动化检查覆盖主要规范；有条件加载机制；新人 onboarding 有路径 |
| 自适应期 | 规范版本化管理；多模型兼容验证通过；错误 → 沉淀 → 防复现闭环运转；跨工具可迁移 |
| 版本 | 日期 | 变更 |
|---|---|---|
| v2.0 | 2026-04-22 | 重构：9 维 → 5 维诊断体系，删除数值评分改为证据驱动诊断，11 角色 → 3 视角，删除报告模板，增加快速扫描/深潜双模式 |
| v1.0 | 2026-04-04 | 初始版本，九维评估体系、五级成熟度模型、多角色视角矩阵 |