三轮评审全打回之后：AI记忆库关上了人工直写的门
字数：约3400字 | 阅读时间：8分钟“人可读，不等于人可直改——这是am项目用一次事故、一份被打回三轮的提案、一天三阶段落地换来的设计翻转。” 一、从一个字段说起：事故是怎么发生的给AI建的”第二大脑”（am项目）有一条铁律：记忆正本是明文Markdown加Git，谁都能打开看。这个设计让审计变得极其简单——git log 一翻，哪条记忆谁写的、什么时候改的，清清楚楚。 但”人人可看”慢慢滑向了”人人可改”。 事故锚点是一次提交 74b004f：一条 rel-amr-delivers-context 的记忆链接记录里，混进了一个schema之外的字段。入库没人拦，落盘没人报，唯一能看到异常的地方——解析器的 parseErrors 统计——因为字段不合法，记录解析直接失败，错误永远不可见。 一条记忆静静躺在库里，看起来完好，实际上永远读不出来。更麻烦的是没人知道还有多少条这样的记录。 事后复盘时发现了更根本的问题：这条记录是人工直接编辑进库的。而整个系统里，人工写入完全绕过归属检查——.ownership.json 里写着这条记录属于哪个 agent，但人工提交根本不看...
一个人四台机器一块任务板：am的多AI协作流水线
字数：约3000字 | 阅读时间：9分钟“把派活做成流水线，把拍板留给人。” 一、14个任务，0个开工第一篇埋过一个伏笔：这个项目由我和几个AI协作开发，一台服务器上的AI做编排，另外几台机器上的AI分头写代码。这篇兑现承诺，把这条流水线拆开讲。 先接上一处线头：上一篇结尾预告的《记忆也有版本号》不会鸽，版本轴的深水区值得单独一篇，往后作为番外插播；按栏目规划，这一篇先走工程线，讲讲这条流水线本身。 再交代起点，免得后面显得太顺。立项时项目手里有什么？一份需求提案、一份设计文档、一轮五路红队评审——结论FAILED，11个阻塞性问题；外加一张14个开发任务的清单。开工数：0。 决策者（系列里称绿叶儿）没打算自己一行行补代码，也没打算找一个”超级Agent”托管一切。最后跑通的东西说出来很朴素：一块任务板，一条纪律，三台机器上各跑一个干活的AI，工头也住在其中一台服务器上。 四台机器在同一张内网里：一台云主机当工头兼工人；一台云服务器专管编码和CI，内部代号龙虾；一台Windows笔记本干编码重活；还有一台挂着博客和Git中转，属于编外人员，平时只在巡检报告里露脸。 二、第一...
把记忆存进Git：am的数据模型与四条底线
字数：约2800字 | 阅读时间：8分钟“索引烧了可以重建，正本烧了就什么都没了。” 「记忆工程」系列第二篇。上一篇讲了为什么要给 AI 造一个”第二大脑”，这一篇往下挖一层：记忆到底长什么样，为什么必须能 diff，以及四条底线是怎么一条条落进代码里的。 一、先说清楚”正本”是什么上一篇发出去之后，被问得最多的问题是：向量库、嵌入式数据库、各种记忆框架都有，为什么偏要从”一堆文件加一个 Git 仓库”开始？ 先给结论：我们要的不只是“存得下”，更要”毁不掉”。 所谓正本，就是把所有派生物全删掉之后还剩下的那份东西。embedding 索引删了，可以从 Markdown 重建；缓存删了，可以重新生成。这些都可以坏，坏了重跑就行。但 Markdown 和 Git 历史要是没了，整个系统就只剩一个空壳。反过来，只要这两样在，索引层随便推倒重来，十分钟满血复活。 这个设计被真实场景检验过。项目进行中，本机的记忆仓库被一次强制重置打翻，AI 在巡检报告里提示了异常。最后我们是靠 Git 的操作日志（reflog）把现场完整恢复的——那些记忆要是存在某个私有数据库里，那次大概率就是永...
给AI建一个"第二大脑"：am项目立项——把记忆存进Markdown和Git
字数：约2500字 | 阅读时间：7分钟“上下文窗口是租来的，记忆得自己盖房。” 一、从一次”失忆”说起上个月，我在两台机器上让两个AI协作开发同一个项目。A机上的AI刚做完一轮设计评审，结论写进了它的会话记录；B机上的AI第二天接着干活，对这份结论一无所知，按自己”新想”的方案把接口改了。等我发现时，两边的代码已经分叉，返工花了整整一个晚上。 这件事之后我盘了盘自己的AI工作流，发现”失忆”无处不在： 会话内失忆：上下文窗口一满，早期聊定的决策就被挤出去，AI开始”自作主张”； 会话间失忆：新会话从零开始，我要么把背景重新粘一遍，要么接受它带着错误的前提干活； 工具间失忆：A工具记住的东西，B工具看不到。换一个工具，等于换了一个没有经验的实习生； 机器间失忆：我在台式机、笔记本、服务器上各跑着AI助手，它们对同一个项目的认知互不相通。 这些问题的根子不在模型。模型的能力一直在涨，但记忆这件事，从来没有一个正经的架构位置——它被默认塞在上下文窗口里，而上下文窗口本质上是租来的临时工位。 二、结论先行：做一个”外置记忆层”am（agent memory）想做的事情一句话能...
中国唯一的开源基金会，注册身份居然是'慈善机构'？
最近开源领域热闹非凡。7000万鸿蒙装机量的数字不断刷屏，HDC 2026上发布了鸿蒙7，openEuler SP4也在6月底的开放原子开源生态大会上正式发布。这些新闻背后，我很好奇支撑这些开源项目的组织架构是什么样的。 作为一个工控系统架构师，我特意去查阅了相关资料，结果发现了一些非常有趣的差异。 第一个发现：慈善基金会vs商会组织民政部的公开信息显示，开放原子开源基金会注册为”慈善公益性法人”。这个分类让我很意外，因为国外主流开源基金会的注册身份通常是商会或行业组织类型。 Apache软件基金会是501(c)(3)非营利组织，Linux基金会是501(c)(6)商会性质，而开放原子基金会却是”慈善公益性法人”。这不仅仅是名称上的差异，而是治理结构和资金运作机制的根本区别。 501(c)(3)允许接受捐赠，资金来源于企业和个人，强调公益性；501(c)(6)则主要由企业会员费支持，代表行业利益；而”慈善公益性法人”在法律框架下运作，资金需要透明管理，运营方式更加严格。 这种差异直接影响了基金会的运作模式。国外基金会可以有更灵活的商业化运作，而中国的基金会更强调”公益性”，资金使...
工业时序数据的断点续传设计：风电场网络抖动时的保数策略
字数：约3800字 | 阅读时间：12分钟“数据丢了不可怕，可怕的是丢了还不知道” 问题背景：偏远风电场的网络困境风电场的选址有一个铁律——风大的地方，通常也是人烟稀少的地方。对于华北平原上几十台风机组成的小型风场来说，4G/5G信号覆盖已经不是什么新鲜事，但”有信号”和”信号稳定”之间隔着一道巨大的鸿沟。 我们的监控系统架构是这样的：每台风机的PLC（可编程逻辑控制器）以50ms间隔采集振动、温度、转速等时序数据，通过边缘计算网关汇聚后，经MQTT协议上报到中控室的时序数据库。数据流设计上，每台风机每秒约产生20条记录，一个50台风机的风场，每秒就是1000条数据在管道中流动。 这套架构在城市里跑得好好的，但到了偏远风场就出问题了。 一个真实的故障场景： 2026年3月，某个风场连续一周出现数据缺口。值班人员查看监控画面，发现图表上每隔几小时就有一段空白——不是传感器故障，也不是设备断电，纯粹是网络抖动导致MQTT连接断开，数据在传输途中丢失了。更让人头疼的是，丢数据这件事本身也被”丢”了——监控面板上只显示空白，没有告警，值班人员根本不知道什么时候丢的、丢了多...
风电场监控系统的假数据陷阱：传感器漂移是如何骗过报警规则的
凌晨3点15分，报警电话响了。 20台风机振动超标——这是我们某风电场项目上线半年以来第一次触发红色报警。我赶紧打电话给现场运维工程师，让他去检查。 20分钟后，现场回电话：”没发现异常，振动值正常。” 我在监控后台盯着那20个”超标”的振动数值，显示4.5mm/s。现场工程师用便携式振动测试仪实测，真实物理值只有4.2mm/s。 差了整整0.3mm/s。0.3mm/s看起来不大，但我们的报警阈值是4.5mm/s，真实值4.2mm/s正常，传感器输出却显示4.5mm/s刚好超标。 这不是系统bug，也不是传输错误，而是传感器漂移——一个在工业物联网里极其普遍，却经常被忽略的”假数据”陷阱。 从传感器到数据库的全链路追踪我们的系统架构是典型的风电场监控：每台风机安装振动传感器，数据通过Modbus RTU协议采集，经过PLC汇聚后，通过4G MQTT上传到云端IoTDB时序数据库，报警规则引擎基于IoTDB的连续查询功能实时判断。 当我发现”后台显示4.5，现场实测4.2”这个差异时，第一反应是传感器本身的问题—...
技术文档写作实践：让代码自解释的工程师习惯
在风电场监控系统的前两年，我写的文档只有两种：给领导看的PPT和给接锅人看的wiki页面。前者满是架构图和箭头，后者通常只有一句话——“部署文档见运维手册”。 而运维手册并不存在。 直到有一次，一个新来的同事花了一周时间才搞懂我写的报警模块配置流程。他跑来问我，我说”这个你看看代码就明白了”。他真的去看了。三天后他在Slack上说：”看懂了，但为什么不写个README？” 那个星期我在工位上坐了很久。一个工作了十年的架构师，交付的系统没有一份像样的文档。 代码自解释的三个层次后来我慢慢总结出来，代码的”自解释”并非不写注释，核心在于分三个层次让代码自己说话。 第一层：命名这一层很基础，但十年了还是看到有人写 List<String> list1 = new ArrayList<>()。 在风电数据采集模块里，我见过这样的代码： 123456789// 改之前public void process(List<Map<String, Object>> data) { for (Map<String, Object&...
风电场IoT数据采集：从传感器到云端的数据完整性保障
在风电行业做了几年监控系统架构，被问得最多的问题不是”用什么技术栈”，而是”数据准不准”。 这个问题看起来简单，背后是一整条数据链路的可靠性工程。从风机塔筒里的振动传感器，到集控中心的时序数据库，中间要经过边缘网关、消息队列、网络传输，任何一个环节出问题，最终看到的报表数字就会和现场实际情况对不上。而在风电行业，数据偏差可能直接影响发电量考核和设备预测性维护的判断。 这篇文章把我在实际项目中踩过的坑和解决方案梳理一遍，重点不在具体代码，而在数据完整性保障的设计思路。 风电场数据采集的特殊挑战风电场的数据采集环境，用”恶劣”来形容都算客气的。 设备分散：一个风电场几十台风机，分布在方圆几十公里的山脊或戈壁。每台风机上有振动传感器、温度传感器、风速风向仪、偏航角度编码器，少的十几 个，多的三十多个。所有这些数据都要汇总到升压站的边缘服务器，再传到远端的集控中心。 网络不稳定：这是最大的坑。风电场多建在偏远地区，场内通信靠光纤环网，但光纤会被施工挖断、被雷击损坏、被老鼠咬断（这不是笑话，是真事）。场外通信靠专线或4G/5G，稳定性更难保障。一旦网络中断，正在产生的数据怎么办？...
遗留系统的渐进式改造：不推倒重来的重构策略
在某能源央企做了十年工控架构，我打交道最多的不是新技术，而是那些已经跑了五六年甚至更久的系统。风电场的监控系统就是典型——最初为了赶工期快速搭建，后来不断打补丁，三年后变成了一座代码迷宫。没有人敢动它，也没有人完全理解它。 每次新人入职，看到代码库里那些两千行的Controller、没有注释的SQL拼接、硬编码的IP地址列表，都会问我同一个问题：”为什么不推倒重来？” 我的回答总是：因为推倒重来的失败率比你想象的高得多。 遗留系统的三座大山在和几个类似系统的改造打交道之后，我总结出遗留系统难以改造的三个核心问题，姑且叫它们”三座大山”。 技术债是最显性的。过时的框架版本、缺失的依赖管理、到处复制粘贴的工具类、没有统一规范的接口协议。我们有一个监控模块还在用Spring 4.x，升级意味着改一堆被废弃的API，而这些API散落在上百个文件里。 知识债是最隐性的，也是最危险的。写了那段代码的人早就离职了，没有人知道为什么某个接口的返回值要加一个看似多余的字段，直到你删掉它之后才发现——下游有个五年前写的报表服务在依赖这个字段做条件判断。这种隐含的依赖关系没有任何文档记录，只在运行时的...
