全盘接受，一窍不通
按下回车键接受代码建议，比滚动跳过它们要省力得多。只需一个按键，代码就成了你的。但阅读和理解这些代码的速度并没有变快。
你接受代码的速度与理解代码的速度之间存在着差距。而错误往往就发生在这个差距之中。
技术债过去通常有明确的原因。要么是截止日期紧迫，要么是偷工减料。你可以指明原因。而现在，你可能在一个平静的周二就在积累债务。因为看起来没问题，你连续接受了六个建议。没有人催促你，但代码却未经审视。
Brian Kernighan 在 1974 年曾说过，调试比编写程序要难两倍。他当时指的是人类编写的代码。至少人类能理解自己的工作。
如今，一个建议可以通过 linter，甚至通过测试。但它仍可能基于错误的假设。之所以会这样，是因为人们把建议当作“输出结果”而非“代码”来阅读。看起来不错的输出结果就会被批准。
如果模型既写了代码又写了测试，那你就像是在用学生自己的答案来批改作业。这无法告诉你逻辑是否严密，也无法告诉你是否覆盖了边界情况。当代码出现在你自己的编辑器中，并符合你自己的风格时，人们很容易忘记这一点。
这会引发严重的问题：
- 你在调试从未读过的代码。当几周后程序崩溃时，你只能从零开始。
- 边界情况失效。建议可能很好地处理了快乐路径（happy path）。它包含了空值检查，但却遗漏了业务所需的特定逻辑。
- 你无法为自己的 pull request 辩护。如果审查者问你为什么选择某种方法，你答不上来。因为决策不是你做的，你只是没有拒绝它。
这些工具很有用。它们可以帮助你探索代码库或规划新功能。问题在于你的态度。你必须把每一个建议都当作需要阅读并做出决定的内容，而不仅仅是扫一眼。
对于样板代码或快速脚本，追求速度没问题。但对于业务逻辑或安全性，你的方法必须改变。要像你会负责这段代码一样去阅读它。因为你确实会负责。
建议采取以下做法：
- 在请求代码之前，先与模型讨论你的解决方案。
- 像代码是你亲手写的一样去审查 diff。
- 在接受代码之前，要求工具解释其推理过程。
- 把建议当作初级开发者的工作来对待。它有用，但并非事实标准。
- 在让你感到意外的代码行上慢下来。意外是一种信号。
按键的成本降低了，但你的责任并没有。没有理解的速度只是在快速积累债务。
来源：https://dev.to/cloudx/accept-all-understand-none-4dob
可选学习社区：https://t.me/GyaanSetuAi