企业官网建设流程全解析

1. 这不是“AI审PR”，而是重构代码协作的临界点

你有没有遇到过这样的场景：团队里刚 merge 了一条 PR，CI 通过了，测试也绿了，但上线后用户反馈“搜索功能突然卡顿三秒”——回溯发现，是某位新人在useSearchHook 里悄悄加了个未节流的debounce(50)，而这个改动被淹没在 37 行 diff 里，没人注意到它把原本每秒触发 2 次的请求放大成了每秒 20 次。这不是虚构，是我上个月在电商后台项目里真实踩过的坑。而 Matt Pocock 在 AI Engineer Paris 2026 上演示的/pr skill，恰恰就是为解决这类“高可信度、低可见性”的隐性风险而生的——它不替代 Code Review，而是把 Review 的颗粒度从“函数级”压到“意图级”，把“这段代码做了什么”翻译成“它想解决什么问题、可能引发什么副作用、是否符合当前架构契约”。

关键词/pr和skill看似简单，实则承载着两层关键信息：/pr是 GitHub 原生交互入口，代表它无缝嵌入现有工作流，不强制迁移；skill则不是传统意义上的插件或脚本，而是指一种可组合、可验证、可复用的语义化能力单元——它封装的不是具体命令（如git checkout），而是对“代码意图”的结构化理解与推理能力。比如一个performance-safetyskill，它不关心你用的是lodash.throttle还是useDebounce，只校验“高频触发逻辑是否被合理节流”这一契约是否被满足。这正是 Matt 的方案区别于其他 AI 工具的核心：它不生成代码，也不解释代码，而是对代码背后的设计决策进行可信度审计。

我试过把这套逻辑套用在我们团队的 CI 流程里。过去，我们靠 ESLint 规则防低级错误，靠 SonarQube 查复杂度，靠人工 Review 抓架构一致性——三层防线，但漏洞依然存在。而/pr skill的介入点很特别：它在 PR 描述提交后、CI 启动前，就基于 PR 标题、描述、关联 issue、diff 内容，调用一组预置 skill 进行并行评估。比如auth-contractskill 会检查所有新增的 API 路由是否都声明了@AuthRequired注解；>{ "id": "security-scan", "version": "1.0.0", "name": "API Key Leak Detector", "description": "Scans added lines for hardcoded secrets in common patterns", "inputSchema": { "type": "object", "properties": { "addedLines": { "type": "array", "items": { "type": "string" } }, "context": { "type": "object", "properties": { "fileExtension": { "type": "string" } } } } }, "outputSchema": { "type": "object", "properties": { "severity": { "enum": ["high", "medium", "low"] }, "evidence": { "type": "array", "items": { "type": "string" } }, "suggestion": { "type": "string" } } } }

这个文件定义了 skill 的输入输出结构。关键点在于inputSchema强制要求addedLines是字符串数组——这意味着 skill 只关注新增代码，天然规避了“误报历史代码”的问题。outputSchema的severity字段采用枚举而非自由文本，确保下游系统能可靠解析。

3.2 实现核心扫描逻辑（25 分钟）

我用 Node.js + Express 实现，核心是scanForSecrets函数：

// utils/secret-scanner.js const SECRET_PATTERNS = [ // AWS Access Key (AKIA...) { regex: /AKIA[0-9A-Z]{16}/g, label: "AWS Access Key" }, // Google Cloud API Key { regex: /AIza[0-9A-Za-z_-]{35}/g, label: "Google Cloud API Key" }, // Generic password pattern { regex: /password\s*[:=]\s*["']([^"']+)["']/gi, label: "Hardcoded Password" } ]; function scanForSecrets(addedLines) { const findings = []; addedLines.forEach((line, index) => { SECRET_PATTERNS.forEach(pattern => { const matches = line.match(pattern.regex); if (matches && matches.length > 0) { matches.forEach(match => { findings.push({ lineIndex: index, content: line.trim(), patternLabel: pattern.label, matchedValue: match }); }); } }); }); return findings; } module.exports = { scanForSecrets };

这个实现刻意保持极简：不依赖外部库，不调用 LLM，只做确定性正则匹配。为什么？因为硬编码密钥是 100% 的确定性风险，不需要“概率判断”。实测中，它比 GitHub 的 secret scanning 更快（因为只扫新增行），且误报率更低（因为我们只匹配password = "xxx"这种明显模式，不匹配const PASSWORD = "xxx"这种变量声明）。

3.3 构建 Skill 服务（12 分钟）

创建server.js：

const express = require('express'); const { scanForSecrets } = require('./utils/secret-scanner'); const app = express(); app.use(express.json()); app.post('/analyze', (req, res) => { const { addedLines, context } = req.body; // 输入验证：确保 addedLines 存在且为数组 if (!Array.isArray(addedLines)) { return res.status(400).json({ error: "addedLines must be an array" }); } const findings = scanForSecrets(addedLines); if (findings.length === 0) { return res.json({ severity: "low", evidence: [], suggestion: "No hardcoded secrets detected in added lines." }); } // 高危发现立即标 high const highRiskFindings = findings.filter(f => f.patternLabel.includes("AWS") || f.patternLabel.includes("Google") ); res.json({ severity: highRiskFindings.length > 0 ? "high" : "medium", evidence: findings.map(f => `Line ${f.lineIndex + 1}: ${f.content} -> ${f.patternLabel} (${f.matchedValue})` ), suggestion: "Replace hardcoded secrets with environment variables or secret management service." }); }); app.listen(3001, () => { console.log('Security Scan Skill running on http://localhost:3001'); });

启动服务：node server.js。现在，你可以用 curl 测试：

curl -X POST http://localhost:3001/analyze \ -H "Content-Type: application/json" \ -d '{ "addedLines": ["const apiKey = \"AIzaSyBd1234567890abcdef1234567890abcdef\";"], "context": {"fileExtension": ".js"} }'

你会得到精准的高危告警。这个 skill 已经具备生产可用性——它轻量、快速、可审计，且完全可控。

提示：不要试图用一个 skill 覆盖所有安全问题。Matt 的团队实践是“小 skill，多组合”：security-scan只管密钥，cors-config只管 CORS 头，sql-injection只管拼接 SQL。每个 skill 专注一个契约，组合起来才形成完整防护网。

4. 从skill到skill ecosystem：如何让团队真正用起来

技术再好，如果没人用，就是废纸。我们在落地/pr skill时，最大的教训不是技术问题，而是组织惯性。最初我们把security-scanskill 设为 PR 检查必过项，结果三天内收到 17 条抱怨：“为什么我的 PR 卡在 security-scan？它说password = "test"是高危，但我只是测试用！”——问题不在 skill，而在我们没给团队建立“skill 使用心智”。

4.1 三阶段渐进式 Adoption 策略

我们最终采用 Matt 提倡的“三步走”策略，效果显著：

阶段一：只读模式（Read-Only Mode）
持续 2 周，所有 skill 运行但不阻断 CI。结果以灰色评论形式出现在 PR 底部，标题为[Skill Insight]。重点是教育：每条评论末尾加一句“为什么这个很重要？”的解释。比如security-scan的评论末尾会写：“硬编码密钥一旦泄露，攻击者可直接访问云资源，平均修复成本是 $23,000（2024 Verizon DBIR 报告）。” 这个阶段，团队开始主动点击 skill 评论看详情，而不是忽略。

阶段二：建议模式（Suggestion Mode）
持续 1 周，skill 评论升级为黄色，标题[Skill Suggestion]，并提供一键修复按钮。比如performance-safety发现未节流的useEffect，按钮会自动插入useDebounce的 import 和调用代码。这个阶段，73% 的建议被开发者主动采纳，因为他们看到“修复只需 1 秒”。

阶段三：守门模式（Gatekeeper Mode）
正式启用，skill 作为 CI 的必要检查项。但关键设计是：每个 skill 都有豁免开关。比如security-scan的高危告警，Reviewer 可以在评论区输入/pr skill security-scan ignore --reason "test-only key in mock file"，系统会记录豁免原因并存档。这避免了“一刀切”引发的抵触，也让豁免行为本身成为可追溯的决策。

4.2 Skill 的版本管理与灰度发布

Skill 不是静态的，它需要迭代。我们的做法是：

• 每个 skill 用 Git Tag 版本（如v1.2.0），skill-manifest.json中的version字段必须严格匹配。
• 新版本 skill 部署后，先在dev环境的 PR 上灰度 24 小时，只对 5% 的 PR 启用。
• 灰度期间，监控两个指标：① skill 响应时间（P95 < 200ms）；② 告警准确率（人工抽检 50 条，误报率 < 5%）。
• 通过灰度后，才全量发布。我们曾因auth-contractskill 的 v1.3.0 版本在灰度期出现 12% 误报（误判了@AuthOptional注解），果断回滚，避免了大规模干扰。

4.3 构建内部 Skill MarketPlace

我们用一个简单的 Next.js 页面搭建了内部 Skill MarketPlace，页面结构如下：

每个 skill 卡片都有“试用”按钮，点击后弹出模拟 PR 界面，输入一段 diff 就能实时看到 skill 输出。这个 MarketPlace 让 skill 开发者获得可见性，也让使用者能直观比较不同 skill 的质量。最有趣的是，i18n-checkskill 的作者是实习生，他发现团队常忘记给新文案加国际化 key，于是用 3 天写了这个 skill，现在它已成为 PR 的标配检查项。

提示：技能生态的健康度，不取决于 skill 数量，而取决于“最小可行 skill”的数量。我们规定，任何新 skill 必须满足：① 代码行数 < 200；② 单次执行耗时 < 100ms；③ 误报率 < 5%。这逼着开发者聚焦真正痛的点，而不是堆砌功能。

5.skill的边界在哪里？哪些事它永远做不了

Matt 在直播结尾抛出了一个尖锐问题：“如果/pr skill能做一切，那还要工程师干什么？” 这不是谦虚，而是清醒的认知。我在实践中总结出/pr skill的三大不可逾越边界，也是工程师不可替代的价值锚点：

5.1 边界一：无法替代“权衡决策”的上下文判断

/pr skill可以检测到“这个函数用了setTimeout而非requestIdleCallback”，但它无法判断“为什么在这里用setTimeout”。上周，后端同学提交了一个 PR，security-scan报告高危：const jwtSecret = process.env.JWT_SECRET || 'dev-secret';。按规则，这绝对是硬编码密钥。但实际背景是：这是一个本地开发环境的 demo 项目，所有环境变量都由 Docker Compose 注入，process.env.JWT_SECRET在 CI 中必然存在，|| 'dev-secret'只为方便本地调试。/pr skill无法理解“Docker Compose 环境变量注入”这个部署上下文，它只能按字面规则报警。这时，需要 Reviewer 基于架构文档、部署流程、团队约定，做出“此处豁免合理”的判断。Skill 提供事实，人提供语境。

5.2 边界二：无法生成“创造性解决方案”

/pr skill可以指出“这个组件渲染 1000 条数据卡顿”，但它不会建议“用虚拟滚动替代全量渲染”。它能检测到useMemo的 deps 数组缺失items.length，但不会设计出useVirtualizedList这样的新 Hook。创造性解决方案来自对业务本质的理解、对技术边界的探索、对用户痛点的共情——这些是 LLM 无法模拟的。我们团队有个performance-safetyskill，它只做一件事：当检测到map渲染超过 500 项时，提示“考虑虚拟滚动”。但它不提供虚拟滚动实现，因为实现方式取决于框架（React/Vue/Svelte）、数据结构（数组/Map）、交互需求（滚动加载/固定高度）。这个 gap，必须由工程师填补。

5.3 边界三：无法建立“信任契约”的长期关系

最深刻的体会来自一次事故。auth-contractskill 报告一个 PR 违反了“所有 API 调用必须携带X-Request-ID头”，我们按流程驳回。但后来发现，这个 PR 修改的是一个遗留的 Python 微服务，它根本不走我们的 Node.js 网关，自然没有X-Request-ID。/pr skill的规则是基于主干架构制定的，但它不知道这个微服务已脱离主干治理多年。修复这个问题，不是更新 skill 规则，而是推动团队重新梳理服务治理边界，召开跨团队对齐会议，制定遗留系统迁移路线图。这种需要建立信任、协调利益、推动变革的工作，是 skill 永远无法替代的。

所以，/pr skill的终极价值，不是让工程师失业，而是把工程师从“重复性模式识别”的体力劳动中解放出来，让他们回归到最核心的使命：做决定、创方案、建信任。Matt 的直播没有展示炫酷的 AI 效果，而是反复强调：“Skill 是你的新同事，不是你的替代者。它帮你过滤噪音，让你听见信号。”

我在实际使用中发现，最高效的团队不是 skill 用得最多的，而是 Reviewer 最懂得何时关闭 skill、何时手动介入的。比如我们有个accessibilityskill，它会检查<img>是否有alt属性。但当设计师提交 PR，新增了一张纯装饰性 SVG，skill 会报错。这时，资深前端会直接回复：“此 SVG 为装饰性元素，已添加aria-hidden="true"，请忽略此 skill 告警。”——这个动作本身，就是 skill 无法复制的专业判断。