前言一句话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 层skill-issues.jsonl诊断 → 评估 → 09 的单假设棘轮工作流层execution-audit.md、复盘、项目管理、报告改编排器 / 门禁 / 阶段定义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收口。计划三档采集当场、每周、季度档位谁来做产出当场你或偶发的 Agent 提示skill-issues.jsonl追加一行工作流则落execution-audit.md/ 复盘每周Skill Review选出该转 eval 的 top 问题顺带扫一眼本周审计里的高优 IMP季度Stocktake见 10 篇看转化率、僵尸问题、该不该淘汰 Skill / 收紧工作流档位真实记录长什么样 比如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 怎样表现——没有真实发生就不要转 evalsource常见三种session_retro人复盘、user_feedback同事/业务反馈、agent_self_reportAgent 自己报。我给我现在的工作流程多了一种来源执行审计报告。它不替代skill-issues.jsonl但经常先暴露「整条链路」的问题——例如门禁脚本被跳过、产物缺文件、Full 模式按 Lite 跑。这类问题往往该进重要的标记而不是硬塞进某一个 Skill 的 eval。关于「Agent 自行上报问题」别神话模型自己很容易写成这样比如任务结束 Agent 自动判断失败并追加 issue 等等。但是真实的现实是——模型经常不知道自己错了。自己问自己怎么可能是错的呢我认为真实的可靠顺序是1.人在复盘时手写 JSONL现在就能做2.校验脚本 / CI / 执行审计失败时辅助记一条半自动3.真有把握再让 Agent 自报锦上添花脚手架复盘里「Issue 自动采集 hook」仍标在 P2。 先做自行的人肉闭环人的判断很重要使用者的真实反馈很重要。 执行审计可以强制诚实记录「跳过 / 降级 / 绕过」但是否升级成 issue / IMP仍要人拍板。工作流审计把「整条链路」也纳入观测当下2026 年 67 月我对工作流ai-frontend-dev-workflow把验收与执行大致拆成两类审计能力职责典型产物4b 交付验收审计acceptance-audit-loopauditor-agent业务 AC 是否真完成acceptance-audit-round-*.md、ac-traceability-matrix.md阶段 5 执行审计execution-audit-loop定义链路 vs 实际落盘有没有偷懒输出目录/execution-audit.md具体反馈如下4a 通过 ≠ 4b 通过。七维技术验证拦不住「AC 假完成」。 4b 通过 ≠ 执行合规。验收过了仍可能跳过编码前闸、没跑 validate、证据用行号糊弄。执行审计的硬规矩只有一句禁止美化。跳过、降级、绕过必须逐条写进报告因为之前遇到过工作流会跳过某一个步骤。而这正是生产监控在工作流层的第一产物。举个例子一条完整的工作流反哺2026-07-21hebei-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-054058IMP改了什么054 / 058workflow-contract写清脚本路径解析与依赖表055craft-validate 脚本不可用时的降级清单056Mini 轻量校验清单模板057Loop L2 证据类型diff/line-ref/command-output这不是「又写了一篇复盘」。这是真实 Mini 任务 → execution-audit-loop 诚实记账 → IMP 排期 → 改 orchestrator 契约与阶段定义 → 下一单再跑时降级路径已写死不必靠当场灵感为此我根据问题对之前的记录问题进行了对照发现对照 special-order-inherit2026-06-22更早的那轮Brownfield 路径不清、Loop 名存实亡、lessons 格式不对——同样是复盘 → IMP-001007 → 编排器硬化。为此后来才在工作流中加档位才有 Lite / Mini 档位、编码前后硬闸、4b 验收审计。说明一下上述的IMP 这些是我跑工作流之后出的审计报告里面会见优化意见与反馈都写了的。所以我们自己搭建的工作流与审计反馈机制的重要性就出来了。工作流不是一次设计出来的是一单单真实需求磨出来的。审计产出怎么分流审计发现该进哪里不该怎么做某 Skill 契约缺口如 path 双轨该 Skill 的skill-issues.jsonl→ eval只改提示词里「下次注意」编排跳过 / 门禁绕过 / 产物缺失WORKFLOW_IMPROVEMENT_BACKLOG→ 改阶段卡 / validate把流程问题塞进单个 Skill 的 eval一次性措辞偏好LEARNINGS.md或项目复盘扩测试集案例字段名污染通用契约先抽象再改 L1L3见下节把birthDateText写进 output-contractSkill Review 周会建议加一项本周有没有新的 execution-audit / 复盘高优 IMP 认领了吗反哺时内容分层设计与抽象真实案例最容易犯的错比如把单案例字段名、路由名、真实业务写进通用契约导致 Agent 照抄、eval 过拟合。脚手架为此补了skill-engineering/docs/content-layering-guide.md层写什么禁止L1 契约章节、触发条件、技能术语具体字段 / 业务路由L2 模板[占位符]真实业务举例当规则L3 eval产品口吻 prompt 契约级 expected案例专有 CamelCaseL4 案例examples / retro / skill-issues—这里可以很具体铁律复盘只能向上抽象进 L1L3不能把 L4 原文向下复制进契约。转 eval 前做 30 秒「案例名替换测试」比如把birth-age换成foo-bar规则还成立吗不成立就说明还绑死在单案例上。issue-to-eval.md已写死不得把案例字段原样写入expectedprompt用「列表页/确认页」不用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几条 high2.只讨论 top 3转 eval / 先改描述 / 忽略3.扫一眼回归关键 Skill 的 high 是否还绿evolution_report有没有难看趋势4.工作流侧本周 audit / 复盘里的 P0P1 IMP认领 02 条5.下周只认领 12 条转化或修复Skill 与工作流合计也别贪多进行排序或靠个人直觉严重度 × 重复次数 × 还没转成 eval。已经converted_to_eval: true的别反复开会复读。 已fixed的可用mark_issue_resolved.py批量回写别靠手改 JSONL。借助你工程化设计的理念一个命令行跑一下就可以了。什么时候转 Eval什么时候先别转我们可以对照issue-to-eval.md情况动作high open优先转同类 symptom 反复出现优先转缺少 expected先补期望再谈转换一次性措辞偏好写进LEARNINGS.md不进 eval单次偶发、像用户误操作先观察别急着扩测试集编排/门禁类流程洞进 IMP必要时再给 orchestrator 加 trajectory / validate 回归失败优先于成功。不能改着改着把之前的改化了基本要求锁住核心功能不能也别退步了。不能改问题优化迭代把核心功能优化迭代没了不能把之前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 / 时长 / 调用次数这些我们需要关心吗其实还是值得看我们不能本末倒置。 这些的真实反馈其实也是非常重要的比如信号可能意味着建议单次 token 突然暴涨Skill 太长 / 死循环读文件 / 喂了 full PRD 而非 dev-slim记一条 medium issue检查输入形态经常超时Workflow 卡住或工具乱调同上对照 execution-audit 看是否重试/回退异常一个月 0 调用僵尸候选交给 10 篇的 StocktakeMini/Lite 用得越来越多Full 契约过重或文档噪声大可能是档位设计成功也可能是人在绕开硬闸——看审计有日志就解析没有日志的我们完全可以凭使用感受在 Review 里报一声也行。不要为了「看起来已经有监控了」就先上一套复杂的观测流程。有 issue 文件、有周会、有执行审计L6 的主闭环就已经成立。两条完整反哺例子例 A · Skill 层path 双轨 → eval-007还是那次特殊单任务1.session_retro 记下 path 双轨high2.triage 把它顶到前面3.锚定到 eval-007craftloop 串联4.改validate-output.sh --chain5.grade_evals.pyPASS → KEEP见 096.issue 标fixed这不是「审计监控系统很棒」这是现场问题进了测试集以后再改 Skill这样的错误就不会再出现第二次。能力得到进一步提升。例 B · 工作流层执行审计 → IMP-054058之前的问卷需求 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侧又补齐了几块以下就是最近新增的几条线能力用途run-evolution-cycle.shtriage / convert / baseline / verify / report / mark-resolved 一键阶段mark_issue_resolved.py批量回写 issue 状态少手改 JSONLevolution_report.py看 trendsReview 时扫一眼content-layering-guide.md防案例污染契约issue-to-eval.md强化fixture_expected、grader 选择、禁止事项更硬CI Eval 门禁 graders转成 regression 之后PR 能真拦住退化工作流侧对应补齐的是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大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。