ARTICLE · 1103132
AI能写代码了,为什么软件质量却没有提升?
AI加快代码生成，为什么不一定带来更好的软件？a16z这期播客的节目简介提出了一个区别：加快软件的编写，与改变软件运行时能做的判断，是两件事。标题中的疑问并不等于软件质量没有提升的统计结论；现有节目简介也没有提供这样的行业测量。
节目将TypeSafe AI的Jev描述为把智能放进软件运行过程，让程序判断意图并作出概率性决策，而不只是生成文字供人解释。TypeSafe AI官网进一步将其定位为接收结构化问题、返回类型化决策及置信度的模型，开发者可以组合这些判断，并设置自动执行或转交复核的阈值。这说明了产品想解决什么问题，不等于已经证明接入后的软件更可靠。
例如可以把“伙伴听懂玩家的撤退指令”作为测试任务。代码助手可以帮助编写解析、状态转换和测试代码；运行时模型则在玩家发出指令时参与选择行为。前者可能缩短实现时间，后者可能扩大可处理的表达范围，但两者都要检验伙伴是否及时撤离、是否误解指令，以及修复错误需要多少工作。
三种速度要分开
开发速度指需求实现并通过测试所需的时间；单次推理延迟指一次模型请求多久返回；闭环决策频率指系统每秒完成多少次“读取状态、判断、执行、接收反馈”。它们分别影响制作周期、响应等待和行为更新，不能合并成一个加速倍数。
例如，假设一次完整模型请求耗时100毫秒，串行调用在不计其他开销时，每秒最多完成约10次请求。状态提取、动作执行与反馈等待还会占用时间。增加并发可以提高总吞吐量，却不能让依赖上一次动作结果的下一次判断提前获得反馈；对旧状态的快速回答，也可能已经不适合执行。
在游戏Harness——负责组织状态输入、模型调用和动作执行的外围程序——中，可以让确定性逻辑承担坐标转换、寻路、技能合法性检查、冷却计算和按键映射。模型则尝试处理语义边界较模糊的选择，例如玩家说“先别惹事”时，伙伴应保持跟随、躲避敌人，还是允许自卫。这是可测试的架构方案，不是Jev已有游戏表现的证明。
对于大量NPC，可以按事件触发语义判断，或让模型选择短期目标，再由本地逻辑持续执行。代价是目标更新不如逐次调用及时；收益是否成立，要看减少调用后，伙伴对新指令和危险变化的响应是否仍达标。如果每个动作都有明确规则，增加模型反而会新增等待、调用费用和故障点。
替换节点而非骨架
简单巡逻、发现敌人、进入攻击距离后出手，这类规则明确、结果容易验收的行为，可以先用状态机表达。行为树可以组织可复用的条件与动作，通过优先级、顺序和中断规则控制执行。两者都能制作复杂行为，也便于追踪触发路径，但条件相互依赖增加后，维护与调试并不会自动保持简单，不能概括为“零灵活性”或“完全容易解释”。
如果采用Jev类方案，可以保留巡逻、警戒、战斗、撤退等状态，只替换某个转移条件或打分节点。例如可以先由代码排除没有路径的撤退点，再让模型根据队友处境和玩家指令，从剩余选项中选择。这样可能减少模糊语义的规则枚举，却不会免除状态定义、动作实现、优先级冲突、中断处理和异常恢复。
需求经常改变时，自然语言描述值得试验，但改一句话不等于完成一次修改。把“保护玩家”改为“优先保护受伤队友”，可能同时影响跟随距离、目标选择和撤退时机。应比较各方案从修改到回归测试通过的总工时，而不只比较编辑提示词与编辑代码的时间。置信度能记录模型有多确信，不能直接解释它为何忽略某个战术条件。
强化学习则需要围绕环境交互和奖励构建训练过程。如果有可批量运行的模拟环境、明确的表现指标，并且需要优化复杂操作策略，它值得参与比较。代价包括环境搭建、奖励设计、采样与评估；需求变化后是否需要重新训练、运行时推理有多快，都取决于具体策略和部署条件，不能统一写成“修改必然耗时数周”或“推理都是微秒级”。
竞技对抗也不必默认选择强化学习。可以让脚本、搜索、效用评分和学习策略在相同对手与资源限制下竞争，再比较胜率、响应时间和维护成本。若目标是制作Boss，还要单独验收攻击提示是否清晰、难度是否可控、是否保留反制空间；最高胜率不等于最合适的游戏体验。
可靠性靠约束验证
语言意图驱动的NPC适合做局部试验：候选动作有限，输入含有难以直接写成条件的玩家表达，需求又经常调整。例如可以测试“别主动攻击，但受到攻击可以还手”的不同说法，看伙伴能否区分主动挑衅与自卫。如果几条规则已经覆盖需求，模型带来的接入和验证工作可能超过节省的条件维护。
自动化QA也要区分检查对象。金币数、任务标记、按钮可点击性可以直接用程序断言；“任务描述是否与实际进度矛盾”可以试验语义判断。应使用一组已标注的正常与异常案例，比较漏报、误报和人工复核时间。若测试依赖画面理解，还需另行确认输入能力，不能从“决策模型”推导出视觉检测能力；更不能让模型自己的判断成为唯一验收依据。
类型化输出只说明结果能被程序接收，不保证选出的动作正确。高置信度也要在游戏自己的测试集上校验：例如可以把置信度接近0.9的判断分为一组，检查其中正确判断是否接近九成，并继续检查高风险场景是否偏离。官网关于校准置信度的描述，不能替代这种项目内验证，更不能据此承诺零错误。
例如可以为伙伴行为设置超时回退：请求超过本次决策预算，就执行预设安全行为；低置信度时采用保守策略，或向玩家确认。代码在执行前仍须检查目标、资源、路径和权限，丢弃过期回答，并对消耗稀缺道具、改变任务分支等难以撤销的动作增加确认门槛。代价是伙伴可能变得保守或打断玩家，因此还要记录回退频率与确认次数，不能只看最终是否完成任务。
用同一任务核账
要验证取舍，可以选“伙伴保护指定目标并完成撤离”这一任务，统一游戏版本、可见状态、合法动作、成功条件、难度和随机种子集合，再固定并发量与目标决策频率。状态机、行为树、强化学习和模型节点方案应遵守相同的路径与技能约束，不能让一个读取完整世界状态，另一个只能读取局部信息。达不到目标频率的方案应记为未达标，而不是悄悄降低负载。
测量应覆盖完整闭环的平均延迟和P95、P99尾延迟，即95%、99%的样本不超过的耗时，同时记录超时、非法动作、任务失败和回退次数。重复运行时，要区分自主完成与回退接管后完成。平均响应足够快，仍可能被少数长等待打断战斗节奏；只报告成功样本会掩盖这个问题。
总成本要同时核算API、计算资源、必要训练、日志与人工维护，并区分一次性投入和持续运行支出。再安排一次需求修改实验，把“保护玩家”改为“保护指定目标”，记录修改、调试、回归测试工时及新增失败。这样才能看出模型减少的规则编写，是否被额外验证和故障处理抵消。
性能宣传也必须核对分母。TypeSafe AI官网展示“193.6倍更快、444.6倍更便宜”，注明针对其所称的System One任务工作流；同页另一个展示给出0.114秒与8.566秒、0.000081美元与0.013880美元。按这组数分别相除，耗时比约75.1倍、费用比约171.4倍，并非前述倍数。它们可能对应不同测试，但在测试集、模型版本、输入规模与统计方法明确前，不能拼成同一结论，更不能换算成游戏帧率或相对行为树的优势。
官网标示输入价格为每十亿token42美元，折合每百万token 0.042美元。这只能说明所展示的输入单价，不能单凭它确认输出免费或完整运行成本。核算时还要记录价格适用时间、实际输入量、重试、辅助模型和其他收费项目。
关于《宝可梦 红》37小时40分钟通关、16,150次决策、1.65美元费用，以及《DOOM》10Hz决策的说法，现有节目简介和官网正文没有提供原始实验记录，不能据此认定已验证。应取得带时间戳的调用日志、账单、游戏版本、通关判据，以及寻路、辅助规划和人工修正记录，再分别核对墙钟耗时、模型等待时间与有效决策数。
即使暂按上述通关数字作算术检查，37小时40分钟等于135,600秒，16,150次决策摊到全程约为每秒0.119次，即约每8.4秒一次；这不等于单次推理耗时，也不能证明10Hz闭环能力。一次通关可以展示系统做成了什么，但只有重复任务中的失败率、尾延迟、接管比例和总成本，才能支持是否适合上线的判断。
📰 原文（a16z Podcast）：https://a16z.simplecast.com/episodes/ai-can-write-code-why-isnt-software-better-je38wEkC
