无人值守工程团队：Automotive Skills Suite自主每日Standup（PLAN/POLISH/DOCS/RELEASE）运行机制全解析

【免费下载链接】automotive-skills-suite100+ installable Claude skills covering Engineering areas such as, ISO 26262 functional safety, ISO/SAE 21434 cybersecurity, ISO 21448 SOTIF, AIAG-VDA quality (APQP/PPAP/FMEA), Automotive SPICE, and continuous improvement tools — every builder paired with a confirmation reviewer.项目地址: https://gitcode.com/gh_mirrors/au/automotive-skills-suite

Automotive Skills Suite 是一套覆盖汽车工程全生命周期的 Claude 技能套件（152 个可安装技能，76 个 builder + 76 个配套 reviewer），而它真正独特的地方在于：这个项目由一个自主每日 Standup驱动——一个名为automotive-skills-daily-standup的定时任务，每天无人值守地按 PLAN / POLISH / DOCS / RELEASE / TRIAGE 等模式运转，持续计划、打磨、发版、复盘。下面完整拆解它的运行机制。

Automotive Skills Suite 是什么

先简单认识主角。仓库 skills/ 目录下的每个.skill文件都是一个可独立安装的技能，按"builder + 确认 reviewer"成对组织：

• builder：根据 JSON 输入 + 上游工件，生成结构化 xlsx 交付物（HARA、FMEA、TARA、DBC、AUTOSAR 配置……）
• reviewer：对 builder 的输出跑确认措施检查清单，产出带 KPI 与发现项的可视化报告

覆盖域包括 ISO 26262 功能安全、ISO/SAE 21434 网络安全、ISO 21448 SOTIF、AIAG-VDA 质量（APQP/PPAP/FMEA）、Automotive SPICE、AUTOSAR、MBSE、SysML、V&V 等。整条工具链通过稳定的 xlsx 文件契约串联，上游变更会自动传导到所有下游技能。

而 STATUS.md 是这套"团队"的家底表：每个 builder 的领域、配对 reviewer、最后触碰日期，以及 🟢（30 天内新鲜）/ 🟡（陈旧）/ 🔴（孤立）三个健康标志。

每日 Standup 的周节奏总览

整个机制的核心是一个按星期轮转的模式表，每个模式对应仓库里一种固定产物：

每一次运行都会再生成 STATUS.md，并在 docs/AUTONOMOUS_LOG.md 里留下完整日志条目——这份近 2000 行的日志本身就是理解这套机制的最好教材：每条记录都包含模式、动作、触碰文件、测试结果、技能计数、开放 issue 数、判断理由（judgement call）和后续跟进。

六大模式逐一拆解

周一 PLAN：先审账，再派工

PLAN 的选目标逻辑是一条严格的优先级链：

1. 开放 issue 引用的技能（优先处理skill-bug标签）
2. 孤立 builder（没有配对 reviewer 的）
3. 最久未触碰的 builder（least-recently-touched）

选出 3~5 个目标后，每个目标都会带一个"完成定义（DoD）"写成周计划文件（如 docs/weekly/WEEK-2026-W40.md），并通过 API 开立对应的 GitHub issue。计划里还有一道领域扩散检查：刻意避免连续几周只打磨同一领域，保证 safety、cyber、quality、comms 等 13 个领域轮流被照顾。

PLAN 还有一个隐藏职责：用测量代替假设。例如 W39 的 PLAN 曾把"全仓库性 HIGH"的头行探测问题，实测降级为"24 个档案存在、仅 2 处有活症状"再排期——避免为一个虚高的目标浪费一整个打磨日。

周二至周四 POLISH：一天一个技能，只做"小且对"的事

POLISH 是机制里最体现工程纪律的模式。每天的流程是：

1. 按优先级链选出当天目标
2. 完整审计该技能的 SKILL.md、frontmatter、生成脚本与示例
3. 先运行生成器，而不是只读源码——大量静默缺陷（空输出、列错位）只有跑一遍才能暴露
4. 只有命中"自主编辑白名单"的问题才动手改：拼写错误、超长文本、缺失必需字段
5. 其余发现一律记入打磨日志，留给维护者决策

典型的白名单修复案例：control-plan-builder示例文档声称 18 个特性但 JSON 里只有 15 个——这是"小、明确、可验证的事实错误"，当天修掉并重新打包归档；而"触发短语位置需要编辑性重写"这类判断，就只写草稿、不自动应用。

值得注意的是 POLISH 的克制：一次运行只修一个技能，绝不做大型重构。docs/AUTONOMOUS_LOG.md里明确写着判断逻辑——"小的、已交付的，胜过大的、坏掉的"。

周五 DOCS：给一周的工作写"归档文档"

DOCS 日做的是三件事：把本周提交按意图（fix / feat / polish / docs）滚入 CHANGELOG.md 的[Unreleased]段；为本周触碰过的技能补写 examples/ 下的示例 README；再生成 STATUS。

DOCS 有个反直觉的规矩：示例 README 必须对着解包后的真实归档写，而不是照抄 SKILL.md 的散文描述。这个规矩屡建奇功——正是它发现了 4 个 reviewer 宣称的检查数量与实际实现相差 3 倍以上（"约 30 个检查"，实际只有 9 个）这类文档漂移。

周六 RELEASE：轻标签 + 人点击发布

RELEASE 的模式可以概括为：

1. 确认本周有真实提交（空周则跳过，只记一条"安静周"日志）
2. 打轻标签，命名遵循v<年份>.<月份>.W<ISO周号>惯例（如v2026.09.W39），先用git tag -l确认无冲突
3. 在 RELEASES.md 追加对应章节：亮点、按意图分组的提交清单、技能盘点、开放 issue 快照
4. 把 CHANGELOG 的[Unreleased]滚入带日期的版本段
5. 不创建 GitHub Release 对象——发布这个动作留给人类点击

这条"机器打标签、人类点发布"的边界，是整个机制 human-in-the-loop 设计的关键一环。

周日 TRIAGE：给 issue 分类，但不替人类拍板

TRIAGE 的职责是维护 issue 追踪器的健康度：

• 标签审计：为开放 issue 补类型标签（skill-bug、chain-break、description-quality等 7 类）和领域标签，但坚持80% 置信度门槛——低于门槛宁可标记needs-triage交给人，也不硬贴
• 陈旧提醒：对 30 天以上无动态的 issue 发自动评论
• 证据核验：不轻信 issue 描述，直接解包.skill归档、读源码来验证"完成定义"是否真的达成

TRIAGE 有一条铁律：从不关闭 issue。它只做"看起来能关"的标注与证据整理，最终关不关由人决定。

月初 MONTHLY-KPI：给"团队"打绩效

每月第一个运行日会生成月度 KPI 报告（如 docs/monthly/2026-07.md），指标包括：

• Velocity：当月提交数、触碰的技能数、发版数
• Coverage：reviewer 配对率（持续 100%）、示例覆盖率（从 5 月的 7.9% 一路爬到 40%+）
• 领域混合度：用 ASCII 条形图展示各领域提交分布，并执行"连续两月零提交"检查——某领域两个月没被碰就会被点名，成为下周 PLAN 的候选
• 陈旧观察名单：60 天以上未触碰的归档清单
• "这个月是好月份吗？"：一段诚实的定性总结，连"任务调度器漏跑了几次"都会如实记录

护栏：AI 如何不被自己跑偏

无人值守最怕的是失控。这套机制用了几层护栏：

• 编辑白名单：POLISH 只允许拼写/超长/缺失字段三类修改，编辑性重写一律留草稿
• 一运行一提交：每次运行至少产出一个提交，保证"团队"每天都在留痕
• 永不关闭 issue、永不发布 Release：状态变更的最终权限永远在人类手里
• STATUS 生成器入库：scripts/regen_status.py 是 8 月中旬才"转正"的——此前生成器每次运行都在 /tmp 里重写，别名配对规则反复丢失、假报孤立技能。把它变成受版本控制的脚本（且解析docs/PAIRING_ALIASES.md 而非硬编码），才根治了漂移
• 链契约审计：scripts/chain_contract_audit.py 静态比对所有 builder→builder 的标签页契约；scripts/column_contract.py 进一步把断言下沉到列名与数据起始行级别。审计报告见 docs/chain-contract-audit.md

这个"无人团队"实际办成了什么

机制的价值要看战果。从日志时间线看，它已自主完成：

• NUL 字节批量修复：全仓库扫描发现 14 个技能归档携带损坏性尾随 NUL 字节（其中 8 个 Python 成员无法编译），按"验证一条、批量复制"的模式一天修完
• 24 个 reviewer 批量修复：一次打磨日统一修正了 24 个归档的表头探测缺陷，并用 2616 行检查清单的前后对比证明零行为回归
• 列级审计的重大发现：column_contract.py上线当天就发现 TSC→软件分支整条链一直读着错位或空白的列运行——此前标签级审计对这些边全部报 MATCH
• 7 个崩溃级 reviewer 修复：sysml 和 mbse 两个领域的 reviewer 曾对任意输入直接崩溃，修复后领域可用性从 0 到全开
• 连续发版：从v2026.05.W20到v2026.09.W39，周快照从未断档（个别周因调度漏跑合并为双周标签，并如实记录）

人类在哪里：真正的分工点

这套机制不是"去人类"，而是"人类只做决策"。日志里反复出现的"Human:"段落就是待办清单：关闭已达成 DoD 的 issue、在审阅 RELEASES.md 后点击 Publish、裁决分类学问题（比如是否新增polish类型标签）、拍板跨技能的架构决定（比如脚手架表格该由输入驱动还是留白）。

机器负责高频、机械、可验证的工作；人类负责低频、判断、不可逆的动作。这正是"无人值守工程团队"能长期稳定运转的原因。

如何上手体验

想亲自看看这套机制的产物，建议按这个顺序读仓库：

1. docs/AUTONOMOUS_LOG.md —— 从第一周（2026-05-11 的 PLAN）读起，感受节奏如何成型
2. STATUS.md —— 看当前的技能配对与健康度全景
3. CHANGELOG.md 与 RELEASES.md —— 对比两个文档如何被 DOCS/RELEASE 两种模式接力维护
4. docs/weekly/WEEK-2026-W40.md —— 看一份带 DoD 的周计划长什么样

如果你想完整跑起来，可先克隆仓库git clone https://gitcode.com/gh_mirrors/au/automotive-skills-suite，从 skills/ 里挑一个 builder 安装试用，再回头对照它的打磨日志读 docs/skill-polish-log/——你会清楚地看到一条技能从"种子导入"到"被自主团队反复体检"的完整生命周期。

【免费下载链接】automotive-skills-suite100+ installable Claude skills covering Engineering areas such as, ISO 26262 functional safety, ISO/SAE 21434 cybersecurity, ISO 21448 SOTIF, AIAG-VDA quality (APQP/PPAP/FMEA), Automotive SPICE, and continuous improvement tools — every builder paired with a confirmation reviewer.项目地址: https://gitcode.com/gh_mirrors/au/automotive-skills-suite