提示词工程入门:让模型更稳的四条习惯

星期五, 4月 3, 2026 | 1分钟阅读 | 更新于 星期三, 4月 8, 2026

@

「提示词工程」(Prompt Engineering)听起来很高大上,核心其实很简单:把需求说清楚,让模型在有限步数内逼近你要的输出。下面四条是我日常用得最多、也最容易复制给新手的习惯。

1. 说清楚「你是谁、写给谁」

在开头用一两句定义角色受众,输出风格会稳定很多。

例:你是一名技术博客编辑,读者是有 Python 基础的工程师,请用简洁中文解释什么是向量数据库,避免营销话术。

2. 用约束代替形容词

少说「写得好一点」,多说长度、格式、必须包含/禁止的内容。

例:不超过 300 字;分三点列出;每点不超过两行;不要出现「颠覆」「赋能」等空泛词。

3. 给一个「好例子」(Few-shot)

若格式复杂,与其长篇描述,不如贴一段你满意的样例,请模型「按同样结构」生成。

4. 迭代,而不是一次赌对

第一次不满意时,把问题具体化:「第二点太笼统,请补充一个具体场景」「把第三段改成更口语」。


没有万能模板;不同模型、不同温度设置下,同一提示词表现也会变。把上面四条当成检查清单,比收藏一百条「神提示词」更有用。

若你已经在用 IDE 里的 AI 补全,可以把「当前文件路径 + 相关函数签名」一并贴进对话,上下文越完整,胡编概率越低——这和写 RAG、写长对话是同一套逻辑:信息给够,模型才站得稳。

关于我

大家好,我是 lew。这里主要记录学习、工作与阅读里的碎片想法——偏工程实践,少空话;写给自己备忘,也欢迎路过的你顺手翻翻。

经历与方向

从事互联网研发与技术管理十余年,长期负责团队建设、架构演进、技术选型与交付节奏;经历从客户端到服务端、从功能迭代到线上治理的完整链路,习惯在稳定性、成本与交付速度之间做权衡。

技术栈与工程

后端以 GolangNode.js(及常见服务端框架)为主;在分布式与实时服务微服务(RPC、服务发现、可观测)、容器与编排Docker / Kubernetes)、CI/CD 与云上架构上有较多实践。数据侧熟悉多种关系型 / 文档型数据库、缓存与消息队列;关注高可用、安全与弹性,也关注研发协作与发布效率。

AI / 大模型工程化

持续跟进 LLM 落地与工程化,方向包括但不限于 RAGLoRAAgentMCPSKILL 等缩写所指领域;更关心「模型能力」如何与业务约束、数据边界、可观测与发布节奏对齐,而不是单点炫技。文里会尽量直接用这些缩写,避免冗长中文释义。

管理与协作

在敏捷与 Scrum 实践、跨职能沟通与版本迭代上有较多经验;习惯用可度量的目标、评审与回顾推动改进,而不是只堆流程文档。

学习

MBA 在读,侧重创新创业与组织管理,用来补足商业与战略视角,和技术判断互相校准。

博客里可能写什么
  • LLMRAGAgent 等在实际业务里的取舍与踩坑
  • 后端、分布式与可观测的一得之见
  • 工具链、CI/CD 与个人工作流里的「人机协作」节奏

若你也关心 LLMRAG、软件工程或知识管理,欢迎偶尔回来看看。

联系可通过站点页脚邮箱;合作与交流请说明来意。