跳到主要内容

第 8 部分：建立团队标准

前七部分的所有内容对一个开发者都有效。一旦涉及团队，一个额外的失败模式就会出现：工作套件（harness）漂移。一个人的规则文件说一件事，另一个人的说另一件事，智能体行为在团队中无法复现，规范悄悄侵蚀。本部分讲的是如何将这套工作流变成一个共享的、持久的标准。

需要牢记的底层原则：AI 放大了它所落地的工程文化。 一个有着完善测试、清晰标准和健康审查文化的团队，能从这些工具中获得巨大收益。一个没有这些的团队，只是在更快地制造问题。标准化的目的，就是让优秀文化成为阻力最小的路径。

把工作套件当作代码来对待​

规则文件、系统提示词、评估套件和技能库不是个人配置——它们是共享基础设施。像对待代码一样对待它们：

  • 随项目进行版本管理。
  • 像对待任何其他改动一样，在 Pull Request 中审查。
  • 指定命名负责人，让它们被有意地维护，而不是悄然腐化。

没有这些，每个开发者的智能体行为略有不同，没有人能复现别人的结果。

以评估而非 Demo 作为门禁​

一个能运行的 Demo 证明智能体能成功一次。一个通过的评估套件证明它能可靠地成功。两者不是一回事，凭借 Demo 的表现来发布，是不可靠的智能体进入生产的方式。

把评估覆盖作为发布的前提条件，就像你以测试覆盖率来把控一个服务一样。但没有明确评分标准的评估什么都衡量不了——所以要定义你在评分什么：

  • 任务成功率
  • 工具使用质量
  • 轨迹合规性
  • 幻觉率
  • 响应质量

一个 CI 门禁让这变成现实：

# ci: block merge if the agent's eval suite regresses
agent-evals:
  run: eval-suite --rubric rubric.yaml --min-score 0.9
  on: [pull_request]
  required: true

为生成代码重塑代码审查​

生成的代码需要和人类代码同等甚至更严格的审查——审查者需要了解它特有的失败模式。培训他们识别幻觉依赖、薄弱的错误处理，以及乍看无误但实则有误的正确性缺口（第 5 部分）。根据这些模式调整审查清单，而不是照搬旧的人类代码审查清单不加改动。

明确划定原型与生产的边界​

快速、松散的探索和严谨、规范的生产工作都是合理的——但前提是每个人都知道当前处于哪种模式。明确划定这条边界：

  • 哪些代码库是生产环境 vs. 沙盒。
  • 哪些分支需要执行完整的规范。
  • 智能体的输出能够触达哪些环境。

团队若对此模糊不清，就会产出意外上线的原型。一条书面边界能让探索保持快速，同时让生产保持安全。

一次性构建工作套件，持续打磨完善​

可复用的提示词、技能库、工具连接和评估套件，能在多个项目中产生复利。从 AI 开发中获益最多的团队，是那些一次性构建好这套共享的工作套件并持续改进的团队，而不是每个人各自从头重建。把它当作基础设施：有文档、有人维护、被有意识地改进。

招聘与晋升时注重判断力​

随着实现工作变得越来越廉价，瓶颈转移到了规格说明能力、评估能力和架构判断力。未来几年最有价值的工程师，是那些能够很好地指挥智能体的人——而不是那些能敲最多代码的人。在招聘、定级和人才培养上反映这一点：重视规格说明能力、评估严谨性和系统设计能力，而不仅仅是原始的实现速度。

最强的设置是有意为之的混合模式：人类设定方向，智能体来实现，清晰的交接协议管控边界。代码审查、值班和团队结构都会演进，将智能体作为参与者而非单纯的工具来对待。

搭建你自己的工作流​

  • 将规则文件、提示词、评估套件和技能移入代码库；要求对改动进行 PR 审查。
  • 为共享工作套件指定一名负责人。
  • 添加一个 CI 门禁，当评估套件低于阈值时阻止合并。
  • 为生成代码的失败模式编写一页审查指南。
  • 记录原型与生产的边界：代码库、分支、环境。
  • 在下次招聘中，增加一个规格说明与评估练习，而不仅仅是编码测试。

来源：The New SDLC With Vibe Coding（Google）— https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding

编辑此页
最后由 Oleksandr Derechei 于 更新