本文基于《优秀的工程师如何在大公司写出糟糕的代码 — How good engineers write bad code at big companies》整理核心信息，并结合实际工程场景给出可执行建议。
核心摘要
- Every couple of years somebody notices that large tech companies sometimes produce surprisingly sloppy code. If you haven’t worked at a big company, it might be hard to understand how this happens. Big tech companies pay well enough to attract many competent engineers. They move slowly enough that it looks like they’re able to take their time and do solid work. How does bad code happen?
- Most code changes are made by relative beginners
- I think the main reason is that big companies are full of engineers working outside their area of expertise. The average big tech employee stays for only a year or two1. In fact, big tech compensation packages are typically designed to put a four-year cap on engineer tenure: after four years, the initial share grant is fully vested, causing engineers to take what can be a 50% pay cut. Companies do extend temporary yearly refreshes, but it obviously incentivizes engineers to go find another job where they don’t have to wonder if they’re going to get the other half of their compensation each year.
- If you count internal mobility, it’s even worse. The longest I have ever stayed on a single team or codebase was three years, near the start of my career. I expect to be re-orged at least every year, and often much more frequently.
我的判断
这类内容的共同点是：模型能力上限不断提高，但稳定产出仍取决于流程约束。把验收标准、上下文边界、回归测试写清楚，实际收益会明显高于“追最新模型”。
真正有复利的做法不是一次性写出完美提示词，而是形成可复用的协作脚手架：任务拆解模板、失败回喂模板、以及固定的验证清单。
可直接落地的做法
- 先写可判定的完成标准（测试通过、接口契约、输出格式），再让模型实现。
- 每轮迭代只改一个维度（正确性/可读性/性能），避免目标漂移。
- 把失败案例沉淀为检查清单，下次直接复用。
结语
技术文章真正的价值不在“看过”，而在“转化为下一次决策时可复用的方法”。建议把本文结论映射到你当前项目的一项具体动作，并在一周内验证效果。