本文由分享稿整理为博客测试稿。保留展示内容和图片，改为连续阅读；讲者备注与内部编辑记录未收录。

1. 怎样让 AI 接上你的工作

用项目管理组织工作，用带新人的方法指导 AI：先交接清楚，再执行、反馈、验收和沉淀。

先讲思路

怎样交代任务、提供资源、约定做法，并判断结果是否合格。

再接工作流

把交接方式变成任务说明，把资源变成可访问的资料和工具。

最后看案例

金蝶 ERP、分析仪接入，再看硬件验证和实际建库。

人负责目标、取舍和最终验收；AI 协助梳理、执行、自查与修订。

带人的思路 → 任务交接 → 接入工作流 → 真实案例

2. 像带新人一样， 按小项目组织工作

项目管理与带新人使用同一套方法；先判断当前小项目是在探索路径，还是按已有方案执行。

需要探索时

让 AI 找路线、试关键假设，交付可行方案、验证证据和剩余缺口。

已有方案时

按确认的规范与工具执行，交付符合要求的成果和验收记录。

人的指导贯穿

补资源、作取舍、给反馈；按表现安排阶段检查，再决定继续、转向或交付。

探索也是小项目。路径验证后进入执行；执行中发现新缺口，可以再开一个探索小项目。

3. 一张交接卡， 讲清四件事

先说清当前任务所需的基本条件；细节可以在执行与反馈中逐步补齐。

下任务

说明本轮是探索还是执行，以及目标、交付物、范围、依赖和检查点。

定规范

AI 辅助草拟、人确认本轮规则；变更说明理由、版本与影响范围。

给资源

提供资料、工程、工具与完成任务所需的访问范围。

定验收

探索验路径与证据；执行验成果与效果。明确由谁确认、何时交付。

四项是交接时要考虑的方向，不要求一开始就把所有约束写全。

下任务 → 定规范 → 给资源 → 定验收 → 反馈更新

4. 使用人的工作逻辑， 不代表使用人的工具

工作方法与工具操作是两层：保留目标、判断和验收，按任务选择 AI 的执行入口。

继承工作方法

理解目标、查找依据、执行、检查、修正；保留步骤之间的判断与反馈。

调整工具入口

优先用命令行、API、SDK 和结构化数据，直接完成操作、取得结果。

按同一目标验收

不以点击过程是否相同判断成败，而看产物、测量和实际效果是否符合要求。

“像人一样做事”指工作逻辑，不等于复刻人的鼠标、键盘和界面操作。

工作逻辑与目标 → 适合任务的工具接口 → 真实产物与数据 → 验收与反馈

5. 把金蝶 ERP 接入 AI 怎么做

6. AI 提出方案， 人决定先探索哪条路

目标是把金蝶云星空 ERP 接入系统。先比较官方 API 与模拟操作，按实际成本作取舍。

AI 提出两个方向

寻找官方 API，或者通过浏览器模拟操作完成工作。

人补充判断条件

AI 当时倾向模拟操作；考虑到资源消耗，我更倾向官方 API。

继续探索 API

让 AI 沿官方接口方向继续找证据，先不把初始倾向当作最终方案。

探索项目的验收是“有依据的可行路径”；模型给建议，负责人按目标和约束作取舍。

接入目标 → API / 模拟操作 → 比较资源成本 → 人作取舍 → 继续探索

7. 拿不到文档， 就先把资料条件补齐

AI 找到了 API 线索，但无法直接取得文档；人介入找到开发者入口并完成注册。

让 AI 给出线索

要求给出链接，再由人找到金蝶云星空开发者页面。

人完成登录条件

注册后能够看到 API 文档；通过 CDP 连接已登录浏览器辅助访问。

AI 整理可见文档

结合模拟操作与低速采集，将可访问的 API 文档整理为后续可检索资料。

给资源也可以成为一个小项目：先交付可查阅的资料，再推进业务接口实现。

找到链接 → 人注册 / 登录 → CDP 辅助访问 → 整理 API 文档 → 形成资料库

8. 文档有了， 关键参数从真实操作中确认

接口描述还不足以确定某些调用参数时，让人完成一次真实操作，AI 在旁取得必要证据。

明确剩余缺口

不凭习惯填猜测值，先列出哪个参数或上下文仍然不清楚。

用 CDP 观察操作

由我在浏览器登录，AI 通过 CDP 观察请求，识别当前业务所需的关键数据。

回到 API 验证

用取得的参数完成接口调用并核对结果，再整理成可复用能力。

CDP 在这里帮助补齐调用依据；一旦路径明确，主要业务继续走 API。

发现参数缺口 → 人登录并操作 → CDP 观察请求 → 确认关键数据 → API 验证

9. API 做主通道， 待办单独用 CDP 补齐

当时可用的 API 路径未覆盖待办提示，就把这个缺口再拆成一个小项目。

主流程保持 API

已验证的查询继续使用原有 API 路径，不因一项缺口推翻整体方案。

待办独立接入

针对待办功能建立单独的 CDP / HTML5 通道，并分别检查结果。

记录边界与复用

明确哪类任务走哪条路，保留输入条件、反馈与退出方式。

成熟路径继续执行；新缺口单独探索、验证后再接入，逐步扩展工作流。

API 主路径 → 发现待办缺口 → 单独探索 CDP → 验收待办通道 → 形成明确分工

10. 把逻辑分析仪接入 AI 怎么做

11. 先验证现成路线， 再决定是否改造

把“让 AI 使用我的逻辑分析仪”作为探索小项目：先给源码、找路径、验证基础能力。

先给探索资源

知道配套软件有开源源码，就把源码交给 AI，要求分析哪些路线可行。

先验证 sigrok-cli

当时未找到可直接采用的官方 CLI；先实现 sigrok-cli 路线，基础功能验证可用。

人指出实际缺口

对照自己使用分析仪需要的功能，发现基础可用仍未覆盖需求，决定继续改造。

探索交付的是路线和验证证据；“能采到”只是阶段结果，还要对照真实使用需求。

给源码 → 探索路线 → sigrok-cli 基础验证 → 对照实际需求 → 决定改造

作者博客 · 早期阶段

12. 参考官方源码， 做出 CLI 和 Skill

把已识别的能力缺口变成执行项目：人定需求，AI 参考源码开发，并持续验证。

CLI 承接设备能力

参考官方开源实现开发 native CLI，连接原有驱动与资源，完成实际操作和数据返回。

Skill 承接使用方法

写清测量目标、通道含义、采集条件、解释方法和什么时候需要补测。

按需求一起迭代

把使用中不满足预期的地方具体反馈，修改实现，也同步修订 Skill。

CLI 让设备可调用，Skill 让 AI 知道如何使用和判断；两者一起形成可复用能力。

明确缺口 → 参考官方源码 → 开发 CLI → 形成 Skill → 按反馈迭代

公开实现与文档

13. 用已知波形校核， 再让解析结果可信

先由人确认信号产生正确，再让 AI 通过 Skill 采集和解释，逐项比对预期。

先验“真的看到”

准备有明确特征的波形，确认发生端正确，再检查通道、边沿和时间关系。

再加入解析器

对已知协议或已知内容做解码，核对恢复出的结果与预期是否一致。

人校核并修订

有偏差就区分波形、采集、参数和解析问题，修改 CLI、解析器或 Skill，再验收。

先验工具，再用工具验产品；已知输入、真实采集和人工校核共同建立可信反馈。

确认发生端 → Skill 采集 → 对照预期 → 加入解析器 → 校核与迭代

早期波形与 UART 验证记录

后续实现

14. 让 AI 完成电机控制时序验证 怎么做

15. 先固定外设基线， 写清时序与代码要求

把电机控制的时序联动作为一个小项目：前期已调好的外设和接口是输入条件，再明确时间预算与工程规范。

继承已验收的外设

记录外设配置、引脚、接口及已通过范围。影响基线的修改要说明理由，并重新验证。

把时序写成验收条件

本例 PWM 周期 50 µs；选中低侧开启后约 1 µs 触发，写回距下一谷底至少保留 1 µs。

编码与注释也是条件

遵循当前版本化格式配置；函数说明用途、参数方向和返回值，关键时序依据要能交接。

验收同时看：外设基线是否保持、时序是否满足、代码与注释是否符合约定。

外设基线 → 时序约束 → 编码与注释 → AI 实现 → 实测验收

当前代码风格基准

出处：项目 style_requirements_reference.md · 当前机械格式（完整小节）

text
C11；4 空格缩进；禁止 Tab；最大行宽 120。
控制语句的左大括号与语句同行。
函数定义的返回类型单独一行，函数名和左大括号所在行采用 Attach 风格。
指针星号靠类型侧，例如 uint8_t* data。
case 相对 switch 缩进一级。
自动排序 include，并为单行控制语句补齐大括号。
Doxygen 标签使用反斜杠形式，例如 \brief、\param、\return。
文本文件统一 LF。

本条为当前小节的完整要点转写，省略私人权威目录；不是逐字引用。

函数注释要求

出处：代码格式规范 README · 函数文档规则（连续完整条目）

text
Documentation for functions MUST be written in function implementation (source file usually)
Function MUST include `brief` and all parameters documentation
Every parameter MUST be noted if it is `in` or `out` for *input* and *output* respectively
Function MUST include `return` parameter if it returns something. This does not apply for `void` functions
Function can include other doxygen keywords, such as `note` or `warning`
Use colon `:` between parameter name and its description

保留连续原文条目，去除列表前缀；未显示私人路径。

16. AI 在约束内实现， 通过仪器读取真实结果

基于已调好的外设和给定规范实现控制链路；自建工具负责采集、读状态和返回可复核的数据。

能调用

开发 AI 能调用的接口，连接仪器底层能力，提供设备选择、采集配置和状态读取。

能理解

原始波形与协议数据经过分析，形成边沿、时序、错误和验收结果。

能改进

把结果与代码和目标对照，提出修改，再用测量判断是否有效。

沿用人的工作逻辑，操作通过工具接口完成：构建、采集、分析、检查、反馈。

调试器 / 分析仪 → 采样与状态 → 分析结果 → 判断 → 复测

  • 给资源：调试器、逻辑分析仪与自行开发的工具接入。
  • AI 执行：按时序预算、代码风格和注释要求实现；格式检查与硬件验证分别进行。

DreamSourceLab 官方 DSLogic Plus 产品图片

DSLogic Plus · 观察数字信号与时序

DreamSourceLab 官方产品图

图片来源

SEGGER 官方 J-Link BASE 调试器产品图片

J-Link · 读取芯片内部状态

SEGGER 官方产品图；BASE 为系列示例

图片来源

17. 按时序约束检查， 让失败和复验都有证据

真实历史案例：首次触发落在错误半周期；调整触发配置后重新采集，再用长抓取验证覆盖与余量。

先定义信号

明确通道与探针含义。

再分析边沿

原始采样计算时序关系与余量。

保留范围

开发板时序通过不等于整机验证通过。

修正后长抓取：2000/2000 周期满足所检查的低侧条件；1999 条有效谷底估算中，最小写回余量 9.125 µs。

  • 定验收：按低侧窗口、采样时刻和写回余量判断。
  • 反馈：失败暴露的是触发相位偏差，不能用“编译通过”结束任务。

电机控制 PWM ADC 硬时序真实采样：修正前后对比与长抓取验收结果

2026-07-28 · 硬时序修正前后真实采集

原始八通道数据提取六个主要信号 · 独立长抓取验收

原分享稿还包含交互式时序演示。本测试稿保留上方真实采样图和本节验收数据，交互控件没有嵌入。

18. 修正代码， 也修正下一轮执行的约束

这个小项目沿同样的循环推进：继承外设基线、确认约束、AI 实现、测量检查、反馈并同步修订。

检查后反馈

说明具体哪里不满意及判断依据。

同步修改

修正产物，补充或修订对应规范。

回到执行

AI 按新规范继续做，完成后再次检查。

本例修正触发配置后复测；可沉淀的是触发相位、探针含义和时序验收方法，而不只保留一次“通过”。

  • 变更确认：说明为何改规则、影响哪些结果；确认新版本后，按影响范围复验。

  • 共同定约束：外设 / 时序 / 风格 / 注释

  • AI 实现：按基线与规范编码

  • 实测检查：真实波形与软件检查

  • 指出差距：定位触发相位偏差

  • 同步修订：修代码、补约束与检查

达到本轮验收标准 → 负责人确认 → 产物与规范版本归档 → 交付 / 整体验收

19. 让 AI 建好 KiCad 器件库 怎么做

20. 先定规范， 再让 AI 动手

规范可由 AI 协助梳理、人确认。下方可悬停展开实际 skill 的完整段落，再据此执行与检查。

原理图 / 符号规范

单位、网格、引脚关系、图形与预览要求。

PCB / 封装规范

焊盘、孔位、方向、几何依据和变更范围。

3D 规范

模型来源、真实尺寸、配准、例外和入库条件。

AI 辅助起草，人确认本轮版本；检查后的改动说明理由与影响，再确认、再执行。

  • 定规范：先给原理图、PCB、3D 的判断依据，作为本轮执行和检查基准。

单位与网格

出处：实际建库 SKILL.md · 单位规则

text
原理图库统一英制 mil 绘图（默认连接网格 100 mil，紧凑阻容可用 50 mil），PCB 封装库统一公制 mm，3D 按 mm 核验尺寸与配准。封装尺寸不为凑网格而取整；KiCad 文件及工具输入按原生格式处理，不能直接缩放资产来改显示单位。

符号绘制与预览

出处：实际建库 SKILL.md · 图形规则

text
符号统一使用 KiCad Default 原生主题；IC 等方框使用 `background` 本体填充（默认浅黄），简单图形保持原生类别画法，有极性电容的实心极板可保留随线色的 `outline`。普通符号不将白色或其他 RGB 硬编码到库；LED 发光结按用户要求以实际光色填充，多色逐通道着色/标识，3D 发光区域配色一致；预览明确使用同一主题和不透明画布，见命名与显示规则。

封装命名与修改范围

出处：实际建库 SKILL.md · 封装派生规则

text
通用封装按几何命名，专用封装加入厂家和机械身份，3D 默认与封装同名。为新器件/新用途调整相似资产时，先复制到 tmp，使用描述差异的新正式名，绝不覆盖原 Footprint/STEP 或批量重定向旧引用；丝印、开窗、Courtyard、模型绑定也在此范围。只换模型也须另建封装绑定组合；不变且已核验的模型可只读共享。原件纠错必须有独立明确的维护范围，详见命名与显示规则。

3D 完整要求

出处：实际建库 SKILL.md · 模型入库条件

text
所有实体器件及其正式封装必须绑定已核验的本地 3D，阻容也不允许缺省；缺少模型、文件断链、未绑定或未配准时仅保留候选 draft，不得正式入库或标为 verified。取得或用现成工具建立合适模型并核验后再入库，不能以备注或占位模型代替。无实体封装的电源、地等纯电气符号不创建虚假 3D。

候选到正式

出处：实际建库 SKILL.md · 工作区与入库边界

text
本技能目录内的 `tmp/<本次任务>/` 用于下载、转换、生成、测试工程和核验。工具输出默认为候选资产。只有适用的工程核验完成后，才将选中的资产分别移入父目录的 `symbols/`、`footprints/`、`3dmodels/`，手册按制造商放入 `doc/datasheet/`。

完整交付要求

出处：实际建库 SKILL.md · 交付要求

text
给出实际修改或生成的资产、来源、版本和核验结果。正式物料交叉检查 XML 与 Symbol 的料号、实现版本、采购选型及模型关联。区分 XSD、工具能读取、KLC、人工尺寸/引脚核验、平台适配及实板验证；不能将其中一步通过写成全部完成。阻塞问题保持 `draft`，适用检查完成才标记 `verified`；JLC 编码留空不属于阻塞问题。

21. AI 按规范做， 做完就检查产物

把指定器件建库作为一个小项目。AI 按确认的规范执行，再逐项检查真实符号、封装和 3D 产物。

符号

按真实脚号表达电气关系。

封装

孔位、方向与实体引脚对应。

3D

模型与安装面、孔位相互核对。

检查时指出具体差距：是产物没有遵守规范，还是规范本身还没说清楚？

  • 小项目：一个指定器件，一组可审阅的交付物。
  • AI 执行：依据规范、手册和模型生成并整理库产物。
  • 检查结果：逐项核对脚号、孔位、方向与模型配准，指出不满意之处。

AI 建库实际产物：H0505S-2WR2 模块符号

定规范 · 脚号与输入 / 输出分组

实际建库报告预览 · 2026-09-07

AI 建库实际产物：模块四焊盘封装

定规范 · 四个实体脚、孔位与方向

实际建库报告预览 · 2026-09-07

AI 建库实际产物：模块模型与检查板斜视图

定验收 · 核对模型与孔位、安装面

实际建库报告预览 · 2026-09-07

22. 修改产物的同时， 把规范也修好

每个小项目都走这一圈：共同明确规范，AI 执行，检查反馈，再同步修改产物和规则。

检查后反馈

说明具体哪里不满意及判断依据。

同步修改

修正产物，补充或修订对应规范。

回到执行

AI 按新规范继续做，完成后再次检查。

每一小块独立交付和复盘；共性经验证后沉淀通用，修订后的规范进入下一轮。

  • 变更确认：说明为何改规则、影响哪些结果；确认新版本后，按影响范围复验。

  • 共同定规范：AI 辅助梳理，人确认

  • AI 做：依据本轮规则执行

  • 检查：工具自查与人的审阅

  • 反馈：具体指出哪里不满意

  • 同步修改：修产物，也修规范

达到本轮验收标准 → 负责人确认 → 产物与规范版本归档 → 交付 / 整体验收

23. 换一种工作， 仍然可以这样交接

用资料整理和网站维护说明方法如何迁移，不堆叠工具清单。

资料整理

给用途、原始材料和分类样例；交付整理结果，验收完整性和来源。

网站维护

给修改目标、页面规则和必要访问；提交预览和变更结果供审阅。

后续电路设计

设计仍在早期阶段，继续用目标、约束、资源和验收推进；不把建库通过等同整板完成。

换场景时，重新填写任务、规范、资源和验收这四项。

24. 从一次任务， 沉淀下一次可复用的方法

不论是探索路线，还是执行已有方案，都通过阶段反馈完成交付，并沉淀下一次可复用的方法。

先有基本约束

为每个小项目明确目标、输入输出、依赖和验收；AI 可协助梳理规则草案。

在反馈中细化

检查后指出差距，修改产物，也更新规范；由确认后的规则指导下一轮。

把共性沉淀下来

达标后归档产物、规范版本和证据；共性沉淀复用，小项目汇合后再验整体。

每块有交付，整体有验收；带新人式反馈不断改善执行，也积累可复用的方法。

基本交接 → 执行反馈 → 细化约束 → 再次验证 → 通用沉淀

25. 结果来得更快， 能力怎样跟上？

AI 缩短了获得答案的过程，也可能让我们绕过原本用来积累经验的环节。

做出来，却讲不清

代码能运行、器件能生成，但对原理、取舍和适用条件理解不够。

少了试错，也少了判断

直接接受方案，缺少自己提出假设、观察失败、修正认识的练习。

遇到变化，又依赖答案

熟悉场景可以完成，一旦条件改变，就难以定位问题或独立调整。

这些是使用方式可能带来的困境。下一步要练习的，是让每次协作也成为理解与判断的训练。

26. 与 AI 一起做事， 也让自己持续成长

每完成一个任务，都多理解一点原理、多练习一次判断，逐步形成自己的方法。

先想，再对照

先提出自己的判断或方案，再与 AI 的结果比较，找出假设和思路的差异。

追问为什么

理解方案为何有效、依赖哪些条件；用资料、实验和真实结果核对关键结论。

复盘，再迁移

记录一次取舍、错误和修正，尝试独立解释，并把学到的方法用到下一个问题。

评价一次协作，也问自己：我现在能否解释、判断，并指导别人把这件事做好？

独立思考 → 对照结果 → 追问验证 → 复盘沉淀 → 迁移应用