在过去的一年里，无论是开发的过程还是目标都在发生变化 —— 这一切的核心驱动力，是大模型工具（如 trae）从 “辅助工具” 变成了 “核心生产工具”，也让我对 “开发” 的定义和价值产生了新的认知。
开发过程上，回顾今年过去的 2 个月，我几乎没有手写过任何代码，也没有尝试修复过任何 AI 生成代码（甚至不需要我手动修复）。使用 trae 的频率也从年中的偶尔使用到现在天天使用，它不再是 “帮我写代码的助手”，而是 “能自主完成验证、迭代的协作方”。
开发目标上，在过去我们所做的一切工作，可以总结为提升人的工作效率（比如写脚本帮人省时间、优化流程减少人工操作）；而现在，已经转变为提升 Agent 的工作效率 —— 如何让 AI 工具用更低成本、更高精度完成任务，成了开发的核心命题。
下面我分享几个case梳理这一整年的变化。
生成代码
对待AI生成代码的态度，经历了如下转变。
- 必须人工review所有代码
- 仅当输出存在异常时人工修复问题
- 输出异常的部分全部删掉重新生成，直到生成的结果满足用例
如果给一个单元测试
背景
上传视频/音频往往有文件大小限制。我有一些长度较长的视频，需要按照50M每个文件的大小切片，并提取切片后文件的音轨。音频文件要求小于15M。允许本地调用ffmpeg。
开始工作
- 新建文件夹
- 在文件夹里加一个mp4文件作为样例
- 在builder里输入需求：
有一个视频case.mp4，需要按照50M每个文件的大小切片，并提取切片后文件的音轨。音频文件要求小于15M。允许本地调用ffmpeg。生成一个python脚本实现。
输出：
- 输出一个实现要求功能的python脚本。
- 执行代码切分给出的case.mp4。
- 检查切片是否满足要求。
- 发现不满足要求修改脚本。
- 发现满足要求，输出改动总结。
这个工作流程让我震惊的是：
- 初始生成的脚本仅实现了简单的视频切片，但未校验切片大小（部分切片超过 50M），存在部分提取的音轨有 3 个文件超过 15M。
- 在验证失败后，自动分析了问题原因（切片大小计算未考虑视频编码压缩率、音轨提取未做二次压缩），并依次调整了切片大小计算公式、增加了音频转码（将 mp3 转为 aac 并降低码率）等逻辑，最终 5 轮迭代后完全满足要求。
- 在过去，这个过程需要我先写脚本、手动测试、排查问题、修改代码，至少要花 1-2 小时。在一年前，可能每一轮迭代完都需要手动执行测试用例，当发现失败时要指出哪里失败，并且给出一些解决方式，才会基于给出的解决方式实现。在现在，只需要给出清晰的需求和样例文件，剩下的全部由 trae 自主完成。
一次性的功能开发
背景
举办社区活动时手动统计了一个人员-出勤/按月分sheet的表单。每月会根据此报表统计的出勤情况手动生成一张带有人员-出勤次数的海报。希望将输入统计的表单，自动生成海报。
开始工作
-
确认输入，当前已有2个文件：XX活动出勤记录.xlsx，xx活动x月出勤榜.html。其中出勤榜是原生html5的静态页面，积分数据是一个数组。
-
新建文件夹，放入已有的 XX活动出勤记录.xlsx，xx活动x月出勤榜.html 文件。
-
在builder里输入需求：
我需要提取XX活动出勤记录.xlsx中最后一个有数据的sheet的A和B列的数据，生成xx活动x月出勤榜.html中307-329行的list数据，生成一个python脚本实现。
在传统的开发场景下，类似低频的功能很少会用一个脚本去自动化的 —— 手动完成这项工作每次需要5分钟，每月1次，全年累计60分钟；而如果我自己写脚本，光是阅读Excel读取的API文档、将HTML作为文本格式来匹配修改，至少也要花费半天，显然 “不划算”。
但 AI 生成代码改变了这个逻辑：我只花了 5 分钟整理需求、10分钟等待 trae 生成并验证脚本，后续每月只需自动化运行1次脚本，一次性投入 15 分钟，全年就能节省60分钟。高质量的代码生成扩展了开发的边界，也让 “一次性使用的功能 / 产品” 从 “不划算” 变成了 “低成本高收益”，开发不再只聚焦 “高频核心功能”，而是能覆盖更多长尾的工作场景。
我们还需要结构化的数据吗
背景
一个衣服穿搭助手的项目，让用户能够便捷地上传自己的衣物照片到个人“线上衣柜”，系统再基于衣柜里已有的衣物，通过AI智能生成符合用户风格、场景需求（比如通勤、约会、休闲）的穿搭方案。
相信刚听到这个项目创意时，大部分做技术开发、产品设计的人，第一反应都会和我一样：要做好穿搭匹配，需要把用户上传的每一件衣服，都整理成结构化的数据。
比如，我们会开始构思衣物的数据表结构：衣服ID作为主键，然后是衣物类型（上衣/裤子/裙子/外套等）、颜色（黑色/白色/卡其色等）、款式（宽松/修身/oversize/通勤风等）、材质（棉/牛仔/针织/真丝等）、季节（春/夏/秋/冬/四季通用）、领口类型（圆领/V领/衬衫领等）、袖口设计（长袖/短袖/喇叭袖等），甚至还要加上用户自定义的标签（比如“约会专用”“职场必备”“旧衣服不常穿”）。
紧接着，会进一步思考搭配逻辑如何依托这些结构化数据落地：当用户触发AI穿搭生成指令时，系统先从衣物表中查询符合当前场景（比如“通勤”）和季节（比如“春季”）的衣物，再根据穿搭规则（比如“修身衬衫+直筒牛仔裤”“宽松卫衣+运动裤”），筛选出风格适配、颜色协调的组合，最后把这些筛选出来的衣物数据，按照固定格式组织成prompt，输入给AI模型，让AI生成具体的穿搭描述和搭配建议。
直到我尝试了用豆包来实现这个需求，才发现之前的 “结构化思维” 其实是 “人的思维惯性”—— 我们习惯用结构化数据降低自己的处理难度，但 AI 完全可以通过自然语言和视觉信息理解非结构化内容。
只要在对话一开始说清楚穿搭的需求，然后上传我衣服的照片，豆包就可以直接实现上述的功能。
这让我反思：很多时候我们花大量时间设计数据表、清洗结构化数据，本质是为了 “适配人的处理能力”；而当 Agent 成为核心执行者时，“结构化” 不再是必须的前提，开发工作也从 “设计数据结构、编写 CRUD 代码” 转向 “如何用自然语言清晰定义需求、让 Agent 准确理解任务目标”。
提升agent的效率
背景
目前WPS等商用产品，均已内置“上传会议录像自动生成会议纪要”的功能，且体验成熟、输出质量稳定。
我通过实测发现，若直接将会议音视频数据，输入qwen3-vl模型，加上一点简单的prompt生成的纪要，输出质量与WPS商用功能相比并无明显差距。
不过这样直接的调用模型，还是存在一些效率上的问题：分析总结30分钟的视频会议，直接输入模型要消耗大约60万token，按照阿里云上给出的单价，基本在0.5-1元之间。这个算力成本并不低。
这就有个很直观的疑问了：WPS这些商用产品，肯定不会用“直接把完整音视频丢给大模型”这种笨办法，不然运营成本早就扛不住了。其实这背后，核心就是要想办法提升智能体（Agent）处理任务的效率，而不是光靠大模型本身的能力硬扛。
优化思路
优化思路很简单，说白了就是“先预处理，再提效率”，减少大模型没必要的token消耗，让Agent能更高效地完成“音视频转纪要”这件事——这也正好呼应了我们之前聊的核心观点：开发的目标，已经从提升人的效率，慢慢变成提升Agent的效率了。
比如几个简单的预处理操作：
- 在提取音轨切片时，识别音频的静音片段(比如停顿超过3秒)，把静音片段过滤掉。
- 使用语音识别的模型(如paraformer)将音频转成文字稿。
- 过滤文字稿中“嗯、啊、重复话术”这类无效内容，以及包含“闲聊”关键字的句子（比如今天天气不错，中午吃什么）；
- 将经过过滤的文字稿传给大模型，针对文字稿进行总结。
更重要的是，这些预处理逻辑可以封装成通用的 Agent 组件，复用到所有 “音视频转纪要” 的场景中 —— 这就是现在开发的核心价值：不是写 “让人用的代码”，而是写 “让 Agent 更高效的代码”。
总结
从这个场景就能看出来，大模型本身的能力，其实已经能满足我们的核心需求了。但想要低成本、高效率地落地，关键在于优化Agent的任务处理流程——帮它少做冗余操作、压缩无效输入，让它能以更省成本、更高效的方式把事做好。
最后
回顾这一年的变化，从 “手写代码、修复 AI 生成的 bug” 到 “定义需求、验收 AI 的输出”，从 “提升人的效率” 到 “提升 Agent 的效率”，开发的核心已经从 “实现功能” 转向 “定义规则、优化流程”。
AI 工具已经能完成大部分 “执行层” 的工作，而我们的价值，在于成为 “策略层” 的设计者 —— 如何清晰定义任务目标、如何设计 Agent 的工作流程、如何降低 Agent 的执行成本，成了现在开发工作最核心的命题。
