第一回引言：从“对话”到“推理”的范式转变
传统的LLM应用大多基于“单次问答”或“线性链式（Chains）”模式。在这种模式下，模型如果第一枪没有打中，应用就宣告失败。而在实际工业场景中，我们迫切需要Agent具备像人类一样的反思、推理与迭代纠错能力。
本文将聚焦于如何利用 ReAct 模式、LangGraph 状态机 与 PydanticAI 结构化输出 三大核心技术，从零构建一个具备“自我纠错（Self-Correction）”能力的智能化代码生成 Agent。
一、 核心技术栈深度解析在动手构建复杂系统之前，我们必须先理清底层的技术支柱。一个拥有自主决策能力的 Agent，其大脑由以下三个关键部分构成：
1. 决策范式：ReAct 模式（Reason + Act）传统的 LLM 习惯于直接输出答案，而 ReAct 模式改变了这一习惯。它强制大模型按照 思考（Thought）、 行动（Action）、 观察（Observation）、 再思考 的闭环逻辑运行。
在代码生成场景中，这套模式的映射非常直观：
Thought（思考） ：分析用户的需求，或者分析上一次编译器抛出的报错信息。
Action（行动） ：编写 ...
SPA发版后偶发白屏：场景、根因与治理方案
本文结合具体应用场景，说明我们遇到的在生产环境偶发整页空白的问题：在什么条件下出现、如何定位、项目内已采取哪些措施、以及仍依赖运维侧配合的部分。
1. 现象
用户侧：页面突然白屏或长时间无内容，常发生在发版后的一段时间内，且并非所有用户同时复现。
浏览器开发者工具中常见（可能同时出现多项）：
Failed to load module script：期望加载 JavaScript 模块，响应的 Content-Type 却是 text/html。
Failed to fetch dynamically imported module / Importing a module script failed 等动态 import() 相关错误。
网络面板中：对 .../assets/*.js 的请求返回 404，或返回 200 但正文为 HTML（实为 SPA 回退页）。
另有一条独立但常一起出现在控制台的问题：**413 Request Entity Too Large**（附件上传超过网关或服务端请求体限制）。它不直接导致「JS 白屏」，但会干扰排障，需在文档中区分。
...
从“不存在”的重复请求，聊到 Web 存储的深坑
在 Web 开发中，有些 Bug 的隐蔽性极高，它们往往藏在浏览器的底层机制和复杂的交互链路中。最近我们遇到了一个关于“邀请码重复绑定”的诡异问题，最终溯源发现，这不仅涉及前端的存储选择，还涉及浏览器对网络请求的展示逻辑。
问题背景项目中有个典型的裂变需求：用户 A 分享链接给用户 B，B 点击链接进入站点（URL 携带邀请码），点击登录后调起微信授权，登录成功后前端调用 /invites/bind 接口完成绑定。
现象： 后端数据库出现了同一个用户被重复绑定的两条记录。 初步排查： 后端日志显示，两个 /invites/bind 请求几乎在同一秒（间隔仅几十毫秒）到达服务器。
疑点一：消失的“第二次请求”前端最初的结论是： “后端背锅” 。理由看似非常充分：
控制台证据：Network 面板从头到尾只显示了一条 bind 请求。
逻辑自洽：前端代码对 bind 请求做了严格控制，执行前会判断 SessionStorage 中是否存在邀请码，请求发出的那一刻会立即清空该值。理论上，第二次请求根本过不了判断逻辑。
然而，后端日志是铁证。为什么控制台只显示一条请求，后端却收到了两条 ...
未来已来-论ai时代的最佳编程实践
三十多年前，软件工程的鼻祖弗雷德里克·布鲁克斯（Frederick Brooks）在他的神作《人月神话》里掐指一算，断言：“编程界没有银弹。” 他的意思是，没有任何一种技术或管理方法，能像杀掉狼人的银弹一样，让软件开发的生产力在十年内提高一个数量级。
老布当年说这话时，手里可能还攥着打孔卡片或者在为 C++ 的内存泄漏掉头发。他大概做梦也没想到，三十年后，人类真的搞出了一颗闪着赛博光芒的“准银弹”——人工智能。
现在的编程界，画风已经彻底从“面向 Google 编程”进化到了“面向意图编程”。如果你还在坚持纯手工一行行敲代码，并以此为傲，那感觉就像是在 F1 赛场上坚持骑自行车，虽然锻炼身体，但确实追不上那群开了挂的“提示词工程师”。
那么，在这个 AI 领跑的时代，什么样的编程实践才称得上是“最佳”？让我们聊聊如何优雅地装上这颗银弹。
一、 从“搬砖工”进化为“包工头”：提问力的觉醒以前我们评价一个程序员优不优秀，看的是他的“手速”和“记忆力”——能不能盲打正则表达式？能不能背出 Linux 的八百个参数？
在 AI 时代，这些技能的价值正在迅速贬值，贬值速度堪比没通电的比特币。A ...
现代单页应用（SPA）中微信授权登录的高可用架构实现
深度解析：现代单页应用（SPA）中微信授权登录的高可用架构实现在当前的 Web 开发生态中，微信扫码登录已成为 B/S 架构系统的标配。然而，如何在单页应用（SPA）中优雅地处理跨窗口通信、状态校验、以及 Nginx 层的路由分发，是衡量一个系统工程化水平的重要指标。本文将结合实际项目经验，深度拆解一套工业级的微信授权登录全链路实现方案。
一、 授权发起的严密性：State 校验与环境预判授权的第一步并非简单地跳转链接，而是确保请求的安全性和上下文的可追溯性。
1. 安全指纹：State 的生成与持久化为了防御 CSRF（跨站请求伪造）攻击，前端在请求后端获取微信授权 URL 之前，需生成一个随机的 state。在本项目中，该 state 被写入 localStorage 而非 sessionStorage。
技术细节：由于微信授权往往涉及新窗口弹出（window.open），子窗口与父窗口之间需要共享状态。sessionStorage 仅在单一标签页生命周期内有效，无法跨窗口传递。
2. 交互降级策略为了提供极致的用户体验，前端通常优先尝试使用 window.open ...
webrtc技术详解
本文将详细研究webrtc的相关技术，最后以一个点对点的视频通话demo散花。webrtc核心模块
MediaStream（媒体流模块）：负责捕获摄像头、麦克风的音视频数据，生成媒体流，提供媒体轨道的添加、移除、切换等基础操作。
RTCPeerConnection（对等连接模块）：核心模块，负责建立、管理两个端之间的音视频连接，处理 ICE 协商、SDP 交换，实现音视频数据的实时传输与解码。
RTCDataChannel（数据通道模块）：辅助模块，用于传输非音视频数据（如实时消息、文件），实现端到端的数据交互。
工作流程
如上图所示，通信流程包含了四方玩家：两个peer、信令服务器及stun服务器。过程解释：
第一步：发起方（peer1）创建RTCPeerConnection（配置STUN服务器），加入本地音视频流，然后创建Offer，发给接收方（peer2）；
第二步：接收方（peer2）收到Offer，设置远程描述，然后创建Answer，回传给发起方（peer1）；
第三步：双方在完成Offer/Answer协商后，才会向STUN服务器请求自己的公网IP+端口（生 ...
Transformation of Team Development Models
I’ve been using Cursor obsessively lately, which sparked some ideas so I want to share them hereConclusion first: with AI-assisted capability, one person becomes an entire team
The legacy development routinePRD + prototype + code
Product managers interview stakeholders, nail down requirements, and produce the PRD
Designers coordinate with product to deliver the UI prototype
Engineers align with product and design, clarify requirements, then schedule and start coding
This is the typical mainstr ...
Fps射击游戏开发：第一回
由于项目需要，研究了下unity，借此写个小游戏，所以本文开始，将详细记录，使用unity开发fps射击游戏的所有细节认识编辑器
基本的界面如上图所示，就四大块工作区：视图区（红色）、文件区（橙色）、对象区（蓝色）及最右侧的inspector区域。其中inspector可以看作是属性详情，例如我们选中某个刚体（物体，如圆柱、地面），能够看到该刚体的位置等的所有信息，当然，还包括了其绑定的c#代码文件。
我们首先创建了一个圆柱体和一个地面。本质就是俩三维刚体，通过GameObject选项卡中的capsule和plane创建。并分别给他们加了点material（材质、颜色）。最后设置了一个光照，使其看起来有质感些。
Start和Update这俩函数是我们之后几乎标配的函数。前者在项目开始运行时，执行一次。后者就是大名鼎鼎的tick时刻，每帧执行，类似于前端的raf函数。
给圆柱体绑定c#代码创建scripts文件夹专门存放代码文件，然后选中物体，将c#文件直接拖入inspector中绑定。代码文件具体如下。
palyer.cs
using System.Collections;
u ...
Thoughts on the Frontend Product Perspective
Keep it simpleHaving been in development for four years and worked on plenty of projects, I suddenly had some thoughts about the product side.
It started when I noticed many domestic friends building independent sites and overseas ventures. After briefly getting involved, I realized that some shopping platforms can be extremely minimalist. Because of work, I got exposed to many overseas businesses. Compared with domestic projects, they share one glaring trait: clean, flashy, and built on modern ...
第一回：开宗明义的聊聊
本文简单聊聊“整洁代码”的几个点究竟什么样的代码才是高质量可维护的代码（没有味道的代码）？什么样的组件才能叫作好的组件？函数怎么写才是干净、高效、得体的？瓦卡利马僧。但是，本文中我们尝试着去瓦卡利。
组件化编程随着业务量代码的积累，自己突然感觉有点力不从心：代码太容易成为“屎山”了。就拿目前项目的一个场景举例：写一个创建任务的表单组件。听起来很简单是吧？是很简单，但写起来，极度费劲。原因在于，该创建表单项过多，且伴随着各种联动需求。一开始愣头愣脑的上去就是干。写到一半，发现已经写不下去了—->该文件已经超过了 1000 行，变量无数，单单 flag 就十几二十来个，如若再这么写下去，我估计即使勉强实现了需求，后面接手的人都会顺着网线来砍我。此时，我的心情是崩溃且尴尬的。你能够想象，在一个单文件代码超过1000 行游走是什么感觉吗？望着这座自己亲手堆砌的半坐“屎山“，觉得自己有义务寻求一些解决方案，免得被后人耻笑。简单的讲就是一个字：拆。在《重构》这本书的指导下，疯狂拆分这座屎山，当然，这个过程也是无偿加班的过程。最终单文件代码量干到了 300 来行，虽然被拆出去的儿子组件的可复用 ...