从技术雷达到上线审计：给开发的15个Skill

AI 能写代码之后，工程效率并没有自动变好。代码生成得越快，需求理解错误、上下文丢失、Review 堆积、依赖漏洞和部署事故反而可能出现得更快。真正决定 AI 编程能否进入生产环境的，是整个过程能否被约束、验证、回滚和审计。

我把这 15 个开发类 Skill 按工程流程重新排了一遍：

信息雷达 → 任务定义 → 多智能体执行 → GitHub 协作 → 质量检查 → 部署与安全

一、信息雷达：技术资讯不是越多越好

Arxiv 论文速递：适合研究驱动型团队

每日抓取 Arxiv 新论文，整理核心贡献、方法创新、实验结果和实用价值。帮开发者完成第一轮筛选。短板：摘要只能回答"值不值得读"，不能替代阅读原文。方向过宽时日报容易变成噪声。

GitHub 趋势日报：发现项目，不等于选定依赖

自动抓取 GitHub Trending 并按技术栈分类提炼项目价值。不要把"Trending"直接当技术选型依据，License、维护频率和升级成本仍需单独检查。

选择建议： 做算法前沿跟踪 → Arxiv；做工程生态跟踪 → GitHub Trending。普通业务团队不必两者都装。

二、多智能体工程：三个 Skill 不是同一层工具

Sprint Contract：先定义验收，再让多个 Agent 开工

约束多智能体开发并加入独立 QA 评价。适合功能开发、复杂 Bug 修复和跨模块任务。关键价值不是"多叫几个 Agent"，而是把目标、边界、交付物和验收标准写进合同。

Network AI：需要共享状态的多智能体工程

通过共享黑板、权限门控、Token 预算和持久化项目上下文组织多个 Agent。适合长周期、跨角色项目。优点是协作结构完整，代价是部署、调试和状态维护成本更高。

任务调度官：轻量任务拆解和执行协调

负责生成任务清单、拆解复杂任务并匹配执行 Agent。适合"我知道目标，但不知道如何拆"的场景。比 Network AI 更轻，但验收和质量隔离约束更弱。

三者怎么选： 先拆任务 → 任务调度官；多 Agent 开发且必须验收 → Sprint Contract；长期多智能体系统 → Network AI。

三、GitHub 协作：代码完成只是流程开始

GitHub 命令行工具：基础设施 Skill

基于 gh CLI 管理 Issue、PR、CI 和高级查询。整套工具链最该先装的一项——提供稳定、结构化、可审计的操作入口。注意创建 PR、合并代码、关闭 Issue 都会改变外部状态，必须设置授权和确认边界。

GitHub Issue 自动修复：适合结构清晰、可复现的问题

覆盖 Issue 分析、根因定位、代码修复和 PR 描述起草，支持批量处理。

适合：有明确复现步骤的 Bug、失败测试已定位模块、仓库结构规范。不适合模糊需求、安全敏感改动和架构重构。批量修复要限制目录、文件类型和可执行命令，防止错误规模化。

容器化部署：完整 Docker 运维链路

覆盖容器、镜像、Compose、网络、卷、调试和生产加固。适合从"本机可跑"推进到"环境可复现"。容器命令可能涉及停止服务、删除卷和覆盖配置，生产环境必须区分只读诊断与变更操作。

Obsidian：给工程知识留下长期记忆

操作纯 Markdown 知识库并自动整理。承接 ADR、故障复盘、调试笔记和项目上下文。长周期项目中，这些知识资产比一次对话中的代码更有复用价值。

四、代码质量：按风险分层

React 代码质检：前端专项门卫

面向 React/TypeScript 项目，覆盖格式、ESLint、类型安全和 Hooks 规范。适合放在提交前或 CI 阶段处理高频、规则明确的问题。不能替代业务逻辑测试和性能检查。

Spec 驱动开发：先让需求变成工程契约

覆盖需求、架构、流程设计、计划、编码、测试、修复、Review 和发布，设置阶段门控。特别适合 Vibe Coding：代码生成速度不是瓶颈时，先写规格能减少"边写边猜"。流程较重，一次性脚本或探索性原型不必完整走完。

Dockerfile Optimizer：构建资产，不是部署全流程

聚焦层数、镜像体积和构建速度优化。与"容器化部署"不重复——一个负责运行链路，一个专注构建产物。

优化后须重新验证启动命令、运行用户、系统依赖和多架构兼容性。

五、安全合规：上线前至少三道检查

依赖漏洞监控：检查供应链已知风险

扫描依赖包已知 CVE，按 CVSS 分级并给出升级建议。适合定时运行。发现漏洞 ≠ 可以盲目升级，修复版本可能带来破坏性变更，需结合可利用性和暴露面判断。

代码安全审查：检查代码自身风险

面向硬编码密钥、访问控制、注入和不安全数据处理。比依赖扫描更接近业务代码，但静态判断可能产生误报，高风险系统仍需人工评审和动态测试。

数据隐私合规清单：治理层的合规检查

覆盖治理、同意、安全、违规响应、供应商和跨境等领域。适合涉及用户数据、企业客户和跨境业务的系统。不能替代法律意见，但能提前暴露"技术上能做、合规上未必能上线"的问题。

建议组合

多数开发团队可从六件套开始：

1. GitHub 命令行工具 — 基础协作入口
2. Spec 驱动开发 — 约束需求到发布
3. GitHub Issue 自动修复 — 承接明确 Bug
4. React 代码质检（或技术栈匹配的质检）
5. 依赖漏洞监控 — 持续发现风险
6. 代码安全审查 — 补充代码层检查

复杂项目再增加 Sprint Contract 或 Network AI。

结论速查