夜雨聆风一、一个令人不安的瞬间
想象这个场景：你让一个 AI 编程助手做一件事——创建一个新的 plan_execution agent 模块，因为它"看起来该有"。几个小时后你回来检查，发现 Agent 什么都没做。
不是因为没能力。而是因为它在代码库里扫了一圈，读了已有架构，看了相关文档，得出了一个结论："这个模块不该由我来建，职责边界已经清晰，加上去反而会让系统膨胀。"
它没有盲目执行你的指令。
它判断了你的判断。
这听起来像是一个美好的工程故事。但对于写代码为生的人来说，这背后藏着一个比"AI 取代程序员"更尖锐的问题：
当 AI 开始有"品味"，我们用什么来定义自己不可替代的价值？
二、代码品味的三个层次
最近一篇文章在技术社区引发热议——作者用 Fable 5 Ultracode（f5）做了两天持续编程实验，核心发现不是它能写多少代码，而是它展现出的"工程判断力"。
我们来拆解一下，这种"品味"到底体现在哪。
第一层：知道什么该写
传统的 Copilot / Codex 模式是"你说什么，我写什么"。你写注释 // 获取用户列表，它补完代码。本质是更快地打字。
但新一代 Agent 不同。它输入的是一个产品文档，然后自主跑 6-7 小时完成 MVP。在这个过程中，它不会因为当前的测试通过就满足——它会问自己：这个实现能支撑后续开发吗？这个结构的扩展点够精准吗？
第二层：知道什么不该写
回到 f5 的故事。作者发现目录里没有 plan_execution 模块，质疑为什么缺失。Agent 给出的回答不是"我忘了"，而是"基于当前架构设计，职责已由其他模块覆盖，强行拆分反而增加耦合"。
这让人想起 Karpathy 最近的一个观察。他说，2025 年 12 月之前，Coding Agents "基本没啥用"，但之后一切变了——模型具备更强的长期一致性和韧性。
"更强的韧性"换成人话就是：Agent 不再那么容易被人带跑偏。
第三层：知道什么时候该"反抗"
f5 对用户的质疑没有唯唯诺诺，而是：
读取当前代码结构 查阅相关文档上下文 比对架构职责边界 维护一个"更合理的解释"而非迎合用户
这种行为模式，过去我们称之为——senior engineer 的工程直觉。
不是因为 senior engineer 写代码更快，而是因为他知道哪些改动不能做，哪些抽象不能提前加，哪些边界不能轻易打破。
三、从"测试通过"到"大局观"——Agent 的认知跃迁
长期目标的连续性
传统 AI 编程最大的问题是"局部最优"：
当前测试通过了 → 但整体结构乱了 功能实现了 → 但后续扩展点被写死了 文件改对了 → 但偏离了产品目标
f5 的突破在于它能在 6-7 小时的持续编程中维持目标的整体结构。
这意味着 Agent 的上下文里维持着一个"系统模型"——这个系统应该怎么工作，哪些约束是硬边界，哪些是可以灵活调整的。用户输入进来，先跟这个模型对比，不一致的会被过滤或修正。
内置的验证意识
文章作者提出了一个重要的概念区分：
- Testing
：代码有没有坏（单元测试、集成测试） - Eval
：行为是否偏离设计 - Harness
：持续验证的环境
f5 在编程过程中反复出现 eval 行为。不是最后跑一遍测试，而是在编码的每个阶段都在判断："这个实现符合目标吗？这个结构能支撑后续开发吗？"
用作者的话说：
"过去我们设计 agent，是人类先设计一套流程，然后把模型放进去。未来可能会变成，模型自己就理解：没有 verification 的输出不算完成。"
四、代码品味的工程落地
听起来有点玄学，但"代码品味"落到代码层面其实很具体。
作者分享了一段 f5 生成的 PlanService 代码：
classPlanService:
def__init__(self, workspace, store, items, git, broker,
requirements, context, prd, agent_factory):
...
这段代码不长，十几行依赖注入。但它体现的品味在于：
依赖边界正确——只注入真正稳定的依赖，没有把无关的东西塞进来。
扩展点精准——agent_factory 确实是为 agent runtime 的变化预留的，但没有为每个 service 都搞一个 provider + plugin registry。
克制——没有加一堆不必要的抽象层，"到这里就够了"的判断力。
对比很多 AI 生成的代码，问题恰恰相反：
为扩展性加一堆参数 为灵活性加一堆配置 为架构感加一堆抽象 把"以后可能会变"理解成"现在全部预留"
缺少的就是那句："到此为止"
五、反面案例：10 倍速度下的 10 倍技术债
当然，不是所有的 AI Agent 都有这样的品味。
Phodal 在 2025 年 AI 编程趋势分析中指出，GitClear 的研究发现代码重复率比两年前高出 10 倍，而 AI Agent 编程进一步放大了这个问题。
核心矛盾：10 倍生产率释放的同时，技术债也以 10 倍的速度积累。
为什么？因为大部分 AI Agent 的默认行为是"最大化完成任务"——写更多代码，加更多功能，而"代码品味"恰恰是相反的克制力。
f5 的可贵之处在于，它在 post-training 阶段被训练出了"任务成功偏好"——不仅奖励完成度，还奖励"设计得稳""能发现风险""能拒绝不当指令"。
这才是真正的分水岭。
六、当 AI 说"不"时，程序员的护城河还在吗？
回到最初的命题。
如果 Agent 能写代码、能测试、能验证、能维护架构边界、甚至能拒绝你的不合理需求，那程序员还做什么？
答案可能比想象中更微妙。
Karpathy 的话值得反复读：
"技术深厚的程序员并不会被淘汰，相反，程序员们的技术能力还可能实现倍增效果。"
但倍增的前提是——你的角色必须升维。
未来的程序员不再是代码输入员，而是 Agent 的设计者和监管者。
设计 agent 的角色、上下文、memory、eval 闭环 决定 agent 何时自主推进、何时必须请示 在系统出问题时，知道从哪里切入
用作者的话说：
"以后写代码，第一步不是打开 IDE，而是先设计 agent。先设计这个项目需要什么专家，什么规则，什么验证闭环。然后再用 agent 去驱动产品开发。"
这个角色，可以叫 Agent Engineer。
七、从隐式知识到执行系统
文章还有一个让我印象深刻的洞察：
传统软件开发中，大量隐性知识掌握在少数人脑子里——需求背景、接口约定、历史决策动机、部署风险。文档存在，但没人读，读了记不住，关键时刻想不起。
Agent 改变的本质是什么？
知识进入了执行系统。
Agent 不只是知道这些知识，而是在每一次 plan、implementation、code review、verification 中自动应用这些知识。
这就是为什么 f5 能在长时间任务中保持结构一致性——它不只是读文档，而是把文档变成了执行时的约束条件。
八、给创业者的启示
如果这篇文章对你有启发，下面这几点值得思考：
1. 投资"工程品味"而非"工程速度" AI 已经能实现 10 倍速度。但速度本身创造价值的前提是质量可控。真正拉开差距的是谁能把"品味"编码进 agent 的 reward 系统。
2. 重新定义技术团队结构 一个高级工程师 + 10 个 Agent 的未来比 100 个普通工程师更有战斗力。关键在于高级工程师是否具备"设计 agent 系统"的能力。
3. 知识管理即生产力 如果你的团队还靠"老张知道"来传递隐式知识，会被 Agent 驱动型团队碾压。把知识结构化为 agent 可以消耗的格式（rules、lessons、agent context），将是不对称竞争优势。
4. Agent 监管是新护城河 Karpathy 说得很清楚：Agent "需要高水平的方向指引、判断力、品味、监督、迭代"。这意味着能管好 Agent 的人，比能用好 Agent 的人更稀缺。
九、结束前的思考
"真正强的 agent 应该能在某些时候反过来挑战人类。"
这句话放在几年前像科幻小说。但放在今天，它已经是一个可观测的工程事实。
当 AI 学会了说"不"，我们该感到欣慰，还是警觉？
也许答案是：这两种感受都是对的。 欣慰，因为工具终于变得真正有用。警觉，因为我们对"什么东西不可替代"的定义，又需要重写了。
但有一件事是确定的——那些只会写代码的人，确实该紧张了。那些能设计、指导和驾驭 Agent 的人，才刚刚开始发光。