破茧者~BLOG

当 AI 编程进入下半场，拼的不是模型，而是 Harness

2026-03-29T15:30:00.000Z

当 AI 编程进入下半场，拼的不是模型，而是 Harness

Humans steer. Agents execute.

最近几个月，我把 OpenAI、Anthropic、LangChain、Thoughtworks、HumanLayer 这些团队关于 Agent 的文章基本顺着看了一遍，也顺手看了不少一线实践、开源项目和企业侧复盘。看得越多，我越觉得现在很多人对 AI 编程的理解，其实还停在一个挺早期的阶段。

大家最爱聊的还是模型、prompt、MCP、上下文窗口，仿佛只要这些关键词掌握得够熟，AI 编程就算学明白了。但真把那些一线团队的实践拆开看，你会发现他们真正花时间、花精力、花工程能力去补的，常常不是模型本身，而是模型外面的东西。

同样是 Claude Code、Codex、Cursor，有人让 AI 改两个文件就开始发散，修一个 bug 顺手再造三个 bug；也有人能让 Agent 自己读仓库、跑测试、看日志、开 PR、吃 review、修回归，连续干几个小时还不崩。很多人第一反应是模型差距，但你真把这些案例拆开看，会发现真正拉开差距的，往往不是模型本身，而是模型外面那套工作环境。

这套东西，现在慢慢有了一个更稳定的名字，叫 Harness。

我一开始其实挺烦这种新词，感觉像又在给老东西换包装。后来资料看多了，才发现不是。因为它讨论的已经不是“prompt 怎么写更巧”“MCP 要不要接”“要不要多开几个 Agent”这种局部技巧，而是在追问一个更硬的问题：

你到底有没有给 AI 一个能持续工作、能不断纠错、能长期积累的环境？

如果没有，再强的模型也只能偶尔灵光一现；如果有，它才可能从一个聊天框，慢慢变成一个真的能协作的执行者。说得再难听一点，很多人现在不是不会用 AI，而是根本没把 AI 放进一个能好好干活的场子里。

Harness 到底是什么

LangChain 那篇《The Anatomy of an Agent Harness》里给了一个很简洁的说法，叫 Agent = Model + Harness。这句话好就好在，它一下子把很多空话都裁掉了。模型负责的是能力上限，Harness 负责的是稳定下限；模型决定它会不会，Harness 决定它稳不稳；模型给你生成的可能性，Harness 决定这些可能性能不能真的落地。

所以 Harness 说白了，不是什么玄乎的新发明，它就是 AI 的工作台。你得给它文件系统，给它清晰的仓库结构，给它能读懂的文档，给它能实际调用的工具，给它看运行结果的入口，给它知道哪里算错、哪里算对的反馈机制。再往后一点，你还得管它每次会话之间怎么接力，怎么恢复，怎么避免把上下文越用越脏，怎么让坏模式不要在仓库里越长越多。

没有这些，模型再强也只是个会说话的概率机器；有了这些，它才可能开始干真正复杂、真正长期的活。

顺着阿里那篇文章里的比喻往下说，我觉得 Harness 这个词确实挺形象。模型像一匹很强、很有爆发力、但也带着黑盒属性的马；Harness 是缰绳、马鞍、护具这些成套装备；人类工程师更像骑手，负责明确方向、设计环境、布置约束、接住反馈。单独有马不够，单独有骑手也不够，真正决定这套系统能不能跑远的，是这三者之间有没有被工程化地接好。

腾讯那篇文章里还提到 Mitchell Hashimoto 给 Harness 下过一个特别朴素、但非常有杀伤力的定义：每次你发现 Agent 犯了一个错误，就花时间设计一个工程化方案，让它以后别再犯同样的错。这个定义比很多大词都更像人话。因为它直接把 Harness 从“听起来很高级的方法论”拉回到了一个非常日常的动作上：别反复纠正，要把纠正固化成系统。你写进 AGENTS.md 的规则也好，补的脚本也好，专门加的截图工具也好，甚至一条 linter 规则也好，本质都是同一类东西。Harness 不是一开始就有的，它很多时候就是被错误一条条逼出来的。

从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering

我现在越来越觉得，AI 工程这几年其实已经走过了一个很清楚的迁移路径。

最早大家聊的是 Prompt Engineering。核心问题是“怎么跟模型说话”。那时候很多技巧确实有用，few-shot、chain-of-thought、角色扮演、格式约束，大家都在一个固定对话窗口里雕 prompt，试图从黑盒里诱导出更好的答案。

后来大家开始意识到，单靠 prompt 不够，于是讨论慢慢转向 Context Engineering。问题变成了“模型到底该看到什么”。知识库、工具、记忆、检索、文件选择、上下文压缩，这一层其实已经不再是纯聊天技巧了，而是在给模型设计输入面。Karpathy 说 context engineering 比 prompt engineering 更重要，我觉得这话是对的，因为很多时候模型表现差，不是它不会想，而是它根本没看到该看的东西。

但到今天，再往前走一步，你会发现光解决“看什么”还不够，还得解决“整个环境怎么运作”。也就是说，问题继续升级成了：

这个 Agent 在什么边界里工作？怎么拿工具？怎么验收？怎么恢复？怎么避免失忆？怎么避免仓库熵增？

到了这一步，讨论的就已经不是 prompt，也不只是 context，而是 Harness Engineering。

这也是为什么我现在越来越觉得，prompt engineering 这件事并没有死，但它的地位确实降了。以前大家总觉得谁更会写 prompt，谁就更会用 AI。现在看，prompt 当然还重要，但它已经更像一台机器里的一个零件，而不是那台机器本身。你只研究 prompt，不研究环境、约束、反馈和恢复，最后就很容易陷入一种很熟悉的局面：AI 偶尔特别惊艳，但一拉长流程就散，一碰真实系统就乱，一遇到复杂项目就开始到处漏风。

OpenAI 真正讲明白的，不是“AI 写了一百万行代码”，而是“工程师开始不直接写代码了”

OpenAI 那篇《Harness engineering: leveraging Codex in an agent-first world》之所以能一下子把 Harness 这个词带火，不是因为它用了什么特别花哨的概念，而是因为它给了一个所有人都没法忽略的案例。三名工程师，五个月，零手写代码，做出一个约一百万行代码的真实产品，已经有内部用户，也有外部 alpha 测试用户。文章里提到，五个月里大概开了 1500 个 PR，平均每个工程师每天 3.5 个 PR，而且随着团队从 3 人长到 7 人，吞吐量还在往上走。

但老实说，真正值得看的根本不是这个数字，而是他们从头到尾都在强调一件事：团队最早的瓶颈，不是模型不够强，而是环境不够完整。项目早期推进慢，不是 Codex 不能写，而是仓库里缺少足够清晰的工具、抽象、结构和内部约束，Agent 没法稳定朝高层目标推进。于是工程师的主要工作，慢慢从“自己写实现”变成了“给 Agent 补能力”。

这句话非常关键，因为它把很多人今天的误区一下子点穿了。很多人一遇到 AI 产出差，第一反应就是模型还不够强，提示词还不够细，训练数据没见过我的项目。OpenAI 这篇文章给出的回答完全是另一套逻辑：当 Agent 卡住时，不要先问它为什么不聪明，要先问系统里缺了什么。很多时候不是模型拉胯，是你的场子太烂。

这个视角一变，后面所有动作都会跟着变。

比如他们自己就踩过一个很典型的坑：一开始把系统说明、架构规范、代码风格、注意事项全塞进一个巨大的 AGENTS.md，以为信息给得越全越好。结果恰恰相反，AI 被淹没了。后来他们把 AGENTS.md 压得很短，只保留入口和导航的作用，真正的设计文档、架构文档、计划文档、质量文档都分开放回 repo，让 Agent 在需要的时候自己去找。

这个改动表面看只是文档整理，实际上背后是个很硬的判断：AI 不需要一开始就知道一切，它需要的是在正确的时机拿到正确的信息。给一张地图，比塞一本到处翻不到重点的说明书有用得多。

再往后，他们做的事就更有意思了。OpenAI 不是只让 Codex 看源码，而是让它能跑 bash、执行代码、打开应用、驱动浏览器、看 DOM snapshot、截图、查日志、查指标、看 trace。你仔细想想，这些东西凑在一起，才构成了一个真正像样的工作台。因为很多 bug 根本不在代码字面上，而是在运行之后才出现。你不给 Agent 这些反馈，它就只能闭眼猜。你给了，它才有机会真的像工程师一样，写完，运行，观察，修正，再验证。

他们还做了一件特别工程的事，就是把规则尽量从“文档建议”变成“机械约束”。比如他们把业务域内部固定成 Types -> Config -> Repo -> Service -> Runtime -> UI 这种依赖方向，然后用自定义 lint 和结构测试去硬卡。这个点我觉得特别重要，因为它说明了一个事实：对 Agent 来说，稳定边界的价值远高于自由发挥。很多人总怕“约束太多会不会限制创造力”，但对 Agent 而言，边界清楚往往恰恰会让它更稳定。

还有一个我特别喜欢的细节。OpenAI 说他们后来连 linter 的错误提示都专门改过，因为这些提示不只是给人看，也要给 Agent 看。以前我们默认所有工具链的第一读者都是人，现在不是了。未来很多工程系统，第一读者很可能是 Agent。这个变化其实非常深，它意味着软件工程里很多原本“默会的、靠经验理解的东西”，都要被重新翻译成机器也能稳定读懂的形式。

再往后一个层次，就是他们发现坏模式会扩散。Agent 会模仿仓库里已经存在的风格，哪怕这些风格本身就不太好。时间一长，坏抽象、坏习惯、坏代码味道会像霉菌一样蔓延。OpenAI 最开始是靠人类每周花很多时间清理这些东西，后来发现根本不可持续，于是开始把清理逻辑系统化，把“黄金原则”写进 repo，定期让系统去巡检仓库里的文档和代码模式，发现过期说明、坏味道和跑偏的地方，就自己提修复 PR。

你会发现，到了这一步，所谓 Harness 已经不是“给 AI 几个工具”那么浅的东西了，它开始变成一整套维持秩序、抑制熵增、让系统长期不烂掉的工程机制。

所以 OpenAI 这篇文章最震撼我的，不是“AI 写了一百万行代码”，而是它把工程师的角色讲变了。人类开始越来越少地直接下场写实现，越来越多地去设计结构、定义规则、布置反馈、维护秩序。这不是“AI 帮我写代码”这么简单了，而是软件工程本身在为了 AI 协作重新长一遍。

Anthropic 讲得更现实：长任务真正的敌人，不是笨，而是失忆和自我感觉良好

如果说 OpenAI 把 Harness 的大方向说得很震撼，那 Anthropic 的文章更像在给你拆工程现场。它们没有那么强的“传奇叙事”，但特别贴地。尤其是《Effective harnesses for long-running agents》和《Harness design for long-running application development》这两篇，几乎把长任务为什么容易废掉讲透了。

Anthropic 观察到的第一个问题特别真实：长任务一旦跨多个上下文窗口，Agent 很容易开始失忆。前一个会话里想明白的事，后一个会话未必还知道；前一个会话里埋下的坑，后一个会话经常会踩第二遍。于是项目就会进入一种很熟悉的状态：半截功能，半截修复，半截理解，最后谁也说不清现在到底卡在哪一步。

第二个问题更常见：Agent 特别容易过早宣布“差不多做完了”。项目做到一半，它看了一眼页面，觉得“好像也能用”，就开始收尾。这个现象你一旦见过一次，后面就很难忘，因为它太像一个自我感觉良好的实习生了。Anthropic 对这个问题的判断很准：这不是单纯的推理能力不够，而是状态管理和验证闭环太差。说白了，不是笨，是散。

所以他们的做法很工程化。第一轮不是直接开写，而是先跑一个 initializer，把环境搭起来，生成进度文件、拆任务、留下 handoff artifact。后面的 coding agent 不再从零开始猜世界，而是每次只推进一个明确子任务，做完之后留下可交接的工件，让下一个会话接班。你会发现，这整套做法的核心根本不是“让模型更聪明”，而是 别失忆。

Anthropic 另一点讲得特别明白，就是端到端验证的重要性。模型特别容易把“代码改了”误判成“功能好了”。它可能跑一下单测，或者 curl 一下接口，就觉得这件事 done 了。但用户路径一走，发现页面不通、按钮失效、交互断裂。所以他们后来非常强调浏览器自动化和真实用户视角的验证。能看到按钮点没点通、页面有没有挂、交互是不是顺手，这比只看 diff 有价值得多。

更进一步，Anthropic 在另一篇文章里把 generator / evaluator 这套双环路也讲得很清楚。说白了就是：负责生成的 Agent 不负责给自己打分，另一个 Agent 拿着工具去真实操作页面、检查功能、截图、对照标准打分，再把问题反馈回来。这个设计最打动我的地方，不是“多 Agent 听起来很高级”，而是它把一个大家平时不好意思承认的事实说透了：

模型自评真的非常不靠谱。

特别是在设计任务、前端任务这种主观度高的场景里，一个页面到底是“能看”还是“真的好”，一个交互到底是“勉强通”还是“顺手”，模型自己往往没那么清醒。它太容易对半成品说“已经不错了”。这点真的很像实习生，只不过这个实习生嘴特别硬。

Anthropic 后面那几篇 context engineering、sandboxing、tool design 的文章，其实也都在补同一件事。上下文不是垃圾桶，而是注意力预算；沙箱不是束缚，而是自治的前提；工具不是越多越好，而是越清晰越好。你把这些东西全放一起看，就会发现 Anthropic 真正在做的，不是给 Agent 增加一点花里胡哨的新能力，而是在不断把它从“会胡乱发挥的聪明人”往“在边界内稳定做事的工程角色”上拉。

腾讯那篇文章里有一句我也很认同：纪律没有消失，只是从“如何把代码写好”转移到了“如何把让 Agent 工作的支撑结构搭好”。这句话其实非常重要。以前工程纪律体现在线下怎么写代码、怎么 review、怎么守编码规范；现在纪律越来越多地体现在文档怎么组织、约束怎么机械执行、反馈回路怎么布置、验收标准怎么前置、运行结果怎么暴露给 Agent。你要是还把工程纪律只理解成“把每一行代码写漂亮”，那你其实还活在上一个时代。

四个具体案例，比概念更能说明 Harness 到底在补什么

如果只停留在概念层面，Harness 很容易被讲成一句大话。但把具体案例摆出来，问题就清楚多了。

1. 编辑工具本身就是 Harness，不只是小配件

阿里那篇文章里提到一个很有意思的案例。独立开发者 Can Duruk 发现，很多 coding agent 失败，不是因为模型不会改，而是因为 编辑接口太脆弱。你让模型输出 patch、精确复写旧文本、或者依赖某种特殊 diff 语法，本质上都是在要求模型用很别扭的方式表达意图。

他后来做了 Hashline 这种方案，给文件每一行加短哈希标签，让模型按标签编辑，而不是按全文复现。结果同一批模型，成功率直接明显上升。这个案例我特别喜欢，因为它说明了一件很容易被忽略的事：

Harness 不只是宏大架构，连编辑接口这种底层交互面，本身也是 Harness。

你以为你在测模型，其实你常常在测的是模型和环境之间那层接口设计。

2. 技术债在 Agent 时代不是线性累积，而是指数扩散

第二个案例也很扎心。有开发者复盘说，人类工程师看到仓库里一段脏代码，很多时候知道“这是历史包袱，不要学它”；但 Agent 不会，它看到什么，就会模仿什么。于是一个临时妥协、一个硬编码、一个绕层调用，很可能会被它当成仓库合法模式，然后系统性复制到后续实现里。

这点和 OpenAI 的经验其实完全对上。人类时代的技术债，很多时候是慢慢堆；Agent 时代的技术债，更像会自我复制的病毒。你仓库里什么味道占上风，Agent 就会把这种味道放大。

所以现在越来越多团队开始重视“代码库卫生”这件事。不是靠人每周手工大扫除，而是把品味固化成 lint、结构测试、模板、脚本、巡检任务、后台 refactor PR，让系统自己去抑制坏模式扩散。说白了，Harness 到最后会碰到一个很老派、但躲不开的问题：

你有没有能力把“品味”从口头经验变成机器能执行的规则。

3. 子 Agent 真正值钱的地方，是做上下文防火墙

HumanLayer 有个说法我特别认同，他们把 sub-agent 直接看成一种 context firewall。

这个比喻很准。一个复杂任务如果所有搜索、探索、grep、read、试错、日志输出都塞进主上下文，主线程很快就会被临时垃圾拖死。让子 agent 在自己的上下文里把局部问题做完，再把压缩后的结论和引用交回来，主上下文才能保持干净。

所以多 Agent 真正有价值的地方，很多时候不是“人多力量大”，而是：

隔离噪音
压缩信息
保住主线程的方向感

这也是为什么我现在越来越不迷信“多开几个 Agent 就更高级”。多 Agent 不是目的，能稳定交接、稳定压缩、稳定恢复，才是。

4. 成功应该是沉默的，只有失败才应该发声

阿里那篇文章里还提到 HumanLayer 和 LangChain 的另一类实践，我觉得特别值得普通团队直接拿来用。HumanLayer 早期踩过一个坑：每次 Agent 改完代码，就把一整套测试输出塞回上下文。结果不是更安全，而是把模型注意力拖垮了。

后来他们总结出一句很重要的话：

成功应该是沉默的，只有失败才应该发声。

这句话听起来像个小技巧，但背后其实是非常硬的 harness 思维。你要让 Agent 获得反馈，但不是让它淹死在反馈里。构建、测试、lint、截图、日志这些东西，成功时给简短信号就够了；失败时再返回最小可操作单元的错误。这种“静默成功、精准失败”的设计，本质上是在保护上下文预算。

LangChain 那边更进一步，还做了 pre-completion checklist 和 loop detection。一个负责拦截“你真的做完了吗”，一个负责识别“你是不是在同一个地方兜圈子”。这些设计听起来不像模型能力，但它们恰恰是让模型少犯低级错误的关键。

HumanLayer 这批文章最值钱的地方，是把很多细活讲透了

如果说 OpenAI 和 Anthropic 是把大方向讲清楚，那 HumanLayer 那几篇文章的价值，就在于它们特别像一线使用者写的复盘。没有那么多宏大叙事，但很多点一看就知道是被真实问题逼出来的。

我最认同的是他们对 CLAUDE.md 这类文件的态度。HumanLayer 在《Writing a good CLAUDE.md》里讲得很克制：这种文件是高杠杆点，因为它会稳定进入每次会话；但它也是高风险点，因为你很容易把它写成垃圾场。太多人写这类文件时，思路其实是“把我脑子里的所有想法都塞进去”。结果不是帮助，而是污染。短、小、稳定、只写模型自己推不出来但又会反复用到的规则，这种做法反而更有效。

这点和 OpenAI 后来把大 AGENTS.md 拆散，逻辑是一模一样的。

HumanLayer 另一个特别强的观点，是他们把 coding agent 的很多问题直接归因到 configuration surface 上。skills、MCP、memory、sub-agents、hooks，这些都不是边角配件，而是 coding agent 的真正配置平面。这个说法很扎心，但也确实把问题说透了。很多人不是不会用模型，而是根本没给模型一个像样的工作配置。嘴上说是在用 Agent，实际干法还是把它当一次性聊天框。

而且 HumanLayer 那种写法有个好处，它不会假装一切都很优雅。很多文章会把 Agent 写得像一个天然懂事的协作者，HumanLayer 没这么浪漫。它们的出发点更像是：模型会忘、会乱、会自信地犯错，会被噪音拖死，会在错误接口上用力过猛，所以你必须把这些坑一个个封起来。这个思路其实很符合我现在对 Harness 的理解。Harness 不是锦上添花，它很多时候是在不断堵漏。

Thoughtworks、Inngest 这些文章把另外半边补上了：别迷信框架，要重视系统纪律

再往下看，会发现很多文章最后都绕不开同一个话题：约束和系统纪律。

Thoughtworks 那篇《Harness Engineering》我觉得特别好的一点，是它没有被“新词”带跑，而是把这件事拉回了工程本身。他们把重点落在三件事上：context engineering、architectural constraints、entropy control，也就是持续清理漂移和坏模式。这其实和 OpenAI 的经验高度重合。说明一线团队最后都在同一类问题上收敛。

Inngest 那篇《Your Agent Needs a Harness, Not a Framework》则从另一个方向把问题说透了。它的核心观点是：Agent 最终碰到的很多问题，本质上不是 AI 问题，而是基础设施问题。比如任务做到第五步挂了怎么办，两条消息同时打进来怎么防止状态冲撞，一个长循环怎么拆成可重试的 step，中间结果怎么持久化，出错之后谁来接管、怎么通知。

这些问题如果放回传统软件工程里，大家都觉得理所当然；可一到 Agent 这里，很多人又突然回到“给个 prompt 试试”的原始社会。

所以我现在越来越认同 Inngest 这个判断：很多团队不是缺 framework，而是缺 harness。真正难的地方，通常不在“怎么让模型更会想”，而在“怎么让系统别失控”。

很多人现在最缺的，不是更多 Agent，而是更像样的规格、评估和可观测性

还有一层很容易被忽略，但其实非常要命，那就是 spec、eval 和 observability。

规格不清，Agent 往往不是做不动，而是高效率跑偏。OpenAI 把设计文档、架构文档、计划文档、质量文档都收进 repo，Anthropic 把 feature list 结构化，GitHub 的 spec-kit 干脆直接把这种思路产品化了。本质都在回答同一个问题：Agent 到底在替你完成什么目标，按什么流程推进，做到什么程度才算结束。

一旦进入多会话、多步骤、多 Agent 的世界，模糊规格的代价会被无限放大。人类工程师还能靠 tacit knowledge 补一补，Agent 补不了。

评估这件事也是一样。OpenAI 后面关于 eval 的几篇东西，像 eval skills、agent evals、trace grading，本质上都在做一件事：把 Agent 的过程纳入评估，而不是只看最后一句答案像不像。因为 Agent 经常不是输在最后结果，而是中间某一步就已经歪了。你不看 trace、不看过程、不做任务级 eval，很多问题根本不会暴露出来。

LangChain 那篇《Improving Deep Agents with harness engineering》甚至直接给出了一个很有说服力的例子：他们的 coding agent 在 Terminal Bench 2.0 上从 Top 30 到 Top 5，改的不是模型，而是 harness，重点就是 self-verification 和 tracing。这句话其实已经够说明问题了，今天很多性能提升，来自系统外壳，而不是大脑本身。

可观测性就更不用说了。OpenAI 让 Codex 看 logs、metrics、traces，Anthropic 让 evaluator 用浏览器去真实操作页面。背后只有一个朴素事实：如果你不让 Agent 看见系统运行后的真实反馈，它就只能闭眼猜。而闭眼猜这件事，偶尔能蒙对，但很难持续交付。

Harness 越强，Spec 越重要，这不是二选一关系

很多人看到 Harness 这个词火起来之后，第一反应是：既然环境和工具这么重要，那是不是以后花精力写 Spec、写设计文档、写行为约束，就没那么重要了？反正 Harness 会越来越强，Agent 会越来越聪明，直接让它在仓库里自己找不就行了？

这个想法乍看很顺，但其实是反的。

OpenAI 那篇文章已经给过一个非常硬的事实：从 Agent 的视角看，它在运行时访问不到的东西，等于不存在。存放在 Google Docs、Slack、会议纪要或者人脑子里的知识，对它来说都像空气。真正能被 Agent 当成推理依据的，只有那些被写进仓库、被版本化、被它明确读到的东西。

也就是说，Harness 再强，也只能放大它真正看得见的内容。你把仓库里的规范、契约、设计决策写得越清楚，Harness 就越能把这些东西放大成稳定输出；如果仓库里根本没有这些东西，或者写得很虚，Harness 放大的就不是工程纪律，而是模型的猜测。

这也是为什么我现在越来越认同腾讯那篇文章的判断：Harness 和 SDD 不是竞争关系，而是同一件事的两个层面。

Harness 解决的是“Agent 在一个什么样的环境里工作”；Spec 解决的是“这个环境里到底写了什么，让它可以推理、可以执行、可以验证”。Harness 像放大器，Spec 像被放大的信号。放大器越强，输入质量越重要。引擎越猛，导航越不能瞎。高速路的护栏不是因为车慢才不重要，恰恰是因为车快了，护栏才更重要。

腾讯那篇文章里有个说法我觉得很准：Spec 在 Harness 里至少扮演三种角色。第一，它是 Agent 推理的地图。没有地图，Agent 看到的只有“代码现在长什么样”，看不到“为什么这么设计”“哪里不能动”“这个字段跨服务到底是什么意思”。第二，它是很多语义约束的载体。Lint 能卡格式，结构测试能卡依赖方向，但很多业务语义、错误码契约、状态流转规则，机械检查根本管不到，这些东西不写下来，Agent 就只能猜。第三，它其实还是反馈回路里“正确性”的判据。你得先有一个“应该是什么样”的定义，后面的验证、回归、评分、trace grading 才有落点。

这三层我觉得特别重要，甚至可以说是很多团队现在最薄弱的地方。地图这一层，很多人其实是缺的。仓库里代码很多，但没有高层视图，没有边界说明，没有清晰导航，Agent 一进去就像掉进迷宫。语义约束这一层，更容易被忽视。大家总以为有 lint、有类型系统、有测试就够了，但很多真正会出事故的东西，恰恰不在这些机械规则里，而在那些“默认大家都懂”的跨服务契约、业务含义、错误码语义、状态流转条件里。人类同事之间还能靠语境和背景知识补一下，Agent 不行。它不知道的时候不会举手说“这里我有点不确定”，它大概率会沉默地猜一个看起来合理的答案，然后把这个猜测写成代码。

腾讯那篇文章举了一个我觉得特别有代表性的例子：服务 A 定义了某个错误码的含义，但服务 B 的 Agent 在实现时完全不知道这个跨服务语义，于是直接猜了一个处理方式。这个 bug 不是因为模型不够强，而是因为真正关键的语义根本没写进 Spec。这个案例我觉得特别能说明问题。很多人现在在 AI coding 里遇到的坑，本质都不是“能力缺失”，而是“定义缺失”。

所以我现在越来越觉得，Harness Engineering 真正把一件事放大了：仓库里写进去的东西，比以前重要得多。 以前很多团队文档写得一般，也能勉强靠几个熟手扛住。现在主力执行者慢慢变成 Agent，那些原来藏在人脑、口头、群聊和默契里的知识，必须被显式写出来，不然系统就会在最脆弱的地方开始靠猜测运转。

换句话说，Harness 越成熟，Spec 不但不会过时，反而会更值钱。不是因为 Harness 不够强，而是因为 Harness 太强了，强到它会把你仓库里的好东西和坏东西一起放大。你写清楚了，它就高速放大你的清晰；你写含糊了，它就高速放大你的含糊。

而且腾讯那篇文章还把另外一个容易被忽略的问题讲得很透：大型 AGENTS.md 本身就是个陷阱。OpenAI 已经踩过这个坑，腾讯那边顺着这个坑继续往下分析，指出执行约束和语义约束其实是两类完全不同的东西。前者更像“不要用这个 API”“文件不要超过多少行”“这个命令不要跑”，后者更像“这个字段到底是什么意思”“这个状态在跨服务场景下怎么流转”“这个错误码在什么上下文里代表什么”。这两类东西混在一起，最后就会一起失效。文件越来越长，Agent 既抓不到行动入口，也抓不到真正关键的语义重点。

这个分析我觉得特别值钱，因为它帮我们把一个很模糊的感觉说清楚了。不是所有东西都该写进一个 agent file。AGENTS.md 更像目录和行动入口，Spec 更像系统语义和行为定义，两者职责不同。你硬把它们揉成一团，最后只会变成一个没人愿意读、Agent 也读不好的巨大说明书。

腾讯那篇文章还有一点我很喜欢，它把“Spec 漂移”这个问题单独拎出来说了。代码漂移通常还能在运行时感知，测试会挂、类型会报错、行为会出问题；Spec 漂移更阴，因为它往往是沉默的。仓库里那份 Spec 还挂着“Active”，但实际上早就没跟上系统演化了。下一个 Agent 进来，基于一份过时定义继续生成代码，整个系统就开始在错误地图上高速前进。这个问题我觉得特别真实，而且很多团队现在还没认真对待。大家会觉得“文档过时一点很正常”，但在 Agent 时代，过时文档不是中性噪音，而是主动误导。

所以腾讯那篇文章最后那几个启示，我觉得都很值得吸收进 Harness 的讨论里。第一，人类最稀缺的资源不是代码时间，而是注意力，所以 review 的重点迟早要前移到 Spec；第二，大型 AGENTS.md 是个陷阱，行动入口和语义定义要分开管；第三，Spec 漂移是必然的，只靠人工维护不够，迟早要有主动检测机制；第四，系统一出问题，首要追问不该是“人类要不要更努力一点”，而应该是“AI 还缺什么能力，才能把这件事自己做对”。我觉得这四个判断，基本已经把 SDD 为什么不会过时、反而会在 Harness 时代更重要，说得很明白了。

为什么现在 benchmark 也越来越像在测 Harness，而不是单测模型

现在很多 benchmark，像 SWE-bench Verified、OSWorld、GAIA、AppWorld、WebArena、WorkArena、Terminal-Bench、HAL。把这些 benchmark 放在一起看，你会发现一个很明显的趋势：今天有区分度的测试，越来越少是“单轮答题”，越来越多是“长链路闭环”。

终端里能不能稳定操作，浏览器里能不能真实完成任务，多步工作流里会不会把环境搞乱，跨工具、跨状态、跨时间窗口之后，还能不能维持方向感。比如 SWE-bench Verified 强调真实 issue、真实测试，天然就能暴露 retrieval、patching、validation 这些 harness 质量；OSWorld、WebArena、WorkArena 这种更偏 computer-use 的 benchmark，测的已经不是“会不会答”，而是“能不能在环境里稳定操作”；Terminal-Bench 更像是对 shell-native harness 的全面拷打；HAL 这类 leaderboard 甚至开始把可靠性和成本也纳入比较。

这说明了一件很重要的事：行业已经默认，Agent 的竞争不再只是大脑竞赛，而是整套系统竞赛。以后你再看到某个榜单，很可能不能只问“这是什么模型跑出来的”，还得问一句：它跑在什么 harness 里？不然你很可能拿着一个系统分，当成了模型分。

开源实现也越来越多了，但越看越会发现：真正稀缺的不是框架，而是系统能力

还有一些实现和参考系统：Claude Agent SDK、Anthropic 的 multi-agent research system、SWE-agent、SWE-ReX、deepagents、Harbor、AgentKit、terminal-bench 等等。把这些项目放一起看，你会发现一个很有意思的现象：大家表面上长得不同，底层都在补同一类东西。会话和状态管理、受控执行环境、任务分解和分工、恢复能力、验证闭环、trace 和可观测性，这些东西才是真正反复出现的硬需求。

阿里那篇文章里提到的 CLI-Anything 和 HiClaw，其实也是这个脉络里的东西。一个更偏“把 GUI 世界翻译成 Agent 能稳定调用的 CLI 能力”，一个更偏“多 Agent 组织、共享文件系统、模型路由、权限治理、FinOps 和网关控制”。你看名字会以为大家在做不同的产品，往底层一拆，其实都在做同一件事：给 Agent 搭更完整的执行环境。

Anthropic 那篇多 agent 研究系统的文章就特别典型。它讲得很清楚：multi-agent 真正有价值的地方，不是“人数多”，而是把大问题切成并行、可压缩的小问题，再由 lead agent 汇总。子 agent 的价值本质上是扩展 token 容量、隔离上下文、做信息压缩。但他们同时也强调，多 Agent 很费 token，也很容易出现协调复杂度暴涨。研究任务适合，因为可并行性高；大多数 coding task 不一定适合，因为强依赖和实时协调很多。

这话就特别有含金量。因为它把很多人的误区直接打掉了：多 Agent 不是目的，能稳定交接、稳定压缩、稳定恢复，才是。

所以我现在越来越不迷信“某个框架”。这些开源项目看久了，你会发现真正稀缺的不是框架 API，而是你有没有把环境、状态、规则、验证、恢复这些能力接好。

腾讯那篇文章其实也在另一条线上提醒了这一点。很多人看见 Harness 这个词火起来，会下意识地把它理解成“又多了几个工具、几个框架、几个平台”。但真把 OpenAI、Mitchell、Anthropic、HumanLayer、Inngest 这些文章放一起看，你会发现大家说的根本不是“去选一个最好的壳”，而是“你有没有把你的工程能力迁移到环境设计上”。这个迁移才是最难的。因为它要求你不再只盯着功能实现，而要开始思考：这个系统怎样组织，Agent 才能读懂；这个规则怎样表达，Agent 才能执行；这个错误怎样反馈，Agent 才能修正；这个知识怎样沉淀，下一次会话才不会重新踩坑。

对企业来说，Harness 还不只是提效工具，而是群体智能的治理层

阿里那篇文章里还有一层我觉得值得补进来，就是它不是只把 Harness 当成 coding agent 的工作台，而是把它往企业侧再推了一层。

单个 Agent 的效率提升当然重要，但真正让企业愿意长期投资源的，通常不只是“写得更快”，而是 能不能把多个角色、多个工具、多个模型、多个知识源组织成一个可治理、可编排、可持续演化的系统。

这个角度一进来，Harness 讨论的东西就会明显变化。你不只是关心 prompt 和代码生成了，你还得关心：

多个 Agent 之间怎么隔离记忆污染
文件和中间结果怎么共享
不同任务怎么路由到不同模型
凭证、权限、审计、限流怎么做
成本怎么控制，失败怎么降级

说白了，到了企业场景，Harness 已经不只是“让 AI 干活”，而是“让一群 AI 不要互相拖垮、不要失控、还能被治理”。这个思路和 HiClaw 那类项目想解决的问题，其实是一致的。

所以我觉得 Harness Engineering 这个词会越来越常见，不是因为它听起来新，而是因为 Agent 一旦从“单人副驾驶”往“组织级执行者”演进，你迟早都得补上这一层。

看完这一圈文章之后，我现在对 Harness 有三个更明确的判断

第一个判断是，prompt engineering 没死，但它确实降级了。Prompt 当然还重要，但它现在更像一台机器里的一个零件，而不是那台机器本身。真正决定效果的，是 prompt 能不能接上工具、接上状态、接上规范、接上验证、接上恢复、接上评估。脱离这些单谈 prompt，有点像在研究怎么把方向盘擦得更亮。

第二个判断是，未来最值钱的工程能力，不一定是“写”，而是“布置”。OpenAI 那句 Humans steer. Agents execute. 我觉得不是一句宣传语，它其实是在提前描述一种角色转移。以后越来越值钱的人，可能不是手写代码最快的人，而是最会做这些事的人：把问题拆成 Agent 吃得下的粒度，把经验沉淀成稳定工件，把主观口味变成可执行规则，把运行反馈暴露给 Agent 自己，给系统设计边界、恢复和回收机制。说白了，就是更会布置战场的人。以前拼的是谁手更快，后面拼的很可能是谁把场搭得更对。

第三个判断是，Harness Engineering 本质上是在把“AI 味”一点点挤出去。很多人现在一看 AI 生成的东西，就说有股“AI 味”。我现在越来越觉得，这个味道很多时候不是模型天生带的，而是 harness 太差导致的。规范不清，所以它讲空话；验收模糊，所以它自我感觉良好；上下文太脏，所以它重复、漂移、跑偏；没有反馈，所以它看起来很忙，实际没闭环。从这个意义上说，Harness Engineering 干的事非常朴素：它不是在给模型加戏，而是在不断挤掉系统里的模糊、噪音和侥幸。

普通人今天能怎么开始

说了这么多，最后还是得落回来。不然又变成一篇“看完觉得很有道理，然后什么都没改”的文章。

如果你今天就想把自己的 AI 工作流往前推一步，我觉得不用学大厂那套完整系统，先做几件事就够了。

先建一个短而稳的入口文件，别写百科全书，只写目录结构、构建命令、输出要求、禁止事项、去哪找详细资料。再把长期知识放回文件系统，规范、模板、参考资料、历史决策固定存放，不要每次都靠聊天记录和复制粘贴续命。

再往下，就是先写验收单，再让 Agent 开始干活。不要只说“做个页面”“写篇文章”“修个 bug”，要把“怎样算做完”说清楚。然后给它看结果，不要让它盲改，能跑测试就跑测试，能截图就截图，能看日志就看日志，能回放就回放。

最后，每次犯错都别只纠正一次，要想办法把它固化下来，变成 lint、清单、模板、脚本、文档、hook，让同样的错，不要下次还靠你亲自盯。对个人来说，这是把 AI 从“会聊天的助手”往“能协作的执行者”推一步；对团队来说，这其实就是你们第一版 harness 的起点。

这几件事做完，你的 harness 可能还很粗糙，但已经不是“纯聊天”了。你会明显感觉到，AI 不再只是时灵时不灵地给你吐答案，而是开始有一点“真在这个环境里干活”的味道了。

如果再往前多走一步，我觉得腾讯那篇文章给的启发也很值得普通团队直接照着想。别把“写 Spec”理解成官样文章。真正有用的 Spec 不是为了给人看着舒服，而是为了让 Agent 少猜一次、少返工一次、少把错误放大一次。你现在每次在 review 里发现 AI 又把某个字段理解错了、又把某个跨服务契约猜偏了、又把某个边界条件漏了，其实都可以反过来问一句：这件事是不是应该前移写进 Spec，而不是等下一次再人工纠正？

这就是 Harness 最实在的起点。不是一上来搭一个很大的平台，也不是先聊宏大方法论，而是把一次次真实犯错，慢慢固化成它以后不再犯的环境。

写在最后

我现在越来越不觉得 Harness Engineering 是个营销词了。

它更像是 AI 时代的软件工程，被现实逼出来的一次重新分工。

以前很多东西做得差一点，也许还能靠几个老工程师硬撑住。现在主力执行者慢慢变成 Agent，这些以前模糊过去的地方，全都会被成倍放大。文档烂、边界松、日志乱、规格虚、验收空，这些东西以前只是“不够专业”，现在会直接把 Agent 用废。

所以最后你会发现，Harness Engineering 讨论的根本不是“怎么更优雅地用 AI”，而是一个老问题的新版本：

什么样的系统，才配得上持续协作？

以前这是问人的。

现在，也得问 Agent 了。

参考资料

鹅厂九人谈：如何让Agent自动持续进化

2026-03-04T06:00:00.000Z

鹅厂九人谈：如何让Agent自动持续进化

“落地一个 Agent 容易，但通过一定机制自动持续优化 Agent 却很难。” —— 一位鹅厂员工的灵魂拷问

前几天读到一篇文章，收录了 9 位鹅厂员工关于「Agent 如何自动持续进化」的讨论。说实话，看完之后我在椅子上坐了好一会儿没动——这些观点里有好几个，精准地戳到了我最近在用 AI 工具时一直隐隐感觉到、但没想明白的东西。

我们这个行业现在有一个很尴尬的现状：人人都在搭 Agent，但几乎没人说得清楚怎么让 Agent 越用越聪明。首版能跑，demo 炫酷，老板点头，然后呢？上线三个月，Agent 还在犯同样的错，用户还在重复同样的纠正，每次对话都像第一次上岗的实习生——永远在同一个坑里反复踩。

这篇文章不是简单的转述。我想做的，是把这 9 位的观点展开、补充、串联起来，结合我自己使用 Claude Code 等 AI 工具的体感，尝试回答一个问题：Agent 进化到底是一套什么样的系统？

1. 先别急着优化，先学会量化

第 1 位分享者说了一句话，听起来像废话，但其实是整件事的基石：

“关键的关键是建立自己业务的评估体系：对于你的 Agent 经常执行的任务，该怎么评价 AI 每次执行结果的好坏，有了量化指标之后才能谈优化。”

这话为什么重要？因为我见过太多团队在”优化 Agent”的时候，做的第一件事是——改 prompt。改了一版觉得好像好了，又改一版觉得好像又不行了，来回折腾三天，最后发现根本不知道到底是变好了还是变差了。

这跟写代码一个道理。你不会在没有测试的情况下重构一个核心模块对吧？TDD 的核心思想是”先写测试再写代码”，Agent 优化也是一样——先建评估体系，再谈优化策略。

具体量化什么？我觉得至少要覆盖这四个维度：

指标	含义	为什么重要
任务完成率	Agent 在无人干预的情况下成功完成任务的比例	最基本的能力衡量
Token 效率	完成同一任务消耗的 token 数	越少说明上下文管理越好
人工干预频率	用户需要纠正、补充、重试的次数	直接反映 Agent 的可靠性
错误恢复率	Agent 犯错后自主修复的比例	衡量”越用越聪明”的核心指标

没有这些数字，所谓的”优化”就是盲人摸象。你甚至不知道自己在改善什么。

2. 临时工和正式工：两种记忆策略

同一位紧接着说了一句更有意思的话：

“如果你对 AI 的定位是临时工，每次都是一锤子买卖，比如 Coding Assistant，Skill 和 Rule 比较合适；如果 AI 的定位是长工，需要它自身有成长，则还需要依赖记忆模块。”

这个”临时工 vs 正式工”的比喻太形象了。

临时工模式就是每次干完活就走，下次来还是从零开始。你靠的是给他一份详细的操作手册（Skills/Rules），让他照着做就行。Claude Code 的 CLAUDE.md 就是典型的”操作手册”——在上一篇文章里我们详细聊过它的用法。每次 Claude 犯一个错，你就加一条规则。久而久之，这份手册越来越完善，Agent 的表现也越来越好。但本质上，这不是 Agent 自己变聪明了，而是你给它的说明书写得更好了。

正式工模式就完全不一样了。你需要 Agent 记住上周犯过的错、上个月学到的经验、这个项目的特殊偏好。这就需要记忆模块——短期记忆处理当前任务的上下文，长期记忆沉淀跨会话的知识。

记忆策略的选择取决于你的业务场景：

高频重复任务（代码审查、测试生成）→ Skills/Rules 足矣，写好手册就行
长期陪伴场景（个人助理、项目管理）→ 需要记忆模块，Agent 要能成长
混合场景（大多数实际情况）→ 两者结合，手册兜底 + 记忆增强

我个人的感觉是，大多数人目前还停留在”临时工”阶段，CLAUDE.md 写得再好也只是一份更好的说明书。真正的突破点在于——让 Agent 像正式工一样，自己积累经验。

3. 失败比成功更值钱

第 2、3、5 位从不同角度说了同一件事，合并起来就是一个极其深刻的洞察：

“好数据并不是全部都正确的数据，恰恰是那些有问题但包含了纠正的数据。”

这话听着反直觉对吧？我们通常觉得，训练 AI 当然要用高质量的、正确的数据。但仔细想想——人类自己是怎么学习的？

你还记得高考备考的时候吗？考完试之后，老师会让你做一件事：整理错题本。不是让你把做对的题再做一遍，而是把做错的题反复看、反复练。为什么？因为错题里包含了你的知识盲区，而知识盲区正是提升空间最大的地方。

Agent 也是一样。一个 Agent 顺利完成了一百个任务，这一百条记录有价值吗？有，但有限。它说明 Agent 在这类任务上已经足够好了。真正珍贵的是那些“翻车 + 纠正”的数据——Agent 犯了什么错、用户怎么纠正的、最终正确的做法是什么。这些才是驱动进化的燃料。

这就是所谓的数据飞轮：

1
2
3

Agent 执行任务 → 犯错 → 用户纠正 → 记录"错误 + 纠正"数据对
    → 反馈给 Agent/模型 → Agent 下次遇到类似问题时避开坑
    → 犯新的错 → 继续循环

第 2 位说得很实在：”不然每次都像第一次上岗，永远在同一个坑里反复踩。”这句话应该贴在每一个搞 Agent 的人的工位上。

但这里有一个残酷的现实，第 3 位也提到了——很多 Agent 在数据飞轮转起来之前就被推翻了。因为用户使用频率低、容忍度有限，Agent 还没攒够足够的纠正数据就被宣判死刑了。这是一个先有鸡还是先有蛋的问题：Agent 需要犯错才能进步，但用户不给它犯错的机会。

4. 人在回路：安全员的智慧

第 3 位和第 6 位都提到了 Human-in-the-Loop（人在回路），但第 3 位用了一个绝佳的类比——自动驾驶安全员。

“在我们使用 Claude Code 过程中，Human-in-Loop 环节每次选择/ESC 取消/补充问题修正等过程，相当于人类在帮助 Agent 进行数据纠正（和自动驾驶安全员类似）。”

你想想自动驾驶安全员是怎么工作的？他坐在驾驶座上，大部分时间不动方向盘，让自动驾驶系统自己开。但他的眼睛一刻都没离开路面。当系统要做一个危险决策的时候，他会介入——接管方向盘、踩刹车、修正路线。而这每一次介入，都会被记录下来，成为训练自动驾驶系统的宝贵数据。

我们用 Claude Code 的时候，其实就是这个角色。想想你日常的操作：

显性反馈：点击确认（✓）或取消（ESC）—— 相当于安全员说”这步没问题”或”停，不对”
隐性反馈：看了 Agent 的建议但自己手动改了 —— 相当于安全员默默接管了方向盘
纠正数据：取消之后补充新的指令 —— 相当于安全员接管后手动把车开到正确位置

这三种信号的价值是递增的。显性反馈告诉 Agent 对不对，隐性反馈暗示了哪里不够好，纠正数据直接示范了正确做法。

这里有一个美妙的悖论：你干预得越多，未来需要干预的就越少。每一次纠正都在训练 Agent，每一次”安全员接管”都在让自动驾驶系统更可靠。前提是——这些干预数据被记录下来并反馈到系统中。如果你的 Agent 没有这个反馈机制，你就是白白当了一个永远不被倾听的安全员。

5. 冻结的大脑 vs 流动的上下文

第 5 位用了一个特别精准的数学类比，把 LLM 的知识来源说清楚了：

“模型矩阵和上下文向量，粗暴地说最后是要乘到一块去的。但模型是被冻结的部分，上下文是不断改变的部分。”

翻译成人话就是：大模型有两个大脑——一个是固定的（参数），一个是临时的（上下文）。你跟 ChatGPT 聊天时塞进去的所有内容，就是那个”临时大脑”。而模型本身那几十亿上百亿的参数，是”固定大脑”——一旦训练完就冻结了。

这就意味着，Agent 想要持续进化，只有两条路：

路径一：解冻固定大脑（模型可塑性）

让模型本身能够持续学习。这是 Online Learning / Continual Learning 领域的方向，技术门槛极高，目前只有大厂和顶级实验室在探索。普通开发者别想了。

路径二：巧用临时大脑（上下文工程）

既然模型参数改不了，那就把上下文做到极致。通过更好的 prompt 设计、更聪明的记忆管理、更精准的信息检索，让每次对话时塞给模型的”临时知识”更有效。

第 5 位说：”第一条留给训模高手来做。第二条是当下的最热方向，创新空间巨大。”

我完全同意。对于绝大多数人来说，上下文工程才是正道。你不需要训练一个新模型，你需要的是——在有限的上下文窗口里，塞进最有价值的信息。这包括：

任务相关的历史记录（Agent 之前在类似任务上犯过什么错）
用户偏好和习惯（你喜欢什么风格的代码、什么程度的解释）
领域知识的精准片段（不是整本文档，而是此刻最相关的那几段）

上下文窗口就像一个容量有限的工作台，你不可能把整个仓库都搬上来。聪明的做法是——只放此刻真正需要的工具和材料。

6. 让 Agent 学会反思

第 4 位只说了六个字：”强化学习了解一下！” 但第 6 位把这个方向展开到了一个让我非常兴奋的层面——元认知。

“结合元认知和本体论思想来设计 Agent：一方面依托本体知识库赋予 Agent 理解世界的能力，另一方面依托元认知赋予 Agent 对思考本身进行思考和进化的能力。”

元认知这个词听起来很学术对吧？但其实概念很简单——思考自己的思考。

人类之所以能持续进步，不只是因为我们会做事，更因为我们会反思。你写完一段代码之后会回头看看：”这段写得好不好？有没有更好的写法？我是不是又犯了上次那个错？”这种自我审视的能力，就是元认知。

强化学习提供了一种机制，让 Agent 通过”奖励”和”惩罚”来调整行为。但如果只有强化学习，Agent 学到的是”什么行为能获得奖励”，而不是”为什么这个行为好”。加上元认知，Agent 就不只是在试错，它还在理解自己为什么错了。

想象一个理想的 Agent 反思流程：

1. 执行任务 → 得到结果
2. 自我评估："这个结果好不好？哪里不够好？"
3. 归因分析："问题出在哪一步？是理解错了用户意图，还是选错了工具？"
4. 策略调整："下次遇到类似情况，我应该先确认意图再动手"
5. 记忆沉淀：把这条经验存下来

这不就是一个有自我意识的学习者吗？说实话，每次想到这里我都会有一种奇妙的感觉——我们在讨论的，到底是软件工程，还是认知科学？

7. 用 AI 优化 AI：自动进化的 System Prompt

第 7 位提供了一个非常落地的方案——用 AI 模型来逐步优化 system_message。

这个思路特别务实。我们都知道 system prompt 对 Agent 行为的影响有多大——一个好的 system prompt 和一个随便写的 system prompt，出来的效果可能天差地别。但问题是，怎么知道你的 system prompt 是好是坏？怎么系统性地改进它？

第 7 位的回答很直接：让 AI 自己来做这件事。

这里他还提到了一个重要的细节：XML 格式的结构化规则 >> 随手写的字符串。


<rules>
  <rule name="error_handling" priority="high">
    当遇到页面加载超时时，先截图记录当前状态，
    然后等待 3 秒重试，最多重试 2 次。
  rule>
  <rule name="form_filling" priority="medium">
    填写表单前先检查所有必填字段是否已定位到，
    未定位到的字段用日志标注并跳过。
  rule>
rules>


"你是一个浏览器自动化助手，帮我填写网页表单，遇到错误要重试。"

结构化的好处在于：模型能更清晰地理解每条规则的边界、优先级和适用条件。随手写的字符串呢？模型只能靠猜。

把这些串联起来，一个完整的 system prompt 自动优化闭环长这样：

运行 Agent → 收集执行数据和错误日志
    → 度量关键指标（完成率、错误率等）
    → 把数据喂给另一个 AI，让它分析问题并提议修改 system prompt
    → A/B 测试新旧 prompt
    → 择优上线 → 继续循环

这不就是”用 AI 优化 AI”吗？而且这个流程里，人类甚至不需要亲自动手改 prompt——只需要审核 AI 提出的修改建议是否合理。

8. 测试驱动的 Agent 进化

第 8 位的观点是整篇讨论中最系统化的，他直接描绘了一套多 Agent 测试流水线：

“设想：在每一次测评中，引入另外一个 multi-agent，用于 AI 产品的测试。Spec Agent 评测最终结果的质量与正确性。若它认为某个测试用例不通过，那么将自主分析错误原因、分派任务给 Coding SubAgent。后续则由 SubAgent 重新复盘、优化系统提示词，并提交 PR 给人类 review。”

翻译一下这个流水线：

Spec Agent（裁判）    →  评测 Agent 的输出是否达标
    ↓ 不达标
错误归因 Agent        →  分析哪里出了问题、置信度多高
    ↓ 高置信度
Coding SubAgent      →  修改 prompt / 代码 / 配置
    ↓
提交 PR              →  人类 Review
    ↓ 通过
合并上线              →  进入下一轮评测

这个设计有几个特别聪明的地方：

用 Agent 测试 Agent：LLM-as-Judge 不是新概念了，但把它系统化地嵌入迭代流程里，这是关键一步
置信度阈值：不是所有错误都触发自动修复，只有高置信度的归因才进入修复流程——避免误判导致越改越差
人类是守门员，不是执行者：人类不再需要手动分析错误、手动改 prompt。人类只需要 review PR，决定合不合并

第 8 位最后说了一句让我很有感触的话：”AI 时代所谓的测试驱动开发的最佳范式，人类大概率会彻底从执行者变为守门员和裁判了。”

这不是遥远的未来。现在用 Claude Code 的时候，我已经越来越多地在做”守门员”的工作——不是我在写代码，而是 Agent 在写，我在 review。不是我在调试，而是 Agent 在调试，我在判断它调得对不对。

写在最后

把 9 位的观点串联起来看，会发现 Agent 进化不是某一个单点技巧，而是一套完整的系统。如果要用一张图来概括：

┌──────────────┐
│   评估体系    │  ← 量化，才能谈优化
└──────┬───────┘
       ↓
┌──────────────┐
│   反馈闭环    │  ← 错误 + 纠正 = 进化燃料
└──────┬───────┘
       ↓
┌──────────────┐
│   记忆系统    │  ← 临时工 or 正式工
└──────┬───────┘
       ↓
┌──────────────┐
│   自我反思    │  ← 思考自己的思考
└──────┬───────┘
       ↓
┌──────────────┐
│   自动迭代    │  ← 用 AI 优化 AI
└──────────────┘

评估 → 反馈 → 记忆 → 反思 → 迭代，这五个环节缺一不可，形成一个不断自我强化的闭环。

说实话，写完这篇文章我最大的感触是——Agent 进化的本质，和人类学习的本质惊人地相似。我们也是通过犯错来成长、通过反思来进步、通过记忆来积累、通过考试来量化的。区别只在于，人类的这套系统是自然进化了几百万年的结果，而 Agent 的这套系统需要我们亲手设计。

我们既是 Agent 的使用者，也是 Agent 进化系统的设计者。这个身份很奇妙——你在教一个东西学会自己教自己。

原文链接：鹅厂员工怎么看Agent自动持续进化？

当程序员不再写代码——看完 Peter Steinberger 采访后的技术思考

2026-03-03T02:00:00.000Z

当程序员不再写代码——看完 Peter Steinberger 采访后的技术思考

“I always thought I loved programming. Turns out, what I really loved was creating.”

这个男人到底什么来头

前两天刷到了 Lex Fridman 播客第 491 期，嘉宾是 Peter Steinberger。说实话，如果你是做移动端开发的，PSPDFKit 这个名字你多少应该听过——十亿级别的装机量，做 PDF SDK 做到了行业天花板。这哥们花了 13 年时间把 PSPDFKit 做大，然后把公司卖了，退休了，消失了三年。

一般人到这儿故事就该结束了对吧？有钱有闲，环游世界，写写回忆录，完美收官。但 Peter 不是一般人。退休三年之后他说自己快无聊死了——“如果你每天早上醒来没有什么值得期待的事情，没有真正的挑战，那会非常非常无聊”。然后他搞了 OpenClaw，一个开源 AI Agent 项目，直接成了 GitHub 历史上增长最快的项目之一，目前251K Star(top1)，全世界都在讨论。

所以这期播客值得听，不只是因为 Peter 本身的传奇经历，更是因为他对 AI 时代软件开发的理解，真的跟大多数人不一样。他不是在纸上谈兵，他是真刀真枪地用 Agent 写生产代码，服务真实用户的人。

让 Agent 自己调试自己

整个采访里最让我上头的一个点，是 Peter 谈到他怎么调试 Agent 的 bug。

一般vibe时代前我们遇到 bug 是怎么做的？翻日志、打断点、读堆栈、加 print 语句，一层一层地排查。但vibe时代后的做法完全不一样，我们会直接问 Agent：“你看到了什么错误？去读源代码，找出问题在哪。” 但是更绝的是Peter会反问：“你能不能自己调用这个工具？”

这其实是一个非常反直觉的思路。我们习惯了把 Agent 当成一个执行指令的工具，但 Peter 是让 Agent 去理解自己的运行机制。他说了一句话让我印象很深：“I made the agent very aware — it knows what its source code is. It understands how it sits and runs in its own harness.” 他让 Agent 读自己的源码，理解自己是怎么被组装起来的，然后用这个认知去定位问题。

这东西说白了就是 Self-Modifying Software 的雏形。Peter 自己也说：”People talk about self-modifying software, I just built it.”

更深一层说，Peter 还提到了一个我觉得特别重要的理念：和 Agent 共情—换位思考。他说你得考虑 Agent 是怎么看你的代码库的——“它每次开始一个新会话，对你的项目一无所知，你得帮它建立上下文。” 这话听起来简单，但做到真的要转变思维方式。我们习惯了以自己的认知为中心来组织代码，但如果你的协作者是一个每次从零开始的 Agent，你就得重新思考代码结构、文档方式、甚至项目的文件命名。Peter 的原话是：”I’m not building the code base to be perfect for me — I want to build a code base that is very easy for an agent to navigate.” 这话要是放到两年前说出来，估计会被人骂疯了。但现在想想，确实有道理。

Agentic Engineering：不是 Vibe Coding

Peter 在采访中用了一个我很喜欢的说法来区分两种工作模式。他说：”I do agentic engineering, and then maybe after 3:00 AM, I switch to vibe coding, and then I have regrets on the next day.” 哈哈，凌晨三点以后做的决定谁没后悔过呢。

但玩笑归玩笑，Agentic Engineering 和 Vibe Coding 的区别是实质性的。Vibe Coding 是你大概给个方向，然后看着 Agent 去发挥，你凭感觉决定接不接受结果。而 Agentic Engineering 是你真正理解 Context Window 的限制、知道怎么给 Agent 搭建脚手架、怎么切分任务让多个 Agent 并行高效工作。

Peter 的实际工作流是这样的：他同时跑 4 到 10 个 Agent，用一个 3x3 的终端网格来管理它们，大部分 Agent 在同一个文件夹里工作。他很多指令是用语音输入的（用 Wispr Flow），甚至说他”至少 50% 的 prompt 都包含一张截图”。这就不是在 coding 了，这是在指挥。

他还提到了一个”复杂度曲线”的概念：最开始你用 AI 写代码，prompt 很简单——“帮我修一下这个 bug”。然后你开始搞复杂的编排，多 Agent 协作、工具调用、流程控制。但最终，当你真正掌握了这套东西之后，你会回到短 prompt——因为你已经把代码库、文档、工具链都调教到了 Agent 能一听就懂的程度。这个否定之否定的过程挺有意思的。

至于代码审查，Peter 的做法也和传统不一样。他不是自己逐行 review，而是先问 Agent：”你理解这个 PR 要做什么吗？” 确认 Agent 理解了意图之后，再问：”有没有更优的方案？” 然后让 Agent 自己回应 CI bot 的评论，通过了就自动合并。他还搞了 /automerge 和 /massageprs 这种自定义命令来批量管理 PR。这效率，说实话有点恐怖。

Skills 和 CLI 才是正道，MCP 靠边站

Peter 在采访中对 MCP 的态度可以说是毫不客气。他的原话是：“Almost all MCPs really should be CLIs. I say that as someone who wrote 5 MCPs myself.” 作为一个自己写过 MCP 的人来说这话，分量很重。

他总结了 MCP 的几个核心问题。第一是上下文污染——MCP 返回的数据会大块大块地塞进 Context Window。他举了个例子，光用 GitHub 的 MCP 就吃掉 23k tokens，最开始甚至接近 50k tokens。这对于寸土寸金的 Context Window 来说简直是灾难。第二是不支持组合调用——你没法像 Unix 管道那样把多个 MCP 的输出串联起来处理。第三是本质上是一套新语法——模型需要额外的训练才能理解怎么调用 MCP，而 CLI 命令？模型天生就懂。

相比之下，CLI + jq 管道的优势就太明显了。你可以精准地过滤数据，只让需要的结果进入上下文，不会造成任何污染。模型对 Unix 命令的理解是刻在骨子里的，不需要额外的 prompt 去解释。

Peter 说的 Skills 本质上就是一句话的功能描述，模型加载后直接就知道该调用什么 CLI 命令。简洁、高效、不浪费上下文。

当然他也承认 MCP 有一个不可替代的场景：需要维持状态的服务，比如 Playwright 做浏览器自动化，你需要一个持续运行的浏览器实例。但除了这类场景，Peter 的做法是：拿到一个 MCP，第一件事就是花一分钟把它转成 CLI。

说实话这个观点让我有一种”原来如此”的通透感。Unix 哲学里那句 “Do One Thing and Do It Well”，在 AI 时代不仅没有过时，反而焕发了新生。管道、过滤、组合——这些几十年前的老思想，恰恰是和 AI Agent 协作的最佳范式。

当编程变成织毛衣

这部分是整个采访最扎心的地方。

Peter 说了一个类比：编程这个技艺本身会一直存在，但会变成像织毛衣一样的东西——大家做这个是因为喜欢，不是因为什么实际用途。

你知道我第一次听到这话的时候是什么感受吗？说不上来，一种很复杂的东西。我们这些写代码的人，花了几千个小时沉浸在编辑器里，那种把一个复杂的算法写出来、所有测试通过的瞬间，那种凌晨三点终于把一个诡异的 bug 修好然后瘫在椅子上的成就感，那种在代码里找到心流状态、世界只剩下你和屏幕的感觉——这些东西，真的很难接受会被一个”没灵魂的玩意儿”取代。

Peter 注意到了很多开发者正在”mourning the loss of the flow state”——哀悼心流状态的失去。他把这比作工业革命时期工人砸蒸汽机的故事。当年的纺织工人觉得机器夺走了他们的手艺、他们的尊严、他们的身份认同。现在这个故事在技术圈重演了，只不过这次被威胁的不是体力劳动者，而是我们这些自诩为脑力劳动者的人。

但是 Peter 也说了一句很诚实的话——和 Agent 合作的时候，他也能进入类似的心流状态，”I never had so much fun than building this project”。只是那种感觉不一样了。以前的心流是在代码的细节里游泳，现在的心流是在更高的抽象层面做设计、做决策、做创造。

Peter 说他以前一直以为自己热爱的是编程，后来发现他真正热爱的是创造。这话听着简单吧？但真正对自己诚实地想想，我觉得大部分程序员其实都没有想清楚这个问题。我们究竟是喜欢”写代码”这个动作本身，还是喜欢”通过代码把脑子里的想法变成现实”这个过程？如果是后者，那 Agent 并不是在夺走你的东西，它只是换了一种方式帮你实现。

他还有一句话我记得很清楚：”不要把你的身份绑定在’程序员’这个标签上，你本质上是一个创造者。” 说实话，我知道这话是对的。但作为一个正在经历这场变革的开发者，真正做到这一点，比说出来难太多了。我的简历上写着”软件工程师”，我的技能树全部点在代码上，我的圈子里聊的都是框架和语言——这些东西突然被人说”不重要了”，你让我怎么轻描淡写地说一句”没关系我是创造者”？

但我也不得不承认，Peter 确实在身体力行。他真的从一个每天写 Objective-C 的 iOS 开发，变成了一个用语音指挥十个 Agent 同时干活的人。而且他做出来的东西比以前更疯狂、更有影响力。也许这就是答案——不是要放弃什么，而是要升级。

写在最后

两个多小时的播客看完，脑子里其实挺乱的。Peter 说的很多东西，我理性上都认同，但情感上还是需要时间消化。不过有一点我可以确定：这个行业的变化速度，已经快到了你如果不主动去理解新范式，下一次回头看的时候可能就已经被落下了。

至于编程会不会真的变成织毛衣？我不知道。但我觉得，不管怎样，那些凌晨三点修完 bug 的夜晚，那些和代码较劲的日子，都不会白费。它们构成了我们理解计算的底层直觉，而这个直觉，恰恰是在 Agent 时代做好 Agentic Engineering 的基础。

播客链接：Lex Fridman Podcast #491 - Peter Steinberger
Peter 的博客：steipete.me

程序员如何高效使用 Claude Code

2026-03-02T04:00:00.000Z

程序员如何高效使用 Claude Code

Claude Code 是 Anthropic 推出的 CLI 编程助手，能直接在终端中理解你的代码仓库、执行命令、编辑文件、管理 Git——简单说，它就是一个住在你终端里的高级程序员搭档。但和所有强大工具一样，会用和用好之间隔着一道鸿沟。

本文综合了 Claude Code 创始人 Boris Cherny、Vue.js 作者尤雨溪、Google Chrome 工程负责人 Addy Osmani 等大咖的实战经验，以及 Anthropic 黑客松冠军 Affaan Mustafa 的两篇深度指南（The Shorthand Guide 和 The Longform Guide）的精华，以及社区优秀开源项目 everything-claude-code（50K+ Stars）和 awesome-claude-skills（38K+ Stars）的核心内容，帮你从”能用”进阶到”用好”。

一、理解核心约束：200K 上下文窗口

在学任何技巧之前，先理解这一点：Claude Code 的 200K token 上下文窗口是你最稀缺的资源。

一个 200 文件的中型项目全部加载需要约 800K token，是可用容量的 4 倍。高强度工作 30 分钟内就能把上下文填满。一旦上下文接近满载，Claude 会开始”遗忘”早期指令，输出质量急剧下降。

所以，所有最佳实践的核心都围绕一件事：上下文管理。

关键操作

操作	用途
`/clear`	在不相关任务之间清空上下文（最常被推荐的技巧）
`/compact <描述>`	手动压缩上下文，在 70-80% 容量时执行
`/context`	审计 token 使用情况
`/statusline`	自定义状态栏，实时监控上下文占用百分比

黄金法则：在上下文使用率达到 70-80% 时手动执行 /compact，不要等到 95% 的自动压缩——那时已经太晚了。禁用自动压缩，在逻辑断点手动操作。

二、CLAUDE.md — 最重要的配置文件

CLAUDE.md 是 Claude Code 在每次会话开始时自动加载的指令文件，相当于给你的 AI 搭档写一份”入职手册”。

该写什么

# 项目构建
- 构建: `pnpm build`
- 测试: `pnpm test`
- lint: `pnpm lint:fix`

# 代码规范
- 使用 TypeScript 严格模式
- 组件使用 PascalCase 命名
- 禁止使用 any 类型，必须显式声明类型
- 错误处理统一使用自定义 AppError 类

# Git 规范
- 提交信息格式: `feat/fix/docs(scope): description`
- 分支命名: `feature/xxx` 或 `fix/xxx`

# IMPORTANT: 压缩时保留
当压缩上下文时，必须保留完整的已修改文件列表和所有测试命令。

不该写什么

Claude 自己能推断出来的（标准语言规范）
频繁变动的信息
文件逐个说明（太冗长）
“写出干净的代码”这种废话
详细的 API 文档（改用链接）

关键原则

控制在 50-100 行以内（约 2500 token）。太长的 CLAUDE.md 会导致规则被忽略——Boris Cherny 称之为”规则失忆症”
每条规则要有必要性：问自己”删掉这条 Claude 会犯错吗？”如果不会，就删掉
用强调语气标注关键规则：例如 IMPORTANT: 或 你必须
提交到 Git：让团队共同维护，Boris 的团队每周更新多次
Claude 每犯一次错，就加一条规则：这是 Boris 的日常做法
用 @path/to/import 语法引用额外文件，不要把所有内容堆在一个文件里

文件层级

~/.claude/CLAUDE.md          # 全局配置（所有项目生效）
./CLAUDE.md                   # 项目配置（团队共享）
./CLAUDE.local.md             # 本地覆盖（.gitignore）
./src/CLAUDE.md               # 子目录配置（monorepo）

Rules 目录 — 模块化替代方案

对于大型项目，用 .claude/rules/ 目录按关注点拆分规则：

~/.claude/rules/
  security.md      # 不允许硬编码密钥，必须验证输入
  coding-style.md  # 不可变性，文件大小限制
  testing.md       # TDD 工作流，80% 覆盖率
  git-workflow.md  # 常规提交格式
  agents.md        # 何时委派给子代理
  performance.md   # 模型选择策略

三、Subagent（子代理）— 上下文保护的利器

子代理是 Claude Code 最强大的特性之一。每个子代理在独立的上下文窗口中运行，不会污染你的主会话。

尤雨溪的核心建议

“开一批 subagent，一个一个 fix，不要在一个 session 里面批量 fix，容易因为上下文不足产生幻觉。”
— 尤雨溪 (@yuxiyou)

这条建议揭示了一个关键原则：宁可开多个子代理逐一处理，也不要在一个会话里塞太多任务。每个子代理有自己的上下文窗口，不会互相干扰，也不会因为上下文过长而产生幻觉。

子代理定义示例

# .claude/agents/code-reviewer.md
---
name: code-reviewer
description: 对实现完成的代码进行质量审查
tools: Read, Grep, Glob
model: opus
---
你是一位高级代码审查工程师。审查要点：
- 边界条件和错误处理
- 性能问题和内存泄漏
- 安全漏洞（注入、XSS 等）
- 代码可读性和维护性

迭代检索模式

子代理返回摘要以节省上下文，但主代理拥有子代理缺乏的语义上下文（主代理理解目的，子代理只知道字面查询）。因此：

主代理评估每个子代理的返回
在接受前提出澄清性的后续问题
子代理回到源头寻找答案
循环直到充分（最多 3 个周期）

关键：传递目标上下文，而不仅仅是查询。

Writer/Reviewer 模式

这是社区公认的高质量工作流：

Session A（Writer）：实现功能代码
Session B（Reviewer）：用全新的上下文审查代码，没有”自己写的代码一定没问题”的偏见

四、Hooks — 确定性的自动化

CLAUDE.md 的指令是”建议性”的，Claude 可能遵守也可能忽略。而 Hooks 是确定性的——它们每次都会执行，没有例外。

六种 Hook 事件

事件	触发时机	用途示例
PreToolUse	工具执行前	阻止危险命令、tmux 提醒
PostToolUse	工具执行后	自动格式化、TypeScript 类型检查
UserPromptSubmit	发送消息时	拦截用户输入
Stop	Claude 结束响应时	保存会话状态、console.log 检测
PreCompact	上下文压缩前	保存关键上下文
Notification	权限请求时	系统通知

实战 Hooks 配置

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "npx prettier --write $CLAUDE_FILE_PATH || true"
        }]
      },
      {
        "matcher": "Edit && .ts/.tsx",
        "hooks": [{
          "type": "command",
          "command": "npx tsc --noEmit || true"
        }]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash && (npm|pnpm|yarn|cargo|pytest)",
        "hooks": [{
          "type": "command",
          "command": "if [ -z \"$TMUX\" ]; then echo '[Hook] 建议在 tmux 中运行长命令' >&2; fi"
        }]
      },
      {
        "matcher": "Write && .md",
        "hooks": [{
          "type": "command",
          "command": "node .claude/hooks/block-non-readme-md.js"
        }]
      }
    ],
    "Stop": [
      {
        "matcher": "*",
        "hooks": [{
          "type": "command",
          "command": "node .claude/hooks/check-console-log.js"
        }]
      }
    ]
  }
}

Pro tip：用 Stop hook（会话结束时执行一次）来持久化学习成果，而不是 UserPromptSubmit（每条消息都执行，影响延迟）。
更 Pro 的 tip：用 hookify 插件对话式创建 Hook，运行 /hookify 然后描述你想要的行为。

五、上下文与记忆管理 — 跨会话持久化

跨会话记忆文件

创建 .tmp 文件在 .claude/ 目录中追踪会话进度：

# .claude/session-state.tmp

## 已验证有效的方案
- 用 Vite 替代 Webpack 后构建时间从 45s → 8s（已验证）
- API 鉴权使用 JWT + refresh token 方案（已通过安全审查）

## 已尝试但失败的方案
- esbuild 直接打包——不支持 CSS Modules（放弃）
- 尝试用 Redis 缓存——引入了竞态条件（回退）

## 尚未尝试
- 服务端渲染优化
- 数据库查询索引优化

动态系统提示注入

不要把所有内容都塞进 CLAUDE.md，用 CLI 标志动态注入上下文：

1	claude --system-prompt "$(cat memory.md)"

系统提示的权威性高于用户消息，用户消息又高于工具结果。这给了你精确控制加载内容的能力。

实用别名设置：

1
2
3

alias claude-dev='claude --system-prompt "$(cat ~/.claude/contexts/dev.md)"'
alias claude-review='claude --system-prompt "$(cat ~/.claude/contexts/review.md)"'
alias claude-research='claude --system-prompt "$(cat ~/.claude/contexts/research.md)"'

记忆持久化 Hooks

三个被低估的 Hook 实现记忆管理：

PreCompact Hook — 在上下文压缩前保存关键状态
Stop Hook — 会话结束时持久化学习成果
SessionStart Hook — 新会话自动加载之前的上下文

持续学习系统

当 Claude 发现非平凡的洞见（调试技巧、变通方案、项目特定模式）时，将其捕获为新的 Skill。后续类似问题会自动加载该 Skill，避免重复浪费 token。

六、Token 优化 — 省钱又提效

模型选择框架

不要总是用最贵的模型，90% 的编码任务 Sonnet 就够了：

任务类型	推荐模型	理由
探索/搜索文件	Haiku	速度和成本优势
简单编辑	Haiku	单文件变更，指令明确
多文件实现	Sonnet	编码工作的最佳平衡
PR 审查	Sonnet	上下文理解 + 细微检测
文档编写	Haiku	结构化输出简单
复杂架构	Opus	需要深度推理
安全分析	Opus	不能遗漏漏洞
调试系统性问题	Opus	需要持有整个系统上下文

升级到 Opus 的信号：Sonnet 首次尝试失败、任务涉及 5+ 文件、架构决策、安全关键代码。

用 /model sonnet 切换默认模型，需要时再 /model opus。

工具优化

用 mgrep 替代 grep/ripgrep，token 消耗减少约 50%
保持文件在数百行而非数千行，改善 token 成本和首次成功率
用 --lines 选项限制文件读取范围，一个 400 行文件节省约 70% token

MCP 替换策略

许多 MCP 只是包装了现有 CLI 工具。虽然方便，但消耗上下文空间。建议：

用 /gh-pr 命令包装 gh pr create 替代 GitHub MCP
用 Supabase CLI 直接通过 Skill 操作替代 Supabase MCP
每个不启用的 MCP 都在为你节省上下文空间

七、工作流最佳实践

四阶段工作流（官方推荐）

1	探索 → 规划 → 实现 → 验证

探索：进入 Plan Mode（Shift+Tab），让 Claude 阅读代码、回答问题，不做修改
规划：要求 Claude 创建详细的实现计划，用 Ctrl+G 在编辑器中审查
实现：切换回 Normal Mode，Claude 按计划编码并自我验证
验证：要求 Claude 运行测试、构建、lint，确认一切正常

使用 Plan Mode 进行多文件修改时，架构错误减少约 45%。

验证循环 — 单一最高杠杆率实践

所有来源一致同意：给 Claude 一种验证自身工作的方式，可以将最终结果的质量提升 2-3 倍。

验证方式包括：

运行测试套件
执行构建和类型检查
lint 和格式化检查
截图对比（UI 工作）
端到端测试

1 2	# 在 CLAUDE.md 中添加验证指令每次修改代码后，必须运行 `pnpm test` 和 `pnpm build` 验证无错误。

验证评估指标

pass@k: 至少 k 次尝试中有一次成功
        k=1: 70%   k=3: 91%   k=5: 97%

pass^k: 全部 k 次尝试都必须成功
        k=1: 70%   k=3: 34%   k=5: 17%

需要工作一次时用 pass@k，需要一致性时用 pass^k。

五阶段顺序架构（复杂任务）

阶段 1：研究 (Explore agent)           → research-summary.md
阶段 2：规划 (Planner agent)           → plan.md
阶段 3：实现 (TDD-guide agent)         → 代码变更
阶段 4：审查 (Code-reviewer agent)     → review-comments.md
阶段 5：验证 (Build-error-resolver)    → 完成或循环

关键规则：

每个代理接收一个明确输入，产出一个明确输出
输出成为下一阶段的输入
绝不跳过阶段
阶段间用 /clear 清理上下文
将中间输出存储在文件中

八、并行工作 — 成倍提升吞吐量

Boris Cherny 的工作设置

Claude Code 创始人 Boris Cherny 的日常工作方式：

5 个本地终端会话（编号 1-5）
5-10 个额外的 claude.ai/code 网页会话
每个本地会话使用独立的 Git checkout（不是分支或 worktree）
系统通知提醒何时 Claude 需要输入
用 --teleport 在本地和网页会话之间交接
每天早上从手机上启动会话

并行策略

/fork — 为不重叠的任务创建分支会话。主聊天处理代码修改，fork 处理代码库问题、状态查询或外部服务研究。

Git Worktree — 为重叠的并行任务创建独立工作树：

git worktree add ../project-feature-a feature-a
git worktree add ../project-feature-b feature-b

cd ../project-feature-a && claude

Cascade 方法：

在新标签页中打开新任务（向右）
从左到右依次处理（最旧到最新）
上限 3-4 个并行任务

指导哲学：用最少的必要并行化完成最大的工作量。

两实例启动模式（项目初始化）

空仓库用两个 Claude 实例并行启动：

实例 1（脚手架代理）：建立项目结构、创建配置（CLAUDE.md、rules、agents）

实例 2（深度研究代理）：连接服务和网络搜索、开发详细 PRD、创建架构图（Mermaid 格式）、编译参考文档

九、Skills 和 Commands — 可复用的工作流

Skills vs Commands

Skills：~/.claude/skills/ — 更广泛的工作流定义，Claude 根据任务自动激活
Commands：~/.claude/commands/ — 通过斜杠命令快速执行的提示

# 目录结构示例
~/.claude/skills/
  pmx-guidelines.md      # 项目特定模式
  coding-standards.md    # 语言最佳实践
  tdd-workflow/          # 多文件 Skill
  security-review/       # 检查清单 Skill

~/.claude/commands/
  commit-push-pr.md      # Boris 每天用几十次的命令
  refactor-clean.md      # 长会话后清理死代码
  deploy-check.md        # 部署前检查

Skills 中的 Codemap

Skills 可以包含 codemap——让 Claude 快速导航代码库而不必消耗大量上下文进行探索：

# .claude/skills/project-map.md
## 代码地图
- `src/api/` — 所有 REST API 端点
- `src/services/` — 业务逻辑层
- `src/models/` — 数据库模型
- `src/middleware/` — Express 中间件（auth、error handling）
- `tests/` — 测试文件，镜像 src 结构

社区精选 Skills（awesome-claude-skills）

awesome-claude-skills 仓库收录了 150+ 个技能：

分类	数量	示例
开发工具	19	代码质量分析、Playwright 自动化、MCP 服务器构建
文档处理	5	Word/PDF/PPT/Excel 操作
数据分析	4	CSV 汇总、PostgreSQL 查询、根因分析
安全	4	数字取证、威胁狩猎、元数据提取
创意媒体	6	Canvas 设计、图像增强、GIF 创建
效率工具	8	文件整理、发票管理、简历定制
应用自动化	78+	通过 Composio 集成 HubSpot、Jira、Slack、GitHub 等 1000+ 应用

安装使用

# Claude Code 安装
mkdir -p ~/.config/claude-code/skills/
# 将 skill 文件夹复制到该目录
# 启动 Claude Code，Skills 自动激活

# 插件方式安装
/plugin marketplace add affaan-m/everything-claude-code
/plugin install everything-claude-code@everything-claude-code

十、MCP 服务器 — 扩展 Claude 的能力边界

MCP（Model Context Protocol）让 Claude Code 能连接外部工具和服务。它不是 API 的替代品，而是围绕 API 的提示驱动包装器。

关键警告

“你的 200K 上下文窗口可能因为启用了太多工具而只剩 70K。”

可以配置 20-30 个 MCP，但同时启用的不要超过 10 个 / 80 个工具
每个 MCP 的工具描述都会消耗上下文 token
用 /mcp 查看和切换 MCP 状态
如果底层服务有 CLI（如 gh、supabase、vercel），优先用 CLI 技能替代 MCP

十一、Plugins — 打包好的工具集

插件将工具打包以便安装，避免繁琐的手动设置。一个插件可以是 Skill + MCP 的组合，或者 Hooks/工具的捆绑。

插件	用途
`typescript-lsp`	TypeScript 智能补全（编辑器外运行时必备）
`pyright-lsp`	Python 类型检查
`hookify`	对话式创建 Hooks
`mgrep`	比 ripgrep 更好的搜索，节省约 50% token
`frontend-design`	UI/UX 模式
`commit-commands`	Git 工作流自动化
`context7`	实时文档查询

LSP 插件的价值

如果你经常在编辑器之外运行 Claude Code，LSP 插件尤其有用。Language Server Protocol 让 Claude 获得实时类型检查、跳转定义和智能补全，无需 IDE。

十二、编辑器搭配建议

Zed（社区推荐）

Rust 编写，启动极快，巨型代码库也不卡顿，资源占用极低：

速度：Claude 快速编辑文件时编辑器跟得上
Agent Panel：实时追踪 Claude 的文件变更
CMD+Shift+R：快速访问所有自定义斜杠命令
低资源占用：不会和 Claude 竞争 RAM/CPU（运行 Opus 时很重要）

编辑器通用技巧

分屏：一侧终端运行 Claude Code，另一侧编辑器
Ctrl+G：在编辑器中打开 Claude 当前工作的文件
开启自动保存：确保 Claude 读取的文件始终是最新的
文件监听：确认编辑器自动重新加载被修改的文件

语音输入

用语音转录代替打字——对大多数人来说更快。工具：superwhisper（Mac）、MacWhisper（Mac）。Claude 即使有转录错误也能理解意图。

十三、常见陷阱及避免方法

1. “厨房水槽”式会话

从一个任务开始，中途问一个无关的问题，再回到原来的任务。上下文被无关信息填满。

解决：/clear 在不相关任务之间。完成一个功能要去修一个 Bug？先 /clear。

2. 反复纠正

Claude 做错了，你纠正它，还是错的，你再纠正。上下文充满了失败的尝试。

解决：两次纠正失败后，/clear 然后重写一个更好的初始提示，把你学到的教训融入进去。

3. CLAUDE.md 过度膨胀

写了 500 行的 CLAUDE.md，Claude 忽略了一半。重要规则淹没在噪音中。

解决：无情精简。如果 Claude 在没有某条指令的情况下就能做对，就删掉它或者转成 Hook。

4. 全量加载项目

把 200 个文件的项目全部喂给 Claude——消耗约 800K token，是窗口的 4 倍。

解决：精准定位 3-5 个目标文件，效果远好于批量加载 50 个文件。

5. 跳过规划

让 Claude 直接开始写代码，结果解决了错误的问题。

解决：涉及 3 个以上文件的修改，一律使用 Plan Mode。

6. 无限探索

让 Claude “调查一下”但不限定范围，它读了几百个文件把上下文填满。

解决：严格限定调查范围，或使用子代理进行探索。

7. 草率开启 bypass 模式

23% 经历过破坏性执行的用户启用了 --dangerously-skip-permissions。

解决：用 /permissions 白名单安全命令。只在没有网络访问的容器中使用 skip permissions。

十四、快捷键与实用命令速查表

快捷键

快捷键	功能
`Ctrl+U`	删除整行（比退格快得多）
`Shift+Enter`	多行输入
`Shift+Tab`	切换思考模式
`Esc Esc`	中断 Claude / 恢复代码
`@`	搜索文件
`/`	触发斜杠命令
`!`	快速执行 bash 命令
`Ctrl+G`	在编辑器中编辑
`Tab`	切换思考显示

常用命令

命令	用途
`/clear`	清空上下文（最常用）
`/compact`	手动压缩上下文
`/context`	审计 token 使用
`/fork`	分支会话
`/model`	切换模型
`/rewind`	回退到之前的状态
`/checkpoints`	文件级撤销点
`/statusline`	自定义状态栏
`/mcp`	管理 MCP 服务器
`/plugins`	管理插件
`/rename`	标记聊天便于管理

终端别名

1 2	alias c='claude' alias cc='claude --continue' # 继续上次会话

十五、科研场景：用 Claude Code 驱动 AI 研究全流程

Claude Code 不只是写业务代码的工具。结合 Hugging Face Skills 插件，它可以覆盖从数据准备到论文发表的完整 AI 科研工作流。

安装 Hugging Face Skills

/plugin marketplace add huggingface/skills
/plugin install hugging-face-model-trainer@huggingface/skills
/plugin install hugging-face-trackio@huggingface/skills
# 按需安装其他 skill

9 个 Skills 覆盖完整研究流程

Skill	用途	科研价值
Model Trainer	用 TRL 训练/微调语言模型（SFT、DPO、GRPO、奖励建模）	可复现的训练流程，支持硬件选择和成本估算，GGUF 转换支持本地部署
Trackio	实时训练指标追踪和可视化仪表盘	实验追踪和消融研究，团队协作共享仪表盘到 HF Spaces
Evaluation	模型评估和基准测试管理	导入 Artificial Analysis API 基准分数，用 vLLM/lighteval 框架运行自定义评估
Datasets	创建和管理 HF Hub 上的数据集	创建基准数据集、训练语料，SQL 查询和数据转换
Paper Publisher	在 HF Hub 发布和管理研究论文	论文-模型-数据集-代码一站式关联，提升可发现性和可复现性
Gradio	构建交互式 Web UI 和演示	为论文构建可交互 Demo，让审稿人/读者直接体验模型
Jobs	在 HF 基础设施上执行云端计算任务	无需自有 GPU，支持大规模训练和评估
HF CLI	Hub 命令行操作（上传/下载模型和数据集）	简化数据流水线和模型分发
Tool Builder	创建可复用的 API 自动化脚本	构建可复现的数据预处理流水线

典型科研工作流示例

用自然语言驱动整个流程：

第 1 步：数据准备
> "用 HF Datasets skill 创建一个指令微调数据集，基于我 data/ 目录下的 jsonl 文件"

第 2 步：模型微调
> "用 Model Trainer skill 对 Qwen2.5-7B 进行 SFT 微调，
   使用刚创建的数据集，估算 A100 的成本"

第 3 步：实验追踪
> "用 Trackio 监控训练过程，记录 loss、learning rate 和 eval metrics，
   同步仪表盘到我的 HF Space"

第 4 步：模型评估
> "用 Evaluation skill 在 MMLU、HumanEval 和我的自定义基准上评估模型，
   和 baseline 对比生成评估表格"

第 5 步：构建 Demo
> "用 Gradio 为微调后的模型创建一个对话式 Demo，部署到 HF Spaces"

第 6 步：发布论文
> "用 Paper Publisher 在 HF Hub 上创建论文页面，
   关联训练好的模型、数据集和 Demo"

为什么科研人员应该关注

可复现性：所有 Skill 输出可版本控制的代码和配置，论文审稿人可以一键复现
开放科学：论文、模型、数据集、代码在 HF Hub 上形成完整的工件链
零硬件门槛：通过 HF Jobs 在云端训练大模型，内置成本估算
团队协作：Trackio 实时仪表盘支持多人同时查看实验进展
跨平台：这些 Skill 同时支持 Claude Code、Cursor、Codex CLI 和 Gemini CLI

一个完整的 AI 研究项目——从数据集构建到论文发表——现在可以在 Claude Code 终端中用自然语言指令驱动完成，所有代码自动生成且可复现。

十六、安全最佳实践

核心原则

“每个集成都创建了一个潜在的入侵点。”

沙箱与访问控制

通过 allowedTools 限制工具为仅必要功能
实施拒绝列表阻止敏感目录：~/.ssh、~/.aws、凭据文件
不受信任的仓库在 --network=none 的 Docker 容器中运行

数据保护

LLM 读取的一切内容实际上都是可执行上下文——验证所有外部内容
审计配置和 Skills 中的所有外部链接
内联外部文档而不是链接到可能被篡改的源

记忆投毒预防

定期审计持久化文件——恶意片段可能跨会话积累。

AgentShield

使用 npx ecc-agentshield scan 进行自动漏洞扫描，覆盖 102 条安全规则。

总结

Claude Code 不仅仅是一个代码补全工具，它是一个需要管理的高级协作者。像管理一个极其聪明但记忆有限的团队成员一样来使用它：

实践	影响
给 Claude 验证手段（测试、截图、构建）	质量提升 2-3 倍
`/clear` 在不相关任务之间	防止上下文污染
使用 Plan Mode 进行多文件修改	架构错误减少约 45%
CLAUDE.md 控制在 100 行以内	防止规则失忆
用子代理做研究	保护主上下文窗口
在 70-80% 容量时 `/compact`	避免性能下降
并行会话用独立 Git checkout	成倍提升吞吐量
PostToolUse Hook 自动格式化	零例外的一致性
禁用未使用的 MCP	回收上下文空间
两次纠正失败后 `/clear` 重写	比累积修复更干净

“早期我花时间构建可复用的工作流和模式。构建过程很繁琐，但随着模型和代理工具的改进，这产生了疯狂的复利效应。” — Affaan Mustafa

掌握这些原则，你就能把 Claude Code 从一个”偶尔有用的工具”变成”不可或缺的编程搭档”。

参考资源

Claude Code 官方文档
everything-claude-code — 50K+ Stars 的 Claude Code 全方位指南
The Shorthand Guide to Everything Claude Code — 简明指南
The Longform Guide to Everything Claude Code — 深度指南
awesome-claude-skills — 150+ 可复用 Skills 仓库
Boris Cherny 的工作流 — Claude Code 创始人如何使用自己的工具
Addy Osmani 的 AI 编码工作流 — Google 工程负责人的实战经验
YK 的 45 个 Claude Code 技巧
32 Claude Code Tips: From Basics to Advanced
Hugging Face Skills — 9 个 AI/ML 科研 Skills，覆盖训练、评估、发布全流程

KMP详解

2025-09-14T02:52:41.000Z

KMP详解

例题 28.找出字符串中第一个匹配项的下标

题解 28.找出字符串中第一个匹配项的下标
这个算法第一次听说，假设你不是oi的话就是在数据结构课上，但是鉴于部分中国大学计算机系老师毋庸置疑的 “水” 平和令人发指的语言表达能力，大部分学生都是迷迷糊糊的，下面我对这个算法进行下详细讲解，希望对大家有所帮助。

next数组

next数组是KMP算法核心，含义：所有p[1~j]的相等的前缀和后缀中长度的最大值
这里说明下细节，两个需要匹配的字符串数组下标建议从1开始因为后续j的值直接对应前j个字符，无需额外计算偏移量,比如模式串 p = “abcabx” 下标从1开始时，p[1]=’a’、p[2]=’b’…p[6]=’x’，next[5] 直接表示前5个字符abcab的最长匹配长度（值为 2），逻辑清晰。

如上图可以看出next数组的实际含义，第一个A没有匹配的0，第二个B同理，第三个A和第一个A匹配所以记位1，AB和前面的AB匹配长度位2所以记做2，C没有匹配的记做0，所以next[4] = 2。之后子串或者所谓模式串往后移动两个即可。
通过这个例子也可以看出KMP的优势就是，当匹配到不同字符的时候，由于已经知道前面匹配成功的字符信息，就可以利用信息避免暴力遍历方法中的回退操作。也就是上面指针步回退，那么算法的时间复杂度就是线性的了（从O(n*m)到O(n+m))!

计算 next 数组

for (int i = 2, j = 0; i <= m; i++) {
            while (j > 0 && p.charAt(i) != p.charAt(j + 1)) {
                j = next[j];
            }
            if (p.charAt(i) == p.charAt(j + 1)) {
                j++;
            }
            next[i] = j;
        }

就按照上面的例子进行讲解说明：
数组 next 长度为 m + 1（m 是子串长度，这里 m = 5），所以 next 数组大小为 6。
循环变量 i 从 2 开始（因为子串第一个字符索引为 1，next[1] 固定为 0，从第二个字符，即索引 2 开始计算），j 初始化为 0。
第一次循环（i = 2，计算 next[2]）
比较 p.charAt(i)（i = 2，即子串中索引为 2 的字符 ‘B’）和 p.charAt(j + 1)（j = 0，所以是 p.charAt(1)，即字符 ‘A’）。
因为 ‘B’ != ‘A’，且 j = 0，不满足 j > 0，所以 while 循环不执行。
由于 p.charAt(i) != p.charAt(j + 1)，j 保持 0，所以 next[2] = j = 0。
第二次循环（i = 3，计算 next[3]）
比较 p.charAt(3)（字符 ‘A’）和 p.charAt(1)（字符 ‘A’）。
因为 ‘A’ == ‘A’，所以 j++，此时 j = 1。
然后 next[3] = j = 1。
第三次循环（i = 4，计算 next[4]）
比较 p.charAt(4)（字符 ‘B’）和 p.charAt(2)（字符 ‘B’）。
因为 ‘B’ == ‘B’，所以 j++，此时 j = 2。
然后 next[4] = j = 2（这与图片里子串 next 数组中对应位置的值为 2 一致）。
第四次循环（i = 5，计算 next[5]）
比较 p.charAt(5)（字符 ‘C’）和 p.charAt(3)（字符 ‘A’）。
因为 ‘C’ != ‘A’，且 j = 2 > 0，进入 while 循环，执行 j = next[j]，即 j = next[2] = 0。
再次比较 p.charAt(5)（’C’）和 p.charAt(1)（’A’），还是不相等，且 j = 0，while 循环结束。
由于 p.charAt(i) != p.charAt(j + 1)，j 保持 0，所以 next[5] = j = 0。

在主串中匹配模式串

for (int i = 1, j = 0; i <= n; i++) {
            while (j > 0 && s.charAt(i) != p.charAt(j + 1)) {
                j = next[j];
            }
            if (s.charAt(i) == p.charAt(j + 1)) {
                j++;
            }
            if (j == m) {
                return i - m;//i-m+1,但是从1开始所以要-1
            }
        }

第 1 次循环：

// 1. 检查不匹配时的回溯（j=0，不满足j>0，while循环不执行）
while (j > 0 && s.charAt(1) != p.charAt(j + 1)) {
    j = next[j];
}
// 2. 字符匹配判断：s[1]='A' == p[1]='A'（j+1=1），j自增为1
if (s.charAt(1) == p.charAt(j + 1)) {
    j++; 
}
// 3. 检查是否完全匹配：j=1 != 7，不返回
if (j == m) {
    return i - m;
}

第 2 次循环：

// 1. while循环：j=1>0，但s[2]='B' == p[2]='B'（j+1=2），循环不执行
while (j > 0 && s.charAt(2) != p.charAt(j + 1)) {
    j = next[j];
}
// 2. 字符匹配：s[2]='B' == p[2]='B'，j自增为2
if (s.charAt(2) == p.charAt(j + 1)) {
    j++; 
}
// 3. 完全匹配检查：j=2 != 7，不返回
if (j == m) {
    return i - m;
}

第 3 次循环：

// 1. while循环：j=2>0，但s[3]='A' == p[3]='A'（j+1=3），循环不执行
while (j > 0 && s.charAt(3) != p.charAt(j + 1)) {
    j = next[j];
}
// 2. 字符匹配：s[3]='A' == p[3]='A'，j自增为3
if (s.charAt(3) == p.charAt(j + 1)) {
    j++; 
}
// 3. 完全匹配检查：j=3 != 7，不返回
if (j == m) {
    return i - m;
}

第 4 次循环：

// 1. while循环：j=3>0，但s[4]='B' == p[4]='B'（j+1=4），循环不执行
while (j > 0 && s.charAt(4) != p.charAt(j + 1)) {
    j = next[j];
}
// 2. 字符匹配：s[4]='B' == p[4]='B'，j自增为4
if (s.charAt(4) == p.charAt(j + 1)) {
    j++; 
}
// 3. 完全匹配检查：j=4 != 7，不返回
if (j == m) {
    return i - m;
}

第 5 次循环：

// 1. while循环：j=4>0，且s[5]='A' != p[5]='C'（j+1=5），执行回溯
while (j > 0 && s.charAt(5) != p.charAt(j + 1)) {
    j = next[j]; // j = next[4] = 2（根据next数组取值）
}
// 2. 回溯后判断：s[5]='A' == p[3]='A'（j+1=3），j自增为3
if (s.charAt(5) == p.charAt(j + 1)) {
    j++; 
}
// 3. 完全匹配检查：j=3 != 7，不返回
if (j == m) {
    return i - m;
}

第 6 次循环：

// 1. while循环：j=3>0，但s[6]='B' == p[4]='B'（j+1=4），循环不执行
while (j > 0 && s.charAt(6) != p.charAt(j + 1)) {
    j = next[j];
}
// 2. 字符匹配：s[6]='B' == p[4]='B'，j自增为4
if (s.charAt(6) == p.charAt(j + 1)) {
    j++; 
}
// 3. 完全匹配检查：j=4 != 7，不返回
if (j == m) {
    return i - m;
}

第 7 次循环：

// 1. while循环：j=4>0，但s[7]='C' == p[5]='C'（j+1=5），循环不执行
while (j > 0 && s.charAt(7) != p.charAt(j + 1)) {
    j = next[j];
}
// 2. 字符匹配：s[7]='C' == p[5]='C'，j自增为5
if (s.charAt(7) == p.charAt(j + 1)) {
    j++; 
}
// 3. 完全匹配检查：j=5 != 7，不返回
if (j == m) {
    return i - m;
}

第 8 次循环：

// 1. while循环：j=5>0，但s[8]='A' == p[6]='A'（j+1=6），循环不执行
while (j > 0 && s.charAt(8) != p.charAt(j + 1)) {
    j = next[j];
}
// 2. 字符匹配：s[8]='A' == p[6]='A'，j自增为6
if (s.charAt(8) == p.charAt(j + 1)) {
    j++; 
}
// 3. 完全匹配检查：j=6 != 7，不返回
if (j == m) {
    return i - m;
}

第 9 次循环：

// 1. while循环：j=6>0，但s[9]='B' == p[7]='B'（j+1=7），循环不执行
while (j > 0 && s.charAt(9) != p.charAt(j + 1)) {
    j = next[j];
}
// 2. 字符匹配：s[9]='B' == p[7]='B'，j自增为7
if (s.charAt(9) == p.charAt(j + 1)) {
    j++; 
}
// 3. 完全匹配检查：j=7 == m=7，返回i - m = 9 - 7 = 2
if (j == m) {
    return i - m;
}

最终结果：返回2（对应原主串”ABABABCABA”的起始下标，即从第 3 个字符开始匹配成功）

李克勤院士

2025-06-27T06:49:56.000Z

李克勤院士

You get it,you get it;you don’t get it,you don’t get it.

How to Position Yourself

关于怎样定位自己我觉着是极其重要的，作为计算机专业，研究方向其实也就固定的几类，按照李老师的分就是Theory,Algorithm,Middleware (theory-oriented),Middleware (system-oriented)。现在当下最火的毋庸置疑就是Algorithm里的dl。非常搞笑的现状就是人人都AIAI的叫，但基本没多少人懂其到底是啥，有同学读研更是盲目，在不清楚的前提下就入坑，所以建议考虑一下自身情况，万一自己更适合系统等方向呢？再没有Passion的情况下是很难做好一件事的。还有一类人也是非常搞笑的，就是有些想要考研的，其实很多人都对自己定位不清晰，自己到底适不适合考试都不知道，未来要干啥也不知道，就想在学校的温床里躺平，延缓就业，有些甚至二战三战，不多评价，祝好！

Theory + System? No!

既要又要=一无所获。你既要搞研究又要申请专利又要开公司又要抢占市场又要上市，一个人根本不可能做到这些的。这就不得不提大学里面大量水的一批的竞赛了，反正自己判断吧，对自己价值有多大都心里有数，打磨内核才是硬道理。

How to Get into a Research Area

Read extensively but selectively

知道自己干啥别瞎干。

Find the research topic by yourself

这个其实就多少有点意思了，其实一般来说我们高校里的科研就是导师干什么你就干什么，很少有自己选题的。李老说他当时在美国读书的时候所有研究课题都是他自己选择的，哈哈。

Choose a topic of your favorite

还是Passion的问题。

Choose a topic that matches your experience and capabilities

还是自我定位

Learn the background knowledge and skills only when necessary

必须得这样。

Do not rely on your supervisor

青出于蓝而胜于蓝不是没有道理的。李老师说当年他美国的导师是助理教授，把他送走后就立马成了副教授，因此李老师帮导师评上了副教授，结果几十年过去了，李老师不断攀登，而他导师还是副教授。。。

Do not switch areas

换来换去就完蛋了！

How to Find an Original Idea

怎么找创新点？

Scientific research is an individual and creative process

科学研究是一个人发挥创造性的过程，这个我非常认同李老师的观点，李老师说他不理解为什么现在文章都是五六个作者甚至十几个作者，创新点不就是一个人想出来的吗还能是一人想n分之1吗。要是其他人说可信度还没那么高，但是李老师的确毋庸置疑，200多篇独立作者发布的文章，恐怖如斯。老师还自嘲说一千多篇剩下的八百多篇共同作者的都是腐败出来的，哈哈。其实有时候不是独立作者发布文章还会产生一些纠纷比如杨振宁李政道两位老先生的决裂。

You get it, you get it; you don’t get it, you don’t get it

这个是李老师读博的时候和一个他钦慕的导师聊天时，李老师问怎么找创新点，这个学者给的回答，很哲学但也正确，有就有，没就没，就这么简单。

You should not rely on others

不只学术上，方方面面如此，关键时刻谁都没你自己靠谱。

There is no standard process

路都是自己探索出来的，其实没必要畏缩，多试错才能有成长。

There is no shortcut

脚踏实地。

Every paper is not easy to publish

坚持。

How to Make Research Deeper and Wider

You must think deeply and uninterruptedly with concentration

专注。

New ideas may come unexpectedly, but not surprisingly

山重水复疑无路，柳暗花明又一村。

The first idea is the most difficult to obtain

万事开头难。

Usually more and deeper ideas will come when you write a paper

递进。

More papers, more ideas

菜就多练。

New Problems, old methods

变与不变。

New research areas can be opened more easily with more experience

其实也不一定要一味追求热门潮流，在自己领域深耕也是不错的选择。

发表单作论文的条件

能力(对资深学者是一个挑战)

因为有时候屁事一大堆，所以有些学者没法concentrate on。

勇气(对青年学者是一个挑战)

这挑战也是有点大。

动力(梦想+目标+信念+追求+执着+激情)

甭管能不能做到反正发表单作论文应该是每个学术研究者的ultimate goal!
Passion是李老师一直在强调的，干什么事没有激情都很难持续，更别提做好了。

大师

在36年间（1989-2025），共发表了1,130篇论文，年均31篇。在35年间（1989-2024），其中245篇论文为单独或第一作者，年均7篇。这里李老师举了个非常有意思的例子，就是我们甚至不用自己创新，找现成论文直接代码复现然后用latex敲出来一年能做到七篇吗？哈哈。真大师。

Time Management

Set long-, mid-, short-term plans and goals
Set milestones
Set priorities

就比如我要想准时来听李老师讲座我就必须在25分钟内写完Java考试卷，然后还要借辆自行车才能赶到，其实还少考虑了一个事情就是去的晚可能就没座位了。我还发现个可怕的事实，我上大学除了这次外我从来没干过时间规划。

人生楷模

这两位是李老师的楷模那更是我们的楷模。

董韫美院士

董院士是李老师在中科所读研的导师，李老说当时只要一个人但是有九个人报考，后来李老师第一把他们干掉了哈哈。董老师也是单作论文作者值得敬佩。

黄凯教授

最让我印象深刻的是黄老师工作到80岁回国后还去港中文任教了五年，而且黄老师独立作者出了十几本书可谓“著作等身”。而且还紧跟潮流，出新东西就会立马学习钻研，终身学习。

从一而终

李老师其实这波讲座狗粮洒满，就不说了真是秀恩爱楷模。。。不管是对科研还是爱情李老师都是从一而终的，而且李老师和夫人在教育孩子上也是极其成功的，培养了三个“藤娃”！

健康第一

其实有个老掉牙的例子就是健康是1，其他都是0，1没了就全没了，所以健康真的很重要，反复鞭策。。。

QA

我第一个问题就是当时的学习条件远不如现在优渥，当时您是怎么学习的？李老师的回答大概如下,Passion,有次甚至去IBM图书馆查了一天资料；第二个问题是您遇到最大的困难是什么，怎么克服的？这个李老师没有想好，回头告诉我；第三个问题是正常情况下您的一天安排是什么？这个多少涉及隐私了，但是李老师还是进行了回答，老师说一般会睡到自然醒（不熬夜），然后早上起来一般会先回复微信消息（合作的一千多人吧），比如学生的问题、论文的问题，还会直接打语音进行解答。然后就是保持高效率。

Passion

李老师说他虽然62岁了(其实根本看不出来，声如洪钟，快两个小时的讲座全程Passion,还留着和我一样走在时尚最前沿的寸头)，但他心里认为自己至多18岁。讲真，我虽然没过十八多久但早已没年少时的锐气和Passion了，惭愧之至，希望哪天Passion之火能重燃。

结语

总之这是我有史以来听过最有价值的讲座，李老师幽默风趣，实力超群实为吾辈楷模！

碎梦后繁星

2025-05-31T07:33:59.000Z

碎梦后繁星

primary ——The only thing you have to fear is fear itself

迷茫

作为大学生，不管什么专业初入大学时或多或少都会迷茫，总结一下无不归结于一个原因，对未来不确定性的恐惧。

反思

你为什么要读研？上大学以来这句话让我印象最深，我自诩“能言善辩，巧舌如簧”，再加上我本身正直善良，所以很少有一些非知识性问题能让我沉默，但是当问出这句话的时候我沉默了，我找不出来能够自恰的答案，大一的时候我是电信专业，在电信实验室程序组的日子里不说专业知识编程能力的提高，最重要的是思想的升华，非常感谢w学长的启迪，我从清澈愚昧的大一新生蜕变成了现在的我。其实现在我还是不太好回答这个问题，首先，社会潮流所向，从研究生博士生扩招就可以看出大家都有相应需求；第二，大家普遍认为研究生毕业会有更好的工作进而有着较高的生活水平；第三，似乎大家都有名校情结，C9上清北，985上C9,211上985，双非上211；第四，你能遇见更优秀的人，甚至可以找到人生伴侣等等吧。听起来确实不错。

转专业

为什么要转专业，核心原因是我不想上一堆实验课还有两大天书电磁场和信号系统，转计算机纯纯想轻松点。。。

规划

绝大部分大学生对工作是抵触的，在大学，你可以领着父母给的低保吃喝不愁，回家还能享受亲戚邻里的大学生荣耀头衔的夸赞，周末都能放假，寒暑假甚至多于小学生，再者只要你愿意你甚至可以天天放假。其实这都不是本质原因，可能更核心的大学生不愿意面对找工作这个事实的是心里对美好月薪过万生活的向往和现实月薪5000的牛马生活的矛盾，简而言之就是高不成低不就，其实找工作大学生还是很好找的，只要你不挑剔。其实说实话我是幸运的，因为我要高考成绩高点我就会去读数学专业了，为什么？当时的认知就是数学物理，有点好笑。所以有时候真的，塞翁失马，焉知非福！大家一定要有一个乐观的心态。再说下工资问题，可能除了部分计算机专业的同学本科毕业外，其他专业大概很难本科就能拿上万的薪水，所以要是其他专业的同学，也许也只有读研这一条出路了吧。

就业压力大

现在大家可能都会听说过这样一句话，工作难找。我再次声明我单纯从计算机专业本科生角度来阐明一下这个问题是有多么荒唐可笑。举一个例子，一个人是高富帅，学历还好，他能做我的老婆吗？显然不行！为什么呢？因为老婆的首要条件是女性。同理，找工作也是这样啊，首要条件就是你满足公司招聘需求。那怎么看你是否满足呢，打开boss直聘或者牛客看下招聘要求，对于开发岗来说几乎清一色要求本科及以上学历，需要掌握某某某某，显然就目前情况来说，前者显然满足甚至条件还有点优越毕竟双一流，后者就分人了大部分是不合格的。然后可以大概搜一下牛客的面经看下面试问题，我想绝大部分会和我感受一样，嘛也不会，随便举个例子，大家都学过数据库吧，那我问MySQL中的MVCC是什么，不是说你不知道而是你不能很好的深入的解释出来，其实大部分可能还真不知道。那么问题就来了，如果一个985硕士去面试问的问题要么一知半解要么完全不会，换位思考作为老板你会要吗？而且研究生搞得大多是深度学习，和开发区别还是蛮大的，所以其实要求本科及以上学历的原因也就很明显了吧，其实有时候，年龄也是一个巨大的优势。一个很显然的事实就摆在面前你不合适有的是人合适，所以这就是为什么很多计算机专业本科生甚至研究生就不了业的原因（其实计算机专业进互联网行业的比例我觉着92可能平均下来可能也不到40%），是大家普遍渲染的学历焦虑吗，不是，而应该是能力欠缺。其实有趣的一点是真正适合不断深造的人能力往往能力是极强的，不管升学还是就业总会游刃有余，不会存在一般人的焦虑的，可惜大部分人选择深造是无厘头的跟风式的毫无自知之明的，问原因，学历焦虑。

学历贬值

现在因为扩招所以学历贬值这个词非常流行，对于其他专业我不予置评，了解的不深入没有亲身经历时是不具备评判资格的，不过可笑的是，这一点绝大部分人都做不到，一知半解就口无遮拦，极其可笑愚昧。但是作为计算机专业我可以很负责的告诉你这四个字就是扯淡，一个很显然的事实各大厂top计划算法岗年薪百万，应届。其实作为计算机专业本科生进大厂几乎就是一些冷门专业博士毕业的价格，甚至更高，但是也不是每一个本科生都能进大厂，哈哈哈，所以说我是幸运的要不就去学数学了，可能大抵会比较崩溃，不过其实就我亲身经历而言我其实建议想搞深度学习的其实本硕都可以读数学，因为计算机自学资源太多了，而且难度老少皆宜，数学就不一样了，没有环境可能很难学下去，其实深度学习对数学要求还是蛮高的所以往往数学系的转计算机博大抵是可以乱杀科班子弟的。其实还有一个值得思考的问题，假如你选择开发，那么你大学所谓的高等数学线性代数概率统计是没有任何用处的，更别提大学物理这种和计算机风马牛不相及的科目了，如果你想深造搞算法这些也没用，因为浅尝辄止远远不够用。所以其实大学有些课程啊满足等式，上课=坐牢=浪费时间。

35岁危机

现在网上比较热门的还有一个话题，“程序员的35岁危机”，很多懂哥懂姐又要开始输出了，还是别学计算机了，行业饱和了还有裁员风险，赶紧考公考编吧，铁饭碗多稳定啊。然后就开始同情被裁员的大厂程序员，年纪轻轻就失业，好悲惨。讲真，我也不知道该同情谁，你说人家没了工作，人家可能已经在北上深买房了，或者拿着攒下来的几百个w采菊东篱下悠然见南山，或者换个大厂继续卷了，而你，可能退休前也没这数，所以有时候真没必要同情别人。其实裁员很正常，我觉者分两种第一种只会增删改查写屎山的程序员，不把你优化了那些优秀的年轻人怎么进来；第二种，可能因为业务变动整个组或部门都没了，我管你优秀与否呢。显然前者失业就真失业了，后者选择权在自己。（其实有个规划找份稳定工作也挺好的）

责任

大学带给我最大的蜕变就是成长，但是现实确实挺悲惨的，绝大部分大学生不是选择承担，而是选择逃避。逃避就业上文已经有过阐述我就不再重复，其实大部分选择深造的也是一种逃避，因为不想就业或者没有能力就业就要选择深造，甚至未来到底要干嘛都一知半解，那么我这有几个问题，选择深造的大部分可能都给不出答案，第一，你是否适合科研或者了解过科研，其实很多科研佼佼者或者大厂top计划候选人是有着不俗的Noi和Acm成绩的，但是也有很多代码能力强的并不适合科研，所以我觉着强代码能力是科研的必要不充分条件。第二，沉没成本你能承担的起吗，这个就有两方面了，其一，科研有时候要看运气，如果你的想法和另外的一个人的重复了，早了一切顺利，晚一步所有努力付之一炬，这还是在顺利的情况下，如果不顺利，其中的艰辛可能只有本专业的能体会吧；其二，你的家庭情况，我在两个电信班和一个计科班呆过，每年贫困认证都是40%以上，所以其实有时候你的选择不一定取决于你，你还要多为父母家人考虑，更需要结合自身情况审慎定夺。

结语

鲁迅先生说过，“中国的青年应该有志气，要有自己的独立思想。”其实现在也许是家庭或学校教育确实存在一些问题，尤其是家庭教育，好多家长总是喜欢强迫孩子干这干那，导致很多人学傻了，失去了自己的个性，埋没了兴趣爱好和天赋，没有自己的思考和思想，人云亦云；他还强调，“青年最要紧的是勇于探索，不怕吃苦。”技术在不断更迭变化，我们恰好是计算机专业，与时代同频共振，所以要与时俱进，勇于探索新知识和新领域，不怕面对困难和挑战；并且，他进一步指出，“青年人要做一个有用的人，不要只做一个看热闹的人。”我们绝非旧时代的残党，而是要开创新时代的人，我们要勇敢追求自己的理想，并为社会做出贡献。即使是点点星光，最终也会汇聚成辉煌的光芒，只要我们年轻一代心怀梦想，不断拼搏，祖国将在我们的建设下崛起，我们的生活也会越来越美好。

破茧者~BLOG

当 AI 编程进入下半场，拼的不是模型，而是 Harness

当 AI 编程进入下半场，拼的不是模型，而是 Harness

Harness 到底是什么

从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering

OpenAI 真正讲明白的，不是“AI 写了一百万行代码”，而是“工程师开始不直接写代码了”

Anthropic 讲得更现实：长任务真正的敌人，不是笨，而是失忆和自我感觉良好

四个具体案例，比概念更能说明 Harness 到底在补什么

1. 编辑工具本身就是 Harness，不只是小配件

2. 技术债在 Agent 时代不是线性累积，而是指数扩散

3. 子 Agent 真正值钱的地方，是做上下文防火墙

4. 成功应该是沉默的，只有失败才应该发声

HumanLayer 这批文章最值钱的地方，是把很多细活讲透了

Thoughtworks、Inngest 这些文章把另外半边补上了：别迷信框架，要重视系统纪律

很多人现在最缺的，不是更多 Agent，而是更像样的规格、评估和可观测性

Harness 越强，Spec 越重要，这不是二选一关系

为什么现在 benchmark 也越来越像在测 Harness，而不是单测模型

开源实现也越来越多了，但越看越会发现：真正稀缺的不是框架，而是系统能力

对企业来说，Harness 还不只是提效工具，而是群体智能的治理层

看完这一圈文章之后，我现在对 Harness 有三个更明确的判断

普通人今天能怎么开始

写在最后

参考资料

鹅厂九人谈：如何让Agent自动持续进化

鹅厂九人谈：如何让Agent自动持续进化

1. 先别急着优化，先学会量化

2. 临时工和正式工：两种记忆策略

3. 失败比成功更值钱

4. 人在回路：安全员的智慧

5. 冻结的大脑 vs 流动的上下文

6. 让 Agent 学会反思

7. 用 AI 优化 AI：自动进化的 System Prompt

8. 测试驱动的 Agent 进化

写在最后

当程序员不再写代码——看完 Peter Steinberger 采访后的技术思考

当程序员不再写代码——看完 Peter Steinberger 采访后的技术思考

这个男人到底什么来头

让 Agent 自己调试自己

Agentic Engineering：不是 Vibe Coding

Skills 和 CLI 才是正道，MCP 靠边站

当编程变成织毛衣

写在最后

程序员如何高效使用 Claude Code

程序员如何高效使用 Claude Code

一、理解核心约束：200K 上下文窗口

关键操作

二、CLAUDE.md — 最重要的配置文件

该写什么

不该写什么

关键原则

文件层级

Rules 目录 — 模块化替代方案

三、Subagent（子代理）— 上下文保护的利器

尤雨溪的核心建议

推荐的子代理架构

子代理定义示例

迭代检索模式

Writer/Reviewer 模式

四、Hooks — 确定性的自动化

六种 Hook 事件

实战 Hooks 配置

五、上下文与记忆管理 — 跨会话持久化

跨会话记忆文件

动态系统提示注入

记忆持久化 Hooks

持续学习系统

六、Token 优化 — 省钱又提效

模型选择框架

推荐配置

工具优化

MCP 替换策略

七、工作流最佳实践

四阶段工作流（官方推荐）

验证循环 — 单一最高杠杆率实践

验证评估指标

五阶段顺序架构（复杂任务）

八、并行工作 — 成倍提升吞吐量

Boris Cherny 的工作设置

并行策略

两实例启动模式（项目初始化）