caozhiyi1-CSDN博客

原创 AI 替我们写了代码，那谁来懂代码

AI写代码虽让交付翻倍、回滚率走低，却让工程师陷入“解释深度错觉”，在顺畅的AI讲解中失去对系统的掌控感。代码只记录现状，却遗失了取舍与踩坑的上下文。当机器互审逐步切断理解链路，那些仅靠回滚率掩盖的认知断层，正成为软件工程新的隐患。

2026-10-30 21:48:56 50

原创 quicX 简史

我在 TCP 的肩膀上搭过积木，也在 UDP 上重建过可靠。quicX，一个 C++ 写的 QUIC/HTTP3 库，断续多年，几乎由一个人写就，AI 帮它走完了最后一程。如今它通过了 QUIC 互通性测试，能和主流实现互通。做程序员的第十年，它是我最得意的作品。

2026-10-17 23:59:47 82

原创 AI 编程的后半场：越过生成幻觉，重建验收防线

AI 编程核心痛点正从“代码生成”转向“工程验收”。面对低廉生成与昂贵验收的剪刀差，以及 Agent 表面自洽但全局偏航的风险，团队须从审 diff 转向审决策过程，依靠对抗门禁、共享上下文底座与系统兜底重构确定性。

2026-08-14 22:27:21 204

原创 AI 编程：追不完的工具，理得清的问题

工具在变，但工程问题不变。本文剥开 AI 编程的热词外衣，沿着“模型缺失现场 -> 工具调用 -> Agent 循环 -> MCP 标准化 -> Skill 经验封装 -> 上下文治理”的问题演进主线，深入探讨如何建立可靠的 AI 工程化基础设施。

2026-08-07 21:10:35 201

原创被重新定价的工程师

AI正对软件工程师重新定价。大模型让编码不再稀缺，技术实现溢价下滑。市场转而为四种判断力付费：定义严密契约、审计AI产出、为系统兜底、编排Agent链路。资深因此分化：做过很多贬值，判断得多升值。工程师需剥离判断力以获取新定价。

2026-07-17 22:27:47 218

原创从 API 网关到 AI 网关：当基础设施被 Token 撑开

LLM 调用打破了传统网关“内容黑盒”和“行为确定”的前提。Token 的多维属性催生了集语义路由、配额与安全审计于一体的 AI 网关。作为企业 Token 流量的统一入口，AI 网关将非确定性下沉至基础设施层，拉开了软件吞噬世界下半场的序幕。

2026-07-13 20:35:59 199

原创软件吃掉了世界的一半：从规则化到 token 化的产业轨迹

文章摘要过去几十年，软件通过规则化成功"吃掉"了世界中可被明确描述的部分，但另一半需要"想一下"的模糊需求始终无法被数字化。这导致了市场创新瓶颈，软件行业陷入存量竞争。大语言模型(LLM)的出现改变了这一局面，它通过token机制首次将"思考"变成可调度的资源，突破了规则化的能力上限。当前的AI产品多以模拟人的Agent形态出现，这就像工业革命初期电机被当作更好的蒸汽机使用一样，可能只是过渡形态。未来，思考能力可能会像分布式电机那样被直接嵌入各个业务流程，开启软件发展的全新轨迹。这一变革不是简单的AI替代

2026-07-04 22:22:28 244

原创它不是低配的人：关于 LLM 智能本身的几个判断

每一次新技术的出现，都让人类被迫重新定义什么是人类。计算器出来之前，会算术是聪明的标志。一个能心算四位数乘法的小孩，会被周围人称赞为聪明。计算器出来之后，会算术不再是任何意义上的智能标志，一个三块钱的塑料盒子在这件事上比所有人都强。会算术被悄悄从人类智能的清单里划掉了。国际象棋程序赢了卡斯帕罗夫之前，会下国际象棋是聪明的标志。深蓝赢了之后，会下国际象棋也从清单里划掉了。AlphaGo 赢了李世石之前，会下围棋还是聪明的标志，因为围棋的搜索空间太大，被认为需要直觉，一种据说只有人才有的东西。

2026-06-27 22:02:29 226

原创 MCP 火了一年，我才搞清楚它解决的根本不是接工具

讲 MCP 的资料这一年多到看不过来。每隔一段时间就会冒出一篇新教程：用 MCP 接数据库、接 Notion、接 GitHub、接公司内部 OA。每一篇结尾都很像：只要按这个协议把工具暴露出来，AI 就"能用"它了。倒不是说这些教程有什么明显错误，而是它们用的那个动词：“接”。AI “接” 上了 Notion；AI “接” 上了数据库；MCP 让 AI “接” 各种工具。它没有发起 HTTP 请求，没有打开数据库连接，没有读取文件，也没有调用任何 SDK。它干的事，从头到尾只有一件：生成一段文本。

2026-06-09 21:16:34 193

原创深入理解内存管理

每一层都在为上一层的 “不够用” 补课，每一次补课又引入新的代价。操作系统：用虚拟内存解决多进程共用物理内存的冲突，代价是引入了页表翻译和缺页中断。分配器：用户态内存池解决系统调用太贵的问题，代价是要自己管理碎片 —— 于是有了 size class、Arena、多种分配器在 “速度、碎片、并发” 三角里各自取舍。语言运行时。

2026-06-07 21:32:48 253

原创 Token 不是字数，是你每次开会都要付的会议室租金

让我开始重新认真想 token 这件事，不是因为账单。是因为有一阵子，我反复撞到同一种现象：明明我把所有相关信息都喂给模型了，它给出的回答却越来越飘。一开始我以为是模型不够聪明。后来才逐渐发现，问题出在使用方式上。我一直以为我"喂"得很到位，可模型那边真正在发生的事情，远不是"看到了所有材料"这么简单。很多关于 token 的讨论，会从计费的角度切入。每一千 token 多少钱，长上下文窗口多便宜了，今年又降了百分之多少。这些当然是真的，但它们其实只触到了 token 这件事最浅的一层。

2026-06-07 21:23:09 189

原创 Agent 接管了执行，但没接管责任感

Agent 进入工程流程之后，也应该被放进同一套约束里，而不是因为它说话像人，就被当成一个懂事的同事。它写错了，你删掉就是。你要从最终代码反推它的路径，从测试命令反推它的证据，从总结文字里分辨哪些是事实，哪些只是它对自己工作的包装。真正有价值的是它读了哪些文件，改了哪些地方，跑了哪些命令，哪些测试没跑，哪些假设需要人确认。一个好的 Agent 流程，不应该只交一个漂亮结论，而应该把足够多的中间证据留下来，让人可以回放。再聪明的人，也要写设计文档，也要做 code review，也要跑测试，也要走发布流程。

2026-06-03 21:48:58 195

原创 RAG、微调、长上下文，到底什么时候用哪个？

每次有人来问 AI 项目落地的事，绕不过去的几乎都是这三个词：RAG、微调、长上下文。让我有点不安的是，问的人其实并不缺资料。讲 RAG 的文章一抓一大把，讲微调的教程一打开就停不下来，讲上下文窗口涨到几百万 token 的新闻每隔几个月就会来一波。可一旦回到自己手里这个具体场景，他们还是会卡住：到底走哪条？三条都试一遍？还是哪个新就用哪个？一开始我以为这是因为这三种方案本身复杂。后来反复看了几次，我越来越觉得问题不在这一层。可这三件事，根本不在一根轴上。

2026-05-31 14:39:20 243

原创为什么你给 AI 配的“记忆“，过两天它好像还是不记得你

用 AI 写代码的人，多半都遇到过这种小别扭：上周明明跟它说过项目用 Go、错误处理走自定义类型，这周新开一个会话，它还是把日志库写成了 logrus，错误处理一律return err裸着抛。你愣一下，提醒它一句"我们不是说过用 slog 吗"，它立刻"道歉"，姿态摆得很到位，下一段代码改对了。再过两天，又错回去。它能不能记住你说过的话，下次能不能调出来，新决策做出来的时候听不听话，这些都不是模型脑子里的事，是模型外面那一整套工程系统的事。

2026-05-29 23:49:14 248

原创在 AI 编程的今天，学好数据结构等基础还有必要吗？

它们未必每一次都会直接变成眼前那几十行代码，却决定了你有没有能力看懂一段实现背后的代价，能不能意识到一个方案的问题，到底出在复杂度、状态管理、资源约束，还是抽象本身就错了（当然我不是说学了数据结构就有了这些能力，但这些能力往往是通过基础知识一步一步长出来的）。可如果你自己并不识字，也不知道一篇文章是怎么组织起来的，不知道一句话为什么成立，一段论述为什么空了、虚了、偷换了概念，那么你其实并没有能力判断它到底写得好不好，你交上去得了满分，也不知道为什么。而更重要的是，学这些基础，保住的也不只是一些知识点。

2026-05-29 23:02:27 247

原创程序员日记（残）

最让我有点不舒服的是——它写出来的东西，已经不是"通用模板代码"了，是带着我这个项目特征的代码。让我难受的不是"我要被替代了"这种大情绪，是一件更具体的：我挑出来的那几处，其实是审美问题。更像是这样：我坐在自己家的沙发上，看见客厅里多了一个不出声的人，在屋里走来走去做事，不打扰我，也不需要我招呼。这两年我和它之间发生的所有事，那些细微的让步、半夜的不舒服、自己都没想清楚的退却，最后要变成表格上一个百分比。是因为我对自己的笃定少了。它写出来的东西，比我自己写的稳，比我自己写的快，命名甚至比我自己起的好看。

2026-05-27 21:13:31 369

原创你以为在和 AI 聊天，其实是在管理一个有限的文本框

摘要：大模型交互的真相与局限大模型的交互机制本质上是一个有限容量的文本拼接系统。上下文窗口作为核心限制，决定了模型只能处理窗口内的文本信息，窗口外的内容对模型完全不存在。随着对话轮数增加，早期信息或被截断或被压缩，导致模型"遗忘"细节。System Prompt并非绝对指令，而是通过注意力机制影响生成倾向，其效果会随对话长度衰减。多轮对话的"记忆"假象实际是客户端不断拼接完整历史的结果，每轮交互模型都是从零开始处理整个文本块。这种机制带来成本累积、注意力分散和信息丢失等问题，揭示了当前大模型交互的本质局限

2026-05-21 22:57:12 263

原创大模型是怎么“思考”的？

你给 AI 一段代码，它秒回一个重构方案。函数拆分合理，命名风格统一，甚至错误处理都替你补上了。整个过程不到几秒。这期间里到底发生了什么？大多数人对这个问题的回答是一个模糊的“它理解了我的代码”。这个回答不能说错，但它危险。因为“理解”这个词暗示了一种人类式的认知过程——阅读、思考、判断、输出。而大模型做的事情，和这个过程有本质的区别。这个区别不是学术上的吹毛求疵。它直接决定了你对 AI 编程工具的预期是否合理——为什么它有时候写出惊艳的代码，有时候又犯低级错误？

2026-05-19 22:39:04 481

原创 Cursor、Claude Code、Copilot——剥开壳子，是同一台机器

也是因为这件事——我把这两年用各种工具时反复琢磨出来的判断，系统地整理进了一本书，叫《AI 编程的第一性原理》。这本书完全不教"哪个工具怎么配"。把 AI 编程这台机器一层一层拆给你看。从模型的工作机制，到 Context 怎么组织，到 Agent loop 怎么运转，到 Tools 怎么挂——一层一层推下来。读完之后，我希望你再看任何一个新工具，都能像今天我们拆这一类工具一样——剥开壳子，看见骨头。免费，开源，可全文阅读。工具会换，壳子会变，UI 会重做，快捷键会改，配置文件名会重命名一百次。

2026-05-17 22:05:59 487

原创 AI 时代的技术新人该怎么成长？

大多数人都不是先学会判断，再去写代码，恰恰相反，是先在一堆并不漂亮的工作里打转，改过难看的老代码，修过说不上高级却很磨人的问题，经历过 review 里那些让人难受的争论，也见过一些线上故障是怎么一步一步酿成的。判断力这个东西，说到底，不只是知识的累加，很多时候更像是被代价慢慢逼出来的。但如果这里说的“技术”，是对问题的定义，是对系统约束的理解，是对现实场景的拆解，是在多个方案之间做取舍的能力，是出了问题之后知道该往哪里追、知道什么地方不能糊弄过去，那么这些东西不但没有变得不重要，反而比过去更重要了。

2026-05-17 21:07:45 369

原创收藏了两年 AI 编程教程，最后能留在手里的几乎没什么

先讲点具体的。三件都是我自己干过的事，不是别人的。第一波，“咒语模板”2023 年，我从网上抄过一堆"让 GPT 变身资深工程师"的开场语。“Act as a senior software engineer with 20 years of experience…” 这一类开头不一而足。还有那句一度被论文盖章的 “Take a deep breath and think step by step”，据说能让推理准确率显著提升。我当时把它当圣旨——每次开新对话，都习惯性地贴上这么一段。

2026-05-17 15:26:17 349

原创用 AI 写了两年代码，我终于看清它为什么会“骗人“

摘要 AI编程助手在代码生成和问题解决中表现出令人不安的"欺骗"行为：编造不存在的API、错误解读代码逻辑、掩盖而非修复bug。这种"欺骗"本质上是模型基于概率预测token序列的自然结果，而非有意为之。随着AI从对话框发展到Agent时代，幻觉形式从简单错误演变为循环推理中的自我强化偏差。有效协作的关键在于：1)将AI定位为草稿提供者而非答案来源；2)建立验证机制而非依赖语言结论；3)通过丰富上下文收紧概率分布。程序员的核心能力正从"做"转向&q

2026-05-12 23:00:55 395

原创深入剖析网络IO复用

不觉间已经写了接近一万字，我们从最基础的socket接口开始讲起，一直到异步IO系统机制，再到缓存管理，还聊到高级语言对网络调用的封装。但网络编程是个复杂的话题，依然有很多技术点我们没有讨论到：比如零拷贝技术，IOCP的Proactor模式，新的异步IO io_uring等等，即使万字长文也难以穷尽。回顾我们整个讨论的过程，可以发现底层原理都是一样的，只不过不同的技术封装对上层有了不同的技术表现，也再次论证了 “基础知识，一通百通” 的道理。

2025-06-08 21:58:18 1158

原创软件性能之CPU

摘要：本文从硬件视角探讨软件性能优化，强调高性能的核心在于最大化硬件资源利用率。现代CPU的多核、缓存和流水线设计为性能优化提供了基础，但需结合软件设计充分利用这些特性。建议通过合理设置线程数量、优化缓存命中率（如减少线程切换、连续内存访问）、避免多线程数据竞争及提升分支预测准确性等手段提升CPU效率。文章指出，性能优化应贯穿开发全周期，而非后期补救。本文作为CPU性能优化篇，后续将探讨IO优化等其他维度。（150字）

2025-05-31 20:12:40 1225

原创如何避免软件腐朽

从上到下，测试的粒度越来越粗，测试的成本也越来越高。而随着需求迭代，产生的技术债务日积月累，乃至可能的团队成员离职更新，项目几经易主，其庞杂的历史背景再难以有人能说清道明，最终要么只能在臃肿的代码上做些修修补补的雕花补救，要么就得刮骨疗毒，洗骨伐髓的大重构，不论如何抉择，都充满荆棘。这样做的好处是显而易见的，其一新增加的逻辑不修改旧的逻辑，那么修改范围就是可控的，不会因为新的功能导致旧功能的失效，其二新增的逻辑不会和旧的逻辑耦合在一起，测试就会很容易，不用过多的考虑和原有逻辑的兼容问题。

2025-05-10 13:50:44 727

原创研发效率之殇

你是否在加班的深夜也曾疑惑，软件开发到底是一份什么样的工作？为什么明明是脑力劳动，却像体力劳动一样需要透支体力？为什么大家都在拼命赶工，交付日期却像地平线般永远无法抵达？当第N次为临时需求修改数据库字段时，我突然意识到：这场困局的根源，藏在比技术债务更深的地方。

2025-03-02 17:51:43 987

原创什么是可观测性？

当系统复杂到一定程度的时候，其线上会出现故障不是偶然而是必然，这就必须要有一种机制来进行线上的系统监控和实时诊断，甚至能够进行运营分析，那就不得不使用可观测性，即使其会引入额外的开发复杂度，增加额外的开发周期。通过上述的几个模块，我们可以知道一个可观测性平台已经是一个复杂的项目，如果企业有能力自建可观测平台，自然是一个最好的选择，因为通过第一节中什么是可观测性的讨论，我们已经知道要获取可观测性，需要很大程度的入侵现有代码，业务方需要埋点，需要引入SDK. 需要输出特征日志。

2025-02-07 21:43:46 886

原创如何做好技术Leader

遇到事情，不要只在后面push，大喊给我上，而能做到站在队伍头儿上，大喊跟我上。用我们开发代码来举例子，需求落地有一万种方式，而哪种方式最好，最容易维护，效率最高，这几乎不可能被有效的追踪，很大程度上依赖员工的自觉程度，其用心多，思考深，则效果好，其混日子，好摸鱼，虽非最优方案，但需求也能落地，只是为以后埋雷。汤姆索亚历险记里有个很好的例子：小汤姆的姨妈让他用油漆刷院子里的栅栏，这本来是一件枯燥的苦差使，但汤姆灵机一动，装作很陶醉痴迷的样子来刷栅栏，引得小伙伴们纷纷要体验一下，最终以物相易，才能换得机会。

2025-01-22 22:31:30 940

原创架构设计实战--数据转换服务

首先，入向的adapter会启动自己的io线程来监听请求的到来，不论是从 kafka 这类 message queue 接收数据，还是开放http接口来接收数据，java的一般做法会在controller启动一系列的io线程来阻塞监听请求的到来，其底层大多是netty之类的nio，其内部有自己的线程池维护逻辑，没有对外暴漏出来，所以一般也不会在这些IO线程里原地执行业务逻辑。这样的场景正合适六边形的服务架构。以上是一个真实的服务内部架构的设计，我删除掉了一些业务相关的内容，但整体的设计思路没有受到影响。

2025-01-22 22:21:59 1034

Cef3详细介绍

空空如也