前言

一句话：Skill 与工作流的下一版，不在灵感里，在真实任务翻车后的那一行记录里。

开场：问题记了“症状”，却没法“诊断”

比如我跑pm-md-to-openspec-pipeline时，真实业务反馈连续报版本不一致。

第一反应常常是：是不是模型没读到或者没有读全，是AI幻觉？

后来才发现：输出的反馈中没把「源文档必须和项目版本对齐」写死。

更糟的是，issue 只写了「又不一致」，没写预期结果。

每周 Review 打开skill-issues.jsonl，只能看到一堆抱怨，感觉不是自身Skill的问题，也就找不出问题应该先修哪条？

我们之前讲的，比如 09 篇解决「怎么改才不翻车」。 10 篇解决「谁来改、改完怎么发」。 11 篇解决更上游的问题：改什么，从哪来？

没有现场问题，没有真实项目实践的真实反馈，那么所谓的自进化就是在空转假设。

没有可处理的现场问题，都是假设的话，你这个Skill 本身可能就是一个伪命题，伪功能，所以对Skill 的 Review 也只是开个短会而已，并没有改变之前的本质问题（未发现的问题）。

那么接下来要讲什么 ？

本篇我这边不是讲应该是一个怎样的具体的方法论。

核心的简单的主要内容就只有一条：

真实需求场景 → 用 Skill / 工作流跑完（或跑翻） → 把偏差写成可处理记录 → 每周 triage / Review → 够格的进 regression / IMP → 改契约或编排，再回到现场验证

根据这个核心，我现在的仓库里已经长出两层：

Skill 工程化脚手架负责把「一行异常，反馈，评估等等」变成可回归的测试；

比如ai-frontend-dev-workflow的我新增了使用工作流之后都默认进行对使用工作流的过程中进行审计。

这个审计能力负责把「整条链路偷懒了哪里」变成可排期的流程改进。

最终Skill 和 工作流，两边最终都回到同一句话：真实应用现场反哺使用设计存在的问题与缺陷。

先说「生产监控」

这里说的监控，第一产物不是简单的工作实践。

第一产物是：某份可处理的记录里，多了一行带真实发生的偏差。

比如 token、时长、调用次数有用的，但它们是辅助，非主要的。

真正的主线永远是：

真实任务翻车 / 差点翻车 → 写成 issue 或审计偏差（必须有 expected / 可行动建议） → 每周 triage → 够格的转成 regression eval，或进工作流 IMP → 回到 09 的单假设 + 棘轮，或改编排契约后再跑现场

脚手架已经写好 Skill 侧规范：skill-engineering/docs/issue-to-eval.md。

工作流侧则是：

靠阶段5的执行审计 +WORKFLOW_IMPROVEMENT_BACKLOG.md收口。

计划三档采集：当场、每周、季度

真实记录长什么样 ？

比如Skills 中的frontend-dev-prompt-craft技能里有过这样的真实记录：

{"date":"2026-06-22","skill":"frontend-dev-prompt-craft","task_type":"API","symptom":"PRD 接口 path 与项目 request path 不一致，提示词易只写其一","expected":"output-contract 要求 PRD path 与项目 path 双轨记录，并标注 Mock/联调","severity":"high","source":"session_retro","converted_to_eval":true,"eval_id":"frontend-dev-prompt-craft-007","status":"fixed"}

注意两个字段：

•symptom：现场看到什么

•expected：你希望 Skill 怎样表现——没有真实发生，就不要转 eval

source常见三种：session_retro（人复盘）、user_feedback（同事/业务反馈）、agent_self_report（Agent 自己报）。

我给我现在的工作流程多了一种来源：执行审计报告。

它不替代skill-issues.jsonl，但经常先暴露「整条链路」的问题——例如门禁脚本被跳过、产物缺文件、Full 模式按 Lite 跑。

这类问题往往该进重要的标记，而不是硬塞进某一个 Skill 的 eval。

关于「Agent 自行上报问题」：别神话

模型自己很容易写成这样：比如任务结束 Agent 自动判断失败并追加 issue 等等。

但是真实的现实是——模型经常不知道自己错了。

自己问自己，怎么可能是错的呢？

我认为真实的可靠顺序是：

1.人在复盘时手写 JSONL（现在就能做）

2.校验脚本 / CI / 执行审计失败时辅助记一条（半自动）

3.真有把握再让 Agent 自报（锦上添花）

脚手架复盘里，「Issue 自动采集 hook」仍标在 P2。 先做自行的人肉闭环，人的判断很重要，使用者的真实反馈很重要。 执行审计可以强制诚实记录「跳过 / 降级 / 绕过」，但是否升级成 issue / IMP，仍要人拍板。

工作流审计：把「整条链路」也纳入观测

当下2026 年 6～7 月，我对工作流ai-frontend-dev-workflow把验收与执行大致拆成两类审计：

4a 通过 ≠ 4b 通过。七维技术验证拦不住「AC 假完成」。 4b 通过 ≠ 执行合规。验收过了，仍可能跳过编码前闸、没跑 validate、证据用行号糊弄。

执行审计的硬规矩只有一句：禁止美化。

跳过、降级、绕过必须逐条写进报告，因为之前遇到过工作流会跳过某一个步骤。

而这正是生产监控在工作流层的第一产物。

举个例子：一条完整的工作流反哺

2026-07-21，hebei-survey-questionnaire用 Mini 模式跑完。

业务做出来了，但execution-audit.md写得很不留情：

•craft-validate-log.txt缺失（validate-output.sh没跑）

•check-pre-coding-gate-mini.sh未实际运行（手动对照替代）

•validate-workflow-artifacts.sh未实际运行

•Loop L2 证据是文件行号，不是git diff

产物完整率 8/11。审计末尾直接给出优化建议。

随后这些建议进了WORKFLOW_IMPROVEMENT_BACKLOG，并在同一天落成 IMP-054～058：

这不是「又写了一篇复盘」。这是：

真实 Mini 任务 → execution-audit-loop 诚实记账 → IMP 排期 → 改 orchestrator 契约与阶段定义 → 下一单再跑时，降级路径已写死，不必靠当场灵感

为此我根据问题，对之前的记录问题进行了对照，发现对照 special-order-inherit（2026-06-22）更早的那轮：Brownfield 路径不清、Loop 名存实亡、lessons 格式不对——同样是复盘 → IMP-001～007 → 编排器硬化。

为此后来才在工作流中加档位，才有 Lite / Mini 档位、编码前后硬闸、4b 验收审计。

说明一下，上述的IMP 这些是我跑工作流之后出的审计报告，里面会见优化意见与反馈都写了的。

所以我们自己搭建的工作流与审计，反馈机制的重要性就出来了。

工作流不是一次设计出来的，是一单单真实需求磨出来的。

审计产出怎么分流

Skill Review 周会建议加一项：本周有没有新的 execution-audit / 复盘？高优 IMP 认领了吗？

反哺时内容分层设计与抽象

真实案例最容易犯的错：比如把单案例字段名、路由名、真实业务写进通用契约，导致 Agent 照抄、eval 过拟合。

脚手架为此补了skill-engineering/docs/content-layering-guide.md：

铁律：复盘只能向上抽象进 L1～L3，不能把 L4 原文向下复制进契约。

转 eval 前做 30 秒「案例名替换测试」：比如把birth-age换成foo-bar，规则还成立吗？不成立就说明还绑死在单案例上。

issue-to-eval.md已写死：不得把案例字段原样写入expected；

prompt用「列表页/确认页」，不用index/detail。

所以我们跑的是真实的案例，反馈的也是真实的案例数据，但是我们在完善Skill 和工作流的过程中，不可能写死某个案例或者就因为这个真实案例实践出现了问题就要修复？这个不科学与严谨的。

为此我们要对业务进行分层设计与抽象，Skill 和工作流是通用的能力，不是专门为某一个特有业务功能而设计的。

这需要我们人为来判断来识别，所以只有你一首搭建起来的框架与功能，你才可以知晓如何甄别与选择。如果全是AI搭建设计的，你确定你的改动不会为后续埋雷吗？往往使用AI失控是一件很可怕的事情的。

每周 Review：把队列变成决定

不需要很费时间，时间不用很长。执行打开日常想审计结果反馈信息即可：

# 单 Skill 也可走编排脚本 ./plugins/frontend-team-toolkit/skill-engineering/bin/run-evolution-cycle.sh \ --skill frontend-dev-prompt-craft --phase triage # 或直接扫一批 python3 plugins/frontend-team-toolkit/skill-engineering/scripts/triage_issues.py \ --skills-base plugins/frontend-team-toolkit/skills \ --status open

议程建议：

1.本周新增 issue：几条 high？

2.只讨论 top 3：转 eval / 先改描述 / 忽略

3.扫一眼回归：关键 Skill 的 high 是否还绿；evolution_report有没有难看趋势

4.工作流侧：本周 audit / 复盘里的 P0～P1 IMP，认领 0～2 条

5.下周只认领 1～2 条转化或修复（Skill 与工作流合计也别贪多）

进行排序或靠个人直觉：严重度 × 重复次数 × 还没转成 eval。

已经converted_to_eval: true的，别反复开会复读。 已fixed的可用mark_issue_resolved.py批量回写，别靠手改 JSONL。

借助你工程化设计的理念，一个命令行跑一下就可以了。

什么时候转 Eval，什么时候先别转

我们可以对照issue-to-eval.md：

失败优先于成功。

不能改着改着，把之前的改化了，基本要求锁住核心功能不能也别退步了。

不能改问题优化迭代，把核心功能优化迭代没了，不能把之前90分变成了80分。

转 eval 可以用脚本：

python3 plugins/frontend-team-toolkit/skill-engineering/scripts/convert_issue_to_eval.py \ --skill frontend-dev-prompt-craft \ --skills-base plugins/frontend-team-toolkit/skills \ --issue-line 10 \ --dry-run

确认映射无误再--apply。

转完记得补 fixture——否则 09 篇说的确定性回归还是跑不起来。

一条龙也可以：

./plugins/frontend-team-toolkit/skill-engineering/bin/run-evolution-cycle.sh \ --skill frontend-dev-prompt-craft --phase convert --issue-line 10 ./plugins/frontend-team-toolkit/skill-engineering/bin/run-evolution-cycle.sh \ --skill frontend-dev-prompt-craft --phase verify --apply-results

以上这些是我让AI 设计的命令行脚本。

但是在实际上的操作，就是我直接跟AI对话就可以了，我不需要去关心这些脚本是什么？我只需要明确核验我需要优化迭代的内容是什么就可以了。

辅线：token / 时长 / 调用次数

这些我们需要关心吗？其实还是值得看，我们不能本末倒置。 这些的真实反馈其实也是非常重要的，比如：

有日志就解析；没有日志的我们完全可以凭使用感受在 Review 里报一声也行。

不要为了「看起来已经有监控了」就先上一套复杂的观测流程。

有 issue 文件、有周会、有执行审计，L6 的主闭环就已经成立。

两条完整反哺例子

例 A · Skill 层：path 双轨 → eval-007

还是那次特殊单任务：

1.session_retro 记下 path 双轨（high）

2.triage 把它顶到前面

3.锚定到 eval-007（craft+loop 串联）

4.改validate-output.sh --chain

5.grade_evals.pyPASS → KEEP（见 09）

6.issue 标fixed

这不是「审计监控系统很棒」，这是：现场问题进了测试集，以后再改 Skill，这样的错误就不会再出现第二次。能力得到进一步提升。

例 B · 工作流层：执行审计 → IMP-054～058

之前的问卷需求 Mini 跑通业务后，审计暴露脚本路径与降级空洞 → 当天改workflow-contract/mini-run-mode/ 校验清单模板。

下一单再遇到「脚本不可用」，Agent 有写死的降级路径，而不是再次静默跳过。

这和 Skill 侧的 fixture 回归是同一逻辑：把现场例外变成可重复的规则。

中间还可以插一档：prd-three-layer-template技能（prd 规范模版）在真实转换里发现「full 版 token 噪声 / large 源超长」，issue 与样例反哺出*.dev-slim.md、多文件包与 validate 规则——再被工作流 README 定为主输入格式。

这些问题让我自己搭建的 Skill 变好了，工作流也跟着变好了。

迭代优化出真知

在真实项目多次反馈与版本迭代过程中，我又有了新的想法与理念，实践中产出了新的理念与思路，于是我就对我们工程化模版文件skill-engineering侧又补齐了几块，以下就是最近新增的几条线：

工作流侧对应补齐的是：execution-audit-loop、4b 验收审计、IMP backlog、以及从审计直接长出来的降级与证据类型约定。

工具变多了，原则没变：观测 → 结构化 → 改一处 → 再考一次。但能力是越来越好，也越强大了。

最后总结

简单来讲，我主要就讲几件事情，大家只需要记住如下四件事：

1.生产监控的第一产物是可处理记录（Skill 侧是skill-issues.jsonl，工作流侧是诚实的执行审计），不是仪表盘；没有 expected / 可行动建议的抱怨，转不成 eval，也排不成 IMP。

2.异常反馈优先：反复失败做成数据分析；流程洞做成 IMP；偶发先观察；Agent 自报是加分项，人复盘与审计才是主路径。

3.反哺要抽象：案例细节留在 L4，契约与 eval 只收契约级规则；否则测试集越厚，Skill 越窄。

4.每周 Review 只做决定：triage → 转不转 eval / 认不认领 IMP → 回到 09 的单假设与棘轮，或改编排后再跑现场。

最后我想说的就是，实践是检验的唯一标准。

学习资源推荐

如果你想更深入地学习大模型，以下是一些非常有价值的学习资源，这些资源将帮助你从不同角度学习大模型，提升你的实践能力。

一、全套AGI大模型学习路线

AI大模型时代的学习之旅：从基础到前沿，掌握人工智能的核心技能！​

因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

二、640套AI大模型报告合集

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示

​因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

三、AI大模型经典PDF籍

随着人工智能技术的飞速发展，AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型，如GPT-3、BERT、XLNet等，以其强大的语言理解和生成能力，正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。

因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

四、AI大模型商业化落地方案

作为普通人，入局大模型时代需要持续学习和实践，不断提高自己的技能和认知水平，同时也需要有责任感和伦理意识，为人工智能的健康发展贡献力量。