Product Engineering

8 篇内容

技术文章知乎 - 鹅厂架构师

能 1 小时用 AI 做出产品了,能 1 小时让 500 人用上吗?

文章系统探讨了AI大幅降低产品开发门槛后,如何高效将产品分发给用户。作者回顾了App Store和抖音的历史,指出每次创作平权后稀缺性从“创造”转向“发现”,而AI时代的分发将不会是传统的应用商店。通过分析OpenAI两次失败的尝试和当前的技术探索,文章提出未来分发平台将形成“部署即服务”“任务即调用”“内容即发现”的三层结构,每一层都在收各自的“过路费”。文章还指出,监管正从管模型转向管分发,对平台加码,而分发本质是信任问题,最可能从已积累信任的内容社区演化出分发能力。结论为:下一个分发平台不会叫应用商店,但会收取以信任和治理为代价的过路费。

推荐收录,因为文章以历史规律和实际案例(OpenAI的失败)为基础,对AI分发这一新兴议题提供了结构化和有借鉴意义的分析。文中提出的三层结构和对信任机制的强调,能为从事AI产品开发、平台设计和投资决策的读者提供长期参考,其分析框架可迁移到类似技术变革期的分发策略思考。

工程实践知乎 - 鹅厂架构师

AI Native Is All You Need

文章通过美团小团、Figma Config 2026 和米哈游 LPM 三个案例,重新审视 AI Native 的产品形态。作者指出,小团以 LUI 接管传统 GUI 交互链路的效率提升并非绝对,某些浏览和比较过程本身就是产品价值;Figma 则保留 Canvas 并借助 AI 将代码、动画和生成能力引入同一创作空间,说明 AI 不应简单取代原有界面;LPM 从实时反应而非视频生成出发,重新定义虚拟角色的互动方式,让 AI 成为游戏世界运行的基础。文章最终提出 AI Native 的核心不在于加入 AI 功能,而在于追问过去基于旧技术限制的产品结构是否仍然必要,以及 AI 带来了哪些新可能。分析主要从产品设计角度展开,较少涉及具体技术实现,适合思考产品架构和交互范式的读者。

文章以清晰的案例分析展示了 AI Native 的多种产品设计路径,从 LUI 接管交互到保留 Canvas 再到从 AI 能力反向定义产品,为从事 AI 相关产品、架构或人机交互设计的读者提供了可迁移的思考框架。虽然缺乏技术实现细节,但它对产品结构、用户需求和历史妥协的反思具有长期参考价值,可帮助避免盲目跟风“AI 化”。

工程实践知乎 - 鹅厂架构师

从智能体开发到日常构建:Harness Engineering思维的跨界思考

文章系统阐述了Harness Engineering(驭缰工程)这一AI时代工程范式,提出“智能体=模型+驭缰系统”核心公式,并拆解了执行运行时、上下文管理、能力层、治理层、可观测性五层生产级架构。作者深入解读了六条源自实战的方法论,包括先磨设计规格文档、优先补齐关键规则、将高频动作下沉为Skill、按认知负载拆分多Agent等,强调了渐进式复杂度管理和约束先行的构建哲学。结合OpenAI、Stripe等案例验证了约束系统对AI应用成功的关键作用,并将该方法论跨界迁移至个人小程序、团队网页协作、Demo原型等日常开发场景,展示了其作为通用构建哲学的潜力。文章以方法论和思维启发为主,对工程实践中的边界设计与增长节奏给出了可操作建议,但缺少底层技术实现细节,更适合中高级开发者或技术管理者作为架构决策参考。

本文不是浮于表面的AI工具介绍,而是从Harness Engineering这一前沿概念出发,提炼出可跨领域迁移的构建哲学。它既有Mitchell Hashimoto等人的原始洞见作为依据,又通过OpenAI、Stripe等业界案例提供了实证支撑,更难得的是将抽象方法论落地到小程序、网页等日常开发中,展示了清晰的迁移路径。适合正在构建复杂系统或希望提升工程思维的技术负责人和开发者阅读,文中‘约束即赋能’、‘按认知负载拆分’等思想能有效指导实际项目中的架构边界与增长节奏控制。

工程实践知乎 - SmartCode 得物技术

从表单到 Agent:得物社区活动搭建的 AI 实践之路

文章复盘了得物社区活动搭建从“AI 帮填表单”演进到“两阶段 Agent + 聚合工作台”的完整过程。第一版只做字段预填,虽然缩短操作时间,但仍需运营在多个系统间手工校验,且存在黑盒等待、不可逆、无持久化等问题。第二版改为以 LangGraph 编排的 Workflow 为主,通过 interrupt/resume、能力注册表和组件模块协议,把运营角色从流程执行者变成流程监督者。第三版进一步把“从想法到策划文档”前移为只读 Skill,把写操作、构建和审核留给受控流程,并用最小权限、渐进式披露和草稿同步降低风险。文章的边界也很清楚:它偏架构与取舍总结,很多细节是面向特定业务场景的工程妥协。

文章给出了从表单辅助到流程驱动 Agent 的真实演进链路,直接包含 LangGraph、interrupt/resume、模块协议和最小权限等可复用设计。适合做企业级 AI 工作流、运营工具和人机协作架构的参考,但需注意其结论强依赖高正确率、强约束业务场景。

工程实践OpenAI Research

Dreaming: Better memory for a more helpful ChatGPT

这篇文章介绍了 ChatGPT 记忆系统从“手动保存记忆”演进到基于后台自动归纳的 dreaming 机制,重点解决记忆陈旧、正确性和规模化成本三个问题。文章还给出了评估记忆质量的三个维度:持续携带上下文、遵循偏好与约束、随时间保持最新,并说明新架构如何通过记忆摘要页让用户查看和管理被合成的记忆。整体上它展示的是一个已经进入产品化部署的 AI 个性化系统设计,而不是单纯的功能宣传,适合作为 AI 工程与产品化记忆系统的参考案例。

推荐收录,因为它把“记忆”从概念层面落到了可评估、可更新、可扩展的系统设计,覆盖了上下文继承、偏好跟随和时间衰减这类真实问题。对做 AI 产品、个性化系统或长上下文状态管理的人来说,这篇文章有较强的迁移价值。

工程实践知乎 - SmartCode 得物技术

BP Claw 破解 AI 编码输入难题 ——FlinkSpec 需求智能化实践|得物技术

文章介绍了得物在实时数仓场景下构建的 BP Claw:一个位于 FlinkSpec 上游的“AI 数据 BP”中间层,用来把产品经理提交的非标 PRD 自动转成 AI Coding 可消费的标准化需求文档。作者重点讲了它如何通过知识库语义召回、需求转化、PRD 质量评分、自动拉群和多 Skill 编排,把“需求口径不清”这个源头问题前置解决,从而降低后续 FlinkSQL 生成、评审和验收阶段的返工。

推荐收录,因为它不是泛泛讲“用 AI 提效”,而是围绕真实的实时数仓开发链路,给出了从需求输入、语义对齐到生成与校验的完整工程方案。文章对 PRD 规范化、幻觉控制、分段生成、质量评分和工作流融合的处理方式具有较强的可迁移价值,适合做 AI 工程化落地参考。

工程实践Yelp Engineering

How Yelp Keeps Server-Driven UI Consistent Across Four Platforms

文章接着前文介绍 Yelp 的 server-driven UI 框架 CHAOS,重点讲它如何与跨平台设计系统 Cookbook 以及自动生成的桥接库 Konbini 协同工作。作者先说明 Yelp 与 Yelp for Business 在 Web、iOS、Android 上存在多套界面变体,导致视觉与交互一致性难以维护。随后描述如何把设计系统组件抽象成可复用的 SDUI 组件,并通过桥接层把同一套定义映射到不同平台渲染实现。文章也讨论了自动生成桥接代码在减少重复劳动、降低差异漂移方面的作用。它更适合已有多端应用和设计系统的团队参考,但前提是组件边界清晰、平台能力差异可被抽象,否则一致性和灵活性仍会冲突。

推荐收录,因为正文直接围绕 CHAOS、Cookbook 和 Konbini 的集成展开,讨论了如何在 Web、iOS、Android 多端保持界面一致,并用自动生成桥接层降低实现分叉。适合做多端产品、设计系统或 SDUI 落地的团队参考;可迁移价值在于组件抽象、跨平台映射和减少重复代码,但也依赖平台差异可被稳定封装。

工程实践Datadog Engineering

How Datadog uses Datadog to gain visibility into the Datadog user experience

文章讲的是 Datadog 的 DesignOps 团队如何把 Datadog 本身用在自己的产品与设计工作中,借助可观测性手段理解用户如何使用产品,并据此做更稳妥的设计决策。作者强调,单靠主观反馈很难看清真实行为,因此需要把用户路径、功能采用率、流失点和关键交互事件纳入可视化分析。文中展示了如何把前端与产品遥测组织成仪表盘、漏斗和趋势观察,从而快速发现体验中的摩擦点,并验证改版是否真的改善了用户行为。文章的核心结论是:可观测性不仅适用于后端故障排查,也能成为产品与设计团队的决策基础。其边界在于,这类指标更擅长描述“发生了什么”,仍需结合定性研究判断“为什么会这样”,并注意埋点质量与隐私约束。

收录价值在于它直接展示了如何把可观测性用于用户体验分析,而不是只用于运维排障。适合做产品工程、DesignOps、埋点分析和体验优化的读者参考,迁移价值在于指标设计、漏斗观察和改版验证的方法。