Urazuke — 手工编程时代之后的初级开发者：他的培养有什么变化，以什么目标培训他，以及怎么培训

作者：Pablo Kuschniroff，由 Claude Code 辅助。第 1 版，2026 年 10 月 18 日。这份文档伴随方法的 主文档和课程的两个部分（新项目、 继承来的项目）。它是写给三类读者的：带团队、必须决定教新人什么的人；上课或做辅导的人；以及初级本人，他想知道自己要变成什么。生僻的词都在主文档的术语表里。公开仓库：github.com/pkuschnirof/urazuke。

我为什么写这个

三十年里，一个初级开发者只有一种成长方式：在监督之下写代码。他进来时半懂一门语言，别人给他小而有界的任务，一个资深审查他的代码，然后在两三年的写与被改之中，他学会了这门手艺。代码同时是工作，也是学校。

这件事结束了，而且不是因为不再需要初级，而是因为模型在写代码。用我的方法，构建的人不读代码：他索要证据。于是别人问我、我也问自己的那个问题是诚实而紧迫的：如果初级不再写代码，他怎么学？他学什么？他要变成什么？

我有一个答案，而且我从两个位置来写它。一个是我这样构建的三个系统，在那里我是唯一的人类，我一个事故一个事故地看到了哪些能力救了我、哪些我根本没用上。另一个是在模型还不存在之前我教系统工程的那些年：今天必须教给一个初级的东西，很多正是经典系统工程一直在教、而行业在这门手艺变成"编程"时不再实践的东西。模型逼着我们回到键盘把它盖住之前这门手艺本来的样子。

有一句提醒，免得被误解：我不是在说初级不必会编程。我是在说他不再是靠编程成长的，而且他必须懂的那部分编程改变了性质：从手艺变成了识字能力。

一个初级过去做什么，现在做什么

对培训重点的影响

我先用一句话说出来，然后再拆开：失去分量的是一切模型做得比一个两年经验的初级更好的东西，获得分量的是一切模型做得不好、而方法正是为了纠正它才存在的东西。第二份清单不是我发明的：它就是参考资料文档里那份故障清单，反过来看。模型的每一个故障，都是人必须具备的一项能力。

失去分量的重点

• 语法和语言。 "背下来"一门语言曾经是培养的一半。不再是了：模型用任何语言都写得更好更快。剩下的是会*读*它们，那是另一回事（见下文）。
• 框架和库。 熟悉一个库的 API 曾经是市场价值。模型整个都熟，连同它的各个版本。初级要知道它们存在、有什么用、什么时候选哪一个，而不是每个函数叫什么名字。
• 打字和写作效率。 编辑器快捷键、自动补全、手工生成脚手架。作为重点消失了。
• 逐行调试作为主要手艺。 它仍然存在，但换了位置：现在它是最后一件工具，用在证据（日志、红色测试、量具）不够的时候。
• "某某事怎么做"的记忆。 模式、配方、窍门。模型全都有。

获得分量的重点

我按它们被操练的台阶来排序，因为那是教它们的方式。

1. 需求工程（台阶 0、2、3、5）。采访一个不知道自己要什么的所有者，用散文写下他要什么，给用例起名字，搭起业务的语义树，用"给定、当、那么"的形式连同验收标准一起写出一个待办项的规格，区分原始数据和派生数据，并索要原始数据而不是去估计它。这是第一号能力，也是行业二十年前就不再教的那一项。模型在这件事上天生很差：它用最可能的东西填补空缺，而最可能的东西不是业务需要的东西。
2. 验证的设计（台阶 7、9、10、19）。不是写测试：是知道哪个测试证明什么，为什么一个测试必须先被看到变红才算数，什么是端到端测试、什么是一个什么都不证明的模拟，哪个数字决定什么、用什么仪器去测，怎么读一份报告并把已验证的和相信的分开。初级必须能够不读测试就说出"那个测试证明不了你说的东西"。
3. 证据的阅读（所有台阶）。带着训练过的不信任去读模型的报告：找出没有证明的断言、伪装成已验证的"应该能用"、没有声明的盲点、那个其实并不是的"完成了" Ref. 43。这项能力过去不是培养的重点，因为过去没有谁能带着这么大的笃定和这么好的文笔撒谎。
4. 容量估算与运维（台阶 3、4、13、16 到 21）。什么是环境、怎么部署、什么是持续集成、在生产里测什么、什么是索引、什么是断裂点、什么是告警阈值。过去这是另一个角色的领地；现在初级要指挥做这件事的模型，而且必须知道该向它要什么、怎么验证它做到了。
5. 安全与后果（台阶 12、18）。系统的哪些动作作用于现实世界，什么是锁，什么是失败即关闭，什么是漏洞，以及为什么一次依赖更新是一次变更。
6. 决策与和所有者的沟通（台阶 1、6、14）。好好地提问，带推荐和备选；写一条带原话、日期和负责人的决策；写一份不编程的人也能照着做的手册。在方法里，初级是所有者和模型之间的翻译，而翻译是双向的。
7. 工具性英语。 方法的提示词是英文的，因为模型用英文遵循指令更精确。不需要会说；需要能读一条提示词并理解它的每一个条款，并在情况需要时写出一条新的条款。
8. 模型故障的目录。 凭气味认出模型出错的每一种形态：假设而不提问，编造一个原始数据，报告过头，"顺手"做了范围之外的事，重构了没人要求的东西，改进了你的措辞，没有证据就收尾，不知道的时候保持沉默。我在会话中做的、后来变成规则的那四次纠正 Ref. 45 就是例子：每一条都是一个受过培养的初级必须在第一份报告里就发现的故障。
9. 成本作为预算。 token、持续集成配额、所有者的时间。不看成本的初级会重演那个花双倍、交一半的多代理团队 Ref. 6。

初级确实必须懂的那部分编程：识字能力，不是手艺

这里有我最在意、也最容易被误解的那个分寸。一个从来没写过代码的初级，不知道模型什么时候在代码* 里面*撒谎，而方法里有一个时刻——我今天在主文档里把它标为假设——人确实必须去看。所以最低限度的识字能力不可协商。清单如下：

• 读代码，不是写代码：跟着一个函数走，看懂一个条件判断，认出一个循环，看到哪里对数据库做了一次查询。就像不当律师也能读一份合同。
• 一个系统是怎么跑起来的：什么是服务器、进程、数据库、一次 HTTP 请求、浏览器、定时任务。每样东西住在哪里。
• Git：什么是提交、分支、push、历史。够读懂方法留在那里的证据痕迹就行。
• 基础 SQL：读一条查询，明白它读哪张表、用什么过滤条件。它是数据的语言，也是第 7 级台阶那些数字的语言。
• 终端：跑一条模型给你的命令，并读它的输出。如果初级不能跑那把量具，他就不能验证那个数字。
• 调试作为最后一件工具：当日志、测试和量具都不够的时候，和模型一起打开代码，一起读。

它在第一个阶段教完，在整门课程里反复练，而且它不是手艺：它是让人能够从事这门手艺的识字能力。

以什么目标培训一个初级

我直说，因为其余的一切都取决于目标是否清晰。在手工编程时代之后培训一个初级，目标是培养出一个 没有写过一行代码却能为一个生产中的系统负责的人：他能把一个小项目从头到尾带过二十四级台阶，指挥一个模型，在每一步向它索要证据，和所有者一起做决定，并在任何时刻都知道什么是已验证的、什么是相信的、什么是看不见的。我暂且把他叫做*证据的技术主人*：那个不读代码、却能手里拿着证明说出系统做了业务要求的事、而且明天还会继续这样做的人。

目标带来三个结论，它们决定了培训的样子：

1. 评估的产物是证据，不是代码。 评估一个初级，看的是他写的契约、他搭的树、他写了规格的待办项、他索要到的那个红、他没有接受的那份报告。课程手册附录 A 的评分表已经这么说了：未登上、已登上、已登上并有判断力的证据。第三级——能讲出一个模型出错的案例以及他是怎么发现的——才是真正的目标。
2. 反射是用事故形成的，不是用理论。 没有人是靠读到"要怀疑模型"而学会怀疑模型的；他是在模型对他说"完成了"而其实不是、并且他在测试环境里发现了这件事的时候学会的。所以课程里有故意设下的考验（留一个问题不回答，看模型怎么办；在调研里留下假设），所以培训必须有设计好的事故，而不只是一帆风顺的任务。
3. 初级要在完整的方法里成长，不是在某一个阶段里。 诱惑是把他放到循环里"去做待办项"，那最像给他小块的代码任务。那是个错误：没有启动阶段的循环是建在沙子上，而一个从来没做过第 0 级或第 3 级的初级不明白第 5 级为什么是那个样子。两个引导项目正是为此存在：一个新的，一个继承来的，从头到尾，二十四级台阶和八个站点。

怎么培训他：计划

下面是我会用、也将要和第一期学员一起用的计划：四个阶段，没有期限（方法没有，培养也没有：每个阶段在它的出口清单全是"是"时结束），有一位导师，在课程的两个引导项目上，之后是一个有真实所有者的真实小项目。

阶段 1：识字能力，以及把模型当作研究对象

• 上面那份识字清单：读代码、一个系统怎么跑、git、基础 SQL、终端。模型在旁边解释；初级不写，他读和跑。
• 把模型当作研究对象：花一段时间向模型提要求，唯一目的就是看它出错。要一个它没有的数据，看它会不会编。给一个含糊的要求，看它会不会问。让它收尾某件事，看它会不会没有证明就说"完成了"。让它修一个 bug 而不去复现它。每个故障连同它的气味一起记下来。到这个阶段结束时，初级有了他自己的目录，而那就是参考资料文档里的那份目录，被他自己发现了一遍。
• 读主文档，术语表放在手边，以及读参考资料：每条规则从哪里来的故事。

阶段 2：新项目，有导师

课程手册第 1 部分，原样，做在引导项目"Turnera"上，或者做在他自己的一个小项目上。二十四级台阶。有三条辅导规则：

• 导师审查证据，不审查代码。 他读协作契约、语义树、三个待办项的规格、一个待办项的收尾报告、审计的报告、负载测试的报告。而且每次只问一个问题："你怎么知道这是真的？"如果回答是"因为模型这么说的"，那级台阶就没登上。
• 导师设计事故。 每隔一段时间，不打招呼，他改动点什么：改掉调研里的一个数据，在容量数据里塞进一个假设，通过模型提出一个范围之外的改动要求。初级必须靠证据发现它。
• 初级自己记一份模型故障登记册：每一次他抓到模型，是什么气味，在哪级台阶。项目结束时那份登记册就是他个人的复盘，而对梯子的修改提案（第 23 级台阶）由他来写。

阶段 3：继承来的项目，导师少一些

手册第 2 部分：继承来的 Turnera，或者一个真实的小遗留系统。规范化阶段和头两个功能块。这里辅导降下来：导师读恢复出来的地图和那些不一致、读带速度标记的审计报告、读以纠正模式关闭的第一个 bug。这个阶段的目标是让初级学会新项目教不了的东西：通过模型读懂一个别人的系统，和所有者一起决定代码所做的哪些事是错的、哪些是一条被遗忘的规则，以及不要重写。

阶段 4：真实项目，独自

一个真正的小项目，有一个每天有十五分钟的真实所有者，从头到尾。导师不介入；最后读那份带数字的复盘。如果初级带着出口清单上二十四个条件都是"是"抵达生产，他就成型了。如果没有，清单会准确地说出要重登哪级台阶，而那也是培养。

用什么衡量进步

不是他关闭了多少待办项。是三件事，按这个顺序：

1. 他抓到模型多少次，以及在哪级台阶。一个在整个新项目里一次都没抓到模型的初级是没在看：模型总是会出错。
2. 他让所有者付出了多少。 每天多少分钟的提问；如果上升，说明初级在把方法要求他解决的事转嫁给所有者（第 1 级台阶）。
3. 他那条对梯子的修改提案的质量。 它是判断力的指标：一个提出具体修改、并用自己的一个事故来支撑它的初级，是把方法理解成了活的东西，而不是一张清单。

对角色和团队的影响

我说这个，是因为带团队的人一定会问我。如果初级这样成长，团队就会改变形状：

• 初级不再是"写简单部分的那个人"，而成了用方法带完一整个小项目的人。他更早就更有价值，也更早就更危险，因为他指挥着一个构建得很快的模型；所以方法是条件，不是附加项。
• 资深不再审查代码，转向三件事：写并维护那些契约（协作契约、闸门、锁），用另一次会话做审计（第 13 级台阶），以及决定初级不能决定的事（架构、"乘以十"、什么要被阻断）。他的价值从键盘移到判断力上，而在那些好的资深身上它一直就在那里。
• 团队变小、变扁。 一个资深加两三个有方法的初级，带得动过去要八个人的团队带的东西。我砍掉整个代理团队时在自己的数字上看到了这一点 Ref. 6：同样的逻辑适用于指挥模型的人类。
• 领域所有者进入团队。 每天十五分钟，但他进来了，因为方法要求他进来。培训一个初级，包括教他如何争取到那十五分钟、并且不浪费它们。

风险，不加粉饰地说出来

• 那个从来没写过代码、不知道什么时候该去看的初级。 这是主要风险，我用强制的识字能力和"调试作为最后一件工具"的练习来缓解它。但我把它标为假设：我还不知道要写过多少代码才能读好别人写的代码。我怀疑不多，而且我怀疑要紧的不是写过，而是*调试过*。
• 对一个工具的依赖。 方法是有意对工具中立的。一个只在一个工具里成长的初级学到的是它的快捷方式，不是方法；培训必须经过至少两个工具。
• 看不见的成本。 一个带着模型的初级花 token 就像它们是免费的。token 预算必须从第一个阶段起就是培训的一部分，而且数字要摆在眼前。
• 速度的幻觉。 模型一次会话就构建出过去要花多得多时间的东西，而初级可能以为自己做完了。上线生产清单，连同它的二十四个条件，就是解药："完成了"有一个定义，而那个定义不是"能用"。
• 那个出于习惯审查代码的导师。 这是资深那一侧的风险，而且很严重：一个读代码的导师教给初级的是证据不够，而那恰好和方法相反。导师必须比初级更早地在方法里成型。

尚待展开的 假设

1. 要做过多少编程，才能读好别人的代码。我的直觉是，要紧的是调试过，不是写过，而且不多就够。目前还没有数据。
2. 这份四个阶段的计划是从我的项目、以及从我在模型出现之前教过的东西写出来的，不是从一期学员写出来的。第一期会修正它，就像会修正课程一样。
3. "证据的技术主人"到底是一个新角色，还是换了一件工具的那个一直以来的系统工程师。我倾向于后者，那样这个名字就多余了；但市场会需要一个名字，而我宁愿先提一个，免得别人提一个更糟的。
4. 一个进入不使用方法的团队的初级会怎样。这份文档假设团队采纳了方法；如果没有，这样成长起来的初级会撞上一个向他要代码的资深。我没有答案，只能说方法已经公开，好让那个资深去读它。