引发思考的文章热度
最近看到一篇很火的文章，讲 Sander（首个提示工程指南作者） 总结了1500篇论文，提炼出 5套“最有效”的提示技法。 他强调提示词不是随意对话，而是 设计人机协作的“语言协议”。
文章试图纠正三个误解：
- 大模型变聪明不等于不需要好提示
- 角色扮演等花哨写法其实无效
- 提示词应该工程化而非个人化
但看完后，我同事来了句“听君一席话，如听一席话”。
刚开始我觉得他太刻薄，后来仔细想想，确实如此。
Sander核心观点简析
Sander的核心观点就是：个人用户可以 “对话式调试”，企业产品需要 “标准化prompt”。
这就像有人告诉你： 家里做菜可以随意调味， 餐厅做菜需要标准配方。 然后把这个常识包装成 “Chat-based prompting vs 产品级提示工程”的理论体系。
为什么常识会成为热门
- 第一，AI领域新人太多。 很多人缺乏工程经验，对他们来说这确实是有用的提醒。 就像刚开车的人不知道高速和市区要用不同的驾驶策略一样。
- 第二，包装的技巧。 用专业术语，引用成功案例，看起来很专业。 就像把“开车踩油门，停车踩刹车”说成 “交通工具动力学管理哲学”。
说这些不是为了批评Sander，而是因为我们也遇到了类似的问题。
实践中的挑战：OmniMCP案例
我们正在做的 OmniMCP， 是一个 “chat to create agents” 的平台，允许用户通过对话创建各种行业的Agent。
早期，我们不断自己尝试PGC一些各行各业的 agents。 其中遇到一个问题，就是也要不断地去调试不同场景的 agent 的 prompt。
每个Agent的prompt都不一样，但调试过程中我们发现一个规律： 虽然领域千差万别，但思考框架是相通的。
所以我们开始统一思考方式：不管做什么Agent，都先问几个问题：
- 用户到底想干什么？（不是嘴上说的需求）
- 成功的标准是什么？
- 需要哪些技能才能完成？（数据处理、推理、创作、执行等）
- 缺少哪些信息或工具？
- 这事儿分几步能做完？
- 每一步可能出什么岔子？
- 怎么处理异常情况？
- 什么时候需要问用户？
- 结果用什么方式呈现？
这套问法是固定的，但具体答案完全不同。 就像所有好建筑都得符合力学，但房子长得千差万别。
双向难题与解决之道
- 用户那边： 他们需要通过聊天来摸清楚自己到底要什么。
- 平台这边： 我们需要把聊天内容变成能用的Agent。
而我们解决方案，重点不在于教用户写“完美prompt”，而在于 把聊天过程自动变成Agent结构。
举例说明
用户说“我要个销售助手”：
- 通过对话发现他需要筛客户、跟进度、报价格
- 系统自动拆成三个功能块
- 每个功能块有固定的输入输出
- 用户只需要告知具体的业务规则
这样就解决了Sander文章中的核心矛盾： 既让用户聊得舒服，又让产品跑得稳定。
技法背后的真正价值
Sander的5套技法（少样本示例、任务拆解、自我批评等）本质上都是 把用户的活儿接过来——原来用户要想的事，现在系统帮着想。
更聪明的做法是：让对话本身就包含这些技法。
- 系统问：“能给我举个你之前怎么处理的例子吗？”（触发少样本示例）
- 或者：“这个事儿我计划分几步来做”（触发任务拆解）
用户不需要知道什么是 “Few-shot prompting”， 但通过自然对话就能做出专业级的Agent。
我们也不断通过积累场景，去抽象更多prompt的模版，以及把更多 通用的能力 ，如 MCP工具知识、上下文管理、error handling 等，放到runtime。
未来展望：让更多人“不写提示”
我觉得提示工程的未来不在于让更多人学会写prompt， 而在于让大多数人都可以不需要知道prompt。
就像我们用手机不需要懂电路原理一样，用AI做Agent也可以不需要懂提示工程。
Crypto里，我们经常讲mass adoption。展望让创意描述，变成可用agent的核心在于， 让门槛变低， 而不是让技巧变高。