从"造轮子"到"搭脚手架"：AI 时代下我对代码本质的认知重构

slug

type

Post

status

Published

date

Feb 11, 2026

前言

以下是我近期的四点思考。

一、代码的重心：从"实现逻辑"到"编排 AI"

在传统开发中，程序员的核心价值体现在算法实现和业务逻辑的编写上——代码即产品。但在 Agent 架构里，Model 充当"大脑"，Tools 充当"手脚"，代码的重心自然地从"实现业务逻辑"转向了"编排和约束 AI 行为"。

而编排本身，就是一项高密度的设计活动。Agent 的状态机设计、Fallback 策略、Tool Routing 规则——每一项都是架构级的决策。Prompt 模板的版本控制、A/B 测试框架、动态注入机制——这是严肃的工程实践。输入过滤、输出校验、Cost Control、Rate Limiting——这些 Guardrail 代码是生产环境的安全网。

换言之，代码的关注点从"做什么"转向了"如何让 AI 正确地做"。写的东西变了，但工程的分量丝毫没有减轻。

二、代码的本质角色：确定性的硬约束与可审计的契约

大语言模型本质上是基于概率的预测机器，其最大特征是"模糊性"。而工程化落地时，用户需要的是"确定性"。代码在这里扮演的角色，正是用逻辑的确定性去约束 AI 的不确定性。

以 RAG 系统为例：无论模型多么强大，它的生成边界必须由代码来划定。从数据清洗流程、Chunk 策略、检索的过滤与重排序逻辑，到最终输出的格式校验和事实性核查——这些由代码构建的约束是刚性的、不可协商的。它们是防止 AI 产生幻觉或执行偏差的最后一道防线。

同时，代码也是我们理解和审计 AI 行为的唯一窗口。模型本身是黑箱，我们无法直接观察它"在想什么"。但 Tool-call 的定义、检索的过滤条件、Output Schema 的校验规则——这些代码是我们能够"读懂"一个 AI 系统到底在做什么的地方。当系统出现异常时，我们排查的不是模型权重，而是这些编排代码。

在 AI 系统中，代码既是约束，也是契约。

三、代码的杠杆效应：一行 Prompt 替代百行逻辑

当代码被视为编排层，其核心价值就不再是"写得多精妙"，而是"杠杆效应有多大"。

AI 时代的代码杠杆与传统开发有着质的不同。传统开发中，一行代码替代的是一次手动操作；而在 AI 系统中，一行精心设计的 Prompt 可以替代上百行硬编码的逻辑分支。这种杠杆率是前所未有的——但它也引入了全新的工程挑战：

传统代码 Debug 靠断点和日志；AI 系统 Debug 需要 Trace 整条 Chain，追踪每一步 Retrieval、每一次 Tool-call 的输入输出——这是可观测性（Observability）的问题。同样的 Prompt 可能产生不同的输出，如何在非确定性系统中建立可复现的测试体系——这是可复现性（Reproducibility）的问题。传统软件用单元测试验证正确性，AI 系统则需要构建 Eval Pipeline，用统计指标和人工评审相结合的方式来衡量系统表现——这是评估体系（Evaluation）的问题。

杠杆越大，驾驭它所需要的工程能力就越高。