当每个人都能调用相似的大模型、生成大量代码和快速拼出原型时，产出的数量不再构成稳定优势。真正拉开差距的，是团队能否判断什么值得创造、哪些细节必须保留，以及什么时候应该拒绝一个“技术上可行”的方案。
从上海源创会关于 AI 创新的讨论，到 7 月 25 日在北京继续围绕 Taste 展开交流，这个话题指向了一个正在发生的变化：工具降低了实现成本，却没有替我们回答产品方向、质量标准和价值选择。
AI 扩大的是选择空间，不是判断能力
过去，开发者常常受限于实现成本。一个功能需要几周才能验证，许多想法会在编码之前被放弃。生成式 AI 改变了这个约束：团队可以在一天内得到多个界面、架构草案或交互流程。
但候选方案越多，筛选成本越高。模型可以生成十个“都能运行”的实现，却无法天然知道哪一个更符合真实用户的工作习惯。它也不知道团队更看重响应速度、可解释性、长期维护成本，还是某种难以量化的使用感受。
因此，品味并不只是视觉风格。对工程团队而言，它至少包括三层判断：
- 问题判断：这个需求是否值得解决，还是只因为 AI 能做就去做。
- 取舍判断：面对速度、复杂度、隐私和体验冲突时，什么更重要。
- 完成度判断：代码能够运行之后，哪些边界情况和交互细节仍不能妥协。
AI 能够放大这些判断，也会放大判断的缺失。目标含糊时，更强的生成能力往往只会更快地产生大量平庸选项。
把“我觉得不错”改写成可执行标准
品味包含直觉，但团队协作不能只靠直觉。一个有效做法，是在调用模型之前写出评价量表，并明确哪些条件拥有否决权。
例如，为内部知识助手选择回答方案时，可以定义这些标准：
| 维度 | 要回答的问题 | 是否可以妥协 |
|---|---|---|
| 准确性 | 结论是否有可核查依据 | 不可妥协 |
| 清晰度 | 用户能否迅速找到下一步动作 | 可小幅妥协 |
| 隐私 | 是否泄露内部或个人数据 | 不可妥协 |
| 简洁性 | 是否删除了不影响决策的信息 | 可权衡 |
| 可维护性 | 团队能否理解并修改实现 | 可权衡 |
这里最关键的不是分数，而是先确定边界。隐私不合格的方案不应因为界面漂亮而胜出；缺少证据的回答也不应靠语言流畅掩盖风险。
一个可运行的候选方案评审器
下面是一个可以这样实践的最小示例。它不是来源中披露的官方工具，而是假设团队已经让 AI 生成多个候选方案，再通过统一量表记录人工评审结果。代码使用 Python 标准库，可以直接运行。
将以下内容保存为 review_candidates.py，根据项目修改 WEIGHTS、HARD_GATES 和候选数据：
from dataclasses import dataclass
WEIGHTS = {
"accuracy": 0.35,
"clarity": 0.20,
"privacy": 0.25,
"simplicity": 0.10,
"maintainability": 0.10,
}
# 低于门槛时直接淘汰，避免用总分掩盖关键风险。
HARD_GATES = {
"accuracy": 8,
"privacy": 10,
}
@dataclass
class Candidate:
name: str
scores: dict[str, int]
def rejected_reasons(self) -> list[str]:
return [
f"{key}={self.scores[key]} < {minimum}"
for key, minimum in HARD_GATES.items()
if self.scores.get(key, 0) < minimum
]
def weighted_score(self) -> float:
return sum(self.scores[key] * weight for key, weight in WEIGHTS.items())
candidates = [
Candidate("方案 A：信息完整", {
"accuracy": 9,
"clarity": 7,
"privacy": 10,
"simplicity": 6,
"maintainability": 8,
}),
Candidate("方案 B：表达流畅", {
"accuracy": 7,
"clarity": 10,
"privacy": 10,
"simplicity": 9,
"maintainability": 7,
}),
Candidate("方案 C：结构克制", {
"accuracy": 9,
"clarity": 9,
"privacy": 10,
"simplicity": 9,
"maintainability": 9,
}),
]
accepted = []
for candidate in candidates:
reasons = candidate.rejected_reasons()
if reasons:
print(f"REJECT {candidate.name}: {', '.join(reasons)}")
else:
accepted.append(candidate)
for candidate in sorted(accepted, key=lambda item: item.weighted_score(), reverse=True):
print(f"{candidate.weighted_score():.2f} {candidate.name}")
运行命令：
python review_candidates.py
这个脚本不会自动产生“正确品味”，它只完成两件务实的事：让团队公开权重，并确保底线不会被平均分冲掉。评分仍应由了解用户和业务约束的人完成，还可以为每个分数附上证据、评审人和日期，避免数字制造虚假的客观性。
提示词也应该携带价值选择
只让模型“做一个更好的版本”通常不够。团队可以把目标、非目标和拒绝条件写进提示词，让生成阶段就受到产品判断的约束：
你正在为值班工程师设计故障摘要。
目标：
- 让工程师在 30 秒内判断是否需要升级事故等级。
- 每个结论都必须引用输入材料中的证据。
- 明确区分事实、推断和未知信息。
非目标：
- 不追求覆盖所有日志细节。
- 不生成无法从输入材料验证的根因。
拒绝条件：
- 包含访问令牌、邮箱或其他个人数据。
- 给出结论但没有证据编号。
请生成 3 个结构明显不同的候选版本，并说明各自牺牲了什么。
最后一句尤其重要。要求模型说明“牺牲了什么”，能迫使候选方案暴露取舍，而不是把每个版本都包装成全面最优。
团队如何培养可复用的品味
品味不是在会议上宣布一句“要有品味”，而是在持续选择中形成的。团队采用 AI 工作流时，可以检查以下几项：
- 在生成方案前，是否写清楚用户、场景、非目标和不可突破的边界。
- 评审时，是否同时展示多个候选，而不是接受模型给出的第一个答案。
- 是否保留被拒绝方案及理由，让判断逐渐沉淀为团队资产。
- 是否用真实任务验证体验，而不只看演示是否流畅。
- 是否有人对最终选择负责，而不是把责任归给模型或评分表。
代码会继续变得充裕，生成成本也会继续下降。但更低的实现门槛不会自动带来更好的产品。值得长期建设的能力，是提出有方向的问题、建立清楚的质量边界，并在大量可行答案中认出真正值得交付的那一个。