Prompt工程因AI工具的普及而成显学, 然而Claude工程师的「Fable 5」项目揭示了更为本质的问题, 即用户与模型之间存在着严重的信息传输损耗。这篇文章对「焚诀」烧毁的三层沟通幻觉加以深度解析, 还给出了结构化上下文清单, 用以帮助产品经理借助信息组织思维突破AI沟通瓶颈, 而这套方法论甚至能够反哺日常的跨部门协作。
你觉得自己会用AI，但你正在把大量信息浪费在传输路上。
这并非是你的过错, Prompt工程让你知晓了「如何去表述」, 然而却未曾教导过你一件事情, 那便是模型能够「听见」什么、无法「听见」什么, 以及在你与模型之间那张隐形的信息过滤屏障状为何样。
Claude工程师近期交出了个名为「Fable 5」的事物, 有人将其称作「焚诀」, 这听起来好似某种武林秘籍, 事实上它是一次坦率的技术剖析, 剖析的内容是为何你与模型之间始终存在信息差, 以及究竟该如何切实把这个信息差填平。
你以为你说了，模型根本没收到
先用一个测试, 你写了一个Prompt, 其内容为「帮我分析一下这个产品的用户增长趋势」, 你自认为表述清晰了, 然而模型实际接收到的却是另外一个事物。
你的输入, 经历了你的语言习惯, 经历了省略假设, 经历了上下文剪切, 经历了注意力筛选, 然后模型拿到的是一份打了折扣的信号, 它再回给你答案, 你又在阅读时过滤掉一部分。
一来一回，信息损耗超过50%。
这便是「信息差」的实质所在, 并非模型欠缺聪慧程度, 而是模型跟你之间缺失了一个共有的信息坐标体系。
Claude工程师于Fable 5中指出了一个违背直觉的属实情况, 即许许多多用户把80%的精力投放于「认真写对Prompt」这件事上，仅仅只用了20%的精力在「构建上下文」方面。然而实际上上下文乃是模型能够真正接收的内容输入——Prompt只不过算是上下文当中的一行文字而已。
若是你给予模型一段对话历史开云app官方最新下载地址，还有一份文档, 以及一个角色设定, 这些方才是它理解你的真正根基所在。然而大多数人的做法却是这样的那种情况: 每次都将对话清空, 接着从零开始去撰写一段话, 满心期望模型能够猜到你所想要的究竟是什么。
「焚诀」到底烧掉了什么
“焚诀”这一称呼用于Fable 5, 其缘由在于它致使三层幻觉被烧掉了。
第一层：Prompt足够长就能说清楚。
不对。长度较长的Prompt并不等同于优质的上下文。许多人在Prompt当中堆砌指令, 然而模型真正所需要的乃是结构化的信息, 即你是什么身份, 你处于怎样的做事情的场景之中, 你手头持有的是什么材料, 你所期望达成的输出格式是怎样的。将这些内容写成碎片然后丢入 Prompt, 倒不如采用一种清晰的分层上下文结构。
第二层：模型在「理解」你。
不对。是模型在对你进行「匹配」。它要「匹配」你上下文当中所存在的模式, 并非是去理解你的意图。这便是为何同样的那个问题, 一旦将说法改换一下, 得出的结果就会全然不同。并非是模型不稳定, 而是你的上下文没能给予它充足的约束信号。
第三层：把对话历史留着就够了。
错误。对话存续历程越具延展性, 模型的注意力便愈发趋向离散状态。至关重要的信息隐匿于数千符号碎片所构成的随意交谈之中。Fable 5的付诸行动之方式为: 每当面临关键性质的询问之前, 对上下文予以重新构建——将核心性质的资料内容、当下所设定方向意图、输出之时所需满足的条件要求, 于询问瞬间再次呈现在模型视域范围之内。
三层烧完，剩下的才是真实的信号传输通道。
产品经理为什么最该学这个
每个人都是产品经理这件事儿, 其所表达的含义就是当下所有从事产品工作的个体, 俱都专注于处理同一类事情, 具体指的乃是信息不对称这样一种情形。
当你于和开发沟通之际, 于和设计对齐之时, 于和老板汇报之际, 实际上都在着手做同一件事情: 将你自身脑海之中的上下文, 完整无误地传递至对方那里。这跟向AI提问完全毫无二致了。
倘若你连把向模型传递上下文这件事情做好都做不到, 那你怎能做到把跨部门沟通这件事情做好, 又怎么可能做好?
寓言5的核心办法, 置于产品经理平常之时, 实则是一个「结构化上下文列表」:
诸多产品经理撰写PRD时倍感痛苦, 缘由在于他们越过了背景信息以及场景定位, 径直去写需求条目。随后开发前来询问三个问题, 而答案全然涵盖在上下文中, 可你并未给予, 进而导致来回扯皮。
和AI沟通暴露了你的信息组织能力，因为AI不会主动追问。
真正的高手怎么喂模型
Fable 5里举了一个例子开云app在线入口，我转述一下。
一名新手, 让Claude帮忙写一个数据分析脚本, 还有一名老手, 同样让Claude帮忙写一个数据分析脚本。
新手的做法：
「帮我写个Python脚本分析用户留存数据。」
模型给了个通用模板开云真人官方下载，改了半天才勉强能用。
老手的做法：
先是丢过去三行, 其一为数据表的字段结构, 也就是Schema, 其二是分析的业务目标, 所谓增长团队要看30日留存拐点即为此, 其三是输出要求, 即出直接可运行的Python脚本, 且带有注释。
然后问：「基于这些，写一个脚本。」
模型给的几乎可以直接跑。
在何处存在区别呢? 并非是老手在撰写Prompt方面更为娴熟, 而是老手在组织上下文这一方面更具有能力。
他将「背景→目标→约束→输出格式」这四个要素, 一次性全部给予了。新手, 仅仅只是给了「输出格式」这一项, 而且, 表述得还不够具体。
结论：信息差从哪来，就从哪补
Claude工程师交出Fable 5这一情况, 真正值得予以关注的并非技术方面的细节, 而是一种行业发出的信号, 即AI公司已然开始承认, 问题并非存在于模型那一侧, 而是在于用户这一侧的信息组织形式之上。
这实际上是件好事情, 这表明你用不着去等待更为强大的模型, 你当下就能够借助现有的模型, 将事情做得更加出色。
方法很简单：
每次进行提问之前, 要先问问自己, 我有没有给予模型完整的背景, 以及目标、场景、约束, 不要依靠对话历史, 而是要借助即时上下文, 在关键提问之前, 重新构建一次上下文。把给予模型的上下文, 当作给予同事的简要说明, 如果觉得给予同事这样的简要说明是不够的, 那么给予人工智能的同样也是不够的。
信息差从来不是技术问题，是信息组织问题。
而这个问题, 产品经理是特别擅长去解决的, 只是好多人并没有意识到, AI对话恰恰就是练习这个能力的最为理想的训练场。
标签： AI沟通 上下文组织 Prompt工程 信息差 产品经理
还木有评论哦，快来抢沙发吧~