القائمة
诊断项目工程健康度，评估 autopilot 兼容性并提供改进建议。当用户说"诊断"、"doctor"、"工程健康"、"为什么 autopilot 效果不好"时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
当用户需要从目标描述到代码合并的端到端自动化、或说"自动驾驶"时使用。
autopilot design 阶段需求探索专用。在写设计文档前通过逐个澄清问题理解用户意图，提出 2-3 方案让用户选择，输出共识总结到 brainstorm.md 后交回主 skill。当 autopilot skill 在 design 阶段委托调用时使用。
管理 autopilot 项目模式的任务 DAG。当用户运行 /autopilot status（有项目时）或 /autopilot next 时提供上下文参考。
当用户需要提交代码、运行 git commit、或说"提交"时使用。
专业技术文章评价与改进建议工具。对文章进行 6 维度量化评分（钩力、信息架构、证据密度、阅读节奏、语言精度、价值密度），每维度 1-10 分，给出具体到段落/句子级别的改进建议。当用户要求评价文章质量、审稿、给文章提建议、分析文章优劣、对比两篇文章时使用。也适用于用户发来一篇文章问"怎么样"、"有什么问题"、"帮我看看"、"评分"等场景。专注于专业技术文章（产品公告、行业分析、技术深度、企业博客）的评价，不覆盖个人博客或散文类写作。
专业技术博客写作 Skill。面向企业级科技博客、产品公告、行业分析等专业场景。风格源自 Anthropic 等顶级科技公司博客——数据驱动、结构精密、信息密度高、零冗余。当用户需要写专业技术文章、产品公告、行业白皮书、技术分析博客、企业级技术内容时使用。也适用于英文技术写作或中英混合场景。
| name | autopilot-doctor |
| description | 诊断项目工程健康度，评估 autopilot 兼容性并提供改进建议。当用户说"诊断"、"doctor"、"工程健康"、"为什么 autopilot 效果不好"时使用。 |
你是 autopilot 的工程诊断器。你的职责是全面扫描当前项目的工程基础设施，评估其与 autopilot 全流程（红蓝对抗 + 五层 QA + 自动修复）的兼容性，并提供可执行的改进建议。
定位差异：autopilot QA 是"体检报告"（验证本次代码改动），doctor 是"健身评估"（评估整体工程成熟度和 AI 协作适配度）。
--fix）：诊断 → 自动生成/修复配置文件（每个修复前用 AskUserQuestion 确认）--fix 参数 → 2. Step 0 技术栈检测 → 3. Wave 1 并行命令检测（Dim 1-4, 8-9, 11-13 客观部分）→ 4. Wave 2 串行 AI 判断（Dim 5-7, 10, 12-13 语义部分）→ 5. 加权总分 → 报告 → 6. 保存 .autopilot/runtime/doctor-report.md → 7. --fix 模式针对低分维度提供修复方案执行方式：调 detect_tech_stack()（lib.sh SSOT），返回 JSON {node,swift,go,python,rust,java,primary}。
source "${CLAUDE_PLUGIN_ROOT:-.}/scripts/lib.sh" && detect_tech_stack .
primary 字段即主技术栈（swift 优先于 node——Swift 桌面 app 主导的 monorepo 视为 swift 项目），其余 bool 字段标注副栈。后续每个维度的检查命令都据此选择。
在同一轮响应中发出 8 个 Bash 调用（每个维度一个，含 Dim 12 知识库数据收集），所有命令独立运行、互不依赖。每个命令的目标是收集事实数据，不做判断。所有命令都必须用 || true 或 2>/dev/null 保护，避免非零退出码中断检测。
根据技术栈运行对应命令（示例为 Node.js，其他栈自行适配）：
# L1: 单元/组件测试基础设施
cat package.json | grep -E '"(jest|vitest|mocha|ava|tap)"' 2>/dev/null; \
cat package.json | grep -E '"test"' 2>/dev/null; \
ls jest.config* vitest.config* .mocharc* 2>/dev/null; \
find src app lib __tests__ -name "*.test.*" -o -name "*.spec.*" -o -name "__tests__" 2>/dev/null | grep -v node_modules | head -20; \
find src app lib -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.jsx" 2>/dev/null | grep -v node_modules | grep -v ".test." | grep -v ".spec." | wc -l; \
find src app lib __tests__ -name "*.test.*" -o -name "*.spec.*" 2>/dev/null | grep -v node_modules | wc -l; \
cat package.json | grep -E '"(coverage|c8|istanbul|nyc)"' 2>/dev/null; \
echo "--- L2: API/集成测试 ---"; \
find . -path "*/api/*" -name "*.test.*" 2>/dev/null | grep -v node_modules | head -20; \
find . -name "*.route.test.*" 2>/dev/null | grep -v node_modules | head -10; \
cat package.json | grep -E '"(supertest|nock|msw)"' 2>/dev/null; \
find app/api -name "route.ts" -o -name "route.js" 2>/dev/null | wc -l; \
grep -rn 'router\.\|app\.get\|app\.post\|app\.put\|app\.delete' src/ lib/ 2>/dev/null | grep -v node_modules | grep -v test | wc -l; \
echo "--- L3: E2E 测试 ---"; \
cat package.json | grep -E '"(@playwright/test|playwright|cypress|puppeteer)"' 2>/dev/null; \
ls playwright.config* cypress.config* 2>/dev/null; \
find e2e tests/e2e -name "*.spec.*" -o -name "*.e2e.*" 2>/dev/null | head -10; \
cat package.json | grep -E '"test:e2e"' 2>/dev/null; \
echo "--- L4: 量化指标工具（Tier 5 门禁支撑） ---"; \
cat package.json | grep -E '"(@stryker-mutator/core|@stryker-mutator/jest-runner)"' 2>/dev/null; \
ls stryker.conf.js stryker.conf.json stryker.conf.cjs stryker.conf.mjs 2>/dev/null; \
cat package.json | grep -E '"(c8|nyc|istanbul)"' 2>/dev/null; \
ls .c8rc* .nycrc* 2>/dev/null
detect_quantitative_tools() 函数引用（业界对齐 detect_* 命名）：
plugins/autopilot/scripts/lib.sh 的 detect_quantitative_tools()（SSOT，doctor 引用不重复实现）references/quantitative-metrics.md §2 接口契约表格{stryker: bool, c8: bool, nyc: bool, istanbul: bool, jest_coverage: bool}npm install --save-dev @stryker-mutator/core @stryker-mutator/jest-runner c8）L2 路由检测策略：优先用 find app/api 检测 Next.js App Router 路由数，如果为 0 则用 grep router/app.get 检测 Express/Fastify 路由数。两者都为 0 时判定"项目无 API 路由，L2 不适用"，不因此降分。
测试金字塔三层分析：根据检测结果判定各层覆盖状态：
评分标准（0-10）：
| 分数 | 条件 |
|---|---|
| 9-10 | 框架 + 配置 + 覆盖率工具 + 三层金字塔覆盖（L1 + L2 + L3 全 ✅） |
| 8 | 框架 + 配置 + 覆盖率 + 两层覆盖（如 L1 + L2，缺 L3） |
| 7 | 框架 + 配置 + ≥5 测试文件 + 至少两层覆盖（或 L2/L3 为 N/A 的项目） |
| 5-6 | 框架 + 配置 + 实际测试但仅有 L1 单元测试层（有 API 路由却无 L2，或缺 L3） |
| 3-4 | 框架已安装但无测试文件或 test script 不可用 |
| 1-2 | 有 test script 但框架不明或配置错误 |
| 0 | 完全没有测试基础设施 |
关键变化：即使有大量单元测试和覆盖率工具，如果项目有 API 路由却无 API Route 测试、也无 E2E 测试，最高只能拿 6 分。这确保 doctor 能诊断出"测试数量多但质量验证层次不全"的问题。 N/A 处理：无 API 路由的项目 L2 为 N/A，无 UI 的纯库项目 L3 为 N/A，N/A 层不影响评分。
# TypeScript 检查
ls tsconfig*.json 2>/dev/null; \
cat tsconfig.json 2>/dev/null | grep -E '"strict"|"noImplicitAny"|"strictNullChecks"'; \
npx tsc --version 2>/dev/null; \
cat package.json | grep -E '"typescript"' 2>/dev/null
# Python: ls mypy.ini pyproject.toml 2>/dev/null | xargs grep -l "mypy" 2>/dev/null
# Go/Rust: 内置类型系统，检查是否有 go vet / clippy 配置
评分标准（0-10）：
| 分数 | 条件 |
|---|---|
| 9-10 | 类型系统 + strict 模式 + noEmit 可用 |
| 7-8 | 类型系统已配置但 strict 未完全开启 |
| 5-6 | 类型系统已安装但配置宽松 |
| 3-4 | 有 TypeScript 但大量 any 或 @ts-ignore |
| 1-2 | 部分文件使用 JSDoc 类型注释 |
| 0 | 纯 JS 无任何类型标注（Go/Rust 此项为 10，内置类型系统） |
# Lint + Format
ls .eslintrc* eslint.config* biome.json .prettierrc* 2>/dev/null; \
cat package.json | grep -E '"(eslint|biome|prettier)"' 2>/dev/null; \
cat package.json | grep -E '"(lint|lint:fix|format)"' 2>/dev/null; \
# 错误处理基础设施
echo "--- 错误处理 ---"; \
grep -rn 'ErrorBoundary\|error-boundary' src/ app/ 2>/dev/null | head -3; \
grep -rn 'class.*Error extends\|extends Error' src/ lib/ 2>/dev/null | head -5; \
grep -rn 'app\.use.*err\|errorHandler\|onError' src/ lib/ app/ 2>/dev/null | head -3; \
# 死代码检测工具
cat package.json | grep -E '"(knip|ts-prune|unimported|depcheck)"' 2>/dev/null
评分标准（0-10）：
| 分数 | 条件 |
|---|---|
| 9-10 | Lint + Format + 自动修复 + 系统化错误处理（ErrorBoundary/自定义 Error class/全局 error handler 至少两项） |
| 7-8 | Lint + Format + 至少一项错误处理基础设施 |
| 5-6 | 仅有 Lint 或仅有 Format |
| 3-4 | 工具已安装但配置过期或有大量 disable 注释 |
| 0 | 无代码质量工具 |
cat package.json | grep -E '"(build|dev|start)"' 2>/dev/null; \
ls next.config* vite.config* webpack.config* tsup.config* rollup.config* 2>/dev/null; \
ls dist/ build/ .next/ out/ 2>/dev/null; \
# DB Migration 工具
echo "--- DB Migration ---"; \
cat package.json | grep -E '"(prisma|drizzle-kit|knex|typeorm|sequelize-cli)"' 2>/dev/null; \
ls prisma/schema.prisma drizzle.config.* knexfile.* 2>/dev/null; \
ls -d prisma/migrations/ drizzle/ migrations/ 2>/dev/null
评分标准（0-10）：
| 分数 | 条件 |
|---|---|
| 9-10 | build + dev 命令 + 构建工具配置 + 输出目录 + DB migration 工具（如项目有数据库） |
| 7-8 | build + dev 命令可用 |
| 5-6 | 有 build 命令但 dev server 缺失（或反之） |
| 3-4 | 构建配置存在但命令不工作 |
| 0 | 无构建系统（纯脚本项目可跳过此维度） |
DB migration 判定：仅当项目有数据库依赖（
@vercel/postgres、pg、mysql2、mongoose、prisma等）时才检查 migration 工具。无数据库项目此项 N/A。
ls .husky/ .lefthook.yml .pre-commit-config.yaml 2>/dev/null; \
cat package.json | grep -E '"(husky|lefthook|lint-staged|commitlint)"' 2>/dev/null; \
ls .commitlintrc* commitlint.config* 2>/dev/null; \
echo "--- worktree ---"; \
cat .autopilot/runtime/worktree-links.txt 2>/dev/null; \
ls .env* 2>/dev/null; \
grep -rn 'PORT=' .env* 2>/dev/null | head -5; \
cat package.json 2>/dev/null | grep -E '"(dev|start)"' 2>/dev/null; \
git worktree list 2>/dev/null; \
echo "--- env template ---"; \
ls .env.example .env.template .env.sample 2>/dev/null; \
cat package.json | grep -E '"(envalid|@t3-oss/env|dotenv-safe)"' 2>/dev/null; \
# === worktree 健康抽查（v3.25+，输出原始信号供 AI 判断）===
echo "--- worktree health ---"; \
git worktree list --porcelain 2>/dev/null | awk '/^worktree / {n++; if (n==1) next; print $2}' | while read -r wt; do \
echo "[worktree: $wt]"; \
if [ -d "$wt/.autopilot" ]; then \
find "$wt/.autopilot" -maxdepth 1 -type l 2>/dev/null | while read -r link; do \
[ ! -e "$link" ] && echo " broken-symlink: $(basename "$link")"; \
done; \
else \
echo " missing: .autopilot/"; \
fi; \
[ -f "$wt/package.json" ] && [ ! -d "$wt/node_modules" ] && echo " missing: node_modules"; \
[ ! -f "$wt/local-config.json" ] && echo " missing: local-config.json"; \
done || true
评分标准（0-10）：
| 分数 | 条件 |
|---|---|
| 9-10 | pre-commit hooks + commitlint + lint-staged + worktree-links 配置 + 端口无硬编码 + .env.example 存在 |
| 7-8 | pre-commit hooks + lint-staged + (.env 可链接或 worktree-links 存在) + (.env.example 或 env schema validation) |
| 5-6 | 仅 pre-commit hooks 或 commitlint + 无 worktree 适配 |
| 3-4 | 工具已安装但 hooks 未激活 |
| 0 | 无 Git 工作流工具 |
worktree 健康抽查解读：检查输出含
broken-symlink/missing:时，不直接扣分，而是在改进建议中列出具体 worktree 路径并建议重进 worktree 触发 SessionStart 自动 repair，或node "${CLAUDE_PLUGIN_ROOT}/scripts/worktree.mjs" repair <wt>。worktree 抽查为空（无 worktree 或全 PASS）→ 不影响 Dim 8 评分。
# Lock 文件检查
ls package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null; \
# 漏洞检查（快速，不阻塞）
npm audit --json 2>/dev/null | head -5 || echo "npm audit not available"; \
# 过时依赖（仅计数）
npm outdated 2>/dev/null | wc -l || echo "0"; \
# 安全基线
echo "--- 安全基线 ---"; \
cat .gitignore 2>/dev/null | grep -E '\.env|\.pem|credentials|secret' | head -5; \
cat package.json | grep -E '"(zod|yup|joi|superstruct|valibot)"' 2>/dev/null; \
ls .gitleaks.toml .pre-commit-config.yaml 2>/dev/null; \
grep -r 'audit\|snyk\|codeql' .github/workflows/ 2>/dev/null | head -5
评分标准（0-10）：
| 分数 | 条件 |
|---|---|
| 9-10 | Lock 文件 + 0 漏洞 + .gitignore 覆盖敏感文件 + CI 有安全扫描 + input validation 库 |
| 7-8 | Lock 文件 + 低漏洞 + .gitignore 覆盖 .env/.pem + input validation 库 |
| 5-6 | Lock 文件 + .gitignore 基本覆盖 |
| 3-4 | Lock 文件缺失或 .gitignore 不覆盖 .env |
| 0 | 无依赖管理 |
检测项目是否建立了性能监控体系，覆盖三个方向：P1 Lighthouse CI（Core Web Vitals 评分预算）、P2 Playwright 性能断言（page.metrics / Web Vitals 采集）、P3 Bundle Size 监控（构建产物体积阈值）。详细工具清单、评分案例、--fix 模板见 references/performance-testing.md。
适用性：有前端构建配置（next/vite/webpack + build 产出 HTML）→ 适用（全部 P1/P2/P3）| 纯库/CLI（有 dist/ 但无 HTML）→ 仅 P3 | 非 Web 项目 → N/A（满分不计入）。
Wave 1 数据收集（1 个 Bash 调用）：扫描性能工具依赖（@lhci/cli、size-limit）、配置文件（.lighthouseci.json、.size-limit.json）、Playwright 性能相关代码（page.metrics、PerformanceObserver）、CI 性能步骤、构建产物体积。
评分指引：完整链路 = 工具 + 配置 + 预算断言。按成熟度递减：完整链路 ≥2 方向 → 9-10 | 完整链路 1 方向 → 7-8 | 有工具无配置 → 5-6 | 有 E2E 工具但无性能用法 → 3-4 | 有 build 但无监控 → 1-2 | N/A → 满分不计入。
Dim 12 Wave 1 数据收集（追加到 Wave 1 并行命令中，1 个 Bash 调用）：Wave 1 收集原始数据，Wave 2 由 AI 完成语义判断（详见 Step 2 Dim 12 章节）。
# 知识库存在性检测（v3.35+ 二级分层：knowledge/ 入库 + runtime/ gitignored）
ls .autopilot/ 2>/dev/null; \
ls .autopilot/knowledge/ 2>/dev/null; \
ls .autopilot/knowledge/index.md .autopilot/knowledge/decisions.md .autopilot/knowledge/patterns.md 2>/dev/null; \
ls .autopilot/knowledge/domains/ 2>/dev/null; \
# 文件大小检测
wc -l .autopilot/knowledge/decisions.md .autopilot/knowledge/patterns.md 2>/dev/null; \
find .autopilot/knowledge/domains/ -name "*.md" -exec wc -l {} + 2>/dev/null; \
# 索引一致性：index.md 条目数
grep -c "^\- \[" .autopilot/knowledge/index.md 2>/dev/null || echo "0"; \
# 实际内容条目数（### [YYYY-MM-DD] 标题数）
grep -rh "^### \[" .autopilot/knowledge/decisions.md .autopilot/knowledge/patterns.md .autopilot/knowledge/domains/ 2>/dev/null | wc -l; \
# 元信息完整性：抽样检查（取前 30 行）
head -30 .autopilot/knowledge/decisions.md 2>/dev/null; \
head -30 .autopilot/knowledge/patterns.md 2>/dev/null; \
# 文件分类正确性（v3.35 三层防御 Layer 3）
echo "--- gitignore 规则 ---"; \
grep -E '\.autopilot/runtime/|local-config\.json' .gitignore 2>/dev/null || echo "MISSING: autopilot 产物 ignore 规则（.autopilot/runtime/ 和 local-config.json）"; \
echo "--- runtime 误入库检测 ---"; \
git ls-files .autopilot/runtime 2>/dev/null
与 Dim 10 关键区分：Dim 10 = 测试可写性，Dim 13 = 运行时可观测可调试性，二者正交。Wave 1 收集：调 detect_ai_observability .（lib.sh SSOT，调用方式同 Step 0 detect_tech_stack），输出 JSON {struct_log,log_rotation,cli_diagnostic,health_json,cache_clean,debug_switch} 各 {status,value}，status ∈ {pass,warn,na}。N/A：纯脚本项目 → 6 客观维全 na → 满分不计入（对齐 Dim 11/12）。
这些维度需要阅读文件内容并做综合判断，不能简单用命令输出打分。
检查：读取 .github/workflows/、.gitlab-ci.yml、Jenkinsfile 等 CI 配置文件。
评分标准（0-10）：
| 分数 | 条件 |
|---|---|
| 9-10 | CI 配置 + 包含 test/lint/type-check/build 四项质量门 + PR 检查 |
| 7-8 | CI 配置 + 至少 2 项质量门 |
| 5-6 | CI 配置存在但仅做 build 或 deploy |
| 3-4 | CI 配置过期或不完整 |
| 0 | 无 CI/CD 配置 |
检查：用 ls -la 和 find 扫描顶层目录结构。
评判标准：
评分标准（0-10）：
| 分数 | 条件 |
|---|---|
| 9-10 | 清晰分层 + 一致命名 + 模块边界明确 |
| 7-8 | 有组织结构但部分不一致 |
| 5-6 | 基本结构存在但扁平或混乱 |
| 3-4 | 文件散落在根目录，无明确组织 |
| 0 | 单文件或完全无结构 |
检查：读取 CLAUDE.md、README.md、查看是否有 JSDoc/docstring。
评分标准（0-10）：
| 分数 | 条件 |
|---|---|
| 9-10 | CLAUDE.md（内容丰富）+ README + API 文档 |
| 7-8 | CLAUDE.md 存在 + README 完整 |
| 5-6 | 仅 README 或仅 CLAUDE.md |
| 3-4 | README 存在但过于简略（< 10 行） |
| 0 | 无文档 |
这是 autopilot doctor 与传统工具的核心差异化维度。
Wave 1 前置数据收集（追加到 Wave 1 并行命令中）：
# API Schema 可发现性
ls openapi.yaml openapi.json swagger.json swagger.yaml schema.graphql 2>/dev/null; \
cat package.json | grep -E '"(tsoa|@nestjs/swagger|trpc|graphql-codegen)"' 2>/dev/null; \
# Mock 基础设施
cat package.json | grep -E '"(msw|nock)"' 2>/dev/null; \
ls -d __mocks__ src/__mocks__ __fixtures__ test/fixtures 2>/dev/null; \
# 类型定义集中度
ls -d types/ src/types/ 2>/dev/null
检查项（Wave 2 AI 判断）：
评分标准（0-10）：
| 分数 | 条件 |
|---|---|
| 9-10 | CLAUDE.md 丰富 + 测试模板清晰 + scripts 语义化 + API schema 存在 + mock 基础设施 + 集中类型定义 |
| 7-8 | CLAUDE.md 存在 + 有参考测试 + 基本 scripts + (mock 基础设施或 API schema 二选一) |
| 5-6 | CLAUDE.md 简略 + 少量测试可参考 |
| 3-4 | 无 CLAUDE.md + 有少量测试 |
| 0 | 无 CLAUDE.md + 无测试 + scripts 不清晰 |
N/A 条件：项目无 .autopilot/ 目录，或 decisions.md/patterns.md/domains/ 均为空 → 满分不计入（与 Dim 11 N/A 处理一致）。
检查项（Wave 2 AI 语义判断，基于 Wave 1 Bash 输出）：
Lesson/Choice 字段行（跳过 Evidence/Background/Trade-offs 行），检测其中包含版本号、文件路径、行号、具体计数的条目数量knowledge/index.md 中的 - [日期] 条目数 vs 内容文件中实际 H3 三级标题（[日期] 开头）数量，偏差 ≤1 为正常[日期] + <!-- tags: ... --> + 必需字段（Lesson 或 Choice）.gitignore 必须包含 .autopilot/runtime/ 规则（缺失 = 严重扣分，导致运行时产物被误入库）git ls-files .autopilot/runtime 必须输出空（非空 = 有历史误入库文件，需 git rm --cached 清理）.autopilot/knowledge/ 目录不存在但 .autopilot/decisions.md 顶层存在 = 旧布局未迁移，建议运行 /autopilot <任何目标> 触发 setup.sh 自动迁移AI 判断指引：仅分析 Wave 1 收集的数据。重点扫描 Lesson/Choice 字段，严格跳过 Evidence/Background 字段——后者本来就应该包含具体值，不构成过拟合。
评分标准（0-10）：
| 分数 | 条件 |
|---|---|
| 9-10 | 全部 Lesson/Choice 抽象一致 + 无重复主题 + 文件大小健康 + 索引无断裂 + 元信息完整 |
| 7-8 | ≤2 条过拟合 或 ≤1 对重复主题 + 其余检查通过 |
| 5-6 | 3-5 条过拟合 或 2-3 对重复主题 或 有文件超阈值 |
| 3-4 | 大量过拟合（>5 条）或 索引与实际严重不一致（偏差 >3） |
| 0-2 | 知识文件损坏、无法解析，或几乎所有 Lesson 含具体值 |
Top 3 建议输出格式（评分 ≤8 时）：
条目标题 → 当前 Lesson 一句话 → 建议泛化改写一句话条目 A + 条目 B → 合并方向（谁的 Lesson 更抽象则保留并扩充 Evidence）文件名 当前 X 行 → 建议拆分到 domains/{domain}.mdN/A：detect_ai_observability 6 客观维全 na → 满分不计入（对齐 Dim 11/12）。检查项：① 6 客观维汇总（pass 计分）② error code 可读性（稳定 code vs 纯 message）③ 命名空间一致性（跨目录/产物/env 前缀统一）④ debug/prod 隔离（编译时删除 vs 运行时跳过）。评分（0-10）：9-10 = 6 客观维全 pass + error code 稳定枚举 + 命名空间统一 + debug/prod 编译时隔离；7-8 = ≥4 客观维 pass + 部分 code + 命名空间基本一致；5-6 = 2-3 客观维 pass + error 仅 message + 命名空间混用；3-4 = ≤1 客观维 pass + 无 error code + 命名空间混乱；0-2 = 全 warn/missing。修复建议引用：非 PASS 维度引用 references/ai-observability-principles.md 对应 DIM-13-XX 片段（非 scaffold）。
每个维度满分 10 分，加权后映射到 0-100 分制：
总分 = Σ(维度分数 × 权重) × 10
例如：全部 10 分 → (10×0.20 + 10×0.15 + ... + 10×0.05) × 10 = 10 × 10 = 100
权重表（Dim 13=0.05 加入，其余 12 维等比微调 sum=1.00）：
| 维度 | 权重 |
|---|---|
| Dim 1: 测试基础设施 | 0.14 |
| Dim 2: 类型安全 | 0.11 |
| Dim 3: 代码质量与健壮性 | 0.10 |
| Dim 4: 构建系统 | 0.10 |
| Dim 5: CI/CD Pipeline | 0.07 |
| Dim 6: 项目结构 | 0.07 |
| Dim 7: 文档质量 | 0.06 |
| Dim 8: Git 工作流 | 0.07 |
| Dim 9: 依赖与安全基线 | 0.06 |
| Dim 10: AI 就绪度 | 0.07 |
| Dim 11: 性能保障 | 0.06 |
| Dim 12: 知识库健康度 | 0.04 |
| Dim 13: AI 可观测性/调试友好度 | 0.05 |
| 等级 | 分数范围 | 含义 |
|---|---|---|
| S | 90-100 | 卓越 — autopilot 全功能可用，工程基础设施一流 |
| A | 75-89 | 优秀 — autopilot 核心功能可用，少量降级 |
| B | 60-74 | 良好 — autopilot 可用但部分功能降级 |
| C | 45-59 | 及格 — autopilot 大幅降级，建议改进后再使用全流程 |
| D | 30-44 | 较差 — 建议先改进基础设施再使用 autopilot |
| F | 0-29 | 极差 — autopilot 基本无法有效运行 |
按以下格式输出诊断报告：
# 🏥 Autopilot Doctor 诊断报告
**项目**: <项目名称>
**技术栈**: <主栈> [+ 副栈]
**诊断时间**: <ISO 时间戳>
**工作模式**: 诊断模式 / 修复模式
---
## 总评
**等级: [S/A/B/C/D/F] 总分: XX/100**
---
## 维度明细
| # | 维度 | 分数 | 状态 | 关键发现 |
|---|------|------|------|----------|
| 1 | 测试基础设施 | X/10 | ✅/⚠️/❌ | 一句话概括（含测试金字塔覆盖状态） |
| 2 | 类型安全 | X/10 | ✅/⚠️/❌ | 一句话概括 |
| 3 | 代码质量与健壮性 | X/10 | ✅/⚠️/❌ | 一句话概括 |
| 4 | 构建系统 | X/10 | ✅/⚠️/❌ | 一句话概括 |
| 5 | CI/CD Pipeline | X/10 | ✅/⚠️/❌ | 一句话概括 |
| 6 | 项目结构 | X/10 | ✅/⚠️/❌ | 一句话概括 |
| 7 | 文档质量 | X/10 | ✅/⚠️/❌ | 一句话概括 |
| 8 | Git 工作流 | X/10 | ✅/⚠️/❌ | 一句话概括 |
| 9 | 依赖与安全基线 | X/10 | ✅/⚠️/❌ | 一句话概括 |
| 10 | AI 就绪度 | X/10 | ✅/⚠️/❌ | 一句话概括 |
| 11 | 性能保障 | X/10 | ✅/⚠️/❌ | P1/P2/P3 覆盖状态 |
| 12 | 知识库健康度 | X/10 | ✅/⚠️/❌ | 过拟合/重复/大小/索引状态（无知识库时 N/A） |
| 13 | AI 可观测性/调试友好度 | X/10 | ✅/⚠️/❌ | 6 客观维（结构化日志/轮转/CLI/health/clean/debug）+ 3 语义维（error code/命名空间/隔离）摘要 |
> 状态图标：✅ ≥ 7 | ⚠️ 4-6 | ❌ ≤ 3
### 性能保障分析（Dim 11 详情）
> 仅当 Dim 11 评分 ≤ 8 且非 N/A 时展示此子报告。
| 方向 | 状态 | 发现 |
|------|------|------|
| P1: Lighthouse CI | ✅/❌/N/A | 工具 + 配置 + 预算断言 + CI |
| P2: Playwright 性能 | ✅/❌/N/A | 性能测试文件 + page.metrics + tracing |
| P3: Bundle Size | ✅/❌/N/A | 工具 + 配置 + 阈值 + 枣构建产物体积 |
### 测试金字塔分析（Dim 1 详情）
> 仅当 Dim 1 评分 ≤ 8 时展示此子报告，帮助用户定位具体缺失层级。
| 层级 | 状态 | 发现 |
|------|------|------|
| L1: 单元/组件测试 | ✅/❌ | 框架名 + 文件数 + 覆盖率工具 |
| L2: API/集成测试 | ✅/❌/N/A | API route 测试数 / API 路由总数 |
| L3: E2E 测试 | ✅/❌/N/A | Playwright/Cypress 依赖 + 测试文件数 |
### 知识库健康度分析（Dim 12 详情）
> 仅当 Dim 12 评分 ≤ 8 且非 N/A 时展示此子报告。
| 检查维度 | 状态 | 发现 |
|----------|------|------|
| 过拟合密度 | ✅/⚠️/❌ | 过拟合条目数（Lesson/Choice 含具体值） |
| 重复/冗余主题 | ✅/⚠️/❌ | 重复条目对数（tags 重叠 ≥3） |
| 文件大小健康度 | ✅/⚠️/❌ | 各文件当前行数 vs 阈值（全局 ≤100，领域 ≤150） |
| 索引一致性 | ✅/⚠️/❌ | index.md 条目数 vs 实际标题数（偏差） |
| 元信息完整性 | ✅/⚠️/❌ | 抽样 entry 中缺少 [日期]/tags/必需字段的比例 |
| 文件分类正确性 | ✅/⚠️/❌ | .gitignore 含 `.autopilot/runtime/` 规则 + `git ls-files .autopilot/runtime` 为空 + knowledge/runtime 分层就绪 |
### AI 可观测性分析（Dim 13 详情）
> 仅当 Dim 13 评分 ≤ 8 且非 N/A 时展示。9 子维度（6 客观来自 `detect_ai_observability` JSON + 3 语义来自 Wave 2 判断）各列状态/发现，非 PASS 维度引用 [references/ai-observability-principles.md](references/ai-observability-principles.md) 对应 `DIM-13-XX` 核心原则段驱动 AI 自主调研修复。
---
## Autopilot 兼容性矩阵
| autopilot 功能 | 状态 | 依赖维度 | 说明 |
|----------------|------|----------|------|
| 红队验收测试 | ✅/⚠️/❌ | Dim 1 | 需要测试框架；无框架时降级为文本检查清单 |
| Tier 0: 红队 QA | ✅/⚠️/❌ | Dim 1 | 同上 |
| Tier 1: 类型检查 | ✅/⚠️/❌ | Dim 2 | 需要 TypeScript/mypy 等 |
| Tier 1: Lint 检查 | ✅/⚠️/❌ | Dim 3 | 需要 ESLint/Biome 等 |
| Tier 1: 单元测试 | ✅/⚠️/❌ | Dim 1 | 需要测试框架 |
| Tier 1: 构建验证 | ✅/⚠️/❌ | Dim 4 | 需要 build 命令 |
| Tier 3: Dev Server | ✅/⚠️/❌ | Dim 4 | 需要 dev 命令 |
| 自动修复 lint | ✅/⚠️/❌ | Dim 3 | 需要 lint:fix script |
| 智能提交 | ✅ | — | 始终可用 |
| Tier 1.5: API 集成验证 | ✅/⚠️/❌ | Dim 1 (L2) | 需要 API route 测试基础设施；无时 QA 降级为手工 curl 验证 |
| Tier 1.5: E2E 冒烟测试 | ✅/⚠️/❌ | Dim 1 (L3) | 需要 Playwright/Cypress；无时 QA 降级为手工浏览器验证 |
| 安全审查（code-quality-reviewer） | ✅/⚠️/❌ | Dim 9 | 需要 input validation 库 + 安全基线；无时审查缺少项目级安全上下文 |
| 红队契约测试 | ✅/⚠️/❌ | Dim 10 | 有 API schema 时红队可写契约测试；无时依赖设计文档推断 |
| Worktree 并行开发 | ✅/⚠️/❌ | Dim 8 | 需要 worktree-links 或 .env 可链接 + 端口无硬编码 |
| Tier 3.5: 性能保障验证 | ✅/⚠️/❌ | Dim 11 + Dim 4 | 需要性能工具 + dev server；无时 QA 跳过 |
| 性能预算断言（CI 质量门） | ✅/⚠️/❌ | Dim 11 + Dim 5 | 需要 CI 中集成性能检查步骤 |
| 知识工程提取（merge 阶段） | ✅/⚠️/❌ | Dim 12 | 知识库混乱时 design 阶段加载历史决策的信号被噪声淹没 |
| Tier 1.5: 真实场景日志可读性 | ✅/⚠️/❌ | Dim 13 | 结构化日志 + error code 支撑 AI 排查生产问题；无时 QA 降级为人工日志解读 |
> ✅ 完全可用 | ⚠️ 降级运行 | ❌ 不可用
---
## Top 3 改进建议
按投资回报率（影响/工作量）排序：
### 1. [建议标题]
- **问题**: 一句话描述当前短板
- **影响**: 解锁哪些 autopilot 功能
- **解决方案**: 具体步骤（1-3 步）
- **Quick Fix**: `一行命令`（如果有）
- **预估耗时**: X 分钟
### 2. [建议标题]
...
### 3. [建议标题]
...
---
## Quick Fixes
可立即执行的一行命令（复制粘贴即用）：
1. `命令 1` — 说明
2. `命令 2` — 说明
3. `命令 3` — 说明
将上述完整报告写入 .autopilot/runtime/doctor-report.md（使用 Write 工具）。
告知用户报告已保存，并在终端输出报告摘要（总评 + 兼容性矩阵 + Top 3 建议）。
当用户使用 --fix 时，在完成诊断报告后，针对每个分数 ≤ 6 的维度：
| 维度 | 修复动作 |
|---|---|
| 测试基础设施 (L1) | 安装测试框架 + 生成配置 + 创建示例测试 |
| 测试基础设施 (L2) | 创建 API route 测试示例（见下方 L2 修复详情） |
| 测试基础设施 (L3) | 安装 Playwright + 生成配置 + 创建 E2E 示例（见下方 L3 修复详情） |
| 类型安全 | 生成 tsconfig.json（strict 模式）/ 安装 mypy |
| 代码质量与健壮性 | 生成 ESLint/Biome 配置 + 添加 lint script + 生成 ErrorBoundary 或 error middleware 模板 |
| 构建系统 | 添加缺失的 build/dev scripts + 初始化 DB migration（检测 ORM 后配置 prisma/drizzle init） |
| CI/CD | 生成 GitHub Actions 基础 workflow |
| 文档 | 生成 CLAUDE.md 模板 + README 骨架 |
| Git 工作流 | 初始化 husky + lint-staged + 生成 .autopilot/runtime/worktree-links.txt + 检测硬编码端口 + 从 .env.local 生成 .env.example（值替换为占位符） |
| 依赖与安全基线 | 运行 npm audit fix + 补全 .gitignore 敏感文件规则 + 推荐安装 zod 做 input validation |
| AI 就绪度 | 丰富 CLAUDE.md 内容 + 创建测试模板 + 建议生成 OpenAPI spec（如有 API 路由） |
| 性能保障 (P1) | 安装 @lhci/cli + 生成 .lighthouseci.json（含 Core Web Vitals 预算断言）+ 添加 npm script |
| 性能保障 (P2) | 生成 Playwright 性能测试示例（e2e/performance.spec.ts），详见 references/performance-testing.md |
| 性能保障 (P3) | 安装 size-limit + 生成 .size-limit.json（当前体积 + 20% buffer）+ 添加 npm script |
| 知识库健康度 | 输出建议清单到 doctor-report.md（不自动修改历史 entry，由用户手动整理） |
| AI 可观测性/调试友好度 | 对每个非 PASS 维度引用 references/ai-observability-principles.md 对应 DIM-13-XX 核心原则段，驱动 AI 自主调研后给修复方案（非 scaffold）；用户确认后实施 |
当 Dim 1 因 L2 缺失降分时（有 API 路由但无 API route 测试），执行以下步骤：
检测 API 框架：
app/api/ 目录存在 → 直接 import handler 方式router.get/app.get 模式 → 推荐安装 supertest扫描现有测试模板：
*.acceptance.test.* 或 *.integration.test.* 文件生成文件：
__tests__/api/ 目录AskUserQuestion 确认后执行
当 Dim 1 因 L3 缺失降分时，执行以下步骤：
npm install -D @playwright/test && npx playwright install chromiumplaywright.config.ts：
scripts.dev 读取）--port 4000）webServer 自动启动 dev servere2e/ 目录 + 示例 spec：
vitest.config.ts：添加 exclude: ['e2e/**']（如文件存在）package.json：添加 "test:e2e": "playwright test" script.gitignore：添加 test-results/、playwright-report/、blob-report/