AI 能让一个想法在一下午变成原型。这当然能提高效率。可如果建造过程中最有价值的部分，恰恰是探索、犯错、修复问题，再慢慢理解系统呢？
本文依据 Hanisha Arora 的文章《When Building Things Was the Fun Part》整理。前半部分梳理原文观点，后半部分关于 QA 与工程实践的建议是本文延伸，不是原作者报告的研究结论。
原文：When Building Things Was the Fun Part: https://bitshift.ing/when-building-things-was-the-fun-part/ 延伸阅读：Leonard Thiele, “What If AI Removes the Friction That Makes Good Engineers?”: https://leonardthiele.substack.com/p/what-if-ai-removes-the-friction
一段公交车程，一团毛线，还有另一种工作日
Arora 在公交车上看到一位乘客一边阅读、一边慢慢织毛衣。她本可以更快完成，但看起来很享受这件事。与此同时，Arora 自己却在检查 AI 写出的代码，不断追问助手到底改了什么。软件成果可能很漂亮，亲手把它做出来的过程却少了些乐趣。她说，自己选择做产品，是因为想把一个想法变成真实的东西，并看到它让某个人开心。
过去，要把一个想法做出来，往往得花几周时间探索、卡住、修好一个问题又引出另一个问题，最后才慢慢理解整个系统。现在，一个能运行的原型可能一下午就出现。问题解决并没有完全消失，缩短的是自己亲自走过这些问题的时间。Arora 担心的不是 AI 消除了所有难题，而是人们可以太轻易地把那些有助于成长的难题交出去。
速度也带来了真实收益：Arora 可以更早验证想法、更快放弃不好的方案，还能在过去认真做出一个方案所需的时间里尝试五种做法。效率确实提高了，同时也让她重新思考：建造过程里哪些部分仍值得亲自经历？
Leonard Thiele 的延伸文章也讨论了类似张力：一些困难并不只是拖慢交付，也可能是形成手艺和判断力的过程。Arora 在原文中推荐了这篇文章，但其中的观点属于 Thiele，不应与 Hanisha 的观点混为一谈。
有些阻力本来就是学会手艺的一部分。
下面的五类阻力是本文从 QA 角度整理出的实践框架，并非 Arora 原文提出的分类模型。
工程团队常把阻力视为应该消除的成本，但不同阻力会带来不同价值：
| 阻力类型 | 例子 | 更合适的做法 |
|---|---|---|
| 重复性阻力 | 样板代码、格式整理、机械重命名 | 尽量自动化 |
| 信息搬运阻力 | 整理日志、汇总报告 | 交给工具或 AI |
| 认知阻力 | 理解架构与连带影响 | 保留直接探索的空间 |
| 判断阻力 | 设计取舍、风险假设 | 人仍需承担判断责任 |
| 创造性阻力 | 从零构建带来的乐趣 | 可以出于兴趣主动保留 |
关键不在于代码由谁敲出，而在于亲自解决问题的过程，能否让人获得可迁移到下一个问题的理解和判断力。
代码写得更快，仍然需要有人带着它做事
Arora 把 AI 编码比作指挥一位速度很快、却缺少关键背景的工程师：你要分配任务、解释限制、审查结果、纠正误解，还要阻止不必要的重写。代码生成确实加快了，但协调、验证与纠偏仍然存在。
所以，“AI 写了 1000 行”不等于“省下了 1000 行工作的成本”。总成本还包括审查差异、验证行为、定位回归、保持架构一致，以及之后继续修改实现。
Arora 说，自己一直不太愿意管理人，因为她想靠近产品建造过程。她理解资深岗位通常会逐渐转向审查、规划、疏通阻塞和帮助他人建造，但她并不喜欢自己从动手构建转向这些工作的过程。AI 又给了她一个停止写代码的理由；如今管理智能体，则让熟悉的协调工作以另一种形式回来。
她把智能体形容为速度很快、但理解力像刚入职的实习生：它可能缺少关键上下文，却很自信地建议重写整个架构。
产出看起来完整时，经验更重要。
Arora 担心，产出看上去成熟的结果，与真正理解结果之间的距离正在扩大。AI 能实现方案，也可能自信地解释错误方案。经验的价值之一，是能对漂亮但不符合现实约束的设计保持怀疑。
招聘和指导新人时，不应只看能否做出演示效果出色的原型。也要观察对方能否说明限制条件、提出反例、复现失败、比较方案，并在没有助手时完成基本的关键推理。
Arora 用最近的一次面试说明这种担忧：她说，有些候选人已经很熟练地使用 AI，也能让这种辅助不那么明显；履历看起来很出色，被追问时却难以解释自己究竟学到了什么。她提到，其中一场面试七分钟就结束了。这不是招聘效果的统计结论，而是她对“表达流畅”与“真正理解”脱节的亲身观察。
质量判断仍应由人负责
以下是质量工程实践延伸，不是原文的实证结论。
AI 可以整理需求、提出测试想法、搭建接口或界面自动化骨架，也能汇总执行证据。但以下判断仍应由人主导：
- 识别风险：哪些失败会影响用户、金钱、隐私或合规？
- 定义判定依据：除了页面元素存在，还有什么能证明结果正确？
- 探索测试：哪些意外行为值得提出新假设？
- 分析失败：这是环境噪声、产品缺陷，还是测试本身有问题？
- 做质量取舍：哪些内容要自动化、深入调查，或明确延期？
如果测试人员说不清五十条生成用例中最重要的五条、各自的目的和可能发现的问题，那么用例数量增加并不代表质量工程更强。
根据任务目标决定委派什么
交付任务：把重复、规范明确且容易验证的工作交给工具；目标、验收标准和审查责任仍由人承担。
学习任务：先自己建立初步理解或完成一个最小实现，再让 AI 挑战你的想法，而不是一上来要求完整答案。
创作乐趣：可以有意识地保留自己想亲历的部分，吞吐量不必成为唯一目标。
高风险变更：保留人工设计审查、关键测试判定依据、授权判断和发布决策，并用可复现证据支撑。
这并不意味着要强迫所有人手写所有代码，以证明自己付出了足够努力。Arora 的意思是有意识地安排学习：若目标是提速，可以把低价值、重复工作交给 AI；若目标是理解、探索或享受创造过程，就应保留其中值得亲自经历的难点。
先说清这次采用哪种工作方式。
开始任务前，可以简单约定工作方式：重复执行选“委派”，探索新问题选“结对”，需要反驳和挑战选“质疑”，刻意练习则选“先手动”。这不必变成新的审批流程，只是先说清任务更看重速度、学习还是决策质量。
代码和测试审查时，有两个问题比“这是不是 AI 写的”更有用：“你为什么认为它是对的？”“出现什么证据时，你会改变判断？”它们更容易看出提交者是否真正理解成果。
除了吞吐量，还要看什么。
AI 降低了得到结果的成本，但工程师仍能决定旅程中哪些部分值得亲自经历。目标不是拒绝自动化，而是自动化空耗的阻力，保留能带来理解、判断与乐趣的阻力。
对 AI 原生质量工程来说，工具可以扩大质量工作的覆盖面，但专业能力仍建立在理解风险、设计验证、解释证据，以及为重要决策负责之上。
参考资料
- Hanisha Arora，《When Building Things Was the Fun Part》: https://bitshift.ing/when-building-things-was-the-fun-part/
- Leonard Thiele，《What If AI Removes the Friction That Makes Good Engineers?》（相关观点）: https://leonardthiele.substack.com/p/what-if-ai-removes-the-friction