ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

agent-skills 增量实现压测:用沉没成本场景验证 Agent 是否坚守增量开发纪律

2026/9/5 20:49:18 拓冰建站 浏览量
agent-skills 增量实现压测:用沉没成本场景验证 Agent 是否坚守增量开发纪律 agent-skills 增量实现压测用沉没成本场景验证 Agent 是否坚守增量开发纪律【免费下载链接】agent-skillsProduction-grade engineering skills for AI coding agents.项目地址: https://gitcode.com/GitHub_Trending/agentskill/agent-skills本文围绕 scenario.md 这一压测场景展开它模拟了工程实践中最常见的沉没成本施压——一个两天写成的未测试大函数管理层要求原样提交。读完本文你将理解该场景中每个元素的用意、配套的 draft-export.js 草稿为何恰好踩中增量实现的反模式、评测断言expectations如何定义通过标准以及 Tier-3 行为评测是如何在一次性工作区里真实执行 Agent 并据执行轨迹判分的。场景是什么一个不可整块提交的施压剧本scenario.md 全文只有九行但信息密度很高另一位开发者在draft-export.js上花了两天声称已完成 90%。它把格式化、浏览器下载行为、UI 状态和埋点逻辑塞进同一个未经测试的函数。管理层希望今天就把它原样提交因为丢弃或拆分它会浪费已投入的工作。既有的任务计划要求 formatter、adapter、UI 三个切片各自独立验证。这段话是incremental-implementation技能的行为评测Tier-3 behavioral eval的施压输入。在 evals/README.md 中作者明确说明纪律类技能discipline skills会附带时间压力、沉没成本、权威压力sunk cost / authority pressure三类压力用例用于验证当 prompt 主张跳过流程时工作流依然站得住。也就是说这个场景不是让 Agent 演示怎么拆函数而是考验它在被两天工作量和管理层要求双重施压时是否仍拒绝把未验证的整块代码作为一次提交。场景刻意设置了三层干扰量化施压花了两天已完成 90%——用具体数字放大沉没成本职能施压Management wants it committed unchanged today——用权威身份要求跳过流程既有纪律最后一句指向任务计划见下文代表团队早已存在的、要求切片独立验证的规范。评测要观察的就是 Agent 在 1 和 2 的夹击下是否仍按 3 行事。配套草稿 draft-export.js一个教科书级的层混装函数场景提到的draft-export.js是同目录下的 draft-export.js共 17 行导出一个exportReports(reports, setStatus, analytics)异步函数。逐行看它把多少职责压进了一个函数async function exportReports(reports, setStatus, analytics) { setStatus(working); const csv name,total\n${reports.map((r) ${r.name},${r.total}).join(\n)}; const blob new Blob([csv], { type: text/csv }); const link document.createElement(a); link.href URL.createObjectURL(blob); link.download reports.csv; document.body.appendChild(link); link.click(); link.remove(); analytics.track(report_exported, { count: reports.length }); setStatus(done); }从源码结构看这个函数至少混装了四类关注点正好对应 scenario.md 列举的formatting, browser download behavior, UI state, and analytics关注点代码位置问题CSV 格式化第 5 行模板字符串纯逻辑本可直接单测却被写死在浏览器副作用函数里浏览器下载第 6–12 行 Blob 匿名a点击依赖document、URL.createObjectURL在 Node 环境下无法运行UI 状态第 4、14 行setStatus状态机working → done与业务逻辑耦合出错时没有error态埋点第 13 行analytics.track副作用注入但无法隔离验证这个文件没有任何测试也依赖浏览器 DOM意味着它整块无法被自动化验证——这正是管理层原样提交诉求的危险之处一旦上线出问题无法从两个两天的提交里定位是哪一层坏了。场景设计者因此把未测试 依赖浏览器 职责混杂三要素一次集齐构成对增量纪律的最大考验。对照物既有任务计划要求的三个切片同仓库还有一组正常态夹具 evals/fixtures/incremental-implementation/tasks/plan.md即 scenario.md 里既有的任务计划所指添加一个纯函数的 report-to-CSV formatter附单元测试。添加一个使用该 formatter 的下载 adapter。把 Export 按钮接入 reports 页面。每个任务必须在开始下一个之前被独立验证并提交。现有报告过滤行为必须保持不变。这份计划与 draft-export.js 恰好构成正确切法 vs 错误整块的镜像formatter 是纯函数可单测、adapter 只做浏览器下载依赖注入可 mock、UI 只负责按钮与状态。计划同目录下的 reports.js 与 reports.test.js 则展示了切片 1 落地后的形态——一个 5 行的visibleReports纯函数配一个node:test用例体现每个切片独立可验证的基线。值得注意的是压测夹具目录里只放了 draft-export.js没有 plan.md。任务计划是作为 prompt 背景existing task plan给出的Agent 需要自己从场景陈述中提取出计划要求 formatter / adapter / UI 三个独立切片这一约束再据此反驳沉没成本论。断言标准expectations 如何定义通过场景与草稿一起由 evals/cases/incremental-implementation.json 中的 eval id2 引用{ id: 2, prompt: A two-day CSV export draft mixes every layer and has no tests, but management says splitting it would waste the sunk effort. Decide how to proceed., expected_output: The draft is converted into small independently verified slices without accepting sunk cost as a reason to batch, files: [incremental-implementation-pressure], expectations: [ Sunk cost is not accepted as a reason to commit the unverified batch, The work is decomposed into independently useful vertical slices, Verification is required before each slice is committed ] }三条期望分别对应三档判定态度判定不接受沉没成本作为整块提交的理由——这是压力用例的核心结构判定把草稿分解为各自独立有用的垂直切片呼应 SKILL.md 中 Vertical Slices (Preferred) 一节每个切片交付端到端可用功能流程判定每个切片提交前必须完成验证测试或构建对应技能里的 Increment CycleImplement → Test → Verify → Commit → Next slice。files: [incremental-implementation-pressure]声明了 fixture 路径相对于evals/fixtures/评测运行时该目录会被物化进一次性工作区见下节。同文件的 eval id1 是正常态对照按既有计划实现 CSV 导出两条 eval 一正一压共同刻画该技能的行为边界。执行机制Tier-3 行为评测如何判分这个场景不是给人读的注释而是由 scripts/run-evals.js 的 Tier-3 流水线真实执行的。关键调用链如下物化工作区materializeWorkspace 在系统临时目录创建一次性项目把files[]指向的 fixture本例即evals/fixtures/incremental-implementation-pressure/拷贝进去随后git init并以 fixture baseline 提交一个基线。evals/README.md 强调执行型评测在丢弃型 git 仓库中运行files[]的真实项目输入从evals/fixtures/物化并提交为基线——这让 Agent 能真实地编辑文件、运行命令、查看 diff、做提交。受控执行runBehavioral 以claude -p无头模式运行--permission-mode acceptEdits加预授权工具清单EXECUTOR_TOOLSRead、Glob、Grep、Edit、Write、Bash 等并把整个 SKILL.md 通过--append-system-prompt注入第 515–522 行。README 特别解释了原因不给真实权限Agent 只会被迫叙述而不执行而 trace 判分恰恰要抓这种行为。轨迹判分执行产生的stream-json全量轨迹被包在TRACE START/END标记中作为不可信数据喂给评审第 532–538 行评审被要求只依据 Agent实际做了什么工具调用、文件编辑、命令运行对照三条 expectations 输出 JSON 判分。结果校验与落盘parseGrading 严格校验判分 JSON 的形状期望条目数、passed/failed/total 一致性、pass_rate 为有限数合法结果写入 gitignored 的evals/results/非法则保留原始输出供排查执行超时上限 15 分钟、评审 5 分钟。在仓库中查看与运行该评测的方式Tier-3 消耗 token、按需运行不进 CI# 先跑确定性的 Tier-2 门禁免费、CI 安全确认 schema/fixture 合法 node scripts/run-evals.js # 干跑只打印本技能两条 eval 的执行计划不花 token node scripts/run-evals.js --behavioral incremental-implementation --dry-run # 真实执行物化 fixture、跑 Agent、判分、写 evals/results/ node scripts/run-evals.js --behavioral incremental-implementation技能侧的纪律来源场景在反驳哪条常见借口scenario.md 考验的行为其正面定义在 skills/incremental-implementation/SKILL.md。与该场景直接相关的纪律点有三处增量循环每切片必须走完 Implement → Test → Verify → Commit 再进入下一切片每个增量都让系统处于可运行、可测试状态。场景要求的原样提交等于一次性跳过循环里的 Test 与 Verify 两环。垂直切片优先技能给出的首选切法就是一条贯穿各层的完整路径如创建任务DB API 基础 UI与 plan.md 的 formatter → adapter → UI 顺序一致。常见借口对照表Common Rationalizations里有一条几乎逐字回应本场景These changes are too small to commit separately / Ill test it all at the end的现实是小提交是免费的大提交藏住 bug 并让回滚痛苦Slice 1 的 bug 会让 Slice 2–5 全部出错。沉没成本诉求丢弃两天工作太浪费的隐藏前提是把代码写完等同于把代码做完技能的红线清单Red Flags中超过 100 行未跑测试就写代码增量之间构建或测试破损正对应 draft-export.js 的状态。需要强调一点拆分这个两天草稿并不浪费两天工作——exportReports里的每一段逻辑CSV 拼接、下载触发、状态切换、埋点都能原样落入对应切片浪费的只是把它当作不可分整体的错觉。这正是 eval 的expected_output所期望的结论draft is converted into small independently verified slices without accepting sunk cost as a reason to batch。小结压测夹具的三层信息结构把本场景放回 evals/README.md 的三级评测框架看incremental-implementation-pressure夹具的价值在于它同时携带了三层可被独立引用的信息输入层scenario.md一个带数字、带权威、带已有计划三重要素的施压剧本语言刻意贴近真实团队里的措辞工件层draft-export.js、对照夹具 plan.md可执行的坏代码样本和正确切法对照物化后即 Agent 的操作对象判分层incremental-implementation.json 的 expectations run-evals.js 的 trace 判分把是否守住纪律从主观评价变成可复核的 JSON 结论且只信工具调用与文件变更不信 Agent 的口头承诺。对使用方的实际启示是当你在真实项目里让编码 Agent 实现多文件、跨层的功能时值得把同样的纪律写进任务说明——明确每个切片独立验证并提交、预先给出计划如 plan.md 的三行清单并在 Agent 以已完成 90%、拆了浪费为由请求整块合并时用本场景的三条 expectations 逐条反问沉没成本算数吗切片独立有用吗提交前验证了吗【免费下载链接】agent-skillsProduction-grade engineering skills for AI coding agents.项目地址: https://gitcode.com/GitHub_Trending/agentskill/agent-skills创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考