山景城小路

@Zen_with_AI · 2026-10-19

让 AI 画图，别再要 Mermaid 那种圆角方框了 🎨 diagram-design：一个 agent skill，一句话让 Claude Code / Codex / Cursor 直接画出一个自包含的 HTML + SVG 图。45 种图型，架构图、时序图、桑基图、爆炸轴测图都有。 审美被写成了规则：全图只用一个强调色，没有阴影，所有坐标都能被 4 整除。给它你的网站链接，它还能自动提取配色和字体。 npx skills add cathrynlavery/diagram-design http://github.com/cathrynlavery/diagram-design

铁锤人

@lxfater · 2026-10-18

AI 再聪明，写代码时我还是更信 GitHub 上成熟仓库里验证过的解法 AI 还没爆发的时候，我就经常参考这些仓库来写代码，质量也很好 现在有人把这套方法做成了工具，叫 XERJ： 帮 AI 下载相近的开源仓库，把代码整理成可搜索的资料，动手写之前先查相关实现 效果怎么样？ 项目方用专门构造的陌生代码库做了对照测试： 两组都通过了 16/16 次运行，用 XERJ 的组比用 grep 搜源码的组，生成的文本量少了约 62%（按 token 计） 挺高兴看到自己以前的做法，有人把它做成工具，还测了效果 https://github.com/xerj-org/xerj

JL

@LJL06019 · 2026-10-20

发现个狠活：Graphify，12.9 万星。 它把整个代码库——连文档、SQL 表结构、配置文件、PDF 一起——在本地解析成 AST，建成一张能查询的知识图谱。不用向量库，每条边都说得清为什么连。 做成了 Claude Code、Cursor、Codex、Gemini CLI 都能装的 skill。 大仓库喂给 Agent 最大的问题是它压根不知道代码长什么样，只能猜。这个是先把地图画出来。

Ethan 恩宇

@UPing123zzz · 2026-10-21

看完这张图，我觉得很多人可能一直没有真正理解 RAG 和 Agentic RAG 的区别。 尤其是现在很多人一上来就想做 Agentic RAG，觉得普通 RAG 已经过时了，加上 Agent、多轮推理、工具调用，系统就一定会变得更智能。 但实际上，这两种架构解决的根本就不是完全一样的问题。 普通 RAG 的逻辑其实很简单：用户提出问题，系统去知识库检索相关内容，把检索到的证据交给大模型，再由模型生成答案。整个流程相对固定，核心是把正确的信息找出来，让模型基于证据回答。 而 Agentic RAG 最大的不同，就是把一部分检索决策权交给了 Agent。它可以根据用户的问题，决定去哪里检索、调用什么工具、要不要拆分问题，以及第一次检索失败以后，是否需要重新查询或者切换数据源。 举个例子，用户问一家公司的报销制度，普通 RAG 可能检索几份相关文档就能回答。但如果用户问的是：今年的报销政策相比去年发生了哪些变化？哪些部门受到了影响？有没有特殊审批流程？ 这时候系统可能就需要查询不同版本的制度，确认生效时间，检索多个部门的规定，甚至调用内部业务系统，最后再把这些证据整合起来。这才是 Agentic RAG 更适合发挥作用的地方。 但我觉得最值得警惕的一件事，就是很多开发者正在把 Agentic RAG 当成一种技术炫耀。 明明一个普通的混合检索加 Rerank 就能解决的问题，非要加上好几个 Agent，让它自己规划、自己检索、自己评估、自己重试。 结果架构越来越复杂，Token 消耗越来越高，响应越来越慢，系统甚至还可能因为错误的规划而检索到不相关的信息。 我自己最近一直在研究企业级 RAG，也越来越发现，真正困难的地方往往不是选什么框架，而是文档解析、权限隔离、增量同步、版本管理、检索质量、证据引用，以及怎么通过 Evals 去验证系统到底有没有回答正确。 这些基础工程没有做好，就算给 RAG 套上十层 Agent，也不代表它能可靠地进入生产环境。 所以我现在有一个越来越明确的判断：能用普通 RAG 解决的问题，就不要为了 Agent 而 Agent。只有当任务真的需要动态规划、多步检索、跨数据源查询和工具协作时，再考虑 Agentic RAG。 真正优秀的 AI 工程师，不是能把系统设计得多复杂，而是知道什么时候应该使用复杂的系统，什么时候应该保持简单。 技术架构从来不是越高级越好，而是谁能以更低的成本、更稳定的方式，把真实问题解决掉。 这才是我认为企业 AI 落地最应该坚持的工程思维。

码良

@cxjwin · 2026-10-20

面试吃瘪记录 只给 SELECT 防住了改和删，防不住查了不该查的。 ① 最小权限：专用只读账号，只授权必要的表或视图，不给写入、DDL、文件操作和存储过程权限。 ② 不直接执行模型写的 SQL：让模型输出结构化查询计划，后端解析成语法树，只允许单条受支持的查询，表、列、函数走白名单，拒绝导出文件、FOR UPDATE 锁定读等。解析不了就不执行。 ③ 数据权限：身份从登录态取，后端给每个受保护的数据源都加上数据范围，不能只在最外层补个 WHERE；没权限的列不能查，也不能拿来做筛选。数据库支持行级安全再加一道。 ④ 防注入：条件值走预编译参数；表名、列名没法用占位符，必须从白名单映射。 ⑤ 防拖垮：限制返回行数，设置查询超时。 面试时可以这样答：只读最小权限账号，模型只出结构化计划，后端解析校验并按白名单生成参数化 SQL，数据范围和列权限由后端按登录态强制加上。

piglei

@Piglei · 2026-10-23

人们说，Code Review 很快会消失，因为人的 review 速度跟不上 AI 产出，会拖累开发流程。人们又说，在这个 Agent 时代搞软件开发，好的基础和工程品味至关重要。 好，现在我就是想知道，一个工程师，他要怎么在不写也不看代码的情况下，培养出良好的技术基础和品味？？长年累月的许愿，等待顿悟吗？

LimboAI

@limbopeng · 2026-10-23

今天阮一峰科技爱好者周刊最有看头的就是这个了：AI 推翻了传统的软件开发，编程现在已经面目全非。 （1）代码审查（Code review）将消失。 人工审查代码已经没意义了。因为人类跟不上 AI 生成代码的速度，无法在合理的时间内，发现 AI 代码中的 Bug。人类未来只能审查整个系统的组成或架构是否合理，而绝不会像现在这样，通过 PR 逐行审查代码。 （2）单元测试可能会消失。 AI 可以随时改变代码的整个实现，再去测试一个个代码单元，就没意义了。也许下次迭代，整栋楼就会重建，何必再去检查单块砖头。将来的项目可能只有接口测试、集成测试、系统测试，而不会保留单元测试。 （3）软件开发的重点不再是写代码。 代码将来由 AI 负责，程序员的工作重点将移到代码以外的其他环节：如何用软件解决业务问题、了解软件如何实现、如何发布软件、如何收集反馈等等。 （4）Bug 的性质也变了。 大多数 Bug 不再是代码 Bug，而是需求提错了或表达不准确。 （5）软件开源不再能提升质量。 以前，代码开源的一个理由是“只要关注的人足够多，所有 Bug 都能被发现”。这句话依然成立，但是现在即使你不开源，AI 也能帮你发现 Bug。 （6）敏捷编程会死亡。 敏捷编程的各种方法（Agile、Scrum 等），都意义不大了，AI 的生成速度决定了项目的开发时间，你所要做的就是把工单直接推给 AI。 （7）项目分工将改变。 以前，项目组一般包括三种角色：项目经理（PM）、设计师（Designer）、工程人员（Engineer）。以后，这种三元架构将消失。有了 AI， 一个人可以兼任多个角色。 （8）“好代码”的概念将消失。 以前，“好代码”的标准是便于人类阅读理解、方便重构、开发维护效率较高的代码。但是，你已经不读代码、不直接修改和维护大部分代码，“好代码”的存在前提就消失了。 （9）代码风格规范和 linter 工具，也没意义了。 AI 会在乎代码风格吗：每行不超过80个字符、有没有换行符、缩进是 tab 键还是空格键……？ （10）UI 将变得不重要。 一方面，未来的很多 UI 是给 AI 使用的，而 AI 只需要 API，不需要精致的 UI。另一方面，如果代码的生成速度极快，那么用户界面（UI）将实时生成。许多 UI 之所以存在，是因为软件无法确定你想要什么。菜单、设置页、仪表盘、过滤器，都是为了帮助用户快速确定需求。用户通过语言明确了需求，AI 就可以实时为他生成定制的 UI。 （11）Token 为王。谁能够负担更多的 Token，谁的软件就更好。如果你没有足够的 Token，你就开发不出最优秀的软件。

Ethan 恩宇

@UPing123zzz · 2026-10-24

看完这份清单，我觉得所有正在使用 Codex、Claude Code 做 AI Coding 的人，都应该认真看看，包括我自己。 AI 时代最可怕的事情，不是你不会写代码，而是 AI 帮你开发了一个完整的软件，你却根本不知道这个软件在什么情况下会崩溃。 这篇文章列出了 50 个软件工程中非常重要的概念，从数据库、并发控制、缓存、分布式系统，到消息队列、系统扩展和可观测性。 这些东西可能没有 Agent、RAG、MCP 那么热门，但它们恰恰决定了一个软件能不能真正进入生产环境。 比如数据库，很多人现在用 AI 开发项目，只需要一句话，AI 就能帮你设计数据库、创建表结构、生成 SQL，甚至把整个后端都搭建起来。 但你真的理解 Database Transactions（数据库事务）吗？知道 ACID 为什么重要吗？知道什么是数据库索引、N+1 查询、连接池、乐观锁和悲观锁吗？ 一个系统在本地只有几个人使用的时候，可能完全没有问题。但如果突然有几百个人同时访问，数据库开始出现性能瓶颈、数据冲突甚至重复写入，你该怎么办？ 再比如并发。Race Conditions（竞态条件）、Deadlocks（死锁）、Idempotency（幂等性），这些听起来非常抽象，但其实都和真实业务息息相关。 假设你开发了一个 AI 自动化订单系统，用户因为网络问题重复提交请求，系统会不会创建两个订单？支付接口超时以后自动重试，会不会导致重复扣款？多个任务同时修改同一条数据，会不会出现错误？ 这些问题不是让 AI 多写几行代码就一定能够解决的。 还有系统可靠性。Rate Limiting（限流）、Circuit Breakers（熔断器）、Retry Mechanisms（重试机制）、Exponential Backoff（指数退避）、Message Queues（消息队列）。 为什么一个 API 超时以后不能无限重试？为什么访问量突然增加，需要限流而不是让所有请求一起进入系统？为什么一些耗时任务应该交给后台 Worker，而不是让用户一直等待？ 因为真正的软件工程，考虑的从来不只是正常情况下能不能运行，还要考虑异常情况下系统会发生什么。 还有缓存、负载均衡、水平扩展、数据库分片、分布式追踪。 这些技术的价值，不是让你的项目看起来更加高级，而是在真实用户、真实数据、真实流量面前，让系统依然能够稳定运行。 我自己这几个月一直在用 AI 做企业应用，也越来越意识到，Vibe Coding 最大的优势就是快速实现想法，但如果缺少软件工程知识，很容易陷入一种错觉： 前端做出来了，后端跑通了，数据库连接成功了，部署也完成了，就以为自己已经开发出了一个成熟的软件。 但 Demo 跑通只是第一步，真正困难的是当系统出现故障、数据不一致、并发冲突、性能下降、API 超时的时候，你有没有能力找到问题，判断原因，并且验证解决方案是否可靠。 当然，我不认为所有人都必须先学完这 50 个概念才能开始 Vibe Coding。做个人工具和开发一个需要支撑数万用户的商业系统，本来就不是同一个难度。 但项目越接近真实生产环境，你就越不能只依赖 AI 给出的代码，而必须逐渐建立自己的工程判断能力。 尤其是未来想成为 AI Engineer、FDE 的人，我觉得这些计算机基础知识真的绕不过去。 你可以让 AI 帮你写代码、设计架构、排查问题，但你必须能够理解它为什么这样设计，什么情况下会失败，以及怎么证明它真正解决了问题。 AI 正在让软件开发的门槛越来越低，但并没有让软件工程本身的复杂性消失。 以前的难点是怎么把代码写出来，现在越来越多的难点变成了怎么判断代码是否可靠，怎么让系统稳定运行，怎么对最终的交付结果负责。 未来会用 AI 写代码的人一定会越来越多，但真正理解数据库、网络、并发、分布式系统，能够把 AI 生成的 Demo 变成可靠产品的人，依然会有竞争力。 所以我越来越觉得：AI Coding 可以成为你的开发方式，但不能成为你逃避理解软件工程的理由。 会让 AI 写代码，只是开始。能够看懂、验证、维护，并且真正驾驭 AI 写出来的系统，才是一个工程师长期的竞争力。

陈大黄

@realchendahuang · 2026-10-24

PostgreSQL 正在以一种不可思议的速度，吞噬整个数据世界。 过去的技术圈讲究各司其职。 存传统关系表格用 MySQL，存半结构化文档用 MongoDB，做全文检索关键词用 Elasticsearch，处理地理测绘信息用专用的 GIS 系统，后来时序数据火了有 InfluxDB，最近大模型爆火又催生了一大批向量数据库。 结果大家一回头，Postgres+插件几乎把这些专精数据库的地盘全给蚕食了。 它原本就是关系型数据库，底座极其扎实，然后配上插件，那就是如虎添翼。 它推出了 JSONB，直接把文档存储干到了原生级别，让不少做文档数据库的人直挠头； 搞全文检索它有内置的倒排索引，普通规模下根本用不着再费劲搭一套搜索引擎； 搞空间测绘有行业标杆级的 PostGIS； 至于这两年大模型掀起的向量检索热潮，大家装上 pgvector 插件，连专用的向量数据库都不用买了。 几乎每一个细分领域，只要 Postgres 把触角伸过去，就能凭着极其成熟的插件生态和稳定性，把原本独立的数据库替换掉。 既然它这么能打，那我们在架构里挂了十多年的 Redis 缓存，能不能也被它顺手给彻底代替了？ 要搞清楚这个问题，我们得先回到最原点：到底什么是 Redis 缓存，为什么我们一开始非要用它？ 计算机硬件的世界里有一条铁律：离 CPU 越近的存储介质越快，但也越贵、越容易丢数据。内存拿数据的速度极快，通常只要几十个纳秒；而哪怕是现在最顶级的固态硬盘，读写速度也要比内存慢上成千上万倍。 我们平时用的关系型数据库，为了保证电脑突然断电时数据一颗都不丢，所有数据都必须老老实实写进硬盘里保存。这就带来了一个天然的瓶颈： 如果一个网站突然涌进来几万人，大家都去查同一个热门商品或者同一篇爆款文章，数据库就得拼命在硬盘里翻箱倒柜找数据。硬盘的寻址吞吐量一旦被吃满，后续的请求只能排队等候，用户端看到的现象就是网页一直在转圈，最后干脆直接超时报错。 为了保护脆弱的数据库，Redis 出现了。 你可以把 Redis 理解成摆在办公桌最顺手位置的一张便签纸。 它不搞复杂的多表关联，专门把数据放在纯内存里。每次有人来查热门数据，系统先看一眼便签纸；如果便签纸上写着现成的答案，直接照着念给用户，整个过程耗时连一毫秒都不到，底下的数据库根本不需要去翻硬盘。 只有当便签纸上没有记录时，系统才去硬盘里查一次，并顺手把结果抄到便签纸上供下一个人使用。这种把高频访问的数据预先放在超高速内存里的做法，就是缓存。 有了这张便签纸，系统的响应速度确实有了质的飞跃，但随之而来的是一套让人极度痛苦的副作用： 账本和便签纸怎么保持一致？ 在真实的业务代码里，用户一旦修改了自己的昵称，你的程序就得做两件事：第一步，把硬盘主库里的账本改了；第二步，把内存便签纸上的旧昵称划掉或者换成新的。 可这两件事发生在两台完全独立的服务器上，走的是两条不同的网络通道。 万一网线抖了一下，或者程序刚改完数据库还没来得及通知 Redis 就突然崩溃了，灾难就发生了：硬盘里的数据是最新的，便签纸上的数据却是旧的。此后所有用户从便签纸上读到的全是错误信息，这就是臭名昭著的双写不一致。 为了解决这个毛病，程序员们发明了各种复杂的延迟双删、死信队列、甚至是专门去监听数据库底层变动的中间件，原本简单的系统被越搞越臃肿。 既然大家这么头疼，那全能的 Postgres 到底能不能把这张便签纸也收到自己屋檐底下？它是怎么做到的？ 很多人一听到用关系型数据库当缓存，第一反应就是觉得荒谬：你个存硬盘的家伙，凭什么跟纯内存的 Redis 比速度？ 但数据库写硬盘之所以慢，是因为每次写入提交时，必须把预写日志强制刷进物理磁盘，等待操作系统和硬件控制器确认。 而 Postgres 有一个非常绝妙的特性：允许你建立一种不记日志的表，叫做 UNLOGGED 表。 只要给表加上这个标记，Postgres 就会彻底关掉磁盘刷盘流程。所有的读写操作直接在它分配好的内存缓冲池里飞速流转，单次写入耗时直接从几毫秒断崖式下跌到零点零八毫秒，只比 Redis 纯内存的零点零五毫秒慢了几十微秒。 更巧的是，这种表如果遇到机器断电重启，里面的数据会自动被清空，物理特性天生就跟随时可以失效的缓存一模一样。 把缓存收回 Postgres 之后，双写不一致的Bug当场消失了。 以前改数据和删缓存是两码事，现在它们都在同一个数据库引擎内部。修改业务数据和清理缓存表，可以完完全全塞进同一个本地数据库事务里。 要么两件事一起成功生效，要么中间出一点岔子两边同时回滚，原子性被底层系统死死锁住，从物理机制上彻底断绝了账本和便签纸打架的可能。 更顺带的是，很多团队为了发通知、跑后台异步任务，往往会用 Redis 顺手搭个消息队列或者发布订阅系统。而在 Postgres 里，这些边角料功能它自己也早就有现成的解法。 比如防止多个后台工人重复抢活，它有行级锁跳过机制 SKIP LOCKED，多个进程同时抓任务时自动跳过正在被别人处理的行，完全不需要外挂分布式锁；要是工人中途挂了，本地事务回滚，任务自动重新放回待办。 再比如实时状态推送，它有内置的 LISTEN 和 NOTIFY 机制，数据写入成功的瞬间顺手触发通知，保证了通知和业务数据绝对同步。 哪怕把这些功能都补齐了，单用 Postgres 真的能跑得更快吗？ 如果单看实验室里脱离真实业务的简单读写测速，Redis 确实稍胜一筹。但在真实的工程链路上，几乎没有哪个用户的操作是只读写一个键值的。 一个标准的业务动作打进来，往往需要先更新业务表，再跨网络去删掉旧缓存，最后再发一条通知给前端。 在过去，你的程序必须在自己的服务器、Postgres 服务器、Redis 服务器之间来回发起三次网络通信。光是跨机器的网络往返与握手等待，随随便便就吃掉三四毫秒。 而如果这一切全在 Postgres 的单连接内部搞定，你的程序只需要发过去一次请求，数据库在本地事务里把这三件事一气呵成处理完，全流程只要两毫秒左右。 省掉两次跨服务器的网络往返延迟，所带来的性能收益远远盖过了微观内存操作上那几十微秒的差距。 既然这么厉害，那为什么依然不能武断地说它可以完全代替 Redis？ 因为物理定律从来不会被奇迹打破，真正的架构师必须一眼看穿天花板在哪里。 第一个无法逾越的天花板是极端高并发下的吞吐量。 Redis 的底层架构极其纯粹，它用单线程配合非阻塞的事件多路复用，就像一个只做单一动作的流水线机器人，单个核心一秒钟能纯靠内存吞吐几十万次请求。 而 Postgres 是典型的多进程架构，每一个连接都要占用操作系统独立的内存和进程上下文。当你的系统真的面临极端抢购，每秒有十几万次甚至几十万次并发涌入时，Postgres 的 CPU 会迅速被进程间的切换和调度压垮，这时候只有把 Redis 挡在最外层，才能死死护住底下的数据库不被瞬间冲塌。 第二个天花板是缓存的自动淘汰与数据膨胀。 Redis 的内存如果被填满了，它内置了精巧的淘汰策略，能在毫秒之间按设定的规则自动把最老的数据扔掉，始终把内存控制在安全水位。 而 Postgres 采用的是多版本并发控制，在它里面删除数据并不是立刻腾出物理空间，而只是把记录打上作废标记，全靠后台的清理进程慢吞吞地去回收。如果你的业务每天超高频地写入几千万个临时缓存又疯狂删除，后台清理一旦跟不上节奏，整个数据表在磁盘上就会迅速膨胀失控，最终拖慢整台机器的磁盘性能。 第三个天花板是专精数据结构。 Redis 并不只是个简单的键值抽屉，它里面专门用 C 语言实现了跳表支持的实时排行榜、支持几千万人在线去重统计的基数算法，还有各种位图运算。 如果硬要在关系型数据库里用 SQL 语句去给十万人做实时的积分排名，不仅语法别扭，消耗的算力也远比内存跳表昂贵得多。 对于绝大多数业务系统、单体应用或者初创项目，根本不需要直面几十万 QPS 的恐怖洪峰，也没有复杂的算法排行榜。 在这样的场景下，强行在架构里塞一个 Redis，往往只是照搬大厂教条换来的心理安慰，实际上却白白背负了翻倍的服务器账单和随时可能暴雷的双写一致性隐患。 把 Postgres 的能力吃透，用一张不记日志的表、一套本地事务和原生的并发机制，就能把缓存、队列和通知办得妥妥帖帖。 少开一个云实例，少维护一套高可用集群，少一个半夜把人叫醒的报警电话，整个系统往往反而更干净、更敏捷、跑得更稳当，才能不烧心。

码良

@cxjwin · 2026-10-20

https://x.com/i/article/2112243370219450374

码良

@cxjwin · 2026-10-21

https://x.com/i/article/2112693518598877184