12 Thinking in React

zyan_cn zyan_cn 博客等级 墨衍会员 · AI 创作全网分发 墨衍智能分发 本文由作者通过墨衍一键同步至各平台 1分发平台 100+累计阅读 195平均单平台 已同步平台 优快云 微信公众号 微博 知乎 掘金 百家号 博客园 抖音 小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网 我也要 码龄9年
关注
原创 最新推荐文章于 2026-07-08 12:58:57 发布 195 阅读 AI 写同款· GEO 优化 ›
Claude Opus 4.7 省钱实战：精准控制 thinking tokens 与 effort 级别 Claude Opus 4.7 是一款面向工程化落地的高精度代码大模型，其核心特性在于可计量的 extended thinking 能力——思考过程（thinking phase）与输出内容同等计费。理解这一机制是优化成本的前提：它并非越‘聪明’越贵，而是越‘模糊’越烧钱。通过合理设置 effort 级别、约束 prompt 明确度、限制 MAX_THINKING_TOKENS，并结合上下文跨度与错误代价做决策，开发者可将 thinking tokens 降低 60% 以上。典型场景如语法修正、单文件重构、 阅读详情

Steps to think in React

1. 根据UI划分组件层级

划分示例

  • App
    • SearchBar
    • ProductTable
      • CategoryRow
      • ProductRow

2. 用React创建一个静态版本(渲染UI)

建议:

  • 渲染UI和添加交互过程分开
  • 通过props传入所需数据, 不推荐使用state构建静态版本
    state代表了随时间变化而变化的数据, 应当仅在实现交互时使用
  • 大型项目自下而上开发, 小型项目自上而下开发(先父后子)

3. 确定UI state的最小完整表示(添加交互)

想要UI具备交互能力, 需要触发基础数据改变的能力, React通过state来实现
建议:

  • 只保留应用所需可变state的最小集合, 其他数据均由计算产生

4. 确定state的放置位置

寻找state放置组件的方法:

  • 找到根据该state进行渲染的所有组件(集合A)
  • 找到他们的common owner组件, 在层级上高于所有集合A组件层级
  • 该common owner组件应拥有该state
  • 如果找不到合适位置存放state, 就再创建一个新的父组件来存放state

5. 添加反向数据流

反向数据流用于较低层级组件更新较高层级组件的state
实现方法:

  • 将父组件实施更改local state的函数通过props传递给子组件
    施更改local state的函数通过props传递给子组件
  • 子组件监听用户时间，将props收到的更改函数作为eventHandler
收录于
Main Concepts

当前文章被收录于：

Main Concepts
12 篇文章 0 人学习

根据React官网教程步骤学习整理

订阅专栏 查看详情
标签
#react
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
Claude 3.7 Sonnet深度实测：面向软件开发的Thinking Model工作流 Thinking Model 是新一代大语言模型的关键演进方向，其核心在于显式暴露可观察、可干预的内部推理链路，而非仅输出最终答案。这一架构变革显著提升了模型在代码理解、错误归因与上下文一致性等任务上的可控性与可靠性。结合Software Dev Focus的垂直优化，Claude 3.7 Sonnet在跨文件符号解析、堆栈因果建模和文档-代码双向校验等关键能力上实现突破，使开发者能将AI深度嵌入真实工程流——从单元测试生成、类型安全补全，到IDE级错误三阶归因。本文基于一线开发实践，解析其thinking 阅读详情

相关推荐

GPT-5.5 Thinking与Image 2：智能推理架构与图文协同新范式

大语言模型的‘思考能力’并非简单延长响应时间，而是指具备可控推理链（Chain-of-Thought）、多阶段调度与状态回溯的智能执行机制；其技术价值在于提升逻辑严谨性、降低幻觉风险，并支撑复杂任务的可解释性验证。典型应用场景包括技术方案比选、长文档结构化分析、跨模态需求转化等。GPT-5.5 Thinking正代表这一范式的工程落地，而GPT Image 2则通过空间语义解析与视觉逻辑建模，实现从‘画图工具’到‘视觉思维伙伴’的跃迁——二者共同指向AI从单向输出走向人机协作的新阶段。

weixin_33795806的博客 428

Think in React(官方文档)翻译

原文链接 https://facebook.github.io/react/docs/thinking-in-react.html 文章是以第一人称写的，所以少部分内容读起来比较奇怪，但是结构很清晰，适合初学者理解。翻译水平不够，欢迎大佬指导（可以对照原文和原文中的代码）。 正文开始： React是我们构建性能良好的大型webapp的首选，它目前在我们的facebook和

HaveALookLook的博客 608

Codex CLI 配置深度指南：从 thinking_strength 到 model_catalog

代码大模型本地化集成是现代开发者提效的关键路径，其核心在于将 LLM 的代码理解与生成能力，以低延迟、高可控方式嵌入日常开发流。原理上依赖模型能力分层（如 GPT-5.5/GPT-5.4 代称体系）、上下文精准裁剪与可配置的推理深度控制。技术价值体现在告别黑盒 API 调用，实现本地化、可审计、可复现的智能协作者。典型应用场景包括遗留代码重构、跨语言绑定生成、安全敏感模块自动加固等。本文聚焦 Codex CLI 这一代表性工具，深入解析其配置本质——尤其是 thinking_strength 推理强度调控机

weixin_34405354的博客 443

Thinking in React（翻译）

以下是React官方文档中的Thinking inReact文章的翻译，第一次翻译英文的文章，肯定有很多不正确的地方，还望多多包涵。 原文地址：https://facebook.github.io/react/docs/thinking-in-react.html 原文开始 ---------------------------------------------------------

win0032的博客 4454

Qwen3-Max-Thinking与Kimi K2.5：大模型原生工作流的双引擎范式

大语言模型正从‘文本生成工具’迈向‘可编程思考基础设施’，其核心演进体现在显式推理链构建与跨模态语义对齐两大技术路线上。Qwen3-Max-Thinking通过三层架构——显式推理链生成、中间状态持久化缓存、多路径自我校验——实现了推理过程的可解释、可审计、可复用；Kimi K2.5则突破传统多模态拼接局限，依托统一语义空间映射，在PDF深度解析、图文联合推理等真实业务场景中达成专业级语义理解。二者协同并非能力叠加，而是分工重构：前者担当工作流编排与思考协议设计，后者作为垂直领域专家模块按需调用。这一范式转

weixin_33700350的博客 397

Kimi-K2.5-Thinking在软件开发中的实操能力评估

软件开发中的人工智能助手，核心价值不在于参数榜单，而在于能否稳定支撑真实编码场景。从代码生成、错误诊断到Agent协同，AI模型需具备高指令遵循能力、上下文理解深度与输出一致性——这直接决定开发者‘思维流’的连续性与工程落地效率。Kimi-K2.5-Thinking凭借71.3%准确率与显著降低的Token消耗，在React组件生成、FastAPI逻辑补全、Python异常定位等典型任务中展现出强专业语境适配性；其非全能但高容忍的特性，使其成为Vibe Coding与中小型AI原生应用构建中可信赖的‘超级结

cuemes08808的博客 437

React中文文档之Thinking in React

Thinking in React - 思考React 在我们看来，React是使用js来创建大的、速度快的web应用的首选方式。它已经在Facebook和Instagram表现的非常好。 React众多伟大部分之一是：创建应用时，它是如何让你思考的。在这个文档中，我们将带领你穿越，使用React来构建搜索产品数据表的整个思维过程 Start With A Mock - 以一个模拟开

beyond__devil的博客 1962

Kimi模型代际切换：从thinking模式到原生推理的实战迁移指南

大语言模型API的代际升级已从功能迭代演变为架构范式变革。当传统‘能力开关’式设计（如显式thinking_options）被深度集成的原生推理能力取代，开发者面临的不仅是接口更换，更是上下文管理、错误处理与多模态交互逻辑的全面重构。Kimi K2.6+系列通过256k动态上下文、结构化错误反馈和统一多模态输入，显著提升代码理解、技术文档分析与跨模态诊断能力；而K2.7 Code进一步聚焦开发者工作流，在AST级项目拓扑识别、编辑器级低延迟补全及LSP原生集成上实现质变。本文基于真实断代事件，解析模型下线背

cihongmo6452的博客 412

为你定制的 React 学习路线

本文为掘金投稿，译文出自：掘金翻译计划 原文链接：Your Timeline for Learning React 原文作者：DAVE CEDDIA，感谢作者对本篇文章的翻译授权。 译者：aleen42 校对者：llp0574, jiaowoyongqi 欢迎技术投稿、约稿，给文章纠错，请发送邮件至tangxy@youkuaiyun.com。 以下所谈及的，就是为你定制的...

历史上的今天 1181

Grok 4.1国内合规接入与Thinking模式实战指南

大语言模型（LLM）作为当前AI应用的核心底座，其推理能力、响应稳定性与本地化适配能力直接决定工程落地效果。Grok 4.1凭借双路径推理引擎与显式思维链输出，在多步逻辑推演、上下文感知和中文场景理解上展现出显著技术优势；其Thinking模式并非功能噱头，而是通过动态激活深度推理路径，实现从‘答案生成’到‘决策过程可审计’的范式升级。该能力在文案创作、代码审查、技术方案论证等真实工作流中已验证可降低30%以上人工返工率，并支持与WebAssembly、Python沙箱、跨平台API编排等工程环境深度协同。

weixin_30715523的博客 570

零基础手写ReAct Agent：从LLMClient到Mini Claude Code组装实战

ReAct（Reasoning + Acting）是一种将大语言模型推理与工具调用深度结合的智能体范式，其核心在于显式建模‘思考→行动→观察’闭环。理解ReAct不仅需要掌握prompt工程原理，更需厘清LLMClient协议抽象、agent状态机设计、安全工具执行等关键技术价值。它广泛应用于代码助手、自动化运维、低代码集成等场景，是当前AI工程落地的关键路径。本文聚焦零基础可复现的轻量级实现，通过手写agent.py和LLMClient解耦设计，深入剖析ReAct Prompt黄金三段式、token精算策

weixin_34414196的博客 317

Sequential Thinking：AI深度思考的新范式及其与CoT、ReAct的对比分析

随着AI技术从简单的模式识别迈向复杂的认知推理，CoT、ReAct和Sequential Thinking共同构成了当前AI深度思考的技术谱系。这三种技术虽然诞生于不同发展阶段，但本质上都在解决同一个核心问题：如何让AI像人类一样进行结构化、持续性的思考。它们的协同演进正在重塑人机协作的边界，为各行业带来前所未有的智能升级机遇。从技术发展轨迹来看，这三种方法呈现出明显的互补性。

zuiyuelong的博客 3770

DeepSeek V4技术解析：MoE架构、1M上下文与Thinking Mode实战

大语言模型的长上下文处理、推理可靠性与部署效率，是当前Agent工程落地的核心瓶颈。Transformer架构在扩展至百万级token时面临显存爆炸、注意力计算复杂度剧增和逻辑断层等根本性挑战。DeepSeek V4通过三重创新破局：基于动态Top-K路由的稀疏MoE架构实现算力精准调度；融合Token-wise压缩与DSA（DeepSeek Sparse Attention）的双引擎长文本建模，使1M上下文真正可用；以及内嵌可验证的Thinking Mode状态机，将多步反思能力原生集成于单次前向传播。这

cixu3288的博客 403

深度解析Thinking-Claude：让AI思维过程完全可视化的Chrome扩展实战指南

在AI交互日益普及的今天，我们往往只能看到模型的最终输出，却无法窥见其思考过程。Thinking-Claude Chrome扩展通过创新的可视化技术，让Claude AI的思维过程变得透明可读，为技术爱好者和AI研究者提供了前所未有的洞察力。这个开源项目不仅提升了AI交互的透明度，更让用户能够理解模型如何逐步推理并形成最终答案。 ## 场景一：为什么需要AI思维可视化？ ### 技术痛点与解决

gitblog_00110的博客 433

Claude Opus 4.7深度实测：Tokenizer升级、Adaptive Thinking与API工程化落地

大型语言模型的推理能力正从‘黑箱生成’迈向‘可验证协作’，其核心支撑在于底层tokenizer语义建模精度与adaptive thinking（自适应思维）机制的工程化实现。现代AI系统不再仅依赖参数规模，而是通过细粒度token切分（如中文语义单元、代码符号独立编码）、三阶段推理流程（Planning→Reasoning→Verification）及跨模态联合建模，显著提升技术文档解析、API契约生成与代码静态验证等任务的可靠性。这类能力已广泛应用于OpenAPI规范生成、TypeScript SDK自动

weixin_34314962的博客 433

python cartopy绘制扇形区域图/cartopy绘制北极部分区域

实际上，这个问题原因还是由于投影转换的问题，在set_extend时，绘制的上下边界仍然是方形、未被正确投影的边界，与我们的set_boundary存在冲突，最根本的原因还是在于cartopy对于投影计算的一些缺陷。另外我们需要指出的是：**该方法不适用于极地投影，即NorthPolarStereo，由于NorthPolarStereo本身投影特性只需一个参数，本身并不适合。我们绘制极地投影时，同样也是使用set_boundary绘制圆形边界，那么当我们想要绘制扇形时，可以通过。请根据喜好自行选择，

weixin_43750300的博客 3212

AI推理革命：从Sequential Thinking到Agentic AI的演进之路——揭秘大语言模型思维进化的四重奏

想象一下，当你在解决一个复杂的数学题时，你不会直接给出答案，而是会在草稿纸上一步步地推导。这就是序列化思维的本质——将复杂问题分解为一系列有序的步骤。在传统的大语言模型中，AI往往像一个"直觉型天才"，能够直接给出答案，但却无法解释推理过程。这就像一个学生告诉你"答案是42"，但却说不出为什么是42一样。Sequential Thinking的出现，让AI开始学会"慢思考"。# 传统模式：直接回答return model.generate(question) # 直接输出最终答案。

许泽宇的技术分享 2494

3、保险行业商业智能解决方案的理解与实施

本文详细探讨了商业智能（BI）在保险行业的应用与实施策略，涵盖了从BI环境开发的关键步骤、自下而上与自上而下的数据仓库开发方法，到决策支持工具的选择与使用。文章还分析了BI系统与互联网、内联网和外联网的结合方式，并讨论了购买与自建方案的优劣比较，最后总结了商业智能成功的关键因素及其对保险行业带来的商业价值。通过实际案例与未来趋势展望，展示了商业智能如何推动保险企业的数字化转型和竞争力提升。

moon9的博客 96

ReAct工程实践：从协议设计到可落地的Agent控制器

ReAct（Reasoning + Acting）是一种面向可控执行的AI代理运行时协议，其核心在于将大模型的推理过程与外部动作解耦，通过结构化输出、状态机驱动和工具调用闭环，解决传统Chain模式中任务偏航、错误不可逆、多步崩溃等工程痛点。它不依赖特定模型，而是定义Thought/Action/Action Input三段式交互契约，强调实时观测反馈与深度可控性，广泛应用于金融风控、智能客服、工业诊断等需强确定性的生产场景。本文聚焦ReAct的协议本质、状态机实现与200行可运行控制器，覆盖格式校验、动作

weixin_30823001的博客 340

uniapp：APP报错Error: Not Found：Page[2][-1,1；-1,1,0,0,2-0] at view.umd.min.js:1（uniApp安卓苹果ios出现一大堆数字错误）

Error: Not Found：Page[2][一串数字] at view.umd.min.js:1，uniapp在APP端运行报错Error: Not Found：Page[2][-1,1；-1,1,0,0,2-0] at view.umd.min.js:1，uniapp真机运行偶尔出现Not Found:Page[2][-1,28] at view.umd.min.js:1，如何解决uniApp app报错：Not found -1,71 at view.umd.min.js:1，uniapp项目在H

✅ 精选推荐文章 3983

基于 Arduino 的鱼缸水质检测控制系统设计

本系统通过多传感器实时采集鱼缸水质参数（pH 值、温度、溶解氧、浊度），经 Arduino 主控芯片处理后，驱动执行模块自动调节水质，并通过显示模块实时展示数据。系统具备阈值报警、自动换水、温度调节、增氧等功能，适用于家庭或小型水族箱的水质智能管理。本设计提供了低成本、易扩展的鱼缸水质管理方案，适用于家庭水族箱或小型水产养殖场景，可根据实际需求调整传感器类型和控制逻辑。注：本设计如有疑问需要解惑可直接私信本人，看我个人简介。

weixin_42300449的博客 1086

OLLAMA部署本地大模型新标杆：LFM2.5-1.2B-Thinking支持ReAct与Tool Calling

本文介绍了如何在星图GPU平台上自动化部署【ollama】LFM2.5-1.2B-Thinking镜像，快速搭建本地AI助手。该模型专为边缘计算优化，支持ReAct思维链与工具调用，可应用于本地编程辅助、逻辑推理及文本生成等场景，实现高效、私密的AI交互。

weixin_32836713的博客 407

开源机器人库orocos KDL 学习笔记（二）：Geometric

开源机器人库orocos KDL 学习笔记二：Geometric 如果按照上一篇搭建的VS2015 orocos KDL环境，会出现3个例程：geometry, chainiksolverpos_lma_demo, trajectory_example. 这一篇看一下geometry的例程。 在frames.hpp中，定义了这些class: - class Vector - class R

行者无疆的博客 6703
上一篇： 11 Component Composition
下一篇： 02 Code-Splitting
点赞 0
评论 0
书签 书签 0
zyan_cn
zyan_cn
博客等级 码龄9年 4粉丝 39原创
+ 关注 专栏目录 订阅专栏
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值