企业官网建设流程全解析

1. 这不是工具消亡史，而是开发者工作流的“静默进化”

过去一年，我几乎每天都会打开 Slack 查看团队消息，但 Claude Code 的图标在 Dock 栏里积了灰——不是它不好用，而是它已经“退场”成了背景音。标题里说的“70% 的工作都不需要打开 Claude Code”，听起来像某种技术淘汰宣言，但实际翻看我们团队的 commit 记录、PR 评审日志和 daily standup 笔记，你会发现一个更真实的图景：Claude Code 没有消失，它被拆解、封装、调度，最终沉入底层，变成了 Harness 工程中一个无需感知的执行单元。这不是 AI 工具的失败，恰恰是它真正成功的标志——当一个能力足够可靠、足够可编排、足够可预测时，它就该从“显性操作界面”退场，转为“隐性基础设施”。

这背后的核心转变，是工作流范式的迁移：从“人调用工具”走向“系统调度智能体”。Claude Code 原本是一个强交互式 IDE 插件，你得选中代码、右键、点击“Ask Claude”、等待响应、再手动复制粘贴；而 Harness 构建的是一套基于意图的自动化流水线——比如你 Slack 里发一句“把用户登录失败日志的错误码提取成结构化 JSON，并写入监控看板”，Harness 就自动拆解任务：调用 Claude Code 处理自然语言理解与代码生成，调用本地 Python 环境执行数据清洗，调用 Grafana API 更新看板，全程无须你打开任何 IDE 界面。我统计过我们团队上季度的 237 个典型开发任务，其中 168 个（约 71%）完全由 Harness 在后台闭环完成，开发者只负责输入自然语言指令和验收结果。

这种变化对不同角色影响差异极大。初级工程师最受益：他们不再卡在“不知道怎么写正则提取日志”或“搞不定 Prometheus 查询语法”的环节，一句“帮我写个告警规则，触发条件是 error_count > 5/min 且持续 3 分钟”，Harness 就能生成带注释的 YAML 并自动部署；资深架构师反而要花更多时间设计 Skill 编排逻辑——比如“日志分析”这个 Skill，必须明确定义输入 Schema（原始日志格式）、输出契约（JSON 字段名与类型）、失败降级策略（当 Claude Code 返回空结果时，是否 fallback 到硬编码规则），这些才是新阶段真正的技术门槛。而“Claude Tag”这类标签机制，本质上是给自然语言指令打元数据，让 Harness 能识别“这是运维类请求”还是“这是前端样式调整”，从而路由到对应 Skill 集合——它不是魔法，是工程化的语义路由表。

你可能会问：那 Claude Code 本身还重要吗？当然重要，但它已从“主角”变成“引擎供应商”。就像汽车驾驶员不需要懂内燃机原理，但发动机的可靠性直接决定整车体验。我们团队至今仍保留 Claude Code 的本地调试模式，用于验证新 Skill 的 prompt 工程效果——比如测试“生成 TypeScript 接口定义”这个 Skill 时，会直接在 VS Code 里用 Claude Code 手动跑通样例，确认输出格式稳定后，才注入 Harness 流水线。这种“线下验证+线上调度”的双轨机制，正是当前最务实的落地路径。

2. Harness 的“自我淘汰”：不是放弃 Claude Code，而是重构它的存在形态

Harness 的“自我淘汰”这个说法，初看容易误解为技术否定，实则是工程演进的必然结果。它淘汰的从来不是 Claude Code 这个模型能力，而是“人作为中间调度者”的低效环节。我们可以用一个具体场景来拆解这个过程：上周三，后端同学小李需要为新上线的支付模块添加链路追踪埋点。按旧流程，他得：

1. 打开 VS Code，定位到payment_service.go文件
2. 手动阅读 300 行代码，找出所有 HTTP 调用点
3. 查阅 OpenTelemetry 文档，确认Tracer.StartSpan()的参数签名
4. 逐行插入埋点代码，反复编译调试
5. 提交 PR，等同事 Code Review

整个过程耗时约 2.5 小时，且极易遗漏边缘调用路径。而新流程下，他在 Slack 的 #infra 频道发送：

/harness trace-payment-service --target payment_service.go --span-name "payment-flow"

Harness 收到指令后，自动执行以下步骤：

• 解析指令，匹配预设的trace-serviceSkill
• 调用 Claude Code 的 API（非 UI 界面），传入payment_service.go的完整源码和指令上下文
• Claude Code 返回结构化 patch：包含需插入的 span 创建代码、context 传递逻辑、error 处理模板
• Harness 将 patch 应用到 Git 仓库，生成 draft PR，并附上 diff 链接和 Claude Code 的 reasoning 日志（说明为何选择在第 47 行和第 129 行插入）
• 全过程耗时 87 秒，小李收到 Slack 通知后，只需点击链接查看 diff 并 approve

这里的关键在于：Claude Code 的能力被封装为 Skill 的“推理引擎”，其输入/输出被严格契约化。我们为每个 Skill 定义了三个核心接口：

• Input Contract：明确要求传入的代码片段必须带 AST 结构信息（而非纯文本），这样 Claude Code 能精准定位函数边界；
• Output Contract：强制返回 JSON 格式，包含patch_lines（行号范围）、insert_code（待插入代码）、reasoning（简要解释）三个字段；
• Fallback Policy：当 Claude Code 返回格式错误或超时，自动切换至规则引擎——比如对标准 HTTP client 调用，直接应用预置的模板补丁。

这种设计让 Claude Code 从“自由发挥的助手”变成“可预期的组件”。我们甚至给它加了“刹车机制”：所有 Claude Code 生成的代码变更，在提交前必须通过静态检查（golangci-lint）和单元测试覆盖率验证（≥85%），否则自动回滚并告警。这解决了早期最大的顾虑——AI 生成代码的不可控性。现在团队共识是：Claude Code 不是替代开发者，而是把开发者从“机械编码”中解放出来，专注更高阶的设计决策，比如“这个埋点应该采集哪些业务维度？”、“span 的 parent-child 关系如何映射真实业务流程？”——这些恰恰是 Claude Code 目前无法替代的领域。

3. 从 Claude Code 到 Harness：一场围绕“可编排性”的底层重构

Harness 的本质，是一套面向 AI Agent 的编排框架，而 Claude Code 只是它可接入的众多“执行器”之一。理解这一点，才能看清所谓“自我淘汰”的技术实质——它淘汰的是单点工具思维，建立的是可组合、可验证、可审计的智能体协作网络。我们团队的 Harness 架构分三层，每一层都针对 Claude Code 的局限性做了针对性设计：

3.1 接入层：解耦模型调用与业务逻辑

Claude Code 作为 VS Code 插件，其调用深度绑定 IDE 环境：你必须在编辑器里选中文本，触发上下文感知。而 Harness 的接入层通过统一的Agent Gateway实现协议抽象。我们为 Claude Code 封装了一个 REST Adapter，它接收标准化的 JSON 请求：

{ "skill_id": "generate-unit-test", "input": { "code": "func Add(a, b int) int { return a + b }", "language": "go", "test_framework": "testing" }, "config": { "max_tokens": 512, "temperature": 0.3 } }

Adapter 负责将此请求转换为 Claude Code 的 API 调用（如 Anthropic 的/v1/messages），并过滤掉敏感字段（如system提示词中的内部文档链接）。关键改进在于：同一份提示词模板（Prompt Template）可同时服务于 VS Code 插件、Slack Bot 和 CI Pipeline。比如“生成 Go 单元测试”这个 Skill，我们在本地调试时用 Claude Code 的 UI 模式快速迭代 prompt，验证通过后，直接将该 prompt 注册到 Harness 的 Skill Registry，后续所有渠道调用都复用同一逻辑。这避免了过去常见的“Slack 里生成的测试代码格式错乱，VS Code 里却正常”的环境不一致问题。

3.2 编排层：用 DAG 定义智能体协作关系

Harness 的核心创新在于引入有向无环图（DAG）描述 Skill 依赖。以“修复线上 Bug”为例，传统做法是人依次执行：

1. 查看 Sentry 错误堆栈 → 2. 定位源码 → 3. 写修复代码 → 4. 写测试 → 5. 提交 PR

而 Harness 的fix-bugSkill 是一个 DAG：

• Node A（诊断）：调用 Claude Code 分析 Sentry 错误日志，输出 root cause 和影响范围
• Node B（修复）：将 Node A 输出作为 context，调用 Claude Code 生成修复 patch
• Node C（验证）：运行本地测试套件，若失败则触发 Node D
• Node D（fallback）：启用规则引擎，根据错误类型匹配预置修复模板（如空指针异常→添加 nil check）

每个 Node 可独立配置超时、重试次数、失败通知方式。我们甚至给 Node A 加了人工审核闸门：当 Claude Code 的置信度低于 0.7 时，自动创建 Jira ticket 并 @ 相关开发者，而不是盲目执行后续步骤。这种细粒度控制，是单点 Claude Code 无法提供的——它把“AI 决策”变成了可观察、可干预的工程节点。

3.3 执行层：构建安全可控的沙箱环境

Claude Code 在本地 IDE 运行时，理论上能访问你电脑上的任意文件。而 Harness 的执行层强制所有 Skill 在隔离沙箱中运行：

• 代码执行沙箱：基于 gVisor 容器，限制网络访问（仅允许调用内部 API）、禁止文件系统写入（除临时目录外）、CPU/内存配额严格管控；
• 模型调用沙箱：Claude Code 的 API Key 经过 Hashicorp Vault 动态签发，每次调用生成唯一 token，有效期 5 分钟，且绑定 Skill ID 和请求指纹；
• 输出净化层：所有 Claude Code 返回内容经过正则过滤（移除可能的 shell 命令、base64 编码的恶意 payload）、AST 语法校验（确保生成的 Go 代码能被go/parser解析）。

这套机制让我们敢把 Harness 接入生产环境 CI。上周五，CI 流程检测到main分支的测试覆盖率下降，自动触发improve-test-coverageSkill：Claude Code 分析未覆盖代码，生成补充测试，Harness 在沙箱中运行测试验证通过后，才推送 PR。整个过程无人工干预，但每一步都有审计日志——这是 Claude Code 单独使用时完全缺失的工程保障。

4. 实操指南：如何将你的 Claude Code 工作流迁移到 Harness 框架

迁移不是推倒重来，而是渐进式重构。我们团队花了 6 周完成全量迁移，核心策略是“先封装，再编排，最后集成”。以下是可直接复用的实操步骤，基于 Ubuntu 22.04 + VS Code 环境（其他系统仅需微调路径）：

4.1 第一阶段：封装现有 Claude Code 能力为 Harness Skill（耗时约 2 天）

目标：把你最常用的 3 个 Claude Code 操作（如“生成单元测试”、“解释报错信息”、“重写代码为更优实现”）变成可 API 调用的 Skill。

步骤详解：

1. 安装 Harness CLI：

   curl -sSL https://get.harness.io | sh source ~/.harness/harness.sh harness login --api-key your-api-key-here

   提示：API Key 在 Harness Cloud 控制台的Settings > Access Tokens中创建，权限仅勾选Skill Management。

2. 创建 Skill 模板：

   harness skill create --name "go-unit-test" --template "claude-code"

   此命令生成目录skills/go-unit-test/，包含skill.yaml（定义元数据）和prompt.txt（存放提示词）。

3. 编写健壮的提示词（prompt.txt示例）：

   你是一名资深 Go 开发工程师，为以下函数生成单元测试。要求： - 使用标准 testing 包 - 覆盖正常路径、边界条件、错误路径 - 每个测试用例命名清晰（TestFuncName_CaseDescription） - 输出仅为 Go 代码，不包含解释文字 - 函数签名：{{.FunctionSignature}} - 函数实现：{{.FunctionBody}}

   注意：{{.FunctionSignature}}是 Harness 的模板变量，运行时会被实际值替换。相比 Claude Code 原生提示词，这里强制约束了输出格式，避免自由发挥导致解析失败。

4. 本地测试 Skill：

   echo '{"FunctionSignature":"func Add(a, b int) int", "FunctionBody":"return a + b"}' | \ harness skill run go-unit-test --input-json

   预期输出应为纯 Go 代码块。若返回含解释文字，立即修改prompt.txt，增加“输出仅为 Go 代码，不包含解释文字”等强约束句。

4.2 第二阶段：构建 Slack 集成与基础编排（耗时约 3 天）

目标：让团队成员能在 Slack 中直接调用 Skill，且支持简单串联（如先解释报错，再生成修复代码）。

关键配置：

• 在 Slack App 设置中，启用Slash Commands，将/harness指向 Harness Cloud 的 Webhook URL（格式：https://app.harness.io/api/v1/slack/command）；
• 在skills/go-unit-test/skill.yaml中添加：

  triggers: - type: slack_command command: "/harness test-go" description: "为当前代码生成单元测试"

• 创建编排流程debug-flow.yaml：

  name: debug-error description: "诊断错误并生成修复建议" nodes: - id: diagnose skill: explain-error input: "{{ .error_log }}" - id: fix skill: generate-fix input: "{{ .diagnose.output.root_cause }}" depends_on: [diagnose]

  此流程定义了两个 Skill 的依赖关系，Harness 会自动按序执行。

实测技巧：我们发现 Slack 的消息长度限制（4000 字符）常导致长日志截断。解决方案是在explain-errorSkill 中加入预处理：

# skills/explain-error/preprocess.py def truncate_log(log): if len(log) > 3000: return log[:1500] + "\n...[LOG TRUNCATED]...\n" + log[-1500:] return log

并在skill.yaml中声明：preprocess: preprocess.py。这样既保证信息完整性，又规避 Slack 限制。

4.3 第三阶段：接入 CI/CD 与生产环境（耗时约 1 天）

目标：让 Harness 自动参与代码质量保障，成为研发流程的“隐形守门员”。

核心配置：

• 在.harness/ci.yaml中定义：

  on: - pull_request: branches: [main] jobs: - name: "Test Coverage Check" steps: - name: "Run Harness Skill" uses: harness/actions/skill@v1 with: skill_id: "improve-test-coverage" input: | {"file_path": "${{ github.head_ref }}", "threshold": 85}

• 在 Harness Cloud 的Environments中，为生产环境创建专用 Service Account，仅授予read:code和write:pr权限，绝不赋予admin:all。

避坑经验：初期我们曾将 Harness 配置为自动 merge PR，结果因网络抖动导致 Skill 超时，误合并了未验证的代码。血泪教训是：永远不要让 AI 自动执行不可逆操作。现在所有涉及代码变更的 Skill，都强制设置auto_merge: false，Harness 只负责生成 draft PR，最终决策权留在开发者手中。

5. 常见问题与实战排查手册：那些文档里不会写的细节

迁移过程中，我们踩过不少坑，有些是 Harness 的设计特性，有些是 Claude Code 的固有局限。以下是高频问题的排查清单，附带真实日志片段和解决路径：

5.1 问题：Claude Code 返回结果不稳定，同一提示词有时格式正确，有时混入解释文字

现象：generate-unit-testSkill 在 CI 中偶尔返回：

Here's the unit test for your function: func TestAdd(t *testing.T) { ... }

导致 Harness 解析失败（因多出首行文本）。

根因分析：Claude Code 的 temperature 参数影响输出确定性。默认值 1.0 会导致随机性增强，尤其在复杂提示词下。

解决方案：

• 在 Skill 的skill.yaml中显式设置：

  model_config: temperature: 0.2 max_tokens: 1024

• 更关键的是，在提示词末尾添加格式锚点：

  [OUTPUT FORMAT START] func TestAdd(t *testing.T) { ... } [OUTPUT FORMAT END]

  Harness 的解析器会严格提取[OUTPUT FORMAT START]和[OUTPUT FORMAT END]之间的内容，彻底忽略外部干扰。实测后成功率从 82% 提升至 99.7%。

5.2 问题：Slack 中调用 Skill 时，中文指令被识别为乱码或触发错误 Skill

现象：用户发送/harness 生成用户注册接口，Harness 日志显示：

WARN: Unmatched trigger for command '生成用户注册接口', falling back to default

根因分析：Slack 的 Slash Command 默认使用application/x-www-form-urlencoded编码，中文字符需 URL decode。而 Harness 的早期版本未自动处理此解码。

解决方案：

• 升级 Harness CLI 至 v2.3.1+（已内置解码逻辑）；
• 若无法升级，临时方案是在 Slack App 的Interactivity & Shortcuts设置中，将Request URL改为指向自建代理服务，该服务先做decodeURIComponent()再转发给 Harness。
• 长期建议：在skill.yaml中定义trigger_keywords，例如：

  triggers: - type: slack_command command: "/harness api" keywords: ["生成接口", "创建API", "user register"]

  这样即使指令文本有偏差，也能命中 Skill。

5.3 问题：Harness 执行 Skill 时超时，但 Claude Code API 实际已返回结果

现象：explain-errorSkill 日志显示timeout after 30s，但查 Anthropic 后台发现该请求 12 秒就完成了。

根因分析：Harness 的默认超时是全局配置，而 Claude Code 处理长日志（如 500 行堆栈）时，网络传输耗时可能超过阈值，尤其当公司防火墙启用深度包检测（DPI）时。

解决方案：

• 为特定 Skill 单独设置超时：

  timeout_seconds: 60

• 更优方案是优化输入：在 Skill 的preprocess.py中，用正则提取关键错误行（如panic: runtime error及其后 5 行），丢弃无关的 goroutine dump。我们发现 90% 的错误诊断只需 20 行关键日志，传输时间从 28 秒降至 3 秒。

5.4 问题：生成的代码在沙箱中编译失败，但本地 VS Code 里 Claude Code 生成的相同代码能通过

现象：Harness 报错go build: exit status 2，错误指向undefined: http.Client。

根因分析：Claude Code 在 VS Code 中能看到项目完整的go.mod和依赖树，而 Harness 沙箱默认只挂载当前文件，缺少import语句所需的依赖上下文。

解决方案：

• 在 Skill 的skill.yaml中声明依赖：

  dependencies: - module: "net/http" - module: "encoding/json"

• Harness 会自动在沙箱中注入这些模块的 stub 定义，确保 AST 解析通过；
• 对于复杂依赖（如第三方 SDK），我们采用“双阶段生成”：第一阶段 Claude Code 生成核心逻辑，第二阶段由规则引擎注入import语句和初始化代码。这比强行让 Claude Code 记住所有 import 路径更可靠。

6. 未来半年：Harness 不会取代开发者，但会重塑“开发者”的定义

回顾这一年，Harness 的“自我淘汰”本质是工作流的静默升级——它淘汰的是重复劳动，而非人的判断力；它隐藏的是工具界面，而非技术复杂性。我们团队最近在规划 Q3 的技能图谱，发现一个有趣趋势：初级工程师的考核指标已从“写了多少行代码”转向“定义了多少个可复用的 Skill”；而架构师的周报里，“优化 Harness 编排 DAG”出现的频率超过了“设计微服务接口”。

这种转变带来两个现实挑战：一是 Prompt Engineering 正式进入岗位 JD。我们招聘新同学时，会现场给一段模糊需求（如“让订单状态流转更健壮”），要求候选人写出可落地的 Skill 提示词，并说明为什么这样写能约束 Claude Code 的输出。这比算法题更能检验工程直觉。二是“AI Debugging”成为新技能。当 Harness 流程失败时，你不能再像以前那样console.log，而要会看三类日志：Skill 的输入/输出快照、Claude Code 的 reasoning 日志、沙箱的资源监控数据。上周我们定位一个间歇性失败，最终发现是 Claude Code 在处理含 emoji 的日志时，token 计数异常导致截断——这种细节，只有深入日志才能捕获。

最后分享一个真实案例：上个月，实习生小陈用 Harness 快速搭建了一个“自动更新 Swagger 文档”的 Skill。他没写一行 Go 代码，而是：

1. 用 Claude Code 生成解析 OpenAPI spec 的 Python 脚本；
2. 将脚本封装为 Skill，输入为swagger.yaml路径，输出为更新后的文件；
3. 在 CI 中配置：每次docs/目录变更，自动触发此 Skill。
   整个过程 4 小时，而传统方式需要 2 天。但真正让我惊讶的，是他主动在 Skill 中添加了 diff 验证：Harness 会对比生成前后文件的 MD5，若无变化则跳过提交——这个细节，连很多资深工程师都没想到。

所以，Claude Code 没有消失，它只是换了一种方式存在；Harness 也不是终点，它只是我们重新定义“开发效率”的起点。当你不再需要打开某个工具，恰恰说明你已经把它用到了极致。