Harness Engineering从AI 辅助到驾驭 AI的工程效能革命这篇文章你会得到什么我们学了怎么开发 Skill把工程经验教给 AI。但单个 Skill 只是一个技能点。如果把 Rule、Skill、Hook、Subagent系统化地组合起来你就不再是被 AI 辅助写代码而是在驾驭 AI 做工程。这就是Harness Engineering驾驭工程——一种系统化利用 AI 能力来放大工程效能的方法论。大多数人用 AI 的方式停留在对话式遇到问题问一下 AI写段代码让它补全。这就像有一台挖掘机你只用它的铲子当凳子坐。今天要讲的是怎么真正开上这台挖掘机。认知转变三个层次的 AI 使用L1被动使用——“AI 帮我写代码”特征遇到问题才想起用 AI主要用自动补全和问答AI 输出直接复制粘贴不怎么审查没有任何定制化配置这是大多数人的状态。AI 是一个比 Google 方便一点的搜索工具。L2主动指挥——“我指挥 AI 做事”特征会写结构化 Prompt 引导 AI用 AI 做 Code Review、写测试、生成文档配置了一些 Rule 约束 AI 行为开始用 AI 处理重复性工作这一层已经比大多数人强了。你知道怎么让 AI 做事但还是每次都要手动指挥。L3系统化驾驭——“我建了一套 AI 基础设施”特征Rule Skill Hook Subagent 形成完整体系AI 自动守护代码质量无需手动触发工程经验持续沉淀为 AI 可执行的知识整个开发流程都有 AI 参与从需求到部署这一层的核心转变是不再是你用 AI而是你的 AI 基础设施在替你工作。三层对比维度L1 被动使用L2 主动指挥L3 系统化驾驭触发方式遇到问题才用主动发起自动 主动AI 角色搜索替代品执行助手工程基础设施知识沉淀无在对话中在 Rule/Skill 中一致性低中高团队效应个人技巧个人经验团队资产效能放大1.2x2-3x5-10x四大 AI 基础设施要从 L2 跃升到 L3核心是建立四层 AI 基础设施。这四层与上一篇讲的 Cursor 扩展机制一一对应但这里从工程效能的角度来理解它们的组合。第一层Rules约束层Rules 定义 AI 的行为边界和代码规范。它们是被动生效的——不需要你触发只要条件匹配就自动应用。工程效能价值确保 AI 生成的代码从一开始就符合团队规范减少 Code Review 的返工。# .cursor/rules/typescript-standards.mdc---description:TypeScript 编码规范写 TS 代码时自动应用globs:**/*.ts,**/*.tsxalwaysApply:false---# TypeScript Standards-禁止 any用 unknown 类型守卫-async 函数必须有 try/catch-组件 props 定义 interface不用 inline type-工具函数必须有 JSDoc 示例# .cursor/rules/git-commit.mdc---description:Git commit 规范alwaysApply:true---# Commit Convention-使用 Conventional Commits:type(scope):description-type:feat|fix|refactor|test|docs|chore-description 用英文不超过 72 字符-body 说明 why不只是 what关键实践一个关注点一个 Rule不要写超大 Ruleglobs精确匹配避免alwaysApply: true泛滥定期 Review Rule 是否过时第二层Skills能力层Skills 是 AI 的技能包——教它完成特定任务。详细开发方法见上一篇。工程效能价值把团队的隐性知识标准化一次编写永久执行。常见的 Skill 设置~/.cursor/skills/ # 个人技能 ├── deploy-project/ # 项目部署 ├── git-workflow/ # Git 工作流 └── tech-writing/ # 技术写作风格 .cursor/skills/ # 项目技能 ├── api-standards/ # API 设计规范 ├── db-migration/ # 数据库迁移 └── incident-response/ # 故障响应流程第三层Hooks守护层Hooks 是自动触发的守卫——在特定事件发生时自动执行不需要你记得去做。工程效能价值把别忘了做 X变成系统自动帮你做 X。{version:1,hooks:{afterFileEdit:[{command:.cursor/hooks/auto-format.sh,matcher:Write}],beforeShellExecution:[{command:.cursor/hooks/safety-check.sh,matcher:rm|drop|delete|truncate,failClosed:true}]}}常见 Hook 场景事件Hook作用afterFileEditauto-format保存后自动格式化beforeShellExecutionsafety-check拦截危险命令afterShellExecutionaudit-log记录所有执行的命令stopsummary-reportAgent 结束时生成总结第四层Subagents专家层Subagents 是独立的 AI 专家——有自己的上下文和专业知识。工程效能价值复杂任务委派给专家主对话保持轻量。# .cursor/agents/security-reviewer.md --- name: security-reviewer description: - 安全审查专家。在涉及认证、授权、数据库操作、文件上传、 用户输入处理时自动触发。 --- 你是安全审查专家重点关注 ## 审查清单 - SQL 注入参数化查询 vs 字符串拼接 - XSS用户输入是否经过转义 - CSRF表单操作是否有 token - 认证JWT 是否正确验证 - 授权是否检查了用户权限 - 文件上传是否限制类型和大小 - 敏感数据日志中是否有密钥/密码 ## 输出格式 - CRITICAL: 必须修复有安全漏洞 - WARNING: 建议修复潜在风险 - INFO: 最佳实践建议四层协同示例假设你说了一句“帮我加一个用户注册接口”。你的指令 → 帮我加一个用户注册接口 │ ▼ Rule 层自动约束 ├─ TypeScript 规范函数式、有类型 ├─ API 规范RESTful、统一错误格式 └─ Git 规范commit 用 conventional 格式 │ ▼ Skill 层执行流程 └─ api-standards Skill ├─ 生成 POST /api/users endpoint ├─ 定义 CreateUserDTO interface ├─ 实现 validation error handling └─ 生成对应的 unit test │ ▼ Hook 层自动守护 ├─ afterFileEdit → auto-format自动格式化 └─ beforeShellExecution → safety-check拦截危险命令 │ ▼ Subagent 层专家审查 └─ security-reviewer 自动审查 ├─ 密码是否 hash 存储 ├─ 输入是否做了校验 └─ SQL 是否参数化一句话指令四层基础设施自动协作。这就是 L3 驾驭的威力。驾驭模式一AI 驱动的全链路开发传统流程 vs AI 驱动流程阶段传统方式AI 驱动方式需求分析手动拆解AI 辅助拆解为技术任务方案设计手动写设计文档AI 生成初版 你审查修改编码手敲 / 补全AI 生成 Rule 约束 你审查Code Review同事审查AI 初审 同事终审测试手写AI 生成测试用例 你补充边界文档事后补AI 同步生成Commit手写 messageAI 根据 diff 生成部署手动执行Skill 一键部署一个实际的开发循环1. 需求输入 需要一个文件上传功能支持图片和 PDF最大 10MB 2. AI 拆解任务你审查确认 ├─ 后端upload API 文件校验 存储 ├─ 前端拖拽上传组件 进度显示 └─ 测试上传成功 / 超大文件 / 非法类型 3. 逐项实现Rule 自动约束代码规范 ├─ AI 生成代码 → 你审查 → 修改 └─ 每次修改 → Hook 自动格式化 4. 安全审查Subagent 自动介入 └─ security-reviewer 检查文件上传安全 5. 测试生成 └─ AI 生成 unit integration tests 6. 提交 └─ AI 根据 diff 生成 commit message 7. 部署 └─ deploy Skill 一键发布关键你的角色从执行者变成了决策者和审查者。AI 做执行你把关质量。驾驭模式二质量守护自动化痛点代码质量靠人盯着总有疏漏Code Review 赶时间就走过场Lint 规则配了但总有人// eslint-disable安全漏洞在 Review 时不一定能发现测试覆盖率达标但测试质量堪忧AI 质量守护体系建立三道防线第一道编码时——Rule 实时约束AI 在写代码的同时就已经受到 Rule 约束从源头减少问题。第二道提交时——Hook 自动检查{version:1,hooks:{beforeShellExecution:[{command:.cursor/hooks/pre-commit-check.sh,matcher:git commit}]}}pre-commit-check.sh可以运行 Lint 检查运行类型检查检查是否有console.log残留检查是否有 TODO 未处理第三道Review 时——AI Review Pipeline在 CI 中接入 AI Code Review 工具比如ai-review-pipeline对每个 PR 自动逐文件审查代码变更生成审查报告Critical / Warning / Info发现问题自动提交修复建议生成 HTML 报告方便人工复审# .github/workflows/ai-review.ymlname:AI Code Reviewon:[pull_request]jobs:review:runs-on:ubuntu-lateststeps:-uses:actions/checkoutv4-run:npx ai-review-pipeline--modereview--formathtml三道防线层层把关编码时预防 → 提交时拦截 → Review 时兜底。驾驭模式三知识飞轮这是 L3 最核心的模式。它让你的 AI 基础设施越用越强。飞轮循环┌─────────────────────────┐ │ 1. 日常开发中发现模式 │ │ 每次部署都要做这几步 │ └───────────┬─────────────┘ ▼ ┌─────────────────────────┐ │ 2. 沉淀为 Rule/Skill │ │ 写成 SKILL.md 或 .mdc │ └───────────┬─────────────┘ ▼ ┌─────────────────────────┐ │ 3. AI 自动应用 │ │ 下次触发自动执行 │ └───────────┬─────────────┘ ▼ ┌─────────────────────────┐ │ 4. 使用中发现改进点 │ │ 这个步骤还漏了 XX │ └───────────┬─────────────┘ │ └──────→ 回到 1实际案例第一周手动告诉 AI 部署命令 ssh 到服务器cd /var/www/blog git pullpnpm installpnpm build第二周发现重复写成 Skill--- name: deploy-blog description: Deploy blog to server... --- # 部署流程 1. SSH to server 2. git pull 3. pnpm install --frozen-lockfile 4. pnpm build第三周用了几次发现问题有时候 build 失败忘了回滚nvm 环境没加载导致 node 找不到更新 Skill加上 nvm 环境加载和错误处理。第四周加 Hook 自动守护部署前自动检查本地是否有未提交的代码部署后自动检查服务是否正常响应两个月后一套完善的部署体系一句部署博客搞定一切自动确认 → 自动执行 → 自动验证新人入职直接用零学习成本这就是飞轮使用 → 发现问题 → 优化 → 更好地使用。每一次使用都在让系统变得更好。知识沉淀的时机什么时候该把经验沉淀为 Rule/Skill信号沉淀为第二次跟 AI 说同样的话SkillAI 生成的代码每次都犯同一个错Rule某个检查总是忘记做Hook某类任务需要专门的知识Subagent经验法则重复两次就沉淀。第一次是学习第二次是信号第三次就是浪费。度量 AI 驾驭成熟度团队 AI 成熟度模型级别特征度量指标L1 初始个别人用 AIAI 工具使用率 30%L2 受管有基础 RuleRule 覆盖率 50%AI 代码采纳率 40%L3 定义Rule Skill 体系化Skill 数量 10重复任务自动化率 70%L4 量化有度量有改进AI 代码贡献率 50%Bug 率下降 30%L5 优化知识飞轮运转Skill 月更新率 20%新人上手时间减半关键度量指标效率指标AI 代码采纳率 AI 生成并被保留的代码行数 / 总新增代码行数 重复任务自动化率 Skill 自动完成的任务数 / 总重复任务数 部署频率提升 当前部署频率 / 引入 AI 前部署频率质量指标AI Review 发现率 AI Review 发现的问题数 / 总问题数 Bug 逃逸率 线上 Bug 数 / 总提交数 代码规范符合率 通过 Rule 检查的文件比例知识沉淀指标Skill 覆盖率 有对应 Skill 的工作流数 / 总工作流数 Rule 活跃度 最近 30 天被触发的 Rule 数 / 总 Rule 数 知识更新频率 Rule/Skill 月更新次数简单的度量脚本importsubprocessimportjsonfrompathlibimportPathfromdatetimeimportdatetime,timedeltadefmeasure_ai_maturity(project_path:str):度量项目的 AI 驾驭成熟度projectPath(project_path)cursor_dirproject/.cursorruleslist((cursor_dir/rules).glob(*.mdc))if(cursor_dir/rules).exists()else[]skillslist((cursor_dir/skills).glob(*/SKILL.md))if(cursor_dir/skills).exists()else[]hooks_filecursor_dir/hooks.jsonagentslist((cursor_dir/agents).glob(*.md))if(cursor_dir/agents).exists()else[]hook_count0ifhooks_file.exists():hooks_datajson.loads(hooks_file.read_text())forevent_hooksinhooks_data.get(hooks,{}).values():hook_countlen(event_hooks)thirty_days_agodatetime.now()-timedelta(days30)recent_rulessum(1forrinrulesifdatetime.fromtimestamp(r.stat().st_mtime)thirty_days_ago)report{rules:len(rules),skills:len(skills),hooks:hook_count,subagents:len(agents),total_components:len(rules)len(skills)hook_countlen(agents),rules_updated_last_30d:recent_rules,rule_activity_rate:f{recent_rules/max(len(rules),1)*100:.0f}%,}totalreport[total_components]iftotal0:report[level]L1 - 初始eliftotal5:report[level]L2 - 受管eliftotal15:report[level]L3 - 定义eliftotal30:report[level]L4 - 量化else:report[level]L5 - 优化returnreportif__name____main__:importsys pathsys.argv[1]iflen(sys.argv)1else.resultmeasure_ai_maturity(path)print(json.dumps(result,indent2,ensure_asciiFalse))运行python measure_maturity.py /path/to/project输出{rules:8,skills:5,hooks:3,subagents:2,total_components:18,rules_updated_last_30d:3,rule_activity_rate:38%,level:L4 - 量化}避坑过度依赖 vs 有效驾驭过度依赖的信号信号说明AI 写的代码不看就合并失去了质量把关离开 AI 不会写代码了基础能力退化AI 出错不知道怎么修丧失了理解力所有决策都交给 AI放弃了判断力有效驾驭的原则1. AI 做执行你做决策✅ 正确姿势 - AI 生成代码 → 你审查逻辑、性能、安全 - AI 提出方案 → 你评估取舍 - AI 做 Review → 你做最终判断 ❌ 错误姿势 - AI 说什么就做什么 - AI 生成的代码不看直接用 - 遇到问题只会问 AI不自己思考2. 保持核心能力即使有了 AI这些能力不能丢架构设计AI 不理解你的业务上下文问题诊断AI 经常在复杂 Bug 上绕弯路代码审查AI 可能引入微妙的逻辑错误技术决策AI 不知道团队的历史债务和约束3. 渐进式信任第一阶段AI 做 → 你全部审查 第二阶段AI 做 → 你抽查 自动测试 第三阶段AI 做简单任务 → 自动化验证 → 你审查复杂任务信任是逐步建立的。先在低风险任务上验证 AI 的可靠性再逐步扩大授权范围。团队落地路线图Phase 1基础建设1-2 周目标建立最基本的 AI 约束和能力。.cursor/ ├── rules/ │ ├── code-standards.mdc # 编码规范 │ ├── git-conventions.mdc # Git 规范 │ └── security-basics.mdc # 基础安全规范 └── skills/ └── deploy/ # 部署流程 └── SKILL.md关键动作梳理团队最核心的编码规范转化为 Rule把最高频的重复操作写成第一个 Skill团队内部做一次 AI 工具使用培训Phase 2流程贯通3-4 周目标AI 参与开发全流程。.cursor/ ├── rules/ │ ├── code-standards.mdc │ ├── git-conventions.mdc │ ├── security-basics.mdc │ ├── api-design.mdc # API 设计规范 │ └── test-requirements.mdc # 测试要求 ├── skills/ │ ├── deploy/ │ ├── pr-workflow/ # PR 工作流 │ └── incident-response/ # 故障响应 ├── hooks.json # 自动化守护 └── agents/ └── security-reviewer.md # 安全审查专家关键动作Hook 接入自动格式化和安全检查建立 AI Code Review 流水线Subagent 覆盖安全审查Phase 3知识飞轮持续目标系统持续自我优化。关键动作建立 Skill 更新机制谁发现问题谁更新月度 Review 所有 Rule/Skill 的有效性度量 AI 效能指标持续优化新人入职以 Skill 为导航加速上手从个人到团队推广策略先自己用起来不要等团队统一决策。先在自己的开发中实践配几条 Rule写两个 Skill用起来积累效果数据用数据说话自从用了部署 Skill - 部署时间从 15 分钟降到 2 分钟 - 部署失败率从 20% 降到 0% - 新人第一天就能独立部署找同盟找 1-2 个对 AI 感兴趣的同事一起搞。三个人的实践比一个人的布道有说服力。提供脚手架不要让每个人从零开始。提供模板 Rule 和 Skill配置指南常见问题 FAQ降低上手门槛才能形成普及。总结Harness Engineering 的核心是一句话不要只用AI要建一套系统来驾驭AI。层级做法效果L1 被动使用遇到问题才问 AI略有提效L2 主动指挥结构化 Prompt 主动安排明显提效L3 系统化驾驭Rule Skill Hook Subagent效能革命关键行动先建约束Rule确保 AI 产出符合标准再建能力Skill教 AI 做重复性工作加上守护Hook自动化的质量关卡引入专家Subagent复杂任务专人负责启动飞轮使用 → 发现 → 沉淀 → 更好地使用别等完美方案。今天就开始写第一条 Rule、第一个 Skill。用起来你就能感受到从AI 辅助到驾驭 AI的质变。讨论话题你的团队在 AI 驾驭成熟度上处于哪一层有哪些 AI 基础设施是你想建但还没建的评论区聊聊。