https://blog.sanbei101.cn/ai-book/04-iter-and-test/Recent content in 第四章 迭代与测试 on Sanbei的博客Hugozh-CNSat, 26 Sep 2026 15:29:13 +0800https://blog.sanbei101.cn/ai-book/04-iter-and-test/01-orval/Mon, 01 Jan 0001 00:00:00 +0000https://blog.sanbei101.cn/ai-book/04-iter-and-test/01-orval/<p>在前后端协同开发中,接口定义的高频变动通常是效率瓶颈:</p> <ul> <li>业务管理后台中,每个数据实体均涉及标准 CRUD 接口的定义与前端调用层封装;</li> <li>表单模型调整字段名称或增删属性,前端需同步更新对应的数据模型与请求方法。</li> </ul> <p>在缺乏确定性契约的场景下,依赖人工同步或通过自然语言让模型阅读 Git Diff 修改代码,容易消耗额外上下文,且极易出现类型遗漏或字段漂移。</p>https://blog.sanbei101.cn/ai-book/04-iter-and-test/02-pprof/Mon, 01 Jan 0001 00:00:00 +0000https://blog.sanbei101.cn/ai-book/04-iter-and-test/02-pprof/<p>在人机协同开发中,许多人习惯把成百上千行的业务代码直接抛给模型,提出类似&quot;帮我看看这段代码性能有没有问题&quot;、&ldquo;优化系统性能&quot;的请求。</p>https://blog.sanbei101.cn/ai-book/04-iter-and-test/03-test/Mon, 01 Jan 0001 00:00:00 +0000https://blog.sanbei101.cn/ai-book/04-iter-and-test/03-test/<p>在人机协同开发中,最需要警惕的汇报之一是:</p> <blockquote> <p><em>&ldquo;代码已完成,测试已通过。&rdquo;</em></p> </blockquote> <p>审查测试代码时,常会发现明显的工程隐患:</p> <ul> <li>当 <code>Service</code> 依赖数据库时,模型生成了一个返回 <code>nil</code> 的 <code>FakeRepository</code>,使每个调用都直接跳过底层读写;</li> <li>测试仅断言无错误返回,未验证数据是否真实持久化或事务是否正确回滚;</li> <li>并发逻辑中硬编码 <code>time.Sleep(100 * time.Millisecond)</code>,在本地容易通过,而在持续集成流水线中因调度延迟产生随机 Flaky 报错。</li> </ul> <p>这类测试的风险在于提供虚假的通过信号:模型基于自创的 Mock 验证了自身生成的逻辑,而真实的 SQL 语法、约束与并发竞争从未被运行时检验。</p>https://blog.sanbei101.cn/ai-book/04-iter-and-test/04-log/Mon, 01 Jan 0001 00:00:00 +0000https://blog.sanbei101.cn/ai-book/04-iter-and-test/04-log/<p>在工程演进中,系统上线后通常面临如下场景:</p> <blockquote> <p><em>&ldquo;生产环境接口在夜间偶发 500 错误,随后自动恢复,需要定位根本原因。&rdquo;</em></p> </blockquote> <p>若服务在标准输出中仅打印非结构化文本:</p>