一句话定义
AI-Powered Software 是一种架构立场：控制流、确定性规则和副作用留在代码里，模型只被用来做窄而类型化的判断。
模型不决定下一步做什么，也不生成给人读的文字。它只回答被明确提出的问题，返回类型化的值、概率分布和置信度，由代码决定怎么用。
与 Agent 的差别是根本性的：Agent 让模型决定流程，AI-Powered Software 让代码决定流程。
为什么重要
它提供了一个被主流叙事挤掉的问题：并非所有 AI 软件都应该是 Agent。
当模型能力持续变强时，「让模型自己决定」看起来总是更省事。但省事的是开发阶段，付出代价的是运行阶段——每一轮循环都是一次偏离目标的机会。
这条路线主张把 AI 限制在一个更小、更可测试的位置上：代码负责确定性的部分，模型只负责需要常识的部分。
根源：输出契约不匹配
语言模型是为给人读而训练的，输出是文本。当消费者变成程序时，你会被迫做三件额外的事：
- 在提示里要求 JSON 输出。
- 解析返回的文本。
- 解析失败就重试。
这条链上的每一步都可能静默失败，而且失败方式不可预测。
有人把这条路线概括为 Machine Native Intelligence：让 AI 具备软件的属性——结构化、可靠、可观测、可测试、快、一致、便宜。它的前提判断是，大规模自动化里绝大多数交互是机器对机器，而不是人对着聊天框。
校准的概率：把不确定性变成可编程的量
这是整套思路里最值得单独拿出来的一点。
**校准（calibration）**指模型给出的概率与真实发生频率一致：被赋予 0.2 的判断，应该在约 20% 的情况下成立。
它带来一个真正的新能力：不确定性从「读起来语气如何」变成了一个可以和阈值比较的数值。 代码终于可以写：
置信度 < 0.5 → 不要猜，转人工
置信度 > 0.9 且低风险 → 自动执行
高风险的破坏性操作 → 即使置信度高也要二次确认在纯文本输出下这件事做不到，因为文本没有可比较的量纲。
最重要的细节：阈值不是单一数字，而是随代价变化。 读操作和不可逆操作的阈值应当不同——这本质上是在把风险容忍度写成代码。
三类问题
这类系统通常只暴露很少几种「问题形状」：
| 问题类型 | 回答空间 | 返回 |
|---|---|---|
| 选择 | 一个选项列表 | 选项 + 概率分布 + 置信度 |
| 打分 | 一个量级（如 0–2） | 分值 + 概率分布 + 置信度 |
| 判定 | 真 / 假 | 0–1 的概率 |
关键在于输出是被约束的：选项空间由你定义，模型无法即兴发挥。这与「让模型自由生成再解析」是两种不同的错误模型。
原子问题，在代码里组合
最重要的一条实践：每个问题只问一件事。
如果需要综合多个因素，就拆成多个独立问题，再用你自己的公式加权。一个具体的对比：
- ❌ 「给这个创业项目打分」
- ✅ 分别问市场规模、技术可行性、差异化，然后按你自己的权重合并
好处是双重的：每个判断都更可靠，而且当优先级变化时，你改的是一个系数，而不是重写一段提示。
这与 Context Engineering 是同一个方向——把判断标准显式化，把权重交还给代码。同时它也顺带解决了长上下文里的一个老问题：多个问题彼此独立评估，一个问题的结论不会变成影响另一个问题的隐藏上下文。
与 Agent、工作流的分工
这不是「谁取代谁」的问题，而是控制流放在哪里的问题：
| 场景 | 更合适的选择 |
|---|---|
| 步骤能事先画出来 | AI Workflows / 本条 |
| 需要常识判断，但流程固定 | 本条（模型做窄判断，代码做路由） |
| 下一步取决于中间结果，且允许出错 | Agent |
| 需要开放式生成或多步推理 | 语言模型 / 推理模型 |
一份相关文档把这个光谱描述为传统软件 / LLM Agent / AI-Powered Software 三分法：第三种是「代码拥有工作流，模型只处理窄判断」。多数真实系统同时用到其中两种以上。
训练目标的分歧
这条路线背后有一个值得认真对待的批评。
主流的后训练路径 RLHF（基于人类反馈的强化学习）优化的是「人更喜欢哪个回答」。它对聊天场景很有效，但当目标变成无人值守的自动化时，这个目标函数会奖励两样不该奖励的东西：
- 谄媚（说用户想听的）
- 自信的幻觉（语气笃定与事实正确由同一个机制产生）
另一个副作用是 mode dropping：模型学会偏好某一种风格，其他可能输出的概率被系统性压低。结果是「读起来可信」和「机器上可信」变成了两个不同的优化目标。
作为对照，可验证奖励（RLVR）能训练出很强的推理模型，但更慢更贵。而报告这条路线的一方能给出的第三条路是 RLCD（Reinforcement Learning for Calibrated Decisions）——直接优化「决策 + 校准概率」。
常见误解
- 「这不就是结构化输出吗」：结构化输出是让文本模型吐 JSON 再解析；这里说的是模型的原生输出就是类型化值，且概率经过校准。差别不在格式，在错误率和可组合性。
- 「置信度高就等于答对了」：校准是关于一组预测的统计性质，不保证单个答案正确。这是整套机制里最容易被误用的一点。
- 「所以 Agent 是错的」：不是。两者适用场景不同，多数系统会同时使用。
- 「换成这种模型就不需要评估了」：恰恰相反。置信度阈值必须用你自己的数据校准，否则那个 0.5 只是猜的。这需要 Evals。
- 「新范式一定更好」：这条路线目前仍很早期，公开实现很少，长期可行性有待验证。它指出的问题是真实的（文本输出与程序消费之间的错配确实存在），但它的答案是否最优，现在下结论太早。
参考
- TypeSafe 文档：Introduction / System One / Confidence / AI Primer（
docs.typesafe.ai，2026-09）——本条目的具体实现案例来自这里，其余为通用工程判断 - Daniel Kahneman, Thinking, Fast and Slow ——「System One」这个名字的来源：快而直觉的判断，与慢而审慎的推理相对