摘要：本文系统分析了 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 读完后能按规范生成风格一致的 API
• prompts/phase1-arch.md 中的分层模式模板 → LLM 读完后能把一个模糊需求映射到分层架构
• references/error-handling.md 中的错误类型体系 → LLM 能在实现时自动分类错误

为什么这是优势区：LLM 的本质是一个巨大的模式匹配引擎。它看过数十万份 API 设计文档，所以给一个规范 + 一个需求，它就知道该生成什么。不需要计算，只需要联想。

结构化填充（Template Filling）

LLM 看到 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 Traversal）

LLM 看到列表 → 逐项检查

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 的短板：无法可靠计数。在长列表中容易遗漏或重复。

补偿机制：测试覆盖矩阵

端点	400	401	403	404	409	422	429	500
POST /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/phaseN+1-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)