软件开发的方式正在经历一次范式转移。过去我们熟悉两种路径——手写每一行代码的"工匠模式"，和靠流程、测试、CI/CD 保驾护航的"工程化模式"。如今第三种方式正在成型：开发者不再逐行编写代码，而是通过意图描述让 AI 生成实现，人负责审查、修正和决策。这不是"让 AI 替你干活"的幻想，而是已经发生在日常开发中的真实变化。
前两种方式做了什么
第一种方式是个人英雄主义。一个程序员从零写出整个项目，代码质量完全取决于个人水平。速度快的时候很爽，但项目规模一旦膨胀，维护就成了噩梦——没有测试、没有文档、没有自动化保障，只有"这段代码我能看懂"的脆弱信心。
第二种方式是工程化。单元测试、代码审查、持续集成、分支策略、部署流水线……这些实践把软件开发从手艺变成了可重复、可验证的工程。代价是流程变重了，一个功能从想法到上线要经过多层关卡，但好处是系统稳定性大幅提升，团队协作有了共同语言。
两种方式各有适用场景，但它们有一个共同前提：人必须亲手写代码。第三种方式正在动摇这个前提。
第三种方式的日常形态
第三种方式的核心不是"AI 写代码，人不用动脑"，而是人与 AI 的分工重新划分：
- 人负责：定义问题、拆解意图、审查输出、处理边界情况、做架构决策
- AI 负责：根据意图生成代码骨架、填充重复性实现、提供多种方案供选择
日常开发中，这已经不是理论。以下是一个真实的开发场景：你需要给一个 Flask 项目加一个带限流的健康检查接口。传统方式下你要查文档、写代码、写测试、调试。第三种方式下，你先描述意图，再审查和修正 AI 的输出。
实践：用意图驱动的方式完成一个限流健康检查接口
下面是一个完整的可运行示例。先看项目结构：
flask_health/
├── app.py
├── requirements.txt
└── test_app.py
requirements.txt：
flask==3.0.0
limiter==1.4
pytest==8.2.0
app.py——一个带限流的健康检查接口，包含手动编写的架构决策和 AI 生成后经审查修正的实现细节：
from flask import Flask, jsonify
from limiter import Limiter
from limiter.util import get_remote_address
app = Flask(__name__)
# 架构决策：限流策略按 IP 地址划分，每分钟 60 次
# 这是人做的决策，AI 不应该替你决定限流阈值
limiter = Limiter(
key_func=get_remote_address,
app=app,
default_limits=["60 per minute"]
)
@app.route("/health")
@limiter.limit("60 per minute")
def health():
"""健康检查接口，返回服务状态和基本运行信息"""
return jsonify({
"status": "ok",
"service": "flask_health",
"version": "1.0.0"
})
if __name__ == "__main__":
app.run(host="0.0.0.0", port=5000)
test_app.py——测试同样可以由 AI 生成初稿，人审查修正：
import pytest
from app import app
@pytest.fixture
def client():
app.config["TESTING"] = True
with app.test_client() as client:
yield client
def test_health_returns_ok(client):
"""核心断言：健康检查必须返回 status=ok"""
resp = client.get("/health")
assert resp.status_code == 200
data = resp.get_json()
assert data["status"] == "ok"
assert "version" in data
def test_health_rate_limit(client):
"""限流测试：超过阈值应返回 429"""
# 发送 61 次请求，第 61 次应被限流
for i in range(60):
resp = client.get("/health")
assert resp.status_code == 200
resp = client.get("/health")
assert resp.status_code == 429
运行测试：
pip install -r requirements.txt
pytest test_app.py -v
启动服务并手动验证：
python app.py
curl http://localhost:5000/health
# 应返回 {"status":"ok","service":"flask_health","version":"1.0.0"}
这个例子虽小，但体现了第三种方式的工作节奏：你决定限流策略和接口语义，AI 帮你快速填充 Flask + Limiter 的组合用法，你审查后修正细节（比如确认 Limiter 的 key_func 参数名、确认 429 状态码是否正确返回），然后写测试验证。
分工的边界在哪里
第三种方式最容易犯的错误是两个极端：
极端一：完全信任 AI 输出。 把生成代码直接粘贴上线，不做审查。AI 生成的代码经常在边界情况上出错——限流阈值不合理、异常路径没处理、依赖版本不兼容。这些错误在审查阶段花十分钟就能发现，上线后排查可能要花半天。
极端二：拒绝使用 AI。 坚持逐行手写，认为"只有自己写的代码才可靠"。这忽略了 AI 在重复性工作上的效率优势。一个熟练开发者手写上面的 Flask + Limiter 组合可能要 20 分钟查文档加调试，而意图描述 + 审查修正可能只要 5 分钟。
合理的分工边界是：架构决策、业务语义、安全相关逻辑由人主导；重复性实现、模板代码、多方案探索由 AI 主导，人审查。
一个更贴近日常的命令行场景
不是所有 AI 辅助开发都发生在编辑器里。很多时候你用命令行和 AI 交互来完成运维、调试、数据处理的任务。下面是一个用 shell 脚本 + AI 辅助思路完成日志分析的例子：
假设你有 Nginx 访问日志，想快速统计过去一小时访问量最高的 10 个 IP。传统做法是翻 AWK 语法；第三种方式下，你描述意图让 AI 生成命令，你审查后执行：
# 意图：统计过去一小时 nginx 日志中访问量最高的 10 个 IP
# AI 生成的初版命令（审查后修正了时间过滤逻辑）
# 先确认日志路径和时间格式
head -5 /var/log/nginx/access.log
# 统计过去一小时的 Top 10 IP
awk -v cutoff="$(date -d '1 hour ago' '+%d/%b/%Y:%H:%M:%S')" '
$0 >= cutoff {
split($1, a, " ")
count[a[1]]++
}
END {
for (ip in count) printf "%6d %s\n", count[ip], ip
}
' /var/log/nginx/access.log | sort -rn | head -10
审查要点：cutoff 的日期格式是否和日志中的格式一致？Nginx 日志的时间字段在第几个位置？这些细节 AI 经常搞错，必须人工对照实际日志格式确认。
如果日志格式不同（比如 JSON 格式），改用 jq：
# JSON 格式日志的同类统计
jq -c 'select(.time >= "$(date -d '1 hour ago' --iso-8601=seconds)") | .remote_addr' /var/log/nginx/access.json.log \
| sort | uniq -c | sort -rn | head -10
采用第三种方式的检查清单
在团队中引入第三种方式，不是买一个 AI 工具就完事了。以下是一份实用的检查清单：
| 检查项 | 说明 |
|---|---|
| 审查流程是否到位 | AI 生成的代码必须经过人工审查才能合并，和人工代码走同样的 review 流程 |
| 意图描述是否清晰 | 模糊的意图产生模糊的代码。"加一个接口"不够，"加一个限流 60 次/分钟的 JSON 健康检查接口"才够 |
| 测试是否覆盖 AI 输出 | AI 生成的代码和手写代码一样需要测试覆盖，不能因为"AI 写的应该没问题"就跳过 |
| 边界情况是否人工验证 | 限流阈值、错误处理、并发场景、安全相关逻辑——这些 AI 经常遗漏的地方必须人工检查 |
| 团队是否达成共识 | 哪些模块允许 AI 辅助、哪些必须手写（比如安全模块、支付逻辑），团队需要明确约定 |
| 是否保留人的决策记录 | 代码注释或 commit message 中记录"为什么这样做"的决策理由，AI 无法替你做这个 |
第三种方式的真正代价
第三种方式节省了写代码的时间，但审查和决策的时间不会减少，甚至可能增加。因为你需要理解 AI 生成的代码才能审查它，而理解别人写的代码（即使是 AI "写"的）从来都比自己写更费脑。
另一个隐性代价是对 AI 的依赖惯性。长期用 AI 生成代码，开发者对底层 API 和语言细节的熟悉度可能下降。当 AI 输出出错而你缺乏判断力时，调试时间反而更长。保持"能脱离 AI 手写核心逻辑"的能力，是使用第三种方式的安全底线。
第三种方式不是替代前两种，而是在它们基础上增加了一个新维度。工程化实践（测试、CI、代码审查）依然是地基，AI 是加速器。地基不牢的时候加加速器，只会更快地撞墙。