同一类问题，第二次必须走同一条路：我把 13 张能力卡装进 WorkBuddy

副标题：一个不写框架、不做算法的人，用 19 个技能把 AI 从「问答框」改成「可复用管线」的真实记录

一、一个想删掉的深夜

去年有段时间我在啃 STM32。某个晚上十一点，ADC 的读数在阈值附近反复横跳，OLED 上的电压后两位一直在抖。

我把问题丢进对话框：「STM32 ADC 读数不稳怎么办」。

回答很快，也很像样：降低采样速率、加均值滤波、注意参考电压、检查地线。我照着改了采样时间，抖动小了一点。第二天换了个板子，同样的代码，读数直接偏了 0.2V。我又问了一次，这次它让我检查 VREF 和分压电阻。

两次回答都对，但两次都不是同一个路径。

问题不在答得准不准。问题在于：我把「判断」留在了对话记录里，而不是留在我的工作系统里。 第二天那个 0.2V 的偏差，本质是上一轮没有把「ADCCLK 必须先算」这件事固定下来——采样时间是可以调的旋钮，但旋钮的合法区间是被分频决定的，顺序反了，怎么调都是碰运气。

那次之后我做了一件事：不再把 WorkBuddy 当聊天框用，开始把重复出现的判断，一个个写成能被复用的东西。三个月后，我这台机器上装着 19 个技能，其中 13 个是同一门课拆出来的能力卡。

下面是我实际做的三条线，和踩过的坑。

二、聊天式使用的三个漏点

先把问题说清楚。用 AI 处理技术问题，聊天模式有三个结构性缺陷，跟模型强不强没关系：

第一，上下文会死。 一次新对话，上次定过的约束全部清零。你上个月定下的「这个项目用 8MHz 外部晶振、PCLK2 按 72MHz 算」，下次要重新说一遍。说得不完整，它就按默认值给你算。

第二，判断没有沉淀。 模型给的是结论，不是决策树。同一个「采样时间取多少」，它是查了手册，还是顺手写了个常见值？你从输出里看不出来。分不出「算出来的」和「猜对的」，是聊天模式最危险的地方——因为猜对的时候，你也不会发现。

第三，交付不可复用。 这次解决完，产物是一段对话。下次同类问题，从头再来一遍，包括重新踩一遍坑。

一句话总结：聊天解决「这一次」，系统解决「下一次」。

三、第一条线：把课程里的判断，拆成能力卡

我学的教材是江协科技的《STM32 入门教程 2023 版》，B 站上的免费课。这门课的好处是讲师会把「为什么」讲透，坏处是——你看完就忘了，下次遇到还是查手册。

于是我把它拆成了 13 张能力卡，一张卡对应一类高频问题：

• adc-sampling-chain — ADC 读数抖、分辨率和采样时间怎么折中
• rcc-clock-first — 外设开了没反应，先查时钟
• timer-param-calc — PWM 频率占空比，PSC/ARR/CCR 怎么定
• isr-minimalism — 中断里到底能不能 delay
• serial-packet-framing — 串口收包错位、定长还是变长
• modular-engineering — 工程一挪位置就报 missing file
• 还有 dma-offload、flash-storage-design、sync-serial-bus、bus-protocol-selection、peripheral-config-method、freq-vs-period-measure
• 加一个路由入口 stm32-jiangxie-2023，负责判断该走哪张卡

每张卡的结构是固定的三段：

R（原文） — 讲师原话，带时间码。比如 ADC 那张卡里引的是：「ADCCLK 最大是 14MHz……72 兆除以 2 等于 36 兆，超出允许范围了，4 分频之后是 18 兆，也超了。所以只能选择 6 分频 12 兆和 8 分频 9 兆这两个值。」——第 21 讲，23:28。

I（方法论骨架） — 把原话整理的决策顺序。ADC 那条链路是「先算参数、再打通路、最后换算」，顺序不能反：

1. 先算分频：PCLK2 = 72MHz，÷2 = 36MHz、÷4 = 18MHz 全部超 14MHz 上限，只剩 ÷6（12MHz）和 ÷8（9MHz）
2. 再定采样时间：总转换时间 T = 采样时间 + 12.5 个 ADC 周期，12.5 = 12 位逐次逼近 + 0.5
3. 手册标的 1μs 不是「正常值」，是 14MHz 下 (1.5 + 12.5) = 14 周期凑出来的极限组合
4. 换算必须先把整数强转 float：V = AD × 3.3 / 4096，不转的话整除恒为 0
5. 判完成只认 EOC 标志，别被 ADC_GetSoftwareStartConvStatus 骗了——它读的是 SWSTART 位，启动后立刻被硬件清零
6. 多通道共用一个 DR，扫描模式必须配 DMA，人手搬不赢几微秒一次的转换

A（应用案例） — 一个具体的、带数值的场景，以及最后实测结果。比如电位器单通道采集：10K 电位器两端接 3.3V 和 GND，抽头飞线到 PA0，要在 OLED 上同时显示原始 AD 值和换算电压。参数不是抄的，是按链路算出来的——PCLK2 ÷6 = 12MHz，采样时间取 55.5 周期（68 周期约 5.6μs），GPIO 配 AIN，序列 1 填通道 0，软件触发 → 等 EOC → 读 DR，换算前先 (float)。实测拧到底：AD 0 / 0.00V；拧到顶：AD 4095 / 3.27V，末位有小幅跳动。抖动怎么处理，卡里给了三条路：双阈值迟滞、连读 10~20 次取均值、裁掉尾数降分辨率。选哪条，取决于下游是「判断开关」还是「显示数值」——这又是一个判断，不是知识点。

这三段里，R 是最关键的。因为它是原始证据。我可以随时回到第 21 讲 23:28 核对讲师原话，而不是相信我自己的记忆或者模型的一次转述。这也直接决定了整套东西的可信度：它不是在「讲知识点」，是在引用证据并给出决策顺序。

效果很直接：同一个问题，第二次提问得到的是同一条路径。不是「这次碰巧问对了」，而是「这次一定走这条路」。ADC 抖动那件事，现在我不再问「为什么抖」，我问的是「这次要多高的采样率、能容忍多少转换时间」——问题本身变了。

四、第二条线：把视频变成能回溯的笔记

能力卡解决的是「判断」，但判断要有素材。我的素材主要来自视频课程，所以我做了第二个技能：把 B 站课程批量转成图文笔记。

这件事的关键不是「转文字」，是两条通道都要读：

只读画面写出来的笔记，是在「看幻灯片猜课」；只读讲稿写出来的笔记，复习时没有图可看。必须按时间戳对齐着写。

实际实现里的坑，记录几个真实的：

• 清晰度不是参数问题。 我一开始以为调 qn 参数就能拿 1080P，实测 accept_description 里明明写着支持 1080P/720P/480P，但 dash.video 实际只回 id=32（852×480）。这是服务端按登录态下发的权限，不是脚本能绕的。480P 看板书够用，就接受了。
• 音轨不受清晰度限制。 不登录也能拿到 dash.audio。所以「没有高清画面」不等于「没有讲解」。
• 讲稿来源要有优先级。 登录态的 CC/AI 字幕是秒级且免费，无字幕才下载音轨做转写。反过来的话，每讲多花十几分钟。

最终的产物是：每讲一篇带截图和讲稿要点的 Markdown，加一个单页 HTML 索引。关键是每个结论都能点回原始位置。

这条线解决的正是我最怕的一件事：看起来完整，但内容是我猜的。 笔记里每个数字、每条公式，都能回到那一帧、那一句话。宁可标「信息不足」，也不要一个漂亮的幻觉。

五、第三条线：把重复动作交给时间

前两条线都是「我需要的时候去用」。第三条线不一样：它不需要我在场。

我做了一个积分播报的技能，定时跑，把我每天的积分状态、连续天数、本期活动、待领奖励汇总出来。同时做签到和「派猫猫旅行」的自动闭环：先查有没有到期待领的，领完再看今天还能不能派，能派就派。

这里我给自己划了一条硬边界：写操作只允许三个已验证的接口——签到、领取、派遣。其它任何写接口一律不调。只读的部分尽量多查，写入的部分尽量少碰。派出前必须先查 daily_limit_reached，到上限就跳过，绝不发写请求。

为什么把这件小事单列成一条线？因为它证明了系统的第三层不是「更聪明」，而是「不需要你在场」。你的判断被写进了流程，流程被写进了时间。

六、抽象出来：三层，和一条判断标准

三条线做完，我发现它们其实是同一个东西的三个层级：

L1 能力卡 = 固化「判断」。 什么情况下走哪条路，边界在哪，什么时候不适用。粒度小，复用频率最高。

L2 技能/管线 = 固化「流程」。 多步骤、有中间产物、可重跑、可校对。它把若干个判断串成一条能交付的路径。

L3 自动化 = 固化「时间」。 定时触发、幂等、失败可恢复。它把流程从「被调用」变成「自己发生」。

判断什么该做成技能，我用一条很土的标准：

• 同一类问题，你回答过 3 次以上，且每次都要重新推导 → 做成 L1
• 多步骤、有交付物、中间产物需要人校对 → 做成 L2
• 周期性发生、几乎不需要判断、但必须准时 → 做成 L3

反过来，只用过一次的问题，别做卡。做了就是负债。

七、几个必须说的坑

写到这儿不能只讲好的。

第一，卡写错了会放大错误。 技能比聊天更危险，因为它更可信。聊天时你还会怀疑，技能跑出来的东西你倾向于直接接受。所以每张卡我都强制写「不适用」字段和原文出处——adc-sampling-chain 里明确写着「只问 DMA 本身怎么配请走 dma-offload」。边界不写清楚，卡就会在它不该管的领域给你一个看起来很专业的错误答案。

第二，技能不是越多越好。 19 个里面，我真正每天用的不超过 5 个。剩下的 14 个是「偶尔但致命」——平时不用，用的时候没有会很痛。这两类要分清，别为了数量去做卡。

第三，成本是真实的。 长上下文、批量抽帧、语音转写，都烧额度。判断标准还是那条：这类任务会不会重复。只做一次的任务，用聊天最快。

第四，别把判断全交出去。 系统能给你路径，但验收仍然是人的事。我现在的工作方式是：让它给出决策顺序和证据出处，我来判断这个顺序在我的场景里成不成立。它负责不遗漏，我负责做选择。

第五，维护成本会悄悄累积。 课程更新了、芯片换型号了、客户端版本升级改了登录态的加密方式——这些都会让一张昨天还好用的卡今天失效。我遇到过的最典型一次，是客户端强制更新后，本地登录态从明文 JWT 变成了加密信封，脚本直接把信封当明文读，鉴权一路失败。这种问题不会报错给你看，它只会安静地什么都不做。所以定期回归一次，比多写三张卡重要。

八、回到那个 ADC

现在再遇到读数抖动，我不问「怎么办」。

我问的是：这次的目标采样率是多少、允不允许上 DMA、转换时间能不能压到 10μs 以内。系统按 adc-sampling-chain 的链路把这些算出来，把每一步的依据附上。

模型其实没变强多少。变的是我把判断放在了哪里——从对话记录里，挪到了一个能被检查、能被修正、能被重复执行的地方。

这大概就是「用 AI」和「用 AI 搭系统」的区别。前者你每次都在赌它这次答对，后者你只需要在写卡的那一次做对，之后每次都对。

——如果你也在重复问同一类问题，从最小的一张卡开始。不用 19 个，一个就够。