- 博客(701)
- 收藏
- 关注
RSS订阅原创 第 30 期：把 AI 应用真正交付出去
AI应用发布需通过严格门禁，涵盖评估证据、版本溯源、费用与安全边界。本次实验因样本不足、延迟与费用数据缺失、安全通过率0%等六项阻断未上线。强调发布清单应包含模型、Prompt、索引等全链路制品指纹，评估集需覆盖失败场景，多维评估不可简单加权，非确定性输出需分层判定，且“缺失值”本身即为阻断条件，确保发布可测、可控、可回退。
2026-10-11 13:44:50
239
原创 第 29 期：工作流、工具调用与 Agent 的边界
本文通过一个订单退款场景，揭示Agent系统中“看似正确”的工具调用背后隐藏的风险。核心观点：模型生成的建议不能直接执行，必须通过受控工作流进行多层校验——包括动作参数、订单与策略版本、权限范围及业务逻辑一致性。实践表明，即使模型输出结构合规，若缺乏对版本变更、重复调用、越权操作的防护，仍会导致安全漏洞。因此，应将模型定位为“动态决策辅助”，而非全权执行者；工具调用需严格约束，审批需透明可追溯，真正实现“确定性外壳”下的智能协作。
2026-10-11 13:44:14
140
原创 第 28 期：RAG 的难点不在“把文档塞进提示词”
RAG虽能引入外部知识，但模型仍可能忽略、误解或误引信息。实验显示，即使答案块已进入上下文，生成结果仍常因引用错误、逻辑矛盾或幻觉而失效。问题根源在于流程链中每个环节——检索、重排、生成、引用校验——均可能出错。作者强调需建立分阶段失败分类与追踪机制，确保错误可定位；同时指出文档解析、查询改写与版本一致性对结果至关重要。最终结论：RAG不是“一键正确”的黑箱，而是需精细设计与验证的有状态数据链。
2026-10-11 13:43:23
187
原创 第 27 期：Embedding 与向量检索，不只是把文本变成数组
本文通过对比固定字符切分与标题/段落感知切分在向量检索中的表现，揭示了看似合理的文本切分策略可能因重复标题、语义稀释等问题导致召回率下降。实验使用BAAI/bge-small-zh-v1.5模型，基于真实技术文章与14个问题评估，发现结构化切分在放宽块长至800字符后，Recall@5达0.9286，显著优于固定切分的0.7143。结果强调：向量检索中“相似”不等于“正确”，切分方式、向量归一化、排序一致性及文档更新同步等环节均需谨慎处理，否则易产生误导性结果。
2026-10-09 10:13:55
158
原创 第 26 期：调用大模型 API 之后，工程问题才刚开始
本文探讨了将大模型接入生产系统时的工程挑战：输入输出不可控、结果不可信、成本难估算、流式响应复杂等。作者强调，真正难点不在于模型本身，而在于如何管理超时、重试、限流、数据校验与可观测性。通过拆分流式摘要与结构化分类、明确上下文边界、分离指令与用户数据、设计清晰的API接口，构建稳定可靠的模型服务。核心是把模型视为一个有成本、不稳定且需严格验证的外部依赖，而非“万能生成器”。
2026-10-09 10:08:59
225
原创 第 25 期：把 Python 服务交给 Kubernetes 之后
Kubernetes 仅执行声明的规则，不理解业务逻辑。本文通过一次发布故障揭示：当就绪探针过早放行、资源配置不当、扩缩容与数据库容量不匹配时，系统会“正确地”放大问题。强调需明确 Pod 生命周期、合理配置探针（startup/readiness/liveness）、精确设定资源请求与限制，并避免将 Pod 当作可长期维护的服务器。实践建议以请求链路为视角，统一各组件语义，确保调度、发布与可观测性协同一致。
2026-10-08 10:37:36
193
原创 《幸福的陷阱》读书感悟：先不急着把自己修好
假期里我一般要睡到八九点，这天却在七点醒了。脑子里没有一件特别明确的事，但我知道自己心里压着东西。第二天要上班，那颗做过根管治疗的左上后槽牙又在隐隐作痛。想到看牙，我先想到的不是疼，而是又要预约、跑医院、隔三差五地请假。这些事都不算多严重，但它们突然闯进原来的安排里，我会觉得麻烦，甚至有些烦躁。我躺着想把焦虑的原因一件件找出来，好像只要分析清楚，心里就能安定。可想了一圈之后，工作、牙齿、年龄、孩子和未来全混在了一起，问题反而显得更大了。
2026-10-07 08:54:14
176
原创 第 24 期：一条值得信任的 CI/CD 流水线
流水线全绿不等于交付可信。关键在于：代码提交是否一致、构建是否唯一、制品能否追溯。需建立从源码到生产的证据链，确保测试、构建、发布使用同一输入，杜绝因重复构建或缓存污染导致的环境漂移。快反馈与强证据可兼得，通过分层、并行、依赖驱动的流程设计，实现安全与效率平衡。
2026-10-07 08:44:20
145
原创 第 23 期：Docker 镜像里应该装什么，不应该装什么
本文剖析了常见Dockerfile的误区，强调镜像应是清晰的运行契约而非开发者环境复刻。通过优化构建上下文、使用.dockerignore、合理排序指令与依赖锁定，实现可重复、可审计的镜像构建。重点实践多阶段构建，将编译器等开发工具隔离于生产层之外，确保镜像轻量、安全、边界明确，真正服务于高效交付。
2026-10-07 08:23:24
216
原创 第 22 期：Python 程序运行在 Linux 上时，应该看懂什么
进程存在不等于服务可用。即使 PID 仍在、内存与端口正常，若文件描述符耗尽或线程阻塞于无超时队列，服务仍无法响应。信号处理需谨慎，SIGTERM 后的优雅退出依赖合理预算与收尾逻辑，而非简单日志打印。排查应深入状态（如 STAT、wchan）、资源限制与退出码上下文，避免误判“假死”为“正常”。
2026-10-07 08:06:29
208
原创 第 21 期：接口安全不是加一个登录框
本文剖析了系统中常见的“对象级越权”问题，指出仅依赖登录认证（如Session、JWT）不足以保障安全。核心在于：即使用户已登录，仍需在数据访问层验证其对具体对象的权限。文章强调，必须将身份上下文（如商户ID）嵌入数据库查询条件，而非仅依赖前端传参。通过对比401/403/404状态码使用、不同认证机制（Session、API Key、OAuth 2.0、JWT）适用场景，提出应构建“认证→功能授权→对象级授权→输入控制”的多层防护体系，避免因信任传递错误导致数据泄露。
2026-10-05 20:36:10
195
原创 第 20 期：一次慢请求的完整排查：从现象到证据
性能排查最耗时的，往往不是工具不会用，而是过早相信第一个看似合理的解释。本文以订单接口慢为例，强调应先精准描述现象、构建时间线、收集证据，而非依赖直觉。通过对比健康与慢请求，发现瓶颈在Python数据组装阶段，而非数据库。关键在于每一步都明确排除或确认假设，借助指标、日志与Trace逐步缩小范围，最终定位代码热点。真正的排查核心是严谨的验证路径，而非工具本身。
2026-10-05 20:16:50
146
原创 第 19 期：测试不是补在最后的一层保险
测试真正保护的，是系统在重复、并发与失败下的业务承诺，而非代码实现细节。高覆盖率的单元测试常因Mock掩盖真实风险。应聚焦三类核心验证：业务不变量（如金额约束）、边界契约（如接口响应）与运行时性质（如事务一致性）。测试层级应依风险与反馈速度选择，而非固定比例。关键在于将领域规则剥离框架，用参数化测试覆盖边界，并通过真实数据库、消息队列等集成测试验证核心承诺，确保测试不仅是“代码的复述”，而是“承诺的证据”。
2026-10-05 09:46:31
149
原创 第 18 期：同一份订单数据，为什么需要不同的存储
数据存储的合理性取决于使用场景。同一份订单事实需根据不同需求生成不同投影：事务库保当前状态，对象存储存历史事件，列式数据库支持高效分析。关键不是“用哪个库”，而是明确读写模式、时效要求与数据生命周期。行存适合点查，列存利于聚合，但选型需基于实际访问路径——一次读多少行、几列，是否需追溯历史，能否容忍延迟。多副本带来维护成本，但合理分离负载才能保障系统稳定与可扩展。
2026-10-05 09:32:01
184
原创 第 17 期：Airflow 不是定时器：如何编排一条数据工作流
本文以订单处理流程为例，阐述Airflow调度系统的核心价值：不在于替代cron，而在于管理数据区间、任务依赖与状态恢复。通过拆分任务为可独立重试的业务阶段，传递产物引用而非数据本身，实现安全重放与精准回补。强调任务设计应基于失败隔离、资源差异与契约一致性，而非代码层级。最终构建出可追溯、可验证、可重试的增量数据管道，真正发挥调度系统的编排能力。
2026-10-05 09:16:46
195
原创 第 16 期：从全量脚本到增量数据管道
本文探讨增量数据处理的核心挑战：在失败、重跑与延迟后仍能准确追踪进度。以每日同步四千万订单的脚本为例，揭示全量处理的高成本与一致性风险。通过引入基于时间窗口的增量管道，强调使用source_updated_at与revision构建可靠变更识别机制，采用左闭右开区间分页避免遗漏，并区分Watermark（持久进度）、Window（处理范围）与Cursor（分页位置）三者职责。重点解决同一秒多条记录、边界对齐、写入中断等复杂场景，最终实现高效、可恢复、一致的数据同步。
2026-10-03 21:56:50
144
原创 第 15 期：脏数据不会自己消失：解析、清洗与质量检查
数据清洗的真正风险，不在于程序报错，而在于静默输出看似干净却错误的数据。本文以订单金额格式、时区处理、重复判定等为例，揭示“自动补0”“去重逻辑”等常见操作如何悄然扭曲业务含义。作者强调：清洗应基于明确的数据契约与来源规则，拒绝模糊推断，保留可疑记录并生成可追溯的质量报告，而非盲目“凑出结果”。
2026-10-03 21:41:38
142
原创 第 14 期：写一个对目标网站和自己都负责的爬虫
一个可靠的爬虫不仅知悉下一页，更懂得何时该停、何处不可去。本文强调采集前需确认访问权限、遵守robots.txt、规范URL、控制速率，并建立白名单策略。通过代码化访问边界与任务声明，实现安全、合规的增量采集，拒绝盲目并发与重试。真正的爬虫工程，重在责任与边界意识。
2026-10-03 21:23:12
949
原创 第 13 期：深入 asyncio：取消、超时与结构化并发
异步编程的难点不在于启动任务，而在于确保请求结束后无遗留任务。文中通过订单接口案例揭示：create_task() 未管理的任务、被吞掉的 CancelledError 及 gather() 的默认行为，均可能导致连接泄漏、资源耗尽。核心问题在于任务生命周期与请求解耦。建议使用 TaskGroup 明确管理子任务，配合超时控制与异常捕获，确保取消信号有效传播，释放锁与连接。事件循环非自动并行器，协程需主动挂起，避免阻塞。关键原则：每个任务都应有明确归属与终止机制，否则“后台运行”即“失控”。
2026-10-02 14:07:30
185
原创 第 12 期：线程、进程和协程，到底应该选哪一个
本文剖析并发优化的本质：程序慢并非单一问题，而是多种瓶颈（I/O等待、CPU计算、共享状态）交织所致。线程池可叠加等待时间，但受限于GIL与资源竞争；进程池突破GIL限制，适合纯计算任务，却增加内存开销。关键在于区分“等待”与“计算”，根据任务特性选择串行、线程、进程或协程，兼顾吞吐、延迟与资源成本，避免盲目提升并发。
2026-10-02 10:11:32
205
原创 第 11 期：算法不只在面试里：从一段慢代码谈数据结构
数据量小时，低效算法看似无害，但规模扩大后，复杂度问题将“连本带利”返还。本文以订单去重脚本为例，揭示双层循环导致的 O(n²) 性能瓶颈。通过明确业务规则（保留高版本订单、排除冲突），改用字典索引实现 O(n) 去重，显著提升效率。强调：性能优化前需厘清逻辑，选择合适数据结构，避免小数据带来的认知偏差。
2026-10-01 15:47:12
169
原创 第 10 期：把耗时工作移出请求：消息队列与异步任务
异步化缩短用户等待，但不消除任务本身的风险。订单确认后通知异步发送，虽提升响应速度，却引入重复、失败、延迟等问题。真正的挑战在于厘清“完成”的多层含义：从事务提交到消息投递、消费确认，每一步都可能失败或重试。系统需通过幂等消费、有限重试、死信队列与监控机制，确保业务结果可预期。消息设计应清晰表达事件而非命令，元数据完备以支持追踪与演进。核心原则是：传输层允许多次投递，但业务逻辑必须支持幂等处理。最终，异步不是逃避责任，而是将责任转移得更清晰——谁生产、谁消费、谁负责恢复，边界必须分明。
2026-10-01 15:35:23
153
原创 Go RPC 入门指南：从 `net/rpc` 到 gRPC
本文介绍Go语言中RPC的原理与实践，通过net/rpc和gRPC两个案例，展示远程调用的实现。net/rpc基于标准库，适合学习和内部简单通信；gRPC则使用Protocol Buffers定义接口，支持多语言、流式传输和高效通信，适用于复杂系统。文章强调RPC虽像本地调用，但需处理网络延迟、超时、幂等性等实际问题，建议为写操作设计幂等键，并合理控制重试。配套源码已打包提供，可直接运行学习。
2026-09-30 17:51:09
144
原创 第 9 期：Redis 缓存加速了什么，又带来了什么
缓存虽能提升读取效率，却也引入一致性与并发风险。订单详情缓存若设置统一过期时间，易引发“缓存雪崩”；更新后未失效缓存，则导致数据不一致。合理缓存需评估重复读、查询成本与可容忍旧值时长。采用 Cache Aside 模式时，应处理未命中、Redis 故障等异常，通过降级、TTL 抖动和互斥重建保障系统稳定。缓存是加速层，而非决策依据，其可靠性取决于对失效、回源与容错的全面设计。
2026-09-30 14:31:46
153
原创 Python RPC 入门指南：从一次远程调用到可运行的 gRPC 服务
本文以Python调用远程函数为例，深入解析RPC（远程过程调用）的核心概念。从“像本地调用”出发，梳理一次RPC调用的完整流程：客户端桩封装请求、序列化传输、服务端解码执行、结果返回。对比RPC与HTTP、REST的区别，强调其作为通信抽象的本质。结合gRPC、Thrift、Pyro5等框架，说明如何根据项目需求选择合适方案，并揭示远程调用在延迟、失败处理、幂等性等方面的挑战与实践建议。
2026-09-30 14:26:00
242
原创 第 8 期：用好 ORM，而不是忘记 SQL
ORM 的危险不在于报错，而在于其平滑接口掩盖了背后的多次数据库查询。看似简单的属性访问（如 order.customer.name）可能触发 N+1 查询，导致性能骤降。本文以订单接口为例，揭示延迟加载、Session 生命周期与加载策略的隐性成本，强调开发者需具备“脑补 SQL”的能力：即使使用 ORM，也应清晰预判查询次数、对象状态与连接复用机制。结合 SQLAlchemy 2.x 的现代写法，从 Engine、连接池到 Session 与关系映射，层层剖析性能陷阱，倡导在便利中保持对底层行为的清醒认
2026-09-30 11:44:30
193
原创 第 7 期：事务不是一个装饰器：隔离、锁与并发一致性
两段看似正确的代码在并发执行时可能引发超卖，因事务间读取过期数据导致“丢失更新”。尽管数据库操作均成功且无异常，但库存被重复扣减。问题根源在于事务边界模糊、隔离性不足。通过显式事务管理、行锁、版本号或原子更新可修复。事务并非自动保障一致性，需开发者明确业务原子性与冲突处理策略。
2026-09-30 11:37:42
257
原创 第 6 期：一条 SQL 为什么会变慢？从查询结果走进执行计划
慢查询常非突现，而是数据量增长暴露了原有执行路径的低效。优化前需区分瓶颈是SQL执行、锁等待还是网络传输。通过EXPLAIN (ANALYZE, BUFFERS)分析真实执行计划，发现如全表扫描、大量过滤后排序、深分页丢弃海量数据等问题。关键在于理解数据库实际执行顺序，结合数据分布与访问模式设计匹配索引，避免盲目加索引。真正高效的优化始于看清“做了什么”，而非猜测“应该怎么做”。
2026-09-30 11:07:50
310
原创 第 5 期：从一次 HTTP 请求看懂 Python Web 服务
一次“确认订单”请求看似简单，实则穿越网络、代理、框架与数据库的多重边界。从客户端点击到服务响应，每一步都需处理身份验证、数据校验、幂等性与事务一致性。关键在于：在边界尽早拒绝非法输入，用 X-Request-ID 跟踪链路，确保重复请求不引发副作用，并将业务逻辑与格式校验分离。真正的挑战不在写函数，而在理解请求如何在系统中协作流转。
2026-09-29 17:57:08
402
原创 第 4 期：如何写一个可靠的 Python 自动化脚本
脚本的可靠性不在于运行速度，而在于中断后能否安全重启。真正可靠的自动化需确保幂等性：任务有唯一标识，副作用可复现，失败状态清晰可追溯。通过临时文件+原子替换避免半成品文件，按块计算摘要防止内存溢出，错误分类处理（瞬时与永久），并保留已完成工作。重试非万能，关键在设计上让每一步都可验证、可恢复，使接手者能明确下一步行动——这才是可靠性的核心。
2026-09-29 17:45:30
84
原创 第 3 期：从单文件脚本到可维护的 Python 项目
项目结构的意义在于让修改有明确位置，错误被清晰边界隔离。从单文件脚本开始，当需求增多导致逻辑混杂时，应通过重构保护核心业务规则：将数据模型与计算逻辑分离，使用Iterable[Order]和Decimal提升灵活性与精度，用纯函数build_report实现可测、可复用的统计逻辑。测试不再依赖文件或环境，而是聚焦于规则本身，让代码在变化中保持清晰与可靠。
2026-09-29 17:22:54
349
原创 第 2 期：变量背后是什么？理解 Python 的对象与内存模型
这段代码似乎是把字符串"Alice"放进了变量user_name。运行结果不是["Alice"]如果是一份独立备份，修改它就不应该影响。问题在于，赋值语句并没有复制列表，只是让两个名称关联到了同一个对象。修改函数参数后，调用方的数据也发生了变化。使用字典模板生成记录，多条记录却共享同一个列表。对配置执行了浅拷贝，修改嵌套字段时仍然污染原配置。服务运行一段时间后内存持续增长，却找不到没有释放的变量。删除对象后，操作系统看到的进程内存没有立即下降。
2026-08-16 20:20:31
194
原创 第 1 期：八年 Python 开发后，我重新画了一张能力地图
回头看八年的 Python 开发生涯，我越来越难用某一种技术或某一个岗位来概括这段经历。Python 可以用来写几十行的自动化脚本，也可以支撑长期运行的 Web 服务；可以抓取网页、处理数据，也可以参与机器学习、任务调度和大数据系统。继续向外延伸，还会接触数据库、缓存、消息队列、Docker、Kubernetes、CI/CD 和可观测性。技术列表会越来越长，但工程师的时间和精力始终有限。如果只跟着工具学习，很容易陷入一种状态：接触过很多技术，却无法判断自己真正掌握了什么，也不知道下一步应该补哪块能力。
2026-08-16 20:13:27
168
原创 Apache Airflow 系列教程 番外篇 | 核心概念深度解析：从源码到生产实践
本文基于Apache Airflow 3.2.1源码，深入解析其核心架构与实现原理。Airflow 3.x采用分包架构，包含airflow-core（核心服务）、task-sdk（任务执行）和providers（插件）模块。文章详细剖析了DAG模型、任务调度机制（Scheduler）、执行引擎（Executor）、状态管理（TaskInstance/DagRun）等核心组件，以及连接管理（Connection/Hook）、变量系统、插件生态等关键功能。通过源码层面对工作流编排、任务执行、异步触发等机制进行分
2026-08-16 19:54:24
278
原创 FastGPT | 24 - AI 模型配置与 LLM 调用层
FastGPT的AI模型调用架构采用分层设计，核心是运行时模型注册中心模式。系统通过插件服务定义模型，结合数据库配置形成全局缓存，并按LLM、Embedding等类型分类存储。模型配置不仅是字符串，而是包含供应商、真实模型ID、能力描述等信息的对象。调用层统一处理OpenAI兼容协议的请求转换和用量统计，业务层负责结果处理和计费。该架构支持多模型类型（LLM/Embedding/Rerank/Audio）、供应商适配和自定义配置，实现了模型能力描述与请求执行的解耦，同时统一了用量追踪和计费机制。
2026-08-16 19:53:58
18
原创 从零开始学前端 | 第二十二章：基础类型与类型注解
类型注解”这个词第一次听起来可能有点正式。你现在可以先把它理解成一句很直白的话：在代码里明确写出来：这个值应该是什么类型。const userName: string = "小白";: string就是类型注解。userName这个变量，应该是一个字符串。名称价格是否有库存然后用 TypeScript 把这个数组的类型写清楚。练对象类型练对象数组类型练stringnumberboolean的组合。
2026-08-16 19:53:27
194
原创 MinerU 系列教程 第二十三课：生态集成 - RAG 框架与 AI 工具链
MCP（Model Context Protocol）是由 Anthropic 提出的开放协议，用于在 AI 模型与外部工具之间建立标准化的通信通道。通俗地说，MCP 让大语言模型可以"调用工具"——而 MinerU 的 MCP Server 就是一个让 AI 模型能够解析文档的工具。MinerU 的 MCP Server 包名为mineru-mcp，通过uvx（uv 的工具执行器）可以自动安装和运行，无需预先手动安装。推荐方案最大灵活度，完全可编程可自定义分块策略、向量化模型、检索算法。
2026-08-16 19:52:13
24
原创 MetaGPT | 第二十二章：常见问题解答与学习资源推荐
RoleAction最容易错在消息路由。下游角色忘记_watch。上游消息忘记设置cause_by。send_to写错角色名。用content传结构化数据，导致下游重复解析。所有角色都响应初始。content 给谁看instruct_content 给谁用cause_by 给谁 watchsend_to 发给谁Action属于固定流程。Tool通常给动态智能体调用。Action-> Role 明确调用-> SOP 固定-> 更容易测试Tool。
2026-08-06 07:03:37
24
原创 MetaGPT | 第二十一章：综合项目实战：构建一个轻量级研发助手
project_name: str = Field(description="项目名称，使用简短 snake_case")summary: str = Field(description="一句话说明项目目标")target_users: List[str] = Field(default_factory=list, description="目标用户")key_features: List[str] = Field(default_factory=list, description="核心功能")
2026-08-06 07:03:01
19
DeerFlow 系列教程 skill技能-市场报告编写
2026-04-21
Kubernetes-1.27.3 在 ARM 机器的部署资源包
2025-11-26
Kubernetes-1.27.3 在 ARM 机器的部署资源包
2025-11-26
Kubernetes-1.27.3 在 ARM 机器的部署资源包
2025-11-26
Kubernetes-1.23.16 离线部署 kubeadm kubelet kubectl 三者rpm包
2025-11-24
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人