北京
你有没有遇到过这种情况：让AI帮你实现一个功能，它确实写出来了，但完全不是你想要的意思。不是代码跑不通，而是它"理解"错了方向——你想要的是一把椅子，它给你造了一张桌子。
这种挫败感，做过产品的人都不陌生。无论是跟人协作还是跟AI协作，传达"为什么这么做"的意图，往往比"做什么"本身更难。而跟AI协作时，这个问题被放大了无数倍——它没有人类同事那种"你懂的"默契，也没有多年共事积累的上下文。
一位资深产品人在多年实践中发现，无论做工程师还是产品经理，最核心的基础能力其实是同一件事：有效地传达上下文和意图。开会、交接、协作，几乎每个环节都在做这件事。行业内给它起了各种名字：背景同步、脑力倾泻、上下文传递、对齐目标——本质都一样。
AI为什么总在"跑偏"
跟AI协作时，这种"跑偏"尤其频繁。它可能完全丢失对话线索，可能优先处理了错误的事情然后矫枉过正，也可能实现了一个能跑的功能，但完全偏离了你原本想做的事。更气人的是，这些错误最终都要你为token买单。
问题出在哪？LLM不是人，它没有人类那种对"意图"的本能理解。人类同事能从你的语气、背景、甚至沉默中读出弦外之音，AI只能从你给的文字里猜。而文字能承载的信息，远比你想象中少。
把意图变成可验证的声明
这位产品人给出的解法，是一个叫Semantic Claims的开源项目。核心思路很直接：把自然语言写成的意图声明，跟可执行的测试代码、以及它们所描述的实现，放在同一个地方。
具体来说，就是为每个功能写一段普通人能读懂的声明——描述"这个功能应该表现出什么可观察的行为"，然后紧挨着放上对应的测试用例和实现代码。这样，AI在动手之前，先看到你想要的"行为"，而不是直接去猜你的意图。
这个思路其实借鉴了软件工程里几个成熟的方法：测试驱动开发、Given/When/Then行为描述、验收标准、文档化。这些方法本质上都在做同一件事——把知识和意图编码成结构化的形式，让协作变得稳定。没有这些，产品很难保持稳定。
个人项目更需要这套方法
在个人项目里，这个问题更突出。你既是产品经理又是工程师，尤其在Agentic AI时代，AI成了你的主要协作者。这位作者已经在一个全栈框架项目上埋头干了几个月，用AI辅助实现和设计评审。他发现AI最大的价值在于快速验证方向——一天能跑通5种不同的系统设计原型，这速度是人类做不到的。
但速度越快，意图丢失的风险越大。AI能快速生成代码，但它不知道你为什么选这个方案而不是那个。Semantic Claims想解决的，正是这个"为什么"的传递问题——让AI在动手之前，先理解你的意图，而不是靠猜。
如果你也在用AI写代码，不妨试试这个思路：先写清楚"这个功能应该表现出什么行为"，再让AI去实现。也许能少付不少冤枉的token费。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
