工程品位概念解析,以及如何提升工程品位 从理论到实践

回复 群友 2236： 结合你刚才说“项目在往 AI slop 方向狂奔”，工程品位可以理解成： 在现实约束下，判断什么值得做、做到什么程度、复杂度应该放在哪里，并对结果负责的能力。 它不是“代码写得漂亮”，也不是“知道很多架构名词”。真正体现品位的，往往是：为什么这里没有引入某个框架，为什么这个功能暂时不做，为什么宁可多写一点代码，也不做一个万能抽象。 一、理论：工程品位到底在判断什么 第一，价值。 先判断问题值不值得解决，再判断方案够不够高级。 比如课程笔记工具，用户真正需要的可能是“关键结论准确，能回到原视频核对”，而不是“同时有五个 Agent 模拟讨论”。 功能多不等于价值高。能识别并删掉没有价值的功能，是工程能力的一部分。 第二，复杂度。 不是代码越少越好，而是理解、修改和排错所需的脑力越少越好。 一个一百行、流程清楚的实现，可能比三十行、依赖多层隐式配置的实现更简单。 John Ousterhout 的《A Philosophy of Software Design》强调管理复杂度。一个很有用的判断是：模块应该把复杂性封装起来，而不是要求调用者先理解它的全部内部机制。 比如调用“生成笔记”，不应该要求调用者自己处理字幕分块、重试、结果拼接和临时文件清理。 第三，边界。 哪些事情应该放在一起，哪些必须分开？ 好的边界通常让一类变化只影响一个地方。比如换转写服务，不应该顺带重写笔记导出逻辑。 但不是拆得越细越好。一个修改需要追着十几个文件才能看懂，说明拆分也可能制造复杂度。 第四，可靠性。 “正常情况下能跑”和“出了问题仍然可控”是两回事。 模型输出不符合要求怎么办？处理到一半失败怎么办？重复提交会不会重复收费？用户怎么知道结果不完整？ 有品位的实现，不一定覆盖所有极端情况，但会优先处理最可能发生、后果最严重的失败。 第五，取舍。 工程不存在脱离情境的最优解。 自己用一次的脚本，与给付费用户长期使用的服务，不需要相同的设计。前者做得过重是浪费，后者缺少必要的保护是失责。 所以，品位不是“永远选择简单方案”，而是“知道哪些复杂度现在值得支付”。 二、为什么懂了这些道理，还是写不出好工程 因为知道原则，不等于有判断能力。 “高内聚低耦合”“不要过度设计”都很容易背，但具体到一个模块，到底该不该拆，仍然需要证据。 品位主要来自一个循环： 做出选择 → 经历修改或失败 → 看见代价 → 调整判断。 只让 AI 连续生成代码，很容易跳过后半段：你拥有了很多实现，却没有积累对这些实现后果的认识。 提升的关键不是拒绝 AI，而是保留自己的预测、比较和验收。 三、实践：直接拿你现在的项目练 第一步，选一条核心链路，不要全面重构。 例如：输入字幕 → 生成笔记 → 核对原文 → 导出。 写清楚这条链路怎样才算可用。不要只写“摘要质量好”，而要具体到：关键结论没有歪曲、不编造原文没有的信息、重要内容能定位到出处。 这一步是在训练价值判断和验收能力。 第二步，亲自跟踪一次真实执行。 看看每一步收到了什么、输出了什么、状态存在哪里、失败怎样传递。 哪个地方你必须问 AI 才知道为什么存在，就先检查那里。它不一定该删，但你需要能解释它承担了什么责任。 这一步是在建立对系统的掌控，而不是追求读懂所有依赖的源码。 第三步，对一个设计做两种方案。 比如： 直接按固定步骤生成笔记。 让多个 Agent 分别提炼、批评、合并笔记。 先写下你的预测：第二种方案准备解决第一种的哪个具体问题？代价是什么？ 然后用同一批真实输入比较。不要用“看上去更全面”做结论，要看错误是否减少、人工修改是否减少，以及耗时和成本是否值得。 如果复杂方案没有明显收益，选择简单方案不是退步，是一次有效判断。 第四步，做一次小规模重构。 只选一个明确的问题：重复的重试逻辑、混在一起的转写与导出、到处散落的模型参数。 先保留能检查原有行为的样例或测试，再改结构。不要同时换框架、改需求和重写整条链路，否则出了问题很难判断原因。 重构后的验收不是“目录更整齐”，而是： 同类修改是否更集中？ 失败是否更容易定位？ 阅读时需要记住的隐含约定是否更少？ 第五步，主动安排一次“变化测试”。 假设现在要换模型、支持另一种字幕格式，或者允许失败后继续处理。 先预测要改哪些地方，再实际改一次。预测之外的连锁修改，就是设计给你的反馈。 这种练习比凭感觉评价架构“优不优雅”更有用。 四、怎么使用 AI，才不会越用越失去品位 让 AI 提供候选方案，不替你决定目标。 让它指出失败路径，不只完成正常流程。 让它解释某个抽象解决了什么实际问题，不接受“方便未来扩展”作为唯一理由。 让它提交小而可验证的修改，不要一次生成一个你无法审查的平台。 尤其注意：不要把同一个 AI 说“实现完成”和“评审通过”，当成独立证据。真正的依据仍然是可运行的检查、真实输入和使用反馈。 五、怎么判断自己在进步 不是看用了多少设计模式，而是看： 动手前，越来越能预测哪里会复杂。 出问题时，越来越快知道该看哪里。 需求变化时，越来越少出现意外的连锁修改。 面对新技术，越来越能说清楚“我现在为什么不用它”。 最后这一点很重要：好的工程品位，不是让每个局部都显得精巧，而是让整个系统少一些不必要的负担。 你现在最值得练的，不是“把项目改得更像大厂”，而是挑一个核心任务，把它做到有价值、能解释、可验证、敢修改。 延伸阅读：围绕复杂度和模块设计，可以看这篇《A Philosophy of Software Design》书评： https://blog.pragmaticengineer.com/a-philosophy-of-software-design-review/