你有没有过这种体验。

用AI帮你看了一份原理图，讨论了引脚分配，分析了接口方案，聊得很深入，妈耶，觉得这AI太懂你了。

第二天开新对话，这些全没了。

你得重新描述一遍项目背景，重新描述一遍硬件接口，重新解释一遍你要干什么。AI用一双无辜的大眼睛看着你，仿佛你们从来没见过。

我踩过这个坑。

而且踩得很惨。

大概一年前吧，我在做一个有感无刷电机的项目。当时用Gemini的网页版，当时我觉得这模型能力最强，想着让AI帮我把整个驱动方案理清楚。引脚怎么分配，PWM频率怎么设，霍尔传感器的接口怎么处理，一个个聊。

聊了十几二十轮吧。

开始还挺顺的，AI给的方案像模像样，给我写的程序，一下载进去，卧槽电机竟然转了，我照着调试，哪怕完全没接触过电机项目，觉得这事很快就能搞定。

然后就开始不对劲了。

越到后面，它给的调试方法越扯淡，我按它说的做了，代码也改了，就是调不出来。回去问它，它换了一套方案，我又照着做了，还是不行。再回去问，它又换了一种说法。

就这么陷入了死循环。

更让人崩溃的是，聊到后面你明显感觉到AI开始变傻了。前面还条理清晰的，后面开始前言不搭后语，前面讨论好的引脚定义跟后面的对不上。你纠正它一次，它说好的我记住了，并且和我保证这次一定可以，然后一试又不行。

那种感觉怎么说呢。。。

天都塌了，这叼毛简直就是渣男一样，承诺都是骗人的。。。

辛辛苦苦花了好几天，才把项目背景教会它，把引脚分配、外设初始化顺序、调试经验全都喂给它了。结果上下文一满，这个对话直接废了。

而且你还没法抢救。

那些经验，那些讨论出来的方案，全都在对话记录里，跟一堆闲聊混在一起。你想整理都无从下手。你甚至不知道哪个版本是对的，哪个是已经被推翻的，因为AI在同一个对话里给了你三四个不同版本的方案，你自己都搞混了。

我当时就想，这也太扯了吧？？？

这不是我一个人的问题。

后来我发现，大多数用AI辅助开发的，几乎人人都踩过这个坑。工具换了又换，从Gemini到GPT再到Claude，场景变了又变，从驱动开发到系统架构到调试排障，但那个核心问题始终没变。

经验留不住。

但是这个问题，放到团队层面看，就更致命了。

你想想看，项目做了一半，有个工程师离职了，新来的人接手。问这个引脚为什么这么接，这块电路的设计依据是什么，上一个人只能翻聊天记录，翻半天找不到。因为当时只在对话框里讨论过，没有留下来。

或者更常见的，方案商那种环境，项目一多，工程师流动性也大，每个人写的程序架构都不一样。有的喜欢用HAL库，有的直接操作寄存器，代码风格不同，注释也参差不齐。接手的人光看代码就能看疯掉。

更别提那些用AI聊出来的经验了，关掉对话框，什么都没了。

最近有个做方案商的客户找我，说的就是这个事。他们工程师流动性大，项目又多，每个人的开发习惯都不一样。

然后团队也不大，气得他都想自己学软件干了。

我当时就跟他说，要借助生产力的杠杆，上AI。

否则你学1-2年，都不一定能做，能接手你现在的项目。

只要用AI把项目记忆搭建起来，自己看得懂代码，就能指挥AI帮你改，但看懂和会改，完全是两个水平。

什么叫项目记忆呢。

坦率的讲，就是把你项目里所有关键信息，以结构化的方式，存在本地文件里，下面是我设计了一个skill，帮他结构化项目的效果。

不是存在对话框里，不是存在某个人脑子里，而是白纸黑字写成文件，放在项目目录下。

比如你的功能需求是什么，原理图里的引脚怎么分配的，参考资料和数据手册在哪，代码架构是什么样的，每个模块负责干什么。这些东西不应该只存在于某一次对话的上下文里，它们应该像项目的DNA一样，随时可以被读取。

以上，都是通过设计AI工作流自动帮我做的，人工要做到这个程度没个3，4天搞不定，现在10分钟到半个小时完成。

这样的话，你每次开新对话，不需要从头描述。AI只需要先读一遍这些文件，就能立刻进入状态。换一个人接手项目，也不需要翻聊天记录，看看项目目录里的文件，就知道这个项目是怎么回事。

听起来很简单对吧。

讲真，我一开始也觉得简单。以为写几句提示词就行了，搞个模板让AI按模板输出，不就完事了嘛。

不是的。。。

我自己为了把这个东西跑通，连续干了一个多月，每天10个小时。一天10个小时，一个多月，你就知道我有多头铁了。

这个玩意跟写程序一模一样。你得先搭个框架出来，然后在真实的项目上去验证，发现问题就优化，优化完再跑，跑完发现问题再改。每一个环节都得在实际项目上跑过，才知道哪里有问题，比如小到一个排版细节都要优化。

我一共做了5,6个模块。

一个是硬件接口分析，你把原理图扔进去，它自动把所有MCU引脚分配整理出来。哪个引脚接什么，什么复用功能，有效电平是什么，软件初始化要注意什么，全都给你理清楚。以前这个东西要自己一个一个从原理图里抠，现在自动就搞定了。

一个是功能需求整理。把那些散落在微信聊天记录里、客户口头描述里、零散文档里的需求，全部整理成一份人能看懂的功能说明书。这一步太重要了，因为大部分嵌入式项目的需求，一开始都是非常模糊的。

还有一个是参考资料自动归档，数据手册、应用笔记这些开发用的文档，自动归到对应的文件夹里。

最后一个是我觉得最实用的，对已有代码库的智能问答。哪怕是个别人写的老项目，你直接问它这个模块怎么工作的、这个中断是干什么的，它读源码直接回答你。不用再找写这段代码的人了。

听起来好像每个都不复杂对吧。

但是从第一版到最终稳定，中间迭代了不知道多少版。

有的模块第一版看着还行，放到实际项目里一跑，发现场景根本覆盖不了。有的模块逻辑上说得通，但是AI执行的时候总是跑偏，得反复调整指令的粒度和边界。

这个过程中最折磨人的，是你永远不知道什么时候算够了。你觉得这一版应该可以了吧，拿去跑了一下，又发现一个边界case，又得改。改完再跑，又发现新的问题。

就这么一个循环接一个循环，跟调bug一样，无穷无尽。

但是最后跑通的那一刻，那种感觉太爽了，哪怕结果只有70-80分。

我跟你说几个具体的效果吧。

以前要搭一个新项目的文件结构，光是整理目录、规范命名、写说明文档，半天就过去了。现在用这套工作流，半个小时，项目文件的完整框架搭起来了，硬件引脚定义全部整理好了，功能需求也结构化输出了，开发用的参考资料也自动归档到对应文件夹里了。

以前这个事情要做到这么规范，要花很长时间，而且需要工程师有很强的自觉性去维护文档。说句难听的，大多数嵌入式工程师，你让他写代码可以，你让他写文档，他宁愿再写一套代码。

现在不是靠自觉了，是靠流程。AI帮你在前面搭好架子，你只需要在这个架子上干活就行。

那个方案商客户用了以后，原话就是，感觉很智能。以前要花很长时间才能做到的规范化。

最近也有一些老板找我聊这个事，说想给自己的团队搭建类似的AI工作流。如果有这个需求，可以找我，目前刚起步阶段，价格历史最低，哈哈。

我也不知道我这套思路是不是最优解。我自己也还在摸索，也还在迭代。

但是有一件事我是真的觉得很重要。

AI工具越来越多，聊天越来越方便，这当然是好事。但是方便的另一面是，经验都留在了对话的上下文里，关掉就没了。

这跟人类文明早期的问题一模一样。

在文字发明之前，所有的知识都是口口相传的。老猎人教小猎人怎么追踪猎物，老工匠教小工匠怎么打铁，全靠脑子记。传着传着就丢了，走形了，甚至传错了。

后来人类发明了文字，知识可以写下来，刻在泥板上，写在竹简上，印在纸上。知识的传递不再依赖于某个人是不是还记得，不再受限于某个人在不在这个团队。

这是人类文明真正起飞的起点。

我觉得AI时代的项目开发，现在正处在口口相传的阶段。大家都用AI聊项目，聊得很好很深入，但是这些知识只在对话里，关了就没了。换个人来，得重新聊一遍。项目换了一轮，前面的经验就断了。

我们要做的，就是给AI时代的开发工作，发明一套文字系统。

把项目知识从对话里提取出来，结构化地保存下来，让任何人在任何时候都能读取和使用。

这就叫项目记忆。

不是什么高深的东西。但我始终觉得，这可能比学会用某一个AI工具更重要。

因为工具会变，会更新，会被替代。但你沉淀下来的项目记忆，是你真正的资产。

原创不易，如果觉得这篇文章能让你学到东西，麻烦给我安排个赞和在看，我是欧工，一个懂嵌入式开发的AI工作流实践者。