企业级AI Coding实战：用Harness工程与8个Skill构建可控全链路

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 的设计要点。序号Skill 名称输入输出核心工具/能力1需求解析器Requirement Parser业务需求原始文本结构化需求卡片、验收标准关键词识别、意图分类2架构规划师Architect Planner需求卡片组技术方案、模块拆分、接口设计上下文聚合、模板匹配3代码生成器Code Generator模块任务书可运行代码、单元测试多文件生成、依赖分析4代码评审官Code Reviewer代码变更集问题清单、修改建议静态扫描、规范检查5测试工程师Test Engineer代码模块测试用例、覆盖报告边界分析、自动断言6链路压测员Load Runner部署环境信息压测报告、瓶颈分析压测脚本生成、数据采集7文档撰写者Doc Writer代码变更、压测数据发版说明、API 文档信息聚合、模板渲染8运维观测员Ops Observer线上日志、监控指标异常预警、健康报告日志分析、趋势识别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 / MinorBlocking 级问题直接打回让代码生成器重做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.yamlSkill 元信息、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 编码体系里也一样适用。