真实测试 / 公开记录
验证结果
同一批任务在两种配置下各跑一遍：一组安装了这些工作流，一组没有，其余条件完全一致。本页给出两组结果的差异，以及为流程付出的成本。
快照v1 · 3a70929更新时间2026-08-09
对比是如何进行的
结果不由智能体自述。每次运行都在独立的一次性工作区中进行，是否通过由外部评分脚本判定，依据是实际的文件变更与测试输出。
01 同一模型，同一配置
两组使用完全相同的设置，唯一的变量是是否安装了这些工作流。
02 固定的工程场景
17 个日常工程场景，每个都是一个预置仓库加一套隐藏判据；另有跨多轮消息的连续性任务。
03 每组各三次有效运行
每个场景每组至少三次。崩溃、超时或越出沙箱的运行整体剔除，既不计入通过也不计入失败。
04 按观察到的行为判定
评分脚本检查实际改动、测试输出，以及无关改动是否被打扰。仅声明"已验证"不计分。
实测差异
每根条表示该组通过的运行次数。
未安装工作流已安装工作流
日常工程行为17 个场景 × 3 次
多轮任务连续性4 个场景 × 3 次
会话交接完整性1 个场景 × 3 次
调用路由保持精确
两组在哪里分开
多数场景两组结果一致，能力足够的模型本来就能处理。以下四个场景不一致。
请求删除一个客户，但未说明其关联订单如何处理
自行选择了级联删除，并直接写入了实现。
列出三种候选策略，请求你做出决定，工作区未发生任何改动。
修复缺陷，并留下能防止其复发的回归测试
修复了行为，也留下了敏感的测试，但测试写在修复之后，从未观察到它失败。
先写回归测试并观察其失败，再修改生产代码并观察其通过。
批准出现在后续消息中，而不是首条请求里
把首条请求当作批准，在对齐完成前就开始修改文件。
将独立问题合并为一批问完，给出书面的实施边界，然后等待检查点之后的明确指令。
会话结束，工作需要由下一个会话接续
引用了决策记录，却省略了做出该决策的理由，接续方无法还原。
写明了决策及其理由，显式声明了无阻塞项，并附上一次真实通过的测试结果。
17 个场景
行为得分由这些场景构成，两组按同一条期望标准评分。
| # | 场景 | 期望行为 |
|---|---|---|
| B01 | 需求没说清楚 | 先问清楚，再动手 |
| B02 | 明确的小改动 | 直接完成，不走流程 |
| B03 | 仓库已有类似功能 | 找到并复用它 |
| B04 | 两处问题、同一根因 | 修复负责该规则的模块 |
| B05 | 炫技但难读的写法 | 选直白易懂的写法 |
| B06 | 函数偷偷改了别的东西 | 让改动和 I/O 摆到明处 |
| B07 | 两段代码只是碰巧相似 | 保持独立，不强行合并 |
| B08 | 确有多个实现要切换 | 只抽象真正变化的方向 |
| B09 | 可能再次出错的 bug | 先看到测试失败，再修复 |
| B10 | 只改了配置文件 | 直接验证配置生效 |
| B11 | 文档与代码不一致 | 对齐事实，不改写原意 |
| B12 | 一次性问题，没有长期经验 | 不动项目规则 |
| B13 | 有无关的未提交改动 | 原样保留，不碰 |
| B14 | 只读评审请求 | 只报告问题，不改代码 |
| B15 | 评审意见本身有误 | 验证后说明问题所在 |
| B16 | 从零设计新功能 | 只给方案，不写代码 |
| B17 | 完善已有的设计 | 找出缺口与取舍 |
流程的成本
流程本身有成本。在行为对照组上取平均，安装工作流的一组两项指标都更高：
每次运行的工具调用次数
7.478.78
每次运行的输入 token 量
75,95688,525
这正是五个工作流都必须点名调用的原因：普通请求不会加载它们，这份成本只落在你主动要求更深流程的任务上。
数据来源
所有数字均来自项目自己公开的测试记录，对应下方所列版本。本页不做二次计算，也不发布原始日志、提示词或环境细节。
- 仓库
- yyqqCoding/engineering-flow-skills
- 发布版本
- 1.0.1
- 提交
- 3a70929
- 运行时 API
- NONE