深度揭秘：如何打造高可靠的AI助手，提升工作效率

阿里妹导读

文章首先拆解了上下文工程的五大最佳实践模式（状态管理、渐进式上下文、结构化输出、模版程序、多步处理），并深入对比了 Skill 与 Subagent 在上下文管理机制上的本质差异。

背景

2025 年 AI 辅助编程领域经历了多次里程碑式的快速发展。

Vibe Coding

在 2025 年 2 月，Andrej Karpathy 提出 Vibe Coding 的概念，即氛围编程，开发者只需要描述需要什么功能，不需要关注具体的代码实现。听起来非常的吸引人，但我认为 Vibe Coding 更大的意义是大幅降低编程的门槛，让一些不懂编程的人员，能够快速的落地自己的想法。

反而 Vibe Coding 对于现有的企业线上项目而言意义并不大，主要原因是，大模型和开发者之间存在很大的隐形的信息差，包括但不限于项目中使用了许多非公开的技术框架，每个团队有自己的代码规范等，另外，不加限制的 Vibe Coding 对于线上稳定性而言，也是一个不小的挑战。

Spec Coding

2025 年 6 月，在 AIEWF 2025 大会上，OpenAI 研究员 Sean Grove 提出 Spec（规约） 比代码更重要。这个观点非常有意思，Sean Grove 做了一个形象的类比：高级语言通过编译器编译成二进制产物，重要的是高级语言代码，而二进制产物我们可以随时通过编译器生成。Spec 就像是高级语言代码，而 AI 就像是编译器，我们随时可以使用一个 Spec，通过 AI 来生成代码。

相比于 Vibe Coding，我认为，就目前而言 Spec Coding 更适合应用在真实的项目中，我们可以通过让 AI 先生成修改代码的 Spec，即让 AI 先把要做什么和怎么做写出来。工程师通过审查和修改 Spec 实现对 AI Coding 行为的控制，以此来提高 AI 生成代码的可控性，降低线上稳定性的风险，也能大幅提升 AI 生成代码的可用性。

当然，如果 AI 生成的 Spec 质量很差，那后续的 Coding 就完全没法执行了？这个确实是，但是造成这个问题的原因，是 AI 了解的上下文和我们的认知的信息是有差异的，我们需要将我们认知的信息，通过知识库或者文档的形式给到 AI，这样才能提高 Spec 生成的成功率。

从本质上来讲，是现有 AI 能力不足，我们才需要通过上下文和 Spec 来弥补 AI 不能精确理解代码库的能力的缺陷，未来如果 AI 能够很好的理解项目代码，并且能够有人类一样，甚至超越人类的记忆，也就不需要 Spec 来驱动开发了。

上下文工程 和 Skill

在 2025 年 6 月，“上下文工程”概念引发了行业内的广泛讨论，上下文工程不再像提示词工程一样，关注“怎么问”，而是要构建“提问时，模型应该知道什么” 以及 如何将上下文提供给 AI。

和设计模式类似，随着近几年 AI 的快速发展，互联网上也逐渐出现了一些上下文工程常见的最佳实践模式：

1. 状态管理：目前 agent 中最常用的 todo list 工具就是一种状态管理 （todo list）；2. 渐进式上下文：一步步的生成查询、检索信息、提取概念，上下文逐渐丰富和聚焦 （skill 展开）；3. 结构化输出：无论是生成查询还是提取概念，都要求使用结构化的格式要求，确保输出稳定可用（spec 生成）；4. 模版程序：每个 prompt 都是为特定子任务设计的、可复用的提示模版。（subagent, skill）；5. 多步处理：将复杂任务拆成多步执行（workflow）；

在 2025 年 10 月，Anthropic 公司提出了 Skill 概念，Skill 的本质就是渐进式上下文模式：在最开始的提示词中，只提供给 AI 一个 Skill 信息列表，只包含 Skill 名称和简短的描述，随后让 AI 在任务执行的过程中，去获取对应 Skill 的具体内容，然后用对应 Skill 完成任务。

使用渐进式上下文有2个好处：一是比起把所有上下文信息全量拼在系统提示词中，Skill 能大幅降低 token 使用量。二是随着任务执行而展开上下文信息，能够让 AI 持续聚焦于 Skill 信息本身，降低长任务场景下 Skill 信息遗忘的概率。

Skill 和 Subagent 有什么区别呢？

其最大的区别就是上下文的管理方式，Skill 在主流程的上下文空间中进行展开，而 Subagent 具有独立的上下文空间。

使用 Skill 做 AI Coding 遇到的问题

在实际使用 Spec Coding 的过程中，我们发现了一些问题：

1. 复杂的任务会导致 Skill 过于复杂：如果使用一个 Skill 去完成一个复杂的工作，会导致 Skill 复杂度过高，就像我们将所有代码写在一个方法里，需要做适当拆分。 2. 多 Skill 任务执行准确率低：如果直接将一堆 Skill 丢给 AI，那么在执行复杂任务的时候，AI 并不会很好的按照我们预期的方式去使用这些 Skill，所以需要提供一定的引导。 3. 编写 Skill 耗时高：打磨一个好用的 Skill 确实需要花费一定量的时间。

因此我们做了一个名为 kuspec 的内部工具去尝试解决这些问题：

1. 针对第一和第二个问题，我们提出了 Workflow 概念，每一个 Workflow 是包含若干个单一职责的 Skill 的编排，通过 Workflow 将一个复杂的任务拆解成若干个步骤，每一步需要非常明确的告诉 AI 使用哪一个具体的 Skill。2. 针对第三个问题，我们提供了 创建 Workflow 的 Workflow 和 创建 Skill 的 Skill，能够帮助我们快速创建自己业务的 Workflow 和 Skill。

上下文封装的基本单位：Workflow

工作流包含特定业务的上下文，以及对通用 Skill 的执行编排。

工作流本质是对我们一整个工作流程的语义描述，在编写工作流的时候，我们要从人的角度思考，人是怎么完成这个工作的，随后对其进行语义化表述，就是我们的工作流。

工作流的结构很简单，一个目录里面包含两个文件：WORKFLOW.md 和 WORKFLOW_INIT.md。

WORKFLOW.md 文件

包含了业务上下文以及对 Skill 的执行编排：

通常我们推荐使用 Spec Coding 去解决比较复杂的问题。

WORKFLOW_INIT.md 文件

这个文件不是必须的，当我们要输入给工作流的信息比较复杂时推荐使用。

以这个例子为例：开发一个卡片，我们要同时提供需求文档、设计稿信息、服务端接口文档，等很多信息。

那么可以使用 WORKFLOW_INIT.md 让 AI 在执行工作流前，先执行这个初始化任务，生成一个结构化文档，交给用户填写，填写完成后，再将这个文档作为后续执行工作流的入参，实现具体需求和通用工作流的解耦。

实现工作流复用：WorkflowRepo

WorkflowRepo 即工作流仓库，包含了若干 Workflow 和 Workflow 所用到的 Skill。他可以通过 git 仓库的进行迭代和分发，方便团队同学使用。

下图所示就是一个简单的工作流仓库的结构：

包含一个仓库的配置文件(config.json)，以及若干个工作流和Skill。

如何在 Agent 中使用工作流

我们可以使用 Agent 支持的自定义命令来作为工作流的入口，通过 MCP 去访问仓库中的 Workflow 和 Skill。

Step1 - 集成

我们可以编写一个 CLI 工具，在开发目录执行。通过为不同的 Agent 安装自定义命令和MCP，将工作流能力集成到对应 Agent 中。

以 kuspec 为例，实现了一个 CLI 工具，可以让用户选择对应的 Agent 进行集成：

以 iFlow CLI 为例，集成到 Agent 后，我们可以看到开发目录下，会安装几个自定义命令，以及在 settings.json 中，为 Agent 配置所需的 MCP

Step2 - 初始化工作流（可跳过）

集成到 Agent 中后，我们进入 Agent 就可以使用自定义命令执行工作流了。

对于上一节中，需要使用 WORKFLOW_INIT.md 的场景而言，这里需要执行工作流初始化自定义命令，来执行我们编写的 WORKFLOW_INIT.md 文件，在 Agent 中执行以下自定义命令：

/kuspec:init

执行这个自定义命令的 Prompt：

description = "初始化 kuspec workflow"prompt = """1. 需要提供 workflow 名称，如果没有 workflow 名称请使用 get_available_workflows 获取所有可用的 workflow 供用户选择，不要自行决定，请使用 get_available_workflows 工具的返回结果，不要使用其他信息。2. 使用 get_workflow_init_by_name 工具获取对应 workflow 的初始化信息，并按照获取的信息，执行相对应的操作。"""

可以看到，这个自定义命令，就是让 AI 去通过 MCP 获取具体工作流的 WORKFLOW_INIT.md 文件，并按照文件的描述执行任务。

Step3 - 执行工作流

接下来，就可以执行工作流了，在 Agent 中执行

/kuspec:exeute

执行这个自定义命令的 Prompt:

description = "执行 kuspec workflow，需要提供 workflow 名称"prompt = """按照下述步骤，逐步执行：1. 通过上下文确认目前执行的 workflow 名称，如果不存在目前执行的 workflow 名称，可以使用 get_available_workflows 获取所有的可执行 workflow 分析哪个最可能执行，并让用户确认。2. 如果没有相关 workflow，停止并报错，提示用户输入需要执行的 workflow 名称，3. 使用 get_workflow_execution_by_name 获取 workflow 对应的执行信息，并按照获取的执行信息执行。"""

这个自定义命令，让 AI 通过 MCP 工具，获取具体工作流的 WORKFLOW.md 文件，并按照文件提供的信息去执行。

这里有个细节：

在通过 MCP 返回具体 WORKFLOW.md 文件内容时，我们会通过 MCP 在 WORKFLOW.md 文件头部，加上可用的 Skill 列表，以及通过 MCP 查询 Skill 的方法，因为在执行工作流的过程中， AI 需要通过 MCP 查询具体 Skill 的详细信息，实现渐进式上下文管理。

提效实践场景

首先，我们要承认工作流设计具备一定的复杂性，同时在工作流中融入了 SDD 的理念，使得工作流的流程会变长和复杂，一些通过和 Agent 对话就能搞定的需求，使用工作流是舍近求远没有必要的。

我们在日常业务迭代中，通过 kuspec 工作流，完成了很多工作，也总结出了以下几个适用的场景。

特定框架下的插件、模块开发

1. 在特定的框架下的插件、模块的开发流程是固定的。2. 框架中的插件、模块开发，通常要编写很多模版代码，创建很多模版文件，这对工程师而言是重复劳动。3. 使用 AI 开发一个模块，不需要提供太多的上下文内容，准确性比较高。4. 通常会在模块中开发业务需求，代码比较简单，AI 完全可以胜任。5. 可以通过工作流，将编码前后的事情也纳入 AI 工作的范畴，例如编码完成后执行编译检查、自动将模块集成到框架中等。

前端 UI 开发/改版、服务端 CRUD 等简单重复劳动

1. 这类工作通常比较简单，而且流程固定。2. UI 改版/开发，可以通过设计工具的 MCP，将 UI 信息提供给 AI。3. CRUD 可以通过 Skill 或 MCP 提供 AI 所需的上下文。

团队内部“小众”技术栈下的业务开发

“小众”是相对于团队内部而言，通常由于为了满足某些业务的特殊诉求，会采用一些特定的技术框架，团队内部只有少数人熟悉。

例如，在客户端团队，由于某一个业务要求线上发版和快速迭代，因而采用 H5 开发，但是团队内部只有少部分同学熟悉 H5 相关技术。此时，可以让熟悉 H5 技术的同学，对该业务的开发流程做一个拆解，编写若干个该业务的开发工作流。其他同学参与进来时，可以直接使用工作流快速上手开发，并且通过实际业务开发，快速熟悉 H5 技术栈，这是一个正循环。

跨团队业务开发协同

通常一个大型的应用会拆分多个团队维护，当一个业务涉及多个团队时，就会出现 A 团队接入 B 团队的服务或者 SDK。通常 A 团队的同学需要 B 团队提供接口文档，或者 SDK 接入文档，并且在接入过程中，会频繁的要求 B 团队同学答疑。

这个时候，B 团队可以换一个思路：构建自己服务或SDK接入的工作流，将如何接入服务或接入 SDK，封装成一个工作流，这样 A 团队直接执行工作流，就可以完成接入任务，实现高效的跨团队业务开发协同。

最后的一些思考

目前 AI 的能力，要独立负责一个大中型的项目还比较困难。现在的 AI 扮演的角色更多的是工程师的助手，我们应该积极的拥抱 AI，让 AI 帮我们从重复劳动中解放出来，让我们能将有限的精力专注于更有价值的事情，从而创造更大的价值。