作者尔东陈在路上发布日期2026-09-24原文https://mp.weixin.qq.com/s/J7IpcLSbXzy8-8e_bsNpsQ上周我同时经历了两个看似毫无关联的场景一场和老朋友的深夜技术交流以及一期线下 AI 培训课程的收官。两个场景聊的内容完全不同——一个聊的是 AI 编程的最佳实践一个聊的是怎么教学员用 AI 写业务文案。但当天晚上我静下来复盘时却惊讶地发现这两件事都在指向同一个结论你说不清楚的东西AI 很容易做偏你能说清楚目标和边界它才更有可能交出符合预期的结果。这可能算不上什么新道理但当它在两个完全不同的场景下同时被深度验证时我觉得特别值得认真和你聊聊。第一幕AI 编程里的“验收条件”在聊 AI 编程的时候朋友提到了一个他最近特别推崇的工作模式goal 模式。思路其实并不复杂把“验收条件”说得足够清楚——这个功能做到什么状态算完成边界在哪哪些情况算异常再让 AI 围绕这些条件循环实现、检查和修正。最后是否完成要看实际验证结果不能只听它说“做好了”。这本质上就是敏捷开发里的 ACAcceptance Criteria验收条件。过去我们写 AC 是为了和人类开发者对齐预期现在我们也用 AC 来驱动 AI。但这中间有个非常容易被忽略的风险人类开发者看不懂需求时可能会来追问AI 也能追问但如果没有澄清就继续执行它可能自行补全假设——然后生成一段看起来能跑、实则方向全偏了的代码。我们当时复盘了一个非常经典的失败案例用 AI 开发一个功能需求描述写的是“用户登录后展示个人信息”。AI 很快生成了代码跑起来也没有任何报错但实际上它根本没有处理登录失效的情况也没有考虑数据为空时的展示逻辑。原因很简单需求里没说清楚这些边界AI 就自作主张假设了一个“最完美”的正常情况。要想避免这种坑靠的不是一遍遍点重试而是靠你在一开始就把验收条件想透、写清**登录有效时**展示哪些字段格式是什么**登录失效时**具体跳转到哪个页面**某个字段为空时**展示什么默认值你的条件越具体AI 跑出来的结果就越容易符合预期。第二幕培训课堂上的“提示词找茬”同一天在我主持的培训课收官环节上我设计了一个互动现场收集学员们自己写的提示词大家一起开会“找茬”。过程非常有意思。有一个学员写的提示词是“帮我写一份商品描述。”我现场问他“什么商品卖给谁在哪个平台发需要多少字有没有必须要包含的关键词”他一下子愣住了反问我“博哥这些……都要我自己想吗”对这些业务背景需要由你提供或确认。AI 可以帮你追问、梳理选项也可以快速生成内容但“你到底要什么”最终还得由你来判断。还有个学员在搭建一个智能客服小工具写完后让 AI 模拟了几轮对话看起来回答得还挺顺畅。但我问他“你有没有把你自己业务的产品知识库喂给它”他说没有觉得 AI 应该什么都知道。结果我们当场一测试AI 回答的全是套话甚至还在煞有介事地编造完全不存在的参数。AI 有时会承认不知道也有时会用听起来极其可信的语言填补它不知道的信息空白。我们不能把识别这种空白的责任完全交给它。你没告诉它你到底卖什么它就可能用“觉得合理”的内容补全答案。因此除了提供产品知识还要明确没有依据的信息不要编造不确定时应说明或转人工。根本原因其实是同一个你看这两个场景下的底层逻辑完全是一样的**在 AI 编程里**验收条件没说清楚AI 可能生成“看起来能跑”的代码**在日常应用里**需求描述没说清楚AI 可能生成“听起来有道理”的废话。AI 很善于补全信息但它补全的方向未必是你想要的。人与人沟通时我们会通过追问和确认消除歧义和 AI 协作也需要建立这样的过程。如果你给出一个模糊需求而它直接按默认假设执行双方就很容易错位。你说清楚了它更容易成为好帮手你说得模棱两可它就可能替你做了一个你根本不想要的决定。那我们到底该怎么做我绝不是劝你每次用 AI 都要写三页纸的需求文档。核心动作其实只有一个把你真正在意的约束条件显式地表达出来。常规细节可以让 AI 提出默认方案但那些你有特殊要求、涉及业务边界、绝对不能碰的雷区必须明确写出来。关键假设也要核对不能因为它看起来合理就直接接受。分享几个我一直在用的实用方法1. 从输出倒推输入动手前先在脑子里想清楚你希望 AI 最终交出来什么字数多少什么格式哪些词绝对不能出现把这些倒推为具体的约束条件。2. 重点锁定边界而不是只看正常流程正常流程容易被注意到真正容易遗漏的是“如果……怎么办”。把你脑海里能想到的异常情况列进验收条件再让 AI 帮你检查是否还有遗漏。3. 用“精确限制”代替“模糊修饰”“尽量不要太长”不如直接写“控制在 200 字以内”“风格轻松一点”不如直接写“不要用专业术语多用口语表达”。AI 能理解模糊描述但具体限制更容易执行也更容易验收。4. 先跑一版再补充约束不用强求一次性写得完美无瑕。先让 AI 出一版试水看看哪里不对然后把“不对”的地方转化为新的约束条件加进去。小步迭代比一步到位现实得多。一个非常有意思的延伸那天晚上的交流结束前朋友跟我说了一句话让我印象极深“博哥这套逻辑其实不只适用于 AI也完全适用于管理和协作。”你平时工作中有没有遇到过这种情况给下属或者同事交待了一个任务自以为讲得很透彻结果交上来的东西完全不是你想要的这时先别急着归因于对方能力不行也要检查自己有没有把真正在意的“约束条件”和“底线”说清楚。不管是你和 AI 协作还是你和人类伙伴协作这个道理一通百通你以为对方懂了绝不等于对方真的懂了。写在最后这一天一场技术交流一场培训收官两个看似平行的场景在同一个结论上汇合了。和 AI 协作的过程常常像照镜子你把问题想得越透彻它越有机会帮你放大效能你如果自己都没想清楚它也可能把混乱放大。当然说清楚需求也不代表 AI 一定能做好。工具能力、可用资料和验证过程同样决定结果。但把目标和边界说清楚是我们自己能先做好的那一步。所以下次在你准备抱怨“这个 AI 怎么这么蠢、一点都不好用”之前不妨先停下来问问自己我真的把我自己想要的东西给它说清楚了吗 
长河君 · 2026/10/10 14:25:38 · 阅读 1.2k 你说不清楚的，AI 永远做不好
作者尔东陈在路上发布日期2026-09-24原文https://mp.weixin.qq.com/s/J7IpcLSbXzy8-8e_bsNpsQ上周我同时经历了两个看似毫无关联的场景一场和老朋友的深夜技术交流以及一期线下 AI 培训课程的收官。两个场景聊的内容完全不同——一个聊的是 AI 编程的最佳实践一个聊的是怎么教学员用 AI 写业务文案。但当天晚上我静下来复盘时却惊讶地发现这两件事都在指向同一个结论你说不清楚的东西AI 很容易做偏你能说清楚目标和边界它才更有可能交出符合预期的结果。这可能算不上什么新道理但当它在两个完全不同的场景下同时被深度验证时我觉得特别值得认真和你聊聊。第一幕AI 编程里的“验收条件”在聊 AI 编程的时候朋友提到了一个他最近特别推崇的工作模式goal 模式。思路其实并不复杂把“验收条件”说得足够清楚——这个功能做到什么状态算完成边界在哪哪些情况算异常再让 AI 围绕这些条件循环实现、检查和修正。最后是否完成要看实际验证结果不能只听它说“做好了”。这本质上就是敏捷开发里的 ACAcceptance Criteria验收条件。过去我们写 AC 是为了和人类开发者对齐预期现在我们也用 AC 来驱动 AI。但这中间有个非常容易被忽略的风险人类开发者看不懂需求时可能会来追问AI 也能追问但如果没有澄清就继续执行它可能自行补全假设——然后生成一段看起来能跑、实则方向全偏了的代码。我们当时复盘了一个非常经典的失败案例用 AI 开发一个功能需求描述写的是“用户登录后展示个人信息”。AI 很快生成了代码跑起来也没有任何报错但实际上它根本没有处理登录失效的情况也没有考虑数据为空时的展示逻辑。原因很简单需求里没说清楚这些边界AI 就自作主张假设了一个“最完美”的正常情况。要想避免这种坑靠的不是一遍遍点重试而是靠你在一开始就把验收条件想透、写清**登录有效时**展示哪些字段格式是什么**登录失效时**具体跳转到哪个页面**某个字段为空时**展示什么默认值你的条件越具体AI 跑出来的结果就越容易符合预期。第二幕培训课堂上的“提示词找茬”同一天在我主持的培训课收官环节上我设计了一个互动现场收集学员们自己写的提示词大家一起开会“找茬”。过程非常有意思。有一个学员写的提示词是“帮我写一份商品描述。”我现场问他“什么商品卖给谁在哪个平台发需要多少字有没有必须要包含的关键词”他一下子愣住了反问我“博哥这些……都要我自己想吗”对这些业务背景需要由你提供或确认。AI 可以帮你追问、梳理选项也可以快速生成内容但“你到底要什么”最终还得由你来判断。还有个学员在搭建一个智能客服小工具写完后让 AI 模拟了几轮对话看起来回答得还挺顺畅。但我问他“你有没有把你自己业务的产品知识库喂给它”他说没有觉得 AI 应该什么都知道。结果我们当场一测试AI 回答的全是套话甚至还在煞有介事地编造完全不存在的参数。AI 有时会承认不知道也有时会用听起来极其可信的语言填补它不知道的信息空白。我们不能把识别这种空白的责任完全交给它。你没告诉它你到底卖什么它就可能用“觉得合理”的内容补全答案。因此除了提供产品知识还要明确没有依据的信息不要编造不确定时应说明或转人工。根本原因其实是同一个你看这两个场景下的底层逻辑完全是一样的**在 AI 编程里**验收条件没说清楚AI 可能生成“看起来能跑”的代码**在日常应用里**需求描述没说清楚AI 可能生成“听起来有道理”的废话。AI 很善于补全信息但它补全的方向未必是你想要的。人与人沟通时我们会通过追问和确认消除歧义和 AI 协作也需要建立这样的过程。如果你给出一个模糊需求而它直接按默认假设执行双方就很容易错位。你说清楚了它更容易成为好帮手你说得模棱两可它就可能替你做了一个你根本不想要的决定。那我们到底该怎么做我绝不是劝你每次用 AI 都要写三页纸的需求文档。核心动作其实只有一个把你真正在意的约束条件显式地表达出来。常规细节可以让 AI 提出默认方案但那些你有特殊要求、涉及业务边界、绝对不能碰的雷区必须明确写出来。关键假设也要核对不能因为它看起来合理就直接接受。分享几个我一直在用的实用方法1. 从输出倒推输入动手前先在脑子里想清楚你希望 AI 最终交出来什么字数多少什么格式哪些词绝对不能出现把这些倒推为具体的约束条件。2. 重点锁定边界而不是只看正常流程正常流程容易被注意到真正容易遗漏的是“如果……怎么办”。把你脑海里能想到的异常情况列进验收条件再让 AI 帮你检查是否还有遗漏。3. 用“精确限制”代替“模糊修饰”“尽量不要太长”不如直接写“控制在 200 字以内”“风格轻松一点”不如直接写“不要用专业术语多用口语表达”。AI 能理解模糊描述但具体限制更容易执行也更容易验收。4. 先跑一版再补充约束不用强求一次性写得完美无瑕。先让 AI 出一版试水看看哪里不对然后把“不对”的地方转化为新的约束条件加进去。小步迭代比一步到位现实得多。一个非常有意思的延伸那天晚上的交流结束前朋友跟我说了一句话让我印象极深“博哥这套逻辑其实不只适用于 AI也完全适用于管理和协作。”你平时工作中有没有遇到过这种情况给下属或者同事交待了一个任务自以为讲得很透彻结果交上来的东西完全不是你想要的这时先别急着归因于对方能力不行也要检查自己有没有把真正在意的“约束条件”和“底线”说清楚。不管是你和 AI 协作还是你和人类伙伴协作这个道理一通百通你以为对方懂了绝不等于对方真的懂了。写在最后这一天一场技术交流一场培训收官两个看似平行的场景在同一个结论上汇合了。和 AI 协作的过程常常像照镜子你把问题想得越透彻它越有机会帮你放大效能你如果自己都没想清楚它也可能把混乱放大。当然说清楚需求也不代表 AI 一定能做好。工具能力、可用资料和验证过程同样决定结果。但把目标和边界说清楚是我们自己能先做好的那一步。所以下次在你准备抱怨“这个 AI 怎么这么蠢、一点都不好用”之前不妨先停下来问问自己我真的把我自己想要的东西给它说清楚了吗