AI 产品经理的系统思维:从种花到构建智能系统 ✍ Christine Zhu🕐 2026-07-23📦 11.3 KB 🟢 已读 𝕏 文章列表 文章阐述了 AI 产品的有机特性,强调系统思维对 AI 产品经理的重要性。核心观点包括:系统行为源于组件交互、结构与规则比参数更具杠杆效应、新演员(Agent)出现时价值流向接口。实践层面建议通过分解产品、定义契约和设计反馈循环,将 Agent 深度融入产品,以建立竞争壁垒。 AI产品系统思维Agent产品设计PM系统架构反馈循环SaaS # What systems thinking looks like for PM'ing AI products **作者**: 𝐂𝐡𝐫𝐢𝐬𝐭𝐢𝐧𝐞 𝐙𝐡𝐮 **日期**: 2026-07-22T13:32:25.000Z **来源**: [https://x.com/christinexzhu/status/2079922517469225362](https://x.com/christinexzhu/status/2079922517469225362) ---  Software is designed, but models are grown, not designed. As such, AI products are organic. PM’ing AI products has an organic nature, akin to growing a garden. It’s more about creating the system for your plants to grow in rather than specifying exactly how an individual plant will look like. (see Alex Komoroske’s Gardening Platforms about platform PM'ing, the same concept applies for all PMs now.) This now makes systems thinking tablestakes for PMs.  ## systems thinking truths Donella Meadows’ Thinking in Systems spelled out a few truths for applying systems thinking in building AI/agents in existing products. I only understood these better after living through building agent systems in a platform PM role. Truth 1. Behavior arise from the interactions between the parts, not the individual parts. A system’s output is the result of how the components connect and interact. You can perfect every individual part and still get a broken whole. The classic PM role (let’s call it the domain PM), especially at a large company, owns a specific scope/product area. By org design (and Conway’s law), every domain PM optimizes for their part. But a product is not its individual part, it's how the parts are assembled to a useful whole. Systems thinking means optimizing the connections between the parts. This matters more with agents because agents don’t know your org chart, they need to act holistically across the product for the user. Truth 2. Structure, rules, information flow have greater leverage than parameters. The places to intervene in a system has a spectrum of leverage. Tweaking parameters has the weakest leverage. Next is changing the structure, the rules, and the information flows. Changing the paradigm has the highest leverage. For example, experimenting with versions of a feature is only parameter level intervention. Designing the contract that many teams can build on is a rule. Traditional product management is often filled with planning parameter tweaks. The higher-leverage systems thinking & product work is building the contracts and new information flows. 3. When there’s a new actor in the system, value goes to the interface. Systems don’t exist on their own. Every system nests inside larger systems and they exchange with each other through interfaces. When agents are added to a product system as a new actor, new value goes to the interface for how the agent communicates with the product surface. For example, the shipping container was the interface for trade. API was the interface for software. MCP is the interface for agents and the tools they use. So what’s the interface for agents to use your product? ## systems thinking in practice Building for the agent is systems work. Every incumbent SaaS is facing the existential question of how to build durable moats when the frontier labs are moving so quickly into their space. Here a few ways to take on a systems thinking lens to more deeply embed AI/agents into products beyond just a bolt-on chat.  ## 1. decompose the product Traditional workflows and UI has always been built for human consumption (so called "UX"). But now the agent enters as a new actor in the product’s system. Most existing products aren’t composed in a way that is easily digestible by agents. New value comes from creating the interface that lets agents understand and act in the product. Let’s call this AX: “agent experience”. It requires thinking from the agent’s perspective, not just the user’s. To make products more usable by agents, a product can be decomposed into a few ingredients: structured context (so agent can “see” what the user sees), typed actions (so agent can know what actions are available to take in the workflow), preconditions and rules for human intervention, and the coordination to know what action to take given the context. Decomposing the product into these common primitives and providing the interface for agents to access them give you a chance to differentiate from the AI labs. Otherwise, you’ll end up with bolt-on “AI features” that don’t perform any better than ChatGPT/Claude etc., and your customers will balk at AI’s disruption to their usual workflows without delivering significant new value. New value can only be realized when agents are deeply wired inside the product and can understand and act in workflows that are already familiar to the customers. ## 2. define the contracts Once the product is decomposed, the parts need a contract (agreement) to specify how they should behave, so different product areas can plug in to get to their agents to perform the desired behaviour. Contrast this from the traditional feature-level PM’ing: building a feature on your product area alone only works on your product area. But a contract defines how a capability can work at a system level, what each component means, the rules by which they can interact, etc. This allows any team or agent to add that capability in their own surface or use case. It makes the capability much more scalable, consistent, and cohesive across the entire product. It’s like the electrical outlet - individual appliance maker don’t have to negotiate with the power company because the outlet gives them the contract. Contract thinking was not always needed for domain product PMs but is required when building agents, since agents need defined preconditions to operate in your product. ## 3. design the loop New features come with a lifespan. But a loop can improve the agent system over time. An example of a valuable loop is capturing the correction signal: the delta between what the agent did and whether the user corrected it. For example, when the user edits the field the agent updated, or accepts the draft but rewrites the last paragraph. Corrections are labeled examples from real usage. The correction signal gives two benefits. One is eval data: signal for where the agent fails in production, which no offline benchmark can. The second is improvement data: corrections improve the agent by preference pairs or past corrections retrieved into context so the agent doesn’t repeat the same mistake. Great AI products are built on these loops. Coding agents track what jobs are accepted, rejected, or edited after accepting. The bonus: this valuable signal is simply a byproduct of normal use of the product that doesn’t require any additional action from the user (unlike a feedback form). Improving the agent with this signal makes it perform uniquely better inside your product on subsequent use, compared to starting cold in generic AI chat products. Features depreciate, systems (with loops) compound. @sierraplatform's newly launched Horizon platform is an example of how a holistic system brings material differentiation for a product. Horizon’s innovation is in the seams, the interface layer that feeds signals, goals, guardrails, and cross-interaction context to agents. It answers the differentiation question that most companies are struggling with: “How can you build a durable moat in your business as frontier AI progresses so rapidly?”?  Sierra’s Horizon platform ## Systems thinking’s velocity advantage Stewart Brand’s “pace layers” explains that buildings work because the things that change fast (furniture, room layouts) aren’t welded to the things that are harder to change (the frame, foundation). The fast layer can change quickly because of the affordances built in the foundation layer that don’t have to change. In software products, you might think decomposing and building contracts and loops sound slower than shipping that new AI feature in the next cycle. It’s the age-old tension between speed and scale. But in the agent era, the features are so much cheaper to build, so read speed actually comes more from investment in the system, the platform. The system level capabilities and contracts are the product thinking that can bring real differentiation in your existing (especially non-AI native) product. One contract allows you to test many variants of an experience in one sprint, and new variants can easily be added as a new surface on the same contract. But if that capability was built on individual surfaces, then each variant needs to re-implement the same plumbing. Platform is now the speed play. ## What now Elizabeth Stone on @lennysan's podcast shared that Netflix is hiring people who can look across the business domains and abstract the building blocks. It previously let local teams build off the paved path to move fast, but agents operating across multiple systems make common paved paths and solving problems once more important. To practice systems thinking, pick a high traffic JTBD area and ask a few Qs: - What would the agent need to see, know, and do at each step to complete this job accurately for the user? What are the structured ingredients it would need? - How can your agent access those ingredients across multiple surfaces? Is your capability attached to your UI surface only or is it interchangeable with other areas of the product or of the customer’s workflow holistically? - How are you capturing unique context from your customers and improving your agent? Software used to be designed. But now, AI products are grown. A great PM/builder acts more like a gardener who creates the conditions, sows the seeds, and tends to what comes up. Don’t stay stuck in the traditional PDLC boundaries of defining the perfect feature and perfect roadmap. Think about the core primitives that make up the system, define contracts and loops, and watch the new organic value that can grow from your system and maybe surprise you. If you want to get these directly in your inbox and see past writings, I also publish on substack. ## 相关链接 - [𝐂𝐡𝐫𝐢𝐬𝐭𝐢𝐧𝐞 𝐙𝐡𝐮](https://x.com/christinexzhu) - [@christinexzhu](https://x.com/christinexzhu) - [7.5K](https://x.com/christinexzhu/status/2079922517469225362/analytics) - [Gardening Platforms](https://docs.google.com/presentation/d/1cY95dRixFho0pMIlrEFcGL_XKVy9vnE4NGOD6TQMj50/view?slide=id.p#slide=id.p) - [Thinking in Systems](https://www.amazon.com/dp/1603580557?ref_=cm_sw_r_ffobk_cp_ud_dp_E7J13DT35A9HX7T3H9JM&bestFormat=true) - [Conway’s law)](https://en.wikipedia.org/wiki/Conway's_law) - [@sierraplatform](https://x.com/@sierraplatform) - [Horizon](https://x.com/btaylor/status/2077767352431882355) - [@lennysan](https://x.com/@lennysan) - [podcast](https://youtu.be/t0GiTyz4syY?si=WryolPc1hJuL6IEy) - [substack](https://christinezhu.substack.com/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [9:32 PM · Jul 22, 2026](https://x.com/christinexzhu/status/2079922517469225362) - [7,527 Views](https://x.com/christinexzhu/status/2079922517469225362/analytics) - [View quotes](https://x.com/christinexzhu/status/2079922517469225362/quotes) --- *导出时间: 2026/7/23 10:56:16* --- ## 中文翻译 # AI 产品经理管理中的系统思维实践 **作者**: 𝐂𝐡𝐫𝐢𝐬𝐭𝐢𝐧𝐞 𝐙𝐡𝐮 **日期**: 2026-07-22T13:32:25.000Z **来源**: [https://x.com/christinexzhu/status/2079922517469225362](https://x.com/christinexzhu/status/2079922517469225362) ---  软件是被设计出来的,而模型是生长出来的,而非设计出来的。因此,AI 产品具有有机性。管理 AI 产品具有一种有机的本质,就像培育一个花园。这更多的是关于为植物的生长创造一个系统环境,而不是精确规定每一株植物长成什么样。(关于平台产品经理管理,请参阅 Alex Komoroske 的《Gardening Platforms》,同样的概念现在适用于所有产品经理。) 这使得系统思维成为产品经理的必备技能。  ## 系统思维的真相 唐内拉·梅多斯在《Thinking in Systems》(系统思维)一书中阐述了几个在现有产品中构建 AI/智能体时应用系统思维的真理。只有在平台产品经理的职位上亲身经历了构建智能体系统之后,我才更好地理解了这些真理。 真理 1. 行为源于部分之间的互动,而非单个部分本身。 系统的输出是其组件连接和交互方式的结果。你可以完善每一个单独的部分,但最终得到的整体仍然是破碎的。传统的产品经理角色(我们称之为领域产品经理),尤其是在大公司,负责特定的范围/产品领域。通过组织设计(以及康威定律),每个领域产品经理都在优化自己负责的部分。但是,产品不是其单个部分的简单叠加,而是各个部分组装成一个有用的整体的方式。系统思维意味着优化各部分之间的连接。这对于智能体来说尤为重要,因为智能体不知道你的组织架构图,它们需要为了用户在整个产品中全面地行动。 真理 2. 结构、规则、信息流比参数具有更高的杠杆作用。 系统中的干预点存在一个杠杆谱系。调整参数的杠杆作用最弱。其次是改变结构、规则和信息流。改变范式具有最高的杠杆作用。例如,测试功能的不同版本只是参数级别的干预。设计一个让许多团队可以基于其构建的契约,则是一种规则。传统的产品管理往往充满了规划参数调整的工作。更高杠杆的系统思维和产品工作是构建契约和新的信息流。 3. 当系统中有一个新的行动者时,价值会流向接口。 系统不会独立存在。每个系统都嵌套在更大的系统中,并通过接口进行交换。当智能体作为新的行动者被添加到产品系统中时,新的价值流向了智能体与产品表面进行通信的接口。例如,集装箱是贸易的接口。API 是软件的接口。MCP 是智能体及其使用的工具之间的接口。那么,智能体使用你的产品的接口是什么? ## 系统思维的实践 为智能体而建是系统性工作。每一家现有的 SaaS 公司都面临着关于如何构建持久护城河的存在性问题,尤其是在前沿实验室如此迅速地进入他们领域的情况下。以下是几种采用系统思维视角的方法,可以将 AI/智能体更深地嵌入到产品中,而不仅仅是作为一个附加的聊天功能。  ## 1. 解构产品 传统的工作流程和 UI 一直是为人设计的(即所谓的“UX”)。但现在,智能体作为产品系统中的一个新行动者进入了。大多数现有产品的组成方式并不易于被智能体消化。新的价值来自于创建一个接口,让智能体能够理解并在产品中采取行动。我们可以称之为 AX:“智能体体验”。这需要从智能体的角度思考,而不仅仅是用户的角度。 为了让产品更易于被智能体使用,产品可以被解构为几个要素:结构化上下文(以便智能体能“看到”用户所看到的)、类型化操作(以便智能体知道在工作流程中可以采取哪些操作)、人工干预的前提条件和规则,以及知道在给定上下文时应采取何种操作的协调机制。 将产品解构为这些通用基元并提供接口供智能体访问,使你有机会区别于 AI 实验室。否则,你最终只会得到附加的“AI 功能”,其表现并不比 ChatGPT/Claude 等更好,而且你的客户会因为 AI 打乱了他们的常规工作流程却未带来显著的新价值而抗拒。只有当智能体深度嵌入产品内部,并且能够理解和执行客户已经熟悉的工作流程时,才能实现新的价值。 ## 2. 定义契约 一旦产品被解构,各个部分就需要一个契约(协议)来规定它们应该如何表现,这样不同的产品领域就可以接入,让他们的智能体执行期望的行为。 将其与传统功能级的产品经理管理进行对比:仅在您的产品领域构建一个功能只能在该领域内起作用。但契约定义了一种能力如何在系统级别工作,每个组件意味着什么,它们可以交互的规则等等。这允许任何团队或智能体在他们自己的界面或用例中添加该能力。这使得该能力在整个产品中更具可扩展性、一致性和内聚性。这就像电源插座——单个家电制造商不需要与电力公司谈判,因为插座为他们提供了契约。对于领域产品经理来说,契约思维并不总是必需的,但在构建智能体时是必须的,因为智能体需要定义的前提条件才能在你的产品中运行。 ## 3. 设计循环 新功能有其生命周期。但循环可以随着时间推移改进智能体系统。一个有价值的循环的例子是捕获修正信号:即智能体所做的事情与用户是否修正了它之间的差异。例如,当用户编辑智能体更新的字段时,或者接受草稿但重写最后一段。修正来自真实使用的标注示例。 修正信号带来两个好处。一个是评估数据:指示智能体在生产环境中失败的信号,这是任何离线基准测试都无法提供的。第二个是改进数据:修正通过偏好对或检索到上下文中的过去修正来改进智能体,这样智能体就不会重复同样的错误。 优秀的 AI 产品就是建立在这些循环之上的。编码智能体会跟踪哪些任务在被接受后遭到拒绝、接受或编辑。额外的好处是:这个有价值的信号仅仅是产品正常使用的副产品,不需要用户采取任何额外行动(不像反馈表)。利用这个信号改进智能体,使其在后续使用中在你的产品内部表现得更独特、更好,相比于在通用 AI 聊天产品中从零开始。功能会贬值,系统(带有循环的)则会复利增长。 @sierraplatform 新推出的 Horizon 平台就是一个整体系统如何为产品带来实质性差异化的例子。Horizon 的创新在于接缝处,即向智能体提供信号、目标、防护栏和跨交互上下文的接口层。它回答了大多数公司都在纠结的差异化问题:“随着前沿 AI 进展如此迅速,你如何在自己的业务中建立持久的护城河?”  Sierra 的 Horizon 平台 ## 系统思维的速度优势 斯图尔特·布兰德的“速度层级”理论解释了建筑物之所以有效,是因为变化快的东西(家具、房间布局)并没有与难以改变的东西(框架、地基)焊接在一起。快速层级之所以能快速变化,是因为基础层中内置的便利设施不需要改变。 在软件产品中,你可能认为解构、构建契约和循环听起来比在下一个周期发布那个新的 AI 功能要慢。这是速度与规模之间永恒的张力。但在智能体时代,构建功能的成本要低得多,因此实际的速度更多来自于对系统、平台的投资。系统级的能力和契约是能够在你现有的(尤其是非 AI 原生的)产品中带来真正差异化的产品思维。一个契约允许你在一个冲刺中测试体验的许多变体,并且新的变体可以很容易地作为同一契约上的新界面添加。但如果该能力是构建在单个界面上的,那么每个变体都需要重新实现相同的底层管道。平台现在是速度的玩法。 ## 现在该怎么做 Elizabeth Stone 在 @lennysan 的播客中分享说,Netflix 正在招聘能够跨越业务领域并抽象出构建模块的人才。它以前允许本地团队在铺设好的路径之外构建以快速移动,但在多个系统上运行的智能体使得通用的铺设路径和一次性解决问题变得更加重要。 要实践系统思维,选择一个高流量的 JTBD(待完成任务)区域并问几个问题: - 为了准确地为用户完成这项工作,智能体在每一步需要看到、知道和做什么?它需要哪些结构化的要素? - 你的智能体如何跨越多个界面访问这些要素?你的能力是仅附属于你的 UI 界面,还是可以与产品的其他领域或客户的整个工作流程互换? - 你如何从客户那里捕获独特的上下文并改进你的智能体? 软件过去是被设计出来的。但现在,AI 产品是生长出来的。一个优秀的产品经理/构建者更像是一个园丁,他创造条件,播种,并照料长出来的东西。不要停留在传统的 PDLC(产品开发生命周期)界限中,即定义完美的功能和完美的路线图。思考构成系统的核心基元,定义契约和循环,并观察从你的系统中生长出来的新的有机价值,它可能会给你带来惊喜。 如果你想直接在收件箱中收到这些内容并查看过去的文章,我也在 substack 上发布。 ## 相关链接 - [𝐂𝐡𝐫𝐢𝐬𝐭𝐢𝐧𝐞 𝐙𝐡𝐮](https://x.com/christinexzhu) - [@christinexzhu](https://x.com/christinexzhu) - [7.5K](https://x.com/christinexzhu/status/2079922517469225362/analytics) - [Gardening Platforms](https://docs.google.com/presentation/d/1cY95dRixFho0pMIlrEFcGL_XKVy9vnE4NGOD6TQMj50/view?slide=id.p#slide=id.p) - [Thinking in Systems](https://www.amazon.com/dp/1603580557?ref_=cm_sw_r_ffobk_cp_ud_dp_E7J13DT35A9HX7T3H9JM&bestFormat=true) - [Conway’s law)](https://en.wikipedia.org/wiki/Conway's_law) - [@sierraplatform](https://x.com/@sierraplatform) - [Horizon](https://x.com/btaylor/status/2077767352431882355) - [@lennysan](https://x.com/@lennysan) - [podcast](https://youtu.be/t0GiTyz4syY?si=WryolPc1hJuL6IEy) - [substack](https://christinezhu.substack.com/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [9:32 PM · Jul 22, 2026](https://x.com/christinexzhu/status/2079922517469225362) - [7,527 Views](https://x.com/christinexzhu/status/2079922517469225362/analytics) - [View quotes](https://x.com/christinexzhu/status/2079922517469225362/quotes) --- *导出时间: 2026/7/23 10:56:16*
A AI Native CLI:一种基于 Skill 的新商业模式 文章探讨了在 AI 时代,基于 Skill 的获客与变现困境。作者指出 Skill 因复制成本低难以单独作为商业模式,而开发外部 App 又面临流量转化损耗。解决方案是采用“AI Native CLI”——一种面向 AI 的命令行接口。它允许在同一容器内通过用户登录鉴权,实现从免费 Skill 到付费解决方案的无缝转化,从而构建完整的商业闭环。 技术 › Agent ✍ 卡颂🕐 2026-07-10 AI商业模式AgentSkillCLI变现SaaS产品设计
纳 纳米Work实测:跨三家大模型制作宣传片 作者体验了纳米Work产品,通过两个真实任务测试其Agent能力。该产品成功调用多家大模型完成了产品宣传片剪辑及文案落地页制作。产品具有全过程透明、支持多模型切换及移动端接管等特点,展示了AI作为工作伙伴的巨大潜力。 技术 › Agent ✍ 花叔🕐 2026-07-29 纳米WorkAgent大模型工作流自动化产品设计视频剪辑AI办公
如 如何设计 AI Agent:思维模型与实体化 文章提出 AI Agent 应被视为“思维与身体”的结合。单纯依赖大模型能力的 Agent 难以体现价值,唯有通过构建包含身份、资产、感知和限制的“身体”结构,将无界的智能具象化,才能解决用户痛点,避免沦为单纯的套壳聊天机器人。 技术 › Agent ✍ Will Chen🕐 2026-07-25 AI Agent产品设计思维模型大模型应用SaaS
O OpenCode 番外篇:驾驭 AI 的法典、军团与薄壳 文章指出 AI 编程的核心不是工具安装,而是建立权力结构与规则。作者通过 AGENTS.md、模型路由、MCP 和 Team Mode 等 OpenCode 机制,阐述如何通过立法、感官建立和验收来驾驭 AI 军团,强调开发者应成为立法者而非单纯的批准按钮。 技术 › OpenCode ✍ AI最严厉的父亲🕐 2026-07-22 AI编程OpenCodeAgent工程方法论模型路由AGENTSMCPTeamMode系统架构技术哲学
H Hermes Agent 大师课程:完整指南 本文是一份关于 Hermes Agent 的 12 部分系列课程汇总,涵盖了从工作流程、学习系统、技能管理到多平台集成、浏览器控制等核心功能,详细介绍了该系统的架构设计与最佳实践。 技术 › Hermes ✍ Tony Simons🕐 2026-07-20 AgentHermesLLM教程系统架构工具集成多代理自动化
A AI 销售陪练怎么做成一门小生意 文章复盘了一款AI语音销售陪练产品的成功案例,详细介绍了如何利用现有工具构建最小可行产品(MVP),包括产品卡、异议卡等核心材料准备。作者建议从四周训练营切入,服务小团队和独立销售,并提供了定价策略、交付注意事项及启动五步法。 技术 › LLM ✍ Christal.Z🕐 2026-07-19 AI销售陪练创业AgentElevenLabs语音交互产品方法论SaaS
读 读 Google Cloud 多租户智能体 AI 系统参考架构 作者分享了阅读 Google Cloud 《多租户智能体 AI 系统》参考架构后的 5 个核心启发。文章指出企业级 Agent 落地需关注中心辐射模式、系统级安全防护(Model Armor)、MCP 的企业级用法以及完整的闭环流程。作者认为单纯依靠 Prompt 的时代即将结束,未来的重点在于系统架构设计与安全边界。 技术 › Agent ✍ lifcc🕐 2026-07-14 Agent多租户GoogleCloud系统架构安全防护MCP工程化
使 使用 Fable 5 构建自我改进 Agent 系统的 14 步指南 文章深入探讨了如何充分利用 Claude Fable 5 的潜能,而非仅仅将其视作上下文窗口更大的 Sonnet。作者提出了构建“自我改进系统”的 14 步路线图,区分了自我学习与自我改进,并详细阐述了基于 Loops、Dynamic Workflows 和 Routines 的三层架构。文章还提供了 Fable 5、Opus 和 Sonnet 在系统中的成本与任务分配策略。 技术 › LLM ✍ Codez🕐 2026-07-09 Fable 5AgentClaude架构设计提示工程工作流自动化自我改进系统架构最佳实践
A AI面试管家系统架构:AI、GitHub、Codex与飞书的四端协同 文章介绍了作者团队研发的「AI面试管家」系统,该系统通过集成AI面试、GitHub资料仓、Codex本地智能和飞书执行层,实现了招聘流程的高度自动化与GitOps化。核心亮点包括将候选人转化为可版本化的数据对象,利用本地Agent保障数据安全边界,以及通过异步任务提升系统的容错与追踪能力。 技术 › Agent ✍ 姚金刚🕐 2026-07-03 Agent招聘自动化GitOps工作流自动化Codex系统架构飞书AI面试
万 万字长文:做了些爆款 Skills 以后,我对 Skills 的看法 本文通过作者制作多个爆款 Skill(如 PPT、社交媒体卡片、Logo 生成等)的实战经验,深入探讨了 Skill 在 AI 时代的本质与价值。作者指出,Skill 不仅是提示词,更是封装专家经验、工作流和审美判断的“能力商品”,能有效弥合 Agent 使用中的认知差距。文章详细阐述了 Skill 的设计哲学(中心短、辐射厚)、像代码一样的维护流程,以及如何通过“把品味变成约束”来保证高质量输出。 技术 › Skill ✍ 歸藏(guizang.ai)🕐 2026-06-12 AgentSkillLLM上下文工程提示词工程产品设计经验封装DevOps交互设计AI应用
使 使用 Fable 5 构建自我改进 Agent 系统的 14 步指南 本文介绍如何利用 Claude Fable 5 模型构建具有复合能力的自我改进 Agent 系统。文章首先澄清了 Fable 5 作为 Mythos 级模型的定位,强调了其支持“长周期自主会话”和“自验证”的核心能力。作者指出,真正的自我改进并非模型权重的更新,而是通过 loops、dynamic workflows 和 routines 这三种原语,构建起包含记忆层和评估反馈层的环境架构。文章还详细阐述了如何根据任务复杂度在 Fable 5、Opus 和 Sonnet 之间进行成本最优的路由配置。 技术 › LLM ✍ Codez🕐 2026-06-12 LLMAgentClaudeFable 5自我改进系统架构工作流Claude Code工程化
读 读《置身钉内》:AI时代企业产品的复盘与反思 本文是对长文《置身钉内》的概括。文章以亲历者视角复盘了钉钉“ONE”产品从立项到搁浅的过程,深入剖析了产品设计中的形式矛盾、用户反馈的陷阱以及极致敏捷管理的副作用。作者指出,AI时代企业产品的关键不在于技术,而在于组织能否慢下来理解真实需求。这是一份关于产品、管理与个人职业的深刻反思。 职场 › 管理 ✍ Mr Panda🕐 2026-06-08 产品复盘钉钉企业管理AI产品职场反思团队管理产品设计