LLM 重写工程管理旧规则
推荐指数 46.0 NO. 014 · 2026.07.26
发布2026/07/25Score60Comments89
为什么值得看
一位工程总监在引入 LLM 后重新审视传统管理信条，发现约半数"铁律"的底层假设因代码成本暴跌而失效。对正在调整研发管理策略的 AI 团队有直接参考价值。
编辑判断
这篇文章的冲击力在于它来自实践者而非管理顾问。作者提到的"保护团队免受业务干扰"这条规则尤其值得细想——当 LLM 让原型成本趋近于零，"业务频繁改需求"反而可能是优势，因为验证成本低了，快速试错比长期保护更有价值。
另一个被颠覆的假设是"好工作需要时间"。在 Cursor 或 Claude Code 的环境下，一个资深工程师的产出瓶颈从"写代码速度"变成了"判断哪些代码值得写"。这意味着管理者的核心任务从"保护专注时间"转向"提高决策质量"，而决策质量又取决于对业务上下文的理解深度。
如果你还在用"代码行数"或"故事点"衡量团队，这篇文章是一记警钟。建议直接和团队做一件事：挑一个最近完成的 feature，用 LLM 重做一遍，对比实际耗时和原计划的差异，这个数字会告诉你管理规则该更新多少。
社区反馈
意见分歧 86 条评论
核心争论：LLM降低写作成本后内容质量是否下降，以及AI辅助创作是否损害可信度
Can a llm predict the price of a change to a codebase in tokens and predict the origin of the price, aka cam it see good and bad architecture?
Ask it to do so, would love to know your results.
I did, the problem is that you need a sort of standardized feature change to compare similar repos. So the metric is relative only to same projects lacking that same feature. So no, its a useless thing. No architecture score comparisson between apples and oranges.