过去一个月，OpenAI、Anthropic、智谱先后推出新一代前沿模型。新闻本身很热闹，但对工程师更关键的问题不是“谁的榜单更高”，而是：当模型可以稳定连续工作几个小时，AI 开发工具会从“给你一段建议”变成“接管一段任务”。这会改变我们拆任务、写测试、做代码审查和设计工程边界的方式。
三家模型竞争，焦点不只是能力分数
从来源摘要看，GPT-5.6、Claude Fable 5、GLM-5.2 的发布时间非常接近。它们代表的不是单点能力升级，而是前沿模型同时向三个方向推进：更强推理、更长上下文、更稳定的长任务执行。
对开发者来说，模型差异可以先按工程使用场景理解：
- GPT-5.6 更像通用 AI 开发底座，适合代码理解、任务拆解、跨文件修改、工具调用等综合场景。
- Claude Fable 5 如果延续 Anthropic 一贯风格，开发者会更关注它在长文本理解、规范遵循、复杂需求解释上的表现。
- GLM-5.2 的意义不只在模型能力，也在国产模型生态、私有化、合规和本地业务集成的可能性。
这里不要急着把模型当成“更聪明的 Copilot”。真正的变化在于运行时间。一旦模型能连续跑几个小时，它就不再只是编辑器里的补全器，而更像一个可以被调度、被观察、被中断、被验收的执行单元。
范式迁移：从 Chat 到 Agent Job
过去的 AI 编程大多是回合制：你问一句，模型答一段；你贴报错，模型再修一版。这个模式适合局部问题，但不适合真实工程里的长链路任务，比如：
- 读完一个陌生模块，定位一次线上问题的根因；
- 完成一次跨服务 API 迁移；
- 给遗留代码补测试，再重构实现；
- 跑失败用例、修改代码、重新验证，直到收敛。
长时间稳定运行的模型，把交互单位从“prompt”推向“job”。工程师给出的不再只是一个问题，而是一份可执行任务单：目标、范围、约束、可用工具、验收标准、停止条件。
这也意味着 AI 开发会越来越像 CI/CD、任务队列和代码审查的组合：模型负责尝试，系统负责隔离，测试负责裁判，人负责决策。
可以这样实践：把 AI 任务写成可验收的工程 Job
下面是一个最小可改造的 Python 示例。它不绑定任何具体模型 API，而是演示一个“长任务代理”的工程外壳：限制运行时间、让模型产出修改建议、执行测试、记录结果。你可以把 call_model() 替换成 OpenAI、Anthropic 或智谱的真实 SDK 调用。
运行前准备：
mkdir ai-job-demo
cd ai-job-demo
python -m venv .venv
source .venv/bin/activate
创建一个待修复的小项目：
cat > calculator.py <<'PY'
def divide(a, b):
return a / b
PY
cat > test_calculator.py <<'PY'
from calculator import divide
def test_divide_normal():
assert divide(6, 2) == 3
def test_divide_zero():
assert divide(1, 0) is None
PY
pip install pytest
创建 agent_job.py：
import subprocess
import time
from pathlib import Path
WORKDIR = Path.cwd()
TIME_BUDGET_SECONDS = 300
def run_tests():
result = subprocess.run(
["python", "-m", "pytest", "-q"],
cwd=WORKDIR,
text=True,
capture_output=True,
)
return result.returncode, result.stdout + result.stderr
def call_model(task, test_output):
"""
示例中的假实现：真实项目里，把这里替换成 GPT-5.6、Claude Fable 5 或 GLM-5.2 的 API 调用。
关键是要求模型返回结构化变更，而不是随意聊天。
"""
if "ZeroDivisionError" in test_output or "division by zero" in test_output:
return {
"file": "calculator.py",
"content": "def divide(a, b):\n if b == 0:\n return None\n return a / b\n",
"reason": "Handle division by zero according to the test contract.",
}
return None
def apply_change(change):
target = WORKDIR / change["file"]
target.write_text(change["content"], encoding="utf-8")
print(f"applied: {change['file']} - {change['reason']}")
def main():
task = "Fix the failing tests with the smallest reasonable code change."
deadline = time.time() + TIME_BUDGET_SECONDS
while time.time() < deadline:
code, output = run_tests()
print(output)
if code == 0:
print("job accepted: tests pass")
return
change = call_model(task, output)
if change is None:
raise RuntimeError("model returned no actionable change")
apply_change(change)
raise TimeoutError("job exceeded time budget")
if __name__ == "__main__":
main()
运行：
python agent_job.py
这个例子故意很小，但它体现了长时间 AI 开发的核心结构：
- 任务有时间预算，不能无限跑；
- 模型输出要结构化，便于审计和回滚；
- 测试是验收器，不是装饰品；
- 人类工程师定义目标和边界，而不是把整个仓库裸交给模型。
在真实项目中，可以继续加上 Git 分支隔离、文件白名单、命令 allowlist、日志归档、PR 自动创建和人工审批。
两个可落地的工程答案
第一个答案是“Agent Job 化”。不要把长时间模型调用塞进聊天窗口，而要把它接入任务系统。一个 AI Job 至少应该包含：
id: fix-payment-timeout-tests
model: gpt-5.6
budget:
max_minutes: 120
max_tool_calls: 200
scope:
allowed_paths:
- services/payment/**
- tests/payment/**
blocked_paths:
- migrations/**
- infra/prod/**
commands:
allowlist:
- python -m pytest tests/payment -q
- npm test -- payment
acceptance:
required:
- all targeted tests pass
- no production config changed
- summary includes root cause and changed files
review:
require_human_approval: true
第二个答案是“验收前置”。不要等模型改完一大坨代码再问“你做了什么”。在任务开始前就写清楚验收规则：哪些测试必须过，哪些文件不能碰，性能指标是否要保持，是否允许改公共接口。
这两个答案背后的思想很简单：模型能力越强，工程约束越要清晰。长时间运行不是让模型自由发挥，而是让模型在可控环境里完成更大的闭环。
采用建议：先让模型跑窄任务
GPT-5.6、Claude Fable 5、GLM-5.2 这类模型把 AI 开发推进到新阶段，但团队不应该一上来就让它们改核心链路。更稳的路线是从低风险、高验收确定性的任务开始：补测试、修 lint、迁移小模块、整理文档示例、分析失败日志。
可以用这张清单判断一个任务是否适合交给长时间模型：
- 目标能用一句话说清；
- 相关文件范围能被限定；
- 有自动化测试或可执行检查；
- 失败后容易回滚；
- 结果需要人审，但不需要人全程陪跑。
真正的新阶段不是“AI 替代开发者”，而是开发者开始设计 AI 可以工作的工程系统。谁能更早把任务、工具、测试、权限和审查串起来，谁就能更稳定地吃到这轮模型升级的红利。