芯耀
与非AI
67
大家好，我是杂烩君。
这篇文章不劝你「全信」或「全弃」AI，只聊一件能落实的事——怎么把公司规范变成它能遵守的输入，再用编译、静态分析、最小测试把补丁拦住。
生成与正确性
模型的强项是语感：注释像那么回事，函数长得像见过的开源项目。
嵌入式要命的是那些没人写在题干里的前提：栈深够不够、能不能在 ISR 里走这条路径、volatile 该不该登场、优化一开寄存器访问会不会被「优化没了」。
划重点（类比）：把模型当成刚入职、没看过你们 Wiki的同事。你口头扔一句「按惯例写」，它只能按业内最常见的惯例写——这在纯业务层多半是风格问题，在驱动层经常是时序或数据竞争。你要做的，是把「惯例」拆成条目写进对话或文档片段里，别指望它心领神会。
补一句实操认知：上下文不是越长越灵。整本手册贴进去，模型容易平均用力，把你最关心的三条规范冲淡。
更省事的是写「本次改动的最短背景」：动的是哪路外设、当前时钟树谁已开好、仓库里同类函数叫啥名——各用几行钉死，比几千字背景说明好使。
三类投喂材料
厚厚一叠 PDF 整份粘贴，模型往往抓不到重点。实战里更顺手的，是离源码更近的三类东西。
一份缩写的硬条目：能不能用 malloc、ISR 里允许哪几个库函数、裸机要不要禁用浮点、错误码是 enum 还是 int、头文件分层怎么切——用列表或表格，条数可控，比章程全文好用。
两段golden sample：仓库里大家公认干净的小模块，脱敏后要留住的其实是骨架——初始化顺序、命名节奏、注释写为什么而不是复述代码。
模型「仿写」的能力，往往大于「理解长篇原则」的能力。常见两个坑：只贴总则它照样自说自话；一次贴五千行现网代码当风格参考，噪声又大。
折中办法是每次任务抽三百到五百字的最小相邻切片——同目录头文件包含顺序、近邻驱动的错误码表、旁边函数的注释粒度，够了。
再加一页团队版负面清单：上一次评审里反复被打回的雷区——ISR 里打印、魔数、忘了关中断就碰共享变量——贴出来，专治「顺手一写」。
芯片与工具链是第二层现实：手册里的时序、DMA 与 Cache、RTOS 哪些 API 能从中断上下文调，这些不和规范并列谈，生成物就容易「文从字顺，板子上翻船」。
组里若已有 clang-format、clang-tidy 的配置文件，把路径或关键开关写进说明，让输出先过一遍再进评审，少吵一半花括号；真正要命的风格（禁止某类隐式转换、未检查返回值）交给 tidy 比靠人眼扫靠谱。
三层输入叠在一起，才谈得上「像自己人写的」：
分步生成
整文件甩给模型，diff 一大，你 Review 时眼睛会糊。更省心的办法是拆：先定接口与数据走向，再补实现，最后补超时、失败分支、资源回收。
你审阅也照着这个顺序——先认「契不契约」，再抠细节。
划重点（并发）：有人在 lint 报告里纠结格式，却放过主循环和中断之间那个几比特的标志位。症状是间歇性坏了才难查。
写需求时直接写明：哪几个变量只在 ISR 写、主线程只读；或者必须走队列、关中断、拿锁里的一种，别写「注意线程安全」六个字糊弄过去。
流水线上各人干各人的活——机器做重复规则，人做板级与并发判断。串起来长这样：
按风险分工
省事的一类活——掩码表展开、重复初始化、在你们封装风格里把 HAL 迁一迁——适合模型打底，但你照样要套模板、跑检查，别以为省了测试。
揪心的一类——上电顺序、DMA 环形缓冲与 Cache、进低功耗前后外设状态——模型可以给你检查清单和草稿，可寄存器级谁置位、谁先开后开，最终要和手册、和组里踩过的坑对齐。这里省时间不省责任。
还有一种恼人的：模型给你短了、漂亮了，却违反了你们的静态规则（比如隐式窄化）。这类别跟模型辩论三回合，多半不如加一条明文规则或换一段 golden，比讲大道理管用。
走 C++ 又想省重复代码时，别让模型起手就设计七层继承。先把具体类型跑通，接口稳定了再请它帮忙抽共性；一上来「给我一套通用策略模板」，常常得到能编、但半年后的自己也不想读的一坨。
往下这张是工程师脑子里的分岔，用来决定你怎么分工：
合入前检查
把编译选项和 CI 对齐再谈「能编过」；本地 Debug、CI Release 不一致，UB 和栈行为会变脸。
静态分析规则集用团队同一份；别自己关掉规则只为了绿。给模型的输入里写清
调用上下文：这段会不会在 ISR、会不会被多任务重入。动到外设或 DMA，准备
最小复现：能冒烟就别只靠「我肉眼看过了」。模型加了 volatile 或 memory barrier，对照手册问一句：是需要，还是它慌了。用 C++ 时把
构造/析构里能干啥
- 写进约束：构造别拉长时间线去等硬件、析构别关还没停稳的外设——否则它按桌面 RAII 习惯写「顺手」，掉电或复位路径里全是坑。
划重点（UB）：有些代码 -O0 侥幸活了，-Os 一开刀，变量像从来没人读过。表现往往是「某次重构之后」「只在这一块板子上」才出问题。别靠模型乱点关键字挡枪；分析工具 + 正确序的访问约定才是底子。
规范沉淀
团队可以把「常用 prompt 段落」「负面清单」「golden 链接」放进仓库里的 docs/ai/ 之类目录，和编码规范一样打版本。
谁要是单独在 IDE 里维护工程提示，记得把长期有效的约束和一次性会话参数分开——前者该进仓库、该过评审；后者随便。
不然换个人新开聊天窗口，昨天口头说死的规矩今天就蒸发。
自动化吃规则，人吃语义与现场：
一份打通“应用→驱动”的Linux底层修炼指南！
