技术圈最近重新讨论一篇 2015 年的文章：《Choose Boring Technology》。它的观点并不复杂：一家公司的创新预算很有限，每引入一种新技术，就等于消耗一部分“创新积分”。当这些积分被用完，团队就必须面对学习成本、故障排查、招聘困难和长期维护等现实账单。
这套判断在 AI 时代重新变得重要，是因为今天的新工具更多了：新的模型、新的 Agent 框架、新的向量数据库、新的编排平台，以及各种看起来可以立刻改变开发方式的产品。真正困难的问题不是“有没有更先进的技术”，而是“这个系统是否值得承担额外的不确定性”。
“无聊”不是落后，而是可预测
这里的“无聊”并不是拒绝新技术，也不是坚持使用过时的工具。它更接近工程上的“可预测”：
- 团队已经知道它怎样部署、监控和升级。
- 出现故障时，有成熟的排查路径。
- 招聘和交接不会依赖少数专家。
- 社区、文档和第三方工具足够丰富。
- 技术的行为边界已经被大量真实项目验证。
例如，一个团队已经熟悉 PostgreSQL，那么给普通业务增加一个新的数据库，应该回答的就不只是“它是否在某个基准测试中更快”，还包括：谁来维护？备份怎么做？权限怎么管？迁移如何回滚？本地开发是否一致？
“无聊技术”的价值，往往不在演示当天体现，而是在两年后的凌晨故障、人员变动和业务重构中体现。
创新积分应该花在真正改变结果的地方
“每家公司只有大约三个创新积分”可以理解为一种决策模型，而不是精确的数字。它提醒团队：创新不是免费的，技术选择会产生叠加风险。
一个项目同时采用全新的语言、全新的数据库和全新的部署平台，单独看每项选择都可能合理，但组合起来就会产生乘法效应：
总复杂度 ≈ 业务复杂度 × 技术不确定性 × 团队陌生度
因此，创新积分应该优先花在真正能够改变产品结果的地方。例如：
- 新技术是产品核心能力，而不是开发者个人偏好。
- 现有方案已经明确无法满足关键约束。
- 预期收益足以覆盖学习、迁移和运维成本。
- 团队有能力把实验限制在可回滚的范围内。
如果某项技术只是让架构图更时髦，却没有改善延迟、可靠性、成本或交付速度，那么它很可能不值得消耗积分。
AI 项目更需要“无聊的外围”
AI 系统确实带来了新的技术问题：模型调用具有概率性，输出需要评估，提示词会变化，成本会波动，数据安全边界也更加复杂。正因为核心部分已经足够不稳定，外围系统更应该尽量成熟。
一个可实践的组合是：
- 使用成熟的 Web 框架承载 API。
- 使用熟悉的关系型数据库保存用户、任务和审计记录。
- 使用普通队列处理长时间运行的模型任务。
- 把模型、提示词和检索策略封装在清晰的适配层后面。
- 为每次调用记录模型版本、输入摘要、耗时、token 用量和结果状态。
下面是一个最小的 Python 示例。它没有依赖特定的 Agent 框架，而是把模型调用放在一个可以替换的函数后面。实际接入供应商 SDK 时，只需要改造 call_model，业务层仍然保持稳定。
运行前安装依赖：
python -m venv .venv
source .venv/bin/activate
pip install fastapi uvicorn
uvicorn app:app --reload
保存为 app.py：
from typing import Any
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
app = FastAPI()
class AskRequest(BaseModel):
question: str
def call_model(question: str) -> dict[str, Any]:
"""Replace this function with a provider SDK or internal model gateway."""
if not question.strip():
raise ValueError("question must not be empty")
# Keep the provider-specific code behind this boundary.
return {
"answer": f"A model would answer this question: {question}",
"model": "demo-model",
"usage": {"input_tokens": 0, "output_tokens": 0},
}
@app.post("/ask")
def ask(request: AskRequest) -> dict[str, Any]:
try:
result = call_model(request.question)
except ValueError as exc:
raise HTTPException(status_code=400, detail=str(exc)) from exc
return {"ok": True, "result": result}
测试接口：
curl -X POST http://127.0.0.1:8000/ask \
-H 'Content-Type: application/json' \
-d '{"question":"如何设计一个可观测的 AI 服务？"}'
这个例子故意很普通，但它保留了几个关键工程边界：HTTP 层负责协议，业务层负责流程，模型层负责供应商适配。之后无论替换模型、加入重试、增加缓存，还是把同步调用改成队列任务，都不必让整个系统一起变化。
如何判断一项技术是否值得引入
可以在技术评审中固定问下面几组问题：
- 它解决的是当前已经发生的问题，还是一个想象中的未来问题？
- 如果技术明天停止维护，我们能否迁移或接管？
- 团队中有多少人能够独立排查生产故障？
- 它会新增哪些部署、监控、备份和安全工作？
- 失败时能否快速回滚，而不是重写整个系统？
- 这项选择是否与其他新技术叠加，形成不可控的复杂度？
对于 AI 项目，还应增加几项检查：
- 模型输出是否有离线评估集和线上质量指标？
- token 成本和延迟是否可观测？
- 是否能切换模型或供应商？
- 敏感数据是否会被发送到不合适的边界之外？
- 提示词、模型版本和检索配置是否可以审计？
把新技术放进隔离区
并不是所有新技术都应该被拒绝。更稳妥的做法，是先把它放进一个边界清晰的实验区：
- 用独立服务或适配器隔离供应商 API。
- 用小流量或内部用户验证真实收益。
- 明确成功指标和停止条件。
- 保留成熟方案作为降级路径。
- 在正式依赖之前记录迁移和退出方案。
这样做的重点不是降低技术野心，而是控制失败半径。技术实验应该像一笔有上限的投资，而不是悄悄渗透进所有基础设施。
结语：成熟系统需要的是判断力
“选择无聊的技术”真正反对的不是创新，而是把新颖误认为价值。工程团队的目标不是让技术栈看起来先进，而是持续交付可靠的软件，并且在业务变化时保留选择权。
AI 时代当然需要实验，但实验不等于全栈重建。让模型层保持可替换，让数据和任务流程使用团队熟悉的基础设施，让每一项新技术都对应明确收益和退出方案。能把创新限制在值得创新的地方，本身就是一种高级能力。