prompt-engineering

本技能主题为提示词工程（Prompt Engineering），目标是让大语言模型输出可靠且高质量的结果。页面内容按以下部分组织。

一、核心原则

1. 要具体：模糊的提示词只会得到模糊的结果。
2. 少说多示范：示例比单纯指令更有效。
3. 结构化输出：明确告诉模型你想要的格式。
4. 迭代：提示词也是代码，需要测试和优化。

二、技术方法

1. 系统提示词：设定模型角色与约束。例如代码审查场景，要求模型作为资深代码审查者，检查安全漏洞、性能问题、可读性问题，并对每个问题给出严重级别（critical/warning/info）、行号、描述和修复建议；若无问题则回复“No issues found.”。
2. 少样本示例：提供 2-3 个输入到输出的示例。例如把自然语言问题转成 SQL，先给出两个示例输入与对应 SQL 输出，再让模型转换用户的查询。
3. 思维链：要求模型逐步推理。例如分析错误时依次说明错误含义、可能原因、结合代码上下文的最可能根因、修复方案。
4. 结构化输出：要求 JSON 或指定格式。示例给出包含 summary、sentiment、key_topics、confidence 的 schema。
5. 约束与护栏：只用所给上下文信息；不知道就回答“I don't know”不要猜测；回复控制在 200 词以内；不得包含任何个人身份信息（PII）。

三、代码相关模式

1. 代码生成：说明要写的 TypeScript 函数、需求列表、使用的库、遵循代码库中的某个示例模式。
2. 代码转换：按目标重构代码，保持行为不变，不修改公共 API（函数签名、导出）。
3. 缺陷修复：给出缺陷描述与错误信息，要求修复并说明原因（写在注释中）。

四、反模式 过于模糊（如“让它更好”）应明确“更好”指什么；过长应拆分为多个聚焦的提示词；自相矛盾（如“简洁但详尽”）应二选一或定义权衡；没有示例的复杂格式应补 1-2 个示例；提示注入风险在于直接拼接原始用户输入，应使用 <user_input>...</user_input> 等清晰分隔符。

五、提示与技巧 确定性任务（代码、分类）用温度 0，创意任务用 0.7 及以上；用边界用例而非仅正常路径测试提示词；对提示词做版本管理；需要程序化解析结果时使用结构化输出（JSON）；若足够精确，更短的提示词往往优于更长的提示词。

关于该技能的具体安装方式、运行命令、支持的模型或平台、是否收费等信息，资料暂未提供。