最近在帮朋友做一个内容创作工具，碰到了个比较麻烦的事。

需求其实不复杂，就是一个面向内容创作者的写作工作台，需要有项目管理、AI对话、富文本编辑、多平台分发的功能，还得有一套专家模板系统，让用户可以自己配置写作风格。

功能列下来大概就这些，但要做成一个真正能用的东西，还是有相当体量的工作量的。

正好这两天，看到群里有人在讨论GLM-5.1，说是在长任务执行上有比较大的提升，所以我决定把这个项目扔给它试试。

1
我先简单写了一份PRD，主要是把所有模块、功能点、交互逻辑都描述清楚，然后跟它说：完成产品开发，交付完整项目给我。

没有指定技术栈，也没告诉它从哪里开始，然后我就去干别的事情了。

大概十分钟后我回来看了一眼，它还没开始写代码，而是在列计划。

它先读了文档里的五个核心模块，然后自己规划了一个完整的执行顺序：先搭骨架，再设计数据库，然后一层一层往上加业务逻辑，最后才是页面和交互。
每个阶段做什么、依赖什么、产出是什么，都列得很清楚。

2
但真正让我觉得有意思的，是它在后面一小时的执行过程。
这种完整项目开发，最难的地方不是写某一段代码，而是在几十个步骤里，始终记住一开始定下来的那些约定。

举个例子，数据库设计阶段定了字段结构，用户表长什么样，文档表长什么样，项目和文档之间的关联关系是什么。
这些东西定下来之后，后面所有的接口、前端调用、数据展示，都得跟它对得上。

以前我用其他模型做类似的事，走到七八步之后，这些约定就开始模糊了。
它会写出和之前字段名不一致的接口，或者在前端调用一个实际上根本不存在的属性。
这不是它单步能力差，而是它在长时间执行中开始丢失早期的上下文。

GLM-5.1在这次任务里，从头到尾执行了十几个步骤，涉及后端七个路由模块、前端六个完整页面，还有数据库初始化、文件上传、JWT认证等等。
整个过程里，所有之前定义的字段名和模块间的依赖关系，它都没有搞混。

前后端联调的时候，字段全部对得上，一次就通了。

3
然后是bug的处理。
做到一半，出了三个问题。

第一个是前端代码里有个样式属性，引用了一个叫project.theme_color的字段，但这个字段在数据库里压根没定义。渲染的时候直接报错，页面空白。

第二个是富文本编辑器，初始内容为空字符串的时候，不渲染任何东西，用户点进去就是一片白。

第三个是后端少了一个update接口，前端调用的时候直接返回404。

这三个问题单独看都不算复杂，但它们之间有关联。
如果你只处理表面现象，修了一个，另外两个还在，甚至可能引出新的问题。

GLM-5.1的处理方式是，先把三个问题的根源分开说清楚，然后逐个修掉，修完重新构建，验证通过。

整个排查和修复过程，它没有来问我一句话。

最后它交付给我的，是一个完整的前后端分离项目，一键启动脚本，一份README。

我启动试了一下，用户登录、项目管理、稿件创建、富文本编辑、AI辅助工具栏、多平台分发，功能非常齐全。
也有演示账号，打开即用。

我实际点进去，新建项目、新建稿件、写东西、切换模块，基本功能都是通的。

如果这个任务给一个初级工程师，两三天交付算正常速度。

4
测完这个case以后，我脑子里一直在思考一个问题。

以前大家说AI替代程序员，其实替代的是写代码这个动作，最终把所有东西整合起来的那个人，是你。
你需要拆任务、定优先级、在不同模块之间协调，这部分是没有被替代的。

但这次的体验，让我重新审视了一下这个问题。

因为GLM-5.1做的不只是写代码，它自己做了任务拆解，自己安排了执行顺序，自己在十几个步骤里维持了目标的一致性，自己遇到问题找根源修掉，然后自己交付了结果。

这是规划、执行、纠错、交付，一套完整的工程行为。

我后来去查了一下，这个方向有个专门的说法叫Long Horizon，大概是指模型在长时间、多步骤任务上的持续执行能力。

真实的工作任务，绝大多数不是一句提问可以解决的。
你要做一个产品，要推进一个项目，要处理一个复杂的技术问题，都是需要在时间跨度里持续推进的事。

在这个过程里，记住之前的约定、感知到当前的进度、处理中途的意外、不偏离最终的目标，这些能力加在一起，才是一个人或者一个系统真正的工作能力。

GLM-5.1在这个维度上的表现，确实非常出彩。

5
我朋友问我：那以后还要不要学编程？
我也没有答案，但我和他分享了一下我自己的实际感受：以前用AI，你得想清楚让它做什么；但现在用GLM-5.1，有时候你不需要想那么清楚，你只需要想清楚你最终要什么。

当然，这不是说以后不需要懂技术，而是说懂技术这件事本身，它能保护你的范围，正在收窄。

如果你也在做开发相关的工作，或者正在考虑要不要学，可以去用GLM-5.1跑一个真实的任务试试。
不是为了测试它，而是为了弄清楚，在这个结果里，你的那部分贡献是什么。