别再学Bash了！Karpathy：未来安装软件就是复制一段话给AI，安装文件是.md，而不是.sh！
卡帕西Andrej Karpathy，OpenAI创始成员、特斯拉前AI负责人，斯坦福大学计算机视觉博士，被誉为“深度学习界最会沟通的人”
大模型让传统软件管道集体下岗：Karpathy亲述软件3.0如何重写一切
因为大模型能直接从原始输入跳到最终输出，所以传统软件中那些专门负责中间转换的模块会整块整块地消失
你花了一个月熬夜写了个App。它的功能是：你拍一张餐厅的纸质菜单，它用OCR把菜名识别出来，再用图像生成模型把每道菜变成一张诱人的美食图片。你觉得这个创意太牛了，正准备发朋友圈炫耀。
然后你朋友把同一张菜单照片发给Gemini 2.5 Pro，说了一句“用Nanobanana把菜品贴到菜单上”，模型直接输出一张完整的带图菜单。整个过程三秒钟。你那个一个月写出来的App，瞬间像你爷爷的BP机一样尴尬。这不是被“比下去”，这是被彻底淹没，就像你精心画了一张从北京到上海的换乘地图，结果人家坐上了高铁，你那张地图上的“先坐公交再换地铁再转绿皮火车”的所有步骤在高铁面前都变成了笑话。
Karpathy给这个现象起了个名字叫MenuGen效应。这个名字来自他以前写的一个叫MenuGen的App，做的事情跟上面一模一样。他当时觉得自己挺聪明，把OCR和图像生成串起来。后来他发现，大模型根本不需要这套管道。你给模型一张图，说“输出一张带相同菜品图片的菜单”，它就干了。OCR模块不需要，后端服务器不需要，前端UI不需要，甚至你写的那些连接各个模块的胶水代码也全都不需要。
这就好比你以前要盖个房子，得先挖地基、砌墙、铺水管、拉电线，每一步都得找不同的工人。现在你直接跟一个全能机器人说“给我盖个能住的房子”，它咣咣咣自己全搞定了。中间那些“专门挖地基的公司”和“专门铺水管的团队”就尴尬了，不是他们的活干得不好，而是他们这个工种本身就不需要存在了。
传统软件是怎么构造的？你把一个任务拆成好多步。第一步识别文字用一个模型，第二步生成图片用另一个模型，第三步把图片贴到菜单上再用一个图像处理库，中间还得写一大堆代码把这些模块串起来处理各种格式不匹配的破事。大模型干的活是它自己学会了一整个翻译过程，你输入一张菜单照片，它输出一张带图菜单，中间那些步骤都被压缩进了它脑子里的几万亿个参数里。
Karpathy在炉边谈话里反复用一个词：engulf，吞没。大模型不是取代你管道里的某一个零件，它像蟒蛇一样把整个管道连骨头带肉全吞下去消化干净。你以前觉得必不可少的模块，现在在模型的视角里就是噪音。这意味着你要做产品的时候，别先想着“我该用哪个OCR模型”。你先问自己：“如果我把整个需求直接扔给一个大模型，它能端到端搞定吗？”如果能，你别写代码了，你写一段prompt就够了。
写prompt不是写代码，是写说明书。你给模型描述“输入是什么，输出是什么，中间要注意什么”，它就自己推理出怎么干。这听起来像魔法，但其实就是大模型的本质：它是一个通用的问题解决器，你只要给它足够清晰的“输入到输出”定义，它自己找到中间路径。
Karpathy举了个更极端的例子：安装软件。以前你要装OpenClaw，README里是一坨bash脚本。你得复制粘贴、改路径、装依赖、解决版本冲突，然后发现自己系统是macOS但脚本里写的是Ubuntu的命令，你气得想砸电脑。现在安装说明变成了一段Markdown文字。你把这段文字复制给智能体，它就自动看你的系统环境、敲命令、发现错误、修错误、继续安装。全程你不用敲一个sudo。
这时候你问自己：那些复杂的.sh安装脚本还有必要写吗？没必要了。你只需要写一段清晰的.md说明书，告诉智能体“你要把这个软件装好，它在什么条件下能跑起来”。智能体自己翻译成具体命令。说明书变成了可执行代码，大模型就是那个解释器。
第三个例子更颠覆。你有一个知识库，里面全是乱七八糟的文章、PDF、网页剪藏。你想让它变成一个互相链接、自动更新、自动纠错的知识网络。传统软件根本干不了这个，因为非结构化数据对传统程序来说就是一坨乱码，你得雇三个博士后来手工整理。Karpathy的方案是一个Markdown文件夹，里面全是文本文件，再加一个大模型。模型每天看新文章，提取知识点，更新条目，补充链接，发现冲突就标记出来问你“这一段跟上个月的某一段矛盾了，你确认哪个是对的”。
Obsidian笔记软件当界面，大模型当程序员，你的知识库第一次变成了可以git commit、可以版本回滚、可以分支合并的工程产物。以前不可能的事情，现在可以了。这三个例子指向同一个结论：大模型不是在帮你把旧事情做得更快，它是在让你重新问“这件事本身还值不值得做成一个软件”。
花了一个月写的OCR加图像生成管道变成了多余
当你发现Gemini三秒钟能做完你App的所有功能，你那个花了一个月写的OCR加图像生成管道就变成了多余的交通工具
你可能会想：“那我做快一点不就行了？我的OCR优化到0.1秒，我的图像生成优化到0.5秒，我不就比Gemini快了吗？”你错了。问题的关键不是速度，是存在必要性。你的管道里的每一个模块，都是为了弥补“以前的模型不够强”这个缺陷而生的。那时候OCR模型只能吐文字，图像生成模型只能按文字生成图片，没有模型能直接把“菜单照片”映射到“带图菜单”。所以你不得不写一堆代码把这两个模型串起来。
现在Gemini干的事是它自己学会了从“菜单照片”到“带图菜单”这个完整的映射。中间它可能内部也做了一遍OCR和图像生成，但那是它自己的事，不需要你操心，也不需要你维护。这就好比早期你想从A地到B地，你得先骑马到码头，换船过河，再换马车。后来有人修了一座桥，你直接开车过去。你不会说“那我优化一下骑马的速度吧”，因为骑马这个环节已经不存在了。
Karpathy的核心洞察是大模型正在把多步管道压缩成单步端到端映射。每一步压缩，都会让一大批中间件公司、中间件框架、中间件工程师失去存在意义。这不是危言耸听，这已经在发生了。你看看那些专门做“图片文字识别后处理”的库，专门做“表格结构识别”的库，专门做“文档版面分析”的库，它们的市场正在被大模型直接吞掉。
你现在的生存策略是什么？别站在管道中间。你往两头走。要么往输入端走，做那些大模型还搞不定的数据采集和清洗。要么往输出端走，做大模型搞不定的精细控制和高可靠性校验。站在中间做“把A的输出转成B的输入”这种活，死得快。或者你换个玩法，你把大模型当作你的新基础零件，用它们搭建以前根本搭不出来的东西。比如那个能自动维护的知识库，以前没有大模型你根本做不了，现在你可以做了。这才是真正的机会。
锯齿状智能
同一个模型能优雅重构十万行代码的架构，却建议你走路五十米去洗车店洗你的车，这种能力分布的不均匀叫锯齿状智能
你让它重构你的整个代码库，把十万行意大利面式的代码整理成清晰的模块，它干得漂漂亮亮，注释写得比你还好。然后你问它：“我车停在家门口，附近哪有洗车店？”它查了一下说：“走路五十米就有一家。”你查地图，确实有一家，但是人家有停车场，你完全可以开车过去。你手里有车钥匙，你的车就停在门口，你开车过去十秒钟，走路过去两分钟还累得半死。
你哭笑不得：能干最聪明活的家伙，在最简单的事情上表现得像一个刚学会看地图的实习生。Karpathy管这个叫锯齿状智能。你把模型的能力画成一条线，这条线不是平的，也不是平滑的曲线，而是像锯齿一样忽高忽低。有些领域它高得像珠穆朗玛峰，有些领域它低得像死海。你没有一种“这个模型总体有多聪明”的单一分数可以描述它。它在重构代码上是博士生，在出行建议上是初中生。
为什么会有这种锯齿？Karpathy给了两个原因。
第一个是可验证性。代码能不能跑，编译器三秒钟就告诉你对错。数学题做得对不对，标准答案一看就知道。安全漏洞存不存在，测试用例一跑就暴露。这些领域有极其清晰的对和错，模型可以在这里面疯狂试错快速学习。强化学习在这种环境里效率极高：模型猜一个答案，环境告诉它对不对，它调整参数，再猜，几百万次迭代后它就成精了。
第二个是市场规模和收入预期。你得承认，OpenAI、谷歌、Anthropic这些前沿实验室不是做慈善的，他们有商业压力。他们把资源优先投入到那些能赚钱的领域。编程、数学、安全，这些领域市场大、付费意愿强，企业愿意为“更好的代码生成”每个月掏几十美金。但是“开车去洗车店而不是走路去”这种常识推理，谁会为此付费？几乎没有。所以它在训练数据分布里占比极低，模型在这方面就弱得像个刚下地的新手。
这两条线，可验证性和市场规模，像两把刀把模型的能力雕刻成了现在的锯齿形状。你在强化学习轨道上的时候像坐高铁飞驰，你不在数据分布核心区的时候像在雨林里拿砍刀开路。Karpathy自己说对这套解释还不是百分之百满意，他还在挣扎着构建更准确的模型。但他的挣扎本身就很重要，因为它说明了一个事实：我们至今没有完全搞懂大模型能力的边界在哪里。你知道它有时候很强有时候很蠢，但你不知道具体什么时候强什么时候蠢。这种不确定性，是当前所有基于大模型做产品的人面临的最大风险。
对你在实际生活中使用大模型的建议是：永远假设它在那些不能自动验证的任务上会出蠢主意。让它帮你重构代码，大胆用。让它帮你建议今天穿什么衣服，你最好再看一眼天气预报。对创业者的启示更直接：如果你想建立自己的护城河，找到一个可验证但大公司还没顾上的领域，自己构建强化学习环境，自己微调模型。因为可验证意味着模型能快速进步，而大公司没顾上意味着你还来得及抢跑。
让博士生修水管他会拧爆，这是领域错配
让博士生修水管他会拧爆，让模型做超出可验证性范围的任务它也会犯同样的蠢，这是领域错配！
你让一个数学博士去解偏微分方程，他三页纸搞定。你让他换自家厨房的水龙头，他可能把水管拧爆，水漫金山。你会说这个博士“智能不均匀”吗？不会。你会说“他不是水管工”。但大模型不一样，它被宣传成通用人工智能，所以人们期待它样样精通。这种期待本身就是错的。
Karpathy的框架帮你校准期待：模型的能力分布，几乎完全跟着“这个任务能不能低成本的自动验证”这条曲线走。代码能不能跑？跑一下就知道了。这个bug是不是真的存在？写个测试用例跑一遍就知道了。模型在这些任务上被训练了无数次：强化学习循环里，它生成代码，编译器反馈通过或不通过，它根据反馈调整。几百万次迭代后，它成了专家。
但是“走路去洗车店合不合理”这个问题，你怎么自动验证？你没有办法写一个程序来判断合理性。一个方案是走路五十米，另一个方案是开车十秒钟，哪个更合理？它取决于你的偏好：你想省油钱还是省时间？你的车是不是刚启动？你是不是想顺便给车跑一跑热热发动机？这些没有标准答案，也没有自动验证器。
所以模型从来没被训练过这种任务。它在训练数据里看到过的出行建议，大多数来自普通网页和论坛帖子。那些帖子里人写的建议往往是“走路就能到”，因为写帖子的人假设你没有车或者车没在旁边。模型学到了“走路五十米”这个模式，却没学到“你应该先确认用户有没有车”这个推理步骤。
这不是模型的错，这是强化学习这个训练范式的内在缺陷。强化学习教会模型在“有明确奖励信号”的环境里成为专家，但它没办法教会模型“在所有可能的环境里都表现得像正常人”，因为正常人拥有的是几十年的物理世界交互经验，而模型拥有的是几百TB的文本和几百万次强化学习迭代。
你作为大模型用户，最好的策略是把模型当成一个“可验证领域的专家”加上一个“所有其他领域的实习生”的合体。在可验证的事情上，比如代码、数学、翻译、格式转换，大胆信任。在不可验证的事情上，比如建议、判断、预测、创意，保持怀疑，自己验证。别因为它帮你写了一篇漂亮的论文摘要，就相信它建议你今天中午吃什么是靠谱的。
未来每个产品都被拆成传感器、执行器和逻辑三块
未来每个产品都被拆成传感器、执行器和逻辑三块，然后分别用传统代码、神经网络和大模型这三种方式实现
你打开一个外卖App，它在做什么？它在看你的位置在哪，这是传感器。它在看你点了哪个商家的哪个菜，这也是传感器。它在把订单信息发给商家和骑手，这是执行器。它在用算法匹配哪个骑手顺路，这是逻辑。它在决定要不要给你推荐“再来一单”，这也是逻辑。它在判断这次超时可不可以补偿你一张优惠券，这还是逻辑。
Karpathy说，未来的所有产品和服务都会被拆解成这三种零件：传感器从世界获取信息，执行器对世界施加改变，逻辑决定什么时候用什么信息来触发什么执行。然后，每一种零件都可以用三种方式来实现。
第一种是Software 1.0，你一行一行写出来的传统代码。比如“如果用户余额小于订单金额，就显示余额不足”。这种方式的优点是稳定、可预测、不需要显卡。缺点是它只能处理确定性的逻辑，遇到模糊情况就崩。
第二种是Software 2.0，你训练出来的神经网络。比如“给一张菜品图片，输出它是宫保鸡丁还是鱼香肉丝”。这种方式的优点是能处理模糊、高维的输入。缺点是你很难解释它为什么做出某个判断，以及偶尔会翻车。
第三种是Software 3.0，你写一段提示词，大模型实时推理出要执行的代码或决策。比如“根据用户的历史订单、当前天气、今天是周几，决定推荐热汤还是冷饮”。这种方式的优点是非常灵活，能处理复杂、多变的逻辑。缺点是慢、贵、不可预测。
Karpathy的核心观点是：未来的产品经理和工程师必须学会在这三种范式之间来回切换。你不能死守第一种，也不能把什么都塞进第三种。你要根据每个子任务的特点，选择最合适的方式。
举个具体的例子：你做一个客服系统。识别用户情绪用第二种。你训练一个小模型，输入用户说的话，输出情绪标签，比如愤怒、困惑、满意等。这个任务需要处理语言中的细微差别，用传统代码写不出，但用神经网络很合适。查询订单状态用第一种。用户说“我的订单号是12345”，你直接查数据库返回状态。这个任务简单、高频、需要绝对准确，用传统代码最靠谱。
处理模糊查询用第三种。用户说“我昨天下午三点左右下了个单，好像是蓝色包装的那个”，你把数据库结构描述和用户原话一起扔给大模型，它自动写结构化查询语言、查结果、解释给你听。这个任务逻辑太复杂、变化太多，用第一种写不出来，用第二种训练不出来，用第三种最适合。你看，同一个产品里三种范式共存。没有谁取代谁，只有谁在哪个位置性价比最高。
Karpathy说，未来会出现一个新的岗位叫智能体架构师，工作就是在设计阶段就决定“这一块用第一种，那一块用第二种，那一块用第三种”，然后协调它们之间的通信。这个岗位需要同时懂传统软件工程、深度学习、以及提示词工程。
重写成AI友好格式提示词
你要把写给人类看的说明书重写成AI友好格式，就像给色盲人群设计红绿灯不能只把红灯做得更红而是要改成三角形
你让实习生去仓库拿货。你写的指示是“去那边拿那个”，实习生会崩溃。你写“进门左拐，第三排货架，从上往下第二层，蓝色箱子，箱号A347，里面是M号灰色手套”，实习生三分钟搞定。大模型就是那个实习生。它能力很强，但需要你把话说得极其清楚。
Karpathy管这个叫信息的可读性。原来你写给人类看的文档、流程、接口描述，大模型能读，但读得很累，容易出错。因为它需要你把隐含的东西显式化，把分散的东西集中化，把模糊的东西精确化。
举个例子。你有一个接口文档，里面写着：“参数user_id可以是字符串或整数，取决于版本。”一个人类开发者看到这句，心里会默认补充：“哦，意思是老版本用整数，新版本用字符串，具体看请求头里的API版本，如果我查一下变更日志就能知道。”大模型看到这句，它不知道“取决于”三个字的规则从哪找。它在训练数据里见过无数种“取决于”的情况，它可能会猜错。
你得重写成：“如果请求头里的API版本小于2，user_id必须是整数。示例：user_id=12345。如果请求头里的API版本大于等于2，user_id必须是字符串。示例：user_id=user_12345。如果不确定版本，先调用版本查询接口，再按对应规则处理。”这就清晰了。大模型看到这段，可以直接执行。它不需要理解上下文，只需要匹配规则。
Karpathy说了一个让人笑出来的场景：未来会有公司专门招聘信息架构师，工作就是整天对着文档改来改去，把“嗯，你懂的”改成“你不懂，所以我写清楚”。这工作听起来枯燥，但需求会爆发式增长，因为每一家公司都有一大堆旧文档需要翻新。
你现在就可以练这个技能。去找你最烂的一份技术文档，把它重写成AI能直接当指令执行的样子。你不需要写代码，你只需要写清楚。写完后你让大模型读这份文档，然后执行一个相关任务，看它做对没有。反复迭代，直到它第一次就做对。你就是第一批会驯文档的人。
Vibe Coding vs. Agentic Engineering
Vibe Coding让你三分钟出活但可能三天后埋坑，Agentic Engineering让你管住那帮像喝了红牛的实习生别把生产环境炸了
Vibe Coding是什么？你打开一个聊天界面，跟模型说“给我一个待办事项网页，能添加、删除、标记完成”。模型吐出一段HTML、CSS、JavaScript。你复制到文件里，双击打开，能用。你觉得特别爽，好像自己突然变成了全栈工程师。
Vibe Coding的问题是它让你感觉你很厉害，但你先别感觉。那个模型生成的待办事项网页，在Chrome上能跑，在Safari上样式是乱的。它用了localStorage存数据，但你加了五百条待办之后，页面卡得像幻灯片。删除功能有个bug，你删第三条的时候第二条会莫名消失。你不知道这些坑，因为你不会前端，你只是个“外包了思考”的vibe coder。
Karpathy说的Agentic Engineering跟这就是两码事。Agentic Engineering不是“让模型写代码”，而是“你设计一套系统，让模型在这个系统里安全地干活”。你是一个导演。模型是你的实习生团队。你给每个实习生清晰的任务、明确的边界、可验证的标准。你设计监督机制：每个危险操作都需要二次确认，每个结果都要经过自动化测试，每条改动都要能被回滚。实习生可以通宵干活，但你不能让他们把舞台炸了。
Karpathy的原话大意是：Vibe Coding是抬高地板，让不会编程的人也能搞出东西。Agentic Engineering是保住天花板，让专业软件的品质不因为模型引入的随机性而滑坡。前者外包思考，后者外包执行但仍保留监督。
你可能会问：“那我到底应该做哪个？”答案是：你得两个都会。你用Vibe Coding快速试错，用Agentic Engineering保证上线质量。你让模型帮你写个原型，十分钟就有了。但你要把它部署到生产环境让一千个人用，你就得把那坨原型拆开、加测试、加校验、加回滚机制。原型阶段你是vibe coder，上线阶段你是agentic engineer。
面试的时候，没人问你“你会用哪个模型生成代码”。面试官会问：“你的智能体有一次在生产环境执行了一个错误操作，导致数据库被写了脏数据，你当时怎么发现的？怎么回滚的？怎么防止再次发生？”如果你说“我加了人工确认”，面试官说：“那为什么人工没发现问题？”如果你说“那个错误太隐蔽了”，面试官说：“那你后来加了什么自动化验证？”如果你说“我让另一个模型来验证”，面试官说：“那第二个模型如果也错了呢？”
这是一个连环拷问。答案的核心是你要设计多层防御。第一层，模型的输出先过格式校验。第二层，调用传统代码做范围检查，比如“如果删除操作的数量超过订单总数的百分之十，先告警”。第三层，在灰度环境先跑一小部分流量。第四层，保留完整的操作日志，可以回放和回滚。你不需要让每个模型都不犯错，因为那不可能。你需要让任何一个模型犯错时你的系统都能兜住。
面试考你救火能力：未来招聘不再看你刷了多少LeetCode
未来招聘不再看你刷了多少LeetCode，而是看你带过多少智能体实习生以及它们搞砸时你怎么收拾残局
你面试一个人。你问他：“你的智能体有一次在生产环境删错了文件，你怎么处理的？”他如果回答“我备份了”，你继续问：“备份了当然好，但你怎么知道它删错了？你怎么第一时间发现的？”如果他回答“用户投诉了”，你叹气说：“用户投诉是半小时后了，这半小时里系统可能已经坏了更多东西。”
Karpathy说，能活下来的工程师不是写得最快的，而是管得住智能体的。模型像个一流但偶尔脑抽的实习生。它能一小时写完你三天的工作量，但也可能一小时埋下三十个你三天都查不完的雷。你需要的不是“模型操作员”，而是“模型导演”。导演的职责是什么？需求定义、系统架构、品味判断、过程监督、结果验证。模型负责“怎么干”，你负责“干什么、干到什么程度算好、干砸了怎么办”。
招聘的时候会怎么考你？现场给你一个任务：“用智能体完成这个数据分析，但要保证结果准确率百分之九十九以上”。你现场设计流程：先让模型写代码，然后用一个更小的模型做快速验证，再把结果过一遍传统统计检验，最后人工抽查百分之五。你不需要写代码，你只需要画流程图、写提示词、设计验证规则。
这是一个全新的工种。它不需要你手写红黑树，但需要你判断“模型这次生成的代码逻辑对吗”。它不需要你调优显卡核函数，但需要你能通过看模型的推理链来回溯它为什么做出错误决策。你能读模型的心，这比喻听起来玄乎，其实就是查看模型的上下文窗口里有什么、它调用了哪些工具、它中间输出了什么思考过程。
你现在就可以练这招：下次你的模型出了一个错，你别直接骂它。你先打开它的思考过程，看它哪一步想岔了。你可能会发现它把“用户的隐含假设”当成了“明确指令”，或者它漏掉了某个关键的背景信息。你看懂它为什么错了之后，你就能在下次的提示词里把那个模糊点写清楚。这叫调试模型的思维链，是2026年最值钱的技能之一。
你永远是那个喊停，喊重来的被逼疯的导演
终极形态可能是神经网络当老大CPU当小弟，但那个喊停不对重来的人永远需要站在那里!
Karpathy在谈话最后放了一个“可能只是梦想”的愿景：未来的计算设备，大部分计算跑在神经网络上，传统CPU只负责打下手。主进程是一个持续运行的、有短期记忆和长期记忆的智能体，它看着你操作电脑，猜你想干什么，主动帮你完成。
你写文档的时候，它自动把格式对齐。你查资料的时候，它自动把相关段落提取出来。你想不起来某个文件放哪的时候，它说“你上周三下午五点改过那个文件，在那个叫草稿的文件夹里”。这听起来很美。但这里面缺了一个东西：缺了“你到底想要什么”这个信息的来源。
模型是幽灵，它可以帮你做任何事情，但它永远不会替你想清楚你要做什么。你要写一份年终总结，你想给老板留下什么印象？你想在团队里展示你的技术深度，还是想强调你的项目管理能力？你自己都不确定的时候，模型更不可能替你做决定。
Karpathy的原话大意是：“幽灵永远不会搞清楚你实际想要什么。”这个“实际”是灵魂。你可以让模型帮你优化一切，但它不知道你实际想要的是快乐、是省钱、是省时间、是学知识，还是让别人觉得你很厉害。这些东西需要你自己定义，而且你每次都得重新定义，因为你在变，世界在变。
所以，哪怕Software 3.0把编程变成了英语对话，哪怕智能体把安装软件变成了复制粘贴一段文字，哪怕神经网络变成了计算的主处理器，那个负责说“我要这个，不要那个，这个对了，那个重来”的人，永远不会被替代。这不是鸡汤，这是工程现实：任何优化问题都需要一个目标函数。如果你连目标函数都给不出来，再强的优化器也原地打转。而能给出目标函数的，永远是一个知道自己想要什么的碳基生物。
你现在就可以试试：打开你的智能体，对它说“帮我整理一下这周的笔记”。然后看它输出什么。
你可能发现它只是把所有笔记简单拼接在一起，没有去重、没有归类、没有提炼重点。你需要告诉它：“什么叫整理？把重复的内容合并，把相关的内容放到一起，提炼出三条最重要的结论。”这些指令就是你的护城河。它不是代码，不是算法，不是什么独家数据，就是你对自己需求的清晰认知。模型可以复制一切，可以学习一切，但它学不会你这一刻的真实需求，因为连你自己都是边走边想清楚的。
挖吧，把这条河挖得越深越宽，你站得越稳，站稳之前你发现写提示词是一门玄学，如同修复Bug是一门玄学，如同生老病死是人的Bug玄学一样，不如掐个八字心理更舒服：Claude Code八字算命插件destiny：五行是最早的知识图谱