1. 从拒绝到接纳这个工具为什么突然转变了态度第一次接触 Pi 这个工具的人多半会被它的脾气搞得有点懵。你兴冲冲地打开它准备让它帮你干点活结果它回你一句这个我不做或者干脆给你一个极其保守的回复让你觉得这玩意儿是不是故意跟你作对。Pi 1.0 就是这么一个角色——它以会说不是一种美德为设计信条在圈子里出了名。很多人第一次用完之后的第一反应是这东西怎么这么轴但到了 Pi 1.1事情起了变化。它开始说是了。不是那种毫无底线的什么都答应而是在原本拒绝的边界上重新划了一条线把一部分原本被挡在门外的请求纳入了可处理的范畴。这个转变看起来只是版本号从 1.0 跳到 1.1但背后涉及的是整个工具定位的重新思考一个以克制为核心竞争力的工具如何在保持克制的同时又不让用户觉得它没用这个问题其实很多做工具的人都会遇到。你做一个东西一开始为了安全、为了稳定、为了不出错把边界收得很紧结果用户用起来处处碰壁最后干脆不用了。但如果你一上来就把边界放得很宽又容易出各种幺蛾子口碑崩得更快。Pi 的 1.0 到 1.1 的演进本质上就是在回答这个问题克制和可用之间的平衡点到底在哪里。这篇文章适合几类人看一是正在设计或迭代自己工具产品的开发者尤其是那些在安全边界和用户体验之间纠结的人二是已经在用 Pi 或者类似工具的用户想搞清楚 1.1 到底改了什么、值不值得升级三是对工具设计哲学感兴趣的技术爱好者想看看一个靠说不成名的工具是怎么学会说是的。我会从 Pi 1.0 的设计逻辑讲起拆解它为什么要把拒绝当成核心能力然后分析 1.1 在哪些地方松了口、松口的依据是什么最后给出实际使用中的操作建议和避坑经验。2. Pi 1.0 的不字诀拒绝背后的设计逻辑2.1 为什么一个工具要把拒绝当卖点大多数人做工具的思路是我能做什么但 Pi 1.0 的思路是我选择不做什么。这个思路在当时的背景下其实很合理。市面上大量工具为了追求功能覆盖什么请求都接结果就是输出质量参差不齐用户拿到一堆看似有用实则没法用的结果反而增加了筛选成本。Pi 1.0 的判断是与其给你十个半成品不如只给你一个能用的剩下的我直接说不。这个策略的核心假设是用户对被拒绝的容忍度高于对拿到垃圾结果的容忍度。你告诉我做不了我换个别的方式就行但你给我一个看起来像那么回事、实际上没法用的东西我还得花时间验证、修改、甚至被误导这个成本更高。所以 Pi 1.0 把大量边界情况直接挡在门外用一句干脆的不来降低用户的隐性成本。这个逻辑在早期确实奏效了。一批用户因为它不会给我瞎编而留下来形成了口碑。但问题也随之而来当你的拒绝率太高时用户会开始怀疑你是不是能力不行而不是在坚守原则。这就是 Pi 1.0 遇到的天花板。2.2 拒绝的边界是怎么划出来的Pi 1.0 的拒绝边界大致可以分成三类。第一类是能力边界某些请求超出了工具本身的设计范围比如你让它去做一个它架构上就不支持的任务它会直接拒绝。第二类是确定性边界某些请求它虽然能处理但输出结果的不确定性太高它选择不做避免给出误导性内容。第三类是安全边界某些请求涉及敏感或高风险场景它一律不碰。这三类边界里第一类和第三类相对好判断难的是第二类。什么叫不确定性太高这个阈值怎么定Pi 1.0 的做法是宁可错杀不可放过只要它觉得把握不到某个水平就归到拒绝那一档。这就导致很多其实可以处理、只是需要加一些限定条件的请求也被一刀切了。我实际用下来的感受是Pi 1.0 在第二类边界上过于保守。有些任务它明明有能力给出一个有条件的可用结果但它选择直接拒绝用户连一个部分可用的选项都拿不到。这种体验用久了会让人觉得很挫败——你不是不能做你是不愿意做。2.3 用户端的真实反馈从有个性到太难搞Pi 1.0 刚出来的时候社区里的评价两极分化。一部分人觉得终于有个不瞎编的工具了另一部分人觉得这玩意儿也太难伺候了。这两种评价其实都对因为它们对应的是不同使用场景。如果你的需求刚好落在 Pi 1.0 的能力范围内你会觉得它很靠谱但如果你的需求稍微偏一点你就会觉得它故意跟你过不去。关键的转折点在于随着用户基数扩大落在边界外的用户比例越来越高。早期那批核心用户的需求比较集中所以拒绝率还能接受但当更多普通用户进来之后他们的需求五花八门Pi 1.0 的拒绝率就变得很扎眼。这时候有个性就变成了太难搞口碑开始往负面走。这个阶段其实很多工具都经历过。你的核心用户觉得你很好但你的增长用户觉得你不行你到底听谁的Pi 1.1 给出的答案是不是简单地听谁的而是重新定义拒绝的颗粒度。3. Pi 1.1 的是字诀松口的三个层次3.1 从一刀切拒绝到有条件接受Pi 1.1 最大的变化是把原来那种要么全做要么全不做的二元逻辑改成了在什么条件下可以做的条件逻辑。举个例子原来你问一个稍微偏门的问题Pi 1.0 直接说这个我不处理Pi 1.1 会先判断如果加上某些限定条件这个请求是不是可以给出一个可靠的回答如果可以它就会说在某某前提下我可以这样处理。这个转变看起来只是话术变了但底层是决策逻辑的重构。Pi 1.0 的决策是能不能做Pi 1.1 的决策是在什么约束下能做。后者需要更细粒度的能力评估也需要更复杂的输出控制机制。这也是为什么版本号只跳了 0.1但实际改动量不小。我实测下来这个变化对用户体验的提升非常明显。原来被直接拒绝的请求里大概有相当一部分现在能拿到一个带条件的可用结果。虽然这个结果可能不是完美的但至少用户有了一个起点而不是面对一堵墙。3.2 哪些原来被拒的请求现在能过了具体来说Pi 1.1 在以下几类请求上明显松了口。第一类是需要多步推理但每步都确定的请求Pi 1.0 因为担心中间步骤出错而整体拒绝Pi 1.1 改成逐步处理每步都做校验最后给出结果。第二类是输出格式有特定要求但内容本身没问题的请求原来因为格式不确定而拒绝现在通过模板化输出解决了。第三类是需要引用外部信息但信息源可靠的请求原来一律不碰现在在限定信息源范围的前提下可以处理。这三类松口的共同点是它们都不是因为内容本身有问题而被拒绝的而是因为处理方式不够成熟而被拒绝的。Pi 1.1 的改进主要是在处理方式上而不是在原则上的妥协。这个区分很重要因为它意味着 Pi 1.1 并没有放弃 1.0 的核心原则只是在执行层面做得更细了。3.3 松口的边界在哪里什么仍然被拒绝当然Pi 1.1 并不是什么都答应了。它仍然拒绝的请求主要集中在两类。第一类是本质上无法给出可靠结果的请求比如要求预测一个本质上不可预测的事情或者要求处理一个信息严重不足的问题。这类请求不管怎么改进处理方式都没法给出有意义的结果所以继续拒绝。第二类是涉及高风险场景的请求这类边界没有松动因为松动的代价太大。这个边界划分的逻辑是如果一个问题在原则上是可以给出可靠答案的那就想办法去做如果原则上就不行那就继续拒绝。Pi 1.0 的问题在于它把很多原则上可以但做起来麻烦的请求也归到了拒绝那一档Pi 1.1 把这些捞了回来。理解这个边界对用户来说很重要。你不能指望 Pi 1.1 变成一个什么都说好的工具它只是在原来过于保守的地方做了合理的放宽。如果你拿一个本质上无解的请求去问它它还是会说不。4. 实际使用中的操作要点与避坑经验4.1 怎么问才能让 Pi 1.1 更愿意说是用 Pi 1.1 的时候提问方式对结果影响很大。同样的需求你换一种问法可能就从被拒绝变成被接受。我的经验是把请求拆成约束条件 目标的结构比直接扔一个模糊需求过去要好得多。比如你不要问帮我分析一下这个情况而是问在某某条件下帮我分析这个情况的某某方面。前者因为太模糊Pi 1.1 没法判断能不能做倾向于拒绝后者因为约束清晰它能判断出在给定条件下可以处理就会说是。这个技巧的本质是Pi 1.1 的决策依赖于它对请求的理解程度。你给的约束越明确它越容易找到可以做的路径。你给的信息越模糊它越倾向于保守。所以与其抱怨它拒绝你不如先检查一下自己的提问方式是不是太随意了。4.2 遇到拒绝时的正确排查顺序当你被 Pi 1.1 拒绝时不要急着换工具先按这个顺序排查一遍。第一步检查请求里有没有本质上不可处理的部分如果有那拒绝是合理的你需要调整需求本身。第二步检查请求的约束条件是否足够明确如果不够补充约束再试。第三步检查请求是否涉及高风险场景如果是那拒绝是设计使然不用再试了。第四步如果以上都不是那可能是你的请求方式触发了某个保守策略换一种表达方式再试。这个排查顺序能帮你快速定位拒绝的原因而不是盲目地反复尝试。我见过很多人被拒绝之后就开始乱试换各种说法结果越试越乱最后得出这工具不行的结论。其实很多时候只是第一步没做对。4.3 几个容易踩的坑第一个坑是把 Pi 1.1 当成 Pi 1.0 用。有些人习惯了 1.0 的拒绝风格遇到 1.1 说是的时候反而怀疑它是不是在瞎答应。这种心态会让你错过 1.1 真正能提供的价值。正确的做法是对 1.1 说是的结果也做验证但不要预设它一定不可靠。第二个坑是过度依赖条件化请求。虽然加约束能提高接受率但如果你把约束加得太死结果可能变得没有实际意义。比如你为了让它接受把条件限定到一个极端狭窄的范围最后拿到的结果虽然正确但没用。约束是为了让结果可靠不是为了绕过拒绝。第三个坑是忽略版本差异。Pi 1.0 和 1.1 在行为上有明显差异如果你在两个版本之间切换使用要注意同一套提问方式可能得到不同结果。建议固定用一个版本摸清它的脾气之后再考虑切换。5. 从 Pi 的演进看工具设计的取舍之道5.1 会说不是美德这个定位还成立吗Pi 1.1 出来之后有人问它都开始说是了会说不是美德这个定位是不是就废了我的看法是这个定位没有废只是被重新解释了。原来会说不指的是不做没把握的事现在会说是指的是在有把握的前提下尽量做。核心还是把握两个字只是 1.0 把把握的标准定得太高1.1 把它调到了一个更合理的水平。所以与其说 Pi 1.1 放弃了会说不的定位不如说它把不和是的边界重新校准了。一个工具如果只会说不那它最终会变成一个没人用的工具一个工具如果只会说是那它最终会变成一个不可信的工具。Pi 1.1 试图在两者之间找一个可持续的平衡点。5.2 对做工具的人有什么启发如果你也在做工具Pi 的这段演进至少给了三个启发。第一拒绝率是一个需要主动管理的指标。你不能只关注我拒绝了多少不该拒绝的还要关注我拒绝了多少其实可以做的。后者往往被忽略但它对用户体验的影响更大。第二边界不是越紧越好。紧边界能保证质量但会牺牲可用性。你需要根据用户反馈动态调整边界而不是一开始就定死。第三版本迭代不一定要加功能。Pi 1.1 没有加什么新功能它只是把原有功能的边界重新划了一遍但用户体验的提升可能比加十个新功能还大。这三个启发说起来简单做起来难。难就难在你需要有一套机制来持续评估哪些拒绝是必要的哪些是不必要的。Pi 1.1 能做到这一点说明它在 1.0 到 1.1 之间积累了大量用户反馈数据并且有能力把这些数据转化成边界调整的依据。5.3 后续版本可能会往哪走从 1.0 到 1.1 的路径来看Pi 后续的演进方向大概率是继续细化边界而不是简单地放宽或收紧。具体来说可能会在几个方向上做文章一是更细粒度的条件化处理让更多部分可用的请求能拿到结果二是更透明的拒绝理由让用户知道为什么被拒绝、怎么调整三是更智能的请求理解减少因为表达方式导致的误拒绝。当然这些都是基于现有信息的推测。实际会怎么走还得看 Pi 团队怎么权衡。但有一点是确定的只要克制和可用的矛盾还在Pi 的演进就不会停。6. 我在实际使用中总结的几条经验用 Pi 1.1 这段时间我最大的体会是不要把它当成一个问答机器把它当成一个有条件的合作者。你跟合作者沟通的时候会把需求说清楚、把条件讲明白而不是扔一句模糊的话过去等对方猜。用 Pi 1.1 也是这个道理。你给的约束越清晰它越能发挥价值你越随意它越容易拒绝你。另一个体会是拒绝不一定是坏事但频繁拒绝一定是坏事。偶尔被拒绝说明工具在坚守边界频繁被拒绝说明要么你的用法有问题要么工具的边界划得不合理。Pi 1.1 相比 1.0 的最大进步就是把频繁拒绝这个体验改善了很多。如果你之前因为 1.0 太容易拒绝而放弃了 Pi1.1 值得再试一次。最后分享一个小技巧当你拿不准一个请求会不会被接受时先用一个最小化版本试一下。比如你想让它处理一个复杂任务先把这个任务里最核心、最确定的那部分单独拿出来问它。如果这部分它能处理你再逐步加上其他条件。这样既能避免一上来就被拒绝也能帮你摸清它的边界到底在哪里。这个技巧我用下来很稳推荐你也试试。