当代码不再稀缺，工程师真正稀缺的是什么

你以为 AI 写代码是提效？不，它是在制造新型技术债。

整个行业都在狂欢。Copilot 补全、Agent 生成、一句 prompt 出一个项目。每个人都在谈 AI Coding 的效率飞升，没人谈它的成本。

但事实是——你让 AI 写出来的每一行代码，都是一笔你尚未审计的债务。

代码从来不值钱。值钱的是对代码的理解、对边界的判断、对上下文的掌控。AI 可以生成代码，但它不理解你的系统为什么长成这样。它不知道三年前那个"临时方案"至今还在跑，是因为没人敢动。

工具越强大，使用者的判断力就越关键。这不是悖论，这是生存法则。

范式不是信仰，是权衡

现在 AI Coding 有三种主流姿势：Vibe、Plan、Spec。

Vibe，完全托管。你把任务丢给 Agent，祈祷它别搞砸。Plan，执行前先让 AI 出一份方案，你对齐后再动手。Spec，从边界设计到方案到任务拆解，每一步都需要人的介入。

没有银弹。说"我们团队全用 Vibe"的人，要么项目足够小，要么还没踩到坑。

一个争议点：Spec 文档要不要提交到 Git？

支持提交的人说，团队可以 review Spec 而非代码，效率更高。反对的人说，Spec 的生命周期随 Task 结束而终止，提交只会增加仓库的熵。

我的判断：不提交。Spec 是过程产物，不是系统资产。保持简洁，别让工具反噬你。

选择范式的标准只有一个：出了问题，你兜得住吗？

注意力是 Agent 最稀缺的资源

我见过太多人犯同一个错误：把整个项目的上下文一股脑喂给 AI，觉得信息越多越好。

但事实是——什么都重要的时候，什么都不重要。长上下文导致 Agent 注意力分散，幻觉频发。你以为给了它全景图，它看到的却是一团噪声。

这不是 AI 的问题，是人的问题。你没有管理好它的认知边界。

渐进式披露——给 AI 一张地图，而不是一整座城市。

在根目录放一个 AGENTS.md，但不要把所有内容堆在里面。它应该是一份导航目录，指向不同子目录下的具体文档。让 Agent 按需加载上下文，聚焦注意力。

▼
jsx
复制代码
# AGENTS.md (导航地图)

本文档提供智能体在代码库中导航的快速指南。

## 快速开始
1. 阅读 docs/architecture.md 了解整体架构
2. 查看 docs/product-specs/ 了解业务需求
3. 遵循 ARCHITECTURE.md 中定义的分层规则

## 常见任务
- 添加新功能：参考 docs/exec-plans/active/
- 修复bug：先检查 docs/quality-scores/
- 重构代码：遵循 docs/design-docs/core-beliefs.md

## 重要链接
- 架构规范：ARCHITECTURE.md
- 设计原则：docs/design-docs/core-beliefs.md
- 质量标准：docs/QUALITY_SCORE.md

多 Agent 并行——用隔离换专注。

还有一种解法：别让一个 Agent 干所有事。后端、前端、QA、Review、Analysis——一个 Agent 在这些角色之间不停切换，上下文断裂是必然的。把不同任务分配给不同 Agent，各司其职。

代价？工作空间共享带来的协作紊乱。解法是 git worktree 做物理隔离，同时靠有效的模块划分和职责边界来消解冲突。Qoder 的 Expert 专家模式，本质上也是这个思想。

并行的前提不是工具，是你对系统边界的清晰认知。

信任不是给的，是建的

这是 AI Coding 最大的悖论：AI 让执行成本暴跌，但我们在生产级项目中依然不敢放手用它。

原因只有两个字：不信任。

不信任的后果是什么？你让 AI 写了代码，然后花同样甚至更多的时间去做白盒审查。开发效率提升了，Review 成本也提升了。闸门告警了。这不叫提效，这叫把成本从左手倒到右手。

解法不是信任 AI，而是建立一套让你不需要信任它的机制。

在 CI 流程中强制拦截。 不要指望 Agent 自觉。在 pipeline 上设卡，让 AI 先过自动化审查，再过人工闸门。审查标准不是"代码写得好不好"，而是"风险能不能兜住"。

▼
jsx
复制代码
---
inclution: auto
name: code review
description: 增量代码审查
---
# 代码审查（code review）

### 流程

1. 通过 git diff 识别代码变动点
2. 识别是否存在协议变更
3. 验证功能正确性与边界条件
4. 风险分级：high/medium/low，附兜底建议
5. 外部依赖 check list
6. 提供灰度/回滚建议
7. 检查监控/日志，编写故障预案

闸门只守两个东西：API 接口文档——限制问题不冒泡到上下游系统。数据模型——守住内部核心计算的边界。

打通全链路闭环。 设计 → 编码 → 评审 → 测试 → 验证 → 观测 → 修复。缺任何一环，AI 的代码就是薛定谔的代码——不跑起来，你永远不知道它是死是活。

给 AI 接入观测手段：后端日志写本地文件而非控制台，连接 Chrome DevTools，通过 REST API 接 Prometheus。把"验证"这个不确定性的环节，变成确定的。

AI First：绝大多数确定性的问题，AI 都可以解决。但"确定性"三个字，是人定义的。

三次法则。 同一个问题，AI 循环三次仍然解不掉，立刻让人介入。别跟 Agent 死磕。你的时间比 token 贵。

Doc GC：文档也是技术债

你给代码上了护轨，很好。但护轨本身也会腐烂。

每引入一份文档，系统的熵就增加一分。过时的 Spec、废弃的 ADR、三个月前的临时设计——它们不会自动消失，只会在仓库里安静地撒谎。Agent 读到过期文档，输出的代码就是基于谎言的代码。

你需要一个专门做文档垃圾回收的 Agent——Doc GC。

别等到文档烂成一片再搞大清洗。高频小规模的清理成本，远低于一次性大规模的重构。这和代码的道理一样：熵增是持续的，对抗它也必须是持续的。

结语：工程师的终局不是写代码

AI 在加速。模型在进化。Agent 越来越强。

但工具越强大，越暴露一个事实：执行力从来不是稀缺资源。稀缺的是判断力和品味。

面对这个变局，工程师真正该做的只有三件事。

设计环境。 不要去微观管理 AI 的每一步操作，而是设计一个让它难以犯错的环境。护轨、闸门、闭环——这些才是你的杠杆。

明确意图。 模糊的指令产出模糊的代码。你对问题的定义越精确，AI 的输出就越可控。意图不清晰，再强的模型也救不了你。

构建反馈回路。 没有反馈的系统必然失控。从 CI 到观测到告警，每一个环节都是你对 AI 的约束力。

技术只是入场券。真正决定你能走多远的，是你在不确定性面前做出正确权衡的能力。