1. 当鲁班被写进AI提示词一个被大多数人忽略的工程思维切口第一次看到鲁班AI这个组合我脑子里冒出来的不是某个具体工具而是一个很朴素的问题为什么同样是让模型干活有的人写出来的提示词能让模型输出结构清晰、可直接落地的方案有的人写出来的提示词却只能得到一堆正确但没用的废话这个问题困扰了我挺长时间直到我把注意力从模型能力转移到工程思维上才慢慢摸到了一点门道。鲁班这个名字在传统语境里代表的不只是手艺更是一整套先量后画、先算后做、留榫卯余量的工作方法。木匠做一张桌子不会上来就锯木头而是先看料、再放线、然后开榫、最后组装每一步都有明确的输入、输出和验收标准。这套东西放到今天其实就是工程思维的最小闭环需求拆解、约束识别、方案比选、过程控制、结果验收。而AI要真正在复杂任务里发挥作用缺的恰恰不是聪明而是这种把模糊需求变成可执行步骤的工程化能力。我写这篇东西是想把鲁班的创造智慧和AI的工程化落地这两件事拆开揉碎讲清楚。它适合两类人看一类是已经在用AI做实际项目、但总觉得输出差一口气的从业者另一类是刚开始接触AI、想知道怎么把工具用出专业水准的新手。全文不会给你一堆玄乎的概念而是围绕一个核心判断展开——AI的上限由模型决定但AI的下限由工程思维决定而鲁班那套东西正好是工程思维最古老也最扎实的样本。先说清楚一个前提我这里讲的鲁班不是某个具体产品、某个具体模型而是一种方法论隐喻。你可以把它理解成传统工匠的做事逻辑也可以理解成任何把复杂任务拆成可控步骤的思维方式。AI则是当下最典型的能力放大器。两者结合的点在于AI擅长生成和联想但容易发散、容易漏约束、容易在细节上想当然工匠思维擅长收敛和验收但效率低、依赖经验。把工匠的收敛套在AI的发散外面就是这套方法的核心价值。2. 鲁班式工程思维的四个内核以及它们为什么能治AI的发散病2.1 先量后画把模糊需求变成可测量的输入木匠开工第一件事是量尺寸不是画图。这个顺序很关键——先有测量后有设计。放到AI场景里绝大多数人失败的第一步就是跳过测量直接给模型一个模糊指令比如帮我写一个方案帮我优化一下这段代码。模型不是不能干而是它只能按自己的理解去猜你的约束猜错了你还要返工。鲁班式做法的对应操作是在给AI下指令之前先把需求拆成可测量的维度。我自己的习惯是至少拆四层目标是什么、边界在哪里、验收标准是什么、有哪些已知约束。举个具体例子同样是做一个数据看板模糊版是帮我设计一个销售数据看板鲁班版是目标给区域经理看月度销售趋势边界只展示近12个月、只含三个核心指标验收打开后3秒内能看出环比异常约束数据源是两张固定表、不能引入新依赖。后者模型输出的东西可用率会高出一个量级。这里有个容易被忽略的点测量不只是量要什么更要量不要什么。木匠量料的时候会标记出这部分要刨掉AI指令里同样需要显式的排除项。我见过太多人抱怨模型总是加一些没用的东西回头一看指令里根本没写不要加。这不是模型的问题是测量环节漏了。2.2 留榫卯余量给不确定性预留结构化的空间榫卯的精髓在于严丝合缝但不死板留的那点余量是为了应对木材的热胀冷缩。AI落地里最缺的就是这个余量意识——要么把流程卡得太死模型稍微偏离就报错要么完全放任输出什么算什么。鲁班式做法是在关键节点预留结构化的容错空间。具体怎么留我的经验是在流程里设置软约束和硬约束两层。硬约束是不可协商的比如输出格式、必填字段、安全边界软约束是允许模型发挥的比如措辞风格、举例方式、详略程度。把这两层分开写进指令模型就知道哪里必须守规矩、哪里可以自由发挥。这比笼统地说按这个格式来但可以灵活一点有效得多因为后者对模型来说等于没有约束。提示余量不是模糊而是明确哪些地方可以模糊。写指令时把必须和建议分开标注是我实测下来最能提升输出稳定性的一个小动作。2.3 工序分解复杂任务必须切成可验收的段落老木匠做一套家具不会一口气做完而是分成下料、刨光、开榫、试装、打磨、上漆若干道工序每道工序做完都要检查。AI处理复杂任务时最大的坑就是一口气让它干完结果中间某一步理解偏了后面全歪你还很难定位是哪一步出的问题。工序分解的落地方法我总结成一个简单的判断标准每一步的输出必须能被单独拿出来验收。如果一步的输出你没法判断对错说明这步切得还不够细。比如写一份技术方案这种任务直接丢给模型就是一步到位没法验收拆成先列大纲→确认大纲→逐节填充→整体一致性检查每一步都有明确的检查点出错能定位、能回滚。这套逻辑和木匠的试装是一个道理——榫头开好了先别上胶拼一下看看合不合不合还能修。AI流程里对应的就是中间产物先验证再往下走而不是等最终结果出来才发现方向错了。2.4 以用验工成品必须过实际使用这一关木匠做的椅子最后一定要坐上去试试晃不晃、硌不硌坐一下就知道。AI输出最怕的就是看着挺好但用不了。我见过太多方案文字漂亮、结构完整真拿去执行发现缺数据、缺权限、缺前置条件。鲁班式验收的核心是把能用作为唯一标准而不是看起来对。具体操作上我会在验收环节强制问三个问题这个输出能不能直接进入下一步如果不能缺的是什么缺的东西是我没给还是模型没要第三个问题特别有价值因为它能反过来优化你的指令——如果模型反复没要某类信息说明你的指令里没把这个信息标成必填项。3. 把工匠逻辑翻译成AI指令一套可直接抄的提示词结构3.1 为什么大多数提示词看起来专业但不好用网上流传的提示词模板很多是角色任务格式三段式看起来挺规范实际用起来经常翻车。问题出在哪我拆过几十个失败案例发现共性在于这些模板只描述了要什么没描述怎么算做到了。模型拿到这种指令只能按最通用的理解去生成而最通用往往等于最平庸。鲁班式提示词的区别在于它把验收标准前置了。不是先说要什么再想要怎么验收而是一开始就把什么样算合格写清楚让模型在生成过程中就朝着验收标准去靠。这个顺序的调整效果比换模型还明显。3.2 一个带工程约束的提示词骨架下面这个骨架是我自己反复用、反复改出来的不是万能模板但结构可以参考【任务目标】一句话说清楚要产出什么动词开头。 【输入材料】列出所有可用信息标明哪些是必须用的、哪些是参考。 【硬约束】不可协商的项格式、字段、长度、禁止项。 【软约束】可发挥的项风格、举例、详略。 【验收标准】三条以内每条都要能被客观判断。 【工序要求】如果需要分步写明每一步的中间产物。这个骨架的关键不在格式而在每一栏都逼你把模糊的东西说清楚。验收标准那栏最难写但恰恰最有价值——写不出来说明你自己都没想清楚什么叫做好了。3.3 硬约束与软约束的配比经验配比这事没有标准答案但有个经验区间硬约束占三到四成软约束占一到两成剩下是任务描述和材料。硬约束太少输出发散硬约束太多模型变成填空机器失去处理意外的能力。我自己的习惯是凡是涉及下游系统对接的字段一律硬约束凡是给人看的表达一律软约束。这个划分逻辑很朴素机器读的东西不能有歧义人读的东西需要一点弹性。还有个小技巧硬约束尽量用必须包含/必须为/不得出现这种绝对表述软约束用建议/优先/可酌情这种相对表述。模型对这两类词的敏感度不一样混着写容易让它把软约束也当成硬指标输出变得僵硬。4. 真实场景里的工序拆解三个不同颗粒度的落地样本4.1 需求澄清阶段让AI先当问问题的学徒而不是答题的师傅很多人一上来就让AI给答案结果答案不对还得反复改。鲁班式做法是先让AI扮演学徒把不清楚的地方问出来。具体指令可以这样写先不给方案先列出为了完成这个任务你还需要哪些信息按重要性排序每条说明为什么需要。这个动作的价值在于把隐性问题显性化。你自己可能都没意识到某个约束没交代AI一问你就想起来了。我实测下来这一步能砍掉后面至少一半的返工。而且它符合工匠逻辑——学徒上手前先问清楚料在哪、尺寸多少而不是闷头就干。4.2 方案生成阶段分节产出加逐节校验复杂方案不要一次性生成。我的做法是先让AI出大纲人工确认大纲的颗粒度和覆盖范围再逐节生成。每生成一节立刻做一次一致性检查这一节的内容和大纲是否对齐、和前面已生成的章节是否有冲突、有没有引入大纲里没有的新概念。这个流程听起来麻烦但比生成完再大改省时间得多。木匠开榫也是一节一节开、一节一节试不会把所有榫头都开完再统一试装——那样一旦尺寸系统性偏了整批料都废了。AI方案生成同理分节校验就是逐节试装。4.3 交付验收阶段用三问法替代感觉还行验收环节最忌讳看着差不多就过了。我固定用三个问题做验收第一这个输出能不能直接交给下游使用不能的话缺什么第二输出里有没有我没要求但模型自己加的内容这些内容是帮助还是噪音第三如果让我重写一遍指令我会改哪一句第三个问题尤其重要它把每次验收变成一次指令优化。积累下来你会发现很多反复出现的问题根源都在指令的某一句表述上。这跟木匠磨刨刀一个道理——活干得不顺先检查工具别急着怪料。5. 踩过的坑工匠思维用在AI上最容易走偏的三个地方5.1 把工序分解做成过度分解我早期犯过一个典型错误把一个本来两步能完成的任务拆成七八步每步都让AI单独跑结果光是拼接各步输出、处理前后不一致就花掉大半时间。工序分解的目的是让每步可验收不是让每步尽可能小。判断标准应该是这步的输出有没有独立的验收价值而不是这步能不能再拆。木匠分工序也是看需要的——做个小板凳没必要按做大衣柜的工序走。AI任务同理简单任务硬拆反而增加拼接成本和一致性风险。我现在的基本原则是能一次说清楚且能整体验收的不拆说不清楚或验收不了的才拆。5.2 把留余量做成没约束留榫卯余量是为了应对可控的形变不是为了让结构松散。我见过不少人把给AI留发挥空间理解成少写约束结果输出完全不可控。余量的正确用法是在明确的框架内留弹性框架本身必须是硬的。就像榫卯榫头的尺寸是精确的留的余量在榫眼那一侧而且余量大小有明确范围不是随便留。落到指令上就是硬约束一条不能少软约束明确标注范围。比如风格可以口语化但不得使用网络流行语——前半句是余量后半句是边界。只写前半句输出就可能跑偏。5.3 把以用验工做成以我验工验收标准如果只按自己的偏好定很容易陷入我觉得不好就是不好的主观循环。鲁班式验收的精髓是以实际使用场景为准不是以个人审美为准。AI输出尤其如此——你觉得啰嗦的可能正是下游需要的细节你觉得简洁的可能漏了关键约束。我的做法是验收标准尽量写成第三方能判断的形式。比如不写表达要清晰写一个没看过背景的人读完能说出三个核心结论。后者可验证前者只能靠感觉。这个转换看着小实际能大幅减少反复。6. 从会用工具到会设计流程工匠思维带来的能力跃迁6.1 工具能力的天花板与流程能力的地板模型能力一直在涨但你会发现同样用最新模型不同人产出的质量差距并没有缩小反而在某些场景下拉大了。原因在于工具能力决定上限流程能力决定下限。模型再强如果你的流程是丢个模糊指令等结果下限依然很低反过来流程设计得好哪怕用中等模型下限也能稳住。鲁班那套东西的价值本质上就是把下限抬起来。木匠手艺有高低但一个合格的木匠做出来的东西至少是能用的因为他有一套保底的工序和验收标准。AI落地要的也是这个——不追求每次都惊艳但保证每次都能用。6.2 把经验沉淀成可复用的工序卡工匠带徒弟靠的是工序卡——每道工序怎么做、做到什么程度算合格写得清清楚楚。AI流程同样需要这种沉淀。我自己的习惯是每跑通一个任务类型就把指令骨架、验收标准、常见坑整理成一张工序卡下次同类任务直接套。这个动作的长期价值很大。因为AI任务的坑高度重复你今天踩的坑下个月换个项目大概率还会踩。有工序卡至少不会在同一个地方摔两次。而且工序卡会逼你把隐性经验显性化这个过程本身就在提升你对任务的理解。6.3 工匠思维真正稀缺的地方知道什么时候不该用AI这一点容易被忽略但我觉得是最重要的。鲁班式思维的核心不是什么都能做而是知道什么该做、什么不该做、什么该用什么方法做。放到AI场景里就是清楚哪些环节适合交给模型、哪些环节必须人来把关。我的判断标准比较粗暴涉及事实准确性、涉及下游系统对接、涉及不可逆操作的人来把关涉及发散联想、涉及初稿生成、涉及格式转换的放心交给模型。这个划分不是绝对的但有个原则是稳的——越是靠近验收和交付的环节人的介入应该越重。模型可以帮你把活干到八成但最后那两成的判断还是得自己来。这也是我理解的鲁班AI最实在的结合点AI负责把可能性铺开工匠思维负责把可能性收敛成能交付的东西。两者缺一不可但收敛这一环目前还得靠人。