从2026年开始，一系列的编程工具和大模型本身的升级明确了一件事：用大模型取代人(自己)编程势在必行

概念

1 大模型

大模型是驱动这一切的基础。国产的从glm4.7开始，在编程能力方面达到了一定的水平，让大家觉得用大模型编程比较靠谱了。从效果和响应速度上，minimax2.1似乎更好一些。后续应该会有更多更好的大模型，比如deepseek应该也会出。

一个很大的不同是：大部分产商都推出了包次模式。因为每一次的大模型接口交互太多了，产生的token量也可能会非常大，如果走正常的计价模式会比较吃不消。

一个潜在的点就是：不要做简单的沟通，最好是一次想好要做什么，把计划写明白了让大模型整体执行。

2 编程工具

从cursor开始，已经出了非常多的工具，目前我用的比较多的是opencode。

编程工具是围绕大模型开发的一层周边，会将一些通用的规范用prompt约束好，同时提供一些基础的工具辅助开发：例如文件操作、命令行操作以及MCP对接

所谓的大模型编程一般会同时涉及到以上两部分：你用什么工具配什么模型工作。

3 能力边界

从目前实验下来的结果，目前大模型编程能解决流程性问题，但没法规划解决复杂的逻辑比对、判断。

我觉得导致这个现象的原因有两个：

• 1 复杂的逻辑比对是个性化的。这意味着大模型在学习过程中，没有”见过“这些问题怎么去处理；而且一个显而易见的问题：因为这些逻辑很复杂，抽象起来很麻烦，更不会有人放在网上（从产生这类经验的数据上大模型就不会碰到）
• 2 概率模型。本质上，大模型是没有思考能力的，它一直是在高维概率空间上寻找最可能的答案。所以说规划这块不太行，而复杂逻辑是需要多步之后才能看到结果的，中间过程它想不出来。

所以可以用大模型解决那些固定性，流程性的编程问题，比如ETL，这部分工作相当冗长且乏味。而复杂逻辑问题目前还是需要人进行结构抽象+打样来帮助它学习（然后就可以迁移应用了）

4 一些实践

不怕你说太多，就怕你说不清

4.1 流程性问题

刚才说大模型可以用来解决流程性（确定性）的问题，但是要是直接和大模型说一定还是会很困难。这里我尝试了一种通用逻辑：以图的方式来组织结构。

我给几个实际中定义好并运行的规范，作为参考（因为这方面解释起来好像也很难）

我约定了节点、边和子图的命名和生成规范。实际上用来非常稳定，当然这块大家可以根据自己的习惯重新规范。

st-0001
说明：该规范用于约束数据结构的生成
0 规范编号: st-0001
1 采用pydantic 2.x 进行生成数据模型
2 数据模型的命名必须采用 camelCase的方式(首字母小写，后面单词首字母大写)
3 对象应该存储在 memory_node.py下面(追加内容，而不是覆盖）
4 对象设计完成后，应该在memory_node_sample.py 下创建对应的使用示例(一个数据模型，一个示例)
5 对象(类)内应采用docstring, 简要说明，并包含规范编号
6 此规范作用的级别是函数、类内，不要在模块处描述
7 多元素模型采用RootModel方式封装，暴露get_data方法来获取数据，命名则是在原数据对象前加many(用下划线连接)
样例：```from pydantic import RootModel
class readTick(RootModel[list[Tick]]):
def get_data(self):
return [x.model_dump() for x in self.root]```


st-0002
说明：该规范用于约束端到端的数据处理(link函数)
0 规范编号: st-0002
1 必须明确input和output，最好是可以通过接口、数据模型、对象等清晰的代码表达结构
2 端到端的数据处理表达为一个函数，采用snake_case命名(单词均为小写，采用下划线连接)
3 函数开发后在 link.py 下面
4 函数开发完成后，应该在 link_example.py 下创建对应的使用示例
5 对象(类)内应采用docstring, 简要说明，并包含规范编号。同时应当说明其输入和输出的源，最好有数据模型信息。
6 此规范作用的级别是函数、类内，不要在模块处描述

st-0009
说明：基于图的思维进行任务的综合编排处理
0 规范编号：st-0009
1 每一个任务视为一个子图，单独存放在一个脚本里。 脚本采用snake_case命名(单词均为小写，采用下划线连接)，子图是一个对象命名采用PascalCase的方式(单词首字母大写)
2 脚本放在subgraph文件夹下面
3 对象(类)内应采用docstring, 简要说明，并包含规范编号。需要包含以mermaid方式表达的图结构。
4 子图所依赖的数据结构和处理逻辑在 node和link下面应当已有声明。
5 数据的持久化部分在data下面应当已有声明。
6 子图的开发需要先理解需求，对应查看已经实现的node和link，给出mermaid图结构，然后判断是否已经有足够的node和link依赖。得到用户确认后再进行具体开发。
7 子图开发完成后，需要有对应的example脚本，进行非破坏测试（即在内存中观察和运行，不进行持久化）。一个子图一个测试。子图具备两个默认方法：safe_test_run 来进行子图的非破坏测试，run 则执行正式的操作。

4.2 逻辑性问题

这部分我还在探索中，但是之前的一些例子应该也可以说明一些问题。

这是我用大模型来基于flask、jinja方式生成交互式表格的prompt。其中我给了结构，并且也给了一个实际的例子，然后按这种方式去做几乎可以一次成型。本质上，我是采取了抽象结构+打样的方式来实现的，这里面的代码逻辑本身也是有点点复杂的。

视图部分：
交互表格视蓝图要求：
1 头部导入必要资源
2 加上钩子函数，每次执行前对数据库连接进行保活
3 视图函数 view_name 的路径、名称和对应的前端页面名称是一致的
4 对应的CRUD操作，分别是create_view_name, read_view_name, update_view_name, delete_view_name
5 CRUD视图函数内均采用sqlalchemy 数据库模型操作
6 最终一个表格的视图函数应该有5个：
view_name：生成对应的html
create_view_name:创建一个新行
read_view_name：读取若干行
update_view_name：更新一个cell
delete_view_name:删除一行


html部分：
1 使用jinja方式构建，注意我的代码里用了 [[]] 来替代传统的jinja变量符
2 首先继承视图：{% extends 'base_20251216_chank_itable.html'%}
3 按自上往下的顺序，分别有若干block 需要继承或重写
4 block title: 本页的的主标题，这个是展示在浏览器标签页上的
5  block pagejs: 本页最早执行的js，首先是需要继承，然后有必要再增加
6 block page_head: 在本页展示的h1标题， 代表本页的主题
7  block row 是行级容器里面包含了若干个block
8  block modal是row下第一个，用于定义创建行的模态框
9  第一个行容器，按照sb-admin2的样式，会放置几个卡片
10 第二个行容器，是查、增、删三个按钮
11 第三个行容器，放置了交互式表格的placeholder
11 block  edit_cell_script 是行下第二个block，用于定义更新单元格的操作，和视图中的update_view_name 对应
12 block define_table 是行下第三个block，根据业务来定制化表格。
13 block init_table_script 是行下第四个block,用于初始化表格，和视图中的read_view_name对应
14 block modal_create_row_script 是行下第五个block，用于唤起模态框，完成数据创建，和视图中的create_view_name 对应
15 block delete_table_script 是行下第六个block, 用于删除行数据，和视图中的delete_view_name 对应

5 总结

从目前的情况来看，使用大模型编程进行替代是一个可行方案，想想如何把80%以上的coding任务包出去。

大模型编程也是一种更好的模式，在这个模式下，人需要做的是经验的总结、规范的制定以及样例示范。这会让人更聚焦在本质的问题，而不是拧螺丝问题。

不仅是后端，目前看来，从前端设计(figma)到服务到数据库，这个链条是可以打通的。这意味着将来一个人完成整个产品的可能性是很高的，会发生很多有趣的变化。（最简单的是，产品的开发速度和质量大幅提升了）