第 25 卷

1. 分析数据质量问题
2. 编写清洗脚本 `clean.py`
3. 编写可视化脚本 `visualize.py`（生成 `chart.png`）
4. 运行两个脚本验证

dsh 怎么做的（工具链）

<!-- [style] 工具链示意代码块统一补 text 语言标签 -->

read(sales_data.json) → write(clean.py) → bash(python clean.py) → write(visualize.py) → bash(python visualize.py) → read(输出) → 总结

产出与验证

产物结果

clean.py✅ 运行成功，52 → 35 行，所有问题归零

visualize.py + chart.png✅ 生成有效 PNG（1950×825）

清洗策略缺失金额中位数填充、异常值删除、去重、类型统一


输出要点（体现判断力，不是机械执行）

> - 中位数填充会在直方图产生 510 尖峰——插补的固有副作用，建议说明 > - 若 99999 是真实大额订单，建议改用 IQR/分位数法而非一刀切删除

> - 清洗后统计：N=35，均值 489.43，中位数 510，标准差 181.73 **dsh 不仅执行了任务，还主动说明了数据处理的权衡与假设**——这是 agent 工程层"会思

考"的证据。

案例 B：5-bug 代码修复 + 49 个测试（94 秒）

任务

给 dsh 一个**故意埋了 5 个 bug** 的 Python 计算器模块，要求：找到所有 bug → 修复 → 编写完整单元测试 → 运行验证。

埋的 bug

1. `add` 误写为 `a - b`
2. `divide` 除零静默返回 0（应抛异常）
3. `factorial` 负数静默返回 -1（应抛异常）
4. `factorial` 的 `range(1, n)` 漏乘 n

1. `format_money` 未格式化为两位小数

dsh 的修复 + 测试（验证：49 passed）

完整测试见 [case-test-calculator.py](./assets/case-test-calculator.py)——49 个用例覆盖：

函数覆盖

ZeroDivisionError

factorial0!/1! 边界/已知值/负数必须抛 ValueError

formatmoney补零/四舍五入/0.1+0.2 舍入/负数

python -m pytest test_calculator.py -v# 49 passed in 0.37s

观察：dsh 的表现

• **完整闭环**：读 → 修 → 写测试 → 跑测试 → 总结，无人工干预
• **修复质量**：5 个 bug 全修复且补了 docstring 说明
• **测试设计**：覆盖边界（除零/负数/精度），不是"能跑就行"

案例总结：dsh 在复杂任务上的画像

维度表现

多步工具链✅ 自动编排（读→写→跑→验证 →总结）

复杂任务耗时94s-186s（同模型同网关，比 benchmark 简单任务慢但可控）

产出质量✅ 有判断力（数据权衡说明、测试边界设计）

产物追踪✅ 生成文件可在对话末尾直接打开

失败恢复本案例未触发；生产建议配 guard 超时 + 人工审批

**给新手的启示**：dsh 处理"多文件、多步骤、要验证"的任务很顺手——这也是它作为 Agent 运行时的主要价值场景。复杂任务建议：提示词把**验收标准写清楚**（如"运行验

证"），dsh 会照着闭环。

---

动手练习（检验你是否真懂了）

1. **理解题**：不看原文，说出案例 A（数据质量分析）的工具链顺序（read → write

• bash → ...），以及最终产出是什么

> 自查：参考本章"案例 A"的"dsh 怎么做的"段落

1. **理解题**：案例 B（5-bug 修复）里，dsh 补的 49 个测试覆盖了哪些边界情况？

为什么"除零必须抛 ZeroDivisionError"是一个重要的测试点？

> 自查：参考本章"案例 B"的测试覆盖表格

1. **动手题**：设计一个类似的"数据质量分析"任务：准备一份含脏数据的 CSV（至少

3 种问题：缺失值、类型错误、异常值），写提示词让 dsh 分析 + 清洗 + 可视化，记录耗时和产出

> 自查：参考本章案例 A 的任务描述 + 产出验证表格

1. **动手题**：设计一个类似的"bug 修复"任务：写一个故意含 3 个 bug 的 Python 模

块（如字符串处理、日期计算），让 dsh 找 bug → 修复 → 写测试 → 运行验证，记录耗时和测试通过率

> 自查：参考本章案例 B 的任务描述 + "dsh 的表现"观察段落

1. **思考题**：案例 A 里 dsh "主动说明了数据处理的权衡与假设"（如中位数填充的尖

峰副作用）。这个行为对"agent 工程层"的设计有什么启示？模型只是执行命令，还是真的有"判断力"？

> 自查：参考本章案例 A 的"输出要点"段落 + 案例总结表格

1. **思考题**：本章结语说"提示词把验收标准写清楚，dsh 会照着闭环"。如果案例 A

的提示词只说"处理一下这个数据"而不说"运行验证"，dsh 的表现会有什么不同？

> 自查：参考本章"给新手的启示"段落 + 案例 A 的工具链（含 bash 运行验证）

常见疑问 FAQ

**Q1：案例 A 耗时 186 秒，案例 B 耗时 94 秒，这个速度算快还是慢？**

取决于任务复杂度和模型档位。同模型同网关下，比 benchmark 简单任务慢但可控。关键不是绝对速度，而是"多步工具链自动编排 + 产出质量 + 无人工干预"的综合价值。如果想提速，

参考第 6 章的推理档位策略 + 提速插件示例。

**Q2：案例里的"合成数据"是什么意思？为什么不用真实数据？**