又回到了工程品味了 这个怎么培养 用ca的方案总感觉没法达到自己的想法

回复 群友 2236： 说“工程品味”，容易说得很虚。我把它拆成能练的东西。 第一，品味本质是见得足够多并且能分辨好坏。你只用 ca，最多见过自己的项目有几种写法。所以第一件事不是提高标准，是扩大样本：同一个需求找 3 到 5 个成熟实现，读它们的接口和目录，不要读实现。看它把什么东西藏起来了、什么东西暴露出来，往往比看具体代码有信息量。 第二，养成“负责这个模块的人怎么用”的视角。ca 的方案之所以不达你想法，很多时候不是它写错，而是你能感觉到这里别扭，却没法说出哪里别扭。说得出，就能改；说不出，就只会反复重写。所以每次看到不爽的地方，逼自己写出“我希望这个调用方怎么写一行代码”，再倒推实现。这就是接口先行的训练。 第三，积累自己的坏味道清单。品味是不喜欢的东西越来越多，不是喜欢的东西越来越多。比如：函数同时做两件事、错误吞掉不抛、参数超过四个、状态散落在三处、命名动词名词混用。存成一张清单，ca 出活后拿清单过一遍，比空泛地“感觉不满意”有用得多。 第四，小步改和可回滚。品味只有跑起来才能验证，所有一次给你几百行的方案都必然粗糙。让 ca 一次只改一个切口，你 review 完再下一步。这也顺带训练你提需求时把边界说清楚的能力。 第五，要有对比基准，不能只在脑子里想。你觉得 A 方案好，写个五行的用法示例对比 B 方案，往往就会发现有的想法只是感觉。这个动作做个几十次，判断会稳很多。 最后说 ca 本身：它倾向于产出符合大多数代码的写法，也就是平均品味。所以正确用法是让它做执行，判断和边界由你定。你把第一版接口和目录结构定好，它填实现，这比让它从零设计更接近你想要的东西。 顺带一句，这些其实可以变成你自己的评测集：把每次让你不满意的方案和你的修改存下来，慢慢就是你的 badcase 库，模型再出活你能一眼看出踩没踩老坑。