这一期最值得留下的是一个改名：与其叫 prompt engineering，不如叫 knowledge engineering。你写提示词的时候真正在做的，是把自己脑子里那些说不出来的东西，一点点变成模型能读懂的形式。
与其叫提示词工程，不如叫知识工程——这是个更合理的名字。
想一想你写提示词的时候到底在干什么：你在调动脑子里那些隐性的知识，把它们当作概念，构建出一段能让模型读懂的东西。它本质上不是「写那段话」，而是把自己的隐性知识显性化的过程。
《庄子》里那个故事讲的正是这件事：齐桓公在堂上读圣贤之书，堂下的轮扁在削车轮。轮扁说，你读的那些能写下来的都不算什么——我做轮子，孔做宽了不牢固，做窄了转不动，那个分寸没法直接交给别人。
最重要的东西恰恰是写不下来的那部分。
这也是为什么「知识固化」几乎每个老板都很在意，但一问「什么算知识」，大多数人是懵的。
配套引用了一个框架，注意它不是用来思考问题的，而是用来决定怎么行动的。
两个轴：横轴是任务明不明确，纵轴是所需要的知识是简单还是复杂。
右下角是任务明确且知识简单——举的例子是银行柜台的办事员：你说「孩子在外面上学，我要汇款」，他立刻就能对应到具体业务上。
把任务放进不同象限，该用什么方式介入是不一样的。这比笼统地问「AI 能不能干这个」有用得多。
把一条端到端的链路拆开看：微调和检索增强做的所有事，目的都只是让后面生成的内容准确率更高——它们只是整条链上的一个小环节。
而它们能不能做得更准，取决于评测。
这里有个很硬的判断标准：怎么衡量一家做大模型应用的公司靠不靠谱？看他有没有去做一个评测集，看他的产品是不是默认就以 evaluation first 来做。
这是玩票团队和严肃团队之间最大的区别。
还有一句同样值得记：做个 demo 极其容易，把它产品化极其难。——自动驾驶就是最好的例子。
「先建一套扎实的评测」应该是做任何大模型系统的起点。但现实是，几乎所有项目都把评测当成交付标准放在最后，做完了才 eval 一下。
玩过数据竞赛的人都熟悉那一套：挑一批可能有用的特征，选一个不太会出错的模型，跑一遍最优化，看结果。
说白了这件事挺无聊的——无非是动用你的脑子去选特征。
有个项目干脆把这一步交出去：让模型来写所有特征工程相关的笔记本代码。
人退回到更高一层，只负责定义要做什么。
客户反复问的其实是同一类问题：跑你们的 6B 要多少 GPU？跑 32B 呢？要支持几个并发要多少卡？我现在这批老卡能不能跑得动？
光靠白皮书测试答不了。真正需要的是一个端到端的计算器，能从比较高的层面算出「你该花多少资源来搭这套算力基础」。
关键在于它不能只算模型推理那一侧，还得算最终消费者的 token 消耗量——
比如：一百个人，每人每秒 30 个 token，每天真正在读的时间大概半小时；再对上每张卡的吞吐，一乘一除，需要多少卡就出来了。
把「业务侧的使用量」和「硬件侧的吞吐」放进同一个公式，这个问题才算被认真回答。
跟客户沟通时常出现的落差是：领导在意的是有没有业务价值，但同时也在问「我现在做得到那一步吗、我的基础准备好了吗」。
大概率是不行的——数据、技术基础、组织结构，三样往往都差一点。
所以需要一个能让双方在语义上对齐的概念：LLM ready，配一份从定性到定量的评估表，告诉客户你现在差在哪、差多少。
比空谈业务价值有用，也比直接上手做一个 demo 诚实。
同期还有几个数字可以拿来用：大模型预计带来约两千五百亿的利润增量；国内的大模型投标数据里，中标金额最高的是电信运营商——它的预算分布本身就能看出一些问题。