别再用“写代码”定义现在的开发了，我们其实在做概率操纵
这种认知断层让我意识到，我们对“开发”这个动作的定义，已经完全跟不上工具的进化速度了。
过去十几年，开发是典型的“手工业”。我们追求的是确定性：只要语法正确、逻辑闭环，代码在编译器里通过了，运行结果就是预期的。但现在，随着 LLM 介入，开发状态已经从“确定性构建”转向了某种“概率操纵”。
我尝试过用几个不同的词来描述现在的日常工作，但总觉得差点意思。比如 Tokencrafting（Token 锻造），虽然强调了对输入输出的精准控制，但听起来太像在玩文字游戏，缺乏工程感；再比如 Vibecrafting（氛围塑造），虽然继承了 Karpathy 提到的 Vibe Coding 概念，但它太过于浪漫化，掩盖了我们在 Debug 时面对模型幻觉时的那种绝望感；至于 Agent Steering（Agent 操纵），虽然客观，但它把开发者降级成了“操作员”，失去了某种创造者的认同感。
在我看来，现在的实操状态其实是一个极其快速的闭环：架构定义 → 提示词引导 → 结果验证 → 局部微调。
这个过程最核心的矛盾在于，我们不再是那个搬砖的工人，而变成了拿着图纸、盯着工地的“包工头”。以前我们花 80% 的时间在敲键盘，处理那些琐碎的语法细节；现在我们花 80% 的时间在思考如何通过更精准的指令，让模型在第一次输出时就命中正确的逻辑，而不是在经过 10 次对话、反复提示“你之前的回答有误”之后，才勉强跑通。
这种转变带来了一个很残酷的现实：传统的“编码能力”权重在下降，而“定义问题的能力”权重在飙升。
举个具体的例子，以前实现一个带权限校验的 API 接口，我们需要考虑中间件、拦截器、数据库查询以及各种边界条件的 if-else。现在你只需要给 Agent 一个清晰的上下文定义，它能在一秒钟内生成一个结构完整的代码块。但真正的挑战变成了：你如何确保它没有在某个隐蔽的角落引入一个安全漏洞？你如何验证它生成的异步处理逻辑在并发量达到 1000 QPS 时不会导致内存溢出？
这时候，所谓的“Vibe”其实就是一种极其模糊的经验主义。当你觉得这个模型“感觉对了”，其实是你潜意识里通过快速的验证循环，确认了它生成的概率分布落在了正确答案的区间内。
所以，如果非要找个词来描述这种 AI Agent 工作流，我觉得“编排”或者“引导”比“编写”要准确得多。我们不再是字斟句酌的作者，而是通过设定约束条件，引导模型在概率空间中寻找最优解的调度员。
这种定义上的崩塌其实是好事。它强迫我们从繁琐的语法细节中抽离出来，重新思考软件工程的本质——本质不是写出多少行代码，而是如何高效、准确地将业务需求转化为可运行的逻辑。在这种新语境下，一个能精准定义架构并引导 Agent 快速落地的开发者，其生产力将是传统“纯写代码”开发者的数十倍。
