产品团队的 AI. 产品团队的 AI，意味着在你们自己的产品界面内交付一个用户会采用并持续使用的 AI 功能。不是演示，而是一个背后有留存率数据和客服工单数据支撑的功能。
大多数产品团队已经有了原型。你用一个周末在 Lovable、Bolt 或 v0 里做出来的。在站会上看起来很不错。然后它在通往生产环境的路上卡住了。
差距不在模型。差距在模型周围的一切：流式传输、评测、审计日志，以及在用户本来就在用的产品界面里有一个落脚点。这就是介于 v0 界面和用户真正留下来的功能之间需要完成的工作。
为什么原型会在上线前卡住？
原型回答的是一个问题：模型能完成这件事吗？一个生产功能还需要回答另外四个问题。它能流式传输，让用户不用盯着转圈等待吗？提示词变化时还能保持准确吗？六周后你能证明它告诉了某位客户什么吗？它住在用户本来就工作的地方，而不是在一个单独的标签页里吗？
AI 原型和生产功能有什么区别？
原型证明模型能在演示中完成任务。生产功能还需要增加：流式传输让响应感觉即时；评测套件保证提示词变动时质量不寂静下滑；审计日志让你能证明说过什么；以及内置到产品界面的用户体验让用户真正采用它。原型只是那容易的 20%。
该抜上一个聊天框，还是直接构建到你们的产品界面里？
常见的做法是在角落放一个悬浮聊天气泡。上线很快。但它也会被闲置，因为你的用户来这里不是为了聊天，他们来这里是为了发起付款、核对账单，或者发起争议。
更好的做法是把 AI 放进那件事发生的界面里。表单上的一个智能默认値，交易记录旁边的一键解释，在用户本来就已经打开的面板里呈现的答案。
We are
Stennir 把 AI 构建进你的用户已经在用的产品界面，并预先定义采用率和支持工单两项指标，让你看得出它是否落地。
We aren't
Stennir 不是那种往你的应用上挂一个通用聊天框、然后称之为 AI 功能的团队。
这在受监管的金融科技公司里是什么样子？
举例说明，设想一家 B 轮金融科技公司，用 Lovable 做了一个面向客户的 AI 助手。它在演示里能回答问题，却无法上线生产：没有流式输出，无法衡量质量，也没有受监管产品所需的审计记录。这是一个假设的团队，不是客户。
- 流式传输：响应逐 token 渲染，用户看到答案在形成，而不是盯着加载转圈。
- 评测套件：每次提示词变动时运行一组固定的真实问题，这样当有人编辑系统提示词时，质量不会寂静下滑。
- 审计日志：每一条答案连同其输入一起记录，让受监管的金融科技公司能证明某位客户被告知了什么、什么时候告知的。
- 内置产品界面：助手在用户本来就已经打开的交易视图里回答问题，而不是在单独的聊天标签页里。
处于这种情况的团队会先向一小部分用户开放功能，再逐步扩大。要关注的数字是功能的采用率，以及它所覆盖主题的支持工单数，因为在产品里直接得到答案的用户不会为了提问而开工单。上线前先记下这两项基线，这样变化才可衡量。
原型证明人们想要它。让他们持续使用的，是生产化的工作。工单数量是 CFO 会追问的那个数字。
这样的构建如何确定范围？
我们通过 AI 落地实施来做：代码从第一天起就归你。你已在 v0、Bolt 或 Lovable 里做好的原型保留作为起点。我们带着它走完剩下的路，做成你产品里的一项功能。范围和条款在 30 分钟通话中商定。
如果你想要适合自己团队的模式，面向产品的 AI 页面说明了 AI 在产品中该出现在哪里，而这类项目的范围由 AI 咨询来界定。想在做决定前先看看我们怎么思考？读一读日志，或预约一次 30 分钟摸底通话。
