Vibecoding进阶教程-从能用到可控（三）：安全、评测与流水线

VibelearningAI
79 阅读11分钟

Vibecoding进阶教程-从能用到可控（三）：安全、评测与流水线

本篇是 Vibecoding 系列教程第二部分进阶篇的第三篇，也是第二部分的最后一篇。 感谢佬友们一直以来的支持，后面我也会继续产出一些 vibecoding 相关的教程和工具推荐。

写在前面

到这里，我们已经跑通了 MCP 工具链和 Skills 卡片，也了解了多智能体分权和长任务治理机制。本篇是系列的收尾，解决最后三个问题：

  • 任务 1：安全加固
  • 任务 2：评测与可观测
  • 任务 3：团队协作与流水线

末尾附录包含一些模板参考和延伸资料。

任务 1：安全加固——第三方 MCP 不只是普通插件，更代表着权限

目标：建立一套接入前的安全审查习惯。不管是用别人的 MCP server 还是自己开发，都要先排查一下隐患。

你把第三方 MCP 接到你的开发环境里，本质上就是给了一个外部程序跟你一样的系统权限。它能碰到的网络、文件系统，基本等于你能碰到的，这是很夸张的。

1.1 接入前需要考虑的 7 个问题

  1. 读写边界：它到底需要读什么，需不需要写权限。
  2. 权限范围：默认权限是不是给太大了，能不能把权限缩到最小目录。
  3. 网络行为：它在工作时会访问哪些网络，请求会发到哪些域名。
  4. 敏感距离：它离你的环境变量、数据库凭据留有多少距离。
  5. 审计日志：它跑的时候，有没有留下可追溯的日志。
  6. 重试风险：超时或报错后的重试，会不会产生副作用。
  7. 供应链：作者靠谱吗，是长期维护的项目还是可能有后门随时有跑路风险的项目。

1.2 给已接入的 MCP 做一次安全审查

可以拿出我们之前做好的 MCP 出来，也可以拿一个比较常用的 MCP 来进行一次审查。

MCP 审查表
Server 名称：

1. 读写边界：只读/读写
2. 权限范围：已限制到子目录/全盘访问
3. 网络行为：网络请求流向
4. 敏感距离：无法访问 .env/数据库/可访问
5. 审计日志：有日志/无
6. 重试风险：操作幂等/有副作用风险
7. 供应链：官方/知名维护者/个人项目

1.3 需要确认的底线

  • 最小权限：只给特定子目录的访问，只开必要的端口。
  • 写入限制：如果必须能写文件，至少限制在 src 或 tmp 下，避免碰到配置文件。
  • 可追溯：最起码你得能看到它调了什么、改了哪几行。
  • 重试克制：别让重试变成死循环。

1.4 用 HTTP MCP 时的安全注意事项

大部分人用的是本地 STDIO 模式（就是在 config 里配 command + args 那种），这种模式 MCP 跑在你自己机器上，安全风险相对可控。

但如果你用的是 HTTP 模式（MCP Server 在远程通过网络调用），那安全要求就会变高，这里说几个推荐大家注意的点：

  • 认证：必须用 OAuth 做身份验证，裸跑的 HTTP MCP 等于把开发环境暴露在公网上。
  • Token：API Token 只能放在请求的 Header 里（Authorization: Bearer xxx），不要拼在 URL 后面，URL 会被日志和浏览器历史记录泄露。
  • 回调：OAuth 回调只允许 localhost 或 https:// 开头的地址，防止 Token 被中间人截获。

延伸阅读：

如果你要把 HTTP MCP 或第三方组件接入长期开发流程，建议看看这几份安全指南。

任务 2：评测与可观测——不再凭直觉对项目进行迭代

这部分主要为了回答一个问题："改了工作流换了模型之后，效果到底是真的变好了，还是运气呢？"

没有认真的评测量化，日常开发最容易陷入这种情况：

  • 今天一切顺利："天才程序员诞生了"
  • 明天觉得模型降智："天才程序员陨落"

其实多半是上下文膨胀了、工具链卡了、或者纯粹运气不好。我们需要一些量化后的证据来看看到底是为什么。

2.1 自己做一套回归测试集

跑和自己业务项目关系不大的 Benchmark 意义不大，有时间的话自己搭一套质检题库是个不错的选择：

  • 3 个有代表性的 Bugfix
  • 3 次 Feature 增量
  • 2 次重构
  • 2 次补核心链路测试

每道题需要写清楚的是：

  • 输入：原始任务描述。
  • 预期：通过条件。
  • 验证：验证命令。

存成 JSONL，方便即拿即用（附录 A 有最小 Schema）

2.2 先用最朴实无华的方式做 Tracing

用 JSONL 把每次操作录下来：

  • trace_id（任务标识）
  • 操作时间
  • 调用的 Tool 名
  • 输入摘要（注意脱敏，去掉 API Key、密码等）
  • 输出摘要
  • 耗时
  • 报错信息

有了这种记录表，才方便在问题出现的时候，快速定位问题到底在哪。

建议： 每条日志一定要带 trace_id。一旦多个 Agent 并行跑或者长任务反复重试，没有 trace_id 的日志直接就乱套了，根本分不清上下游。

2.3 往标准化靠拢

如果打算把这套推给团队用，建议字段命名向 OpenTelemetry (OTel) 的 GenAI semconv 标准看齐。哪怕现在没接 OTel 的全套体系也可以先统一命名，以后迁移成本就会降低很多。

参考：OpenTelemetry GenAI Semantic Conventions — opentelemetry.io/docs/specs/…

2.4 进阶：从日志到可视化看板

纯看 JSONL 几十次调用确实难受。可以考虑加一层可视化：

  1. 底层还是存 JSONL（这是保底的原始日志）。
  2. 上面接一个可视化平台（Langfuse / Phoenix / LangSmith……）。
  3. 需要注意的有 4 个关键指标：
    • 各类任务的通过率
    • 单次 Bug 修复的端到端耗时
    • 每个环节的 Token 消耗
    • 失败时卡在哪一环

之后就可以比较方便地拉出某次失败任务的完整链路了。 改完prompt后也可以用数据来对比前后的通过率和耗时差异。

延伸阅读：

想深入了解评测和追踪的实践：

任务 3：管理超大仓库与流水线

第一次让两个 Agent 同时去修同一个文件的人，通常会收获一份完美的合并冲突。

本节适用于有 CI/CD 环境、多人协作的团队项目。如果你目前是单人本地开发，可以直接跳过。

3.1 沙盒（Sandbox）

有一个现实是必须接受的：幻觉导致的抽风瞎写发散是不可能完全消除的。所以我们能做的就是考虑怎么降低在幻觉出现时可能造成的负面影响。

做法：

  • 所有试运行、构建、测试都扔到无状态容器或临时沙盒里跑。
  • 只有测试全部通过之后，才允许把 diff 补丁合回主干。
  • 高危操作（删包、重建根目录、大规模推改）要求 coding agent 申请人工审批。

3.2 固定流水线中的关卡

这里面举三个例子：

  1. 静态检查：lint + 类型检查，语法级别的低级错误直接拦掉。
  2. 业务逻辑：跑一遍本次改动涉及的单测或集成测试，确认功能没被改坏。
  3. 安全扫描：有没有硬编码密钥、有没有引入高危依赖，发现了就打断。

如果有关卡没过就退回重来。

对修复主导权本篇也给出两套参考方案：

  • 让 CI job 本身带修复能力，跑挂了直接读 stderr 开始纠错循环，修好了打一个 patch commit。
  • CI 只负责跑测试和报告结果，出了问题通过 Webhook 把错误现场发给远端的 Agent 服务，Agent 打好补丁后 Push 分支等人来审。

3.3 多 Agent 并发时的保护机制

如果你有多个 Agent 同时干活需要注意这两个问题：

  • 同一时刻只允许一个 Builder 有写权限，其他角色（Scout / Verifier）在同一时刻只读。
  • 写入前必须同步最新的上游状态，避免两个 Agent 各写各的然后互相覆盖。

常见的实现方式：

  • 文件锁：在写入和跑测试的入口用 flock 之类的工具加锁，另一个 Agent 过来发现被占了就直接排队或报错。
  • Git 保护：每次写入前强制 git pull --rebase，有冲突就中断当前轮次。

如果你用的是 Codex 的 worktree 模式，它已经帮你做了隔离，每个 Agent 在独立的 worktree 里工作，基本不会冲突。这节主要是给自己搭框架的团队看的。

延伸阅读：

附录 A：模版案例参考

A.1 项目规则模板（放在根目录的 AGENTS.md）

## How to run
- Install：
- Test：
- Build：

## Collaboration rules（协同规矩）
- 动手前先给我 3-7 步计划，标注每一步怎么验证。
- 改完必须贴 diff，不要只给总结。
- 收工前自觉跑 lint、test、build。跑不了的说明原因。
- 任何情况都不许泄露 secrets（.env、key、token、credentials）。
- 最小化改动，不要为了美观重构大片代码。

## Stop conditions（什么时候必须停手）
- 要引入新依赖或做大版本升级。
- 改动超过 5 个文件。
- 连续 2 次排错失败找不到原因。

A.2 需求描述模板

## Context（背景）
（说明：仓库定位 / 相关模块 / 限制条件）

## Goal（目标）
（一句话说清你想要什么效果）

## Acceptance criteria（验收标准）
- （使用什么命令可以校验结果）

## Constraints（约束）
- 不泄露 secrets
- 最小化改动

## Delivery（必须交付）
1) 计划
2) 代码改动
3) 关键 diff
4) 验证通过的输出

A.3 MCP Server 开发 checklist（STDIO 模式）

  • 绝不往 stdout 写日志（调试信息走 stderr）。
  • 先在本地跑通，再对接远端或外部 API。
  • 每个 tool 都要定义清楚：入参类型（schema）、返回结构、错误处理、超时限制。
  • 明确读写范围：它能触及的目录有哪些，是否有被限制在子目录中。
  • 写操作尽量做到多次调用不产生副作用。

A.4 HTTP MCP 的授权 checklist

  • 通讯走 HTTPS
  • redirect URI 严格校验
  • Token 走 Authorization header（不放 query string）
  • 配置 PKCE
  • 按标准走 metadata discovery（.well-known/oauth-authorization-server）

A.5 多智能体角色模板

见前一篇

Vibecoding进阶教程-从能用到可控（二）：拒绝coding agent既当裁判又当运动员

A.6 评测回归库的 JSONL 模板

记录好输入和验收标准，每次升级后全部重跑。

{"id":"bugfix-001","title":"修复计算模块的单测崩溃","input":"...","acceptance":["npm test 全部通过"],"verify":["npm test"],"tags":["bugfix","tests"]}

A.7 Tracing 的 JSONL 模板

每条带时间戳、耗时和 trace_id，事后排查不用瞎猜。

{"trace_id":"bugfix-123-run-1","ts":"2026-03-03T10:00:00Z","tool":"bash","input_summary":"npm test","output_summary":"passed","duration_ms":12345,"error":null}

附录 B：延伸阅读与官方参考资料

MCP 协议与 Server 开发：

MCP 生态与官方参考：

HTTP MCP 的 OAuth 授权（看情况选读）：

MCP 生产环境安全指南：

Skills 与规则标准：

多智能体协作：

长任务管理：

评测与可观测：

跨平台协议与前沿实践：

avatar
文章
阅读
粉丝