摘要本文系统分析了 Prompt 工程与 Skill 框架的互补关系。首先从概率模型本质出发阐明 Prompt 通过改变模型状态、提供高概率轨道和排除不希望输出来引导大模型但作用有限。文章将任务场景分为概率友好型如非结构化数据处理、风格转换和逻辑严苛型如高精度计算、强逻辑工程指出 Prompt 在前者表现优异而在后者存在局限。随后引入 Skill 框架详细阐述了其如何放大 LLM 的五大原生优势能力模式匹配、结构化填充、头脑风暴、逐项验证、角色扮演并通过文件系统、状态跟踪、测试矩阵、阶段拆分等机制补偿 LLM 的六大短板长上下文衰减、状态跟踪、精确计数、长链推理、执行顺序、确定性工具调用最终构建出可靠、可复现的工程化 AI 应用开发流程。1. Prompt一般来说我们对于 prompt 理解是手把手教大模型按照我们的思路走但如果知道大模型是个概率模型的时候就知道不可能完全控制那么它具体是如何表现的呢从概率角度这个是人为的控制特定 Token 概率的升高以及降低这个是会导致一定的不确定性从这方面我们要知道 prompt 作用是受限的。对于 prompt 来说下面才是它大展身手的三个方面1.1 改变当前状态这个的话就是说比如我输入以一个后端开发者的视角看待当前流程问题那么它就会改变当前模型的状态具体体现在用词、问题视角、风险评估以及结论大胆度等角度发生改变。这个的话如果你玩过角色扮演类的就尤为感觉得出来。1.2 提供了高概率轨道这个的话从输出结构化的角度更容易理解比如1. 理解角度 2. 问题分析 3. 具体结论 4. 改进策略你可以在 prompt 这样输出给大模型人为抬高了这些词的概率就会顺着模板把这个格式复制下去。当然相比单纯文字解释完整样例直接给模型一套完整 Token 序列参考复刻力度极强。这一点的话纯文字只是语义层的引导无法改变 Token 概率分布而格式样例是直接修改了 Token 的概率分布从底层拉高了结构化标记的生成概率。1.3 排除不希望输出这个的话就是不要不要降低大模型对于不要方面的概率但这一点我建议一般使用确定性而非否定性。从这些我们不难理解 prompt 适合哪些场景首先如果从概率角度那么分为两种场景概率友好型靠语义、语感、经验模式就能搞定容错高Prompt 很好用。逻辑严苛型必须 100% 精准计算、严格步骤校验纯 Prompt 很难稳定不出错。擅长的任务场景类别适配原理适用场景实操举例非结构化数据处理模型天然理解文字语义可关联上下文关键词合同条款提取、会议纪要总结、简历信息解析输入杂乱会议录音转文字自动提炼行动项、责任人、截止时间风格转换与润色通过 Prompt 指定角色、文风改变模型输出概率偏好切换表达逻辑技术文档通俗化、职场文书润色、多语种翻译晦涩接口文档改写为新手教程口语对话转换成正式商务邮件启发式推理思维链 CoT提示词引导模型分步输出思考过程拆分复杂问题降低单次预测难度方案策划、头脑风暴、简易代码排错分步拆解活动策划定位人群 → 规划预算 → 选定渠道 → 评估风险分步输出而非直接给最终方案语义分类与意图识别给定固定标签模型快速完成文本归类匹配客服工单自动分类、商品评论情感分析批量用户差评自动划分物流慢、质量差、客服态度差三类不擅长的场景类别核心问题说明高精度数学 / 数值运算纯文本提示易计算出错多位数复杂方程、大规模统计计算需搭配计算器工具辅助强逻辑严谨工程内容输出存在逻辑漏洞完整大型工程代码、复杂电路逻辑、精密财务核算仅 Prompt 无法保证严谨确定性规则校验模型易产生幻觉、编造内容严格合规审查、法律条文逐条比对、精密公式推导长链条精准状态计算长文本下概率误差持续累积多步骤连续数字推演、大规模数据库精准统计从这些方面开始初步尝试写一份 skill。2. Skill 书写对于 skill 可到我的 GitHub 库查看https://github.com/qinchen1314/-skill.git具体讲解优势能力层Prompt 原生擅长这一层是 LLM 不需要外部工具就能做好的事情。Skill 框架的设计放大了这些能力模式匹配与类比迁移LLM 看到的问题 → 映射到已知模式 → 生成符合模式的代码Skill 框架的利用方式references/api-design.md 中的 REST/GraphQL/gRPC 规范 → LLM 读完后能按规范生成风格一致的 APIprompts/phase1-arch.md 中的分层模式模板 → LLM 读完后能把一个模糊需求映射到分层架构references/error-handling.md 中的错误类型体系 → LLM 能在实现时自动分类错误为什么这是优势区LLM 的本质是一个巨大的模式匹配引擎。它看过数十万份 API 设计文档所以给一个规范 一个需求它就知道该生成什么。不需要计算只需要联想。结构化填充Template FillingLLM 看到 JSON Schema / 格式模板 → 填入具体信息Skill 框架的利用方式每个 phase prompt 都包含输出格式的 JSON 模板含字段名、类型、注释LLM 在填充时自然被引导到正确的结构例如 phase0-clarify.md 的 JSON 输出模板把收齐需求这个模糊目标变成了字段级的结构化任务为什么这是优势区填充模板是 LLM 在预训练中做过最多的事情之一完形填空的本质。给一个清晰的模板比给一段文字描述要高效得多。头脑风暴与选项生成LLM 被问到还有什么可能 → 产生多样化选项Skill 框架的利用方式prompts/phase1-arch.md Step 6 的 ADR要求 LLM 列出替代方案 理由prompts/phase0-clarify.md 的 4 层提问框架每层根据用户回答动态调整探索不同方向prompts/phase3-security.md 的 OWASP 映射要求 LLM 从 10 个维度逐一排查为什么这是优势区LLM 在生成多样性选项方面优于人类专家——它不会被自己的经验偏见限制。一个 Go 后端开发者可能永远不会考虑 Python 的方案但 LLM 会。逐项验证Checklist TraversalLLM 看到列表 → 逐项检查Skill 框架的利用方式prompts/phase3-security.md 的 5 维度安全检查清单每个维度 4-5 个子项prompts/phase4-testing.md 的 HTTP 状态码矩阵prompts/phase5-review.md 的评分卡为什么这是优势区给 LLM 一个清单让它逐项回答远比让它自己想想有什么问题要可靠。清单提供了外部记忆锚点LLM 不需要在工作记忆中维护还要检查什么。角色扮演与视角切换LLM 被赋予特定角色 → 按该角色的知识框架思考Skill 框架的利用方式每个 phase prompt 以角色定义开头架构师、开发工程师、安全专家、审查者不同阶段使用不同角色LLM 自然切换知识框架例如 Phase 2 是实现者心态怎么写Phase 5 是审查者心态怎么挑错为什么这是优势区角色提示是 LLM 最成熟的 prompt 技术之一。一个 prompt 你是一个安全专家能激活训练数据中所有安全相关的知识分布。短板能力层需工具/规则辅助这一层是 LLM 即使有最好的 prompt 也无法可靠完成的事情。Skill 框架通过规则约束、文件传递、脚本执行来补偿长上下文衰减与跨阶段记忆LLM 的短板上下文越长早期信息的召回率和精度越低。补偿机制文件系统传递references/struct-export.md// Phase 1 的输出写入文件 .backend-dev/phase1-architecture.json // Phase 2 通过 Read tool 读取而非依赖上下文记忆为什么 prompt 解决不了无论 prompt 写得多好LLM 在处理 5000 token 后对第 100 token 的内容的注意力都会衰减。这不是 prompt 工程能解决的根本性架构限制——但通过把信息持久化到文件就绕过了这个限制。同类补偿同类补偿phase2-impl-record.md 记录每次增量的完成状态防止 LLM 在下一轮忘记已经做了什么.backend-dev/adr/ 目录记录每个架构决策LLM 不需要记住为什么选了 PostgreSQL等历史决策状态跟踪与幂等执行LLM 的短板同一输入在不同调用中可能产生不同输出。无法可靠地回答这个操作之前是否已经执行过。补偿机制增量交付 文件状态每次增量完成后把完成状态写入 .backend-dev/phase2-impl-record.md 下次 LLM 启动时先 Read 这个文件知道我做到哪了为什么 prompt 解决不了LLM 的推理是概率性的给定相同上下文输出分布不同而状态跟踪需要确定性执行过就是执行过不能可能执行过。文件系统提供了确定性——文件存在就是存在不存在就是不存在。精确计数与一致性LLM 的短板无法可靠计数。在长列表中容易遗漏或重复。补偿机制测试覆盖矩阵端点400401403404409422429500POST /v1/auth/login✅✅———✅❌✅视觉上的空洞❌比文字描述更容易被 LLM 注意到。为什么 prompt 解决不了让 LLM 检查是否有遗漏是不可靠的——它的检查和生成使用同一套概率机制检查结果本身也是概率性的。但矩阵表格利用了视觉模式识别空单元格比满单元格更醒目。长链因果推理LLM 的短板超过 3-5 步的因果链推理中间任一步出错会级联放大。补偿机制阶段拆分 隔离验证不要求 LLM 一次性做到 设计 → 实现 → 安全 → 测试 → 审查 而是 Phase 1 输出 JSON → 验证 JSON 格式 Phase 2 读取 JSON → 只负责实现 Phase 3 读取代码 → 只负责安全 ... 每阶段有独立的验证标准为什么 prompt 解决不了这不是 prompt 措辞能解决的问题。长链因果推理需要工作记忆维护多个中间状态而 LLM 的注意力分布随 token 数增加而稀释。通过把链条打断成独立阶段、每阶段验证产出后再进入下一阶段把长链推理转化为了多个短链推理 文件检查点。执行顺序维护LLM 的短板在多步骤流程中容易跳过步骤或调整顺序。补偿机制SKILL.md 中的显式工作流 文件依赖检查SKILL.md 定义了固定的阶段顺序0→1→2→3→4→5 每个阶段的 prompt 开头标注 输入: .backend-dev/phaseN-xxx.json 输出: .backend-dev/phaseN1-xxx.json 如果输入文件不存在阶段无法开始 if [ ! -f $input_file ]; then error_exit 找不到阶段1的输出文件: $input_file fi为什么 prompt 解决不了LLM 天生是联想式而非顺序式的。给定一个任务它可能会自然跳到它最熟悉的实现部分跳过需求分析。文件存在性检查是强制的——文件不存在就是不存在LLM 不能假装它存在。确定性工具调用LLM 的短板对需要精确参数、幂等执行、多次重试的场景直接让 LLM 写 shell 命令不可靠。补偿机制scripts/ Bash tool脚本写好放在 scripts/ 中LLM 只需要执行它脚本有参数校验、错误处理、幂等检查LLM 不需要自己拼命令为什么 prompt 解决不了让 LLM 写 shell 命令是让一个概率系统生成确定性指令——语法错一个字符就失败。而预写脚本把生成任务变成了执行任务LLM 只需要调用 Bash(scripts/orchestrate.sh ...)。总结对比能力维度LLM 原生状态Skill 框架的策略机制模式匹配✅ 极强提供规范模板让 LLM 匹配生成Prompt模板填充✅ 极强JSON Schema 格式模板Prompt头脑风暴✅ 强ADR 选项对比Prompt清单检查✅ 强逐项验证清单Prompt角色切换✅ 极强每阶段赋予不同角色Prompt跨阶段记忆❌ 弱文件 JSON 传递工具 (read/write)状态跟踪❌ 弱增量记录 文件存在性检查工具 规则精确计数❌ 弱覆盖矩阵表格工具 规则长链推理❌ 弱阶段拆分 隔离验证架构约束顺序维护❌ 弱文件依赖链 前置检查规则确定性执行❌ 弱预写脚本工具 (bash)