用途
本技能文档用于指导如何编写有效的提示词（Prompt），以便从大语言模型（LLM）获得可靠、高质量的输出。它面向需要与 LLM 交互的开发者与使用者，提供可复用的原则、技术与模式。
核心原则
- 具体明确：模糊的提示词只会得到模糊的结果。
- 以示例代替说教：示例比单纯指令更有效。
- 结构化输出：明确告诉模型你想要的格式。
- 迭代优化：提示词如同代码，需要测试与打磨。
主要技术
系统提示词（System Prompts）
用于设定模型的角色与约束。文档给出的示例是让模型扮演资深代码审查者，审查代码中的安全漏洞、性能问题和可读性问题，并对每个问题给出严重程度（critical/warning/info）、行号、描述和建议修复方案；若无问题则回复“No issues found.”。
少样本示例（Few-Shot Examples）
提供 2-3 个“输入 → 输出”的示例。文档以自然语言转 SQL 为例，给出两个示例后，再让模型转换新的查询。
思维链（Chain-of-Thought）
要求模型逐步推理。示例用于分析错误并给出修复建议，步骤包括：错误信息含义、可能原因、结合代码上下文的最可能根因、修复方案。
结构化输出（Structured Output）
要求返回 JSON 或特定格式。文档给出一个 JSON schema 示例，包含 summary、sentiment、key_topics、confidence 等字段。
约束与护栏（Constraints and Guardrails）
规则示例：仅使用提供的上下文信息；不知道就回答“I don't know”，不要猜测；回复控制在 200 词以内；回复中不得包含任何 PII（个人身份信息）。
面向代码的模式
- 代码生成：编写一个 TypeScript 函数，说明需求、使用的库，并遵循代码库中的既有模式。
- 代码转换：重构代码以实现某目标，保持行为不变，不改变公共 API（函数签名、导出）。
- Bug 修复：描述 Bug 与错误信息，要求修复并在注释中解释原因。
反模式（Anti-Patterns）
- 过于模糊：“Make this better” → 应具体说明“更好”指什么。
- 过于冗长：把所有内容塞进一个巨大提示词 → 应拆分为聚焦的提示词。
- 自相矛盾：“Be concise but thorough” → 应二选一或明确权衡。
- 缺少示例：复杂格式却不展示期望 → 应添加 1-2 个示例。
- 提示词注入风险：直接包含未分隔的原始用户输入 → 应使用清晰分隔符，如 <user_input>...</user_input>。
实用技巧
- 确定性任务（代码、分类）使用温度 0，创意任务使用 0.7 以上。
- 用边界用例测试提示词，而不仅是正常路径。
- 对提示词进行版本控制——它们与代码同等重要。
- 需要程序化解析响应时，使用结构化输出（JSON）。
- 如果足够精确，更短的提示词往往优于更长的提示词。
适用场景与限制
该文档适用于需要与 LLM 交互并追求稳定输出的场景，尤其是代码生成、代码审查、代码转换、Bug 修复、自然语言转 SQL、文本分类等任务。文档未提供具体平台、收费、价格或效果保证等信息；实际效果取决于所用模型与具体任务，需自行测试与迭代。