禁止碰编辑器:当AI接管100%的代码,工程师在做什么?

禁止碰编辑器：当AI接管100%的代码，工程师在做什么？

OpenAI有一个团队，在过去9个月里执行了一条令人匪夷所思的规则：工程师不准打开代码编辑器。所有代码——从功能开发到bug修复到重构——100%由AI Agent完成。人类的工作变成了写需求、审代码、搭护栏。

这不是一个思想实验，是真实跑了9个月的生产级实践。

第一反应可能是：这也太激进了吧？但仔细想想，当85%的开发者已经在用AI辅助编程，当Cursor、Claude Code这些工具的能力每隔几周就跳一个台阶，”人类什么时候不再亲自写代码”这个问题，其实已经不是”会不会发生”，而是”谁先做到”。

今天就来拆解这个实验背后的方法论，以及它对我们每个写代码的人意味着什么。

一、”零编辑器”规则到底怎么执行？

先说清楚这个实验的边界。OpenAI这个团队做的不是demo，不是side project，是生产环境的正式功能开发。他们的规则很简单：

• 禁止手动编写代码——VS Code可以打开看，但不准敲一个字符

• 所有代码变更必须通过AI Agent生成——需求以自然语言描述传递给Agent

• 人类负责三件事：定义需求、审查产出、设计护栏

注意这里有一个微妙但关键的区分——他们没说”人类不参与”，而是把人类的角色从”执行者”彻底切换成了”指挥者+审查者”。

这个切换不是自然发生的。刚开始团队成员本能地想抢过键盘——特别是遇到Agent写出明显低效代码的时候。但规则就是规则，你只能用语言去引导Agent改进，不能自己动手。

这种约束反而逼出了一套方法论。

二、Spec驱动：需求文档变成了”编程语言”

当你不能亲自写代码的时候，需求描述的质量就变成了产出质量的瓶颈。OpenAI团队很快发现了这一点，然后发展出了一套Spec驱动开发的工作流：

• 每个feature先写一份结构化Spec，明确输入/输出、边界条件、错误处理策略

• Spec本身由AI辅助生成，人类审核和补充

• Spec写完后直接传给Coding Agent，作为”编程指令”

这里值得展开说说。传统的需求文档通常是给人看的，含糊之处靠开发者脑补填充。但当读者变成AI Agent的时候，你会发现含糊就是bug。Agent不会像人一样”猜你可能是这个意思”，它会严格按字面理解去执行——要么给你一个出乎意料的实现，要么在歧义处随机选一条路。

一个实际的Spec片段长这样：

## Feature: Rate Limiter Middleware

### Behavior
- Accept requests up to {max_requests} per {window_seconds} per client IP
- Return HTTP 429 with Retry-After header when limit exceeded
- Use sliding window algorithm (NOT fixed window)

### Constraints
- Must work with Redis cluster (no single-node assumptions)
- Lua script for atomicity — no race conditions on concurrent requests
- Fallback to in-memory counter if Redis unreachable (log warning, don't block)

### Edge Cases
- IPv6 addresses: normalize to /64 prefix before keying
- X-Forwarded-For with multiple IPs: use leftmost non-private IP
- Clock skew between Redis nodes: tolerate up to 2s drift

### Test Scenarios
1. 100 concurrent requests from same IP → exactly {max_requests} pass
2. Redis down → requests still served, logs contain WARNING
3. IPv6 /128 and /64 from same subnet → counted as same client

看出来了吗？这不是传统意义上的”需求文档”，而更像是一份面向AI的接口契约。每个边界条件都被显式列出，测试场景直接嵌入——因为Agent需要明确知道”什么叫做对了”。

这就引出了一个有趣的现象：Spec写作本身成了一种核心技能。你对系统的理解越深，写出的Spec越精准，Agent的产出质量就越高。那些最资深的工程师——对分布式系统、并发模型、边界情况有直觉的人——反而在这个模式下最如鱼得水。

三、护栏工程：从写代码到写规则

让AI写100%的代码，最大的挑战不是”能不能写出来”，而是”怎么确保不翻车”。OpenAI团队在这个方向上的投入可能比写Spec还重。

他们搭建了一套多层护栏体系：

第一层：静态规则

这些是硬约束，写在Agent的system prompt和项目的规则文件（类似 AGENTS.md）里：

# Project Rules

## NEVER
- Do not modify files in /core/auth/ without explicit approval
- Do not add new pip/npm dependencies without listing in spec
- Do not use eval(), exec(), or dynamic code execution
- Do not store secrets in code — use vault references only

## ALWAYS
- Run full test suite before marking task complete
- Include type hints for all public functions
- Log structured JSON, never print() to stdout in production code

第二层：自动化审查

每次Agent提交代码，自动触发一条pipeline：

注意关键设计：自动化处理能闭环的问题，只有通过所有自动化关卡的代码才到人眼前。这大幅减少了人工审查的负担——据团队反馈，大约70%的Agent提交在自动化阶段就完成了修正。

第三层：人类终审

到人手里的代码已经过了lint、类型检查、安全扫描、AI审查、全量测试。人类审查的重点不再是”这行代码有没有bug”，而是：

• 设计决策是否合理？（Agent可能选了一个”正确但不优”的方案）

• 有没有Spec里没覆盖的隐含假设？

• 跟现有系统的架构风格是否一致？

这其实是一种效率更高的审查——因为你信任低层正确性已被机器覆盖，人类可以专注高层判断。

四、工具生态的爆发：MCP和AI-First工作流

OpenAI这个实验能跑起来，一个重要背景是工具生态在2025-2026年出现了质变。

Anthropic刚刚披露了MCP（Model Context Protocol）的最新数据：月下载量突破1.1亿，增速超过了React当年的增长曲线。David Soria Parra把2026年定义为”智能体投入生产的元年”——不是实验，不是demo，是真实的生产环境。

MCP的核心价值在于标准化了AI Agent与外部工具的连接方式。打个比方：以前每个AI工具要接一个新能力（比如操作数据库、调用API、访问文件系统），都得自己写一套集成代码。MCP就像USB-C——定义了一个统一协议，任何工具只要实现MCP接口，就能被任何支持MCP的Agent调用。

这意味着什么？意味着Agent的能力边界不再受单一工具限制。一个Coding Agent可以同时：

• 通过MCP连接Git仓库——读取代码、创建分支、提交PR

• 通过MCP连接CI/CD——触发构建、查看测试结果

• 通过MCP连接文档系统——读取设计文档、更新API文档

• 通过MCP连接监控平台——查看线上错误日志、性能指标

这组合起来就是一个具备完整开发环境感知能力的Agent，不再是”只能看当前文件”的补全工具。

再看2026年初那份AI编程工具横评——Cursor 3、TRAE SOLO、Claude Code、GitHub Copilot四个选手，测试场景已经不只是”补全一个函数”或”生成一段代码”了，而是包含了多文件重构、上下文理解、项目级别的任务执行。

工具进化的方向非常清楚：从”代码片段生成器”到”项目级Coding Agent”。

五、实操：普通工程师怎么搭AI-First工作流？

你可能会说：OpenAI的实验太极端了，我不可能说服团队”别碰编辑器”。这确实是。但这个实验真正有价值的不是那条规则本身，而是它逼出来的工作流设计思路。

普通工程师完全可以借鉴，构建自己的AI-First工作流。我的判断是，一个高效的AI-First工作流包含三层：

第一层：项目上下文层

让Agent理解你的项目，而不是每次对话从零开始。具体做法：

# 在项目根目录创建 AGENTS.md（或 CLAUDE.md / .cursorrules）

## Project Overview
This is a FastAPI + PostgreSQL backend for a SaaS billing system.
Architecture: Clean Architecture with domain/application/infrastructure layers.

## Conventions
- Use Pydantic v2 models for all API schemas
- Repository pattern for database access, no raw SQL in services
- All monetary values: Decimal, never float
- Error handling: domain exceptions → application catches → HTTP response mapping

## Directory Structure
src/
  domain/       # Pure domain models and business rules
  application/  # Use cases and service interfaces
  infrastructure/ # Database repos, external API clients
  api/          # FastAPI routers and middleware

## Common Patterns
### Adding a new API endpoint:
1. Define Pydantic request/response in api/schemas/
2. Add use case in application/use_cases/
3. Implement repository method if needed
4. Add router in api/routers/
5. Write integration test in tests/api/

这份文件的作用是把资深工程师脑子里的隐性知识显式化。你的Agent不需要每次都猜”这个项目用什么架构”，直接读规则就行。

第二层：任务编排层

不要把复杂任务一次性甩给Agent。拆分成步骤，每步有明确的验证条件：

# 任务：给用户订阅功能加上试用期(trial)支持

## Step 1: Domain Model
- Add `trial_end_date: Optional[datetime]` to Subscription model
- Add `is_in_trial` property (computed from trial_end_date vs now)
- Add domain rule: trial_end_date must be > created_at
- ✅ Verify: existing tests still pass

## Step 2: Database Migration
- Alembic migration adding trial_end_date column (nullable)
- ✅ Verify: migration up/down both work

## Step 3: API Layer
- Modify POST /subscriptions to accept optional trial_days param
- Add GET /subscriptions/{id}/trial-status endpoint
- ✅ Verify: OpenAPI schema looks correct

## Step 4: Integration Tests
- Test trial creation, trial expiry, trial-to-paid conversion
- ✅ Verify: all tests green, coverage > 80% on new code

这种”步骤+验证条件”的格式让Agent能自我检查。很多时候Agent在Step 1就能发现问题并修正，不需要等到最后你来debug。

第三层：反馈闭环层

这是大多数人忽略的。Agent犯了错，不要只是改掉继续——把教训沉淀到规则里：

# AGENTS.md 追加

## Learned Rules (from real mistakes)
- 2026-04-10: Agent used `datetime.now()` instead of `datetime.utcnow()`
  → Rule: ALL timestamps must be UTC. Use `datetime.now(timezone.utc)`.
- 2026-04-15: Agent added index on high-write table without analyzing load
  → Rule: Database index changes require load analysis comment in PR.
- 2026-04-20: Agent imported a GPL library into MIT-licensed project
  → Rule: New dependencies must have compatible license. Check before adding.

每条规则都从真实错误中提炼，越积累越精准。这就是OpenAI团队说的”护栏进化”——护栏不是一次性搭好的，而是在实践中不断生长的。

六、效率数据：从”感觉快了”到可量化的变化

说了这么多方法论，落地效果到底怎样？

根据公开数据和多个团队的实践反馈，AI-First工作流带来的变化大致可以量化：

其中最反直觉的是测试覆盖率。人写代码时经常偷懒不写测试（或者写得很水），但Agent只要你在Spec里要求了，它会认认真真生成完整的测试用例。而且Agent特别擅长edge case——因为它没有”这种情况不太可能发生”的侥幸心理。

不过有一个方向效率变化不大甚至可能变慢：架构设计和技术选型。这些高度依赖经验、判断和对未来的预判，目前的Agent还无法独立胜任。这恰恰是工程师在AI-First模式下的核心价值所在。

七、”不写代码的工程师”到底在做什么？

回到标题的问题。当AI接管了代码编写，工程师的日常是什么样的？

根据OpenAI实验团队的描述，工程师的时间分配大致变成了这样：

• 40% 需求分析和Spec编写——理解业务意图，拆解为Agent可执行的明确指令

• 25% 代码审查和质量把关——聚焦架构合理性和设计决策，不再逐行看语法

• 20% 护栏和规则维护——更新项目规则、优化Agent配置、沉淀最佳实践

• 15% 系统设计和架构决策——这部分不可自动化，是人类判断力的核心战场

注意一个趋势：“写代码”这件事从时间大头变成了零，取而代之的是更高层次的认知工作。这不是说编程能力不重要了——恰恰相反，你需要比以前更懂代码，因为你要审查Agent的产出、判断方案优劣、预见潜在问题。但你的价值不再体现在手速和语法记忆上。

这让我想到一个类比：就像自动驾驶不是不需要司机了，而是需要一种新类型的”驾驶员”——理解系统能力边界，知道什么时候信任自动化、什么时候接管、什么时候紧急制动。

八、最值得关注的下一步

几个我认为值得持续跟踪的方向：

多Agent协同：不是一个Agent干所有事，而是专业化分工——一个Agent写前端、一个写后端、一个写测试、一个做安全审计。它们通过MCP协议互相通信、协调工作。最新的实践数据显示，多Agent协同的效率提升是单Agent的5-10倍，但编排复杂度也在同步上升。

Agent的自我改进能力：目前Agent犯了错需要人来更新规则。下一步是Agent自己识别错误模式并自动添加规则——形成真正的学习闭环。这在技术上已经可行，瓶颈在于如何验证自动生成的规则是否合理。

跨语言零样本迁移：最新的ArXiv论文Parallel-SFT展示了一个有趣的方向——Agent在一种编程语言上学到的模式可以零样本迁移到另一种语言。这意味着一个精调过Python后端开发的Agent，不需要重新训练就能写出合格的Go或Rust代码。如果这条路走通，Agent的通用性将大幅提升。

“判断力溢价”：当代码生产成本趋近于零，稀缺性会转移到哪里？我的判断是：系统设计能力、业务理解深度、技术选型直觉——这些需要多年实战经验才能积累的东西。会”驾驭AI”的工程师和不会的，效率差距将从现在的2-3倍拉大到10倍以上。

OpenAI那个”禁止碰编辑器”的实验可能过于极端，但它指向的方向是确定的：工程师的核心竞争力正在从”写代码”向”驾驭AI写代码”迁移。现在开始构建自己的AI-First工作流，不是赶时髦，是必要的职业投资。

至于要不要像OpenAI那样彻底禁用编辑器——我觉得不需要这么极端。但你可以试试看：下次做一个feature的时候，先把需求完整地写成Spec，然后全程只通过自然语言指挥Agent来实现。你可能会惊讶于两件事：一是Agent比你想的能干，二是写好Spec比你想的难。

这两个发现本身，就值回票价了。

— End —