整理 AI 端到端研发提效的分享材料时，我越来越关注一个问题：一次与 AI 的协作，除了代码，还能留下什么？如果下一次遇到相似问题，仍然要重新解释工程、重新搭环境、重新找日志，那么这次工作的价值就没有充分保留下来。我希望形成一套流程，让需求、设计、实现、验证和复盘彼此衔接，让每次解决问题都成为下一次的起点。

端到端的起点，是可验证的任务

“帮我修好这个问题”适合开启讨论，却不足以指导交付。开始修改前，需要说清楚现象、影响范围、运行环境、已有证据，以及怎样才算完成。对于嵌入式工程，还要明确使用哪一份源码、哪一个镜像、哪块板卡和哪组启动参数。缺少这些条件，AI 很容易把看似相近的现象当成同一个问题。

我把一次任务看成一条可以回溯的链：需求说明为什么做，设计说明准备怎样做，实现记录具体改了什么，测试和实验说明哪些结论成立，复盘说明下一次能复用什么。任何一环出现新证据，都可以回到前面的环节修订，而不是把最初的计划当成不能改变的承诺。

问题与验收条件
  ↓
上下文检索 → 技术设计 → 实施计划
  ↓
代码变更 → 静态检查 → 构建与产物校验
  ↓
目标环境验证 → 原始证据 → 结论与边界
  ↓
脚本、测试、案例与规则 → 下一次任务

把规则、技能与工具分清楚

环境配置是入口。模型连接、开发工具和项目路径需要先能正常工作，但配置了多少工具，并不能说明流程有多完整。我更愿意按职责整理这些能力：项目规则保存长期约束，Skill 组织一类任务的执行方法，工具提供读取资料、修改代码和运行实验的具体能力。

例如，项目规则可以说明构建入口、代码约定和验证要求；排障 Skill 可以要求先记录现象、建立假设、设计实验，再根据证据收敛；MCP（模型上下文协议）则提供连接外部工具与数据的标准方式。源码检索、文档查询和浏览器检查各有用途，工具仍应按任务需要选择。

这三层需要共同落到输入与输出上。仅写“你是一名资深工程师”无法保证结果正确；写清“使用哪个构建脚本、保留哪些原始日志、失败时怎样停止、用什么证据判定完成”，才便于执行和复查。工具能够访问什么，也不等于它被授权修改什么。

用规范管理变化，用工作流组织执行

分享材料中，OpenSpec 与 Superpowers 分别提供了有用的组织方式。OpenSpec 以变更为单位，记录提案、设计、规范和任务，帮助人在存量代码中明确改动边界；Superpowers 一类工作流则把需求澄清、设计、计划、实现、验证和评审组织起来。两者可以配合，但不必为同一项要求维护多份互相矛盾的文档。

以“日志中的手机号需要脱敏”为例，先界定哪些日志属于修改范围、预期如何展示、哪些诊断信息需要保留，再检索实际打印点。实现后不仅检查常见路径，还要验证异常路径与遗漏位置。确认结果后，将规则归档，供后续变更沿用。任务清单被勾选完成，并不能替代运行结果。

团队研发平台还可以把需求编号与设计文档、提交记录关联起来。原材料中的需求与缺陷 Skills 就沿着这条思路，把需求整理、登记、方案设计和实现连接起来。可复用的是这条关联关系；换一个平台，仍然可以保留“需求—变更—验证结果”的追溯方式。

把工作流带到真实目标板上

RK3588 上的 VxWorks 7 多核研发，是这套方法在嵌入式场景中的一个案例。这里的问题会跨越启动流程、中断控制器、定时器、内存映射、调度和用户态程序。只看单个函数，或只让 AI 解释一段日志，通常不足以确认整个系统的行为。

案例材料记录的一个问题，是 CPU 标识的取法与多集群拓扑不匹配：某些原始路径只取 MPIDR_EL1 的低两位，在该工程的拓扑下可能产生重复 CPU 编号，进而影响每 CPU 状态和相关运行路径。这个现象需要沿异常入口、调度与核间协作等路径检查，不能只改一个取编号的位置就宣布完成。这里描述的是该案例中的适配问题，不应推广成所有 VxWorks 平台都存在的结论。

材料中的适配方向，是结合亲和性字段与显式 CPU 映射梳理编号来源，再将关键约束放入检查和构建流程。真正的闭环还包括：生成镜像与设备树，核对大小和 SHA256，完成加载与启动，保存串口输出，再执行目标功能和回归验证。文件哈希用来确认产物身份，不能证明功能本身正确。

源码版本 + 构建配置
  ↓
镜像 / 设备树 / 符号信息
  ↓ 核对产物身份
加载目标板 → 启动 → 执行功能
  ↓
原始串口日志 + 测试结果 + 基线差异

案例方案记录了构建脚本、板端工作流工具、静态契约测试和日志归档等主要执行部件。其中，板端工具负责产物检查、U-Boot/TFTP 启动、串口采集与结果摘要；AI 负责关联上下文、提出假设和整理证据。日志摘要便于阅读，原始日志仍要保留，才能回头核对某个启动标记或异常结论。

给每个结论标明验证层级

我认为这套流程最重要的约束，是不要把不同层级的成功混在一起。设计自洽、静态检查通过、编译成功、目标板启动和功能回归通过，回答的是不同问题。静态契约测试可以检查关键符号、配置或路径约束，却不能单独证明缓存、中断与调度在真实硬件上运行正确。

设计成立：目标、边界与方案能对应
静态检查通过：关键约束可检查
构建通过：目标产物成功生成
板端启动通过：启动证据符合预期
功能验证通过：指定配置下达到验收条件
回归通过：约定场景与重复次数均有记录

本文依据分享目录中的方案与使用材料整理，没有重新审计原工程全部源码和板端日志。材料将 smp-one 记为已验证基线；smp-dual、smp-quad 等实验配置，仍需按各自记录区分静态检查、构建与板端验证状态。这些是材料记录时的状态，不代表所有多核配置已经完成验证，也不替代后续工程结论。

一次启动成功，不能直接推导出长期稳定；没有看到异常日志，也不能直接推导出所有功能正常。对未覆盖场景明确写“未验证”，比用一个笼统的“全部通过”更有利于下一轮实验。

一次任务，留下三类可复用产物

第一类是执行产物：代码、构建脚本、板端操作脚本和功能用例。它们让下一次任务能够重复运行相同的步骤。第二类是证据产物：源码版本、命令、配置、镜像标识、原始日志和测试结果。它们让别人能够检查结论是怎样得出的。第三类是知识产物：设计理由、失败假设、故障案例和适用边界。它们让经验能够迁移，而不仅是重复执行。

这就是我所说的“研发资产工厂”：在完成当前问题的同时，持续积累执行能力、验证能力和解释能力。一个经过验证的修复，可以进一步成为回归用例；一组稳定的上板步骤，可以成为脚本；一种反复出现的分析过程，可以整理为 Skill。规则应在复用中修订，避免把一次实验的偶然条件固化成通用要求。

怎样判断真的提效了

目前这组材料没有提供足以比较的完整效率统计，因此我不会给出“效率提高几倍”这样的结论。后续可以记录问题从发现到定位的时间、构建与上板的人工步骤、重复问题的复用次数、自动检查拦截的问题数量，以及资产在其他任务中的实际使用情况。比较时还要说明任务难度和环境是否相近。

自动化本身也有维护成本。脚本需要随工具链和板卡变化，测试需要避免只匹配实现文本，文档需要跟随工程状态更新。如果没有减少重复劳动，也没有提高结果的可核验性，就需要重新判断这层流程是否值得保留。

从一个小闭环开始落地

对已有项目，我建议先挑选一个边界清楚、能回归验证的真实任务：整理最小上下文，写出验收条件，完成一轮设计与实现，留下测试和原始证据，再判断哪些步骤值得脚本化。先跑通这个闭环，再扩展到需求平台、更多工具或更多目标板。

一份可复用的任务记录

目标：要解决什么，什么暂不处理
环境：源码版本、配置、工具链、目标设备
假设：原因是什么，如何证实或排除
变更：修改范围与对应理由
验证：命令、预期、实际结果、证据位置
边界：失败、未测试与待确认事项
复用：留下的脚本、测试、规则及适用条件

端到端意味着各阶段能够衔接并回溯，并不意味着让 AI 无限制地自动执行。方案取舍、危险操作、验证结论与交付责任仍需要人的判断。我的目标，是让 AI 帮我更快地组织复杂工作，同时让这些判断有更完整的证据支撑。

一次交付的价值，既在于今天解决了什么，也在于明天能复用什么、复查什么。