# AI 接走入门工单之后，新人靠什么学会排查问题？

**Summary:** hrih.si 把 AI 编程和 FORTRAN 取代手工活放在一起比较。我的态度是：可以用智能体，但得保留有资深工程师盯着、由新人自己负责的排查训练，而不是指望审查能力会自然长出来。

- Canonical: https://markhuang.ai/zh/news/ai-starter-tickets-debugging-apprenticeship
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-10-21
- Section: News
- Tags: AI 编程, 编程智能体, 初级开发者, 软件工程, 开发者培养, FORTRAN
- Source: [hrih.si](https://hrih.si/articles/the-compiler-was-supposed-to-end-programming/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![机械臂正在搭建楼梯上层的玻璃台阶，最下面的几级台阶却是空的](https://cdn.markhuang.ai/news/ai-starter-tickets-debugging-apprenticeship/hero.webp)

*概念图：上层的工作自动化了，人怎么迈出第一步仍然是个问题。*

hrih.si 在 10 月 21 日发表的文章[“The compiler was supposed to end programming too”](https://hrih.si/articles/the-compiler-was-supposed-to-end-programming/)认为，编程智能体可以让开发者更多地去做“写清楚需求、检查结果”，就像早年的工具替人干掉了手工活。文章开头描写的 2031 年某个工作日是明确的设想：智能体一夜之间把实现做完，人只负责处理一条含糊的退款规则。这个方向我觉得说得通。让我不太放心的是另一件事：团队还能不能持续培养出有资格做这些判断的人。

我担心的是学徒期。如果那些小而边界清楚的工单都交给智能体，我会刻意留出一部分活，让新人从中学会排查失败、对一个结果负责。让人去审查生成的代码，本身教不会这些。

历史确实给了点鼓励。[IBM 把 FORTRAN 的商业发布定在 1957 年](https://www.ibm.com/history/fortran)，并称它让科学家和工程师可以直接表达问题，不必再靠别人翻译成机器码。编程因此更容易上手了。但这并不能说明，往后的每一次自动化都会留下同样好走的入行路径。

## 拿编译器作比，有一处对不上

文章区分了“某个任务消失”和“某个职业消失”，这一点我同意。它更大胆的预测是：开发者以后主要维护的是规格说明和测试，代码更像编译器的输出。

我会把这个预测和那段历史类比分开看。Birgitta Böckeler 在[“I still care about the code”](https://martinfowler.com/articles/exploring-gen-ai/i-still-care-about-the-code.html)里区分了语言模型的推理和编译器对结构化输入的翻译。她真正在意的是：人能不能发现错误，尤其当后果严重的时候。

这个质疑对那个假想的退款任务很关键。智能体遇到过期卡就停下来，这很好。但一份带着学习目的的任务，也该让人准备好应付另一种情况：智能体自己编出一条看起来合理的规则，然后很自信地实现出来。审查的人得看出来，有个业务决定被偷偷塞进了代码里。

我希望新人能自己找到这条边界，说清楚该由谁来决定，再确认实现有没有照着决定走。把一份漂亮的 PR 直接丢给他，这些一样都学不到。

## 审查本身也是要学的本事

[Stack Overflow 2025 年的调查](https://survey.stackoverflow.co/2025/ai)让这个担心多了几分现实依据：在回答“对 AI 不满意之处”这道题的受访者里，66% 选了“差不多对，但不完全对”。这是受访者报告的困扰，不是测出来的缺陷率。不过它描述的，正是审查者得有能力挑出问题的那类输出。

[那篇文章在 Hacker News 上的讨论](https://news.ycombinator.com/item?id=50185045)里，既有“下一层抽象”的说法，也有人反对把自然语言指令等同于编程语言。对训练这件事，我觉得后一种意见更有用。它会逼我问：一个人还得具备什么知识，才能注意到实现里做了一个没有依据的选择？

文章本身也提出了另一种学徒方式，包括跟着资深工程师一起审查、独立负责一个小系统。我会把这个提议当成前提：只有这么做，才谈得上它描绘的那个乐观未来。把实现全交给智能体、把批准全交给现有的专家，新人的位置还是没着落。

## 留住问题，缩短枯燥的部分

针对我这个担心，最有力的反驳是：智能体也许能帮人学得更快。我不觉得重复敲键盘有什么必要保留成入行仪式。可以让新人用 AI 要解释、要另一种实现，再用第一个答案解决不了的问题，检验他到底懂没懂。

就拿文章里那个假想的退款工单来说，我会让开发者在生成之前先把相关路径走一遍，写下还没定下来的规则问题，再和资深工程师确认验收标准。智能体实现完之后，开发者要再查一个额外的失败场景，并解释为什么这个行为是对的。资深工程师审的不只是补丁，还有这套推理。

这些是训练方法上的提议，不是实验得出的结果。目的只有一个：让学习者仍然要自己对理解系统负责，同时让智能体拿走那些教育价值不大的活。

我还会把交付速度和学到东西分开看。[METR 在 2026 年 2 月的更新](https://metr.org/blog/2026-02-24-uplift-update/)里说，选择偏差和时间测量上的问题，让后来那次开发者实验没法可靠反映当下的生产力。有些开发者不愿参加，或者隐瞒了任务，因为他们不想在没有 AI 的情况下工作。连测速度都这么难，一张完成得更快的工单，就更看不出一个新手到底学到了什么。

## 一张工单可以有两种价值

在[我早先那篇讲证明补丁代价的文章](https://markhuang.ai/news/coding-agents-patch-proof-cost)里，我主张按“错误有多难发现、多难撤回”来决定把什么交出去。训练又添了一层考虑：把一张工单做完，最省事的办法未必最能帮人准备好下一张。

我会留出这样一类边界清楚的任务：学习者必须自己诊断问题，并解释最终怎么改，身边有经验丰富的开发者可以质疑他的推理。时间长了，我希望看到他在陌生的故障上越来越独立。光看补丁被合入，说服不了我。

文章最后设想，开发者会把更多时间花在决定该做哪些东西、检查拿回来的东西上。这个变化我欢迎。但我会现在就为教这些能力留出预算，放在真实工作里做，而不是假设把所有人都赶去审查，就能自动长出审查者。