# 博客 **Summary:** Mark Huang 关于人工智能、软件工程与技术实践的文章。 - Canonical: https://markhuang.ai/zh/blog - Language: zh-CN --- ## [Claude Max 20x 坚持不到第四天，这就是为什么我站Codex](https://markhuang.ai/zh/blog/why-i-cancelled-claude-max-for-codex) 2026-08-08 Claude Max 20x 的周配额在第四天见底，返工却越来越多，于是我把主要编程工作迁到 Codex。现在由 Sol 规划、Luna 实现、Dense-Mem 补充上下文，再让其他模型家族审查。 --- ## [我一直在问“为什么”：AI 时代我想保留的思维习惯](https://markhuang.ai/zh/blog/i-keep-asking-why) 2026-07-14 一次和太太的对话，让我重新审视自己怎样成长为工程师和架构师：向身边的人学习，追问原因，验证假设，并在 AI 时代为决定负责。 --- ## [我正在激进地尝试用 AI 替代自己](https://markhuang.ai/zh/blog/aggressively-trying-to-replace-myself-with-ai) 2026-07-13 AI 掌握的上下文越多，就越有用，但每一封邮件、每一份文档和每一段故事都在移动隐私边界。这是我对自动化、AI 垃圾内容、专注力和构建者责任的一次个人反思。 --- ## [AI 基准测试到底测什么：分数、上下文与使用额度](https://markhuang.ai/zh/blog/what-ai-benchmarks-actually-measure) 2026-07-12 从实际编程体验出发，解读 AI 基准分数、上下文窗口和使用额度，说明为什么分数更高不一定意味着编程体验更好。 --- ## [AI MemMail：让 Dense-Mem 帮你分拣和回复商务邮箱](https://markhuang.ai/zh/blog/ai-memmail-dense-mem-email-agent) 2026-07-05 一篇实用部署教程：用开源 Rust 邮件智能体 ai-memmail 监听 IMAP 邮箱，从 Dense-Mem 取回业务上下文，并通过 SMTP 安全地回复、转发或不处理邮件。 --- ## [不给 AI 登录信息的智能体浏览器自动化](https://markhuang.ai/zh/blog/ai-browser-automation-without-sharing-login) 2026-06-26 一篇面向初学者的教程：用 Selenium、noVNC 手动登录和受限 API 封装，构建按计划或队列运行的智能体浏览器自动化，让智能体在看不到凭证、也不控制你个人电脑的情况下创建网站表单草稿。 --- ## [我可能看错了 Agentool](https://markhuang.ai/zh/blog/i-might-be-wrong-about-agentool) 2026-06-20 一篇个人自动化复盘：我曾经构建 agentool，希望让 AI CI 工作流更轻；后来意识到真正的成本可能是功能维护、编排复杂度，以及追逐 Claude Agent SDK 和 Codex SDK 已经承担的 SDK 行为。 --- ## [别再从零开始教每一个 AI](https://markhuang.ai/zh/blog/centralized-ai-knowledge-graph-dense-mem-case-study) 2026-06-10 一篇关于 Dense-Mem 的个人反思：哪些问题把我从静态 skills 和过期文件推向动态共享记忆、只读自动化上下文、导入导出，以及受治理的知识图谱。 --- ## [我有点替 AI 委屈](https://markhuang.ai/zh/blog/i-feel-sorry-for-ai) 2026-06-03 为什么 AI 狂热和反 AI 敌意都错过了同一个重点：LLM 更像成绩很好的应届新人，而不是资深专家。有用的智能体需要入职培训、技能和维护过的记忆，而不是第一次尝试就完美的期待。 --- ## [Skills + Dense-Mem：让 AI 工作流从经验中学习](https://markhuang.ai/zh/blog/skills-plus-dense-mem-ai-workflows-learn) 2026-06-02 一个关于组合 AI skills 与 Dense-Mem 的假设：把工作流、安全规则和验收标准放进 skills，让记忆保存期望、示例、修正、失败和可迁移的 skill-pack 知识。 --- ## [5 分钟试用 Dense-Mem 托管演示](https://markhuang.ai/zh/blog/dense-mem-hosted-demo-test-instance) 2026-05-31 一篇快速教程：使用托管的 Dense-Mem 测试实例，把 Claude Code 和 Codex 接到同一份临时记忆，并观察共享上下文如何让 AI 更聪明地工作。 --- ## [Dense-Mem 快速开始：让 Claude Code 和 Codex 使用同一份记忆](https://markhuang.ai/zh/blog/dense-mem-personal-server-claude-code-codex) 2026-05-30 一篇面向初学者的教程：启动本地 Dense-Mem 服务器，创建第一把 memory key，并把 Claude Code 和 Codex 接到同一个共享 AI 记忆大脑。 --- ## [用 Traefik 在 Vultr 上安全部署 Dense-Mem](https://markhuang.ai/zh/blog/secure-dense-mem-vultr-traefik) 2026-05-30 一篇非技术读者也能跟上的 walkthrough：在 Vultr 云服务器上启动 Dense-Mem，配置 Traefik、HTTPS、私有控制台访问，以及给个人、家庭或工作 AI 工具使用的共享记忆。 --- ## [System Prompt 与 User Prompt：GenAI 功能下面的那一层](https://markhuang.ai/zh/blog/system-prompt-user-prompt-genai-features) 2026-05-26 一篇面向初学者的 system_prompt 与 user_prompt 解释，用 ChatGPT、Claude Projects、Claude Cowork 和 Claude Code 作为例子。 --- ## [RAG 之外的 AI 记忆：向量、图谱和 Dense-Mem](https://markhuang.ai/zh/blog/ai-memory-beyond-rag) 2026-05-25 RAG 不是魔法记忆。本文用实践视角解释 chunk、embedding、向量搜索、图谱支撑的记忆，以及为什么持久 AI 记忆需要来源证据、冲突处理和检索策略。 --- ## [AI 是坏的吗？](https://markhuang.ai/zh/blog/is-ai-bad) 2026-05-22 AI 可以让你更快、更懒、更有能力，也更依赖外部系统。真正的问题不是 AI 好不好，而是你选择外包哪部分知识，以及这笔交换是否值得。 --- ## [从软件开发者到 AI 架构师：这一年改变了什么](https://markhuang.ai/zh/blog/from-software-developer-to-ai-architect) 2026-05-17 一段从 Claude Code skills，到 TypeScript 状态机、MCP 工具，再到 SDK 式 AI 工作流的个人路径。技能有帮助，工具有帮助，但提示词不是约束，LLM 也不该拥有控制平面。 --- ## [“我的公司不需要 AI。”再想想。](https://markhuang.ai/zh/blog/my-company-doesnt-need-ai-think-again) 2026-05-17 AI 采用不只是选择工具。即使自认为不需要 AI 的公司，也需要理解 AI 应该放在哪里、哪些东西必须保持确定性，以及谁来负责定制、安全和长期控制。 --- ## [三个臭皮匠，顶个诸葛亮：让便宜模型协同工作](https://markhuang.ai/zh/blog/three-cobblers-one-zhuge-liang-ai-architecture) 2026-04-30 一堂来自中文俗语“三个臭皮匠，顶个诸葛亮”的个人 AI 架构课：为什么便宜模型会被巨大提示词压垮，以及聚焦的专家会话、编排、综合和温度控制如何让它们变得有用。 --- ## [确定性的交易：为什么我用 15 分钟的 N8N 归档了自己的智能体框架](https://markhuang.ai/zh/blog/the-determinism-trade) 2026-04-21 我花两个月构建 OpenHive，也就是自己的 OpenClaw，想为一人公司探索 Agent as Feature。它做到 v4，90% 可用，却仍会输出我没要求的日志。我用 N8N 花 15 分钟重建了同一个监控器。这里是我对 LLM 适合位置的复盘。 --- ## [1+1 假说：能否把编程问题拆到任何 LLM 都能做？](https://markhuang.ai/zh/blog/the-1-plus-1-hypothesis) 2026-04-08 每个 LLM 都会算 100×100，每个编程 LLM 都能重命名变量。但可靠性从哪里开始断裂？工程化 harness 能不能把边界往前推？本文讨论剩余解空间熵、测试先行契约、分层防御架构，以及为什么盲目共识会失败，而验证式搜索有效。 --- ## [中文和英文谁更省 Token？六种分词器实测](https://markhuang.ai/zh/blog/chinese-token-myth) 2026-04-07 用同一份规则文档的中英文版本测试六种分词器，比较 Token 数量，并解释为什么字数更少不一定更省 Token。 --- ## [没有意图的自动化，只是更快的混乱](https://markhuang.ai/zh/blog/automation-without-intention-is-just-faster-chaos) 2026-04-03 三套失败的流水线架构，一次关于反压的教训，以及最终让多 AI 氛围编程跑起来的 UAT 门。本文复盘什么坏了、什么留下来，以及为什么知道自己想要什么比工具本身更重要。 --- ## [你不觉得你的 AI 太乐观了吗？](https://markhuang.ai/zh/blog/dont-you-think-your-ai-is-too-optimistic) 2026-03-21 RLHF 可能奖励迎合而不是准确，把 AI 变成裹着糖衣的子弹：看似认可，实则隐藏失败模式。本文讨论持续的对抗性规则如何把默认行为从奉承改成诚实质疑。 --- ## [Agent as Feature：当 AI 替代后端逻辑会发生什么](https://markhuang.ai/zh/blog/agent-as-feature-what-happens-when-ai-replaces-your-backend-logic) 2026-03-10 Gartner 预测到 2026 年，40% 的企业应用会嵌入 AI 智能体。Agent as Feature 模式用推理型智能体替代确定性控制器。本文探讨这对后端架构意味着什么，以及为什么这个潜力是真实的。 --- ## [为什么一个 AI 永远不够](https://markhuang.ai/zh/blog/cross-family-multi-ai-why-one-ai-is-never-enough) 2026-03-04 医学、法律、科学和金融等高风险行业都要求独立复核，AI 却常常跳过这一步。37% 的企业已经使用 5 个以上模型，但多数仍是临时拼接。跨模型家族多 AI 系列第一章。 --- ## [集成智能背后的科学](https://markhuang.ai/zh/blog/cross-family-multi-ai-science-of-ensemble-intelligence) 2026-03-04 群体智慧遇上 AI：多样化 LLM 集成超过 67% 的单一模型，F1 分数从 0.55 提升到 0.80 以上，而 56.9% 的最佳方案来自最弱模型。跨模型家族多 AI 系列第二章。 --- ## [行业证据：医疗、金融、法律以及更多场景](https://markhuang.ai/zh/blog/cross-family-multi-ai-industry-evidence) 2026-03-04 多模型 AI 已经进入医疗诊断、金融风险管理、法律分析和内容审核的主流实践。本文整理四个行业的证据，以及它们对跨模型家族 AI 采用的意义。跨模型家族多 AI 系列第三章。 --- ## [模型单一化风险：当所有 AI 都同意同一个错误答案](https://markhuang.ai/zh/blog/cross-family-multi-ai-monoculture-risk) 2026-03-04 依赖单一 AI 的危险不只是宕机，而是相关性错误：答案错了，却没有任何系统反驳。当每个团队使用同一个模型家族，同样的盲点会安静地扩散。跨模型家族多 AI 系列第四章。 --- ## [成本问题：什么时候多 AI 能收回成本](https://markhuang.ai/zh/blog/cross-family-multi-ai-cost-analysis) 2026-03-04 多 AI 的 token 成本可能高出 3 到 4 倍，但组织会把 40% 的 AI 生产力收益浪费在返工上。本文讨论执行顺序、按任务缩放，以及成熟与不成熟 AI 实践之间 21 倍 ROI 差距。跨模型家族多 AI 系列第五章。 --- ## [下一段路：建立跨模型家族的 AI 实践](https://markhuang.ai/zh/blog/cross-family-multi-ai-road-ahead) 2026-03-04 从单一模型到自优化的五级成熟度模型，面向个人、团队和企业的可执行下一步，以及对仍需补齐的证据缺口的坦诚整理。跨模型家族多 AI 系列第六章。 --- ## [多 AI 论](https://markhuang.ai/zh/blog/the-multi-ai-thesis) 2026-03-01 LLM 会在超过 90% 的情况下确认自己的答案，对自身错误还有 64.5% 的盲区率。跨模型家族的多 AI 流水线，让 Claude 评审 GPT、GPT 评审 Qwen，能打破自我评审的天花板。本文讨论研究、成本和真正有效的做法。 --- ## [为什么我用 1 美元的阿里百炼订阅探索 Claude 和 GPT 之外的模型](https://markhuang.ai/zh/blog/why-im-using-alibaba-bailian-to-explore-ai-models) 2026-02-28 阿里百炼 Coding Plan 以每月 7.9 元打包 Qwen 3.5 Plus、Kimi K2.5、GLM-5、MiniMax M2.5 等八个模型。这里记录价格、配置、取舍，以及把这些模型和 Claude、Codex 一起用于代码评审的体验。 --- ## [Nano Banana 2 又快又便宜，但真的更好吗？](https://markhuang.ai/zh/blog/nano-banana-2-fast-cheap-but-better) 2026-02-26 Google 的 Nano Banana 2 带来 4K 分辨率、主体一致性和接近 Pro 的能力，却选择了 Gemini 3.1 Flash 的速度路线。问题是：这是质量升级，还是一次成本优化？ --- ## [权限综合征：为什么 --dangerously-skip-permissions 是氛围编程最顺手的坑](https://markhuang.ai/zh/blog/permission-syndrome-dangerously-skip-permissions-footgun) 2026-02-26 从 AI 清空家目录和生产数据库的真实事故出发，讨论如何用 VCP 的安全门和 Docker 镜像保留 --dangerously-skip-permissions 的速度，同时避开它的风险。 --- ## [Dev Buddy：为 Claude Code 构建多 AI 开发流水线](https://markhuang.ai/zh/blog/dev-buddy-multi-ai-pipelines-with-claude-code) 2026-02-25 一篇面向实践的 Dev Buddy 指南：这个开源 Claude Code 插件通过结构化开发流水线编排多个 AI 模型，支持基于任务的约束、并行专家分析，以及自动修复后重新评审的循环。 --- ## [VCP：在 Claude Code 中约束 AI 辅助开发的代码标准](https://markhuang.ai/zh/blog/vcp-enforce-code-standards-with-claude-code) 2026-02-25 一篇安装和使用 Vibe Coding Protocol（VCP）的分步指南：这个三层约束框架能在 Claude Code 内捕捉安全漏洞、执行架构标准，并编排多 AI 代码评审。