build-validator

构建验证器

概述

在执行前验证计划、设计和实现，以避免代价高昂的错误。 此技能可作为所有领域的质量关卡，包括基础设施、数据架构、机器学习模型、 收入核算、客户运营、文档和 AI 系统。给出明确的继续／不继续决策 以及具体的整改步骤，而不是含糊的反馈。

功能

• 架构审查：模式验证、反模式检测、依赖关系分析
• 安全审计：威胁建模、访问控制审查、数据保护评估
• 可扩展性评估：负载测试计划、瓶颈识别、容量规划
• 成本分析：总体拥有成本（TCO）估算、浪费识别、优化建议
• 合规检查：法规要求对齐、审计准备情况、文档完整性
• 风险识别：单点故障、供应商锁定、技术债务、运营缺口

用法

1. 提交要验证的计划、设计或实现
2. 指明领域（基础设施、数据、机器学习、收入、客户运营、文档、AI）
3. 运行下方相应的验证工作流
4. 获取明确的继续／不继续决策以及具体的整改步骤

示例

• 用户：“审查这个数据湖仓架构” Agent：运行架构审查工作流，检查分区策略、治理模型和成本估算，找出 3 个反模式，并给出继续／不继续决策及修复方案

• 用户：“这个机器学习模型已准备好投入生产了吗？” Agent：运行机器学习验证工作流，检查训练数据质量、模型监控计划、漂移检测和回滚策略，并生成准备情况评分卡

• 用户：“检查这个收入确认设置” Agent：运行合规检查工作流，验证 ASC 606 五步模型、合同分析完整性和审计跟踪，并生成合规报告

适用场景

• 在确定重大架构决策或技术选型前
• 在部署到生产环境前（基础设施、数据管道、机器学习模型）
• 在签署供应商合同或做出长期承诺前
• 在推出面向客户的功能或创收产品前
• 不确定设计是否已达到生产就绪状态或是否存在隐藏风险时

不适用场景

• 日常编码决策或小型重构 → 使用代码审查工具
• 快速原型开发或概念验证工作 → 快速迭代，之后再验证
• 没有生产或合规要求的个人项目 → 自行判断
• 需要持证专业人士解读的法律或法规问题 → 咨询法律顾问

核心工作流

1. 架构审查

验证清单：

1. 模式验证

   • 该架构是否遵循此领域的成熟模式？
   • 是否存在反模式（紧密耦合、单点故障、过度设计）？
   • 技术选型是否基于需求，而非潮流？

2. 依赖关系分析

   • 关键依赖项有哪些？如果它们失效会怎样？
   • 是否存在供应商锁定风险？退出策略是什么？
   • 是否有明确的升级／迁移路径？

3. 可扩展性检查

   • 系统在当前负载的 10 倍时表现如何？
   • 瓶颈在哪里？如何缓解？
   • 是否有容量规划流程？

4. 安全审查

   • 身份验证和授权是否经过妥善设计？
   • 静态数据和传输中的数据是否均已加密？
   • 是否有审计日志和监控？

**决策输出：**继续／有条件继续（需修复）／不继续（附原因）

2. 安全审计

威胁建模工作流：

1. 识别资产：哪些数据、系统或流程需要保护？
2. 绘制信任边界：数据会在哪里跨越安全边界？
3. 枚举威胁：STRIDE 分析（欺骗、篡改、抵赖、信息泄露、拒绝服务、权限提升）
4. 评估风险：针对每项威胁评估可能性 × 影响
5. 制定缓解措施：技术控制、流程控制、监控

常见发现：

• 缺少输入验证 → 存在注入风险
• 硬编码密钥 → 凭据暴露
• IAM 权限过于宽松 → 权限提升
• 缺少审计跟踪 → 不符合合规要求
• 缺少速率限制 → 滥用／拒绝服务

3. 成本分析

TCO 估算框架：

成本类别	第 1 年	第 2 年	第 3 年	备注
基础设施				计算、存储、网络
软件许可				按席位、按用量、企业版
人员				全职员工、承包商、培训
运营				监控、支持、事件响应
合规				审计、认证、法律事务
总计

优化检查：

• 是否存在过度配置的资源？
• 是否适用预留实例或承诺用量折扣？
• 是否有能力相当但成本更低的替代方案？
• 不构建此项目的成本是什么？

4. 合规检查

法规符合性评估：

1. 确定适用法规：GDPR、CCPA、SOC 2、HIPAA、PCI-DSS、ASC 606 等。
2. 将要求映射到控制措施：哪些技术／流程控制措施可满足各项要求？
3. 差距分析：缺少哪些内容？哪些内容仅部分实施？
4. 审计准备情况：你们今天能向审计员证明符合要求吗？

文档清单：

• 包含数据流的架构图
• 访问控制策略和用户列表
• 数据保留和删除流程
• 事件响应计划
• 业务连续性和灾难恢复计划
• 供应商风险评估
• 员工培训记录

5. 风险识别

风险登记表模板：

风险	可能性	影响	缓解措施	负责人	状态
	高／中／低	高／中／低			开放／已缓解／已接受

常见风险类别：

• 技术：单点故障、未经测试的依赖项、技术债务
• 运营：无值班覆盖、缺少运行手册、流程未记录
• 业务：供应商锁定、法规变化、市场变动
• 人员：人员冗余度、技能差距、人员流失风险

6. 是否继续决策框架

评分矩阵：

标准	权重	得分（1-5）	加权得分
架构合理性	20%
安全态势	20%
可扩展性准备情况	15%
成本效益	15%
合规符合性	15%
运营准备情况	15%
总计	100%

决策阈值：

• 4.0 及以上：继续 — 有把握地推进
• 3.0-3.9：有条件继续 — 解决特定问题后再推进
• 低于 3.0：不继续 — 存在重大风险，需要重新设计

输出格式：

## Build Validation Report

**Overall Score:** X.X / 5.0
**Decision:** Go / Conditional Go / No Go

### Findings
1. [Finding] — [Severity] — [Remediation]
2. ...

### Risks
1. [Risk] — [Likelihood/Impact] — [Mitigation]
2. ...

### Next Steps
1. [Action item] — [Owner] — [Deadline]
2. ...