从更强模型到可交付系统：近期 AI 探索杂记

前言

这段时间对 AI 的探索，有一点越来越明确：

模型变强以后，真正值得重做的不是某一个工具，而是一整套工作方式。

过去我们很容易把 AI 理解成一个更聪明的问答入口，或者一个更快的代码生成器。但最近几轮实践下来，我更愿意把它看成一种新的组织能力：它要进入需求、设计、开发、审查、交付、运营和复盘，并在这些环节里持续留下可复用的经验。

所以这篇不写成一篇严密论文，而是一组近期实践杂记。主题可以概括为一句话：

AI 的价值，不是更会回答，而是能否进入业务闭环，成为一个可治理、可验收、可持续进化的系统能力。

AI 2.0 开发流程操作系统总览

1. 提示词不只是写得更长，而是逼 AI 进入审查状态

最近我开始在提示词里反复加两句话：

• 从第一性原理出发。
• 开启对抗式审查。

这两句话看起来很普通，但它们对 AI 的工作方式有明显影响。

“从第一性原理出发”不是让 AI 讲哲学，而是让它先拆问题：目标是什么，约束是什么，哪些假设不能直接接受，最小可行路径是什么。它会减少很多“顺着用户话头往下编”的回答。

“开启对抗式审查”则是让 AI 不只完成任务，还要主动找漏洞。比如方案里有没有缺少验收标准，流程里有没有责任断点，设计里有没有被忽略的异常场景，代码里有没有长期维护风险。

很多人在面对 AI 能力提升时，第一反应不是制定理性计划，而是先勉强应付。人在快速变化和复杂问题面前，本来就容易这样做。越是这样，越需要把审查机制写进工作流里，让 AI 帮我们把“看起来能跑”推进到“经得起追问”。

2. Vibe Coding 很快，但真实交付需要闭环

过去一两年，Vibe Coding 这个词很火。它代表了一种轻量、快速的开发方式：我有一个想法，就和 AI 聊，生成一版代码，跑一下，不对再改，直到结果看起来能用。

这种方式对个人原型很有效，但它不是企业级交付的完整答案。

真实世界里的开发，Coding 只是其中一段。企业真正需要的是长期稳定、可维护、可运行的系统。软件工程本质上是一种平衡：既要满足业务目标，也要控制复杂度；既要快，也要稳；既要看到局部效率，也要关心全局可维护性。

模型变强以后，我更关注的是开发流程怎么重做。

模型变强后，开发流程从重流程走向 AI 2.0 轻流程

这张图里有一个关键变化：过去是“人写步骤，AI 执行”；现在更像是“人定目标，AI 规划，AI 执行，AI 审查，AI 迭代”。

这并不意味着人退出流程。相反，人要更清楚地定义目标、验收标准和边界。AI 可以负责循环，但人必须负责判断什么算完成，什么不能越界，什么风险需要升级。

如果没有这些规则，AI 开发很容易变成更快的混乱。如果这些规则被沉淀下来，AI 才可能真正把开发流程产品化、系统化、可复制。

3. claude-fable-5 浅尝

7 月 4 日这次实践给了我一个很直观的体感：用 Claude Fable 5 跑一个明确需求，从理解、规划、生成、审查到调整，大概 1 个小时花了 50 美元左右。

Claude Fable 5 支撑 1 小时需求开发的成本记录

这个数字单独看不便宜，但它把问题变得更清楚了：如果这 50 美元换来的是一个可验收的需求增量，节省的是一名工程师数小时甚至一天的反复沟通、编码和修改，那么它就不再只是“模型调用费”，而是一笔可以被评估的交付成本。

所以成本数据不能只给技术人员看。单次调用多少钱，缓存命中多少，输入输出 Token 怎么变化，某个任务跑一次大概消耗多少预算，这些都会影响产品能不能被买单。

当一次复杂任务的模型调用成本能被清楚记录时，AI 实践就开始进入经营语言：这件事花了多少钱，替代了多少人工时间，产出了什么结果，是否值得自动化，能不能规模化复制。

这一步很关键。因为企业买 AI，从来不是为“它很聪明”付钱，而是为“它能稳定减少某类成本、提升某类结果、承担某类流程”付钱。

4. 团队使用要看总账，也要看性价比

单次调用成本能帮助我们理解某个任务的颗粒度，但真正运营起来，还要看总账。

团队 6 月 DeepSeek 用量与消费趋势

6 月份团队在 DeepSeek 上的调用已经不是偶发试用，而是进入了比较高频的日常使用。请求次数、Token 量和月度开销都能看到明显增长，但整体费用仍然处在可接受范围内。

这也是 DeepSeek 这类模型在团队场景里的价值：它不一定承担所有高难度任务，但可以承接大量高频、标准化、可拆分的工作。比如解释代码、整理材料、生成初稿、做简单审查、辅助分析日志、拆分任务、补充说明文档。

从月度用量看，AI 一旦进入持续工作流，成本形态会明显变化。它不再是偶尔试一次模型，而是每天都在请求、生成、审查、重试、修复和迭代。这个时候，团队需要的不只是最强模型，而是模型组合。

这时候需要关注的就不只是“哪个模型更强”，还包括：

• 哪些任务必须用强模型？
• 哪些任务可以用更便宜的模型？
• 哪些上下文可以缓存？
• 哪些流程可以拆成多阶段？
• 哪些结果需要人工验收？
• 哪些错误会导致重复调用和隐性浪费？

我的体感是，强模型适合打关键战役，性价比模型适合做日常运转。两者配合起来，AI 才不会停留在个人尝鲜，而是能真正进入团队的持续生产。

5. 本体论思考：让 AI 看懂企业里的经营对象

如果想让 AI 真正进入业务，我现在越来越觉得，仅仅把模型接到企业系统上是不够的。

AI 不能只理解语言，还必须理解企业里的经营对象。它要知道客户、合同、项目、订单、库存、任务、风险分别是什么，也要知道这些对象之间是什么关系。

围绕这些对象运转的权限、规则、流程和动作，也必须变成 AI 能理解、能调用、能审查的结构化上下文。否则 AI 面对的就是一个很尴尬的现场：

看得见数据，看不清对象；听得懂问题，听不懂业务。

这就是我最近理解的“企业本体”问题。

企业本体不是传统意义上的文档库，也不是把知识塞进向量库就结束。它更像是一套业务认知模型：定义企业里有哪些核心对象，这些对象有什么属性，彼此是什么关系，会经历哪些状态变化，受哪些规则约束，又能触发哪些动作。

比如同样是“订单”，在销售系统里可能代表成交结果，在交付系统里代表履约任务，在财务系统里代表回款依据，在风控系统里又关联风险等级。如果没有本体层统一语义，AI 很容易在不同系统之间“听懂了词”，但没有真正理解对象。

所以我理解的 AI 原生，不是再加一个聊天框，而是先补一层让 AI 读懂企业的认知底座：

• 对象层：客户、合同、项目、订单、库存、任务、风险。
• 关系层：谁归属谁，谁触发谁，谁约束谁，谁影响谁。
• 状态层：从创建、审批、履约、异常到关闭，每个对象如何流转。
• 规则层：权限、风控、合规、预算、时限、责任边界。
• 动作层：查询、生成、审批、派单、预警、回滚、复盘。

只有这些被结构化之后，AI 才不只是会回答问题，而是能够判断自己面对的是什么业务对象，处在哪个业务环节，应该遵守什么边界，可以调用什么能力，最终把建议转化成可执行动作。

这也是我现在更关心本体论的原因。AI 要进入业务现场，必须先有一套能让它“看清企业”的语义系统。

写在最后

近期这些探索让我越来越确信：AI 的下一步，不只是模型更强，而是系统更稳。

更强的模型可以让我们更快看到可能性，但真正产生价值，还要依赖流程、语义、成本、治理和验收。没有这些底座，AI 很容易停留在演示层面；有了这些底座，它才可能进入业务现场，参与分析、判断、执行与复盘。

所以我现在想解决的，不是让 AI 更会说，而是让 AI：

• 说得准
• 看得清
• 接得住
• 推得动

这可能也是企业 AI 从“工具尝鲜”走向“生产系统”的分水岭。