name: 项目开发 description: 从构思到部署设计和构建基于LLM的项目。用于启动新的智能体项目、在LLM和传统方法之间选择，或构建批量处理管道。

项目开发方法论

本技能涵盖识别适合LLM处理的任务的原则、设计有效的项目架构，以及使用智能体辅助开发进行快速迭代的方法论。该方法论适用于构建批量处理管道、多智能体研究系统或交互式智能体应用。

何时激活

在以下情况下激活此技能：

启动可能受益于LLM处理的新项目
评估任务是否适合智能体与传统代码
设计基于LLM的应用程序架构
规划具有结构化输出的批量处理管道
选择单智能体与多智能体方法
估计LLM重型项目的成本和时间线

核心概念

任务-模型匹配识别

并非每个问题都受益于LLM处理。任何项目的第一个步骤是评估任务特征是否与LLM优势对齐。此评估应在编写任何代码之前进行。

适合LLM的任务具有以下特征：

特征	为什么适合
跨源合成	LLM擅长结合多个输入的信息
基于标准的判断	LLM处理评分、评估和分类
自然语言输出	当目标是人类可读文本，而非结构化数据时
容错性	个别失败不会破坏整个系统
批量处理	项目之间不需要会话状态
训练中的领域知识	模型已有相关上下文

不适合LLM的任务具有以下特征：

特征	为什么失败
精确计算	数学、计数和精确算法不可靠
实时需求	LLM延迟过高，无法满足亚秒级响应
完美准确性要求	幻觉风险使得100%准确性不可能
专有数据依赖	模型缺乏必要的上下文
顺序依赖	每个步骤严重依赖前一个结果
确定性输出要求	相同输入必须产生相同的输出

评估应通过手动原型进行：在构建任何自动化之前，取一个代表性示例并使用目标模型直接测试。

手动原型步骤

在投资自动化之前，通过手动测试验证任务-模型匹配。将一个代表性输入复制到模型界面。评估输出质量。这只需几分钟，可防止数小时的开发浪费。

此验证回答关键问题：

模型是否有执行此任务所需的知识？
模型能否以您需要的格式产生输出？
在规模上应期望什么质量水平？
是否存在需要解决的明显失败模式？

如果手动原型失败，自动化系统将失败。如果成功，您就有了比较基线和提示设计模板。

管道架构

LLM项目受益于分阶段管道架构，其中每个阶段是：

离散的：阶段之间有清晰的边界
幂等的：重新运行产生相同结果
可缓存的：中间结果持久化到磁盘
独立的：每个阶段可以单独运行

典型管道结构：

获取 → 准备 → 处理 → 解析 → 渲染

获取：从源（API、文件、数据库）获取原始数据
准备：将数据转换为提示格式
处理：执行LLM调用（昂贵、非确定性步骤）
解析：从LLM输出中提取结构化数据
渲染：生成最终输出（报告、文件、可视化）

阶段1、2、4和5是确定性的。阶段3是非确定性和昂贵的。这种分离允许仅在必要时重新运行昂贵的LLM阶段，同时快速迭代解析和渲染。

文件系统作为状态机

使用文件系统而非数据库或内存结构来跟踪管道状态。每个处理单元获取一个目录。每个阶段完成通过文件存在标记。

data/{id}/
├── raw.json         # 获取阶段完成
├── prompt.md        # 准备阶段完成
├── response.md      # 处理阶段完成
├── parsed.json      # 解析阶段完成

检查项目是否需要处理：检查输出文件是否存在。重新运行阶段：删除其输出文件和下游文件。调试：直接读取中间文件。

此模式提供：

自然的幂等性（文件存在控制执行）
易于调试（所有状态都是人类可读的）
简单并行化（每个目录独立）
简单缓存（文件在运行之间持久化）

结构化输出设计

当LLM输出必须以编程方式解析时，提示设计直接决定解析可靠性。提示必须指定精确的格式要求，并提供示例。

有效的结构规范包括：

部分标记：用于解析的显式头部或前缀
格式示例：显示输出应确切如何看
理由披露：“我将以编程方式解析此内容”
约束值：枚举选项、评分范围、格式

示例提示结构：

分析以下内容，并以此格式提供您的响应：

## 总结
[您的总结]

## 分数
评分：[1-10]

## 详细信息
- 关键点1
- 关键点2

请严格按照此格式，因为我将以编程方式解析它。

解析代码必须优雅地处理变体。LLM不完美遵循指令。构建解析器以：

使用足够灵活的正则表达式模式来处理次要格式变体
当部分缺失时提供合理的默认值
记录解析失败以供后续审查，而非崩溃

智能体辅助开发

现代具有智能体能力的模型可以显著加速开发。模式是：

描述项目目标和约束
让智能体生成初始实现
测试并迭代特定失败
根据结果优化提示和架构

这是关于快速迭代：生成、测试、修复、重复。智能体处理样板和初始结构，而您专注于领域特定需求和边缘情况。

有效智能体辅助开发的关键实践：

提前提供清晰、具体的要求
将大型项目分解为离散组件
在移动到下一个之前测试每个组件
一次让智能体专注于一个任务

成本和规模估计

LLM处理具有可预测的成本，应在启动前估计。公式：

总成本 = (项目数 × 每项令牌数 × 每令牌价格) + API开销

对于批量处理：

估计每项的输入令牌（提示 + 上下文）
估计每项的输出令牌（典型响应长度）
乘以项目数
增加20-30%的缓冲，用于重试和失败

在开发过程中跟踪实际成本。如果成本显著超出估计，重新评估方法。考虑：

通过截断减少上下文长度
对较简单项目使用较小模型
缓存和重用部分结果
并行处理以减少挂钟时间（而非令牌成本）

详细主题

选择单智能体与多智能体架构

单智能体管道适用于：

具有独立项目的批量处理
项目不交互的任务
更简单的成本和复杂性管理

多智能体架构适用于：

不同方面的并行探索
超过单个上下文窗口容量的任务
当专门子智能体提高质量时

多智能体的主要原因是上下文隔离，而非角色拟人化。子智能体获得新鲜上下文窗口以专注于子任务。这防止在长时间运行任务上上下文退化。

查看 多智能体模式 技能以获取详细架构指导。

架构简化

从最小架构开始。仅在证明必要时添加复杂性。生产证据显示，移除专门工具通常提高性能。

Vercel的d0智能体通过将17个专门工具减少到2个原始工具（bash命令执行和SQL），实现了100%成功率（从80%提升）。文件系统智能体模式使用标准Unix工具（grep、cat、find、ls）而非自定义探索工具。

当简化优于复杂性时：

您的数据层有良好文档且结构一致
模型具有足够的推理能力
您的专门工具是约束而非启用
您花更多时间维护脚手架而非改进结果

当复杂性必要时：

您的底层数据混乱、不一致或文档差
领域需要模型缺乏的专门知识
安全约束要求限制智能体能力
操作真正复杂且受益于结构化工作流

查看 工具设计 技能以获取详细工具架构指导。

迭代和重构

期望重构。生产中的智能体系统在规模上需要多个架构迭代。Manus自推出以来已重构其智能体框架五次。苦涩教训表明，为当前模型限制添加的结构随着模型改进而成为约束。

为变化而构建：

保持架构简单且无偏见
跨模型优势测试以验证您的约束不限制性能
设计受益于模型改进的系统，而非锁定限制

实践指导

项目规划模板

任务分析
- 输入是什么？期望输出是什么？
- 这是合成、生成、分类还是分析？
- 可接受的错误率是多少？
- 每个成功完成的价值是多少？
手动验证
- 使用目标模型测试一个示例
- 评估输出质量和格式
- 识别失败模式
- 估计每项的令牌数
架构选择
- 单管道 vs 多智能体
- 所需工具和数据源
- 存储和缓存策略
- 并行化方法
成本估计
- 项目数 × 令牌数 × 价格
- 开发时间
- 基础设施要求
- 持续运营成本
开发计划
- 分阶段实施
- 每阶段测试策略
- 迭代里程碑
- 部署方法

要避免的反模式

跳过手动验证：在验证模型能执行任务之前构建自动化，如果方法根本上存在缺陷，会浪费大量时间。

单体管道：将所有阶段合并到一个脚本中，使调试和迭代困难。用持久中间输出分隔阶段。

过度约束模型：添加模型本可处理的护栏、预过滤和验证逻辑。测试您的脚手架是帮助还是阻碍。

忽略成本直到生产：令牌成本在规模上快速累积。从一开始估计和跟踪。

完美解析要求：期望LLM完美遵循格式指令。构建处理变体的鲁棒解析器。

过早优化：在基本管道正常工作之前添加缓存、并行化和优化。

示例

示例1：批量分析管道（Karpathy的HN时间胶囊）

任务：用后见之明评分分析10年前的930个HN讨论。

架构：

5阶段管道：获取 → 提示 → 分析 → 解析 → 渲染
文件系统状态：data/{日期}/{项目_id}/ 带阶段输出文件
结构化输出：6个部分，具有显式格式要求
并行执行：15个工作进程用于LLM调用

结果：总成本58美元，执行约1小时，静态HTML输出。

示例2：架构简化（Vercel d0）

任务：用于内部分析的文本到SQL智能体。

之前：17个专门工具，成功率80%，平均执行274秒。

之后：2个工具（bash + SQL），成功率100%，平均执行77秒。

关键洞察：语义层已有良好文档。Claude只需直接访问读取文件。

查看案例研究获取详细分析。

指南

在构建自动化之前，使用手动原型验证任务-模型匹配
将管道结构化为离散、幂等、可缓存的阶段
使用文件系统进行状态管理和调试
设计具有显式格式示例的结构化、可解析输出提示
从最小架构开始；仅在证明必要时添加复杂性
早期估计成本并在整个开发过程中跟踪
构建处理LLM输出变体的鲁棒解析器
期望并规划多个架构迭代
测试脚手架是否帮助或约束模型性能
使用智能体辅助开发进行快速迭代实现

集成

本技能连接到：

上下文基础 - 理解上下文约束以进行提示设计
工具设计 - 在管道中设计智能体系统的工具
多智能体模式 - 何时使用多智能体与单管道
评估 - 评估管道输出和智能体性能
上下文压缩 - 当管道超过限制时管理上下文

参考

内部参考：

案例研究 - Karpathy HN Capsule、Vercel d0、Manus模式
管道模式 - 详细管道架构指导

本集合中的相关技能：

工具设计 - 工具架构和简化模式
多智能体模式 - 何时使用多智能体架构
评估 - 输出评估框架

外部资源：

Karpathy的HN时间胶囊项目：https://github.com/karpathy/hn-time-capsule
Vercel d0架构简化：https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools
Manus上下文工程：Peak Ji关于上下文工程教训的博客
Anthropic多智能体研究：我们如何构建多智能体研究系统

技能元数据

创建时间：2025-12-25 最后更新：2025-12-25 作者：Agent Skills for Context Engineering Contributors 版本：1.0.0