写在 AI Engineering 系列开始之前

从 2021 年开始系统学习 AI 到现在，我越来越确信：AI 带来的变化，不只是多了一个可以聊天的工具，而是我们获取知识、处理信息、完成工作和开发产品的方式正在被重新设计。

这些年，我陆续学习和实践了机器学习、深度学习、大语言模型、RAG、AI Agent、AI 编程等相关技术。最初关注的是模型“能做什么”，后来关注点逐渐转向“怎样让它可靠地完成任务”。

与此同时，AI 的应用已经从演示性质的问答，发展到文档处理、图像生成、PPT 制作、数据分析、代码开发、软件测试和产品构建。技术越来越成熟，工具越来越丰富，真正困难的问题也从“AI 会不会”变成了：

应该在什么场景使用 AI？
怎样把任务、上下文和资料准确地交给 AI？
怎样选择模型、Agent、Skills、MCP 和 Harness？
怎样验证 AI 生成的结果，而不是盲目接受？
怎样把一次有效的尝试，变成稳定、可复用的工作流程？

这也是我决定开始维护这个系列的原因。

一、为什么要做这个系列

我目前从事软件测试工程相关工作。测试本身就是一项需要大量理解、分析、设计、执行和验证的工作：理解需求、设计测试场景、准备数据、执行接口或 UI 测试、定位失败原因、整理报告，并与研发和产品不断沟通。

这些工作中，有不少环节都可以借助 AI 提升效率。例如：

从需求文档中提取业务规则、风险点和测试范围；
辅助生成测试点、测试用例和边界条件；
分析日志、接口响应和失败记录；
整理会议纪要、报告和技术文档；
生成脚本、补充测试代码并协助代码审查；
将重复的工作步骤沉淀为 Prompt、Rules、Skills 或 Agent 工作流。

但实际使用之后也会发现，AI 并不是一个“输入一句话就自动得到正确答案”的万能工具。提示词不清楚、上下文不完整、工具权限不合理、缺少结果验证，都可能让一次看似高效的尝试产生新的返工。

因此，这个系列不会只介绍某个模型或某款产品的功能，也不会只追逐最新名词。我更希望沿着一条完整路径，记录自己对 AI 技术的理解、使用经验、失败教训和工程实践：

从理解技术为什么出现，到掌握工具怎样使用，再到把 AI 真正放进工作流程和产品开发中。

上图中的三条线，也是整个系列的基本组织方式：

技术演进线：理解 AI、LLM、Reasoning、Tool Calling、Agent 和 Harness 之间的关系；
产品实战线：从 Chat、RAG 和工具调用，逐步走向业务 Agent、评估与平台化；
工程方法线：从 Prompt Engineering、Context Engineering，走向 Skills、Vibe Coding、SDD 和 Agentic Software Engineering。

它们不是互相独立的三组名词，而是会在真实项目中不断交叉：技术提供能力，产品定义价值，工程方法保证结果能够稳定交付。

二、第一篇章：基础理论——看懂 AI 技术为什么这样演变

如果只从今天的大模型和 Agent 开始学习，很容易记住很多术语，却不清楚它们分别解决了什么问题。

因此，系列的第一篇章会回到技术演变过程，从人工智能、机器学习和深度学习讲起，逐步梳理 Transformer、Foundation Model、LLM、推理模型、工具调用、Agent 与 Agent Engineering。

这一部分重点不是推导所有数学公式，而是建立一套能够长期使用的技术认知：

机器学习、深度学习和大语言模型是什么关系；
Transformer 为什么成为大模型的重要基础；
Token、Embedding、Context 和生成式推理如何协同；
RAG、Tool Calling 和 Agent 分别解决什么问题；
为什么模型能力增强之后，仍然需要 Context、Memory、Tools 和 Runtime；
为什么复杂 Agent 最终需要 Harness、评估、可观测性和安全边界。

每遇到一个新概念，我都会尽量回答三个问题：

它为什么出现？
它解决了什么问题？
它与前后技术有什么关系？

理解这条演进路线之后，我们面对新的模型、框架和产品时，就不会只看宣传名称，而能判断它位于哪一层、补充了什么能力，以及是否适合自己的任务。

三、第二篇章：工具实战——让 AI 真正进入日常工作

知道原理并不等于能够提高效率。第二篇章会从真实任务出发，关注 AI 工具如何使用、怎样组合，以及最终能否交付可验证的结果。

实战内容将覆盖几类常见工作：

1. 文档与知识处理

长文档阅读、摘要和结构化提取；
多文档对比、资料研究和证据引用；
PDF、表格、图片等混合内容处理；
RAG、知识库和企业文档问答；
博客、公众号文章的选题、写作、校对与配图。

2. 日常办公与内容生产

会议纪要、周报、方案和邮件整理；
PPT 大纲、页面设计和演讲稿生成；
技术架构图、流程图与配图制作；
从一份长文拆分出公众号、短内容和分享材料。

3. 软件测试与 AI 编程

需求分析、测试点和测试用例生成；
接口测试、UI 自动化和失败日志分析；
代码生成、调试、测试和代码审查；
使用 Coding Agent 完成仓库级任务；
将验证、权限和人工审核加入执行流程。

4. 把日常工作“训练”为 Skill：从个人经验到可复用流程

这里的“训练”不是修改模型参数，而是将已经验证的工作经验提炼为 Agent 可以加载、执行和改进的程序性知识。

flowchart LR
    A[选择重复且可验收的工作] --> B[收集成功案例与人工修正]
    B --> C[提炼步骤、判断与风险边界]
    C --> D[封装 SKILL.md 与参考资源]
    D --> E[Agent 执行新任务]
    E --> F[测试与人工验收]
    F --> G[根据失败案例改进 Skill]
    G --> E

适合沉淀为 Skill 的工作通常具备五个特点：高频重复、输入明确、步骤稳定、结果可验收、风险可控制。例如需求分析、测试用例设计、失败日志分析、周报整理和文章校对。

一个最小 Skill 可以由四部分组成：

组成	作用
`SKILL.md`	定义触发条件、主流程、边界和完成标准
`references/`	保存领域规则、操作规范和参考资料
`scripts/`	执行格式校验、数据转换等确定性操作
`assets/`	保存报告、表格和输出模板

后续专题会使用“测试失败分析”和“需求转测试用例”两个案例，完整演示如何从真实工作记录中提炼 Skill，并通过固定测试集持续评估。

5. 从 Agent 到 Harness：理解构建思想，再比较具体实现

这里首先要区分三个不同层次的概念：

模型（Model）提供语言理解、生成、推理和决策能力；
Agent面向目标持续进行“理解—行动—观察—调整”，是模型与外部环境共同形成的任务执行系统；
Agent Harness位于模型和真实环境之间，负责准备上下文、组织 Agent Loop、调用工具、管理状态，并提供权限、沙箱、审批、追踪和结果验证等工程能力。

可以使用一个便于理解、但不是严格行业标准的公式：

1	Agent 系统 ≈ Model + Harness + Environment

模型决定能力上限，Harness 决定模型能够获得什么信息、采取哪些行动、怎样持续执行，以及出错后如何恢复；Environment 则提供代码库、文件系统、Shell、浏览器、数据库和业务系统等真实工作对象。

Harness Engineering 不是一款产品，而是一种构建和治理 Agent 的工程思想。 它关注的不是再写一段更复杂的提示词，而是怎样为模型建立一套可执行、可约束、可观测、可验证的工作环境。

Anthropic 在官方 Agent 工程文章中对这一概念进行了清晰定义：agent harness（也称 scaffold）是让模型能够作为 Agent 行动的系统，它负责处理输入、编排工具调用并返回结果。 Anthropic 也将 Claude Code 直接称为一种灵活的 agent harness。不过，目前没有足够的一手资料证明“Harness Engineering”这个术语由 Anthropic 首次创造，因此本系列会把 Anthropic 视为这一工程思路的重要实践者和推动者，而不简单写成术语的唯一发明者。

同一种 Harness 思想，不同的产品方向

Claude Code、OpenAI Codex、DeepAgents、Hermes Agent 和 DeepSeek Harness 都体现了 Harness 思想，但它们并不是完全同类的产品，也不应该只用同一张“谁更强”的排行榜评价。

产品 / 框架	主要定位	核心优势	更适合
Claude Code	面向真实代码库的 Coding Harness	仓库理解、终端工具、`CLAUDE.md`、Skills、Plugins、Subagents、MCP	日常开发、调试、测试、重构与代码审查
OpenAI Codex	开放且可集成的编码 Harness	开源执行层、Sandbox、Approval、SDK、`exec` 与 app-server	CI 任务、程序化调用及将编码 Agent 嵌入产品
DeepAgents	构建复杂 Agent 的开发框架	Planning、Filesystem、Memory、Skills、Subagents、Context Offloading	研究、分析、测试等自定义长程业务 Agent
Hermes Agent	持久运行的模型无关自主 Agent	跨会话记忆、自主创建和改进 Skills、多消息平台	个人助手、长期自动化和跨渠道任务
DeepSeek Harness	“一切皆插件”的开放 Agent Harness	模型、工具、Skills、Sandbox、Loop、UI 可替换，运行轨迹可回放	Harness 架构研究和自定义插件开发

其中，DeepSeek Harness 目前仍处于 Developer Preview；具体产品能力、版本和稳定性会在对应实战文章中重新验证。

这些工具应该怎样选择

选择时先判断目标：直接完成代码库工作可关注 Claude Code 或 Codex；构建复杂业务 Agent 可关注 DeepAgents；需要长期个人助手可实践 Hermes Agent；研究可插拔 Harness 则可以试用 DeepSeek Harness。

后续文章会使用相同任务，从上下文、工具、扩展性、权限、评估、成本和稳定性等维度进行实测，并记录当时的版本、模型和运行环境。

这一篇章的目标，是把“我会使用某个 AI 工具”进一步变成：

我理解模型、Agent、Harness 与环境怎样协作，也知道如何根据任务选择现成产品或构建自己的 Agent 系统。

官方资料：

四、第三篇章：产品开发——从 Vibe Coding 走向可交付的软件

AI 编程让产品原型的开发成本快速下降。过去需要先准备完整团队和较长周期才能验证的想法，现在可以通过自然语言、代码 Agent 和现成 Skills，在更短时间内做出可以运行的版本。

但“能生成代码”与“能交付产品”之间仍然有很长的距离。需求是否清楚、架构是否一致、数据是否安全、测试是否充分、结果是否可维护，不能因为代码由 AI 生成就被省略。

这一篇章不会把 Vibe Coding 和 SDD 描述成互相替代的开发方法，而会把它们放回完整的 Enterprise SDLC（企业软件开发生命周期） 中，讨论 AI 在每个阶段能够承担什么工作、哪些结果必须由人负责，以及怎样通过 Skills 将组织流程变成 Agent 可以执行的工程约束。

1. Enterprise SDLC：AI 不能跳过软件交付生命周期

Enterprise SDLC 是从业务目标到持续运营的完整交付闭环。AI 可以参与每个阶段，但不能跳过架构、安全、质量、合规和发布门禁。

flowchart LR
    A[业务目标与立项] --> B[需求发现与分析]
    B --> C[产品 Spec 与验收标准]
    C --> D[架构、安全与数据设计]
    D --> E[计划与任务拆分]
    E --> F[编码、测试与审查]
    F --> G[验收、发布与部署]
    G --> H[监控、反馈与维护]
    H --> B

Vibe Coding、SDD 和 Skills 分别承担不同角色：Vibe Coding 加速探索，SDD 保持目标与交付一致，Skills 将组织方法变成 Agent 可执行流程。

2. Vibe Coding：SDLC 前端的探索与加速器

Vibe Coding 适合需求发现、交互原型、技术 Spike 和低风险内部工具，用快速反馈回答“是否值得做、体验是否合理、技术是否可行”。

flowchart LR
    A[Idea] --> B[自然语言描述]
    B --> C[Agent 生成原型]
    C --> D[运行与体验]
    D --> E[人工反馈]
    E --> C
    E --> F[形成经过验证的产品认知]

它是 SDLC 前端的探索加速器，不是生产交付的替代品。原型准备正式开发时，仍需进入 Spec、架构、测试、安全、发布和运营流程。

3. SDD：把探索结果转化为可审查、可验收的交付契约

SDD（Spec-Driven Development）先把人的意图转化为可验证的规格，再由规格约束计划、实现、测试和验收。

flowchart LR
    A[业务目标] --> B[需求与用户故事]
    B --> C[Functional / Technical Spec]
    C --> D[验收标准]
    D --> E[任务与实施计划]
    E --> F[代码与测试]
    F --> G[Spec 审查与发布证据]

它的核心价值是建立 Goal → Spec → Ticket → Code → Test → Evidence 的可追踪关系，减少 Agent 在长任务中的需求漂移。

3.1 SDD Skills：将 Enterprise SDLC 变成 Agent 可执行的流程

Spec 定义“交付什么”，Skills 封装“团队怎样完成和检查”。不同阶段加载不同 Skill，使流程、工具和质量门禁可以复用。

flowchart LR
    A[发现与建模
Discovery
Domain Modeling] --> B[规格与设计
Specification
Architecture / Threat]
    B --> C[计划
Task Planning]
    C --> D[实现与测试
TDD / Testing]
    D --> E[审查
Code / Spec Review]
    E --> F[发布与运营
Release / Operations]
    F --> A

3.2 Matt Pocock Skills 与 Superpowers

两套 Skills 都体现了 SDD 思想，但流程重点不同：

对比项	Matt Pocock Skills	Superpowers
核心思路	保留工程师控制权，将共识转成 Spec 和可追踪工单	通过阶段门禁确保先设计、后计划、再执行
代表流程	`grill-with-docs → to-spec → to-tickets → implement/tdd → code-review`	`brainstorming → 设计批准 → writing-plans → subagent-driven/executing-plans → review`
任务拆分	强调可独立演示和验证的垂直切片及依赖关系	强调细粒度计划、检查点和分任务执行
质量控制	TDD，并分别审查工程标准与 Spec 一致性	TDD、调试、任务间审查和完成前验证
更适合	已使用 Issue Tracker、重视领域语言与追踪关系的团队	重视设计批准、人工检查点和流程纪律的项目

两者不必全量叠加。实际项目应选择一条主流程，再按需要复用对方的访谈、工单拆分、子 Agent 执行或双轴审查能力；高风险企业系统还需增加架构、安全、合规和发布审批。

4. 在 AI Test Platform 中进行完整实践

这一篇章最终会选取 AI Test Platform 的真实功能，演示一条从想法到上线的完整路径：

Vibe Coding 验证测试分析体验
      ↓
整理用户、场景与业务规则
      ↓
编写 Functional / Technical Spec
      ↓
定义测试、安全和验收条件
      ↓
使用 Skills 拆分任务
      ↓
Coding Agent 分阶段实现
      ↓
自动测试 + 人工评审
      ↓
Spec 一致性与安全检查
      ↓
发布审批、部署与监控
      ↓
根据运行数据继续迭代

这一实践希望说明：Vibe Coding 负责提高探索速度，SDD 负责保持目标和交付一致，Skills 负责复用工程方法，Enterprise SDLC 负责控制组织风险。

当 Rules、Skills、MCP、Tools、Memory、Sandbox、Evaluation 和人工审批组合起来，AI 编程才从一次生成行为，逐步变成可以管理、验证和持续改进的软件工程过程。

参考资料：

五、这个系列会怎样推进

整个系列计划以 AI Engineering 为主题，并通过一个持续演进的 AI Test Platform 串联理论和实践。这个平台将从最简单的 LLM Chat 开始，逐步加入 RAG、Tools、Agent、Memory、Skills、MCP、Evaluation 和 Harness，最终探索 Vibe Coding、SDD 与 Agentic Software Engineering。

为了避免把“100 篇”变成只追求数量的任务，我会按阶段推进：

阶段	主要内容	阶段产物
基础理论篇	AI 演变、LLM、RAG、Agent 与工程基础	知识地图、概念图、最小 Demo
工具实战篇	文档、办公、测试、编程与 Harness 工具	可复用流程、案例、Skills
产品开发篇	Vibe Coding、SDD、Agent 产品与评估	持续演进的 AI Test Platform

每篇文章尽量围绕一个明确问题展开，并至少留下一个可以复用的成果：一张图、一个 Demo、一份模板、一个 Skill、一段经过验证的流程，或者一次真实的项目迭代。

博客将承载完整技术细节、代码和长期索引；公众号则更强调问题、案例、结论与阅读体验。两者共享同一套知识主线，但不会只是简单复制。

六、我希望记录的，不只是工具用法

AI 技术仍在快速变化。今天流行的模型、框架和产品，几年后可能已经被替代。如果内容只回答“某个按钮在哪里”“某个接口怎样调用”，它的有效期会很短。

我更希望这个系列最终沉淀三类长期价值：

技术认知：能够看懂 AI 技术的演变和不同概念的边界；
实践方法：能够把 AI 安全、稳定地加入自己的工作流程；
产品能力：能够利用 Agent、Skills、Harness 和 SDD，把想法变成可验证、可维护的产品。

我也会尽量诚实地记录哪些方法有效、哪些尝试失败、哪些任务其实不适合交给 Agent。AI 的价值不在于替代所有工作，而在于重新分配人与工具之间的职责：

人负责目标、判断、约束和验收，AI 负责理解、生成、执行和迭代。

结语：从一次学习，走向长期实践

从 2021 年正式学习 AI 相关内容到现在，技术环境已经发生了巨大变化。从模型只能完成有限的分类和生成任务，到大语言模型成为通用交互入口，再到 Agent 可以读取文件、调用工具、编写代码和执行复杂流程，AI 正在从一种技术能力变成新的工作基础设施。

这个系列既是一份学习记录，也是一场长期实践。我会从自己的软件测试与技术工作出发，持续验证 AI 在知识学习、内容生产、日常办公、软件测试、编程和产品开发中的真实价值。

下一篇，我们从整套知识体系的起点开始：

AI 技术演进：从传统人工智能、机器学习和深度学习，到 Transformer、LLM 与 Agent。

Jean's Blog

写在 AI Engineering 系列开始之前：从技术演变到真实工作