2026-05-09 16:00:00
写代码是便宜的，验证是贵的。但验证的本质是什么？
上一篇笔记讲了 AI Coding Team 的管理方法——马斯克守底线、黄仁勋守质量、雷军守价值。但那篇更偏”怎么做”，这篇要深入”为什么”。
起因是读到孔某人的文章《大组织内的AI Coding过度推行是一种饮鸩止渴》，里面提到美团31万行代码AI重构的困境：AI Coding让代码产出速度暴增，但系统复杂度增长得更快，团队的维护能力跟不上。
这让我重新思考一个根本问题：验证系统的第一性原理到底是什么？
先区分两个容易混淆的概念：
两者的关系：认知是预期的基础。如果认知本身就偏了，预期必然偏。
关键区别：验证只能观测当下，不能观测未来。 跑一个测试，你观测的是此刻代码的行为，跟此刻你对代码行为的认知之间的差距。用当下的观测去推断未来——那是推断，不是验证。
所以严格来说：
不确定性 = 认知与现实的差距
预期是派生的。修正认知偏差是根本。
验证做的唯一一件事：拿现实来校准认知。校准完了，认知更接近现实了，不确定性就降低了。
减少不确定性，不是让认知去匹配现实，也不是让现实去匹配认知，而是两者共同收敛到一起，凝固下来。
产品开发是两者的交替循环：认知→建造→观测→更新认知→再建造……直到两者凝固——认知稳定了，现实也稳定了。凝固不是永久的，下一轮迭代可以重新打回流体态。
验证的严格程度，应该正比于：
验证强度 ∝ 不确定性 × 失败代价
AI Coding改变了什么？它大幅增加了”不确定性”这一侧——因为AI写的代码你不完全理解，而且产出速度极快，不确定性在以指数级累积。但”后果严重性”没有变。
所以：如果验证强度不变，风险就在指数级增长。
不确定性在整个系统内是分层的：
第1层：方向/意图不确定性（根源）
“做出来的东西是不是我真正需要的？”
不确定性最大，影响最深远。美团的问题本质在这里——AI Coding让PM提出更多低质量需求，模糊的、实验性的需求都进了生产系统。代码写得再正确，方向错了也是浪费。
第2层：设计不确定性（桥梁）
“设计能不能支撑实现和未来扩展？”
AI写代码的特点是：每段局部都是合理的，但全局结构会逐渐腐化。因为AI没有”系统全局观”——它看的是当前上下文窗口里的内容，不是整个代码库的架构。
第3层：实现不确定性（执行）
“代码是不是按设计在运行？”
这是最直观的一层——单元测试、集成测试、CI/CD。AI Coding放大的主要是这一层的产出速度。
关键洞察：AI Coding放大的是第3层的产出速度，但第1层和第2层的不确定性没有同步降低。 这就是美团困境的本质——代码写得快了，但设计质量没有跟上，需求质量没有把关。
意图只存在于人的脑子里，是内部状态，外部世界观测不到。要把意图从一个脑袋传到另一个脑袋，唯一的通道是符号化表达——语言、文字、图示。
所以：意图传递的唯一通道是沟通。讨论（广义的）是唯一方法。
但讨论有一个根本性缺陷：语言无法自我验证。 你说了一段话，对方说”我理解了”，你没有证据表明对方的理解和你的意图一致。
有效的方法：让对方把理解的东西具象化成可观测的产物，然后你验证这个产物。
你的意图（不可观测）
↓ 讨论传递
对方的理解（不可观测）
↓ 具象化
产物（可观测！）——复述、设计文档、原型
↓ 你验证
发现偏差 → 再讨论 → 再具象化 → 再验证 → ……
核心原则：永远不要问”你理解了吗？”——要问”你觉得这个需求是什么？说给我听。” 前者是噪声，后者是信号。
认知中存在”我不知道我不知道”的盲区。无法直接消除，但可以通过碰撞间接暴露：
极端化推演：把需求推向极端，看哪里断裂。用极端场景作为探针，探测认知的边界。
红队思维：故意攻击需求。问”为什么要做这个？不做会怎样？” 每一个”为什么”都在从不同角度照射意图，暴露隐含假设。
多元视角：从用户视角、技术视角、商业视角分别审视。每个视角是一束光，照到认知中不同的暗区。
你的全部认知可以分为两层：
不稳定层：意图、方向、业务判断。随需求和场景变化，每个项目都不同，需要注意力持续投入。
稳定层：设计审美、工程标准、架构原则。来自多年经验，跨项目基本不变，已经凝固。
注意力是稀缺资源。 稳定层如果每次都靠人工审查，就是浪费注意力。应该把它固化成验证系统，让AI自动执行，注意力就解放出来，只关注不稳定层。
转化过程：
凝固认知（主观）
↓ 表达成规则
客观规则（可形式化）
↓ 编码成工具/流程
验证系统（可自动执行）
验证系统不是规则的集合，是一个系统——有组件、有流程、有反馈、有边界。
检查器（Checker）：自动执行的判断，不需要人参与。类型检查、lint、自动化测试、安全扫描。
审查器（Reviewer）：需要判断力的审视，AI执行，人审查结论。AI交叉代码审查、架构审查、设计审查。
流程（Process）：事情必须按什么顺序走，每个节点有准入和准出条件。设计评审流程、合并流程、发布流程。
反馈环（Feedback Loop）：从结果中学习，更新系统本身。线上bug回溯→更新检查规则。
L1 自动检查层（零人工成本）：类型检查、lint、测试、安全扫描
L2 AI审查层（低人工成本）：架构审查、设计审查、代码审查
L3 流程守护层（中人工成本）：设计评审、合并审批、发布流程
L4 人工层（高人工成本）：方向判断、意图确认、异常处理
越底层越频繁、越自动化、越不消耗人。越顶层越稀少、越需要判断力、越消耗人。
原则1：从失败中生长，不是从蓝图中设计。 不要试图一次性设计完美的验证系统。让系统在实际运行中，从每一次失败里学到规则。问题→追溯→加检查→系统进化。
原则2：检查器优先于审查器，审查器优先于人工。 能自动化的自动化，不能自动化但可重复的让AI执行，需要判断力的人来做。进化方向：把审查器不断降级为检查器。
原则3：验证失败必须有反馈回路。 验证系统的价值不在于找到问题，在于让同类问题不再发生。修了→追溯根因→更新规则→同类问题永不再犯。
原则4：SOP是验证系统的操作手册。 精确定义：谁触发→做什么→输入什么→输出什么→谁检查→不通过怎么办。
原则5：系统的边界。 反复出现的问题、代价高昂的失败、AI容易犯的系统性错误——值得验证。一次性问题、代价极低的失败——不值得验证。
实际操作中，我把流程简化为两个阶段：
阶段1：意图+规划 — 我和一个AI直接讨论，讨论到认知凝固，产出意图文档和蓝图。
阶段2：设计+实现 — 分配给多个AI并行工作。各自做详细设计→互相review→实现代码→提PR→自动检查+交叉review→合并→部署测试环境→我体验验证。
关键设计：
整个系统不需要自建基础设施，用GitHub原生工作流就够了：
仓库本身就是上下文。每个Agent clone仓库后，意图文档、蓝图、其他模块的设计文档都在里面。不需要额外的”上下文推送”机制。
第1代：你直接和一个AI讨论+实现，验证靠你自己
↓
第2代：你讨论，分配给2-3个AI并行实现，简单PR review
↓
第3代：从问题中长出新机制
- 接口对不上？→ 加接口契约检查
- Review质量低？→ 加上下文自动推送
- Agent卡住？→ 加阻塞自动上报
↓
第4代：大部分验证自动化，你只在意图层和异常时介入
验证系统的第一性原理可以归结为一句话：
验证的本质是减少不确定性。不确定性 = 认知与现实的差距。
所有验证方法——测试、review、CI、讨论对齐、用户反馈——都是在做同一件事：用观测来缩小认知和现实之间的差距。
在这个AI Coding的时代，写代码越来越便宜，但认知和现实之间的差距不会自动缩小。你的价值从”能写代码”变成了”能定义正确的问题”和”能建验证系统来保证答案是对的”。
黄仁勋说得对：写代码是便宜的，验证是贵的。但更准确的说法是——写代码是AI的事，验证是你的事。
2026-05-02 16:00:00
不审查代码，审查系统。不信任代码，信任验证。
我写代码几乎 95% 以上是让 AI 写的。Python 后端我可以仔细 review，发现问题让 AI 改。但对于不熟悉的领域——比如 APP 开发、C++、Rust——我没法逐行审查。随着 AI 越来越强，多个 Agent 并行开发，代码量远超我能看的范围。
核心问题：注意力有限，如何保证交付质量？
答案是：从”审查代码”转变为”验证行为”。
马斯克管理 SpaceX 的方式——他不懂每个零件的制造细节，但他知道物理极限。
他的方法是第一性原理 + Failure Mode Analysis。不管方案多漂亮，他只问一个问题：
最坏情况是什么？
他常说的话：
映射到软件——你不需要 review AI 写的 Rust 代码，但你能判断方案在系统层面是否合理：
具体执行：让 AI 做 failure mode 分析，你 review 分析结果，不做取舍决策（速度 vs 质量 vs 成本）。
黄仁勋最核心的一个数字：NVIDIA 验证工程师的数量是设计工程师的好几倍。
他的哲学：写代码（设计）是便宜的，验证是贵的。不要试图理解每个细节，但要保证验证系统覆盖每个细节。
对应到 AI 团队管理——先建验证基础设施，再让 AI 干活：
每个任务的标准流程：
你只看两样东西：验证覆盖率 + 最终通过/失败报告。
核心理念：一个人检查所有人的代码不可扩展，但一套检查系统可以无限扩展。
雷军跟黄仁勋完全不同的思路。黄仁勋建验证体系，雷军会说你搞得太工程师思维了。
雷军的哲学就七个字：专注、极致、口碑、快。
他的做法是基本可用就发布，让用户告诉你哪里不对。MIUI 早期版本 bug 多到离谱，但每周发一版更新，用户疯狂反馈，团队跟着改。
具体执行：
自动化测试验证不了的东西——体验、交互、需求真伪——只有真人能告诉你。
最好的 review 是用户的投诉。
三个人分别守住不同的维度：
| 马斯克 | 黄仁勋 | 雷军 | |
|---|---|---|---|
| 守住 | 底线 | 质量 | 价值 |
| 防止 | 出大事才知道 | bug 率失控 | 做一堆没用的 |
| 核心动作 | 问最坏情况 | 建验证体系 | 问用户反馈 |
| 关键问题 | 会炸吗 | 测到了吗 | 有人用吗 |
缺任何一个维度都不行：没有马斯克，系统出大事才知道；没有黄仁勋，bug 率控制不住；没有雷军，做了一堆没用的东西。
不是自己写文档，是跟 AI 讨论、拍板、让 AI 写。
你脑子里有想法/方向
↓
跟 AI 讨论（可能多轮）
"我觉得应该用事件驱动，你觉得呢？"
"并发场景下消息顺序怎么保证？"
AI 回复 → 你追问 → AI 补充 → 你再质疑
↓
你拍板："就这个方案，XX部分用A方案，YY部分用B方案"
↓
AI 写架构文档、接口定义、技术方案
↓
你 review 文档（确认 AI 有没有理解对你的决策）
↓
确认无误，文档就是开发契约
时间分配：
你的核心竞争力不是”写文档写得漂亮”，是讨论过程中暴露出来的判断力和决策力。就像 CEO 不会自己写 PPT——CEO 提供观点和判断，秘书（AI）负责整理成文档。
Agent A 写代码（sonnet 级别）
Agent B 写测试（sonnet 级别）
Agent C review 代码（opus 级别，不同 prompt）
Agent D review 测试覆盖度（opus 级别）
自动 CI pipeline 跑一遍
全绿 → 合并，红灯 → 信息回到 Agent A 重做
你只需要看最终的通过/失败报告 + review AI 输出的 review 结论摘要。
25% 跟 AI 讨论架构和方案 ← 核心：讨论、质疑、拍板
15% review AI 写的文档/接口定义 ← 确认 AI 理解对了你的决策
15% 跟 AI 对话质疑执行方案 ← 第一性原理问问题
15% Review 验证结果和报告 ← 测试覆盖率、CI 状态、运行指标
10% 端到端手动验证 ← 把自己当用户走一遍
10% 看关键代码，保持直觉 ← 极少数情况
10% 业务决策、外部协调 ← 跟真人相关的事
| 情况 | 该怎么做 |
|---|---|
| 不熟悉 AI 用的语言 | 只看测试结果和 CI 报告，不看代码 |
| 多个 AI 并行开发 | 先建好验证体系，再让他们开工 |
| 不确定 AI 写的对不对 | 问 AI “失败模式是什么” |
| 不知道功能该不该做 | 先做最小版本给用户，用反馈决定 |
| 代码量太大看不过来 | 专注看架构图和数据流，不看实现 |
| AI 写的代码有性能问题 | 看 profiling 结果，不看代码本身 |
| 担心安全漏洞 | 配好 SAST 扫描和 dependency audit |
| 不知道质量如何 | 看测试覆盖率和线上监控指标 |
你的角色不是不懂技术的 PM，是懂物理定律的系统架构师。
PM 只管”要做什么”，你管”怎么做才不会炸”。你不是在管理一群程序员，你是在建设一个质量保障体系，然后让 AI 在这个体系里自由发挥。
2026-02-23 16:00:00
当 AI 大模型推理速度突破 5000 tokens/s，Agent 的 Re-Act 循环进入毫秒级时代，一个物理铁律浮出水面：有限的上下文窗口（200K~1M tokens）将在几十秒内被“思考”与“日志”填满。现有的“追加历史记录”模式瞬间失效，因为这无异于试图用容量极小的 L1 缓存去存储整个程序运行周期的所有数据流。
这一矛盾决定了 AI Agent 的技术终局：上下文窗口必须从“聊天记录堆”重构为“CPU 寄存器堆”。未来的 Agent 架构不再是简单的对话流，而是类似于操作系统的状态机循环——Context Window 只保留当前指令指针和核心状态寄存器，通过严格的“状态覆盖”替代无脑的“日志追加”，用信息熵减对抗数据洪流。
真正的瓶颈在于 LLM 的核心物理限制——上下文窗口容量。即便模型能力不断提升，上下文窗口从 200K 扩展到 1M，它依然是一个有限的物理容器。试图通过无限扩大窗口来承载 Agent 无限运行产生的日志，无异于试图用一杯水去接一条不断流淌的河。
我们必须从 Transformer 的本质出发，承认一个残酷的现实：Transformer 是无状态的，它通过重放历史来模拟状态。 如果 Agent 要像操作系统进程一样长久、稳定地运行，我们必须彻底重构它的运行模式。
本文将提出一种新的架构范式：将 AI Agent 从“文本补全机器”重构为“状态机循环”，并将其类比为汇编语言与 CPU 架构，以此解决上下文爆炸的根本问题。
目前的 AI Agent 大多基于 Re-Act 模式，其运行逻辑本质上是“日志驱动”的：
这种模式的问题在于，为了维持“状态”，模型必须保留所有“过程”。这就像 CPU 为了执行下一条指令，必须把过去执行过的所有指令记录都读一遍。随着时间推移，Context Window 必然溢出，或者因注意力机制的 $O(N^2)$ 复杂度导致计算崩溃。
操作系统的启示： 在计算机体系结构中，CPU 执行指令只依赖两个东西：
CPU 不关心上一毫秒执行了什么，只关心当前状态。Agent 也必须如此。
如果我们将 Agent Loop 视为一段汇编程序，那么大语言模型（LLM）本身不再是那个无所不知的“大脑”，而是一条极其复杂的“状态转移汇编指令”。
在这个模型下：
Agent 的运行模式应当从“追加日志”转变为“寄存器操作”。每一次推理，都是一次 “状态读入 -> 计算 -> 状态写回” 的过程。
既然 Context Window 是昂贵且有限的“寄存器”，我们就不能像写流水账一样随意填充。必须像设计 CPU 寄存器一样，对其进行严格的分区和结构化设计。
我们将 Context Window 划分为固定的“槽位”，每个槽位承载特定的功能：
.text 段：指令区（只读）这是 Agent 的内核代码，定义了 Agent 的行为逻辑。
[Goal] Fix Bug #404
[Step 1/3] Read main.py (Done)
[Step 2/3] Locate error line -> [Current IP]
[Step 3/3] Apply fix
R_IP 即可知晓“我在哪，要去哪”，无需回溯历史。.data 段：数据区（读写）这是 Agent 的工作台，也是上下文工程的核心。
{
"task_status": "debugging",
"open_files": ["main.py"],
"error_line": 102,
"key_variables": {"user_id": null}
}
.stack 段：调用栈R_State 和 R_IP 压栈。任务结束后弹出恢复。基于上述架构，Agent 的 Re-Act Loop 变成了一个标准的 CPU 指令周期。这个过程的核心在于 “信息压缩”。
注意力机制聚焦于 R_IP 和 R_State。模型不需要知道“之前发生了什么”，只通过当前状态判断“现在该做什么”。
模型根据 R_System 的规则，分析当前状态是否需要调用工具，或者是否需要更新内部状态。
模型输出两部分内容：
Read_File）。Update_State）。这是解决上下文爆炸的关键步骤：
R_Working。R_Working，提取关键信息（如“错误在第 500 行”），生成 Delta_State 更新 R_State。R_Working 中的原始数据。结果：10,000 行的日志被压缩成了 R_State 中的一个字段 "error_line": 500。上下文占用仅增加几个 Token，但信息被完整保留。这就是“状态机”对抗“上下文爆炸”的武器。
在这种架构下，我们需要精心设计 Context Window 的布局，引导 LLM 遵守寄存器约束。
Prompt 模板示例：
# [R_System] Instruction Set
You are a State-Machine Agent. Maintain state strictly in JSON format.
Output format:
1. <tool_call name="..."/>
2. <state_update key="..." value="..."/>
# [R_IP] Current Instruction Pointer
Goal: Analyze Stock Trend
Step: 3/5 (Calculate Moving Average)
# [R_State] Global Registers (Max 4000 tokens)
{
"ticker": "AAPL",
"trend": "UP",
"analysis_progress": "50%"
}
# [R_Working] Scratchpad (Last Tool Output)
[Tool: API] Returned 1000 data points... (Large Text)
# [Input]
Based on R_State and R_Working, generate Next Tool Call and State Update.
AI Agent 的未来，不是让模型拥有无限的记忆，而是让模型学会像操作系统一样高效地管理资源。
通过引入指令指针（R_IP）和状态寄存器（R_State），我们将 Agent 的运行模式从线性的“文本流”转变为循环的“状态机”。在这个架构下，无论 Agent 运行一秒钟还是一百年，其 Context Window 的占用始终稳定在一个可控的范围内。
这才是 AI Agent 从“玩具”走向“工业级应用”的必经之路。我们不是在写对话，我们是在编写 AI 的汇编代码。
通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！
2026-01-19 16:00:00
想了解 Claude Code 的提示词是怎么设计的，最直接的方式就是抓包分析。通过网络流量，可以看清它的 System Prompt、Messages、Tools 等核心信息。
官方文档: https://www.mitmproxy.org
uv tool install mitmproxy
大多数教程用正向代理，需要配置系统代理和 CA 证书。更简单的方式是用反向代理：
mitmweb --mode reverse:https://open.bigmodel.cn --listen-port 8125
这个命令会：
然后把 Claude Code 配置中的 API 地址改成代理地址，正常使用即可。
ANTHROPIC_BASE_URL: http://127.0.0.1:8125/api/anthropic
在 mitmweb 界面中可以看到所有请求和响应：
点击具体的请求，就能看到完整的提示词内容了。
通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！
2026-01-11 16:00:00
前段时间做了一次 AI 大模型技术分享，顺手 Vibe coding 了一个小工具 claude-code-config-switcher，用来在不同 Claude Code 提供商之间快速切换。
后来我给这个工具新增了一个 Supervisor 模式，用了一段时间之后感觉非常有价值，于是把项目改名为 claude-code-supervisor。
用过 Claude Code 的朋友应该有这个体验：有时候 AI 声称”完成了”，但实际上还有一堆问题没解决。比如测试没跑、代码质量很差、功能不完整等等。这时候就需要你再跟 AI 说几轮，让它继续完善。
Supervisor 模式就是为了解决这个问题。它的原理很简单：
这个机制利用了 Claude Code 的 Stop Hook，当 Agent 停止时自动触发审查。Supervisor 会 Fork 完整的会话上下文，评估实际的工作质量，而不是简单检测一些关键词或信号。
使用 Claude Code 最大的痛点，就是 AI 经常会把问题抛回给用户：
这些问题本该是 AI 自己解决的。有了 Supervisor 模式，Supervisor 会检查：
如果发现问题，Supervisor 会给出具体反馈让 Agent 继续。比如：”你声称完成了，但没有测试，请添加测试。”
最近我用 Supervisor 模式做了一个实验（使用GLM 4.7模型），只给 AI 一个很简单的提示词：
用 JS 写一个在浏览器玩的双人坦克对战生存游戏，我和 AI 在有砖墙和钢墙的迷宫战场中驾驶坦克利用掩体进行战术射击对决，游戏要完整、精美、超高质量，AI 要有超强的战术水平。
结果让我很惊讶。在 Supervisor 的监督下，AI 完成了一个功能完整的坦克大战游戏：
游戏地址：https://blog.guyskk.com/shows/tankbattle/
最关键的是，整个过程我只需要给出初始需求，剩下的全部由 AI 在 Supervisor 监督下自动完成。没有中间轮次，没有反复沟通，一次性交付高质量成果。
可能有朋友知道 ralph-claude-code 这个项目，它也能实现类似的监督功能。两者的主要区别在于：
| 方面 | Ralph | ccc |
|---|---|---|
| 检测方式 | AI 输出结构化状态 + 规则解析 | Supervisor AI 直接审查 |
| 评估方式 | 基于信号和规则 | Fork 会话上下文评估实际质量 |
| 灵活性 | 需要更新规则代码 | 更新 Prompt 即可 |
ccc 采用的是 AI-First 的设计理念。规则检测的局限性在于需要预定义所有情况，难以覆盖边缘场景。而 AI 审查能理解上下文，处理边缘情况，随着模型能力提升自动改进。
claude-code-supervisor 已经开源，欢迎体验：https://github.com/guyskk/claude-code-supervisor
主要功能：
通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！
2025-12-31 16:00:00
前段时间做了一次AI大模型技术分享，本想早点把资料整理出来，一拖就到了2026年。趁着元旦假期，把分享材料整理好发出来，希望能对大家有帮助。
这次分享覆盖了AI大模型的方方面面，从底层原理到产品实践，包括：大模型是什么、Agent怎么工作、提示词工程、AI产品开发新范式等等。内容比较多，整理成了PDF，感兴趣的朋友可以直接查看：2025-AI大模型技术分享-PDF
分享之后，又 Vibe coding 了一个小工具 claude-code-config-switcher（简称ccc），现已开源。这个工具解决的问题是：Claude Code虽然很好用，但想在不同提供商（Kimi、GLM、MiniMax等）之间切换，每次都要手动修改配置文件，很麻烦。用ccc的话，一条命令就能切换，欢迎体验：https://github.com/guyskk/claude-code-config-switcher
通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！
