关于 project-development
project-development 是用于规划 LLM 项目和 Agent 辅助开发的方法论技能，指导团队在实施前后评估任务适配度、设计流水线、选择架构并估算成本。
主要功能
- 01LLM 任务适配度评估
- 02手动原型验证
- 03分阶段流水线架构
- 04基于文件的流水线状态
- 05结构化输出与解析指导
- 06成本与规模估算
适用场景
- 01判断任务是否适合 LLM
- 02规划批处理流水线
- 03选择单 Agent 或多 Agent 架构
- 04估算项目成本与时间
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/project-development确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
README.mdreferences/case-studies.mdpipeline-patterns.mdscripts/pipeline_template.py详细介绍
项目开发方法论
此技能介绍如何识别适合使用大模型处理的任务、设计有效的项目架构，以及借助 Agent 辅助开发快速迭代。这套方法论适用于构建批处理流水线、多 Agent 研究系统或交互式 Agent 应用。
何时启用
在以下情况下启用此技能：
- 启动一个可能受益于大模型处理的新项目
- 评估某项任务是否适合使用 Agent，而非传统代码
- 设计由大模型驱动的应用架构
- 规划具有结构化输出的批处理流水线
- 在单 Agent 和多 Agent 方法之间进行选择
- 估算大模型密集型项目的成本和时间线
核心概念
识别任务与模型的适配度
并非所有问题都适合使用大模型处理。任何项目的第一步都是评估任务特征是否符合大模型的优势。应在编写任何代码之前完成此评估。
适合使用大模型的任务具有以下特征：
| 特征 | 适用原因 |
|---|---|
| 综合多个来源的信息 | 大模型擅长整合多个输入中的信息 |
| 依据标准进行主观判断 | 大模型可以根据标准进行评分、评估和分类 |
| 自然语言输出 | 目标是生成易于人类阅读的文本，而非结构化数据 |
| 容错性 | 个别失败不会导致整个系统故障 |
| 批处理 | 项目之间不需要保留对话状态 |
| 训练数据中包含领域知识 | 模型已经具备相关背景知识 |
不适合使用大模型的任务具有以下特征：
| 特征 | 不适用原因 |
|---|---|
| 精确计算 | 数学运算、计数和精确算法的结果不可靠 |
| 实时要求 | 大模型的延迟过高，无法满足亚秒级响应要求 |
| 要求绝对准确 | 存在幻觉风险，因此无法保证 100% 准确 |
| 依赖专有数据 | 模型缺少必要的背景信息 |
| 存在顺序依赖 | 每一步都高度依赖上一步的结果 |
| 要求输出确定 | 相同输入必须产生相同输出 |
应通过手动原型进行评估：选取一个有代表性的示例，在构建任何自动化流程之前，直接使用目标模型进行测试。
手动原型步骤
在投入自动化开发之前，先通过手动测试验证任务与模型的适配度。将一个有代表性的输入复制到模型界面中，并评估输出质量。此过程只需几分钟，却能避免数小时的无效开发。
此验证可以回答以下关键问题：
- 模型是否具备完成此任务所需的知识？
- 模型能否按你需要的格式生成输出？
- 大规模使用时，预期能达到怎样的质量水平？
- 是否存在需要处理的明显失败模式？
如果手动原型失败，自动化系统也会失败。如果手动原型成功，你就有了用于对比的基准，以及用于设计提示词的模板。
流水线架构
大模型项目适合采用分阶段的流水线架构，其中每个阶段都具备以下特点：
- 独立：阶段之间界限清晰
- 幂等：重复运行会产生相同结果
- 可缓存：中间结果会持久化到磁盘
- 可独立运行：每个阶段都可以单独运行
典型的流水线结构：
acquire → prepare → process → parse → render
- 获取：从来源（API、文件、数据库）获取原始数据
- 准备：将数据转换为提示词格式
- 处理：执行大模型调用（成本高且具有非确定性的步骤）
- 解析：从大模型输出中提取结构化数据
- 渲染：生成最终输出（报告、文件、可视化内容）
第 1、2、4、5 阶段是确定性的。第 3 阶段具有非确定性且成本高。这样的分离使你只需在必要时重新运行成本高昂的大模型阶段，同时可以快速迭代解析和渲染阶段。
将文件系统用作状态机
使用文件系统来跟踪流水线状态，而不是数据库或内存中的结构。每个处理单元获得一个目录。每个阶段的完成由文件是否存在来标记。
data/{id}/
├── raw.json # acquire stage complete
├── prompt.md # prepare stage complete
├── response.md # process stage complete
├── parsed.json # parse stage complete
要检查某个条目是否需要处理：检查输出文件是否存在。要重新运行某个阶段：删除其输出文件以及下游文件。要调试：直接读取中间文件。
这种模式提供了：
- 天然的幂等性（文件是否存在决定是否执行）
- 便于调试（所有状态都是人类可读的）
- 简单的并行化（每个目录相互独立）
- 轻而易举的缓存（文件在多次运行之间持久保留）
结构化输出设计
当大模型的输出必须以编程方式解析时，提示词设计直接决定了解析的可靠性。提示词必须通过示例明确规定确切的格式要求。
有效的结构规范包括：
- 分节标记：用于解析的显式标题或前缀
- 格式示例：准确展示输出应该是什么样子
- 说明缘由："我会以编程方式解析这段内容"
- 受限取值：枚举的选项、分数范围、格式
示例提示词结构：
Analyze the following and provide your response in exactly this format:
## Summary
[Your summary here]
## Score
Rating: [1-10]
## Details
- Key point 1
- Key point 2
Follow this format exactly because I will be parsing it programmatically.
解析代码必须优雅地处理各种变化。大模型不会完美遵循指令。构建解析器时应：
- 使用足够灵活的 regex 模式来处理轻微的格式变化
- 当某些分节缺失时提供合理的默认值
- 记录解析失败以供后续审查，而不是直接崩溃
Agent 辅助开发
现代具备 Agent 能力的模型可以显著加速开发。其模式是：
- 描述项目目标和约束
- 让 Agent 生成初始实现
- 针对具体失败进行测试和迭代
- 根据结果优化提示词和架构
这关乎快速迭代：生成、测试、修复、重复。Agent 处理样板代码和初始结构，而你专注于领域特定的需求和边缘情况。
有效进行 Agent 辅助开发的关键实践：
- 预先提供清晰、具体的要求
- 将大型项目拆分为离散的组件
- 在继续下一个组件之前先测试每个组件
- 让 Agent 一次只专注于一项任务
成本与规模估算
大模型处理具有可预测的成本，应在开始前进行估算。公式为：
Total cost = (items × tokens_per_item × price_per_token) + API overhead
对于批处理：
- 估算每个条目的输入 token 数（提示词 + 上下文）
- 估算每个条目的输出 token 数（典型响应长度）
- 乘以条目数量
- 为重试和失败增加 20-30% 的缓冲
在开发过程中跟踪实际成本。如果成本显著超出估算，重新评估方法。考虑：
- 通过截断减少上下文长度
- 对较简单的条目使用更小的模型
- 缓存并复用部分结果
- 并行处理以减少实际耗时（而非 token 成本）
详细主题
选择单 Agent 还是多 Agent 架构
单 Agent 流水线适用于：
- 条目相互独立的批处理
- 条目之间不交互的任务
- 更简单的成本和复杂度管理
多 Agent 架构适用于：
- 对不同方面进行并行探索
- 超出单个上下文窗口容量的任务
- 当专门的子 Agent 能提升质量时
采用多 Agent 的主要原因是上下文隔离，而不是角色拟人化。子 Agent 获得全新的上下文窗口来专注于子任务。这可以防止长时间运行任务中的上下文退化。
有关详细的架构指导，请参阅 multi-agent-patterns 技能。
架构精简
从最小架构开始。只有当必要性得到验证时，才增加复杂度。生产实践表明，移除专用工具往往能提升性能。
Vercel 的 d0 Agent 通过将 17 个专用工具缩减为 2 个原语：bash 命令执行和 SQL，实现了 100% 的成功率（从 80% 提升）。文件系统 Agent 模式使用标准 Unix 工具（grep、cat、find、ls），而非自定义探索工具。
精简优于复杂的情况：
- 你的数据层有完善文档且结构一致
- 模型具备足够的推理能力
- 你的专用工具是在限制而非赋能
- 你花在维护脚手架上的时间多于改进结果的时间
复杂架构必要的情况：
- 你的底层数据杂乱、不一致或缺乏文档
- 该领域需要模型所不具备的专门知识
- 安全约束要求限制 Agent 能力
- 操作确实复杂，且能从结构化工作流中受益
详细的工具架构指导请参阅 tool-design 技能。
迭代与重构
预期需要重构。大规模生产 Agent 系统需要多次架构迭代。Manus 自发布以来对其 Agent 框架进行了五次重构。苦涩的教训表明，为当前模型局限而添加的结构，会随着模型进步而变成约束。
为变化而构建：
- 保持架构简单且无主观倾向
- 跨不同模型能力进行测试，以验证你的框架不会限制性能
- 设计能从模型改进中受益的系统，而非锁定在局限之中
实践指导
项目规划模板
-
任务分析
- 输入是什么？期望的输出是什么？
- 这是综合、生成、分类还是分析？
- 可接受的错误率是多少？
- 每次成功完成的价值是多少？
-
手动验证
- 用目标模型测试一个示例
- 评估输出质量和格式
- 识别失败模式
- 估算每项的 token 数
-
架构选择
- 单管道 vs 多 Agent
- 所需的工具和数据源
- 存储和缓存策略
- 并行化方案
-
成本估算
- 项数 × token 数 × 价格
- 开发时间
- 基础设施需求
- 持续运营成本
-
开发计划
- 分阶段实施
- 每个阶段的测试策略
- 迭代里程碑
- 部署方式
应避免的反模式
跳过手动验证：在验证模型能否完成任务之前就构建自动化，当方法存在根本性缺陷时，会浪费大量时间。
单体管道：将所有阶段合并到一个脚本中，使调试和迭代变得困难。应将各阶段分离，并保留持久化的中间输出。
过度约束模型：添加模型自身能够处理的护栏、预过滤和验证逻辑。测试你的脚手架是有帮助还是有害。
直到生产才关注成本：token 成本在规模化时会迅速累积。从一开始就进行估算和跟踪。
完美的解析要求：期望大模型完美遵循格式指令。应构建能处理各种变体的健壮解析器。
过早优化：在基本管道正常工作之前就添加缓存、并行化和优化。
示例
示例 1：批量分析流水线（Karpathy 的 HN Time Capsule）
任务：回顾性评估 10 年前的 930 场 HN 讨论。
架构：
- 5 阶段流水线：fetch → prompt → analyze → parse → render
- 文件系统状态：data/{date}/{item_id}/，其中包含各阶段的输出文件
- 结构化输出：包含 6 个部分，并明确规定格式要求
- 并行执行：15 个工作进程用于 LLM 调用
结果：总成本 $58，执行约 1 小时，输出静态 HTML。
示例 2：架构精简（Vercel d0）
任务：用于内部分析的文本转 SQL Agent。
精简前：17 个专用工具，成功率 80%，平均执行时间 274 秒。
精简后：2 个工具（bash + SQL），成功率 100%，平均执行时间 77 秒。
关键见解：语义层本身就是很好的文档。Claude 只需要能够直接读取文件。
详细分析请参阅案例研究。
指南
- 在构建自动化之前，先通过手动原型验证任务与模型的适配情况
- 将流水线设计为离散、幂等且可缓存的阶段
- 使用文件系统进行状态管理和调试
- 设计提示词，以生成结构化、可解析的输出，并提供明确的格式示例
- 从最简架构起步；只有在证明有必要时才增加复杂度
- 尽早估算成本，并在整个开发过程中持续跟踪
- 构建稳健的解析器，以处理 LLM 输出的各种变化
- 预期架构会经历多次迭代，并为此做好规划
- 测试脚手架究竟有助于还是限制了模型性能
- 使用 Agent 辅助开发，快速迭代实现方案
集成
此技能关联以下技能：
- context-fundamentals - 了解提示词设计中的上下文限制
- tool-design - 设计流水线内 Agent 系统所需的工具
- multi-agent-patterns - 了解何时使用多 Agent 架构，何时使用单一流水线
- evaluation - 评估流水线输出和 Agent 性能
- context-compression - 管理超出限制的流水线上下文
参考资料
内部参考资料：
本合集中的相关技能：
- tool-design - 工具架构与精简模式
- multi-agent-patterns - 了解何时使用多 Agent 架构
- evaluation - 输出评估框架
外部资源：
- Karpathy 的 HN Time Capsule 项目：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 多 Agent 研究：我们如何构建多 Agent 研究系统
技能元数据
创建时间：2025-12-25 最后更新：2025-12-25 作者：Agent Skills for Context Engineering Contributors 版本：1.0.0