AI 编程概念 和 Harness 工程实践入门

AI 编程概念与 Harness 工程实践入门

引言：AI 会写代码之后，真正的问题才刚开始

过去几年，AI 编程工具从代码补全、对话式助手，快速发展到能够读文件、改代码、调用命令、运行测试的 Agent。很多团队第一次体验 AI Coding 时，都会有一种强烈感受：它真的能把代码写出来，而且速度很快。

但当 AI 进入真实工程项目后，新的问题会接连出现：

• AI 写得很快，但不一定写得对。
• AI 能理解需求，但容易漏掉历史约束。
• AI 会调用工具，但可能不知道哪些工具有风险。
• AI 能生成大量代码，但团队不一定审得过来。
• AI 今天被纠正的问题，明天换个会话又会再犯。
• AI 在演示项目里很顺，在复杂业务仓里却经常跑偏。

这些问题说明，AI 编程的核心矛盾已经不再是“模型会不会写代码”，而是“如何让模型在真实工程环境里稳定、可控、可验证地工作”。

这正是 Harness Engineering 要解决的问题。

一句话概括：AI 编程不是把需求丢给模型等结果，而是要为模型搭建一套工程化运行轨道，让它在正确上下文、明确边界、自动验证和持续反馈中完成任务。

一、先理解几个基础概念

1. LLM：会“续写”的智能引擎

大语言模型，也就是 LLM，本质上是一个极其强大的文本预测系统。你给它一段输入，它会根据训练中学到的语言、代码、知识和模式，预测接下来最合理的内容。

这听起来像“自动补全”，但当模型足够强时，它可以表现出推理、总结、翻译、规划、代码生成等能力。

不过，模型本身并不知道你的项目结构、团队规范、历史决策、线上事故和业务边界。它只有在当前上下文里看到这些信息，才可能正确使用它们。

所以，AI 编程的第一条规律是：模型能力很重要，但模型看到什么同样重要。

2. Prompt Engineering：把问题说清楚

Prompt Engineering 通常翻译为提示词工程。它解决的是“怎么对模型表达任务”。

比如同样让 AI 写一个登录模块，不同提示会得到完全不同的结果：

写一个登录页面。

这个提示太粗糙，AI 只能按通用经验生成。

请用 Vue 3 + TypeScript 写一个登录页面，包含手机号、验证码、登录按钮，使用项目已有 Button 组件，表单校验失败时展示错误提示，不要引入新的 UI 库。

这个提示就更接近工程任务，因为它明确了技术栈、功能范围、复用要求和限制条件。

Prompt Engineering 的价值在于让模型听懂你的意图。但它有明显边界：即使你说得很清楚，如果模型不知道项目已有组件在哪里，不知道接口契约是什么，不知道团队禁止直接引第三方组件，它依然可能写错。

3. Context Engineering：把信息给对

Context Engineering 解决的是“模型在执行任务时应该知道什么”。

真实项目中的关键知识往往散落在很多地方：代码、README、接口文档、需求单、设计稿、历史 PR、团队规范、线上事故复盘、业务术语表。人类工程师可以靠经验和沟通补齐这些信息，但 AI 不行。AI 只能使用它当前可见或可检索的上下文。

因此，Context Engineering 的核心任务是把正确的信息以合适的粒度提供给模型。

典型做法包括：

• 用 AGENTS.md 或规则文件保存项目协作规范。
• 用 context/ 目录沉淀团队规范、业务知识、历史经验。
• 用服务矩阵或依赖表描述微服务之间的关系。
• 用领域模型描述页面、组件、接口和数据结构。
• 用 RAG 检索系统按需注入知识，而不是把所有文档一次性塞进上下文。
• 用滚动摘要、记忆分层和上下文压缩减少无关信息干扰。

Context Engineering 的目标不是“给得越多越好”，而是“在正确时间给模型最有用的信息”。

4. Agent：能行动的模型

普通聊天模型只会回答问题。Agent 则在模型之外接入了工具，让模型不仅能说，还能做。

一个代码 Agent 通常可以：

• 读取文件。
• 搜索代码。
• 修改文件。
• 运行测试。
• 调用命令行。
• 查看日志。
• 访问浏览器。
• 查询接口文档。
• 调用内部平台。

Agent 的能力来自“模型 + 工具 + 上下文 + 控制流程”。

这也带来风险：工具越强，破坏力越大。一个能写文件的 Agent 可能改错代码；一个能执行命令的 Agent 可能误删文件；一个能访问数据库的 Agent 可能读到不该读的数据。

所以，Agent 不能只靠“模型自觉”，必须有工程边界。

5. Skill：把能力封装成说明书

很多 AI IDE 或 Agent 平台都支持 Skill。Skill 可以理解为一份可复用的任务说明书，通常包含：

• 这个 Skill 适合什么场景。
• 触发后应该遵循什么流程。
• 可以使用哪些工具。
• 需要读取哪些参考资料。
• 输出格式和校验标准是什么。

从底层协议看，Skill 往往不是模型 API 的原生概念。它通常会被应用层转换成几类东西：

• 注入 system 或 developer message 的说明文本。
• 可供模型调用的工具 schema。
• 模型按需读取的 SKILL.md、脚本和参考文件。
• 多轮 tool calling 的执行循环。

换句话说，Skill 的本质是“给 Agent 的可执行工作手册”。

6. Harness：让 AI 稳定工作的工程底座

Harness 原意是马具、挽具，也可以理解为把强大力量接入可控系统的装置。

在 AI 工程里，Harness 指的是包裹在模型外面的整套工程系统。它不替代模型，而是决定模型如何被使用。

一个最简单的公式是：

Agent = Model + Harness

模型提供智能，Harness 让智能变成可靠生产力。

Harness 通常负责：

• 任务如何进入系统。
• 如何拆解需求和规划步骤。
• 哪个 Agent 负责哪类任务。
• 工具如何注册、授权和审计。
• 上下文如何加载、压缩和更新。
• 执行过程如何记录 Trace。
• 失败后如何重试、降级或终止。
• 成本如何控制。
• 质量如何评估。
• 经验如何沉淀到下一次任务。

如果说 Prompt 是“怎么说”，Context 是“给什么信息”，Harness 就是“整个 AI 系统如何可靠运行”。

二、AI 编程的三次工程演进

AI 编程的演进可以粗略分为三层：Prompt Engineering、Context Engineering、Harness Engineering。三者不是替代关系，而是逐层叠加。

1. 第一阶段：Prompt Engineering

这个阶段的核心问题是：如何让模型理解任务？

常见技术包括：

• 角色设定：让模型以资深工程师、测试专家、架构师等身份工作。
• 少样本提示：提供几个输入输出示例。
• 思维链：让模型分步骤推理。
• 结构化输出：要求模型输出 JSON、Markdown 表格或固定模板。
• 任务拆分：把复杂任务拆成多个小提示。

Prompt Engineering 可以显著提升单次交互质量，但它解决不了长期协作、复杂上下文和工程验证问题。

2. 第二阶段：Context Engineering

这个阶段的核心问题是：如何让模型拿到正确知识？

当 AI 进入企业代码库，最大瓶颈通常不是模型不会写代码，而是它不知道项目里的隐性规则。例如：

• 某个接口字段不能改，因为下游强依赖。
• 某个组件必须从项目封装层引用，不能直接从第三方库引用。
• 某个服务分页必须有上限，因为历史上打爆过下游。
• 某类错误码有固定区间。
• 某些页面必须同时兼容 CSR 和 SSR。

这些知识如果只存在于人脑、群聊或旧文档里，AI 就无法稳定遵循。

Context Engineering 会把这些知识沉淀成机器可读的工程资产，例如：

context/team/git.mdlogging.mderror-code.mdproject/order-service/architecture.mdapi.mdexperience/pagination-limit.mdharness-framework/workflow.mdgates.md

它的关键原则是单一事实来源：团队规范、业务知识和历史经验应该放在可版本化、可审查、可追溯的位置，而不是散落在不可控的聊天记录里。

3. 第三阶段：Harness Engineering

这个阶段的核心问题是：如何让 AI 在真实工程流程中稳定交付？

只会 Prompt 和 Context 仍然不够。因为 AI 可能：

• 没有运行测试却声称已经通过。
• 改了公共组件却不知道影响面。
• 遇到错误后反复重试同一个失败方案。
• 上下文太长后忘记早期约束。
• 为了完成任务顺手重构无关代码。
• 生成正确答案但中间用了不合规工具。

Harness Engineering 通过流程、门禁、工具治理、Trace、评估和反馈闭环解决这些问题。

它把 AI 编程从“聊天式协作”升级为“工程化协作”。

三、Harness 的核心模块

一个生产级 Harness 不一定一开始就很复杂，但通常会逐步长出以下模块。

1. 任务编排：让 Agent 出主意，让 Harness 拿决定

很多系统失败，是因为把太多全局控制权交给了模型。

生产级原则是：

Agent 负责局部智能，Harness 负责全局控制。

Agent 可以生成方案、分析代码、写实现、做审查，但 Harness 应该掌握以下决策权：

• 任务生命周期：创建、分析、设计、开发、验证、交付、失败。
• 执行顺序：哪些步骤必须串行，哪些可以并行。
• Agent 路由：哪个任务交给需求分析 Agent，哪个交给代码审查 Agent。
• 失败处理：重试、回滚、降级、跳过还是终止。
• 硬限制：最大步骤数、最大工具调用次数、最大 Token、最大执行时长。

一个常见流程是：

需求输入→ 需求拆分→ 风险审查→ 设计方案→ 方案门禁→ 编码执行→ 代码审查→ 测试验证→ 经验沉淀

这里每一步都可以由 AI 参与，但是否进入下一步，应该由 Harness 的门禁规则决定。

2. 工具治理：工具不是函数，而是权限入口

Agent 的能力很大程度来自工具。工具可以是读文件、写文件、Shell、浏览器、数据库、内部 API、MCP Server 等。

工具治理的核心是 Tool Registry，也就是工具注册中心。

一个工具至少应该描述：

• 工具名称。
• 工具用途。
• 输入参数 schema。
• 输出结构。
• 允许调用的 Agent。
• 风险等级。
• 超时和速率限制。
• 是否需要人工确认。
• 调用日志和审计策略。

高风险工具必须加更严格的边界。例如：

• 删除文件需要人工确认。
• 写数据库需要审批或沙箱环境。
• 外部网络请求需要脱敏检查。
• 执行 Shell 命令需要命令白名单或危险命令拦截。
• 修改配置文件需要额外提示。

MCP 让工具接入变得更标准，但也更容易“能力泛滥”。正确做法不是把 MCP Server 直接暴露给 Agent，而是通过 Tool Registry 做白名单、权限、配额和审计。

3. 上下文治理：不是塞满，而是选准

上下文治理要解决三个问题：

• 模型该知道什么？
• 什么时候知道？
• 以什么形式知道？

一个实用的分层方式是：

L1：每次都必须知道的核心规则L2：特定场景才加载的规则L3：按需检索的参考资料L4：任务执行过程中产生的临时状态

例如：

• 每次都必须遵守的代码红线可以 always apply。
• 提交规范只在 commit 场景加载。
• API 文档只在涉及接口修改时加载。
• 历史事故经验只在相关模块被修改时加载。

这能显著降低 Token 成本，也能减少无关信息干扰。

一个重要经验是：上下文质量通常比上下文数量更重要。太多规则会让模型不知道优先级，太长的历史会造成“中间遗忘”，太多相互冲突的文档会让模型综合出错误结论。

4. 状态与记忆：记住该记的，忘掉该忘的

状态和记忆容易混淆，但二者不同。

状态是当前任务运行需要的信息，例如当前步骤、已修改文件、测试结果、待解决问题。它的生命周期短，重点是一致性。

记忆是跨任务复用的知识，例如用户偏好、团队规范、历史坑、某类问题的解决经验。它的生命周期长，重点是相关性。

推荐拆分为：

Working State：当前步骤临时上下文，任务结束可丢弃。Session State：一次会话内共享状态，可设置 TTL。Execution Log：不可变执行日志，用于审计、回放和评估。Episodic Memory：事件记忆，记录踩坑经验和用户偏好。Semantic Memory：语义记忆，记录业务规则和领域知识。

记忆系统还有一个反直觉但重要的机制：遗忘。

如果只新增不清理，记忆会变得越来越噪声化。实践中可以按访问频次、最近使用时间、重要性和可信度计算保留分数：

• 高价值记忆保留原文。
• 中价值记忆压缩为摘要。
• 低价值或过期记忆归档或删除。

记忆不是仓库，而是花园，需要持续修剪。

5. 质量门禁：让错误死在最便宜的地方

AI 编程最怕错误一路流到代码审查甚至上线阶段。Harness 应该把错误尽可能拦在更早的位置。

常见门禁包括：

• 需求门禁：需求是否明确，验收标准是否完整。
• 设计门禁：方案是否覆盖边界、依赖、风险和回滚。
• 开发门禁：任务拆分是否合理，目标文件是否明确。
• 工具门禁：是否调用高风险工具，是否越权。
• 代码门禁：Lint、类型检查、单元测试、构建是否通过。
• 契约门禁：API、IDL、数据库 schema 是否兼容。
• 追溯门禁：代码变更是否能追溯到需求条目。

门禁应该尽量可机读，而不是“AI 口头说通过”。例如测试结果、schema 校验、脚本输出、审查报告都应该落盘，便于审计。

6. Trace 与可观测性：不要只看答案，要看过程

AI Agent 的错误常常不是最终报错，而是过程偏移。

例如：

• 它调用了错误工具，但最终结果看起来还行。
• 它读取了过期文档，但表达得很自信。
• 它反复调用同一个工具浪费大量 Token。
• 它跳过了测试，却声称已经验证。
• 它在上下文压缩时丢失了关键约束。

所以 Harness 必须记录 Trace：

• 用户原始需求。
• 加载了哪些上下文。
• 生成了哪些计划。
• 调用了哪些工具。
• 工具参数和返回结果是什么。
• 哪些门禁通过或失败。
• 最终输出如何生成。

Trace 的价值不只是排查问题，还可以用于评估、回放、优化 Prompt、改进 Skill、训练团队规则。

7. 评估体系：从结果评估到轨迹评估

普通模型评估通常看最终答案。但 Agent 系统还要看执行过程。

一个成熟的评估体系至少包含四层：

组件评估：单个 Agent 是否选对工具、参数是否合规。轨迹评估：步骤是否必要、顺序是否合理、是否重复调用。任务评估：最终结果是否满足用户目标。业务评估：用户是否采纳、返工率如何、单位成本是多少。

LLM-as-Judge 可以评估表达质量、逻辑完整性和开放式输出，但不能替代确定性检查。代码能不能运行、SQL 结果是否正确、权限是否合规、schema 是否匹配，应该优先用程序判断。

对 AI 编程来说，Eval 就是测试体系。每次改规则、换模型、加工具、改 Skill，都应该跑回归评估。

8. 成本控制：Token Budget 是生命线

Multi-Agent 和长任务很容易烧 Token。原因包括：

• 每个 Agent 都有系统提示词。
• 每轮工具结果都会进入上下文。
• 多 Agent 会复制部分历史。
• 失败后会重试。
• 长会话会积累大量无关信息。
• 规则和 Skill 如果 always apply，会产生固定成本。

Token 控制不是最后看账单，而应该进入调度层。

常见策略包括：

• 简单任务用小模型，复杂推理用强模型。
• 简单修改不用加载完整大型 Skill。
• 将规则分为核心规则和按需规则。
• 长对话达到阈值后 compact。
• 工具输出做摘要，不把大段日志全部塞回模型。
• 流程型 Skill 尽量脚本化，减少模型二次推理。
• 对任务设置 max tokens、max tool calls 和 max duration。

一个简单但实用的原则是：昂贵模型用于关键判断，便宜模型用于低风险执行，确定性脚本用于可程序化的检查。

四、AI 编程工程实践：从个人到团队

1. 个人使用：从“让 AI 写”变成“让 AI 按轨道写”

个人使用 AI 编程时，可以先建立几个习惯：

• 每次只做一个主题，避免一个对话混杂多个需求。
• 尽量用 @文件:行号 指定位置，减少 AI 搜索成本。
• 明确现象、预期、限制条件和验收标准。
• 让 AI 先读代码再改代码。
• 让 AI 改完后运行实际测试，而不是自评。
• 对复杂任务先让 AI 输出方案，再批准执行。
• 长会话及时 compact 或开启新会话。

一个好的 Bug 修复提示可以这样写：

@src/pages/Login.vue:86现象：点击发送验证码后 loading 一直不恢复。预期：请求成功、失败、提前返回三种路径都必须恢复 loading。限制：不要重构整个登录流程，只修改验证码发送逻辑。验证：请运行相关单元测试，并说明覆盖了哪些路径。

这样的提示同时给了位置、现象、预期、边界和验证方式，AI 的输出方差会明显降低。

2. 项目改造：让代码库更适合 AI 协作

很多项目不是 AI 写不好，而是项目本身不适合 AI 读懂。

适合 AI 协作的代码库通常具备以下特征：

• 规则机器可读。
• 命名显式可搜索。
• 组件入口收敛。
• 业务术语统一。
• 依赖关系结构化。
• 测试和门禁可自动运行。
• 历史经验能沉淀到仓库。

例如前端项目可以做这些改造：

openspec/rules/coding.mdcstyle.mdccomponent-usage.mdcsrc/components/ui/Button.tsxModal.tsxsrc/themes/tokens/color.tsspacing.tsradius.ts

并通过 ESLint 禁止业务代码直接引用底层第三方组件：

业务代码只能从 src/components/ui 引入 Button，不能直接从 antd 引入。

这样 AI 就不会在多个“都能用”的路径之间乱选。

3. 团队实践：Knowledge as Code

团队级 Harness 的一个关键思想是 Knowledge as Code，即知识也像代码一样管理。

这意味着：

• 规范写在仓库里，而不是只写在文档平台。
• 规则可以被 code review。
• 需求、设计、任务、测试报告可以形成追溯链。
• 经验文件可以版本化和回滚。
• 不同 AI 工具可以从同一份规范生成自己的本地配置。

一个团队级目录可能长这样：

AGENTS.md.codebuddy/skills/agents/commands/hooks/context/team/harness-framework/project/.service-matrix/dependencies.yamlrequirements/REQ-2026-001/requirement.mddesign.mdtasks.jsonreview-report.mddelivery.md

这里的重点不是具体目录名，而是把流程、知识、门禁、经验和工具配置都变成可维护资产。

4. 多 Agent 分工：把复杂任务拆给不同角色

对于复杂任务，不建议让一个 Agent 从头干到尾。更好的方式是角色分工。

常见角色包括：

• Requirement Analyst：需求分析，识别目标和非目标。
• Planner：设计方案，拆分任务和风险。
• Reader：只读代码，收集上下文，不修改文件。
• Executor：按方案执行代码修改。
• Reviewer：独立审查，不参与生成。
• Tester：运行测试并分析失败原因。
• Knowledge Curator：把新经验沉淀到知识库。

关键规则是：生成者和评估者要隔离。让写代码的 Agent 自己评价代码，容易出现过度自信。独立 Reviewer 可以显著降低漏检。

还有一条实践经验：所有需要用户确认的交互，应该由主流程处理，子 Agent 只返回结果，不直接卡住用户确认。否则容易出现多 Agent 死锁。

5. 契约化开发：用领域模型减少猜测

在多端、多服务、复杂业务系统中，仅靠 AI 扫代码不够稳定。更好的方式是把业务抽象成契约。

例如多端前端项目可以定义四层领域模型：

pages.json：页面有哪些。ui-modules.json：页面由哪些模块组成。api-layer.json：接口和调用契约是什么。data-layer.json：核心数据结构是什么。glossary.json：业务术语如何统一。

通用契约描述“是什么”，项目映射描述“在哪里、怎么实现”。

{"HomePage": {"concept": "首页","web": "src/pages/index.tsx","tv": "src/pages/home.tsx","mobile": "src/pages/home/index.vue"}}

这样 AI 不需要在海量代码里猜“首页在哪里”，也不需要猜不同端的实现差异。

契约化的好处是：

• 新项目接入更快。
• 多端一致性更容易检查。
• AI 生成代码更稳定。
• 测试和门禁可以基于契约自动生成。

6. Self-Refinement：让每次纠错都变成资产

AI 没有天然的跨会话记忆。用户今天纠正了它，如果不沉淀，下一次它可能继续犯。

Self-Refinement 的做法是建立一个闭环：

发现问题→ 分析原因→ 提炼规则或经验→ 写入 context/ 或 rules/→ 下一次任务自动加载或按需检索→ 避免重复犯错

例如一次事故发现“所有分页接口必须设置上限”，就应该沉淀为经验：

context/project/order-service/experience/pagination-limit.md

内容包括：

• 问题背景。
• 触发条件。
• 错误写法。
• 推荐写法。
• 检查方式。
• 适用模块。

这样知识不再只存在于某次对话里，而成为团队资产。

五、一个可落地的 Harness 建设路线图

不建议一开始就搭一个庞大的平台。Harness 应该从小闭环开始，逐步增强。

Phase 1：个人和小团队起步

目标是让 AI 不再“凭感觉写”。

建议建设：

• 一个 AGENTS.md，写清项目基本规则。
• 一组核心规则文件，控制在少量高价值规则。
• 一个简单的需求到代码流程。
• 基础验证命令，如 lint、type-check、test、build。
• 一个经验目录，用来沉淀常见坑。

最低可用流程：

读需求 → 搜代码 → 出方案 → 用户确认 → 修改代码 → 跑测试 → 总结经验

Phase 2：项目级工程化

目标是让 AI 能在真实项目里稳定交付。

建议建设：

• Skill：封装常见流程，如新功能、Bug 修复、提交、代码审查。
• Hooks：拦截危险命令、调试残留、大文件写入、配置修改。
• 上下文分层：核心规则 always apply，场景规则按需加载。
• 质量门禁：需求、设计、开发、测试各阶段都有检查点。
• Trace：记录关键工具调用和验证结果。

此阶段的重点是把“口头约定”变成“可执行约束”。

Phase 3：团队级协作体系

目标是让 AI 成为团队工程流程的一部分。

建议建设：

• 统一的知识目录和规范仓库。
• 多 Agent 分工机制。
• 服务矩阵或领域模型。
• 跨仓、跨服务分支和追溯规则。
• 自动化评估和回归数据集。
• Token 成本看板。
• MCP 工具治理和审计。

此阶段的重点是团队规模化，不再依赖某个会用 AI 的个人。

Phase 4：持续优化和自进化

目标是让 Harness 自己也可以被评估、迭代和回滚。

建议建设：

• Ground Truth 测试集。
• Dev/Holdout 分层评估。
• 每次改规则或 Skill 都跑回归。
• 用 Trace 诊断失败案例。
• 对规则、Prompt、Skill 做版本化管理。
• 对无效或过期记忆定期归档。

这个阶段的思想类似训练模型：你不再手工凭感觉调 Skill，而是用数据、评估和门控推动它迭代。

六、常见误区

误区 1：只要换更强模型就够了

强模型当然重要，但很多问题不是模型能力不足，而是上下文、工具边界和验证机制不足。

同一个模型，在不同 Harness 下表现可能差异很大。模型是发动机，Harness 是方向盘、刹车、仪表盘和道路规则。

误区 2：规则越多越好

规则有成本。每条 always apply 的规则都会占用上下文，还可能和其他规则冲突。

好的规则应该：

• 来自真实问题。
• 表达明确。
• 可执行或可检查。
• 有优先级。
• 能按场景加载。

误区 3：让 AI 自己判断是否完成就行

AI 很容易过度自信。它可能没有跑测试却说“应该没问题”。

生产级流程应该把“声称完成”变成“验证完成”。验证结果要来自命令、测试、日志、截图、schema 校验或审查报告。

误区 4：把所有文档都塞给 AI

上下文不是越大越好。无关信息会稀释注意力，冲突文档会误导模型，过长历史会增加成本并降低遵循度。

更好的方式是索引化、分层化、按需加载。

误区 5：AI 生成快，所以可以少做设计

AI 让编码变快，但也让错误变快。如果没有设计和门禁，错误会以更高速度进入代码库。

越是复杂任务，越应该先让 AI 输出方案，并在编码前确认边界。

误区 6：Harness 是大公司才需要的东西

小团队同样需要 Harness，只是形态可以很轻。

一个 AGENTS.md、几条高价值规则、一个固定开发流程、几个验证命令，就是最小 Harness。

七、给工程团队的实践清单

1. 先做规则盘点

把团队反复纠正 AI 的问题列出来，优先沉淀成规则。

例如：

• 禁止直接引用底层 UI 库。
• 修改公共组件前必须分析引用方。
• 异步 loading 必须覆盖成功、失败、提前返回路径。
• 生成代码后必须运行指定测试。
• 禁止在业务代码中硬编码调试开关。

2. 建立单一事实来源

确定哪些文件是规范源头，避免规则散落。

例如：

AGENTS.md：全局协作规则。context/team/：团队级规范。context/project/：项目级知识。rules/：AI 工具可加载的规则。skills/：可复用流程。

3. 把高频流程封装成 Skill

优先封装这些流程：

• Bug 修复。
• 新功能开发。
• 代码审查。
• 提交信息生成。
• 接口契约同步。
• 设计稿转代码。
• 需求拆分。
• 经验沉淀。

Skill 的价值不是写长提示，而是让流程稳定复用。

4. 加最少但关键的 Hooks

Hooks 适合拦截那些“不能靠模型自觉”的问题。

推荐先做：

• 危险命令拦截。
• 调试残留检查。
• 大文件写入提醒。
• 配置文件修改确认。
• 公共组件影响面分析。
• 停止前自动提示运行质量检查。

5. 用评估数据驱动改进

不要只凭感觉判断 Harness 好不好。

可以记录：

• 首次通过率。
• 返工次数。
• 平均 Token 消耗。
• 平均工具调用次数。
• 测试失败类型。
• 审查发现问题数。
• 重复问题复发率。

当你能看到这些指标，AI 编程才从“玄学调参”进入“工程优化”。

结语：AI 编程的未来，是人掌舵，Agent 执行

AI 编程不会让软件工程消失，反而会把软件工程的重要性放大。

过去，工程师的价值很大一部分体现在“亲手写代码”。现在，越来越多代码可以由 AI 生成，工程师的价值正在上移：

• 定义清楚问题。
• 设计合理架构。
• 提供可信上下文。
• 设定工具边界。
• 建立验证闭环。
• 判断关键取舍。
• 把经验沉淀为系统能力。

这就是“Human Steer, Agents Execute”：人类掌舵，Agent 执行。

Prompt Engineering 让我们学会如何对 AI 表达意图。Context Engineering 让我们学会如何给 AI 提供知识。Harness Engineering 则让我们学会如何把 AI 放进真实工程系统，让它稳定、可控、可审计、可演进地工作。

未来的竞争，不是谁能让 AI 写出更多代码，而是谁能设计出更好的工程系统，让 AI 写出的代码更可靠、更便宜、更可维护。

没有 Harness，AI 编程只是一次次聪明的即兴表演。有了 Harness，AI 才能成为真正可持续的工程生产力。