2026年9月5日早上我照例先把几个信息源刷了一遍再根据工作群和社区里的讨论把当天值得记录的事情整理成这份日报。日报不是新闻稿我不追求把所有AI资讯都搬上来只挑和自己工作强相关、或者明显影响接下来几个月技术选型的东西来写。今天最突出的关键词有三个轻量大模型、AI编程落地、Agent工程化另外AI视频和内容合规也有新动向。如果你是做AI应用开发、模型部署、或者正在考虑用AI改造内部流程的人这篇内容应该能对上胃口。1. 今日主线轻量模型与端侧部署终于成为默认选项1.1 为什么轻量化成了大家默认的解法今天最让我在意的不是某个更大参数的模型发布而是好几条关于端侧和中小参数模型的新进展。有家头部团队把主打模型的一个小版本做成了能跑在手机开发板上的规格官方给的宣传点是“离线可用、单Token成本降到可忽略”。这放到两年前是想都不敢想的那时候大家的惯性思维是“模型越大越聪明”谁参数多谁说了算。但从去年下半年开始整个行业的重心已经从“把模型做大”转向“把模型用起来”。原因其实很直接第一成本。云上调用一个大模型的API对一个日活百万的小应用来说每个月光推理费用就可能吃掉不少毛利而端侧或是私有化部署的中小模型边际成本几乎为零。第二数据隐私与安全问题。很多企业不愿意把内部文档、用户对话记录放到公网服务上一个本地可运行的小模型天然规避了这个顾虑。第三延迟。大家已经越来越没耐心等一个转圈圈的AI回复端侧推理省去了网络往返能做到几十毫秒级别。这里要说明一下轻量化和“变笨”并不冲突。现在的中小模型已经用上了大模型蒸馏、量化和结构化剪枝这些成熟手段在很多垂直任务上能力并不比大模型肉眼可见地差。我记得有组数据在客服意图识别、合同关键信息抽取这类任务上一个精简过的7B级别模型效果能逼近原先100B以上模型的95%但推理成本只有后者的几十分之一。这个性价比对绝大多数业务场景来说已经足够了。1.2 端侧部署必须盯住的四个指标如果你也想把模型放到端侧或者做一套私有化部署我建议不要只盯着“能不能跑”这个最低标准。真正上线之前至少要把下面四个指标测透指标含义我建议的最低要求首Token延迟从请求发出到收到第一个字的耗时手机端建议低于500ms服务端建议低于200ms吞吐量每秒能处理的请求或Token数根据业务峰值倒推留出30%以上余量峰值内存加载和推理过程中占用的内存上限手机端不要超过设备内存的1/4功耗与发热持续推理时的设备温度与耗电速度连续跑10分钟后温度不能触发降频很多项目死在最后一条上。我见过有人在一款中端手机上跑了一个多模态模型纯看指标首Token延迟和内存都达标结果连续对话几分钟后手机开始发热降频响应速度直接掉了一半。这个问题的根源往往不在模型本身而在推理框架和线程调度策略上。后来换了支持异构计算的推理引擎又把CPU绑核和大核分配策略调了一下发热问题才缓解。所以如果你做端侧项目一定要把“持续使用场景”作为压测方案的一部分别拿单次请求的漂亮数据去骗自己。另外想多说一句端侧部署不是一个单点工程它需要模型侧、客户端侧和服务端侧一起配合。模型负责压缩和蒸馏客户端要做缓存和预加载服务端要准备模型版本管理和灰度更新通道。我在实际项目里习惯的做法是先做一轮端侧可行性验证把模型转成对应的量化格式再跑业务真实样本业务方确认效果没有明显回退后才进入集成阶段。跳过这一步后面大概率要返工。2. AI编程从“帮你补全”进化到“帮你上线”2.1 垂直语言的代码生成才是行业数字化的硬仗今天社区里刷屏的另一个方向是AI编程开始往垂直语言渗透。以前大家聊AI编程默认是写Python、Java、Go这些通用语言但今天我看到有团队在分享用大模型生成PLC梯形图代码还有人在搞Verilog代码生成这让我挺感慨的。通用代码生成解决的是“让程序员更快写代码”的问题而垂直语言的代码生成解决的是“让行业专家不写代码也能产出代码”的问题。PLC、Verilog这类语言有一个共同点语法范围相对窄逻辑约束强背后有大量的规范文档和历史案例。这正好是一个适合大模型发挥的场景因为模型不需要像写通用业务系统那样处理无边无际的依赖关系它只需要把“输入状态、输出状态、转换条件”这些有限要素理解清楚。当然也不是说现在就能完全自动生成一段可以无脑烧录的PLC程序它仍然需要工程师做大量的确认和测试但至少可以把原来一两周的编码工作压缩到两三天。这里我想泼一盆冷水。通用编程大模型在垂直语言上经常翻车原因是训练数据里这些垂直语言的语料太少模型遇到语法严格的地方容易一本正经地编造API。所以真要在PLC或者Verilog上落地我建议先用一批企业内部的历史代码来微调模型哪怕只微调一个低秩适配层效果都会比直接用通用大模型好很多。2.2 给AI写提示词其实是在做上下文工程今天还有一个“AI编程提示词”的话题被反复提起我顺便说说自己的理解。很多人觉得写提示词就是“把需求说得更详细一点”这个理解太浅了。实际上当你在给AI编程工具写提示词的时候你做的事情是“上下文工程”是要把散落在人脑、文档、旧代码里的信息整理成模型能直接消费的上下文。我常用的一个结构是这样的背景这是一个订单同步模块负责把ERP里的订单状态同步到电商中台。 需求当ERP订单状态变为“已发货”时调用电商中台接口更新发货状态失败时写入重试表最多重试3次。 约束不能用分布式事务要保证最终一致接口调用要在5秒内超时。 接口定义POST /api/ecom/order/ship参数orderId, status, shippedAt 测试样例 - 正常状态变更期望返回200且重试表无记录。 - ERP返回超时期望状态置为PENDING_RETRY且后续重试成功。把接口定义和测试样例写清楚比在提示词里写一百句“请写出高质量代码”都管用。模型的生成质量高度依赖上下文质量这也是为什么很多团队开始建“提示词资产库”把常用场景的高质量提示词沉淀成团队公共资产。如果你现在还是一个人随手写提示词可以试试这个思路用一个月就会发现生成代码的可用率高出一大截。另外我还建议“让AI先写测试再写实现”。这个做法算是测试驱动生成的实践版模型先看到自己生成的测试用例再回去写实现会更清楚自己到底要满足什么行为而不是在一堆花哨注释里迷失方向。2.3 上线前还差临门一脚审查与测试AI编程工具再强我也不会让它在没有人工审查的情况下直接进主分支。今天群里有人转了一张截图AI生成的代码看起来逻辑完整但里面调用了一个已经废弃的SDK而且错误处理的路径里连日志都没打上线后出了问题根本没法排查。这个例子太典型了。我的个人经验是AI写代码的适用边界可以分为三个阶段阶段状态适合场景个人辅助阶段人工编写为主AI补全和改写IDE插件补全、单函数生成、注释转代码团队协作阶段AI生成为主人工审查兜底业务CRUD、测试用例生成、脚本编写全流程自动阶段AI生成并自动验证有成熟测试体系和代码规范的团队绝大多数团队现在都处在第二阶段的初期也就是“AI生成加人工审查”。这个时候最忌讳的事情是盲信AI的自信输出尤其是涉及权限校验、支付金额、时间边界这类敏感逻辑时必须逐行看。我还发现AI生成的测试用例有一个通病喜欢覆盖“正常路径”和“边界值”但很少覆盖“异常并发”“第三方依赖不可用”这类真实故障场景。所以AI生成的测试只能作为底稿最终还是要人来补上那些残酷的场景。3. AI视频与漫剧内容生产的流水线正在重写3.1 从脚本到成片一条完整可复制的AI漫剧工作流今天信息流里有好几个热搜词都指向了AI视频、AI短剧、AI漫剧看来这个方向的热度还在持续升温。我最近也完整跑通过一条AI漫剧的制作流水线这里把流程拆出来给大家参考。AI漫剧的生产路径大概是这么几步第一步写剧本这个可以用大模型生成梗概和分场对白但我建议人一定要做一次“剧本医生”把节奏和逻辑捋顺AI生成的剧本很容易出现“每句话都对但整体很平淡”的问题。第二步生成分镜脚本把每一幕的场景、角色动作、镜头角度用文字描述清楚。第三步用AI绘画生成角色立绘和场景底图这里的关键是角色一致性。第四步把静态图变成动态视频现在主流的做法是图生视频给定角色图和动作描述生成一个短片段。第五步配音和配乐可以用语音合成生成对白再用AI音乐工具生成背景音。第六步剪辑合成加上对话字幕和音效。这套流程最大的改变是把原来需要一整个动画团队的大工程压缩到了一个人能够驾驭的程度。我认识的一个做漫剧的朋友过去一周只能产出两条成品现在同样的时间能产出四五条成本大概降了百分之六七十。当然质量上没办法和精工细作的商业动画比但放在短视频生态里已经够用了。3.2 角色一致性是最大的技术坎做AI漫剧的时候很多新人都在同一个地方栽跟头角色不一致。上一秒还是长头发下一秒发型就变了再下一秒衣服颜色也变了观众一眼就能看出是AI生成的。要解决这个问题可以试试下面这些常规做法。角色参考图是基本功先固定一张角色的标准立绘所有的生成任务都把这张参考图带上有条件的话用LoRA给每个主要角色训练一个专属小模型让模型知道“这个角色长什么样”训练完成后的推理阶段连续镜头之间要保持种子值和提示词的稳定性最后是后期兜底发现明显不一致的镜头直接用局部重绘处理而不是重新生成整个画面。这里要泼一点冷水别指望一套配置能解决所有情况。角色一致性问题在不同画风、光影环境下表现差异很大项目初期最好先把三四个主要角色的配置体系跑通反复确定哪些提示词字段是稳定的再大规模铺开。另外多集连载项目一定要做好素材管理每个角色的参考图、LoRA文件、常用提示词模板都要按角色归档不然做到第十集时你连第一集用的提示词都找不回来了。3.3 别碰“无限制生成”的灰色捷径热词里出现了一批带有“无限制”“无审核”“无禁词”标签的AI生成工具比如“无限制AI生成视频工具”“无禁词AI聊天”这些。我看到的时候第一反应是这又是一个注定走不远的赛道。做内容生产尤其是做公开传播的AI生成内容“无限制”从来不是一个优点而是一个巨大的隐患。理由很简单任何一个内容平台都有自己的审核规则和社区规范渠道分发是内容创作者的命脉如果你的工具生产的内容天生就是奔着踩线去的那等待你的只会是限流、下架、合作终止这些结果。更何况内容质量并不能靠“无限制”来提升一个能输出任何内容的模型同样也会输出大量垃圾内容真正有价值的内容创作靠的是审美、判断力和对用户需求的理解这些能力不是“去掉限制”就能获得的。我自己做AI视频内容这么久最大的感受是工具越强越要用规则来约束自己。正规做法是把精力花在打磨剧本、优化角色表现力、提升画面美学上而不是去寻找什么“无限制”的旁门左道。这条路上没有捷径只有踏踏实实把流程跑通才能持续稳定地产出好内容。4. AI Agent工程化热闹之后真正能上线的是什么4.1 Agent的核心不只是模型而是编排今天好几条热搜词都和Agent有关什么AI Agent、AI智能体、AI应用开发看起来大家都已经开始从“聊概念”转向“做产品”了。白天有个朋友问我Agent和普通的调用大模型API到底有什么区别我说举个例子你就明白了普通的API调用是“你问一句模型答一句”Agent则是“你给一个目标它自己拆解步骤、调用工具、处理异常、最终给你交付结果”。所以Agent的核心其实不是某一个大模型而是模型外围那一圈编排逻辑。一个能稳定工作的Agent至少需要四个模块规划模块负责把目标拆成可执行步骤记忆模块负责记住用户偏好和历史上下文工具模块负责对接搜索、数据库、业务系统等外部能力安全模块负责限制Agent能做什么、不能做什么。这四个模块配合得好不好直接决定了Agent是“聪明助手”还是“定时炸弹”。很多团队在Agent演示阶段都很惊艳但一进入生产环境就翻车原因就是把90%的精力花在了模型提示词上却忽略了编排层的稳定性。比如工具调用失败后的重试策略、多步操作之间的状态保存、用户中途改需求时的上下文同步这些问题每一个都能让Agent从“聪明”变成“不可用”。4.2 渐进式落地方案与常见坑位我在实际项目里总结出来的一条经验是不要急着上多Agent协作先把单Agent的链路做扎实。我的推荐路径分三步走第一步静态工作流。把业务逻辑写死成代码每个节点调用一次模型模型只负责填写固定模板里的字段。第二步单Agent加工具调用。让Agent自己根据用户意图选择调用哪个工具但这个阶段只做工具路由不做复杂规划。第三步多Agent协作让一个主Agent负责拆解任务分发给不同的子Agent执行最后汇总结果。这套路径看着保守但能省下大量调试时间。很多项目跳过了前两步直接上多Agent结果发现连“哪个Agent该负责什么”这种最基本的问题都理不清。另外有几个坑位要提前说工具名和参数设计要足够明确别指望Agent能从“调用接口A”这种描述里猜出业务含义给Agent的权限要遵循最小化原则能读的别让它写能写的别让它删关键操作前一定要加人工确认环节尤其是涉及支付、删除、对外发送消息这些不可逆操作的场景。今天还看到Spring AI相关的框架更新消息顺嘴提一句。像Spring AI Alibaba这类框架本质上就是把大模型和Agent能力封装成Java程序员熟悉的依赖注入、Bean调用方式让后端团队不需要成为算法专家也能在自己的业务系统里快速接上AI能力。这个思路我还是比较认可的AI落地不能总是让每个团队从零造轮子趁手的框架和工具链才是工程化普及的加速器。4.3 Agent排查速查表做Agent工程化这半年我把最常见的问题整理成了一张速查表每次Agent表现不对我都按这个顺序排查现象先查什么常见原因Agent答非所问上下文里是否混入了过时信息记忆模块没有做相关性过滤Agent不调用工具工具描述是否清晰、参数是否有示例工具名太抽象模型识别不了工具调用成功但结果错误工具返回的数据格式是否符合预期缺少返回值的校验和转义多轮对话后表现变差上下文是否已经超出窗口长度缺少摘要压缩或窗口裁剪策略Agent出现越权操作权限控制配置是否生效权限设置只写在提示词里工程层没拦同一步骤反复失败重试策略是否合理盲目重试没有区分瞬时错误和永久错误这六类问题我敢说覆盖了Agent生产环境里八成的故障。你如果也想做Agent建议先把这张表打印出来贴在工位上。5. 内容安全的冷思考越能生成越要可控5.1 “无限制”为什么是伪需求写到这里必须回头聊一下今天热词里反复出现的一个方向“无限制AI”“无禁词聊天”“无审核生成”。这些词的搜索热度一直不低但我作为从业者必须明确说这是典型的伪需求尤其是在产品化和商业化层面几乎走不通。为什么说是伪需求因为任何一个面向公众的AI产品都需要和渠道、平台、支付体系、品牌形象绑定而这些环节天然要求内容可控。今天你做一个“无禁词AI聊天”应用也许能靠猎奇心态吸引一波流量但接下来你要面对的是内容质量失控、用户投诉、渠道下架、口碑崩盘这一套组合拳下来几乎没有项目能撑过半年。更别提一旦生成的内容被他人滥用后果完全不可控。我见过太多团队把大量资源投入到“怎么绕开限制”上结果产品没做起来反而把自己搭进去了。我的态度很明确与其研究怎么让AI“什么都能说”不如研究怎么让AI“在该说的时候说得准在不该说的时候守得住”。后者才是AI产品长期发展的根基。5.2 四道防线搭建可控生成体系那做正规AI产品内容安全应该怎么落地这里分享一套我在实践中逐步搭建起来的方案不管做的是AI聊天、AI绘画还是AI视频都可以参考。第一道防线是输入侧风控在用户请求进入模型之前先做一轮基础检测把明显异常的输入拦截下来减轻模型侧的负担。第二道防线是模型侧对齐通过系统提示词和微调让模型本身具备判断能力知道什么内容不能碰这一道是最核心的因为它决定的是模型的上限。第三道防线是输出侧审核模型生成的内容不能直接展示给用户必须先经过一道审核服务文本用关键词和语义分类双引擎图片走视觉识别视频做抽帧检测。第四道防线是人工抽检机器审核永远会有漏网之鱼定期抽检和用户反馈闭环是最后一道保险。听起来环节不少但实际工程化之后每一道防线都可以做成异步的、低延迟的管道。我现在的习惯是优先把输出侧审核做成强制同步拦截模型输出后必须通过审核才能返回给用户其他环节可以逐步完善。产品做内容安全不是要给用户添堵而是给用户一个稳定可靠的使用环境。6. 岗位变化AI产品经理和AI测试工程师都在重新定义6.1 AI产品经理核心是“场景翻译能力”今天的热词里有“AI产品经理”和“AI测试工程师”这两个岗位最近一年变化非常明显连带着很多技术团队的组织架构都在调整。我看见过不少伪AI产品经理日常工作就是拿生成式工具写一份PRD然后把模型输出包装成产品方案。这不叫AI产品经理这叫打字员。真正的AI产品经理核心能力是“场景翻译”也就是能把一个模糊的业务诉求翻译成技术团队能理解、大模型能执行的方案。比如“专利相关链接AI辅助”这个场景普通产品经理可能只会写一句“帮助用户快速找到相关专利”而合格的AI产品经理会进一步拆解用户是在做专利检索还是侵权分析检索的条件有哪些维度AI辅助应该介入哪个环节是生成检索式、扩展同义词、还是快速对比技术特征这些拆解出来的细节才是技术团队的输入。另外AI产品经理要具备“概率思维”。传统软件的确定性逻辑可以用需求文档描述清楚AI产品则充满了不确定性同一个提示词模型今天和明天的输出可能完全不同。所以AI产品经理需要设计评测标准和兜底方案想清楚“模型答错了怎么办”而不是天真地以为“模型一定是对的”。6.2 AI测试工程师双线作战AI测试工程师这个岗位现在要干两件事用AI辅助测试以及测试AI系统。前者的意思是借助AI能力提升传统测试的效率比如用模型自动生成测试用例、根据历史缺陷预测风险模块、自动录制回放前端操作。后者的意思是把AI系统本身当作被测对象验证它的正确性、鲁棒性、安全性和性能。测试AI系统和测试传统软件差别挺大。传统软件的输出是确定的按下按钮就必然得到某个结果AI系统的输出是概率性的同一个问题问两次答案可能不一样所以不能用“单次结果对不对”来判断质量必须依赖评估集和指标统计。我自己在搭AI测试体系的时候重点看这几个维度准确率和召回率、幻觉率、多轮一致性、极端输入下的表现、响应时间分布以及内容安全命中率。AI测试现在还有一个很现实的问题是测试数据不足。很多人拿通用Benchmark来测业务模型效果看着不错一上真实数据就露馅。我建议团队一定要花时间沉淀自己的业务评估集把真实用户的问题和专家标注的答案收集起来按场景分门别类。这份资产的价值会随着时间的推移越来越大。最后说点个人感受。写这份日报的过程也是我自己梳理信息的过程。今天信息流里关于AI的内容非常多但如果只挑一句话做总结我会说AI行业已经走出了“秀肌肉”的阶段开始踏踏实实解决成本、可靠性、合规和工程化的问题。轻量模型、AI编程、Agent、内容安全、岗位变迁这些东西看着分散背后其实是同一个趋势——AI正在从话题变成像水电一样的基础设施。基础设施不需要多惊艳只需要稳定、便宜、让人放心用。这也是我觉得接下来最值得持续投入的方向。今天日报就到这里明天继续。