罗伯-派克的 5 条编程规则 规则 1.你无法判断一个程序会在哪里花费时间。在测量之前不要调整速度，即便如此，除非代码的某个部分压倒了其他部分，否则也不要调整速度。规则 3.当 n 较小时，花哨的算法会很慢，而 n 通常很小。如果你选择了正确的数据结构，并把事情组织得井井有条，算法几乎总是不言自明的。派克规则 1 和 2 重申了托尼-胡尔的著名格言："过早优化是万恶之源"。Ken Thompson 将派克规则的第 3 和第 4 条改写为 "当有疑问时，使用蛮力"。规则 3 和 4 是 KISS 设计理念的实例。弗雷德-布鲁克斯（Fred Brooks）曾在《神话中的男人月》（The Mythical Man-Month）一书中阐述过规则 5。规则 5 通常被简称为 "编写使用智能对象的愚蠢代码"。

生成代码并不是软件开发最困难的部分，真正困难的是明确需求：理解谁需要什么、哪些约束重要、异常情况如何处理，以及成功如何判断。即使 AI 能快速实现指令，模糊、矛盾或错误的需求仍会制造更大的失败。开发者的核心价值因此包括澄清问题、协调利益和验证结果。

工程策略不是愿景口号，而是工程组织处理当前约束的一套成文判断。好的策略包含三部分：诊断、指导性政策和一致行动。诊断要说明真正的挑战是什么，例如收入增长转向某条业务线、测试不稳定拖慢研发、团队之间缺少决策信息；指导性政策要明确取舍，例如资源如何在产品、基础设施、新实验和开发效率之间分配，何时必须升级技术决策，是否坚持标准技术栈；一致行动则把政策变成具体变化，例如调整团队能力、设立测试稳定性投入、改造技术评审流程、规定发布和技术变更的沟通渠道。很多组织以为没有工程策略，其实只是策略没有写下来，隐藏在高管和团队的日常决策里。把它写清楚的价值，是让每个人知道哪些事情优先、哪些 trade-off 已经被接受、遇到争议时该如何推进。策略只有能改变行动，才算真的存在。