关于
涵盖识别适合 LLM 处理的任务、设计有效项目架构和使用代理辅助开发快速迭代的原则。
name: project-development description: "此技能涵盖识别适合LLM处理的任务、设计有效的项目架构以及使用代理辅助开发快速迭代的原则。" risk: unknown source: community
项目开发方法论
此技能涵盖识别适合LLM处理的任务、设计有效的项目架构以及使用代理辅助开发快速迭代的原则。无论是构建批处理管道、多代理研究系统还是交互式代理应用程序，该方法论都适用。
何时使用
在以下情况下激活此技能：
- 启动可能受益于LLM处理的新项目
- 评估任务是否适合代理而非传统代码
- 为LLM驱动的应用程序设计架构
- 规划具有结构化输出的批处理管道
- 在单代理和多代理方法之间做选择
- 估算LLM密集型项目的成本和时间线
核心概念
任务-模型匹配度识别
并非每个问题都能从LLM处理中受益。任何项目的第一步是评估任务特征是否与LLM优势一致。此评估应在编写任何代码之前进行。
适合LLM的任务具有以下特征：
| 特征 | 为何适合 | |------|----------| | 跨来源综合 | LLM擅长组合来自多个输入的信息 | | 带评分标准的主观判断 | LLM能处理带标准的评分、评估和分类 | | 自然语言输出 | 当目标是人类可读文本而非结构化数据时 | | 容错性 | 个别失败不会破坏整体系统 | | 批处理 | 项目之间不需要对话状态 | | 训练中的领域知识 | 模型已具有相关上下文 |
不适合LLM的任务具有以下特征：
| 特征 | 为何失败 | |------|----------| | 精确计算 | 数学、计数和精确算法不可靠 | | 实时要求 | LLM延迟对于亚秒响应来说太高 | | 完美准确度要求 | 幻觉风险使100%准确度不可能 | | 专有数据依赖 | 模型缺乏必要的上下文 | | 顺序依赖 | 每一步都严重依赖前一步的结果 | | 确定性输出要求 | 相同输入必须产生相同输出 |
评估应通过手动原型验证进行：取一个代表性示例，在构建任何自动化之前直接用目标模型测试。
手动原型步骤
在投入自动化之前，通过手动测试验证任务-模型匹配度。将一个代表性输入复制到模型界面中。评估输出质量。这只需几分钟，却能防止数小时的浪费开发。
此验证回答关键问题：
- 模型是否具有此任务所需的知识？
- 模型能否以你需要的格式产生输出？
- 大规模运行时应期望什么质量水平？
- 是否有明显的失败模式需要解决？
如果手动原型失败，自动化系统也会失败。如果成功，你就有了比较基准和提示设计模板。
管道架构
LLM项目受益于分阶段的管道架构，其中每个阶段是：
- 离散的：阶段之间有清晰的边界
- 幂等的：重新运行产生相同结果
- 可缓存的：中间结果持久化到磁盘
- 独立的：每个阶段可以单独运行
规范管道结构：
acquire → prepare → process → parse → render
- 获取：从来源获取原始数据（API、文件、数据库）
- 准备：将数据转换为提示格式
- 处理：执行LLM调用（昂贵的、非确定性的步骤）
- 解析：从LLM输出中提取结构化数据
- 渲染：生成最终输出（报告、文件、可视化）
阶段1、2、4和5是确定性的。阶段3是非确定性且昂贵的。这种分离允许仅在必要时重新运行昂贵的LLM阶段，同时快速迭代解析和渲染。
文件系统作为状态机
使用文件系统跟踪管道状态，而非数据库或内存结构。每个处理单元获得一个目录。每个阶段完成由文件存在标记。
data/{id}/
├── raw.json # acquire stage complete
├── prompt.md # prepare stage complete
├── response.md # process stage complete
├── parsed.json # parse stage complete
检查项目是否需要处理：检查输出文件是否存在。重新运行某阶段：删除其输出文件和下游文件。调试：直接读取中间文件。
此模式提供：
- 自然幂等性（文件存在控制执行）
- 易于调试（所有状态都是人类可读的）
- 简单的并行化（独立目录可并发处理）