学习与作品：用可检查的成果证明能力

一个能演示的作品，还需要经历什么，才足以让别人讨论你的能力？可以先看一个简单区别：作者运行给定样本，与另一个人根据说明改变规则，是两项不同的观察。前一项可能正确，后一项仍可能卡住。把它们混成“项目完成”，会错过学习最有价值的部分。

本章把前面的能力判断落到同一个小项目。它不要求再建一个更大的毕业系统，也不以使用多少工具评价成果。学习者应留下作品怎样变化、为什么变化以及谁实际检查过的记录。

让一个作品经历三次变化

下面是一条本书建议的练习路径，并非任何公司的培训制度，也不保证带来录用。它适合已有基础编程能力、希望补上交付经验的人。与其一次做很多演示，不如让一个范围很小的作品经历需求变化、异常和移交。

我们用一个明确的教学项目：帮助活动组织者处理预约和候补。所有参与者、时间和记录均使用合成数据，不接真实支付，不向真实用户发送通知。选这个题目不是因为它像大型企业，而是因为它允许初学者看见一条完整的责任链。

第一版：把一个边界讲清楚

第一版先只回答一个问题：一个名额空出来后，下一步应该给谁看什么信息？把报名、候补、取消这些状态写清楚，画出组织者今天怎样处理。这里不必急着加入 AI。如果普通规则已经能按顺序找出候补者，规则就是一个有用的起点。

为了避免凭想象把“客户”写出来，可以请一位了解活动组织的人，在知情同意下评论这份流程。若没有合适的人，就把需求标为自己的假设，先验证程序；不要把朋友随口表示“挺好”写成用户需求已经确认。练习的价值不在于伪装成正式项目，而在于让哪些部分经过检验变得清楚。

接下来需要回答几项容易被演示略过的问题。取消是否立即释放名额？候补者获得的是一个可以接受的邀请，还是已经确定的席位？邀请多久有效？两个人同时操作，会不会让一个名额被分配两次？这些问题的答案决定程序要记住什么，也决定使用者需要作出什么判断。

第一版可以很小：接收一条取消记录，产生一个候补邀请草稿，由组织者确认。此时作品应能展示正常完成，也应能解释为什么暂时不自动确认席位。把边界讲清楚，能让旁观者知道你做的是一段可控流程，而不是看似完整、实际依赖临场补救的表演。

问到并发，并不意味着起步作品已经解决并发。本章参考程序只按顺序处理消息。可以先明确这一局限，把真实并发留作后续任务；不能用串行样本通过证明两个真实使用者同时操作也安全。

第二版：让变化暴露原来的假设

第二版给它加入变化。请评阅者修改一条条件：同一个人可能报名两个场次，取消只影响其中一场；或者一条取消通知被系统重复送来。现在看程序能否保持正确，看看你的数据设计是否清楚地区分了“人”和“某次报名”。保留第一版和修改记录，让人能够比较你原先的假设在哪里不够用。

这一步最值得留下的，往往不是最终那几行代码，而是如何定位问题。记录一条输入怎样经过系统，在哪里产生错误，为什么选择这个修改，以及还有哪些受影响的情形没有检查。别人由此可以判断，你是在追随测试结果修改，还是每次凭直觉换一种写法。

如果要使用 AI，可以给它一个边界清楚的辅助任务，例如把自由文字的取消请求整理成待确认的场次和姓名。然后故意给出含糊输入：只写“周末那一场”，没有明确是哪天。系统应该怎样表示不知道，怎样让组织者补充，而不是替他完成不可逆的决定？这一小步足以练习模型能力与业务责任的分界，不必把整个项目包装成自主 Agent。

第三版：让另一个人继续工作

第三版交给另一个人运行。请对方按照说明安装或打开，处理一次正常请求，再处理一个失败请求，最后修改一项规则。作者尽量不要立刻在旁边补充口头提示。看对方卡在哪里，才知道作品中还有哪些知识只存在于自己脑子里。

移交后的修订应回到作品：模糊的按钮说明改在界面里，遗漏的安装步骤写进说明，难定位的错误补上记录，只有作者知道的规则变成可阅读的配置或代码。这种改进没有新的演示噱头，却会显著改变别人能否使用和维护它。

预约与候补合成练习包把这条路线做成了可以下载、复算的材料：两场活动、一个跨场报名者、候补名单、重复取消、含糊请求与过期邀请。附带的本地参考程序只操作内存里的合成记录，不调用模型、不联网、不发通知、不收付款。读者可先按数据自行实现，再运行参考程序核对预期；知道一个答案与解释它为什么正确，是两项不同练习。

包内第一版只处理明确取消与邀请草稿；第二版检查重复消息、场次隔离和含糊输入；第三版让接手者修改邀请有效期，重新跑边界样本。示范评阅指出一个刻意设置的坏办法：只按人查报名，会把同一个人在另一场的席位一起影响。它是教学评语，不是真人反馈；读者实际请人试用后，应另填空表，保留卡点和没有测试的部分。

这套练习首先训练的是接口、状态和可交接性。若准备面向模型应用的FDE岗位，可另加两条自由文字提取题，检验“知道场次”与“猜场次”；若准备供应链岗位，可接着做供应链容量和时间约束题。前者不能替代领域知识，后者不能替代模型工程。三个版本没有固定完成天数，也不模拟企业全部压力；它们提供的是能被别人检查的起点，不是录用证明。

每一步学习都要有看得见的产物

如果一次看完代码仍难以解释，不必急着加入模型。可以先只读数据和题面，在纸上写出一次明确取消会改变哪条报名、另一场为什么不变；再对照运行。能够写程序后，再实现或修改一段逻辑，请评阅者指出你没有覆盖的条件。已有工程经验的人，则可以从解释边界和安排他人接手开始。起点不同，仍使用同一组材料。

下面的对照帮助读者决定要留下什么。它评价的是本次练习证据，不给出通用任职资格。

程序的事件编号账本与业务状态都只在内存中存在，重启即丢失；角色名称也不是实际身份鉴别。它不证明真实并发、持久化、对外通知或付款的可靠性。练习的约束是有意选择的，让学习者先能解释可见的行为，再决定是否要承担更大的范围。

评阅时可以先问学习者预期怎样，再看运行。如果预期错了，要求说明哪项理解需要改；如果运行错了，要求给出可复现输入；如果说明缺了条件，回到说明中修补。不要仅因为最后一次运行成功，就删除前面的失败记录。

两条可选自由文字题也是这样使用。样本文件的 actual_model_output 为空，表示尚无实际模型结果。若自己接入模型，应保存实际版本、输入和输出，再比较明确场次与含糊场次的差别。抄下参考答案，不构成模型评估；本书也没有替读者完成这一步。

作品集要容得下失败和限制

一个对判断有帮助的作品集，不必装进所有技术。它应让别人看见一段完整工作：为什么选这个问题，输入从哪里来，哪个约束最难，做过哪些选择，怎样检查结果，剩下什么。同时把自己的贡献写在可见的位置：哪些实现和修改由你完成，哪些沿用现成产品或本书参考程序；与同伴合作时，各自负责什么；使用 AI 时，工具参与了哪些环节，你怎样复核。评阅者需要判断你的工作，而不是一个无法归属的总成果。

演示视频或短说明可以作为入口，旁边提供可运行的版本、代表性检查、一次失败的复原和别人能照着使用的说明；需要深入讨论的人再查完整变更记录。若只能公开一部分，就解释省略的范围，不用截图暗示整个系统都已经验证。真实客户材料的展示须取得相应许可，练习可从一开始使用公开或合成材料。不能把客户不允许展示的内容交给工具改写几句，就当作已经脱敏和获准公开。

最有说服力的解释往往涉及取舍。为什么先只生成草稿？为什么没有加入另一个模型？为什么保留人工操作？什么时候会改变这个决定？这些问题能帮助评阅者看到你是否理解系统，而不只是熟悉工具界面。

也要避免用一串缺少分母的好数字代替理解。“处理了很多请求”不能说明请求有多难，“运行成功”不能说明结果适合用户，“成本下降”不能说明工作有没有转给别人。若只是练习，就展示练习规模和条件；不需要把小作品包装成企业级成果。

对于完全没有客户经验的人，诚实的作品尤其有用。它不能替代大型系统经验，但能让导师看到可以从哪一段责任开始培养。假装独立完成从战略到上线的一切，反而会使能力边界难以评估，也使下一项任务更容易分配错误。

把一次失败写清楚，比把错误包装成主动设计更有用。一份可检查的失败记录应留住原判断、触发输入、看到的结果、修正和仍未解决的部分。若回顾时才想到更好的方案，可以明确标为事后认识，不必假装当时已经知道。

把反馈变成下一次可检查的变化

请人看作品前，给出具体任务，而不是只问“怎么样”。例如，请对方根据说明调整邀请有效期，先预测结果，再运行并解释差别。记录实际卡点及其发生条件，区分看不懂说明、环境没准备好、程序错误和规则未解释清楚。不同问题需要改不同地方。

修订后，再检查原卡点是否消失，同时确认修复没有破坏原来正确的路径。若对方这次已经记住操作，不能简单把第二次顺利全归于说明变好；可以增加一项未背过的规则变化，或请另一位知情同意的评阅者试用，并如实保留两次条件的差别。这里给的是练习设计，本书没有据此取得真人学习效果数据。

没有评阅者时仍可学习：先预测、再运行、解释差异，保存未完成的交接环节。不要用 AI 扮演读者得到的赞扬替代真人试用记录。模拟可以帮助找问题，身份必须清楚。

完成一轮后，回到能力地图，只更新已经有新证据的那一项。作品越做越大并非必然进步；一个范围小、能解释变化、能复现失败、能由他人接手的成果，已经足以支持更具体的下一项学习任务。

本章为本书教学设计。全部参与者、事件、时间和评语均为合成材料；未开展真人试读，也不承诺培训或求职效果。引用其他章节仅帮助定位相关判断，不将其案例成效归给本练习。