## 1. 事件背景：Claude Code 进入半导体研发流水线

据近期业界披露，三星电子系统 LSI 事业部在客户定制芯片（Custom SoC）的功能验证与环境搭建环节中，引入了 Anthropic 的 Claude Code，把原本需要约 1 个月才能完成的验证准备与执行工作，压缩到了 2 天左右。

这件事之所以值得关注，不是「大模型又写了一段代码」，而是它第一次在半导体研发的验证流水线里，实现了 Agent 的规模化提效。更关键的一点是：**AI 拿到了执行权，却没有拿到判定权**——Claude Code 可以生成环境、跑用例、读日志、改脚本，但验收标准（Acceptance Criteria）的定义和修改权始终留在工程师手里，Agent 不能自己给自己「放水」。

这种「执行权下放、判定权上收」的设计，是研发领域让 Agent 大规模落地时最难、也最重要的一环。下面从工程实现的角度拆解这套思路。

## 2. 传统 SoC 验证为什么慢

客户定制 SoC 的验证，慢通常不在「跑仿真」本身，而在每一轮迭代之间的手工衔接：

- **环境搭建**：每个新项目都要重新整理 filelist、Makefile、UVM 环境骨架、编译选项、波形保存策略，重复劳动多。
- **用例开发**：根据验证计划（Test Plan）手写 Sequence、Test Case、Scoreboard、Coverage 配置，周期长。
- **回归与缺陷收敛**：跑完回归后要人工翻日志、判断哪些失败是真实缺陷、哪些是环境问题，再返工。
- **验收判定**：到底「过还是不过」依赖人的经验和文档，判定口径不一致时反复扯皮。

如果只是把「写代码」这一小段交给 AI，整体周期并不会显著缩短——因为瓶颈分布在整条链路。三星这次的做法，是把 Claude Code 当作一个能操作工具、读文件、执行命令、分析日志的 Agent 放进流水线，让它承担跨度更大的端到端任务。

## 3. 核心：给执行权，不给判定权

很多团队不敢在严肃研发流程里用 Agent，最大顾虑是「AI 会不会为了让结果好看，偷偷放宽标准」。这个问题在工程上可以结构化地解决：

| 权限 | 谁拥有 | 具体表现 |
| --- | --- | --- |
| 执行权 | Claude Code Agent | 生成环境脚本、写/改验证代码、执行仿真、读日志、提修复建议 |
| 判定权 | 人类工程师 | 定义验收标准、Sign-off 缺陷、决定是否放行投片 |
| 修改权 | 人类工程师 + 系统约束 | 验收标准文件只读，Agent 改动会被校验并回滚 |

也就是说，Agent 可以做的事很多，但它的产出最终都要经过「标准没有被动过」这一道硬校验。标准文件人类一手维护，Agent 若尝试改写，流水线直接阻断。

## 4. 核心技术实现

下面给出一套可落地的最小实现思路：用 Claude Code 的无头模式（`claude -p`）封装一个验证 Agent，配合一个「规则只读」守护逻辑。

### 4.1 受限调用封装

Agent 运行在隔离沙箱内，只允许使用白名单工具，避免它越权修改判定文件：

```python
#!/usr/bin/env python3
"""SoC 验证 Agent：基于 Claude Code 的受限调用封装。"""
from __future__ import annotations

import subprocess
from pathlib import Path

WORKSPACE = Path("/workspace/soc_verify")
RULES_PATH = WORKSPACE / "rules" / "acceptance_criteria.json"


def run_claude(prompt: str, allowed_tools: list[str]) -> str:
    """以受限工具集调用 Claude Code，返回最终文本输出。"""
    cmd = [
        "claude", "-p", prompt,
        "--allowedTools", ",".join(allowed_tools),
        "--dangerously-skip-permissions",
        "--output-format", "json",
    ]
    proc = subprocess.run(
        cmd,
        cwd=WORKSPACE,
        capture_output=True,
        text=True,
        timeout=1800,
    )
    if proc.returncode != 0:
        raise RuntimeError(f"agent failed: {proc.stderr}")
    return proc.stdout
```

`--allowedTools` 限制了 Agent 能调用哪些工具，`--dangerously-skip-permissions` 仅用于隔离沙箱环境，生产环境建议用交互式授权或细粒度权限配置替代。

### 4.2 验收标准只读守护

判定标准是唯一不能被 Agent 触碰的数据。每次流水线运行前后都对标准文件做哈希校验：

```python
import json
import hashlib


def load_rules() -> dict:
    return json.loads(RULES_PATH.read_text(encoding="utf-8"))


def rules_fingerprint(rules: dict) -> str:
    canonical = json.dumps(rules, sort_keys=True, ensure_ascii=False)
    return hashlib.sha256(canonical.encode("utf-8")).hexdigest()


def ensure_rules_intact(before_hash: str) -> None:
    after_hash = rules_fingerprint(load_rules())
    if before_hash != after_hash:
        raise SystemExit(
            "验收标准被 Agent 修改，已阻断流水线并回滚。\n"
            f"before={before_hash}\n after={after_hash}"
        )
```

这个 `ensure_rules_intact` 就是「AI 不自改判定标准」的工程兜底：Agent 即使产生了越权行为，也会在收尾阶段被拦截。

### 4.3 验证闭环主流程



下面是完整验证闭环，各阶段的 Agent 权限与产出物标注在节点中：

![image.png](https://developer.qcloudimg.com/http-save/yehe-1750537/5e6e41d7bf31a9f3ddda9d4df6da49fd.png)
![image.png](https://developer.qcloudimg.com/http-save/yehe-1750537/d6ffe3d5ec050e0a57c0c1cd85b4a9d0.png)
![image.png](https://developer.qcloudimg.com/http-save/yehe-1750537/ad5af2ba352eb0859238dcda54df1a30.png)

图示中的两个决策分支，本质上是 `ensure_rules_intact(before_hash)` 这把「规则只读守护锁」在收尾阶段做的最后一道门槛判断：

- **「标准未变」分支（LOG：`RULES_OK`）**：系统重新计算 `rules/acceptance_criteria.json` 的 SHA-256，与 Agent 执行前记录的 `before_hash` 比对一致，说明验收标准在整轮验证中未被改写。此时 `verify_flow` 正常返回报告，系统写入 `RULES_OK job_id=... hash=... timestamp=...` 事件，并把「缺陷证据链 + 通过/不通过结论」推送进人工 Sign-off 队列，由人类工程师做最终判定。

- **「标准被篡改」分支（LOG：`RULES_TAMPERED`）**：哈希比对不一致，说明 Agent 曾尝试改写验收标准或标准文件被污染。`ensure_rules_intact` 随即抛出 `SystemExit`，流水线状态置为 `BLOCKED`，本阶段 Agent 可写产物全部回滚；日志中同时输出 `before` 与 `after` 两个哈希值，并触发告警通知人类工程师介入审计。

因此，`D` 节点不是一个由 Agent 自行回答的判断题，而是独立守护进程不可绕过的哈希校验；`E` 节点的 Sign-off 权限也始终只在人类工程师一侧，Agent 只负责交付可溯源的证据链。

把环境搭建、用例回归、日志分析串成一个 Agent 任务链。三个阶段都交给 Claude Code，但每个阶段只开放对应工具权限：

```python
def verify_flow(design_name: str, test_plan: str) -> dict:
    rules = load_rules()
    before_hash = rules_fingerprint(rules)

    # 阶段 1：环境搭建。Agent 生成 UVM 骨架、filelist、Makefile 与运行脚本
    env_prompt = f"""
你是 SoC 验证工程师。目标设计：{design_name}。
请根据下面的验证计划生成 UVM 环境骨架：
- 生成 filelist.f、Makefile、run_tb.sh
- 编译目标与仿真选项需符合验收标准文件中的约束
- 严禁修改 {RULES_PATH}

验证计划：
{test_plan}
"""
    run_claude(
        env_prompt,
        allowed_tools=["Read", "Write", "Bash", "Glob"],
    )

    # 阶段 2：用例生成与回归执行。Agent 可写测试代码并跑仿真
    regression_prompt = """
请基于已生成的 UVM 环境：
1. 为验证计划中的每一条特性生成对应的 Sequence 与 Test Case
2. 执行回归仿真，收集覆盖率与失败用例
3. 修复由环境问题导致的编译/运行错误，但不要修改验证意图
"""
    run_claude(
        regression_prompt,
        allowed_tools=["Read", "Write", "Bash", "Grep", "Glob"],
    )

    # 阶段 3：日志分析。Agent 只读日志并产出报告，无权改环境
    analysis_prompt = """
请分析本次回归日志：
- 区分环境错误与真实 RTL 缺陷
- 对每条失败给出证据链（文件、行号、波形时间点）
- 按验收标准逐条给出通过/不通过结论
"""
    report = run_claude(
        analysis_prompt,
        allowed_tools=["Read", "Grep", "Glob"],
    )

    # 收尾守护：校验标准文件未被篡改后才允许输出报告
    ensure_rules_intact(before_hash)

    return json.loads(report)
```

这里的权限分层很关键：**越接近「判定」的环节，Agent 的工具面越窄**。环境搭建可写、可执行；日志分析只能读，防止它在分析阶段顺手改环境去掩盖问题。

### 4.4 验收标准文件示例

判定标准由人维护，Agent 只读。内容形如：

```json
{
  "project": "custom_soc_example",
  "checkers": [
    {
      "name": "axi_burst_length",
      "type": "protocol",
      "expect": "burst length 1-256 全部覆盖",
      "pass_criteria": "coverage >= 100%"
    },
    {
      "name": "clk_gating_power",
      "type": "power",
      "expect": "关断状态功耗低于门限",
      "pass_criteria": "avg_power <= 1.8mW"
    }
  ],
  "signoff": {
    "required_by": "human_engineer",
    "agent_can_edit": false
  }
}
```

`agent_can_edit: false` 不是靠 Agent 自觉，而是靠 `ensure_rules_intact` 在系统层面强制。

### 4.5 与 CI/CD 集成

把上面的 `verify_flow` 接到 GitLab CI / Jenkins 里，每次 RTL 变更自动触发 Agent 验证：

```yaml
# .gitlab-ci.yml
soc-agent-verify:
  stage: verify
  image: verify-agent:claude-code-0.3
  script:
    - python verify_flow.py --design ${DESIGN_NAME} --plan testplan.md
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  allow_failure: false
```

人工 Sign-off 节点放在 Agent 验证之后：Agent 交付「已验证 + 证据链」的报告，工程师只做最终判定，不再逐条翻日志。

## 5. 从 1 个月到 2 天：关键路径拆解

周期压缩不是靠「AI 跑得更快」，而是把原来串行等待的环节并起来、把低价值重复劳动交给 Agent：

1. **环境搭建从手工到生成**：原本 3～5 天的 filelist/脚本整理，Agent 几分钟生成草稿，人只审核。
2. **用例开发规模化**：针对 Test Plan 逐条生成 Sequence/Case，覆盖率和可追溯性同时落地。
3. **回归失败自动分诊**：真实缺陷与环境问题自动分流，工程师不再被「假失败」淹没。
4. **判定标准固化**：验收口径写进只读文件，每一轮都用同一把尺子衡量，减少反复沟通。

整体上是把人的时间从「执行」里抽出来，投到「定义标准 + 判定缺陷」上。这正好对应「AI 拿执行权、人拿判定权」的分工。

## 6. 风险与治理边界

这套方案能落地，前提是守住几条边界：

- **标准文件只读 + 哈希校验**：防止 Agent 自我放宽判定。
- **工具白名单**：环境搭建、执行、分析使用不同的工具面，最小化越权面。
- **沙箱隔离**：仿真服务与工程仓库、判定仓库分离，Agent 跑在可回滚的容器里。
- **人负责 Sign-off**：最终投片决策必须由人做出，Agent 只提供证据和结论建议。

模型幻觉在验证流程里依然存在，因此所有 Agent 结论都必须绑定日志证据，不允许「大概通过了」这类不可溯源的表述。


### 6.1 典型风险场景与应对

Agent 在验证流程中的风险往往不是「完全失控」，而是局部越权或看似合理、实则错误的自洽结论。下面三个场景最值得重点防护：

1. **日志分析幻觉：把环境超时误判为真实缺陷**。回归任务跑挂时，Agent 可能因为上下文里缺少超时原因，自行推演出「疑似 RTL 死锁」并给出一份看似完整的证据链。检测方案：要求每条失败结论必须绑定可回放的日志文件、行号和时间戳，并自动交叉比对仿真退出码；无法回放或引用的行号不存在的结论直接标记为「未证实」。阻断方案：报告由 `report_validator` 解析，缺少 `evidence_id` 或引用日志不存在的条目一律不允许进入 Sign-off 队列。

2. **环境搭建越权：擅自放宽编译/仿真约束来让用例通过**。Agent 在「让回归变绿」的目标驱动下，可能修改 Makefile 中的超时阈值、降低覆盖率门限，甚至关闭某个断言开关。检测方案：对 `rules/acceptance_criteria.json` 做前后哈希校验，同时对 Workdir 下的关键配置文件启用只读挂载；代码审查阶段再对 Makefile 和运行脚本做结构化 diff，识别降低门限的字段变更。阻断方案：一旦 `ensure_rules_intact` 或配置文件指纹校验失败，立即回滚本次 Agent 产物并使流水线状态置为 `BLOCKED`。

3. **用例生成漂移：悄悄删掉难以覆盖的测试项**。Agent 生成 Sequence/Case 时，可能为了提升覆盖率报告而跳过某些协议边界项，或把未被覆盖的测试点标注为「不适用」。检测方案：将 Test Plan 导出为结构化 checklist，在回归完成后自动比对「测试项是否被生成并实际执行」，并检查覆盖报告中的排除项是否有明确的人工批准记录。阻断方案：缺失的 checklist 项会触发 `coverage_gate` 校验失败，Agent 无权自行删除或标注，补项动作必须由人类工程师在只读标准之外显式批准。

这类场景的共同点是：Agent 的输出越「自洽」，越不能只看结论，而要看它是否在既定的权限面和证据约束内完成。工程上的应对原则也一致——**让越权改不动、让幻觉无法伪装成证据**。
## 7. 总结

三星系统 LSI 事业部把 Claude Code 引入 SoC 验证，最有价值的地方不是单个任务的自动化，而是**在严肃研发流程里给出了一种可复制的 Agent 治理范式**：把执行链路大胆交给 Agent，把判定标准牢牢锁在人的手里，再用系统级校验兜底。

对大多数研发团队来说，「给 AI 执行权、不给判定权」是一条比「什么都不让 AI 碰」或「什么都丢给 AI」都更现实的路。先把环境搭建、日志分析、用例生成这些高重复、可校验的环节 Agent 化，再逐步扩大工具面，是成本最低的切入点。

据近期业界披露，三星电子系统 LSI 事业部在客户定制芯片（Custom SoC）的功能验证与环境搭建环节中，引入了 Anthropic 的 Claude Code，把原本需要约 1 个月才能完成的验证准备与执行工作，压缩到了 2 天左右。

三星把 Claude Code 塞进 SoC 验证：1 个月压缩到 2 天的 Agent 提效实践

硬件

人工智能

开发工具

三星引入ClaudeCode将SoC验证周期从1个月压缩至2天，核心在于“执行权下放、判定权上收”：Agent可生成环境、运行用例、分析日志，但验收标准文件只读，经哈希校验防篡改。通过工具白名单与沙箱隔离，实现环境搭建、回归测试、日志分析全链路自动化，同时确保证据链可追溯，人工保留最终签核权。

日志分析

日志文件

代码解释

容器

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

三星把 Claude Code 塞进 SoC 验证：1 个月压缩到 2 天的 Agent 提效实践-腾讯云开发者社区-腾讯云

三星把 Claude Code 塞进 SoC 验证：1 个月压缩到 2 天的 Agent 提效实践

三星把 Claude Code 塞进 SoC 验证：1 个月压缩到 2 天的 Agent 提效实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐