我让 AI 写芯片驱动，撞了三周墙后决定重构开发流程
——电动机与纺织厂
这是一个系列的第一篇，分享我个人落地 AI 辅助开发的经验：怎么判断，怎么试错，怎么重构。
如果你在传统行业做软件——不管带团队还是写代码——正在想 AI 编程到底能不能用、该怎么用，这个系列应该对你有用。
一次闲聊带来的判断
2026 年初，一次同学闲聊。一位在大厂做软件的同学告诉我两件事：他们公司已经把一部分软件定制开发工作交给 AI 来做，并且为此缩减了相应的人力。
演示可以挑场景，试点可以挑项目，但缩减人力是真金白银的决定。一家公司愿意为 AI 做这样的决定，说明那些工作是真的被顶上了。我据此判断：AI 编程到了可以正经使用的阶段。
这个判断对我们这行的冲击是实实在在的。招聘、培养、项目管理、流程建设，全都建立在"代码由工程师一行一行写"这个前提上。前提变了，很多事情要跟着变。
从那天起，我开始主动了解 AI 编程的原理、用法和发展阶段。不过我习惯先动手，再下结论。
第一次严肃尝试，撞在了墙上
四月份，我挑了一个真实任务：让 AI 帮我写一颗低边发射芯片的驱动程序。
结果不理想。首版代码出来得很快，但之后整整三个星期，我和 AI 陷入反复重构：改一版，发现问题，推翻，再改。最典型的一次，AI 把两个模块拆开，理由是职责清晰、接口干净；但这两个模块本质上共享状态，拆不开，发现行不通又合了回去。那阵子产出的代码乱、重复多，过程也磕磕绊绊。
复盘下来，主要问题在我自己：我对这颗芯片的工作原理只懂个大概，对 AI 当时的能力边界也没数，却让它在一个公开资料稀缺的专有领域里硬干。
不过这次失败让我摸到了边界：
- 资料充分、模式成熟的工作，比如应用逻辑、流程性编码，AI 已经可以顶用；
- 专有芯片底层驱动这类公开资料稀缺的领域，AI 是短板，得用特殊方法才可能有好的结果。
边界划清楚了，后面的判断反而好做：门槛过了，但过的只是部分场景。
中小公司走不通"让 AI 自己学"的路
接下来的问题是：怎么让 AI 在我们的开发流程里真正用起来？
我最先想的路线是让 AI 自己摸索——给它足够多的资料，让它自己总结出一套嵌入式软件开发流程。和 AI 深入聊了几次之后，我放弃了：这条路需要海量资料打底，我们这样的中小公司，几十个独立项目的积累远远不够。
剩下的合理路线只有一条，很像上世纪的专家系统：不让 AI 自己学，把我们验证过的成功经验直接交给它。具体是两样东西：
- 约束：告诉 AI 该做什么、做到什么程度、产出放在哪里。落地形态是文件服务器与代码仓库的分工约定、开发流程约定、仓库里的文档模板。
- 知识：告诉 AI 怎么做。落地形态是模板里的内容、程序设计模式知识库、技能中描述的过程和方法。
"约束 + 知识"这个框架，后来成了我们整个体系的设计思想。这个系列后面几篇基本围绕它展开：流程部分讲约束怎么定，知识库和技能库部分讲知识怎么喂。
电动机与纺织厂
随着理解加深，我形成一个判断：AI 最终能承担程序员的大部分工作，但它需要一套适合自己的开发流程。
现有的软件工程流程——包括那些厚重的行业流程标准——都是围绕人设计的：文档写给人读，评审靠人逐行看，项目状态靠人手工维护。这些环节存在的理由是"人是这样工作的"。让 AI 硬挤进这样的流程，它的上限就被流程本身锁住了。
那段时间我刷到过一个短视频，讲电动机替代蒸汽机的故事，我很认同：
蒸汽机时代，纺织厂围绕一台中央蒸汽机布局，靠大量传动轴把动力输送到全厂。电动机发明后，工厂主最初只是把中央蒸汽机换成电动机，传动轴原样保留，效率没提升多少。后来有人反应过来：电动机动力分散、可自由启停，根本不需要传动轴。给每台机器单独配上电动机，按电动机的特性重新布置整个工厂，效率才提升了很多倍。
只把 AI 当工具接进旧流程，就像只换中央蒸汽机。想拿到真正的效率，得按 AI 的特性把流程重新设计一遍——这就是我说的"AI 原生开发流程"。
但我们这行错不起
想法可以激进，落地必须谨慎。
我们的产品用在高可靠场景，对稳定性、安全性和失效率的要求非常严苛，现场出一次问题的代价远不是改行代码能了结的。所以"重构流程"在我们这里有个前提：每一步都保留人工审核。AI 起草，人拍板；AI 检查，人定论。这个分寸贯穿了整个系列，也贯穿了我们每一次尝试。
我自己有这些想法的时候，公司正好要推进 AI 在工作中的应用，两边一拍即合，事情就这么启动了。
然后第一次尝试就失败了——我们为新项目搭的第一套体系，在第一个真实项目上没能跑下去。下一篇就讲这次失败。
