技能介绍

先想清楚再写代码：LLM 项目的隐性成本

LLM 项目失败往往不在模型能力不足，而在于跳过了两个关键问题：这个任务真的适合 LLM 吗？整条管线的非确定性成本有没有被控制住？盲目接入 API、直接写自动化管线，结果不是模型输出格式崩坏、成本失控，就是后期发现任务本质上根本不适合用 LLM——比如需要精确计算、100% 准确或强顺序依赖的场景。

一个项目级决策框架

这个技能把工作单元定义为整个项目或多阶段管线，目标是在 10 分钟内帮你拿到五个答案：该不该用 LLM、管线该什么形态、成本大概多少、单 Agent 还是多 Agent、结构化输出怎么设计。

核心流程分七步：

任务-模型适配识别：先过"可推进"和"该停"两张表。可推进特征包括跨源综合、带 rubric 的主观判断、容错批处理；该停特征则是精确计算、实时低延迟、完美准确、专有数据依赖、强顺序依赖。这一步写代码前必须完成。
手动原型验证：把一条代表性输入塞进模型界面，看模型有没有所需知识、能不能产出所需格式、规模上质量预期多高。失败的原型预测失败的自动化，这一步几分钟能防数小时浪费。
管线架构：规范结构是 acquire → prepare → process → parse → render 五阶段。其中 process 是贵的、非确定性步骤，其余阶段确定且可缓存——保持分离，以便只在必要时重跑 LLM 阶段。
文件系统当状态机：用 data/{id}/raw.json、prompt.md、response.md、parsed.json 等中间文件追踪状态，靠文件是否存在判断是否需要处理，删输出即可重跑，每目录独立便于并行。
结构化输出设计：通过节标记、格式范例、理由披露（明确告诉模型"我将程序化解析此输出"）和约束值来约束输出，并用够灵活的 regex 解析器容错，缺节给默认值，解析失败记录供审而非崩溃。
Agent 辅助开发：用 Agent 生成初版实现、测、在具体失败上迭代；大项目拆离散组件各自验证，一次聚焦一个任务。
成本估算：总成本 = (项数 × 每项 token × 每 token 价) + API 开销，批处理加 20-30% 缓冲应对重试；超支时截断上下文、换小模型、缓存复用、加并行。

输出与适用边界

最终产出一个 ProjectPlan 工件，包含 task_model_fit、pipeline、file_state_layout、structured_output、cost_estimate、single_vs_multi 和 downstream_skills，并附带自然语言说明解释决策依据。

注意边界：这个技能只做项目级决策。单工具的 schema、命名、响应格式归 tool-design；Agent 拓扑拆子 Agent 归 multi-agent-patterns；自主控制循环归 harness-engineering；单轨迹 token 效率归 context-optimization。它不替代这些下游技能，而是为它们划定何时该介入。