这周AI圈的新鲜事不少但最让我印象深刻的还是三条主线AI真的被送上了天开始在大气层外干活政务大厅里的大模型不再只是摆设开始正儿八经地替人办事还有一个很容易被忽略的细节——不少团队正忙着把自家产品从“AI”改名叫“SI”。这三件事放在一起看其实指向同一个趋势AI正在从“会聊天的模型”变成“能扛事的系统”。这篇周报我就围绕这三条主线把这周值得看的信息拆开聊一聊顺便把我自己在工程侧看到的细节和踩坑经验一并放上来。1. 能上天AI开始在大气层外干“脏活累活”1.1 在轨智能卫星自己先挑一遍重点“能上天”这三个字这周可不是形容词而是实打实的新闻。以前AI主要站在地面守着卫星数据现在已经有AI算力被直接送上了轨道在卫星肚子里跑模型。以前卫星拍完数据流程是“先全量传回地面再在机房做目标检测和图像分类”。这套老模式的缺点很突出卫星过境时间只有几分钟下传带宽又有限大量无效数据把信道占得满满的真正有价值的片段反而可能要等下一圈才能传回来情报时效性大打折扣。现在的做法完全反过来了。星上搭载轻量级AI推理板卡直接在卫星上完成云检测、去噪、目标识别只把“值得传下来”的片段打标、压缩再传回地面地面收到后二次精细判读。用大白话说就像你家门口装了摄像头过去是把24小时录像全程传到云端现在摄像头本地跑一个小模型只把“有人经过”的那几秒推送给你。省带宽、省电、省人工这三样在太空环境中每一项都是真金白银这才是星载AI真正解决的大问题。1.2 火箭发射与遥测判读AI参与“上天”的每一道闸口除了卫星在轨应用AI在火箭发射环节的参与度也在明显加深。比如遥测数据判读过去是经验丰富的老工程师在几万路参数里盯异常现在模型先做第一轮筛选把异常概率高的时间段自动标出来再由工程师复核确认。这不是取代人而是把人从“盯数据”的体力活里解放出来让人把精力集中在真正的决策上。发射窗口的辅助决策也在变。气象、电磁环境、空域限制、轨道碎片、历史发射记录多源数据汇聚在一起传统数值计算能算出结果但综合判断的速度跟不上实战节奏。大模型可以把非结构化情报、气象报文、历史任务记录快速整合成决策辅助摘要帮助指挥席在短时间内建立全局认识再由人来拍板。航天AI的意义不在“看起来科幻”而在于它把那些重复、高频、容错率低的环节自动化了。这类应用一旦跑稳复用的价值极高。1.3 航天场景下的AI技术底座这周新闻里能上天的不只是卫星还有几类核心模型在跑量。我整理了一张简表方便大家看明白传统方式和AI介入后的差异应用环节传统做法AI介入后的变化主要技术手段在轨图像处理全量下传、地面处理星上筛选、按需下传轻量化目标检测、云检测遥测判读工程师人工盯参数模型预筛人工复核时序异常检测、告警融合发射窗口决策人工整合多源报告大模型生成辅助决策摘要多源信息抽取、知识增强轨道态势感知数值计算、规则判定数据计算混合判断图神经网络、轨迹预测这张表背后有一个共同逻辑航天场景算力受限、环境极端、样本量小所以“暴力堆参”的路线走不通必须走“轻量化人机协同”的路线。新闻里提到的“可靠AI系统的工程实践”也专门强调过这一点——在容错要求极高的场合自主容错控制比模型本身的精度排名更关键。1.4 航天场景给AI工程带来的四个反向要求航天场景是AI工程的“奥数题”它会逼着你面对很多地面上可以糊弄过去的问题。我把这次看新闻时想到的四个硬性约束列出来算力墙星上板卡功耗和算力都非常紧张模型必须做量化、剪枝常规的FP16推理都要斟酌。可靠性墙发射一次的成本摆在那里模型跑错一次可能就是几亿的损失。模型输出必须带置信度关键动作必须有人工确认。数据墙航天数据标注门槛极高不可能像互联网数据那样标注几十万张。小样本学习、半监督学习成为标配。闭环墙AI不只是在做“识别”还涉及到“决策-执行-反馈”必须设计容错回路。这和做普通接口调用完全是两套思维。如果有朋友在航天或工业场景做AI我的建议是千万不要把互联网场景那套“快速迭代、不行就回滚”的习惯带进去。这类场景更看重的是确定性、可解释性和故障注入测试能力先想清楚“模型如果错了系统怎么兜底”再谈效果指标。2. 能办政务大模型在办事大厅“转正”了2.1 从“问答机器人”到“办事入口”这周政务AI的新闻最打动我的不是某个模型又刷榜了而是应用形态真的变了。过去政务AI给人留下的印象是“智能客服”——你问社保怎么交它从FAQ里给你翻一段答案。现在不一样了大模型直接接入了“一网通办”的办事流程。举个例子你要申请某项补贴AI不会只丢给你一个政策链接而是先通过对话问清楚你的户籍、收入、材料情况自动帮你列出一份材料清单再直接生成申请草稿连需要手填的表格都帮你预填好你确认无误后一键提交。这背后是“问答”向“办事”的跨越。“问答”只需要语义理解而“办事”需要完整的意图理解、要素抽取、流程编排、材料生成每一步都要对接具体业务系统。这个复杂度是翻倍上涨的但一旦跑通用户感知是“这AI终于能干活了”而不是“这聊天机器人又在复读”。2.2 公文写作的“文风对齐”才是硬功夫政务领域还有一个被高频提起的刚需——公文写作。很多朋友吐槽AI写公文“太飘”“一看就是机器写的”根本没法用。这周看到一个让我眼前一亮的样本做法在本地部署的模型基础上拿该单位过往几百篇规范公文做低秩微调再配合“拟稿要点”和“禁用词清单”双重约束生成的初稿在格式、措辞、语气上已经基本对齐本单位文风工作人员只需要做少量修改。这里我想拆解一下为什么这个做法有效。政务公文和普通文章最大的不同不在于“文采”而在于“规范”和“禁忌”。哪些表述绝不能出现哪些固定用语必须保留哪些数据口径必须统一这些都要做成显式的规则约束而不是指望模型“悟出来”。换句话说政务AI的工程重心一半在模型一半在“约束工程”。2.3 政务场景落地必须跨过的三道坎政务AI看着热闹真正落到办事大厅里有三道坎是绕不过去的。第一道是数据安全与本地化部署。政务数据不能随便出域模型必须本地化部署国产算力适配、内网环境下的推理性能优化都是现实问题。第二道是事权归属与责任边界。AI生成的审批意见出了问题算谁的流程上必须有“人审”节点AI只能做辅助预审不能做最终决定。这不是技术问题是机制问题但工程架构上必须提前预留审批留痕、人工复核的接口否则产品根本进不了生产环境。第三道是评测体系要重写。政务AI好不好用不能只看“回答流畅度”要看“办事成功率”。同样是回答一个问题用户能不能拿着AI给的答案成功走完流程这才是金标准。这个评测思路做政务项目的朋友可以直接拿去用。2.4 一个容易被忽略的细节多级协同与知识更新政务场景还有一个很磨人的细节就是省、市、区县多级政策经常会有差异同一件事在不同层级的标准可能不同。AI如果只训了一套通用模型很容易答出“省里对但区里不对”的答案。实操上我建议采取“通用底座多级知识库并行”的架构。底座模型保持稳定各级政策以挂载知识库的方式独立更新问答时根据用户所在区域自动匹配对应层级的政策文档这样才能保证政策调整后AI回答能够同步刷新而不是静默地给出过期信息。这次新闻里虽然没有展开讲这块但做过政务项目的都知道知识更新机制拼的是长期运维能力谁把这个做好谁才能真正“办成事”。3. 还要改成SIAI改名背后的系统化转身3.1 “SI”不是新概念是一次集体转轨这周最有意思的一条动态是标题里那句“还要改成SI”。一开始我以为只是哪家产品又改名换皮但顺着这周的信息仔细看下来发现这不是孤例更像是一次集体动作。不少团队已经不满足于自称“AI产品”更愿意用“SI——系统智能System Intelligence”来定义自己。为什么会有这种改名冲动因为在今天“AI”这个词已经被用滥了。你做一个对话机器人也叫AI做一套自动标注工具也叫AI边际在快速模糊。而“SI”想强调的是另外一层意思我不是单点模型我是把感知、决策、执行、反馈串成完整闭环的系统我更关注“进入生产环境之后的表现”。从我自己的工程视角看这个转向和最近热起来的“AI操作系统”“AI Agent搭建”是一脉相承的。大家开始意识到单靠一个大模型撑不起复杂的业务需求必须有多模块协同、任务编排、状态管理这套东西叠上去叫“AI系统”确实比叫“AI模型”更贴近本质。3.2 AI Agent系统智能的最小可落地单元当前最能把“AI”变成“SI”的工程载体就是智能体。它不是一个聊天框而是一个能调用工具、能多步推理、能根据环境反馈修正动作的程序。一个稍稍完整的Agent至少有四块大脑大模型负责理解自然语言、拆解任务、规划步骤。工具接API、查数据库、跑代码、操作文档让Agent能真正“动手”。记忆短期记忆多轮对话上下文长期记忆向量库里的历史信息保证不“失忆”。规划与反思把大任务拆成小步骤每执行一步都看结果发现跑偏就修正。这周热词里“多AI协作”也值得提一下。单Agent能力再强也有边界所以更实用的做法是“Agent流水线”一个Agent负责信息收集一个负责生成内容第三个负责质量检查各司其职串成一条流水线比一个Agent干所有活更稳定也更容易定位问题。3.3 从“AI”到“SI”之后模型部署和AI工程实践的挑战翻倍“改成SI”提得轻松落地的第一关就是模型部署。实验室里模型跑通和生产环境稳定运行完全是两种工作。这周热词里“AI模型部署”“AI工程实践”高居不下说明大家已经开始扎扎实实啃硬骨头了。模型部署有几个常见大坑我一个个说。第一是推理性能与显存耗尽问题。并发请求一上来算力直接打满响应时间疯涨。第二是排队和超时治理不加队列控制就会出现雪崩。第三是灰度发布与快速回滚模型版本升级不能一刀切必须小流量验证后再全量。第四是可观测性不能只看模型指标输入分布漂移、输出格式异常、调用失败率都要纳入监控大盘。还有一个特别容易忽略的地方资源预留。做系统智能产品不能只给“主模型”留资源还要给路由分发、知识检索、工具调用这些周边模块留足空间。我见过不止一个项目主模型指标漂亮但整体系统在高峰期直接卡死就是因为周边模块的资源没算进去。3.4 智能体走下服务器与硬件的初步融合这周热词表里有一个格外醒目的词条“openclawros为你的ai代理”。虽然目前还没看到特别成熟的工业级方案但方向很有价值——把智能体接到机器人操作系统上等于让AI第一次拥有了“身体”。与之呼应的还有硬件设计软件开放AI接口的消息像“altium designer ai接口 mcpserver”这类尝试本质上都在做同一件事让AI不再只是生成文字和代码而是能直接跟硬件世界对话。这类融合如果跑通会催生出一批真正意义上的“系统智能”Agent规划任务ROS执行动作传感器反馈数据Agent再调整策略。这和单纯聊天问答完全是两个物种也是我把“改成SI”理解为“系统化转身”的重要原因。4. 本周工具、热词与实战备忘4.1 AI编程工具怎么选我的真实使用体会这周热词里“pycharm好用的ai插件fitten”“codex付费ai编程软件”点击量都挺高。做为经常跟代码打交道的博主后台也有不少朋友私信问我到底该用哪个我统一说说我的使用体会。工具/插件定位适合场景我的真实感受Fitten CodeIDE轻量插件日常补全、单文件小重构上手快对PyCharm友好免费额度够个人用适合学习和小项目Codex付费编程助手复杂任务、多文件改动在复杂仓库场景下更“懂”全局但价格不便宜适合团队按席位采购AI代码生成提示词提示词技巧类跟各种工具搭配见效快重点是把需求拆细明确输入输出约束我的建议是别盲目追新。如果你是初学者或者只做脚本级开发轻量插件完全够用如果你在一个复杂的大型代码库上做高频迭代再考虑付费产品。判断标准只有一个——它能帮你省多少“思考时间”而不是代码补全有多顺滑。4.2 写给业务方的“AI应用使用说明”这周热词里反复出现“AI应用使用说明”“AI演示”我突然想多说一句。很多AI项目最后失败不是模型效果不行而是“使用说明”写得不行。给业务方写文档不能只写“这个AI能做什么”更要写清楚“这个AI不能做什么”尤其是边界和触发条件。比如“本模型擅长写政策摘要但不负责计算补贴金额”“当对话内容超出知识库范围AI会明确回答无法处理请走人工通道”。边界写得越清楚用户期望就越理性你的系统维护成本就越低。我看了不少失败案例发现一个共同规律业务方把AI当成“全能超人”一遇到答不上来的问题就觉得系统坏了。这其实是你文档没写明白。把“能力边界”放在使用说明的第一页比写多少功能亮点都管用。4.3 AI工程实践的方法论沉淀“AI工程实践”能进入热词榜在我看来是个很积极的信号说明行业开始关心可靠性、可维护性这些“脏活”了。现在做AI工程至少要有三样东西一套完整的评测集、一套监控告警体系、一套快速回滚机制。评测集要区分“模型能力评测”和“业务效果评测”前者测模型本身后者测模型进了业务流之后对最终结果的影响。监控不能只看CPU和内存还要看“输入内容分布漂移”和“输出格式非法率”。回滚机制要能一键回到上一版本不能为了一个模型升级让整个系统停摆。这套方法论不是什么高深理论都是我在实际项目里被教训出来的经验。本周新闻里“识的llm智能体自主容错控制构建可靠AI系统的工程实践”其实就是更学术化地讲同一件事——AI系统真正能不能顶住生产环境的毒打看的不是demo是工程细节。5. 常见问题与排查实录5.1 大模型“一本正经胡说八道”怎么治这是后台被问得最多的问题尤其政务场景模型一旦瞎编政策依据后果很严重。我分享三板斧第一强制接地。回答必须附带参考来源来源从知识库检索来模型生成时不改一个字。第二范围锁定。凡是知识库里没有的内容一律回答“未收录”不硬编。第三二次校验。对涉及金额、日期、办理条件的回答增加规则引擎复核不让模型直接输出“表述”。这套组合拳治“幻觉”不能说100%根除但能把事实性错误压到非常低的比例。关键动作不是让模型“别乱说”而是从架构上让它“没法乱说”。5.2 Agent多步执行时“跑偏”怎么办Agent一接上工具开始多步执行就很容易“中间跑偏”。最常见的现象是第一步正常第二步开始自说自话第三步彻底偏离原任务。我的排查心得是三步走。第一步压缩规划长度。把一个大任务拆成多个短任务每个Agent只走两到三步不要让一个Agent背上十几步的规划。第二步加检查点。每执行完一个工具调用强制把输出结果和目标任务做一次相似度校验偏差超过阈值就停下来问用户。第三步留人工确认节点。在关键操作前加人机确认不追求全自动。有人说“全自动才是终极目标”我反而觉得在工程落地阶段“关键节点人工确认”恰恰是让业务方放心跟你合作的最短路径。5.3 政务场景本地化部署的实战坑位这一周好几个朋友咨询政务内网部署的事我统一讲三个最容易踩的坑。第一个是环境适配坑。安全等级保护要求高模型框架的版本、操作系统的兼容性都可能出问题不要在项目启动时才做适配要在立项时就把国产算力适配放在计划首位。第二个是数据脱敏坑。业务系统里的真实数据直接拿去微调是灰色地带建议先做完整的脱敏流程姓名、身份证号、联系方式、住址全部走规则引擎替换再做训练。第三个是权限隔离坑。不同委办局的权限不一样AI系统必须能控制某些内容“对A局可见、对B局不可见”这要求知识库本身就带权限标签而不是在应用层生硬过滤。这三个坑每一个我都在真实项目里交过学费。提前规划好能省下后面好几个月的补救时间。5.4 部署后模型变“懒”了怎么办最后更新一个这周刚遇到的排查案例本地部署的模型上线两周后回答质量明显下降用户反馈“AI变懒了只会复述知识库原文”。查了一轮发现不是模型坏了而是参数配置里“温度系数”被调得过低模型输出几乎失去了多样性所有回答都变成了直接从知识库抽取原文。这种问题最容易在“让AI更保守”的优化过程中出现。政务和航天场景确实要求严谨但温度系数调太低会把模型的归纳、概括能力也一并锁死。我们的调整办法是温度系数保持在0.3到0.5之间同时在提示词里单独说明“可以基于知识库内容进行概括但不要改变数据口径”。这类问题说明AI系统上线后不是终点参数调优和业务反馈的闭环才是长期工作。这周看下来我最大的感受是AI行业正在从“模型秀肌肉”切换到“系统拼可靠性”。“能上天、能办政务、还要改成SI”本质上都是一件事——让AI在真实世界里扛起责任。改不改名不重要能不能在事故率、成功率、吞吐量这些硬指标上站得住脚才是真正的分水岭。如果你正在做Agent或者大模型落地的项目我的建议是少追一点概念多在部署、监控、容错这些不亮眼的环节上下功夫这些东西短期看没那么炫但能帮你撑过最难的工程关。
