1957 年，IBM 推出了 Fortran。今天回头看，它是现代高级编程语言的重要起点；但在当时，很多老程序员并不兴奋，反而很抗拒。

原因很简单：以前写程序，大家要手工处理内存、寄存器、机器指令，每一行都像亲手打磨零件。突然有一个工具说：“你写公式就行，机器指令我帮你翻译。”很多工程师的第一反应不是解放，而是不信任。

他们担心编译器生成的代码太慢，担心机器不懂优化，更担心“不是我自己写的代码，我凭什么相信它？”

但历史已经给出答案：除了极少数底层系统场景，今天几乎没人会手写汇编语言，也没人会在提交代码前，把编译器生成的汇编结果一行一行看完。因为一旦抽象层级提高，人们就不会再退回到更原始的工作方式。

现在，类似的事情又发生了。

AI 可以在几秒内生成几百行、上千行代码。很多开发者却还在深夜盯着红绿 diff，一行一行检查，生怕漏掉一个隐藏问题。问题是：当代码生产速度已经进入机器时代，审查方式还停留在人工时代，效率自然会被拖垮。

为什么逐行审查 AI 代码，越来越像一种表演

过去我们重视 Pull Request 里的逐行代码审查，是因为代码主要由人写出来。

人会犯错：可能把 == 写成 =，可能少写一个边界判断，可能在周五下午精神涣散时留下低级 Bug。所以同事之间互相看一遍代码，确实有用。

但 AI 改变了这个前提。

一方面，AI 的生成速度太快了。一个智能体可能在十几秒内重构十几个文件、修改两千行代码；而一个工程师认真读完这些内容，可能需要一个多小时。生产速度和审查速度完全不对称。

另一方面，AI 写出来的代码往往看起来很漂亮：变量命名通顺，注释完整，格式整齐，甚至文档说明都比很多人写得更像样。

这反而会带来新的问题。面对一大段外观漂亮的代码，人的注意力会很快下降。看到第 400 行时，大脑已经开始麻木；看到最后，很可能只剩下一个动作：点“通过”。

表面看你在严格把关，实际上你是在用大量注意力换取心理安慰。

AI 会幻觉，但靠眼睛抓幻觉并不靠谱

有人会立刻反驳：编译器和 AI 不一样。编译器是确定性的，不会凭空发明指令；但 AI 是概率模型，它会胡说，会生成不存在的方法，会写出看似合理但实际错误的逻辑。

这个反驳是对的。AI 确实会产生幻觉。

但关键在于：AI 的幻觉通常不是那种一眼可见的语法错误。

它更可能写出这些问题：

• 调用一个真实存在的库，但使用了当前版本并不支持的参数。
• 在重试逻辑里漏掉一个清理步骤，只有网络超时到第 3 次时才出问题。
• 写出一段看起来没问题的并发代码，普通测试都能通过，但高并发下会卡死。
• 生成一段格式完美、注释完整的函数，但业务边界条件理解错了。

这些问题靠深夜盯着 diff 很难发现。更合理的方式，是把检查交给自动化系统：类型检查、单元测试、集成测试、压力测试、沙箱运行、依赖校验、运行时监控。

换句话说，面对 AI 生成的代码，我们不应该把自己变成“人工语法检查器”，而应该把精力放到规则、合同、测试和结果证据上。

三道防线：把风险交给系统，而不是眼力

真正高效的团队，不会把希望寄托在“有人能看完 2000 行 diff”上。他们会把流程拆成三道防线。

第一道防线：上游定规则

在 AI 开始写代码之前，先把关键边界定清楚。

这部分应该由人类架构师和高推理能力的 AI 一起完成，重点不是立刻写函数，而是确认：

• 数据表结构是什么。
• 接口入参和出参是什么。
• 哪些字段必填，哪些字段允许为空。
• 状态如何流转，哪些状态不能直接修改。
• 错误如何返回，日志如何记录。
• 哪些业务规则绝对不能违反。

这一步就像盖楼前先画图纸。如果图纸清楚，AI 写代码时就不容易跑偏；如果一开始没有约束，AI 就会在一张白纸上自由发挥，后面再想纠正就麻烦了。

第二道防线：中场流水线

真正开始写代码时，也不要让一个模型从头干到尾。

更合理的做法是让不同角色分工：

• 快速编码 Agent：负责实现业务逻辑，追求速度和吞吐量。
• 审查 Agent：只负责检查代码是否符合事先约定，不直接改代码，避免既当运动员又当裁判。
• 重构清理 Agent：负责删除重复逻辑、整理结构、减少技术债。

这样做的核心不是“让 AI 更像人”，而是让 AI 像流水线一样工作。每个环节只负责一件事，错误更容易被发现，也更容易被拦截。

第三道防线：下游看证据

代码写完后，最重要的不是继续逐行读代码，而是看它能不能通过真实验证。

比如：

• 单元测试是否通过。
• 接口合同是否被遵守。
• 集成测试是否能在干净环境里跑通。
• 压力测试下错误率是否可控。
• 关键业务流程是否能完整完成。
• 真实页面是否能正常点击，响应是否明显卡顿。

人类工程师最后应该看的是“证据”：测试通过了吗？错误率如何？体验是否顺畅？而不是盯着几千行代码差异，试图靠直觉找问题。

人类应该做什么：从看代码，到定系统

这并不意味着人类不重要了。恰恰相反，人类要做的事情更难，也更有价值。

你应该把时间花在这些问题上：

• 业务到底要解决什么问题。
• 哪些边界情况必须处理。
• 用户体验哪里不自然。
• 系统失败时如何兜底。
• 哪些规则关系到安全、成本和数据正确性。
• 产品上线后，真实用户是否真的满意。

不要把最宝贵的大脑浪费在机械检查上。人应该像建筑师，而不是砖块质检员。

为什么传统 IDE 和单个终端也开始不够用了

新的工作方式需要新的工具。

传统 IDE 的设计思路通常是：一个人，一个文件，一个光标。但 AI 可能一次修改几十个文件。这时编辑器只能给你扔出一个巨大的 diff，让你继续逐行看。工具本身的交互方式，已经跟不上 AI 的生成速度。

单个终端也有问题。你可能开很多窗口：一个跑 AI 编码，一个跑测试，一个看日志，一个查文档。窗口之间来回复制粘贴，任务状态靠脑子记。如果某个命令卡在“是否继续”的确认提示上，整个流程就会悄悄停住。

所以，现代 AI 工程需要一种新的组合：既有强大的自主编码引擎，也有一个能统一调度多个 Agent 的终端工作台。

下面这个结构图，展示的就是这种协作方式。

# 中文注释：人类架构师先定义合同、规则和体验边界。
# 中文注释：Polter 作为多智能体终端工作台，负责任务调度、自动应答和状态保存。
# 中文注释：agy 负责自主编码、调用工具和子代理。
# 中文注释：沙箱测试负责给出可验证证据，清理代理负责减少技术债。
┌─────────────────────────────────────────────────────────────┐
│                       HUMAN ARCHITECT                       │
│           (Defines Contracts, Rules & UX Boundaries)        │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                 POLTER (Ghostty Multi-Agent Cockpit)        │
│  - Millisecond Quiescence Detection   - Persistent Task Bus │
│  - Autonomous Prompt Auto-Responder   - Shared Local State  │
├──────────────────────────────┬──────────────────────────────┤
│                              │                              │
│   Tab 1: Architect / Sup     │   Tab 2: agy (Antigravity)   │
│   (Claude Opus / Orchestrator)│   Autonomous Engine & Skills │
│   - Creates Task Cards       │   - Deep Codebase Invariants │
│   - Sets OpenAPI / Schemas   │   - Subagents & MCP Tools    │
│   - Delegates to Workers     │   - High-Throughput Coders   │
│                              │                              │
│   Tab 3: Sandbox / Stress    │   Tab 4: Cleaner / Sweeper   │
│   - Headless Docker Sandbox  │   - Cross-file AST Refactor  │
│   - k6 Load & Fuzz Testing   │   - Dead Code Elimination    │
│   - Emits Verified Evidence  │   - Anti-Corruption Layer    │
└─────────────────────────────────────────────────────────────┘

agy：不是简单补全，而是自主编码引擎

素材中提到的 agy，也就是 Antigravity CLI，并不是那种只帮你补全下一行代码的小工具。它更接近一个可以自主完成工程任务的智能体环境。

它的特点可以简单理解为三点：

• 规则可沉淀：你可以把团队的架构规范、编码要求、禁止事项写进规则文件。AI 在工作时会带着这些约束，而不是每次都靠你临时提醒。
• 工具可扩展：它可以接入本地工具、文档、数据库诊断能力等上下文资源，让 AI 不只靠猜，而是能读取更真实的项目信息。
• 任务可拆分：遇到复杂功能时，它可以拆出子任务，让不同的子 Agent 分别处理研究、编码、重构等工作，最后再汇总结果。

这类工具的价值，不是让 AI 更会打字，而是让 AI 更像一个能遵守工程规则的协作者。

Polter：把多个终端变成协作车间

如果说 agy 是强力的编码引擎，那么 Polter 更像一个调度多个 Agent 的本地控制台。

它想解决的问题很实际：多个 AI 终端一起工作时，怎么避免它们各干各的、状态丢失、互相不知道进度？

Polter 提供了几个很关键的能力：

• 任务持久化：任务不是只存在于聊天记录里，而是会被记录下来。即使电脑重启，任务状态也还能找回来。
• 自动处理确认提示：很多命令会停在“是否继续”这类提示上。Polter 可以识别终端是否卡住，并在安全场景下自动回答，减少人工盯着屏幕的时间。
• 本地消息协作：不同终端之间可以通过本地文件通道交换信息，比如编码 Agent 完成了模块，测试 Agent 马上拿到结果并继续验证。
• 用证据交接：最后交给人看的，不应该是一堆庞大 diff，而是一份更清晰的总结：哪些任务完成了，哪些测试通过了，有没有回归问题，哪里可以体验结果。

这套流程的目标很简单：让人少做重复确认，多看关键结果。

以后拼的不是谁读代码更快，而是谁更会设计系统

Fortran 出现时，程序员并没有消失。他们从手工摆弄机器指令，转向了更高层的软件设计。

今天也一样。AI 把写代码的成本大幅降低之后，真正稀缺的能力变成了：

• 能否把复杂需求拆清楚。
• 能否提前定义稳定的接口和数据结构。
• 能否建立自动验证机制。
• 能否判断产品体验是否真的合格。
• 能否让多个 AI 工具在规则下协作，而不是失控地生成一堆代码。

所以，别再把自己当成 2000 行 diff 的人工扫描仪。把语法生成交给机器，把规则、证据和产品判断留给自己。

新的抽象层已经来了。真正重要的不是你还能不能逐行读完代码，而是你是否知道这套系统应该如何运行。

直达网址：https://github.com/Lugia123/polter