回顾一下近几年对大模型的使用, 以及大模型给工作带来的改变.
Tab Coding
大模型给自己带来的第一个震撼, 是用代码补全功能, 生成的yolo 网络的源码.
在此之前, 也多次尝试了解过tensorflow, pytorch , 也尝试看过yolo的相关的开源仓库. 但一直停留在, 未踏入门槛的状态.
我始终没有把网络, 损失函数, 和数据相关的东西白扯清楚——但值得说到的是, 那段时间, github 上检索到的yolo 系列的源码, 在实现上, 工程化都很弱，所以看起来也很吃力.
但当通过自动补全功能, 它以tensorflow 推荐的、标准的写法，一步一步生成了主干网络, 然后完成了损失函数, 再构造训练部分的代码——一直困扰我的点消失了, 我能感觉到, 我算是入门了.
当然, 并不是我很懂了, 而是, 知道如何去拆解, 通过大化小, 最后分板块去实现——对于开发而言, 分层, 分模块的认知路线, 应该也是最能接受的.
随着后面阅读《动手学深度学习》, 对比查看tensorflow 和pytorch的实现, 也逐渐的了解更多——当然, 这也是一个逐渐祛魅的过程.
那个时候, 在绝大部分开发场景下, 都会主动关闭AI 代码补全, 因为它和IDE 的补全差异很大, 准确度还不够高.
Asking
Deepseek 出来之前, 我很少用AI 的问答, 还是习惯用搜索引擎, stackoverflow, github 等.
但当Deepseek 出来后, 元宝接入了 Deepseek 模型, 随后各种国产大模型也快速进入大家的视野.
我并不知道Deepseek 在25年做到了何种程度, 但在看一个RAG 的教程时, 讲师提到: 在此前做agent 开发, 大模型几乎只能接入GPT, 其他的模型, 哪怕你配置好了tools, 大模型也不会主动调用, 而Deepseek, 能够有类似于GPT 80%+ 的效果——所以, 那段时间, RAG, agent 相关的应用, 逐渐多了起来——而自己, 也是逐渐的使用元宝, 替代搜索引擎, stackoverflow, github.
当然, 大模型也是会出错的, 所以那个时候总是元宝、Deepseek、GPT 三个窗口问相同的问题, 看是否有出入.
在Asking 这个阶段, 最大的震撼是, 信息越加透明.
开发项目, 特别是遇到没有做过的领域, 总是对是否能够实现关键功能, 存在较大顾虑, 所以公司更愿意招有相关经验的, 或者寻找技术顾问.
但当大模型出现后, 问题得到了极大的缓解. 当时是合同签订前, 讨论到了一个GIS 相关的功能, 我作为开发, 需要提供技术支持, 了解实现难度, 能否实现.
受限于既有的知识, 其实我是胆怯的. 虽然曾经用过three.js 做过前端3D 模型加载, 也对加载时间做过优化, 有较好的效果——但是, 我知道, B 端应用, 不能通过全量加载来构造GIS 相关的应用, 性能一定过不了关, 内存一定过不了关. 而类似于视窗剔除, 或者模型轻量化相关的算法, 我知道有这个攻关方向, 但是我也无从下手.
然后, 大模型告诉我：你不需要做全量加载, 地图数据是预先处理好的, 分层级, 分横纵坐标块, 存在数据库中的, 不需要考虑实时的遮挡剔除, 预处理后的块状矢量数据按序号存在结构化数据库中, 前端有工具会自动计算当前应该加载哪个层级, 第N行第M列的适量数据. 并且它会自动做增删替换.
从数学原理, 到使用工具, 到时间复杂度, 都统统给了出来.
这个时候的感受是, AI 给了有经验的开发, 跨领域、跨行业完成架构、设计、实现的能力.
随着开发经验增多，开发能力变强, 随着AI 的变强, 甚至会给自己一种“他能干我也能干”的感觉——从前一阶段的祛魅, 到现在的, 自信.
PS: 但是这里的自信并不是来自于做过, 或者自己懂, 而是对编码能力的自信, 外加AI 带来的跨行业经验, 相信自己能胜任绝大部分开发任务.
IDE agent
这个阶段, 从Pycharm的付费用户, 切换到vscode, 付费支持了好几个月copilot.
切换编辑器主要有两个原因.
第一个, 我确实需要多语言的编辑器, 日常需要涉及到python, javaScript, C#, 甚至预估后续还会有其他的编码, Pycharm 在这里支持太差, 虽然有出过fleet, 但出得太晚, 并且功能也差vscode太多.
第二个, pycharm 的AI 功能, 不允许中国区使用, 并且AI 功能需要单独付费. 我确实不愿意同时付两份钱, 并且我迫切需要一个能够在项目中结合实际代码, 便捷向AI 提问的方式——copilot 刚好.
这个时期, 遇到问题询问AI, copilot 能自动获取我打开的文件, 能获取我选中的代码段, 能自动检索当前项目的其他文件——这比网页版问答更准确, 也更高效.
但是, 也是这个时候, 我还是主要停留在ask 和 plan 状态——因为工作中能够让我放手让agent 自动完成开发任务的机会比较少, 并且从实际放手的效果来看, 并没有明显的提高自己的效率,因为往往需要自己来改, 最后的时间反而更长.
我总结是, AI agent 非常适合完成单个点的功能/代码, 但是对于一些有层次结构, 或者有树状流程的功能, 它不能很好的自动完成——但是它读代码的能力一直都很好, 对于一些关键代码生成, 关键代码解读, 算是实打实的提效了的.
虽然都在讨论, AI 将会取代开发的岗位, 但是从实际的开发过程来说, 这样的场景可能更容易出现在大厂——需要足够细化的设计文档, 接口文档, 流程图等资料作为支撑, 让AI 去理解. 而自己所在的团队, 很多概念设计, 实现思路, 甚至文档, 都是在开发完成后, 才会整理, 这个模式其实不利于AI 去实现功能, 这也应该是我应用效果很差的一个原因.
那, 企业会引入AI 来写代码么？我想, 如果我是企业方, 我会. 但是我更看中的是, 强制文档, 然后开发. 虽然可能会因为工作模式的改变, 效率的提高, 裁掉部分人员, 但是企业确实是会希望, 运作模式能够像工厂流水线一样, 人能够像设备一样,可插拔, 可平替,不随着个人的离职而受到影响——而强制文档等操作, 既能够很好的贴合大模型, 又能很好的做存档, 哪怕后续发现AI 开发不靠谱, 带来的效果存档效果也是值得一试的——毕竟还可以让AI 整理文档, 人来做校核.
但为了更好的迎合AI , 自己的工作, 也在逐渐的往, 先文档, 再编码的流程靠, 顺应时代.
此时, 各种AI IDE 满天飞, 各种agent cli 也层出不穷——我迫切的想尝试更多的AI 工具, 但又不想付多份的费用, 并最终放弃付copilot的包月——一方面, 我需要一个付费大模型, 接入各种AI 工具使用, 满足只花一份儿钱的想法, 另一方面, 模型+工具的做法, 在参与特定项目, 或者特定行业特定公司时, 可以私有部署大模型然后正常使用AI 工具, 让自己有一个平稳的降落过程.
于是我选择了Deepseek + Copilot, Deepseek + OpenCode.
后续尝试过让agent 完成开发, 效果都还是不够好. 也就继续停留在asking 和plan 模式下.
skills
前一个阶段, 就感觉到, AI 对那种, 经验类, 流程类的规范, 不太熟悉.
以我最熟悉的Python 为例. 开发项目时, 如果不是开发工具库, 我更倾向于依赖申明里面冻结版本, 这样在很久之后重启项目时, 不会在开发环境上就卡住, 需要去寻找原因. 所以我的流程一般是, 在pypi上寻找次新版或者长期支持版, 然后在依赖文件中声明库和版本号, 在通过pip install -r requirements.txt, 亦或者 pip install -e . 来安装.
但是copilot 也好, 接入Deepseek 的copilot也好, 往往会直接安装库, 不会去声明依赖, 安装时甚至不会主动声明版本号.
亦或者, 在修改开发接口, 或者调整表结构时, 需要考虑向前兼容, 一个改动往往需要分几批次, 甚至分版本号, 有计划的完成, 有目的的保留既有代码(不管它是不是屎).
但AI 的改动总是不会考虑这些点.
在开始使用OpenCode 后, 逐渐的了解到了skills, 也通过skills.sh 安装了一些主流skills 到.agents/skills 做一些尝试.
一个非常主观的感觉是: vscode中接入deepseek的copilot, 在配置了以superpower, planning-with-files 等skills后, 在asking 模式下, 思考过程中展现的角度和排查问题的思路, 更好了, 准确度又上了一个台阶(也更费token).
就好比, 我们做开发, 写代码, 也需要看结构, 分层次, 功能解耦, 然后捋清楚调用顺序, 调用逻辑——其实多数场景下, 我自己是没有办法记住全部的代码, 就好比 AI 中的上下文长度, 不足以装下整个仓库, 哪怕它并不大. 所以, 工作中, 更像是翻目录, 找关键代码, 然后找到运行的那条线, 做排查, 再顺带查看相关数据在其他何处修改, 以及如何修改, 甚至去看设计文档, 这里关系到哪些业务流程.
而配备了skills的agent，虽然可能还不具备具体行业知识（比如财务、医疗、银行等），但已经具备了开发工程师的一些基础能力, 更偏工程思维.
总结回顾
在AI辅助开发的时代，开发工作可能更需要重视文档和流程。比如从需求分析开始，让AI通过提问来明确需求，再逐步完成设计并归档，最后辅助编程或由agent自动编码。
需求是会变化的。需要有专门的地方存放需求和计划，也需要有专门的流程来更新原有的设计文档。这里需要反复修正，确保顶层架构、设计文档和代码实现保持一致——无论是人工完成还是让AI自动同步。完成后的过程文档，可能就不再需要了。
开发流程和模式确实在向适应AI的方向调整，但主观感受来说，他人眼中AI带来的提效、快速完成、快速修改的效果，并没有很明显。
一方面是文档还不够全面和细化，另一方面是出于成本考虑，在后续异常修复时，仍然保留了人工排查的方式，用时反而增加。最后，从不写文档到产出大量文档，算是增加了部分工作量，无法采用控制变量法来准确评估AI的实际效果。