rzk 发起 / Hacker News 讨论 · 阅读原文
Hacker News 的这场讨论围绕一个交付难题：开发者用 AI 写出了能运行的代码，也能说明整体思路，却不一定能解释每个实现细节；若把全部代码重新推导一遍，又可能耗尽工具节省的时间。发帖者 rzk 转引了这种担忧后征求做法。这里以实际可读的 HN 主帖和回复为依据，未把转引的 LinkedIn 内容当作另外核验过的一手发言。
几种回答给“理解”划出了不同范围。linsomniac 从运维经验出发，指出生产系统本来就依赖大量非本人编写的内核、数据库和应用代码；信任来自测试、预发运行、监控以及逐级推广。plastic041 则要求至少有人能解释代码与算法，理由是测试本身也可能错，绿灯不能代替判断。两者争的是能把哪些细节当作可信部件，以及关键假设由谁负责。
otiose_tortoise 用数据库迁移举出一种具体保障：从旧 schema 和数据构造状态，运行迁移后再检查结果，并让新增迁移同时带测试。他把这类约束比作管理扩大后的工程团队，负责人不必掌握每一行，但要建立可重复的交付标准。他报告此后未再遇到迁移失败，仍是一段个人经验。下方分别保留三人的理由，不把这场讨论写成行业共识。
可信度 65 · 重要性 85 · 新颖度 78
技术与主题
linsomniac
回应原帖：查看原帖上下文
从运维工程师处理大量非本人编写代码的经验回答。
忠实转述（非原句）：他运行的生产代码中，绝大部分都不是自己写的；内核、数据库等依赖也不可能逐行理解。因此，他建立信任的方式是测试、监控、在预发环境中充分运行，再按流程逐级推广。对他来说，系统的可信度并不等同于某个人读过全部实现。
plastic041
回应原帖：查看原帖上下文
明确反对无人能解释所交付代码的状态。
忠实转述（非原句）：至少应该有一个人能够解释代码和算法为什么这样工作。他并不反对使用大模型，但不能让“测试通过”代替理解，因为测试本身也可能是错的。关键在于是否还有人能够承担解释和判断的责任。
otiose_tortoise
回应原帖：查看原帖上下文
以工程管理及数据迁移为例主张系统性保障；结果是个人自报。
忠实转述（非原句）：他把问题类比为管理一支规模扩大后的工程团队：负责人不再逐行知道全部改动，需要建立可重复的约束。对数据库迁移，他先从旧 schema 和数据构造状态，再执行迁移并检查结果，并要求新增迁移同时带测试。他说采用这个做法后没有再遇到迁移失败。
编辑评读
这些意见共同推进了一件事：把“理解全部实现”拆成可讨论的责任。运维观点允许依赖成熟部件，但要求能观察行为、限制故障影响并恢复；反对者担心的，是连关键算法与业务假设也无人掌握。二者并不必然冲突。真正需要讨论的是某次改动究竟只是替换一个接口稳定的部件，还是改变了系统依赖的约束。
数据库迁移的例子尤其清楚。拿空数据库跑通，只能说明脚本在那个初态下可执行；从真实旧结构和数据出发，才有机会暴露历史状态的问题。评论者的方法因而有价值：它把团队的信任转成可重复检查的状态变化。这里再往前一步的编辑建议，是让负责人说清哪些数据关系必须保留、测试覆盖了哪些旧状态、失败后如何识别和恢复，而不把“谁手写了代码”作为唯一判断。
但测试仍由人或模型定义，有人需要能审视测试是否表达了正确需求。若算法和测试都来自同一个未经理解的假设，多跑几次不会增加独立依据。工程责任因此可以分工，却不能消失：实现细节可交给工具，验收标准、风险边界与出错后的处置仍要有明确负责人。这样才有可能既利用生成速度，又避免把省下的阅读时间转成无人接手的事故调查。
需要留意
- 按论证差异选取评论，不代表投票多数或行业共识。