用途
该技能覆盖三方面原则：识别适合 LLM 处理的任务、设计有效的项目架构、利用智能体辅助开发进行快速迭代。无论构建批处理流水线、多智能体研究系统还是交互式智能体应用，这套方法论均适用。
主要能力
任务与模型适配判断
并非所有问题都适合 LLM 处理，项目第一步是在写代码前评估任务特征是否匹配模型优势。适合 LLM 的任务特征包括：跨来源综合、带评分标准的 субъективное判断、自然语言输出、可容忍错误、批处理、训练数据中已含领域知识。不适合的特征包括：精确计算、实时性要求、完美准确率要求、依赖专有数据、强顺序依赖、要求确定性输出。评估应通过手工原型完成：在自动化之前，取一个有代表性的样例直接交给目标模型测试。
手工原型步骤
验证模型是否具备所需知识、能否产出所需格式、预期质量水平如何、是否存在明显失败模式。手工原型失败，自动化系统也会失败；成功则可作为基线参照和提示词设计模板。
流水线架构
典型结构为：acquire（获取原始数据）→ prepare（转为提示词格式）→ process（执行 LLM 调用，昂贵且不确定）→ parse（提取结构化数据）→ render（生成最终输出）。其中 1、2、4、5 阶段是确定性的，第 3 阶段是非确定性且昂贵的，这种分离允许只在必要时重跑 LLM 阶段，同时快速迭代解析和渲染。每个阶段应保持：离散、幂等、可缓存、独立。
以文件系统作为状态机
用文件系统而非数据库或内存结构追踪流水线状态。每个处理单元一个目录，每个阶段完成由文件存在标记：
data/{id}/ ├── raw.json # acquire 阶段完成 ├── prompt.md # prepare 阶段完成 ├── response.md # process 阶段完成 ├── parsed.json # parse 阶段完成
检查某项是否需要处理即检查输出文件是否存在；重跑某阶段即删除其输出及下游文件；调试可直接读取中间文件。该模式提供自然幂等、易调试、易并行、天然缓存等好处。
结构化输出设计
提示词必须明确格式要求并给出示例，有效方式包括：分节标记、格式示例、说明「我会以程序方式解析」、约束取值。解析代码必须优雅处理偏差：正则灵活、缺省时提供默认值、解析失败记录日志而非崩溃。
智能体辅助开发
模式为：描述目标与约束 → 让智能体生成初版实现 → 针对具体失败测试并迭代 → 根据结果优化提示词与架构。关键实践：前置明确需求、把大项目拆成离散组件、逐组件测试、一次只让智能体聚焦一个任务。
成本与规模估算
公式：总成本 = (条目数 × 每项 token × 每 token 价格) + API 开销。批处理时估算每项输入、输出 token，乘以条目数，并加 20-30% 缓冲应对重试与失败。开发期跟踪实际成本，若显著超估则重新评估方案，可考虑截断上下文、对简单项用更小模型、缓存复用部分结果、并行处理以缩短墙钟时间。
单智能体与多智能体选型
单智能体流水线适用于独立批处理、条目不交互、成本与复杂度更易管理的情况；多智能体适用于并行探索不同方面、超出单上下文窗口、专用子智能体提升质量的情况。采用多智能体的首要原因是上下文隔离，而非角色拟人化。
架构简化
从最小架构开始，只在被证明必要时才增加复杂度。生产证据显示移除专用工具常能提升表现。当数据层文档完善且结构一致、模型推理能力充足、专用工具反而形成限制、维护脚手架的时间超过改进效果的收益时，简化优于复杂。反之，当底层数据混乱、需要模型不具备的领域知识、安全约束需限制能力、操作确实复杂时，复杂度是必要的。
迭代与重构
要预期重构。大规模生产智能体系统需要多次架构迭代。应为变化而构建：保持架构简单且无强倾向，跨模型测试以确认框架没限制性能。
使用方式
该技能提供项目规划模板：任务分析（输入、输出、任务类型、可接受错误率、每次成功完成的价值）→ 手工验证（用目标模型测试一例、评估质量与格式、识别失败模式、估算每项 token）→ 架构选择（单流水线还是多智能体、所需工具与数据源、存储与缓存策略、并行方式）→ 成本估算（条目×token×价格、开发时间、基础设施、持续运营成本）→ 开发计划（逐阶段实现、每阶段测试策略、迭代里程碑、部署方式）。
适用场景
评估任务是否适合智能体而非传统代码、设计 LLM 应用架构、规划带结构化输出的批处理流水线、在单智能体与多智能体间选型、估算 LLM 密集型项目的成本与时间线。
应避免的反模式
跳过手工验证、单体式流水线、过度约束模型、忽视直到生产才考虑成本、要求完美解析、过早优化。
限制
仅当任务明确匹配上述范围时使用。不要将输出视为环境特定验证、测试或专家评审的替代。若缺少所需输入、权限、安全边界或成功标准，应停止并请求澄清。