AI日报：轻量模型、AI编程与Agent工程化

2026年9月5日早上，我照例先把几个信息源刷了一遍，再根据工作群和社区里的讨论，把当天值得记录的事情整理成这份日报。日报不是新闻稿，我不追求把所有AI资讯都搬上来，只挑和自己工作强相关、或者明显影响接下来几个月技术选型的东西来写。今天最突出的关键词有三个：轻量大模型、AI编程落地、Agent工程化，另外AI视频和内容合规也有新动向。如果你是做AI应用开发、模型部署、或者正在考虑用AI改造内部流程的人，这篇内容应该能对上胃口。

1. 今日主线：轻量模型与端侧部署终于成为默认选项

1.1 为什么轻量化成了大家默认的解法

今天最让我在意的，不是某个更大参数的模型发布，而是好几条关于端侧和中小参数模型的新进展。有家头部团队把主打模型的一个小版本做成了能跑在手机开发板上的规格，官方给的宣传点是“离线可用、单Token成本降到可忽略”。这放到两年前是想都不敢想的，那时候大家的惯性思维是“模型越大越聪明”，谁参数多谁说了算。

但从去年下半年开始，整个行业的重心已经从“把模型做大”转向“把模型用起来”。原因其实很直接：第一，成本。云上调用一个大模型的API，对一个日活百万的小应用来说，每个月光推理费用就可能吃掉不少毛利，而端侧或是私有化部署的中小模型，边际成本几乎为零。第二，数据隐私与安全问题。很多企业不愿意把内部文档、用户对话记录放到公网服务上，一个本地可运行的小模型天然规避了这个顾虑。第三，延迟。大家已经越来越没耐心等一个转圈圈的AI回复，端侧推理省去了网络往返，能做到几十毫秒级别。

这里要说明一下，轻量化和“变笨”并不冲突。现在的中小模型已经用上了大模型蒸馏、量化和结构化剪枝这些成熟手段，在很多垂直任务上，能力并不比大模型肉眼可见地差。我记得有组数据，在客服意图识别、合同关键信息抽取这类任务上，一个精简过的7B级别模型，效果能逼近原先100B以上模型的95%，但推理成本只有后者的几十分之一。这个性价比，对绝大多数业务场景来说已经足够了。

1.2 端侧部署必须盯住的四个指标

如果你也想把模型放到端侧，或者做一套私有化部署，我建议不要只盯着“能不能跑”这个最低标准。真正上线之前，至少要把下面四个指标测透：

很多项目死在最后一条上。我见过有人在一款中端手机上跑了一个多模态模型，纯看指标，首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生成加人工审查”。这个时候最忌讳的事情是盲信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，建议先把这张表打印出来贴在工位上。

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正在从话题变成像水电一样的基础设施。基础设施不需要多惊艳，只需要稳定、便宜、让人放心用。这也是我觉得接下来最值得持续投入的方向。今天日报就到这里，明天继续。