企业官网建设流程全解析

1. 先聊清楚：为什么企业级 AI Coding 需要 Harness 工程

这几年 AI Coding 的热度有多高，不用我多说。但有一个现象特别有意思：个人开发者用 Claude、DeepSeek 这类模型写脚本、做小工具，效率确实翻倍；可一旦到了企业级项目，动辄几十万行代码、多人协作、严格的发布流程、跨系统依赖，AI Coding 的表现就立刻变得不可控。模型有时答非所问，有时生成的代码风格混乱，有时改了 A 模块却把 B 模块搞崩。

问题出在哪？不是模型不够强，而是我们压根没给模型搭一套“工程化”的工作环境。就像你给一个顶尖厨师最好的锅和食材，但厨房里没有案板、没有灶台、没有调料架，他照样做不出一桌宴席。Harness 工程就是这个厨房的改造方案。

Harness 这个词，直译是“马具”，引申义是“驾驭”。在 AI Coding 语境下，Harness 工程的核心目标是：把大模型的生成能力装进一套可控、可观测、可回滚、可评估的工程管道里。它不是某一个工具，而是一整套方法论加工具链的结合。

那 Skill 又是什么？简单理解，Skill 就是给模型预装的一套“专业能力包”。你可以把它理解成给实习生一份极其详细的标准作业流程手册：遇到什么情况，按什么步骤处理，调用什么工具，输出什么格式，边界在哪里，每一条都写得清清楚楚。模型拿到 Skill 之后，就不再是“自由发挥”了，而是按照这份手册执行。

我见过太多团队在这个环节踩坑——他们觉得反正模型很强，我给它一句 prompt 就够了。结果代码审查、单元测试、需求拆解、文档输出，每一步都要人工重新干预。真正跑通的企业级 AI Coding，必须有这么一层用 Skill 串起来的全链路：需求进来，自动拆解，自动规划架构，自动写代码，自动补测试，自动做代码评审，自动跑链路压测，最后自动形成发版说明。

这篇文章我就把自己实际搭过的一套 Harness 工程体系拿出来，完整讲讲这 8 个 Skill 是怎么设计的、怎么串起来的、中间有多少坑。

2. 从 Agent 到 Harness：一次理念层面的转变

2.1 为什么单独的 Agent 模式不够用了

很多读者应该已经接触过 Agent 类产品。它的大致工作方式是：你给它一个目标，它自己规划步骤，自己调用工具，自己完成任务。听起来很完美，但在真实企业场景里，这套模式有两个很难忍受的缺点。

第一个缺点是不确定性。同一句话，Agent 这次可能走 5 步完成任务，下次可能走 15 步，中间还可能偶尔自己“突发奇想”，调用了一个完全不相干的工具。在大规模生产环境里，这种不确定性是致命的。你没法跟运维说“这个任务大概跑 5 分钟，也可能跑 1 小时”，也没法跟财务说“这次调用的 token 成本大概是 5 块钱，也可能 50 块”。

第二个缺点是不可审计性。Agent 的每一步都是模型自主决策的，出了问题之后，你很难回答“到底哪一步错了”“为什么会错”“下次怎么防”。我在做线上事故复盘的时候，最怕看到的就是“Agent 自主决定调用了一个接口”这种描述——这根本没法复盘。

2.2 Harness 工程的三个核心原则

Harness 工程和 Agent 最大的区别，是它引入了三个核心原则。

第一个原则叫显式流程。所有的任务路径、步骤节点、执行顺序，都是工程师预先在 Harness 里定义好的。模型不是在“自主规划”，而是在“按图施工”。每一步该做什么，做完之后交给谁，发生异常时走哪条分支，全部是显式声明的。

第二个原则叫标准化接口。每个 Skill 都定义好输入输出格式、数据模型、错误处理方式。Skill 和 Skill 之间通过结构化的数据传递，而不是靠模型“读懂上下文”。这在工程上至关重要——你要保证需求分析模块的输出，能被架构规划模块稳定地消费，而不是每次输出格式都不一样。

第三个原则叫人在环上。注意，是“在环上”不是“在环中”。模型负责批量干脏活累活，但关键节点（比如架构选型、涉及关键业务的代码合并）必须有人的确认机制。这既是为了保证质量，也是为了责任边界的清晰。

2.3 用生活类比说清 Skill 和 Agent 的关系

为了帮助团队里非技术背景的同学理解，我经常打一个比方：传统的 Agent 像一个被委托人，你告诉他“去买一台适合写代码的笔记本电脑”，他从众多品牌中自己挑，买到什么是什么；而 Harness 工程加 Skill 的组合，像给委托人一张采购单，上面写明了预算范围、屏幕尺寸、处理器型号、售后要求、备选品牌。他还是会去挑，但挑的过程和结果都会收敛在合理边界里。

Skill 就是这张采购单。它把模型中隐性的知识挖掘能力，转译成了显性的流程化执行能力。团队可以像维护代码库一样去维护 Skill——版本迭代、review、灰度试验，全部走正规的工程流程。一个写得好的 Skill，就是一个具备专业水准的“数字员工”。

3. 8 个 Skill 的完整设计拆解：从需求到运维

3.1 为什么是 8 个，而不是 3 个也不是 15 个

在设计这套体系的时候，我反复斟酌过 Skill 的数量。拆得太粗，每个 Skill 内部还是会需要模型做大量隐式决策，“不听话”的问题还会冒出来；拆得太细，光维护 Skill 之间的流转就要花掉大量精力，得不偿失。

最终定下 8 个，是因为这 8 个环节正好覆盖了软件交付生命周期的全部关键节点。每个 Skill 只干一件事，但都干得足够专精。下面我用一个表格先给你看全貌，再逐一细说每个 Skill 的设计要点。

3.2 需求解析器：把模糊变成精确

需求解析是整个链路的第一环，也是最重要的一环。很多人会低估它——觉得“需求拆解不就是让模型读一遍需求然后列几条要点吗”？现实远比这个复杂。

真实业务需求通常是这样的：“优化下单流程，让用户体验更好，同时能够支撑未来大促流量”。这句话放在简历上没毛病，但让工程师直接开发，至少能吵一小时。需求解析器的目标，就是通过结构化模板，强制把需求的各个维度挖出来。

这个 Skill 的内部逻辑是三层递进：

第一层是意图识别。判断这条需求属于新增功能、缺陷修复、性能优化、还是业务策略调整。这一步做不对，后续所有环节都会跑偏。

第二层是要素提取。把业务规则、用户角色、数据字段、异常场景、性能要求五个维度分别提取出来。每个维度又有一组预设问题，比如业务规则维度会追问“必填字段有哪些”“同一用户是否可以重复提交”“并发时如何处理”。

第三层是验收标准生成。这一步是从“可测试性”的角度反向逼问需求——没有验收标准的需求，等于没写。系统会生成一组 Given-When-Then 结构的行为用例，例如“当用户提交订单时余额充足，则订单创建成功并扣减余额；当余额不足，则返回错误码 10086 且不生成订单”。

这个 Skill 的核心实现细节，在于预设问题模板库的积累。我最初的版本只定义了 20 个通用问题，后来把公司内部过去两年的业务需求做了一次梳理，归类补全到 150 多个场景化问题。这个工作没有捷径，只能靠长期沉淀。

3.3 架构规划师：从需求到设计图的跃迁

需求解析器输出的是一堆需求卡片，它们之间的关系还是散乱的。架构规划师负责把这些卡片组织成一张可施工的蓝图。

这个 Skill 的设计思路，是“自顶向下、逐层精化”。第一步先识别业务核心实体和核心流程。举个例子，一个电商订单系统的需求卡片可能有 30 张，但核心实体可能只有“用户”“商品”“订单”“支付”四类。Skill 会把这四个实体识别出来，作为架构的锚点。

第二步是模块划分。根据核心实体和业务边界，把需求卡片归入不同的模块。这一步有一个我非常坚持的原则：高内聚、低耦合必须量化。不能只靠模型“感觉”某个模块应该放哪些东西，而是要求它列出模块间的接口依赖清单，人工确认没有循环依赖才会继续。

第三步是接口设计和技术选型建议。模型不会直接拍板用哪种消息队列、哪个数据库，但它会把每种候选方案的适用场景、团队已有技术栈匹配度、运维成本列出来，供架构师决策。说白了，它做的是“信息整理和方案对比”这种脏活累活，把人的精力留下来做高价值决策。

这里有一个非常实用的提示词技巧：在架构规划 Skill 里，给模型植入一个角色提示——“你是一名从业 15 年的系统架构师，服务过互联网大厂，经历过千万级并发项目”。实测下来，这种角色设定能显著提升产出方案的完整度，尤其是它会下意识地考虑容灾、扩展性、可观测性这些非功能性需求。强烈建议你在自己的 Skill 里也加上这个角色锚定。

3.4 代码生成器：不只是“写代码”

代码生成器是大家最关注的环节，也是最容易产生认知偏差的环节。很多人以为它就是一个“把所有需求转成代码”的魔法盒子，实际上它要做的事情比“写代码”多得多。

代码生成器不是从零开始写代码，而是要完成“翻译”：把模块任务书翻译成符合团队规范的代码。它的核心工作流是：

第一步读取架构规划师输出的模块任务书，提取接口定义、数据模型、业务规则。第二步检索企业内部的代码资产库，看看有没有现成的 SDK、公共组件、类似实现可以直接引用。这一步非常关键——我见过太多团队让 AI 生成了第二套不兼容的工具类库，最后代码审查阶段全部打回去重写。AI 写代码的速度快，但代码的“社区一致性”更重要，引用统一的公共组件，比“写得更快”值钱得多。

第三步是代码框架生成。Skill 内置了团队统一的代码骨架模板，包括目录结构、命名规范、异常处理基类、日志格式。这些约束通过强制模板注入生成逻辑，确保 AI 产出的代码从第一天起就符合团队规范。

第四步是自测用例生成。不要等后面的测试工程师环节再补用例，代码生成器在生成业务代码的同时，就必须生成一套基础的单元测试，确保“自己验证自己做的东西能跑”。

这里我必须提醒一个隐蔽的坑：代码生成器必须严格限制在“模块范围”内工作。我见过 AI 在写用户模块代码的时候，自以为很贴心地顺带改了公共配置文件的例子，结果整个测试环境全崩。后来我在 Skill 的约束规则里加了一条硬性禁令——“禁止修改任务书未提及的任何文件”，这类事故就彻底杜绝了。

3.5 代码评审官：挑出自己的毛病

代码评审官这个 Skill 的设计初衷是“角色对抗”——让另一个独立的推理上下文中挑前一个环节的毛病。很多团队不理解为什么需要这个，他们会说“代码生成器不是已经写了自测用例吗”？这就是典型的外行话。

自测用例解决的是“代码能不能跑”的问题，代码评审官解决的是“代码能不能长期维护”的问题。

这个 Skill 的检查清单分布在四个层面：

• 正确性层面：是否存在逻辑边界遗漏？空指针、越界、并发竞争是否处理了？错误处理链路是否完整？
• 安全层面：是否存在注入风险？敏感信息是否被硬编码？权限校验是否缺失？
• 规范层面：命名是否符合团队规范？是否存在过长函数？依赖引入是否合理？
• 性能层面：是否存在明显的循环内查库？大数据量场景下是否有内存溢出风险？缓存策略是否合理？

每个层面预设了 10 到 20 条检查规则，全部显式写入 Skill 的清单文件里。评审官产出的是带严重程度分级的问题清单（Blocking / Major / Minor），Blocking 级问题直接打回让代码生成器重做，Major 级问题进入人工确认队列，Minor 级问题自动修复。

我觉得这个 Skill 最关键的设计决策，是要在评审官的执行上下文里删除代码生成器当时的角色信息和设计意图，让它“裸评”——只看到代码本身和需求文档，不看到生成过程的中间解释。理由就是人与人协作中常说的“换只手检查”：如果从同一个人的视角出发，很容易延续同样的思路和盲点；让模型在独立上下文中纯粹按规则审查，挑出来的问题反而更准。

3.6 测试工程师：从“代码能跑”到“系统可用”

测试工程师 Skill 的职责，是在代码评审通过之后，把模块级的质量验证做深做透。它的第一步是基于代码评审结果和需求卡片，生成完整的测试计划，而不是零散地补几个用例。

在这个 Skill 里，我用了一个比较老的测试设计方法论——等价类划分和边界值分析。但你不需要把它想得特别高深，我把它们转成了 prompt 层面的“穷举规则”，让模型按四个方向生成测试数据：

• 正常输入：覆盖所有业务流程主线。
• 边界输入：字段长度边界、数值大小边界、分页边界、时间边界。
• 异常输入：格式错误、空值、超长值、类型不匹配。
• 并发场景：多用户同时操作、重复提交、幂等性验证。

另外这个 Skill 还要负责一件事：集成测试场景的预编排。单元测试是模块内部自测，但真正的坑往往在模块之间的交互里。比如订单模块和库存模块之间的接口联调，单独测任何一边都是好的，合在一起就出问题。测试工程师 Skill 会根据架构规划师的接口设计文档，提前把这些交互场景列出来，为后面的链路压测打基础。

3.7 链路压测员：提前掀开性能的底牌

链路压测员是后面“全量压测”的突击队，也是 8 个 Skill 里我个人最有心得的一个。它解决的问题是：单个模块性能 OK，不代表整个业务链路能扛住流量高峰。

这个 Skill 的工作流大致如下：

第一步定义链路范围。从需求解析器产出的核心链路清单里，挑选出需要压测的关键路径，比如“用户下单 -> 库存扣减 -> 支付回调 -> 订单状态更新”这样一条端到端链路。

第二步生成压测脚本。基于接口定义，自动生成符合 JMeter 或 k6 语法规范的脚本，模拟不同并发度（比如 50、200、1000 并发的梯度）的请求。

第三步执行压测并记录数据。这一步 Chain 会调用部署环境信息，把压测任务提交到压测集群，同时采集响应时间、吞吐量、错误率、CPU 内存指标等多个维度的数据。

第四步输出瓶颈分析。模型会把压测数据和代码模块映射起来，定位瓶颈大概率出在哪一环。比如，如果压测数据显示用户查询接口 P99 耗时明显高于其他接口，模型会提示“用户服务可能存在数据库慢查询”，并关联到对应的表结构和索引设计。

在全量压测这个概念上多说一句：链路压测员这个 Skill 配合 Harness 框架，可以实现相对透明的全链路演练——从网关服务开始，到中间件，再到数据库，所有依赖的测试桩都自动替换完成。这才是企业级 AI Coding 的底气：AI 生成的前端到后端整条业务链路，都能在真实压力下先“跑冒滴漏”一轮。

3.8 文档撰写者：让每个变更都有据可查

文档这件事，在企业里属于“人人都知道重要，但谁都不愿意认真做”的典型。AI Coding 改造之后，文档的频率和复杂度反而增加了——代码生成快、变更多，如果文档跟不上，项目很快就变成一座维护地狱。

文档撰写者 Skill 的核心能力，是把前面的代码变更、评审记录、压测报告、需求卡片聚合起来，自动生成两类文档：

第一类是技术设计文档（TDD）。它会追溯这次变更的需求来源、架构设计依据、代码实现思路、测试策略。这个文档的价值在于——三个月后有人问“当时为什么这么设计”，直接把这篇文档甩过去就行。

第二类是发版说明（Release Notes）。它会对比本次代码变更集，自动提取新增功能、缺陷修复、接口变更、配置变更四类信息，生成用户可读的发版说明。配置变更尤其关键，我见过太多生产事故就是因为发版时漏了配置变更同步——有了 AI 审核，这种情况能少 90%。

3.9 运维观测员：让 AI 对线上负责

最后一个 Skill，运维观测员，负责的是“上线之后”这个时段的持续监测。它的触发方式不是“任务式”的，而是“定时 + 事件驱动”的。

定时任务方面，它每五分钟采集一次线上核心服务的日志摘要、错误率、响应延迟 P99，生成一份健康快照。事件驱动方面，当异常指标达到预设阈值时（比如错误率连续 3 分钟超过 5%），它会自动拉取最近 30 分钟的日志，结合代码变更集和时间轴，做一次根因分析，输出“疑似原因 + 验证建议”。

这里有一个重要的工程决策：运维观测员只有预警权，没有处置权。也就是说，它发现了问题，只能发警报和建议给值班工程师，不允许自动执行任何变更操作。在 AI 工程化落地中，这条红线比任何技术能力都重要。

4. 从零搭建 Harness 环境：本地跑的完整步骤

4.1 选型建议：为什么我推荐从 DeepSeek Harness 入手

搭建这套系统，第一步是选一个 Harness 框架作为底座。市面上类 Harness 的开源项目很多，多数是社区驱动的个人项目，也有企业推出的方案。我的建议是，如果想快速一键跑通本地演示，优先选能直接拉起来就跑的框架，先别急着研究什么底层源码。

DeepSeek Harness 是我筛选下来比较省心的一套方案——它本身就是专门为 DeepSeek 系列模型设计的一个桌面端工具，可以直接把 Skill 管理、模型调用、任务编排串起来。对于团队验证“Skill 串联”这套思路，它的入门成本最低，官方也提供了一键安装包。如果你们团队已经有一套 Agent 类工具，也可以在现有工具上按本文的思路实现 Harness 工程化，但前提是不怕折腾。

我用 DeepSeek Harness 举例，下面说一说本地搭建的完整过程。

4.2 本地安装与账号准备

DeepSeek Harness 安装本身不复杂。到官网或者 GitHub Releases 页面下载桌面端安装包，双击装好启动就行。如果你更习惯命令行，它也提供一个 Python 包，用 pip 就能装好。

安装完成后，需要先完成两项关键配置：

第一项是模型服务配置。你可以选择官方 API，也可以选本地模型服务。对于验证 Skill 流程来说，官方 API 的响应速度和稳定性最好。不过要提醒你一点：API 调用是按 token 计费的，跑完一轮完整的 8-Skill 链路，大概要消耗几万 token。所以在调试阶段，建议先把模型温度调到 0，减少无意义的随机输出，能省不少 token。

第二项是建立 Skill 工作区目录。这个目录将用来存放全部 Skill 的配置和定义文件。你可以在 Harness 的配置面板里指定一个本地的路径，比如~/ai_harness/skills。每一个 Skill 用一个独立的子目录来管理，里面包含 index.yaml（Skill 元信息）、prompt.md（核心提示词）、rules.json（规则集）等文件。

4.3 编写第一个 Skill 的详细方法

Skill 的核心是文档加配置的组合。我以需求解析器为例，说说一个 Skill 由哪几个部分构成。创建 skill 目录之后，就需要填写以下内容：

index.yaml是 Skill 的“身份证”，包含 Skill 名称、适用模型、版本号、触发条件等元信息：

name: requirement_parser version: 1.2.0 description: 将业务需求原始文本解析为结构化需求卡片 triggers: - input_type: text intent_keywords: ["需求", "功能", "优化", "开发"]

prompt.md是这个 Skill 的“大脑”，里面是完整的人设设定和分步执行指引，我会在下面展示它的关键要点。它是整个 Skill 里最需要精心打磨的部分，可以模仿优秀技术文档的写法，用递进的层次引导模型一步步完成需求解析。

rules.json是 Skill 的“边界”，用于声明硬性禁止事项，比如不得编造验收标准、不得跳过问题模板直接生成需求等：

{ "prohibited": [ "禁止跳过需求要素提取直接生成验收标准", "禁止自行修改需求卡片字段", "禁止在需求表述不清时盲目假设业务规则" ], "required_outputs": ["requirement_cards", "acceptance_criteria"] }

一个写得合格的 Skill，必须做到“换一个模型也能执行同样的流程”。也就是说，Skill 的质量不能高度依赖底层模型的聪明程度——当模型不够聪明时，Skill 会用更细的步骤、更明确的规则来弥补。反过来，如果 Skill 写得模棱两可，哪怕换成最强的模型，产出的稳定性也会很差。

5. 8 个 Skill 串联实操：从一条需求到一次发版

5.1 完整跑通一个端到端示例

光说不练是假把式。下面我用一个简化但完整的业务需求，带你走一遍 8 个 Skill 串联的全过程。这条需求是：“支持用户通过手机号验证码登录，并自动创建用户档案。”

阶段一：需求解析（Skill 1）

需求解析器读取这句话，首先识别意图——这里明确是“新增功能”。然后调用预置问题模板，自动展开追问逻辑：

• 用户角色：新用户、注册用户，是否包含第三方登录？
• 业务规则：手机号格式校验规则？验证码有效期？同一手机号多久可以重新发送？
• 数据字段：手机号、验证码、用户状态、创建时间、是否绑定实名？
• 异常场景：手机号已注册、验证码错误次数超限、短信服务暂时不可用？

最终输出结构化的需求卡片，包含 5 条业务规则、4 个用户角色、8 组异常场景，同时生成 12 条 Given-When-Then 验收标准。

阶段二：架构规划（Skill 2）

架构规划师读入需求卡片，识别出核心实体是“用户”和“验证码”。模块划分上，新增“认证服务”，并定义它对“用户服务”的依赖接口——createUserIfNotExists(phone, profile)。技术选型上，会对比 Redis 存验证码和本地内存存储的方案，最终给出一个带 TTL 的 Redis 方案，并标注理由。

阶段三：代码生成（Skill 3）

代码生成器在认证服务模块内生成三层代码：Controller（接收验证码发送/校验/登录三个 POST 接口）、Service（核心业务逻辑）、Repository（用户数据访问）。每层代码都按团队模板输出，同时为三个接口各生成一组基础单元测试。

阶段四：代码评审（Skill 4）

评审官用独立上下文扫描代码，发现两个 Major 级问题：验证码校验接口缺少频率限制（模型没考虑暴力破解风险）、用户手机号在日志里被明文打印（敏感信息泄露风险）。这两条被自动打回，代码生成器修正后重新提交。

阶段五：测试工程（Skill 5）

测试工程师补充了 30 多个额外用例，重点覆盖：手机号正则校验的边界值（11 位 / 12 位 / 含+86 前缀）、验证码过期、重复发送冷却期、并发重复登录请求。

阶段六：链路压测（Skill 6）

链路压测员编排一条“手机号验证码登录 -> 用户档案创建 -> 返回登录态”的端到端链路，按 100、500、1000 并发三档执行。压测结果显示 1000 并发下登录接口 P99 达到 620ms，模型给出的瓶颈判断是 Redis 连接池配置偏小。

阶段七：文档撰写（Skill 7）

把前面的改动整合成一份技术设计文档，梳理这次登录模块的需求和实现思路；同时生成发版说明：新增 3 个接口、8 条规则变更、1 个依赖升级提示。

阶段八：运维观测（Skill 8）

部署到测试环境后，观测员按配置的默认观测周期持续上报日志摘要。某天突然发现验证码发送接口错误率从 0.2% 跳到 4.1%，根因分析给出判断：“短信服务商回调超时导致”，并建议检查上游第三方服务的健康状态。

5.2 串联时的状态管理机制

多 Skill 串联的核心难点，不在单个 Skill 的质量上，而在状态传递。我们的做法是引入一张流程编排表，用 JSON 格式记录每一步的输入输出位置、状态和负责人：

{ "pipeline_id": "pipe_login_20250218", "current_stage": "code_review", "stages": [ {"name": "requirement_parser", "status": "done", "output": "s3://req_cards/pipe_login_20250218.json"}, {"name": "architect_planner", "status": "done", "output": "s3://arch/pipe_login_20250218.json"}, {"name": "code_generator", "status": "done", "output": "git://repo/feature/auth-login"}, {"name": "code_reviewer", "status": "in_progress", "output": null} ], "owner": "arch_lei" }

每个 Skill 执行完之后，都会把结构化产物落到指定位置，并在编排表里更新状态。下一个 Skill 启动时，只需要读编排表，找到上游产物路径即可，完全不依赖模型的“记忆”。这种设计让整个流水线可以随时暂停、续跑，也可以随时插入人工审批节点。

5.3 人工审批节点该设在哪几个关键位置

全自动看起来很美好，但在企业生产环境，全自动直接上线是给自己埋雷。我的经验是在三个位置必须设置人工审批：

第一，架构方案确认。方案错了，代码写得再好也白搭。技术选型、模块拆分这种高影响决策，必须人拍板。

第二，代码合并前。AI 生成的代码可以自动提交到功能分支，但要合并到主干或 release 分支时，必须有具备权限的工程师做一次真实的 review。可以 approve 速度很快，但这道“门”不能省。

第三，发版前。发版是一个高风险动作，即便所有测试都过了，也要有一个正式的人工确认节点。

其他环节，包括需求解析、代码生成、单元测试、压测执行、文档产出、日志观测，都做成自动化。这样人力和 AI 的能力各归其位，团队的吞吐量才能理想地放大。

6. 大模型链路全量压测实操：不只是“压一把看看”

6.1 压测工具链的选型与脚本生成

链路压测的工程化程度，直接决定了结果可信度。我常用的方案有两套：一套是 JMeter，适合企业里已有基础设施、熟悉 Java 生态的团队；另一套是 k6，脚本用 JavaScript 写，对云原生环境更友好，也更容易和前面的代码生成链路打通。

现在有了 Harness 和代码生成器之后，压测脚本本身已经“白菜化”了——你只需要在链路压测员 Skill 里配置好模板，它就能用 k6 语法直接输出压测脚本。举个例子，针对登录接口，自动生成的脚本长这样：

import http from 'k6/http'; import { check, sleep } from 'k6'; export const options = { stages: [ { duration: '1m', target: 50 }, { duration: '2m', target: 200 }, { duration: '2m', target: 500 }, { duration: '2m', target: 1000 }, { duration: '1m', target: 0 }, ], }; export default function () { const phone = `13${String(Math.floor(Math.random() * 1000000000)).padStart(9, '0')}`; const payload = JSON.stringify({ phone, code: '123456' }); const res = http.post('https://staging.internal/api/v1/auth/login', payload, { headers: { 'Content-Type': 'application/json' }, }); check(res, { 'status is 200': (r) => r.status === 200 }); sleep(1); }

自动生成的脚本里还预留了流量梯度，让压测数据能够覆盖不同的负载区间——这比“一把梭跑最大并发”有意义得多，因为你可以从数据里看到系统的劣化曲线，知道什么水位开始崩。

6.2 压测指标读法与瓶颈定位

跑完压测之后，链路压测员会自动生成一份压测报告。最需要关注的指标不要贪多，核心看 5 个：吞吐量（RPS）、P50/P95/P99 延迟、错误率、CPU 使用率、内存使用率。

数据出来之后，第一步不是急着调代码，而是先看瓶颈层级。怎么快速分层定位？我总结了一个简单经验：

• 如果并发升高时 CPU 高但内存低，先怀疑业务逻辑代码的计算效率，看看是不是有重复循环或者不合理的正则回溯。
• 如果内存高但 CPU 低，先往缓存、连接池方面想——是不是对象堆积了，GC 压力上来了。
• 如果应用层各项指标都不高，但延迟全面升高，那瓶颈大概率在下游依赖——数据库、缓存、或者外部接口。这时候要去查数据库慢查询日志，看看有没有全表扫描。

6.3 全链路压测要覆盖中间件和依赖

单独对应用服务做压测，并不能回答“线上扛得住吗”这个问题。真正具有参考价值的，是全链路压测——从网关入口到应用服务，再到消息队列、数据库、Redis、对象存储，整条链路上的所有参与者都打到高压状态。

全链路压测的工程量很大，但在 Harness 体系里可以做到相对自动化。链路压测员这个 Skill 会生成测试计划，自动识别链路涉及的中间件，并为打到外部依赖的流量做打标，防止真实数据被污染。同时，测试数据会用后置清理任务自动回收。

这里有一个关键词：不停机压测。理想状态下，压测任务应该直接趴在现网的影子环境里执行（流量完全隔离，但基础设施是真实的）。等这套流程彻底跑顺之后，你每年大促前就不再需要“压测周”这种大动干戈的操作了——随时可以按一个按钮做一盘全链路压测，而这正是全链路工程化带来的可见回报。

7. 踩坑实录：这些问题我帮你趟过了

7.1 Skill 提示词太长，模型执行变形

Skill 的提示词写得太详尽，长到几万字的时候，模型的后半段几乎就“不认账”了。输出经常出现前面按规则走，后面开始自由发挥的情况。后来我做了两件事解决：

一是把大段提示词里的规则性内容拆到独立的规则文件里，主提示词只保留执行路径和关键约束。二是在每个阶段的输出开头，要求模型先复述一遍“当前阶段必备的三个约束条件”，让它在执行时就主动记住规则。

7.2 上下文窗口溢出，长链路直接瘫痪

8 个 Skill 的串联如果通过传统对话上下文传递，跑到第 5 个 Skill 左右，上下文就可能因超出长度限制而彻底瘫痪。我的解法是：Skill 之间只传递产物路径和数据引用，不传完整内容。每个 Skill 启动时自行加载上游产物文件，整个过程是一个工作流引擎在调度，不是靠模型记忆在接力。

7.3 模型“幻觉”验收标准

在需求解析阶段，模型经常编造一些客户根本没提过的验收标准，比如“支持指纹登录”这种完全不在需求里的功能。这个问题非常隐蔽，因为编出来的内容读起来很合理。

后来我在需求解析器 Skill 里加了一条硬性规则：每一个验收标准都必须能在原始需求文本中找到对应依据，找不到的依据则标记为“建议补充确认项”，而不是直接纳入需求卡片。规则一加，幻觉率下降了大概七八成。

7.4 压测数据虚高

用 k6 跑本机压测的时候，脚本的虚拟用户（VU）数设置有问题会导致数据严重虚高。比如循环里 sleep 时间太短，使得“压测真正打到接口的请求数”远大于目标值。后来我在生成脚本时强制要求，每个虚拟用户都要模拟真实思考时间（随机 1-3 秒），这才让压测数据更贴近真实用户行为。

7.5 Skill 版本与底层模型版本绑定问题

模型升级之后，同一个 Skill 的表现有时反而变差——新模型可能“太聪明”，开始自作主张跳过你预设的步骤。这个问题目前没有一劳永逸的解法，但有三条经验可以缓解：Skill 的版本要记录它适配的模型版本；模型升级之后先跑一遍回归清单，确认核心产出格式不变；关键输出字段用结构化 schema 强校验，格式对不上直接判定失败重新生成。

8. 从 8 个 Skill 到一个 Skill 生态：下一步怎么扩展

8.1 你认为 Skill 是“提示词”，它就是玩具

写 Skill 最容易犯的错，是把它当成一段更长的提示词。实际上，真正的工程化 Skill 应该同时包含以下维度：

• 流程定义：在这个 Skill 内部，模型的执行步骤必须是什么
• 约束清单：模型绝对不能做的事是什么
• 输入输出模板：结构化数据的 schema 是什么
• 质量评估：这个 Skill 生成的输出，如何自动评估好坏
• 故障预案：模型输出质量不达标时，如何自动降级或转人工

这五个维度缺一不可。只有提示词，没有约束、没有评估、没有预案的 Skill，在生产环境中只是一个新形式的“不可控 agent”。

8.2 让 Skill 变成“团队资产”的三种方式

第一是共享仓库化。Skill 定义文件全部纳入代码库管理，走分支、提 MR、过评审，跟业务代码的流程完全一致。每个 Skill 的变更记录中保留“修改人”“修改理由”“影响范围”，这样 Skill 本身也变成了值得追溯的团队资产。

第二是指标化评估。对每个 Skill 建立质量指标：需求解析 Skill 的验收标准覆盖率、代码生成 Skill 的一次通过率、压测 Skill 的瓶颈定位准确率。有了指标，团队才知道哪些 Skill 需要优化，哪里值得投入。

第三是灰度发布。Skill 更新先在一个小比例的任务里试用，与旧版本并行观察。如果新版本 Skill 在指标上明显优于旧版本，再逐步灰度到全量。这个方法同样适用于”底层模型升级“的验证，能最大程度减少不可预期的行为变更对生产链路的冲击。

8.3 从工具链到组织能力的跃迁

把 8 个 Skill 全部落地之后，你会发现真正的变化不是“代码写得快了”，而是团队的组织能力发生了质变：

— 需求流转从过去的“口头沟通 + 文档来回补”，变成结构化卡片全流程追踪；

• 代码审查从“工程师凭经验和感觉看代码”，变成“AI 先过一遍清单，人只看关键风险”；
• 压测这种原本需要专门安排一个工程师节奏冲刺的事，变成一次代码变更的默认动作；
• 线上问题复盘从“靠人工翻日志猜原因”，变成“AI 先给出线索，人验证确认”。

这一整套变化背后，是工程流程的定义权重新回到了工程师手里——AI 不是替代了流程，而是愿意服从流程约束、成为一个高强度执行的执行单元。对我来说，这才是 Harness 工程最有价值的地方。

9. 复盘与心得：这套体系的目标不是“取代工程师”

最近总有人问我一个问题：你把 8 个 Skill 串得这么顺，是不是以后就不需要资深工程师了？我的回答始终是：正好相反。Skill 的目标不是取代工程师，而是把工程师从低阶、重复的工作中解放出来，让他们把时间花在真正重要的事情上——定义流程、评估结果、做关键决策、处理复杂异常。

如果你想在公司里落地 Harness 工程，我的建议是先不要追求 8 个 Skill 一步到位。先选一个痛点最明确的环节（比如代码评审或文档撰写），写好一个 Skill，跑通流程，看到效果，再逐步扩展。这套体系最大的成本不是工具，而是团队认知的转变——大家要慢慢接受“把流程显式化写下来，比让模型自由发挥更可靠”这个观念。

最后分享一个我实际用习惯的细节：写完每一个 Skill 之后，我都会自己扮演“最笨的模型”去走一遍流程。如果我在每一步都需要停下来反复确认“下一步该干嘛”，那这个 Skill 还不够好，得继续拆细。这个“最笨用户测试”法，比任何技术指标都好用——因为工程化体系的底线，是让能力最弱的参与者也不会迷路。这套思路放到未来的 AI 编码体系里也一样适用。